Home > Databases, MySQL, Technical > MySQL Replication ERROR 1201: Could not initialize master info structure…

MySQL Replication ERROR 1201: Could not initialize master info structure…

November 19th, 2008

I have noticed strange behavior with MySQL version 5 and replication. I manage several MySQL database servers. The setup is simple, one master and two replication slaves acting as backups. The master server version is 5.0.22-log and the two slaves are 5.0.51a and 5.0.45.

When the replication gets interrupted (either via a clean server shutdown or a forced one), replication refuses to restart citing the following error:

ERROR 1201: Could not initialize master info structure, more error messages can be found in the MySQL error log

The master.info file is present in the data directory and has all the required information in it but MySQL refuses to use it. Searching on the net did not yield anything definitive.

The simplest way to restart replication from this point is to re-enter the master.info data manually. Do the following:

  1. STOP SLAVE
  2. RESET SLAVE
  3. CHANGE MASTER TO MASTER_HOST=’your_master’, MASTER_USER=’your_login’, MASTER_PASSWORD=’your_password’, MASTER_LOG_FILE=’log_file’, MASTER_LOG_POS=log_position
  4. START SLAVE

At this point you want to execute ‘SHOW SLAVE STATUS’ and check to see if everything is running. Most times MySQL will stop since it tried to replay a duplicate record from the logs. We need to tell MySQL to skip that record and continue:

  1. SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1
  2. START SLAVE

That should get replication up and running again.

What is interesting to note is that, under the same circumstances, my MySQL 4 servers had no problems continuing replication. In any case, don’t forget to run regular backups of your database. ;)

Databases, MySQL, Technical , , ,

  1. lichi
    December 27th, 2008 at 10:18 | #1

    thanks… this error drive me crazy the whole day.

  2. November 29th, 2009 at 06:43 | #2

    Thats very good to know… thanks

  3. December 7th, 2009 at 19:25 | #3

    I really enjoyed your blog, Thanks. :)

  4. December 8th, 2009 at 00:54 | #4

    Thanks a lot. Bouncing our MySQL servers has just become a lot easier instead of doing a full dump and reload of the data from the master!

    Regards
    Lewis

  5. Andy
    December 11th, 2009 at 09:03 | #5

    Thanks for being the sole useful source of info on the matter!

  6. December 18th, 2009 at 07:40 | #6

    There were always people who can write beautifully and you are among them

  7. February 12th, 2010 at 08:10 | #7

    This helped a lot. I was able to get away with:
    stop slave; reset slave;
    CHANGE MASTER TO MASTER_LOG_POS=98 , MASTER_LOG_FILE = ‘mysqld-bin.000401′;
    start slave;

    the values came from running
    SHOW SLAVE STATUS\G
    before resetting :)

  8. February 14th, 2010 at 22:26 | #8

    @Akom
    Sounds like replication died right at the beginning of the log file in your case. I wonder if the master.info had the same data as listed by SHOW SLAVE.

  9. March 11th, 2010 at 17:56 | #9

    Зачетный пост, спасибо!

  10. April 5th, 2010 at 17:13 | #10

    спасибо за статью… добавил в ридер

  11. Lawal Adekunle
    May 16th, 2010 at 06:09 | #11

    Thanks a lot. You saved my day.

  12. May 18th, 2010 at 09:52 | #12

    То ли в википедии, то ли еще где я уже читал эту подборку данных, но все равно спасибо

  13. June 17th, 2010 at 03:08 | #13

    I really enjoyed you post, but still I am facing problem with my slave. it is not updating data from master. Output is below –

    Slave_IO_State: Waiting for master to send event
    Master_Host: 192.168.0.209
    Master_User: rplusr
    Master_Port: 3306
    Connect_Retry: 10
    Master_Log_File: mysql-bin.000009
    Read_Master_Log_Pos: 130188
    Relay_Log_File: mysqld-relay-bin.000003
    Relay_Log_Pos: 235
    Relay_Master_Log_File: mysql-bin.000009
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes

    Here Relay_Log_Pos: 235 always same.

    what should i do for this problem

  14. June 17th, 2010 at 09:25 | #14

    @Chetan, have you checked my post on the Silent Timeout Failure?

    Also, I have found that running replication over an SSH tunnel makes it more robust.

  1. No trackbacks yet.