RE: Recovery with binary logs.
Hi Martin, Thank you very much. My system is Linux based so your answers are exactly what I need. One more question though: when you use the --record_log_pos option in mysqlhotcopy, where is that position recorded? In the logging output of the program or somewhere else? Thanks again, Manuel -Original Message- From: Martin Waite [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 28, 2002 3:19 AM To: Manuel Villasante Cc: '[EMAIL PROTECTED]' Subject: Re: Recovery with binary logs. Hi Manuel, On Tue, 2002-11-26 at 21:38, Manuel Villasante wrote: Hi, I have a few questions regarding recovery of a database using binary logs. 1) If you have a set of binary logs in your directory mylog-bin.001 to mylog-bin.nmp, is there an easy way to find out which logs you need to run since the last backup? In other words, when according to the instructions, after replacing the database files with the backup ones, you run the command: mysqlbinlog mylog-bin.[0-9]* | mysql does it know automatically which set to include so as to not incorporate logs that are too old? Or do we have to manually perform a selection? If so, is there a way to figure out easily the subset if one has not been watching it? At the time of backup, you need to record the master position of the server you are backing up - or perform reset master, but this might threaten your recovery if you have a failure during the current backup process and have to roll-forward from your previous dump (requiring the binary logs that reset master have just deleted). If you record the master position (file name, offset) during your dump, you need to ensure all tables involved in the dump are locked. mysqlhotcopy can do all this for you, see the --record_log_pos option. Unfortunately, mysqlhotcopy only works on Unix-like OSes, and so you will need to roll your own if your OS is not supported. 2) If a loss of data has been caused by an unwanted statement like DROP DATABASE... or DROP TABLE VeryImportantOne, how can one delete that statement from the bin-log before using it for recovery and repeat the mistake? You could write the output of mysqlbinlog to file, edit the file, and then pipe the file into the mysql monitor: mysqlbinlog mylog-bin.[0-9]* file.sql edit file.sql mysql file.sql good luck, Martin - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Recovery with binary logs.
Hi Manuel, On Tue, 2002-11-26 at 21:38, Manuel Villasante wrote: Hi, I have a few questions regarding recovery of a database using binary logs. 1) If you have a set of binary logs in your directory mylog-bin.001 to mylog-bin.nmp, is there an easy way to find out which logs you need to run since the last backup? In other words, when according to the instructions, after replacing the database files with the backup ones, you run the command: mysqlbinlog mylog-bin.[0-9]* | mysql does it know automatically which set to include so as to not incorporate logs that are too old? Or do we have to manually perform a selection? If so, is there a way to figure out easily the subset if one has not been watching it? At the time of backup, you need to record the master position of the server you are backing up - or perform reset master, but this might threaten your recovery if you have a failure during the current backup process and have to roll-forward from your previous dump (requiring the binary logs that reset master have just deleted). If you record the master position (file name, offset) during your dump, you need to ensure all tables involved in the dump are locked. mysqlhotcopy can do all this for you, see the --record_log_pos option. Unfortunately, mysqlhotcopy only works on Unix-like OSes, and so you will need to roll your own if your OS is not supported. 2) If a loss of data has been caused by an unwanted statement like DROP DATABASE... or DROP TABLE VeryImportantOne, how can one delete that statement from the bin-log before using it for recovery and repeat the mistake? You could write the output of mysqlbinlog to file, edit the file, and then pipe the file into the mysql monitor: mysqlbinlog mylog-bin.[0-9]* file.sql edit file.sql mysql file.sql good luck, Martin - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Recovery with binary logs.
Hi, I have a few questions regarding recovery of a database using binary logs. 1) If you have a set of binary logs in your directory mylog-bin.001 to mylog-bin.nmp, is there an easy way to find out which logs you need to run since the last backup? In other words, when according to the instructions, after replacing the database files with the backup ones, you run the command: mysqlbinlog mylog-bin.[0-9]* | mysql does it know automatically which set to include so as to not incorporate logs that are too old? Or do we have to manually perform a selection? If so, is there a way to figure out easily the subset if one has not been watching it? 2) If a loss of data has been caused by an unwanted statement like DROP DATABASE... or DROP TABLE VeryImportantOne, how can one delete that statement from the bin-log before using it for recovery and repeat the mistake? Thanks in advance for any help provided, Manuel Villasante - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php