Not 5.7.x, 8.0.27-18 (Q4 2021)
The version used: 8.0.28
The error only occurs with configuration:
replica_parallel_workers = 0
If you execute a CTAS on the master and then stop replication on the replica while it is applying the event, MySQL crashes with the stack trace below:
2022-03-07T20:05:58.848277Z 6 [Note] [MY-010587] [Repl] Slave SQL thread for channel '' exiting, replication stopped in log 'mysql-bin.000005' at position 156 2022-03-07T20:06:26.451968Z 6 [ERROR] [MY-013183] [InnoDB] Assertion failure: dict0dict.cc:1878:table->get_ref_count() == 0 thread 139700593481472 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 20:06:26 UTC - mysqld got signal 6 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. Thread pointer: 0x7f0bb4000900 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 = 7f0e943fc078 thread_stack 0x100000 /opt/mysql/8.0.28/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x1f9ffde] /opt/mysql/8.0.28/bin/mysqld(print_fatal_signal(int)+0x2eb) [0x103628b] /opt/mysql/8.0.28/bin/mysqld(my_server_abort()+0x5e) [0x103638e] /opt/mysql/8.0.28/bin/mysqld(my_abort()+0xa) [0x1f9a3aa] /opt/mysql/8.0.28/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x30c) [0x225c4bc] /opt/mysql/8.0.28/bin/mysqld() [0x23404ef] /opt/mysql/8.0.28/bin/mysqld(Log_DDL::replay_remove_cache_log(unsigned long, char const*)+0x847) [0x2115577] /opt/mysql/8.0.28/bin/mysqld(Log_DDL::replay(DDL_Record&)+0x300) [0x2116a60] /opt/mysql/8.0.28/bin/mysqld(Log_DDL::replay_by_thread_id(unsigned long)+0x91) [0x2117201] /opt/mysql/8.0.28/bin/mysqld(Log_DDL::post_ddl(THD*)+0x2aa) [0x211756a] /opt/mysql/8.0.28/bin/mysqld() [0x206e0cb] /opt/mysql/8.0.28/bin/mysqld(Transactional_ddl_context::post_ddl()+0x26) [0xe69106] /opt/mysql/8.0.28/bin/mysqld(trans_rollback(THD*)+0xc2) [0x1000512] /opt/mysql/8.0.28/bin/mysqld(Relay_log_info::cleanup_context(THD*, bool)+0x220) [0x1c728a0] /opt/mysql/8.0.28/bin/mysqld(handle_slave_sql+0x1328) [0x1c988d8] /opt/mysql/8.0.28/bin/mysqld() [0x24d8fec] /lib64/libpthread.so.0(+0x7ea5) [0x7f0ed5d7fea5] /lib64/libc.so.6(clone+0x6d) [0x7f0ed40ef9fd]
How to reproduce this bug:
We can create a large table to make it easier to reproduce: CREATE TABLE `joinit` ( `i` int(11) NOT NULL AUTO_INCREMENT, `s` varchar(64) DEFAULT NULL, `t` time NOT NULL, `g` int(11) NOT NULL, PRIMARY KEY (`i`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; INSERT INTO joinit VALUES (NULL, uuid(), time(now()), (FLOOR( 1 + RAND( ) *60 ))); Execute this statement until the table is big enough for the test: INSERT INTO joinit SELECT NULL, uuid(), time(now()), (FLOOR( 1 + RAND( ) *60 )) FROM joinit; Create a table with the create table ... as statement. Ex: CREATE TABLE joinit_copy AS SELECT * FROM joinit;
A couple of seconds later after the replica is applying this create table, execute the "stop replica" command. Then after "create table" command was ended, run "start replica" and couple of seconds later "stop replica" again. Test can be non-deterministic if timing is not complied.
We found this bug report with a similar assertion, but it happened due to table corruption.
- mentioned in