Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.8
-
None
Description
I have a MariaDB 5.5 master and MySQL 5.5 slave. I updated MariaDB to 10.0.8 and replication failed on the slave with the following message:
Got fatal error 1236 from master when reading data from binary log: 'Failed to replace GTID event with backwards-compatible event: currupt event.; the first event 'mysql-bin.000558' at 312, the last event read from 'mysql-bin.000559' at 2590451, the last byte read from 'mysql-bin.000559' at 2590451.'
Is this expected to work?
Attachments
Activity
Tom,
Thanks for providing the logs.
The problem happens when the binlog event has a group-commit-ID, e.g.
#140227 11:37:59 server id 1 end_log_pos 2590451 GTID 0-1-3470 cid=11852
|
...
|
On a debug server, the master goes down with the assertion failure:
10.0/sql/log_event.cc:3731: static int Query_log_event::begin_event(String*, ulong, uint8): Assertion `data_len == 19 + 19' failed.
|
140227 18:47:40 [ERROR] mysqld got signal 6 ;
|
#6 0x00007fba769cb621 in *__GI___assert_fail (assertion=0xfd8085 "data_len == 19 + 19", file=<optimized out>, line=3731, function=0xfdb9a0 "static int Query_log_event::begin_event(String*, ulong, uint8)") at assert.c:81
|
#7 0x0000000000943332 in Query_log_event::begin_event (packet=0x7fba532346c8, ev_offset=1, checksum_alg=0 '\000') at 10.0/sql/log_event.cc:3731
|
#8 0x0000000000948f36 in Gtid_log_event::make_compatible_event (packet=0x7fba532346c8, need_dummy_event=0x7fba7885f4af, ev_offset=1, checksum_alg=0 '\000') at 10.0/sql/log_event.cc:6434
|
#9 0x000000000069e249 in send_event_to_slave (thd=0x7fba53234070, net=0x7fba53234328, packet=0x7fba532346c8, flags=0, event_type=GTID_EVENT, log_file_name=0x7fba7885fcd0 "./wheezy-64-bin.000002", log=0x7fba7885f930, mariadb_slave_capability=0, ev_offset=1, current_checksum_alg=0 '\000', using_gtid_state=false, gtid_state=0x7fba7885f650, gtid_skip_group=0x7fba7886043c, until_gtid_state=0x0, gtid_until_group=0x7fba78860438, until_binlog_state=0x7fba7885f810, slave_gtid_strict_mode=false, error_gtid=0x7fba78860440, send_fake_gtid_list=0x7fba78860437, fdev=0x7fba4b06c430) at 10.0/sql/sql_repl.cc:1778
|
#10 0x000000000069f835 in mysql_binlog_send (thd=0x7fba53234070, log_ident=0x7fba4b022088 "wheezy-64-bin.000002", pos=636, flags=0) at 10.0/sql/sql_repl.cc:2346
|
#11 0x000000000067030b in dispatch_command (command=COM_BINLOG_DUMP, thd=0x7fba53234070, packet=0x7fba5323a071 "", packet_length=30) at 10.0/sql/sql_parse.cc:1530
|
#12 0x000000000066eb9f in do_command (thd=0x7fba53234070) at 10.0/sql/sql_parse.cc:1005
|
#13 0x000000000078822d in do_handle_one_connection (thd_arg=0x7fba53234070) at 10.0/sql/sql_connect.cc:1379
|
#14 0x0000000000787f80 in handle_one_connection (arg=0x7fba53234070) at 10.0/sql/sql_connect.cc:1293
|
#15 0x0000000000a2c2bd in pfs_spawn_thread (arg=0x7fba52ff7b70) at 10.0/storage/perfschema/pfs.cc:1853
|
#16 0x00007fba7856fb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
|
We will check this particular failure and if we can reproduce it, quite possibly it will be fixed; but in general, replicating from a newer master to an older slave is not something you should rely on, especially if they are of different major versions. It is supported to some extent, but is never robust enough. The upgrade path is normally the other way round – you upgrade the slave first, then the master.
Could you please upload your mysql-bin.000558 and mysql-bin.000559 to our FTP at ftp.askmonty.org/private?