Mysql – Broken thesql replication on slave server (error 1236)

MySQLreplication

My question is: how to fix broken mysql replication on slave server (error 1236)?

server 1 (192.168.1.105)
server 2 (192.168.1.106)

I ran these steps to re-sync:

At the master – server 1 (192.168.1.105):

mysql -u root -p

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
Note > File: mysql-bin.000001 and Position: 107
mysqldump -uroot -p --events --ignore-table=mysql.events --all-databases > /var/backups/mysqldump.sql
UNLOCK TABLES;
Copy mysql dump file to server 2
(scp -p /var/backups/mysqldump.sql root@192.168.1.106:/tmp)

At the slave server 1 (192.168.1.106):

STOP SLAVE;
mysql -uroot -p < /tmp/mysqldump.sql
RESET SLAVE;
CHANGE MASTER TO MASTER_HOST='192.168.1.105', MASTER_USER='slaveuser', MASTER_PASSWORD='mypassword';
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;
START SLAVE;

I still got this error on server 1

Last_IO_Errno: 1236 Last_IO_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'

Best Answer

I believe the log file and position need to be specified with the host.

Try:

CHANGE MASTER TO MASTER_HOST='192.168.1.105', MASTER_USER='slaveuser', MASTER_PASSWORD='mypassword', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=107;

Related Solutions

Mysql – Max allowed packet changed still replication not starting

Try these steps:

1) Take a mysqldump from master

2) Restore it on a slave, whether it gets restored successfully?

3) You should not keep max_allowed_packet to a high value like 1G or 2G keep it minimal like 16M or 32M and restart Master server.

4) Apply same max_allowed_packet size in slave as well.3

5) Now, stop the slave, execute Change Master .... query accourdingly and start slave

I hope this will work for you.

Mysql – Error 1236 From Master After Restored Replication

This is a guess, but please note that the option server-id cannot be activated in a hot way. In my experience, this is a common cause of problems when setting up the replication for the first time, specially because the master accepts the following syntax without complaining:

mysql> SET GLOBAL server_id = 1;
Query OK, 0 rows affected (0.04 sec)

And the server id seems to have taken effect:

mysql> SHOW GLOBAL VARIABLES like 'server\_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 1     |
+---------------+-------+
1 row in set (0.02 sec)

But it doesn't work, (it does not have effect until restart and read from the my.cnf or passed as a parameter). The slave will complain until the master is restarted.

The official documentation is misleading, while it says it is dynamic in reality it is not (or at least it is not when setup for the first time, or setup with the default, etc.). See this bug for details, mentioning the misleading documentation.

In summary, activation of the binary logs and server id setup requires a server restart, so I always recommend to do it on installation time. Change it on the [mysqld]section of your configuration file and restart the service.

Related Question