Ускорение группового подтверждения и сброса InnoDB в бинарном журнале

MariaDB 10.0 внедрила улучшение производительности, связанное с групповым подтверждением, которое влияет на производительность сброса транзакций InnoDB при включённом бинарном журнале.

Обзор

В MariaDB 10.0 и выше, когда установлено значение innodb_flush_log_at_trx_commit=1 (значение по умолчанию) и включён бинарный журнал, теперь внутри InnoDB во время подтверждения выполняется на одну синхронизацию с диском меньше (2 синхронизации на группу транзакций вместо 3).

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

Переключение на старое поведение сброса

Старое поведение, с 3 синхронизациями с диском на каждое (групповое) подтверждение (и, как следствие, более низкой производительностью), может быть выбрано с помощью нового параметра innodb_flush_log_at_trx_commit=3. Обычно это не приносит пользы, однако существуют несколько особых случаев, о которых следует знать.

Параметры бинарного журнала без гарантии сохранности

Если innodb_flush_log_at_trx_commit=1 установлено, а бинарный журнал включён, но sync_binlog=0, то подтверждения не гарантируют сохранность внутри InnoDB после подтверждения. Это связано с тем, что если sync_binlog=0 и сервер аварийно завершит работу, то транзакции, которые не были сброшены в бинарный журнал до аварии, будут отсутствовать в бинарном журнале.

В этой конкретной ситуации, innodb_flush_log_at_trx_commit=3 можно установить для обеспечения сохранности транзакций в InnoDB, даже если они не обязательно сохранены с точки зрения бинарного журнала.

Следует помнить, что если sync_binlog=0, то авария всё равно может привести к отсутствию транзакций в бинарном журнале. Это приведёт к несогласованности бинарного журнала и InnoDB. Это также, вероятно, приведёт к несогласованности любых ведомых репликации, так как транзакции реплицируются через бинарный журнал. Поэтому рекомендуется установить sync_binlog=1. Благодаря улучшениям группового подтверждения, внедрённым в MariaDB 5.3, эта настройка имеет значительно меньше штрафов в современных версиях по сравнению со старыми версиями MariaDB и MySQL.

Отсутствующие последние транзакции в резервных копиях

Mariabackup и Percona XtraBackup видят только те транзакции, которые были сброшены в журнал переигрывания. С улучшениями группового подтверждения может быть небольшая задержка (определяемая переменной системы binlog_commit_wait_usec) между моментом подтверждения и включением подтверждения в резервную копию.

Обратите внимание, что резервная копия всё ещё будет полностью согласованной с собой и бинарным журналом. Эта проблема обычно не является проблемой на практике. Резервное копирование обычно занимает много времени (по сравнению с 1 секундой или около того, для которой обычно устанавливается binlog_commit_wait_usec), и резервная копия обычно включает много транзакций, которые были подтверждены во время резервного копирования. Учитывая это, если резервная копия не включает транзакции, подтверждённые в течение последних 1 секунды или около того процесса резервного копирования, это обычно незаметно. Это просто упомянуто для полноты.