Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-14988

innodb_read_only tries to modify files if transactions were recovered in COMMITTED state

    XMLWordPrintable

Details

    Description

      Because I had some doubts if my fix for MDEV-14985 needs something more, I wanted to test a scenario where InnoDB will recover a transaction in the COMMITTED state.
      It is a bit tricky to arrange this. Versions before 10.2 will require a DEBUG_SYNC point; below is the 5.5 version:

      diff --git a/storage/innobase/trx/trx0trx.c b/storage/innobase/trx/trx0trx.c
      index 151e70013f9..8f6f90bf36d 100644
      --- a/storage/innobase/trx/trx0trx.c
      +++ b/storage/innobase/trx/trx0trx.c
      @@ -43,6 +43,7 @@ Created 3/26/1996 Heikki Tuuri
       #include "trx0xa.h"
       #include "trx0purge.h"
       #include "ha_prototypes.h"
      +#include "my_sys.h" /* DEBUG_SYNC_C */
       
       /** Dummy session used currently in MySQL interface */
       UNIV_INTERN sess_t*		trx_dummy_sess = NULL;
      @@ -985,6 +986,7 @@ trx_commit_off_kernel(
       	if (lsn) {
       
       		mutex_exit(&kernel_mutex);
      +		DEBUG_SYNC_C("after_trx_committed_in_memory");
       
       		if (trx->insert_undo != NULL) {
       
      

      The test is a variation of innodb.read_only_recovery:

      --source include/have_innodb.inc
      --source include/have_debug.inc
      --source include/have_debug_sync.inc
      # need to restart server
      --source include/not_embedded.inc
       
      --connect(con1, localhost, root)
      CREATE TABLE t(a INT PRIMARY KEY) ENGINE=InnoDB;
      INSERT INTO t VALUES(1);
      BEGIN;
      # Generate insert_undo log.
      INSERT INTO t VALUES(2);
      # Generate update_undo log.
      DELETE FROM t WHERE a=2;
      --connect(con2, localhost, root)
      --echo # Normal MariaDB shutdown would roll back the above transaction.
      --echo # We want the transaction to remain open, so we will kill the server
      --echo # after ensuring that any non-transactional files are clean.
      FLUSH TABLES;
      --echo # Create another transaction that will be recovered as COMMITTED.
      BEGIN;
      # Generate multiple pages of both insert_undo and update_undo, so that
      # the state TRX_UNDO_CACHE will not be chosen.
      --disable_query_log
      let $n= 10000;
      while ($n) {
      dec $n;
      eval INSERT INTO t VALUES(-$n);
      eval DELETE FROM t WHERE a=-$n;
      }
      --enable_query_log
      SET DEBUG_SYNC='after_trx_committed_in_memory SIGNAL committed WAIT_FOR ever';
      send COMMIT;
       
      connection default;
      SET DEBUG_SYNC='now WAIT_FOR committed';
      --echo # Ensure that the above incomplete transactions become durable.
      SET GLOBAL innodb_flush_log_at_trx_commit=1;
      BEGIN;
      INSERT INTO t VALUES(-10000);
      ROLLBACK;
      --let $restart_parameters= --innodb-force-recovery=3
      --let $shutdown_timeout= 0
      --source include/restart_mysqld.inc
      --let $shutdown_timeout= 30
      --disconnect con1
      --disconnect con2
      SELECT * FROM t;
      SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
      SELECT * FROM t;
      UPDATE t SET a=3 WHERE a=1;
      --let $restart_parameters= --loose-innodb-read-only
      --source include/restart_mysqld.inc
      --echo # Starting with MariaDB 10.2, innodb_read_only implies READ UNCOMMITTED.
      --echo # In earlier versions, this would return the last committed version
      --echo # (empty table)!
      SELECT * FROM t;
      SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
      SELECT * FROM t;
      --let $restart_parameters=
      --source include/restart_mysqld.inc
      SELECT * FROM t;
      DROP TABLE t;
      

      In MariaDB 5.5, there is no --innodb-read-only option, and therefore the last-but-one restart can be omitted. MariaDB 5.5 could be unaffected by this bug.

      This will trigger at least the following assertion failures:

      180118 16:04:45 [Note] InnoDB: Starting shutdown...
      2018-01-18 16:04:46 7fe21c330700  InnoDB: Assertion failure in thread 140609112442624 in file lock0lock.cc line 7006
      InnoDB: Failing assertion: trx_state_eq(trx, TRX_STATE_ACTIVE)
      

      This one occurs on 10.0:

      2018-01-18 16:04:47 7f20f39c5080  InnoDB: Assertion failure in thread 139779502788736 in file mtr0mtr.cc line 322
      InnoDB: Failing assertion: !srv_read_only_mode
      #6  0x00007f20ec9ae658 in mtr_commit (mtr=0x7ffea6e73e38) at /mariadb/10.0/storage/innobase/mtr/mtr0mtr.cc:322
      #7  0x00007f20ecaed2e9 in trx_undo_seg_free (undo=0x33f7478) at /mariadb/10.0/storage/innobase/trx/trx0undo.cc:1251
      #8  0x00007f20ecaed0c4 in trx_undo_insert_cleanup (trx=0x3422ca8) at /mariadb/10.0/storage/innobase/trx/trx0undo.cc:1990
      #9  0x00007f20ecae464d in trx_cleanup_at_db_startup (trx=0x3422ca8) at /mariadb/10.0/storage/innobase/trx/trx0trx.cc:1426
      #10 0x00007f20ecad63d1 in trx_rollback_resurrected (trx=0x3422ca8, all=0x7ffea6e74408) at /mariadb/10.0/storage/innobase/trx/trx0roll.cc:679
      

      In 10.2, the assertion expression is different, but the idea is the same:

      2018-01-18 15:41:49 139918570912896 [Note] InnoDB: Cleaning up trx with id 0x507
      mysqld: /mariadb/10.2/storage/innobase/mtr/mtr0mtr.cc:570: void mtr_t::commit(): Assertion `!srv_read_only_mode || m_impl.m_log_mode == MTR_LOG_NO_REDO' failed.
      mtr/mtr0mtr.cc:572(mtr_t::commit())[0x1b4a8d6]
      trx/trx0undo.cc:1111(trx_undo_seg_free(trx_undo_t const*, bool))[0x1f3b877]
      trx/trx0undo.cc:1796(trx_undo_commit_cleanup(trx_undo_t*, bool))[0x1f3b018]
      trx/trx0trx.cc:2009(trx_cleanup_at_db_startup(trx_t*))[0x1f0cd1e]
      trx/trx0roll.cc:749(trx_rollback_resurrected(trx_t*, unsigned long*))[0x1ee5a85]
      

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              marko Marko Mäkelä
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.