[MDEV-9845] Replication from MySQL 5.5.19-ndb to MariaDB Galera Cluster 10.1.13 fails silently Created: 2016-03-31  Updated: 2018-07-18

Status: Open
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.1.13
Fix Version/s: 10.1

Type: Bug Priority: Major
Reporter: Karl E. Jørgensen Assignee: Seppo Jaakola
Resolution: Unresolved Votes: 0
Labels: galera, replication
Environment:

Centos7, 64-bit


Attachments: Text File log-oldcluster.000047.txt     Text File lon3sqlnodedb03-bin.433773.txt    

 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



 Comments   
Comment by Karl E. Jørgensen [ 2016-03-31 ]

A couple of observations that may be relevant:

  • The mysqlbinlog binary in MariaDB 10.1.13 can read the master's binary log OK. And it reports the same Table_map events as the mysqlbinlog binary from MySQL NDB Cluster.
  • I ran FLUSH LOCAL LOGS on the master twice (about 15 seconds apart) to produce a small binlog example (lon3sqlnodedb03-bin.433773.txt has the first 1000 lines) and compared with the corresponding relay log (log-oldcluster.000047.txt has the first 1000 lines) on the slave. And there are some oddities:
    • The relay log appears to start with two extra events with a timestamp which is 22 hours in the past!? (I recall that the underlying representation of timestamps has changed over time, which could possibly affect this?)
    • The relay log does NOT contain the two Table_map events I see in the master's binary log
Comment by Karl E. Jørgensen [ 2016-04-07 ]

I can replicate this problem too when replicating from MySQL 5.5.19-ndb-7.2.4-gpl-log to MariaDB Galera Cluster 10.0.23. Exactly same symptoms.

Generated at Thu Feb 08 07:37:45 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.