[MDEV-5767] Replication 5.6=>10.0 fails with binlog_rows_query_log_events=ON on master Created: 2014-02-28  Updated: 2015-10-09  Resolved: 2015-10-09

Status: Closed
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.0.8
Fix Version/s: 10.0.22, 10.1.8

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Fixed Votes: 2
Labels: None

Issue Links:
Blocks
blocks MDEV-5705 replication testing: 5.6->10.0 Stalled

 Description   

master:

MySQL [test]> set binlog_rows_query_log_events=ON;
Query OK, 0 rows affected (0.00 sec)
 
MySQL [test]> create table t1 (i int, c varchar(8));
Query OK, 0 rows affected (0.56 sec)
 
MySQL [test]> insert into t1 values (1,'a'),(2,'b');
Query OK, 2 rows affected (0.07 sec)
Records: 2  Duplicates: 0  Warnings: 0

Slave:

               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

It might be an unavoidable limitation, in which case it needs to be documented (as it is in MySQL docs for replicating to pre-5.6.2 slaves).



 Comments   
Comment by Michael Widenius [ 2015-10-09 ]

Fixed as part of MDEV-4487 (Allow MySQL 5.6 GTID replication in MariaDB 10.0)

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