MySQL replication compatibility is broken in 5.5

[shinguz]

When we set-up Galera as a Slave to a normal MySQL Master the Galera node acting as a Slave does core dumps.

111031 21:13:35 [Note] Slave SQL thread initialized, starting replication in log 'bin-log.000002' at position 107, relay log './galera1-relay-bin.000002' position: 251
111031 21:15:25 [Warning] IP address '192.168.56.105' could not be resolved: Name or service not known
111031 21:15:29 - mysqld got signal 11 ;
Thread pointer: 0xd779040
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x49da50e8 thread_stack 0x40000
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(my_print_stacktrace+0x39)[0x7b9ea9]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(handle_segfault+0x43c)[0x4ff7fc]
/lib64/libpthread.so.0[0x347b20eb10]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(_ZN13MYSQL_BIN_LOG7log_xidEP3THDy+0x68)[0x721868]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(_Z15ha_commit_transP3THDb+0x470)[0x68d090]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(_Z17trans_commit_stmtP3THD+0x1d)[0x62c7ad]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x45c)[0x57d3ac]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0xfb)[0x581fab]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(_ZN15Query_log_event14do_apply_eventEPK14Relay_log_infoPKcj+0xb44)[0x72fb94]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(_Z26apply_event_and_update_posP9Log_eventP3THDP14Relay_log_info+0x125)[0x51ab45]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld[0x51fc4a]
/home/mysql/product/mysql-5.5.15-galera-1.0/sbin/mysqld(handle_slave_sql+0x986)[0x520e86]
/lib64/libpthread.so.0[0x347b20673d]
/lib64/libc.so.6(clone+0x6d)[0x347aad3f6d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0xd71a349): /*!40000 ALTER TABLE `test` DISABLE KEYS */
Connection ID (thread ID): 2
Status: NOT_KILLED

Then this node crashes continuously...

[Seppo Jaakola (seppo-jaakola)]

This issue happened when loading a mysql dump file on the MySQL master node

Two issues were detected when debugging this:
A). non-effective DDL causes a crash in Galera slave. In this test the:
   ALTER TABLE `test` DISABLE KEYS, was the offending query

B). if log-slave-updates has not been set on Galera slave node, all replicated MySQL transactions are skipped

Howto reproduce case A:

1. setup two Galera nodes but with Galera replication disabled. Instead configure MySQL replication between this pair
2. issue in the master node:
   mysql> CREATE TABLE test.t(i int);
   mysql> ALTER TABLE test.t DISABLE KEYS;
3. Slave node should crash while applying

Howto reproduce case B:

1. use same node pair as in case A
2. in slave configuration make sure log_bin and log_slave_updates are not set
3. issue in the master node:
   mysql> CREATE TABLE test.t(i int);
   mysql> INSERT INTO t values (1);;
4. check out test.t in slave node, it will be empty

[Seppo Jaakola (seppo-jaakola)]

Fix was committed in change set: http://bazaar.launchpad.net/~codership/codership-mysql/wsrep-5.5/revision/3602