Обзор журнала координатора транзакций

Журнал координатора транзакций (tc_log) используется для координации транзакций, которые влияют на несколько XA-совместимых движков хранения. Если у вас включено два или более XA-совместимых движков хранения, то должен быть доступен журнал координатора транзакций.

Типы журналов координатора транзакций

В настоящее время существует две реализации журнала координатора транзакций:

• Журнал координатора транзакций, основанный на двоичном журнале
• Журнал координатора транзакций, основанный на файле с сопоставлением памяти

Если двоичный журнал включён на сервере, то сервер будет использовать журнал координатора транзакций, основанный на двоичном журнале. В противном случае он будет использовать журнал координатора транзакций, основанный на файле с сопоставлением памяти.

Журнал координатора транзакций, основанный на двоичном журнале

Этот координатор транзакций использует двоичный журнал, который активируется опцией сервера log_bin.

Журнал координатора транзакций, основанный на файле с сопоставлением памяти

Этот координатор транзакций использует файл с сопоставлением памяти, определённый опцией сервера --log-tc. Размер определяется системной переменной log_tc_size.

Некоторые факты о данном журнале:

• Журнал состоит из файла с сопоставлением памяти, который разделён на страницы размером 8 КБ.
• Используемый размер первой страницы меньше из-за заголовка журнала. Для каждой страницы существует структура управления страницей PAGE.
• Каждая страница (или, точнее, её структура управления PAGE) может находиться в одном из трёх состояний: активная, синхронизирующаяся, пул.
• Может быть только одна страница в активном или синхронизирующемся состоянии, но много в состоянии пула — пул это очередь FIFO.
• Обычный жизненный цикл страницы — пул->активная->синхронизирующаяся->пул.
• «Активная» страница — страница, где регистрируются новые xid.
• Страница остаётся активной до тех пор, пока занята синхронизирующая ячейка.
• «Синхронизирующаяся» страница синхронизируется с диском. Новые xid не могут быть добавлены к ней.
• После завершения синхронизации страница перемещается в пул, а активная страница становится «синхронизирующейся».

Результатом такой архитектуры является естественное «группирование подтверждений» — если подтверждения поступают быстрее, чем система может их синхронизировать, они не останавливаются. Вместо этого все подтверждения, поступившие с момента последней синхронизации, записываются в ту же «активную» страницу, и все они синхронизируются с следующей синхронизацией. Таким образом, хотя отдельные подтверждения могут быть задержки, пропускная способность не уменьшается.

Когда xid добавляется на активную страницу, поток этого xid ожидает условия страницы, пока страница не будет синхронизирована. Когда свободной становится синхронизирующая ячейка, один из этих ожидающих потоков пробуждается, чтобы заняться синхронизацией. Он синхронизирует страницу и сигнализирует всем ожидающим потокам о том, что страница синхронизирована. Ожидающие потоки подсчитываются, и страница может никогда не стать активной снова до тех пор, пока waiters==0, что означает, что все ожидающие потоки с предыдущей синхронизации заметили, что синхронизация завершилась.

Обратите внимание, что страница становится «грязной» и должна быть синхронизирована только тогда, когда в неё добавляется новый xid. Удаление xid из страницы не делает её грязной — мы не синхронизируем удаления xid на диск.

Мониторинг журнала координатора транзакций, основанного на файле с сопоставлением памяти

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

• Tc_log_max_pages_used
• Tc_log_page_size
• Tc_log_page_waits

Эвристическое восстановление с помощью журнала координатора транзакций

Одна из основных целей журнала координатора транзакций — восстановление после сбоя. Подробнее об этом см. в разделе Эвристическое восстановление с помощью журнала координатора транзакций.

Известные проблемы

Необходимо включить ровно N движков хранения

До версии MariaDB 10.1.10, если вы использовали журнал координатора транзакций, основанный на файле с сопоставлением памяти, и сервер упал, а вы изменили количество загруженных XA-совместимых движков хранения, вы могли столкнуться с ошибками такого типа:

