Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6
Description
Note: I'm not sure whether the test is legit, as it's using a debug injection, but it's an existing one, so I assume it's made the way it is supposed to make sense. Anyway, it's worth checking.
--source include/have_innodb.inc
|
--source include/have_binlog_format_mixed.inc
|
--source include/master-slave.inc
|
|
|
CREATE TABLE t1 (a INT) ENGINE=InnoDB; |
INSERT INTO t1 VALUES (1); |
|
|
--connection master1
|
SET debug_dbug = '+d,fail_binlog_write_1'; |
--error ER_ERROR_ON_WRITE
|
UPDATE t1 SET a = 2; |
SET debug_dbug = ''; |
--error ER_BAD_TABLE_ERROR
|
DROP TEMPORARY TABLE t1; |
|
|
--connection master
|
CREATE TEMPORARY TABLE t1 (i INT) ENGINE=InnoDB; |
|
|
--sync_slave_with_master |
|
10.2 74f677fcc222f6 |
mysqld: /data/src/10.2/sql/log_event.cc:7593: virtual int Gtid_log_event::do_apply_event(rpl_group_info*): Assertion `(bits & (1ULL << 25)) == 0' failed.
|
170918 1:06:58 [ERROR] mysqld got signal 6 ;
|
|
|
#7 0x00007fb0d1662ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
|
#8 0x000056317e4c0ce3 in Gtid_log_event::do_apply_event (this=0x7fb06c01da20, rgi=0x7fb06c000a90) at /data/src/10.2/sql/log_event.cc:7593
|
#9 0x000056317e0876fd in Log_event::apply_event (this=0x7fb06c01da20, rgi=0x7fb06c000a90) at /data/src/10.2/sql/log_event.h:1452
|
#10 0x000056317e07c6a8 in apply_event_and_update_pos_apply (ev=0x7fb06c01da20, thd=0x7fb06c001550, rgi=0x7fb06c000a90, reason=0) at /data/src/10.2/sql/slave.cc:3571
|
#11 0x000056317e07cbdf in apply_event_and_update_pos (ev=0x7fb06c01da20, thd=0x7fb06c001550, rgi=0x7fb06c000a90) at /data/src/10.2/sql/slave.cc:3719
|
#12 0x000056317e07d3f5 in exec_relay_log_event (thd=0x7fb06c001550, rli=0x56318141a7b8, serial_rgi=0x7fb06c000a90) at /data/src/10.2/sql/slave.cc:4009
|
#13 0x000056317e080957 in handle_slave_sql (arg=0x563181418af0) at /data/src/10.2/sql/slave.cc:5148
|
#14 0x000056317e68c996 in pfs_spawn_thread (arg=0x7fb0700384f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
|
#15 0x00007fb0d35a7494 in start_thread (arg=0x7fb0c418b700) at pthread_create.c:333
|
#16 0x00007fb0d171f93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|
Attachments
Activity
./mtr rpl.rpl_bug26395 --view |
|
10.2 fb0b28932ce82903f2fc |
/10.2/sql/log_event.cc:7710: virtual int Gtid_log_event::do_apply_event(rpl_group_info*): Assertion `(bits & (1ULL << 25)) == 0' failed.
|
210715 14:15:30 [ERROR] mysqld got signal 6 ;
|
|
|
Server version: 10.2.40-MariaDB-debug-log
|
|
|
linux/raise.c:51(__GI_raise)[0x7f85fd5e87bb]
|
stdlib/abort.c:81(__GI_abort)[0x7f85fd5d3535]
|
intl/loadmsgcat.c:1177(_nl_load_domain)[0x7f85fd5d340f]
|
/lib/x86_64-linux-gnu/libc.so.6(+0x30102)[0x7f85fd5e1102]
|
sql/log_event.cc:7711(Gtid_log_event::do_apply_event(rpl_group_info*))[0x560cf2452fa8]
|
sql/log_event.h:1462(Log_event::apply_event(rpl_group_info*))[0x560cf190d01b]
|
sql/slave.cc:3469(apply_event_and_update_pos_apply(Log_event*, THD*, rpl_group_info*, int))[0x560cf18f0d70]
|
sql/slave.cc:3637(apply_event_and_update_pos(Log_event*, THD*, rpl_group_info*))[0x560cf18f1821]
|
sql/slave.cc:3936(exec_relay_log_event(THD*, Relay_log_info*, rpl_group_info*))[0x560cf18f2bcb]
|
sql/slave.cc:5087(handle_slave_sql)[0x560cf18fad1f]
|
perfschema/pfs.cc:1871(pfs_spawn_thread)[0x560cf332263c]
|
nptl/pthread_create.c:487(start_thread)[0x7f85fdd26fa3]
|
x86_64/clone.S:97(clone)[0x7f85fd6aa4cf]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x0): (null)
|
Connection ID (thread ID): 13
|
Status: NOT_KILLED
|
The problem occurs when the slave gets an incomplete event group (missing XID/COMMIT at the end) immediately followed by a new event group. If a master crash leaves an incomplete event group, a format description event is written just after by the restarted master, which will cause the slave to roll back the incomplete event group correctly.
But if somehow the slave receives the incomplete event group immediately followed by a new GTID, then the incomplete group is not rolled back or otherwise handled. This leads to the assertion, and in release build can cause the incomplete group to be committed with the wrong GTID.
Since this is somewhat difficult to trigger, I will avoid any risk in older GA releases and fix in 11.4
sujatha.sivakumar, forwarding it to you as a suspect of Incident related.