mysql binary logs, specifying the database for each command - mysql

I am looking to write a backup / restore script based on MYSQL's binary logging.
I have a database on a mysql server, and my colleague also has his own database on the same mysql server.
Looking at the binary logs, I see the statements are logged for both these databases.
Is the database being written to specified in the logs?
Can I safely replay a binary log containing an extra database in it - i.e. I want to replicate database_A, my binary log file contains commands sent to database_A as well as database_B, can I replay these commands into a copy of database_A safely? Or do I need to ask my sysadmin to only log things for dataabse_A?

OK, studying the log files a bit more, it seems that the mysql binlog utility adds the "use database" statements in the appropriate place. I added a part to my script that effectively grepped out the relevant database statements.

Related

how to recover deleted rows from MYSQL database

Today morning I surprisingly found that some data is deleted form my MYSQL database, I am unable to find that data in any table.
Please suggest how to recover data from MySQL database, DOES MYSQL keeps any Log if yes where it is located?
Please suggest any query to get all records.
I am using MYSQL Workbench 5.
If you have binary logs active on your server then you can use mysqlbinlog
You can use the following:
mysqlbinlog binary_log_file > query_log.sql
If you don't have this, then you have probably lost it.
You can look here for more information on how to convert the binary logs to sql.
You can check if binary logging is enabled or not by running the following command:
SHOW VARIABLES LIKE 'log_bin';
For InnoDB tables, if binary logs are not enabled, there is a recovery tool provided by Percona which may help.
Created a script to automate the steps from the Percona tool which recovers the deleted rows (if exist) and provides SQL queries to load the data into database.
Please note:
The time between the deletion of rows and the database stop is
crucial. If pages are reused you can’t recover the data.

Can I recover dropped database in MySQL?

I accidentally dropped a database which I used for my web application, and it is in MySQL. Browsing through the internet I found out that to recover you need to have binary logs enabled. Read that binary logs records only changes in tables, so what it has to do with recovering a db. Upon executing the command "show binary logs;" console shows me "Error Code: 1381. You are not using binary logging". I am a newbie to MySQL, so is it possible to recover it without my binary logging enabled PLUS I have not made any real backup for the db. Going through the MySQL "my.cnf" file found that InnoDB is default enabled, can it help me recover.
If I cannot recover, please mention the steps to be carried out next time creating a new db to ensure that I could recover even if it has been accidentally deleted.
I think it can't be recovered. In case of this case, you can do the following when creating a new db:
open the binary log by add the following:
log-bin=/data/mysqlbinlog/mysql-bin
binlog-format=mixed (or row)
create a slave db.
Good luck for you.

mysql cluster lost data after restore

all,
I use mysqldump to backup mysql cluster data with 10 million lines data daily. Recently, our cluster is crashed after a update, then we restore the .sql file generated by mysqldump. When restoring the database, we got key duplication errors/problem, and then I use "-f" to force the restore process. And finally, the restore process completed and all tables is back. Some tables are smaller, we think that is because the duplicate lines are ignored.
But recently, we find some data is missing, it seems that some duplicated data dose not restored correctly.
May I know whether there is a nice way to avoid this in restore process or how to check whether we have duplication before mysqldump?
Couple of suggestions - take a look at the errors that are generated when not using the force option and see if you can figure out how to fix the root cause. Using the force option allows the restore to continue after the error but the failed rows will still be lost.
Is there a reason why you're using mysqldump rather than the backup command within ndb_mgm - which is an online operation? If using the native Cluster (on-line!) backup then you use the ndb_restore command to restore your data.

mysql best backup method? and how to dump backup to target directory

What is the best method to do a MySQl backup with compression? Also, how do you dump that to specific directory such a C:\targetdir
mysqldump command will output CREATE TABLE and INSERT commands that are sufficient to recreate your whole database. You can back up individual tables or databases with this command.
You can easily compress this. If you want it to be compressed as it goes, you will need some sort of streaming tool for the command line. On UNIX it would be mysqldump ... | gzip. On Windows, you will have to find a tool that works with pipes.
This I think is what you are looking for. I will list other options just because.
FLUSH TABLES WITH READ LOCK will flush all data to the disk and lock them from changing which you can do while you are making a copy of the data folder.
Keep in mind, when doing restores, if you want to preserve the full capability of MySQL bin logs, you will not want to restore parts of a database by touching the files directly. Best option is to have an alternate data dir with restored files and dump from there, then feed to your production database using regular mysql connection channels. Any direct changes to the filesystem will not be recorded by binlogs.
If you restore the whole database using files, you will be OK. Just not if you to peices.
mysqldump does not have this problem
Replication will allow you to back up to another instance of MySQL running on the same or different machine.
binlogs. Given a static copy of a database, you can use these to move it forward in time. binlogs are a log of all the commands that ever changed the data. If you have binlogs back to day one, then you may already have what you are looking for. You can run all the commands from the binlogs from day one to any date you wish and then you have a copy of the database from that date.
I recommend checking out Percona XtraBackup. It's a GPL licensed alternative to MySQL's paid Enterprise Backup tool and can create consistent non-blocking backups from databases even when they are written to. See this article for more information on why you'd want to use this over mysqldump.
You could use a script like AutoMySQLBackup, which automatically does a backup every day, keeping daily, weekly and monthly backups, keeping your backup directory pretty clean and uncluttered, while still providing you a long history of backups.
The backups are also compressed, naturally.

Where can I find the MySQL transaction log?

Does MySQL keep a transaction log and if so where could I find it?
A number of rows have mysteriously been deleted from a table and I want to try and see how and when it occurred.
If you turned on - mysql can track binary log, which contains all the modifications (to be clear - it contains the queries that had changed something).
But anyway, it is useless if you do not have the initial dump, which precedes the binlog turning on. Also i suppose if you made the dump and turned on binlog - you would not ask such question :-S
Short answer: not by default.
In order to have accurate logging results, you need to have started the server in binary logging mode first, using the parameter --log-bin=your-file-name. It then creates a binary log file {your-file-name.seq} where seq is a sequence number for subsequent log files (recommended to put your file name there, with explicit directory location).
More information on the MySQL site explaining all the details: https://dev.mysql.com/doc/refman/5.7/en/binary-log.html
If you're using MySql on Windows, there's a file located in C:\Program Files\MySQL\MySQL Server 5.0\data (assuming a C: drive for the installation target and MySql version 5.0), that is called %COMPUTERNAME%.log that contains the commands that have been executed.