We have a basic master/master replication setup for an InnoDB database between two apt-installed MySQL (5.0.51a-24+lenny5-log) running on Debian Lenny.
We have a simple client-side monitoring of the replication on both server. Basically it's just a script that logs in each 5 minutes with a user with replication slave privilegies only and does "show slave status\G". Then parses the values. For example "awk /Slave_IO_Running/{ print $2 }" for the Slave I/O Running status.
Yesterday, during one of these polls, Slave I/O Running returned "No". The next polling (and ever since) it has returned "Yes" as usual.
The weird thing here is that there is _nothing_ in the logs.
When we set up the replication two days ago, naturally the Slave I/O thread was offlined during one step. That caused the following loggings when exiting and reconnecting to the master:
syslog.2.gz:Feb 1 07:05:33 start mysqld[23658]: 120201 7:05:33 [Note] Slave I/O thread exiting, read up to log 'FIRST', position 4
syslog.2.gz:Feb 1 08:13:23 start mysqld[23658]: 120201 8:13:23 [Note] Slave I/O thread: connected to master 'replicator@xxx.xxx.xxx.xxx:3306', replication started in log 'mysql-bin.000001' at position 1964979
So, anyone have a clue why the "glitch" last night didn't show in the logs? Or why such a glitch can occur (everything else was OK at that time, and it obviously recovered by itself. Are there some known issues with this particular MySQL versions perhaps?
We have a simple client-side monitoring of the replication on both server. Basically it's just a script that logs in each 5 minutes with a user with replication slave privilegies only and does "show slave status\G". Then parses the values. For example "awk /Slave_IO_Running/{ print $2 }" for the Slave I/O Running status.
Yesterday, during one of these polls, Slave I/O Running returned "No". The next polling (and ever since) it has returned "Yes" as usual.
The weird thing here is that there is _nothing_ in the logs.
When we set up the replication two days ago, naturally the Slave I/O thread was offlined during one step. That caused the following loggings when exiting and reconnecting to the master:
syslog.2.gz:Feb 1 07:05:33 start mysqld[23658]: 120201 7:05:33 [Note] Slave I/O thread exiting, read up to log 'FIRST', position 4
syslog.2.gz:Feb 1 08:13:23 start mysqld[23658]: 120201 8:13:23 [Note] Slave I/O thread: connected to master 'replicator@xxx.xxx.xxx.xxx:3306', replication started in log 'mysql-bin.000001' at position 1964979
So, anyone have a clue why the "glitch" last night didn't show in the logs? Or why such a glitch can occur (everything else was OK at that time, and it obviously recovered by itself. Are there some known issues with this particular MySQL versions perhaps?