5.6.12rc error 1756 (slave coordinator) replication

[enajohnson]

Running Percona 5.6.12rc and got the following error message on a slave (it has log slave updates enabled if that makes any difference)

“The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details).”

Stopped mysql, restarted mysql and restarted the slave threads and everything seems fine, still need to do a full audit to make sure.

I found this bug report:

http://bugs.mysql.com/bug.php?id=69369

Another slave off of the same master did not have the same problem, the primary difference, as mentioned above, is that the other slave is not logging updates.

Anyone else experienced this problem?

• Aaron

[enajohnson]

This happened again and I noticed the warning when I restarted the slave:

Code 1753 “slave_transaction_retries is not supported in multi-threaded slave mode. In the event of a transient failure, the slave will not retry the transaction and will stop.”

This makes it clearer as to why the slave stops, but not entirely sure why it is only happening on some of the slaves and not all of them.

• Aaron

[mirfan]

Hi,
Can you please post my.cnf from master, from problematic slave and one from other slave which is working ok.
Did this problem occurring when slave is rotating it’s binlog ?

[arubin]

Looks like this is a bug, mentioned here: http://bugs.mysql.com/bug.php?id=69369
It is seems to be fixed in MySQL 5.6.13 (not yet released).
Regarding “why it is only happening on some of the slaves and not all of them” - could you check if the my.cnf on 2 slaves are different? May be there are some options are set differently.

[enajohnson]

Here is the diff between show variables on the two boxes:

< = with problem

= without problem

< log_slave_updates ON

log_slave_updates OFF

< thread_pool_size 16

thread_pool_size 24

There is no correlation between log rotation, or more precisely, log rotation has occurred more time than this problem and the time stamps on the bin files don’t match when the issue is occurring.

The issue has occurred roughly 6 times, bin log has rotated approx 190 times.

My current workaround is a script that watches for the condition every minute and restarts the slave if it occurs.