I already wrote about some MySQL Error Messages which are confusing, here is one more:
1 2 3 4 5 6 7 8 9 10 | 080603 20:53:10 [Note] Slave: connected to master '[email protected]:3306',replication resumed in log 'master-bin.003676' at position 444286437 080603 20:53:10 [Note] Slave: received end packet from server, apparent master shutdown: 080603 20:53:10 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'master-bin.003676' position 444292333 080603 20:53:10 [Note] Slave: connected to master '[email protected]:3306',replication resumed in log 'master-bin.003676' at position 444292333 080603 20:53:10 [Note] Slave: received end packet from server, apparent master shutdown: 080603 20:53:10 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'master-bin.003676' position 444294573 080603 20:53:10 [Note] Slave: connected to master '[email protected]:3306',replication resumed in log 'master-bin.003676' at position 444294573 080603 20:53:10 [Note] Slave: received end packet from server, apparent master shutdown: 080603 20:53:10 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'master-bin.003676' position 444298239 080603 20:53:10 [Note] Slave: connected to master '[email protected]:3306',replication resumed in log 'master-bin.003676' at position 444298239 |
After setting up new slave Server I’m getting error log file flooded with messages like this and there is no hint in the message what would explain what is wrong.
In fact the issue in this case is (because of configuration error) two slave servers got the same server-id.
Seriously in this case Master clearly sees the problem in this case as there are 2 servers with same server-id connected and replicating so it should report it to the slave instead of sending end packet.
At very least it would be nice to include possible reason for this error message which MySQL already does in many other cases.
I’ve now filed it as a bug.
One day it happen to me, and took me almost an hour to find that out.
Moving foward I always use a base my.cnf to I copy to any other server and the first thing is to increase the server-id.
Could MySQL just use the servername intead of a numeric value?
Ernesto,
I think a lot of people have script or process to set server-id but things tend to break from time to time and it is great to get a good error message.
Server-id is stored in binary log and is integer this is why server-name would not work – too muich overhead.
Great post! I just got this error, and all the other related pages I could find were completely off-track.
Anyway, of the two slaves with the same server-id, one lagged behind with no apparent reason (of course now I know why), the other I just stopped it. Is the former slave going to ever reach the master (Seconds_behind_master = 0) or not?
Thanks whole bunch! Got the error in one of our clusters. Saved me a lot of time.
Definitely misleading and confusing. Almost got our network guy killed.
It really looks like intermittent network problem, the slave is catching up with master but through errors every second.
btw, our version is 5.0.84-64
Amazing! Thank you! 😀
Guys,
i get exactly the same error, but server-ids are unique
How to get out of this?
thanks,
Harsha
Additional info:
Master is 5.1.48 [server-id 1]
1st Slave is 5.1.50 [server-id 2] and
2nd slave is 5.1.48 [server-id 3]
Does anyone see incompatibility issue?
Note: 1. replication is happening but showing the error message that is confusing
I’ve created 2 extra slaves with the same server-id as the original slave, after some time, one of them caught up with the master and the other one started getting further behind, I noticed the I/O message in the logs.
Should I rebuild the slaves from scratch (200 GB of data) or can I just change the server-id and restart?
Hi,
I have exactly same issue, but my setup is Server with Server ID 1 and slave ID’s 2 and 3. (toatlly 3 boxes)
My Mysql versions on all 3 server are 5.1.54
Am not sure where it went wrong…. 🙁
Any help will be appreiciated!!
I have observed this is still a problem with MySQL 5.6 today. The problem and resolution are slightly different though. My server-id were properly set differently, but the server-uuid was the same, because this new slave was a clone. My resolution was to change the server-uuid
I had the same issue as Michael Wehrle. To change the server-uuid, I stopped MySQL, renamed the auto.cnf file in my data directory, and restarted MySQL. Basically like this:
/etc/init.d/mysql stop
cd /var/lib/mysql
mv auto.cnf auto.cnf.bk
/etc/init.d/mysql start
This is on MySQL 5.6.13 on CentOS 6.4.
It also resolved duplicate messages like this:
[Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the ‘START SLAVE Syntax’ in the MySQL Manual for more information.
Thanks Michael!
I was getting this error because two (out of four) slaves of the same master had same server_uuid value although server_id were unique for all of them.
It stopped when I changed the server_uuid of one of the slave.
In times of MySQL 5.6++, maybe you can receive that message also when the server-uuid from auto.cnf is the same in case you’ve just copied the DATADIR to start a new server, for example. Make you you always have unique server_id and unique server-uuid for each of the servers in a replication topology.
Excellent post, I was in trouble of this error and once I changed the duplicated server id on problematic mariadb server then the problem was solved.