Statistics: Row-based replication aborts on some DDL statements if statistics is enabled


While ANALYZE TABLE doesn't cause row binlog events on mysql.*stat tables anymore, some other statements still do; it can cause replication failure even in the best setup, when both master and slave have the same value of use_stat_tables; and even more so if the variable is set on the session level.

Test case 1

Here both master and slave have the same use_stat_tables; but it doesn't help, because DROP TABLE is written into the binlog first, and then row events on mysql.*stat tables:

So, slave SQL thread fails with

Test case 2

In this slightly different scenario, if we enable statistics globally for both master and slave, replication works all right, apparently because statement and row events are written in the reverse order comparing to Test case 1; but if use_stat_tables is enabled on master on the session level, it again causes replication abort, since slave didn't get the memo and didn't write anything to the stat tables, so it has nothing to remove:

Slave SQL thread aborts with

Test case 3

Here is yet another case which I noticed to write row events on stat tables into the binary log; I'm adding it in case this problem requires case-by-case approach (there might be more, though):

bzr version-info:




Igor Babaev


Elena Stepanova



Fix versions