From: Rick James Date: April 29 2011 6:52pm Subject: Re: replication error 1236 start replication from impossible position List-Archive: http://lists.mysql.com/replication/2095 Message-Id: <4DBB08D5.7040406@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit _Usually_ that is caused by the Master dying, and you have sync_binlog=OFF. Details... * Master sends binlog stuff to slave(s) before flushing to binlog * Slave gets the stuff and writes to the relaylog, calculating where it logically is in the binlog * Master crashes without flushing. * Slave is disconnected * Master comes back up. * Master starts a new binlog (as is normal for starting up) * Slave reconnects and asks to pick up where it left off in the binlog. But that is off the end of the unflushed binlog. The Fix (on Slave) -- CHANGE MASTER TO master_file = ... master_pos = 0 (or 4); the file is that new binlog mentioned above. (That is what you did.) Caution: whereas sync_binlog=ON may cure it in the future, it can take a severe toll on I/O. On 4/29/11 5:39 AM, Johan De Meersman wrote: > ----- Original Message ----- >> From: "a smith" >> >> I have a replication setup with one master and two slave systems. >> Both slave systems have failed with the error: >> >> Got fatal error 1236 from master when reading data from binary log: >> 'Client requested master to start replication from impossible >> position' >> >> The master has not crashed or experienced other similar problems, >> what might have caused this? > Hmm. I've seen this a few times over the last weeks, but I ascribed it to an unstable underlying filesystem. That's been patched now, so I'll see wether it pops up again. > > I pretty much set the master position to the start of the next log and then used maatkit to verify consistency when the slave cought up. > -- Rick James - MySQL Geek