Улучшения для START TRANSACTION WITH CONSISTENT SNAPSHOT

С введением групповой фиксации, MariaDB также представила усовершенствованный API движка хранилища для COMMIT, который позволяет движкам координировать порядок фиксации и видимость друг с другом и с журналами транзакций.

С этими улучшениями оператор START TRANSACTION WITH CONSISTENT SNAPSHOT был усовершенствован для обеспечения согласованности между движками хранилища, которые поддерживают новый API. На момент написания поддерживающими движками являются XtraDB и PBXT. Кроме того, журнал транзакций, хотя и не является движком хранилища как таковым, также поддерживает новый API и может предоставлять позицию binlog, согласованную со снимками транзакций движков хранилища.

Это означает, что с уровнем изоляции транзакций как минимум REPEATABLE READ, оператор START TRANSACTION WITH CONSISTENT SNAPSHOT может быть использован для обеспечения того, что запросы будут видеть согласованный с транзакцией вид базы данных также между движками хранилища. Тогда запрос не сможет увидеть изменения от какой-либо транзакции T в таблицах XtraDB без одновременного просмотра изменений, которые T вносит в таблицы PBXT. (В пределах одного транзакционного движка хранилища, такого как XtraDB или PBXT, согласованность всегда гарантируется даже без использования START TRANSACTION WITH CONSISTENT SNAPSHOT).

Например, предположим, что следующие две транзакции выполняются параллельно:

Транзакция T1:

    BEGIN;
    SET @t = NOW();
    UPDATE xtradb_table SET a= @t WHERE id = 5;
    UPDATE pbxt_table SET b= @t WHERE id = 5;
    COMMIT;

Транзакция T2:

    SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
    START TRANSACTION WITH CONSISTENT SNAPSHOT;
    SELECT t1.a, t2.b
      FROM xtradb_table t1 INNER JOIN pbxt_table t2 ON t1.id=t2.id
     WHERE t1.id = 5;

Тогда транзакция T2 всегда будет видеть одно и то же значение для xtradb_table.a и pbxt_table.b.

(В MariaDB 5.2 и более ранних версиях, а также MySQL как минимум до версии 5.5, START TRANSACTION WITH CONSISTENT SNAPSHOT не давало никаких гарантий согласованности между различными движками хранилища. Поэтому возможно, даже со «согласованным» снимком, увидеть изменения в транзакции только для таблиц InnoDB/XtraDB, а не для таблиц PBXT, например.)

Переменные состояния

Другое применение этих улучшений заключается в получении позиции журнала транзакций, согласованной с конкретным транзакционным состоянием движка(ов) хранилища в базе данных. Это делается с помощью двух переменных состояния для журнала транзакций: binlog_snapshot_file и binlog_snapshot_position

Эти переменные предоставляют имя файла журнала транзакций и позицию, как и SHOW MASTER STATUS. Но они могут быть запрошены согласованным образом с транзакциями. После начала транзакции с помощью START TRANSACTION WITH CONSISTENT SNAPSHOT, две переменные будут предоставлять позицию в журнале транзакций, соответствующую состоянию базы данных взятого согласованного снимка, независимо от того, какие другие транзакции были зафиксированы после того, как был сделан снимок (SHOW MASTER STATUS всегда показывает позицию последней зафиксированной транзакции). Это работает для движков хранилища MVCC, которые реализуют часть API движка хранилища, связанную с порядком фиксации, что на момент написания является XtraDB и PBXT.

Это полезно для получения логического дампа/бэкапа с соответствующей позицией журнала транзакций, которая может быть использована для предоставления нового репликанта с исходным сервером в качестве мастера. Сначала выполняется START TRANSACTION WITH CONSISTENT SNAPSHOT. Затем согласованное состояние базы данных получается с помощью запросов, и соответствующая позиция в журнале транзакций получается с помощью SHOW STATUS LIKE 'binlog_snapshot%'. Когда это загружается на новый сервер-репликант, позиция журнала транзакций используется в операторе CHANGE MASTER TO, чтобы установить репликацию репликанта с правильной позиции.

С переменными binlog_snapshot_file и binlog_snapshot_position такое предоставление может быть выполнено полностью без блокировок на сервере-мастере. Без них необходимо получить позицию журнала транзакций в FLUSH TABLES WITH READ LOCK; это может потенциально заблокировать сервер на длительное время, так как это блокирует новые запросы до тех пор, пока все уже начатые обновления не завершатся.

mariadb-dump

Программа mariadb-dump была расширена для использования этих переменных состояния. Это означает, что резервную копию, подходящую для предоставления репликанта, можно получить как обычно, так:

    mariadb-dump --single-transaction --master-data ...

Дамп будет полностью без блокировок, если как программа mariadb-dump, так и сервер, с которым производится запрос, включают необходимую функцию (например, если оба являются от MariaDB 5.2-rpl, 5.3 или более поздних версий). В других случаях это будет переключено на старый блокирующий метод, использующий FLUSH TABLES WITH READ LOCK.

Для получения дополнительной информации о проектировании и реализации этой функции см. MWL#136.

См. также

• START TRANSACTION
• Что такое MariaDB 5.3
• MyRocks и START TRANSACTION WITH CONSISTENT SNAPSHOT