Групповая фиксация для бинарного лога

Обзор

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

Долговечность

В терминологии ACID «Д» означает долговечность. Для обеспечения долговечности с групповой фиксацией следует установить innodb_flush_log_at_trx_commit=1 и/или sync_binlog=1. Эти настройки необходимы для обеспечения того, что в случае сбоя сервера все транзакции, которые были завершены до момента сбоя, по-прежнему будут присутствовать в базе данных после восстановления.

Долговечные данные InnoDB и бинарные лог

Установление как innodb_flush_log_at_trx_commit=1, так и sync_binlog=1 обеспечивает максимальную долговечность и наилучшую гарантию согласованности репликации после сбоя.

Недолговечные данные InnoDB

Если sync_binlog=1 установлено, но innodb_flush_log_at_trx_commit не установлено в 1 или 3, то после сбоя может возникнуть состояние, когда транзакция, присутствующая в бинарном логе сервера binary log, отсутствует в журнале резервного копирования сервера InnoDB InnoDB redo log. Если сервер является мастером репликации, это означает, что сервер может стать несовместимым со своими подчиненными, так как подчиненные могут иметь реплицированные транзакции из бинарного лога мастера binary log, которые больше не присутствуют в локальных данных мастера InnoDB.

Недолговечные бинарные лог

Если innodb_flush_log_at_trx_commit установлено в 1 или 3, но sync_binlog=1 не установлено, то после сбоя может возникнуть состояние, когда транзакция, присутствующая в журнале резервного копирования сервера InnoDB InnoDB redo log, отсутствует в бинарном логе сервера binary log. Если сервер является мастером репликации, это также означает, что сервер может стать несовместимым со своими подчиненными, так как подчиненные не смогут реплицировать отсутствующие транзакции из бинарного лога сервера binary log.

Недолговечные данные InnoDB и бинарные лог

Установка innodb_flush_log_at_trx_commit=1, когда sync_binlog=1 не установлено, также может привести к отсутствию транзакции в журнале резервного копирования сервера InnoDB InnoDB redo log из-за некоторых оптимизаций, добавленных в этих версиях. В этом случае рекомендуется всегда устанавливать sync_binlog=1. Если это невозможно, рекомендуется установить innodb_flush_log_at_trx_commit в значение 3, а не в 1. Дополнительная информация доступна в разделе Настройки Недолговечного Бинарного Лога.

Амортизация затрат на сброс в буфер диска

После каждой транзакции COMMIT сервер обычно должен сбросить все изменения, внесенные транзакцией, в журнал резервного копирования InnoDB InnoDB redo log и бинарный лог binary log на диск (т.е. вызывая системные вызовы, такие как fsync() или fdatasync() или аналогичные). Это помогает гарантировать, что изменения данных, внесенные транзакцией, надежно сохранены на диске. Сброс в буфер диска является ресурсоемкой операцией и может легко ограничить пропускную способность по количеству транзакций в секунду (TPS), которые могут быть завершены.

Идея групповой фиксации заключается в амортизации затрат на каждый сброс в буфер диска на множество фиксаций от нескольких параллельных транзакций. Например, если 10 транзакций пытаются завершиться параллельно, мы можем принудительно сбросить все их на диск одновременно с помощью одного системного вызова, а не делать один системный вызов для каждой фиксации. Это может значительно уменьшить потребность в операциях сброса и, следовательно, значительно повысить пропускную способность транзакций в секунду (TPS).

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

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

Изменение частоты групповой фиксации

Частоту групповой фиксации можно изменить, настроив системные переменные binlog_commit_wait_usec и binlog_commit_wait_count.

Измерение коэффициента групповой фиксации

Для проверки эффективности групповой фиксации в сокращении накладных расходов на сброс в буфер доступны две переменные состояния. Это переменные состояния Binlog_commits и Binlog_group_commits. Эти значения можно получить с помощью следующего запроса:

SHOW GLOBAL STATUS WHERE Variable_name IN('Binlog_commits', 'Binlog_group_commits');

Binlog_commits — общее количество транзакций, зафиксированных в бинарном логе binary log.

Binlog_group_commits — общее количество групп, зафиксированных в бинарном логе binary log. Как объяснялось в предыдущих разделах этой страницы, групповая фиксация — это когда группа транзакций сбрасывается в бинарный лог binary log вместе, используя один вызов сброса. Когда установлено sync_binlog=1, это также общее количество вызовов системного сброса, выполненных при сбросе фиксаций в бинарный лог binary log.

Таким образом, степень эффективности групповой фиксации в сокращении числа вызовов сброса в буфер для бинарного лога может быть определена по отношению между этими двумя переменными состояния. Binlog_commits всегда будет равно или больше Binlog_group_commits. Чем больше разница между этими переменными состояния, тем эффективнее групповая фиксация сокращала накладные расходы на сброс в буфер.

Для расчета коэффициента групповой фиксации нам нужны значения этих переменных состояния из двух снимков. Затем мы можем рассчитать коэффициент по следующей формуле:

transactions/group commit = (Binlog_commits (снимок2) - Binlog_commits (снимок1))/(Binlog_group_commits (снимок2) - Binlog_group_commits (снимок1))

Например, если у нас был первый снимок:

SHOW GLOBAL STATUS WHERE Variable_name IN('Binlog_commits', 'Binlog_group_commits');
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Binlog_commits       | 120   |
| Binlog_group_commits | 120   |
+----------------------+-------+
2 rows in set (0.00 sec)

И следующий второй снимок:

SHOW GLOBAL STATUS WHERE Variable_name IN('Binlog_commits', 'Binlog_group_commits');
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Binlog_commits       | 220   |
| Binlog_group_commits | 145   |
+----------------------+-------+
2 rows in set (0.00 sec)

Тогда у нас будет:

transactions/group commit = (220 - 120) / (145 - 120) = 100 / 25 = 4 transactions/group commit

Если ваш коэффициент групповой фиксации слишком близок к 1, это может помочь изменить частоту вашей групповой фиксации.

Использование групповой фиксации с параллельной репликацией

Групповая фиксация также используется для включения консервативного режима упорядоченной параллельной репликации.

Влияние групповой фиксации на производительность InnoDB

Когда установлено как innodb_flush_log_at_trx_commit=1 (значение по умолчанию) и включен бинарный лог binary log, теперь внутри InnoDB во время фиксации происходит на одну операцию синхронизации с диском меньше (2 синхронизации совместно используются группой транзакций вместо 3). Дополнительная информация доступна в разделе Бинарный лог. Групповая фиксация и производительность сброса InnoDB.

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

Binlog_commits — общее количество транзакций, зафиксированных в бинарном логе binary log.

Binlog_group_commits — общее количество групп, зафиксированных в бинарном логе binary log.

Binlog_group_commit_trigger_count — общее количество групповых фиксаций, инициированных из-за достижения лимита, установленного системной переменной binlog_commit_wait_count, количества фиксаций в бинарном логе binary log в группе.

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

Binlog_group_commit_trigger_timeout — общее количество групповых коммитов, инициированных из-за истечения времени ожидания с момента, когда первый коммит бинарного лога достиг предела, заданного системной переменной binlog_commit_wait_usec.

Для запроса этих переменных используйте оператор, подобный:

SHOW GLOBAL STATUS LIKE 'Binlog_%commit%';

См. также

• Параллельная репликация
• Производительность группового коммита бинарного лога и сброса InnoDB
• Бенчмарк группового коммита