Uploaded image for project: 'Percona Server for MySQL'
  1. Percona Server for MySQL
  2. PS-8106

MySQL crashes if you stop replication while it is replicating a CTAS.



      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`)
      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.


        Issue Links



              amonar Anton Matvienko
              roberto.garciadebem Roberto Garcia de Bem
              1 Vote for this issue
              6 Start watching this issue



                Smart Checklist