I have made a backup, then I have executed several statements, including a delete. So I have recovered the backup but I only want to recover the binary log until before the delete operation, what command can I use for this?
Related
I accidentally deleted records in MSQL database and there is no backup no rollback transaction and i reallly want to recover deleted data back is there any tool to help ? how could i do ? please help me .
Is it MySQL or MSSQL they both are not same. MSSQL stands for SQL Server but by any means for you to recover deleted data either you should have taken a recent full/differential backup in place (or) if you have maintained transaction log. Then yes possible to get back your data by restoring from your backup (or) by reading from transaction log. Else, No there is no way to recover those data.
For InnoDB tables, if binary logs are enabled, one could use:
mysqlbinlog path_to_binary_log_file > query_log.sql
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 back 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.
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.
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.
I have tried several commands (FLUSH LOGS, PURGE MASTER) but none deletes the log files (when previously activated) or the log tables (mysql/slow_log.CSV and mysql/general_log.CSV and their .frm and .CSM counterparts).
SHOW BINARY LOGS returns "You are not using binary logging".
Edit: I found this simple solution to clear the table logs (but not yet the file logs using a mysql command):
TRUNCATE mysql.general_log;
TRUNCATE mysql.slow_log;
FLUSH LOGS just closes and reopens log files. If the log files are large, it won't reduce them. If you're on Linux, you can use mv to rename log files while they're in use, and then after FLUSH LOGS, you know that MySQL is writing to a new, small file, and you can remove the old big files.
Binary logs are different. To eliminate old binlogs, use PURGE BINARY LOGS. Make sure your slaves (if any) aren't still using the binary logs. That is, run SHOW SLAVE STATUS to see what binlog file they're working on, and don't purge that file or later files.
Also keep in mind that binlogs are useful for point-in-time recovery in case you need to restore from backups and then reapply binlogs to bring the database up to date. If you need to use binlogs in this manner, don't purge the binlogs that have been written since your last backup.
If you are on amazon RDS, executing this twice will do the trick:
PROMPT> CALL mysql.rds_rotate_slow_log;
PROMPT> CALL mysql.rds_rotate_general_log;
Source: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html
It seems binary logging is not enabled in your server .And i guess you want to delete the old log files which were used/created at the time of binary logging is enabled . you can delete them manually using 'rm' command if you want . if you want to enable the binary logging you can do the same by updating the configuaration file ( but it needs restart of the server if it is already running) . You can refer below links.
http://dev.mysql.com/doc/refman/5.0/en/replication-options-binary-log.html#option_mysqld_log-bin
http://dev.mysql.com/doc/refman/5.0/en/replication-options-binary-log.html#sysvar_log_bin
Is there any way in MySQL to only log deletes? I tried using the mysql binary log option but unfortunately, there are too many inserts to my database and the file swells instantly. If I let it grow for more than a day or so it will take up all the room on the server. I just want to log deletes for disaster recovery purposes. Any thoughts?
A log file contains all changes to a database. It can be used to roll a backup forward:
After a backup file has been restored,
the events in the binary log that were
recorded after the backup was made are
re-executed. These events bring
databases up to date from the point of
the backup
But in order to roll a database forward, the log has to contain all updates, not just deletes. So I don't think you can change it to just log deletes.
Is it an option to make full backups more often? After a full backup, you delete the old log files. That's a good way to keep the size of the binary log under control.
The MySQL binary logs take up disk
space. To free up space, purge them
from time to time. One way to do this
is by deleting the binary logs that
are no longer needed, such as when we
make a full backup:
shell> mysqldump --single-transaction --flush-logs --master-data=2 \
--all-databases --delete-master-logs > backup_sunday_1_PM.sql