I have a MariaDB 10.3 Galera slave node with general logging turned on. It's consuming binlogs generated by a MySQL 5.5 NDB cluster. The binlog format is row-based in both databases.

SHOW ALL SLAVES STATUS; indicates that Read_Master_Log_Pos and Exec_Master_Log_Pos are caught up to the position on the master DB, Seconds_Behind_Master is 0, and no errors are logged.

Making an INSERT/UPDATE/DELETE on the master database immediately causes the following entries in the slave's general log:

190412 21:02:04     74 Query    BEGIN
                    74 Query    COMMIT

Additionally, the Read and Exec positions will tick upwards, Executed_log_entries will increase, and the relay binlog will get a new entry. Every metric and status indicator I know of suggests that the slave believes it's replicating, but the data doesn't replicate. DDL statements do replicate, however.

There are no filtering rules of any kind on the master/slave nodes. Replicate_Do_DB, Replicate_Ignore_DB, Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table, and Replicate_Wild_Ignore_Table are all empty.

Where do I even start troubleshooting this? What could cause the slave to silently fail to replicate?

  • 2
    SELECT @@log_slave_updates; -- should be 1 Apr 14, 2019 at 0:05
  • It is already enabled. Out of curiosity, isn't that only important for A) propagating the changes to other nodes on the Galera cluster, and B) propagating the changes to other slaves if you're setting up a multi-tiered master-slave relay? I.E., it wouldn't affect a single-node Galera cluster replicating as slave? Apr 15, 2019 at 15:45
  • 1
    Yes, that's consistent with my understanding, but since I had never tried running without it active, it was the only possible explanation I could think of. Apr 15, 2019 at 22:50


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.