_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"<a.smith@stripped>
>>
>> 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