2018-11-30 23:08:49 140046048638848 [Note] Recovering after a crash using tc.log          
2018-11-30 23:08:49 140046048638848 [ERROR] Recovery failed! You must enable exactly 3 storage engines that support two-phase commit protocol
2018-11-30 23:08:49 140046048638848 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}
2018-11-30 23:08:49 140046048638848 [ERROR] Can't init tc log
2018-11-30 23:08:49 140046048638848 [ERROR] Aborting

Чтобы восстановиться от этой ошибки, удалите файл, определённый опцией сервера --log-tc, и перезапустите сервер с установленной опцией --tc-heuristic-recover.

См. MDEV-9214 для получения дополнительной информации.

Неверный магический заголовок в журнале tc

Если вы используете журнал координатора транзакций, основанный на файле с сопоставлением памяти, могут появиться ошибки такого типа:

2018-09-19  4:29:31 0 [Note] Recovering after a crash using tc.log                                                               
2018-09-19  4:29:31 0 [ERROR] Bad magic header in tc log
2018-09-19  4:29:31 0 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}                                           
2018-09-19  4:29:31 0 [ERROR] Can't init tc log
2018-09-19  4:29:31 0 [ERROR] Aborting

Это означает, что заголовок файла с сопоставлением памяти журнала координатора транзакций повреждён. Чтобы восстановиться от этой ошибки, удалите файл, определённый опцией сервера --log-tc, и перезапустите сервер с установленной опцией --tc-heuristic-recover.

Известно, что эта проблема возникает при использовании Docker. В этом случае проблема может быть вызвана использованием контейнера MariaDB с каталогом данных из другой версии MariaDB или MySQL. Поэтому некоторые потенциальные решения:

• Фиксация контейнера Docker на конкретную версию MariaDB в файле docker-compose, чтобы он всегда использовал одну и ту же версию.
• Выполнение команды mariadb-upgrade для обеспечения того, что каталог данных обновлён в соответствии с версией сервера.

См. эту проблему Docker для получения дополнительной информации.

Кластер MariaDB Galera

MariaDB Galera Cluster включает встроенный плагин wsrep. До версии MariaDB 10.4.3 этот плагин внутренне считался XA-совместимым движком хранения. В результате эти сборки MariaDB Galera Cluster по умолчанию имеют несколько XA-совместимых движков хранения, даже если единственный «реальный» движок хранения, поддерживающий внешние XA-транзакции, включён в эти сборки по умолчанию, это InnoDB. Поэтому при использовании этих сборок MariaDB будет вынуждена по умолчанию использовать журнал координатора транзакций, что может повлиять на производительность.

Например, MDEV-16509 описывает проблемы с производительностью, где MariaDB Galera Cluster фактически работает лучше, когда двоичный журнал включен. Возможно, это связано с тем, что в этом случае MariaDB вынуждена использовать журнал координатора транзакций, основанный на файле с сопоставлением памяти, что может не работать так хорошо.

Эта проблема стала более значительной в MariaDB 10.1, когда патч MySQL-wsrep, который питает MariaDB Galera Cluster, был включён по умолчанию в большинстве сборок MariaDB на Linux. В результате этот встроенный плагин wsrep существовал по умолчанию в этих сборках MariaDB на Linux. Следовательно, пользователи MariaDB могут столкнуться с потерями производительности, даже если они никогда не планировали использовать возможности MariaDB Galera Cluster, включённые в MariaDB 10.1.

В MariaDB 10.4.3 и более поздних версиях встроенный плагин wsrep был изменён на плагин репликации. Следовательно, он больше не считается XA-совместимым движком хранения, поэтому он больше не принуждает MariaDB по умолчанию использовать журнал координатора транзакций.

См. MDEV-16442 для получения дополнительной информации.