Skip navigation links
13.5.5 Maria Usage Notes »
Section Navigation      [Toggle]

13.5.4. Maria Recovery

Any change (creation, insertion, deletion, update, etc.) in a Maria table using the transactional format is automatically written to the Maria log. Changes to non-transactional tables are not written to the log.

The basic operation of the recovery process is in two main stages:

  • Replay the contents of the log and update the data and index information.

  • Roll back any statements that had not completed, or where the transactions have not been committed.

More specifically, in the event of a crash or other failure of mysqld, the following takes place during the next invocation of mysqld:

  • Last checkpoint will be read from the log and the log will be replayed from the point calculated on the data contained within the checkpoint record. This point may be before the actual checkpoint.

  • If a checkpoint is not available (for example, if the log file was newly created and no checkpoint was written when the crash occurred), then all events are replayed from the start of the log file.

  • For each active connection, events are replayed until the last statement that completed before the crash occured, unless the statement was executed after a LOCK TABLES statement, in which case recovery takes place to the last statement executed before the LOCK TABLES statement was issued.

    Because multiple connections can be active at the same time, recovery takes place for each connection individually.

  • During recovery, if a statement fails due to a unique key violation, then the entire statement is not rolled back. Only the data that would have triggered the unique key violation is rolled back. For example, if you had executed the following statements into a table with a unique key: 

    INSERT VALUES (1);
INSERT VALUES (2),(1)

    The second statement would generate a unique key violation, but during recovery the statement would not be rolled back. The table would still contain two rows containing the first two values.

You can see a sample of the recovery process after a crash below: 

080111 16:42:05 mysqld_safe Number of processes running now: 0
080111 16:42:05 mysqld_safe mysqld restarted
080111 16:42:05 [Note] mysqld: Maria engine: starting recovery
recovered pages: 0% 99% 100% (0.9 seconds); transactions to roll back: 1 0 (3.8 seconds); tables to flush: 1 0 (0.5 seconds);
080111 16:42:10 [Note] mysqld: Maria engine: recovery done
080111 16:42:10 [Note] Event Scheduler: Loaded 0 events
080111 16:42:10 [Note] /usr/local/mysql/libexec/mysqld: ready for connections.

Recovery is automatic, but the length of time for recovery increases in line with the number of incomplete statements and tables known to be out of synchronization with the log. The recovery process is single-threaded and cannot be configured.