Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.1.13
-
Centos7, 64-bit
Description
As part of a migration we tried to set up replication from an existing MySQL NDB cluster (5.5.19-ndb-7.2.4-gpl-log - it's old...) to its replacement - a MariaDB 10.1.13 3-node galera cluster.
Pretty run-off-the-mill stuff: mysqldump with --master-data and set up replication.
The strange thing: Replication runs fine: IO slave and SQL slave are both happy. Replication log positions move forward. But no data gets updated - despite removing all replicate_do_xxx/replicate_ignore_xxx configuration on the slave.
Running mysqlbinlog -v --base64-output=DECODE-ROWS on the slave's relay logs reveals something strange: lots of reports of "### Row event for unknown table #34" (the actual table number varies). There are no trace of any "Table_map" events in the relay log!!
I flushed the logs on the master a few times to no avail: this did not change anything.
Using mysqlbinlog -v --base64-output=DECODE-ROWS on the binary logs on the master does show the "Table_map" events in the log - it is as if those events get filtered out by the slave IO thread!!??
I believe that this problem is somehow related to the fact that the master is an old MySQL NDB cluster node - I cannot reproduce it when replicating (to the same slave) from a MariaDB server.
Unfortunately, this makes the migration from MySQL NDB cluster to MariaDB Galera Cluster much more difficult than we expected