Bryan, When the slave encounters that error, you can simply set it to replicate from the next binlog file in the sequence starting at position 98. It should be easy to have a script automate this process.
Regards, Gavin Towey -----Original Message----- From: Cantwell, Bryan [mailto:bcantw...@firescope.com] Sent: Friday, July 31, 2009 12:51 PM To: mysql@lists.mysql.com Subject: RE: Replication recovery on restart Yes I am trying to simulate total failure. In this test case I am using 2 Virtual Machines and I just kill one and then when it comes back I have the challenge described. How can I go about getting the slave back in tune with the newly restarted master? Thanks -----Original Message----- From: Gavin Towey [mailto:gto...@ffn.com] Sent: Friday, July 31, 2009 1:21 PM To: Cantwell, Bryan; mysql@lists.mysql.com Subject: RE: Replication recovery on restart Bryan, How are you restarting mysql? In the case a master crashes, it's definitely common for the slave to miss the fact that the master is using a different binlog. The slave advances to a position past the end of the previous binlog, and stops with and error like "tried to read impossible position." In this case you do have to intervene, but that's an easy enough case to write a script to handle. When restarting mysql normally, you shouldn't have this problem: i.e. service mysql restart / /etc/ini.d/mysql restart Regards, Gavin Towey -----Original Message----- From: Cantwell, Bryan [mailto:bcantw...@firescope.com] Sent: Friday, July 31, 2009 10:08 AM To: mysql@lists.mysql.com Subject: RE: Replication recovery on restart Before I simulate a total server failure, master1 is using binary file msyql-bin00001 position 2231467 and it's slave master2 is following the correct file at the correct position. This is after initial setup. Once I restart master1, it will then start to use msyql-bin00002 position 98 and master 2 is still trying to follow msyql-bin00001 position 2231467. And since I have this as dual master setup, if I simulate both boxes restarting in a total catastrophe, the masters both change files and the slaves remain trying to follow on the old information. -----Original Message----- From: Gavin Towey [mailto:gto...@ffn.com] Sent: Thursday, July 30, 2009 5:08 PM To: Cantwell, Bryan; mysql@lists.mysql.com Subject: RE: Replication recovery on restart Hi Bryan, Please define "out of whack." Tell us exactly what you're doing when you restart, and what the replication state is before and after, and where the updates are coming from. Regards, Gavin Towey -----Original Message----- From: Cantwell, Bryan [mailto:bcantw...@firescope.com] Sent: Thursday, July 30, 2009 11:00 AM To: mysql@lists.mysql.com Subject: Replication recovery on restart I have 2 machines 'master' and 'slave'. I have the mysql 5.0.51a-log databases both replicating wonderfully. They are configured in a dual master scenario so that one can take over for the other in my HA environment I've built. All is working great until... If one or the other box reboots or the mysql restarts, the replication gets out of whack. Especially if I simulate both of them crashing in a worst case scenario, they are then both trying to sync from the wrong Master_log_file and Read_Master_Log_Pos... Since catastrpohe WILL happen eventually (heence the need for HA) how do I direct the newly restarted boxes to the right position in the correct files on restart? Thanks -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=gto...@ffn.com The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=gto...@ffn.com The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=gto...@ffn.com The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org