# our slave fell behind due to restart and now getting error

**URL:** <https://forums.percona.com/t/our-slave-fell-behind-due-to-restart-and-now-getting-error/1528>\
**Category:** Other MySQL® Questions\
**Created:** [October 8, 2010, 6:51pm UTC](https://forums.percona.com/t/our-slave-fell-behind-due-to-restart-and-now-getting-error/1528 "2010-10-08T18:51:43Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![iberkner](https://avatars.discourse-cdn.com/v4/letter/i/c67d28/32.png) [@iberkner](https://forums.percona.com/u/iberkner)\
**Post date:** [October 8, 2010, 6:51pm UTC](https://forums.percona.com/t/our-slave-fell-behind-due-to-restart-and-now-getting-error/1528/1 "2010-10-08T18:51:43Z")

</div>

one of our backup slave systems had to be restarted and we forgot to start the slave. It was a few days before someone noticed and when we now try to start the slave we get an error:

Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file’

Running show slave status, shows the information below:

Master\_Log\_File: mysql-bin.001067  
Read\_Master\_Log\_Pos: 137138436  
Relay\_Log\_File: relay-bin.000267  
Relay\_Log\_Pos: 4  
Relay\_Master\_Log\_File: mysql-bin.001067

I’m pretty sure I understand what’s happening, in looking at the master directory where the bin files are stored, the earliest one is “mysql-bin.001077”. Basically, b/c of the late restart, the slave is now to far behind to catch up via bin files, is that correct?

What is the best course of action? does the slave data have to be re-loaded?

Thanks

---

<div class="post-metadata">

**Author:** ![iberkner](https://avatars.discourse-cdn.com/v4/letter/i/c67d28/32.png) [@iberkner](https://forums.percona.com/u/iberkner)\
**Post date:** [October 9, 2010, 3:24pm UTC](https://forums.percona.com/t/our-slave-fell-behind-due-to-restart-and-now-getting-error/1528/2 "2010-10-09T15:24:41Z")

</div>

I solved the problem by dumping a copy of another slave and following the instructions found here:

[URL=“http&#58;&#47;&#47;[MySQL :: MySQL 8.0 Reference Manual :: 4.5.4 mysqldump — A Database Backup Program](http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html)”][/URL]

Specifically:

It is also possible to set up a slave by dumping an existing slave of the master. To do this, use the following procedure on the existing slave:Stop the slave’s SQL thread and get its current status:mysql\> STOP SLAVE SQL\_THREAD;mysql\> SHOW SLAVE STATUS;From the output of the SHOW SLAVE STATUS statement, the binary log coordinates of the master server from which the new slave should start replicating are the values of the Relay\_Master\_Log\_File and Exec\_Master\_Log\_Pos fields. Denote those values as file\_name and file\_pos.Dump the slave server:shell\> mysqldump --master-data=2 --all-databases \> dumpfileRestart the slave:mysql\> START SLAVE;On the new slave, load the dump file:shell\> mysql \< dumpfileOn the new slave, set the replication coordinates to those of the master server obtained earlier:mysql\> CHANGE MASTER TO → MASTER\_LOG\_FILE = ‘file\_name’, MASTER\_LOG\_POS = file\_pos;The CHANGE MASTER TO statement might also need other parameters, such as MASTER\_HOST to point the slave to the correct master server host. Add any such parameters as necessary.

This URL was also interesting (if you want to do it one db at a time with minimal downtime):

[URL=“http&#58;&#47;&#47;[www.elevatedcode.com/articles/2008/03/02/creating-a-mysql-slave-from-a-running-master/](http://www.elevatedcode.com/articles/2008/03/02/creating-a-mysql-slave-from-a-running-master/)”][/URL]

---

<div class="post-metadata">

**Author:** ![przemek](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/przemek/32/3_2.png) [@przemek](https://forums.percona.com/u/przemek)\
**Post date:** [October 18, 2010, 9:08am UTC](https://forums.percona.com/t/our-slave-fell-behind-due-to-restart-and-now-getting-error/1528/3 "2010-10-18T09:08:07Z")

</div>

Yeah, reloading data was the only solution you could take in this case.

For the future I’d suggest you to look at the ‘expire\_logs\_days’ variable - maybe you have enough disk space to keep old binlogs longer.  
Also any script monitoring replication status would save you a lot of time.

Btw. “show binary logs” and “purge binary logs to …” commands are very handful in doing smart binlog rotating scripts )
