Потоки репликации

Реализация репликации в MariaDB требует нескольких типов потоков.

Потоки на примарном узле

Примарный узел обычно имеет только один тип потоков, связанных с репликацией: поток выгрузки двоичного лога.

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

Поток выгрузки двоичного лога

Поток выгрузки двоичного лога работает на примарном узле и выгружает двоичный лог на реплику. Этот поток можно определить, выполнив оператор SHOW PROCESSLIST и найдя поток, где команда потока — "Binlog Dump".

Примарный узел создаёт отдельный поток выгрузки двоичного лога для каждой реплики, подключённой к нему. Вы можете определить, какие реплики подключены к примарному узлу, выполнив оператор SHOW SLAVE HOSTS.

Потоки выгрузки двоичного лога и процесс остановки

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

В MariaDB 10.4 и более поздних версиях эту проблему можно решить, остановив сервер с помощью утилиты mariadb-admin или команды SHUTDOWN и предоставления специального параметра.

Например, эту проблему можно решить, остановив сервер с помощью утилиты mariadb-admin и указанием параметра --wait-for-all-slaves для утилиты, а также выполнив команду shutdown с помощью утилиты:

mariadb-admin --wait-for-all-slaves shutdown

Или эту проблему можно решить, остановив сервер с помощью команды SHUTDOWN и указанием параметра WAIT FOR ALL SLAVES для команды:

SHUTDOWN WAIT FOR ALL SLAVES;

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

В MariaDB 10.4 и более поздних версиях всё ещё невозможно включить это поведение по умолчанию. Это означает, что это поведение в настоящее время недоступно при остановке сервера с помощью таких инструментов, как systemd или sysVinit.

В MariaDB 10.3 и более ранних версиях рекомендуется вручную переключать реплики на новый примарный узел перед остановкой старого примарного узла.

Поток приёма подтверждений

Когда полусинхронная репликация включена, полусинхронные реплики отправляют подтверждения (ACK) своему примарному узлу, чтобы подтвердить, что они получили некоторые транзакции. Примарный узел создаёт поток приёма подтверждений для получения этих подтверждений.

Потоки на реплике

Реплика имеет три типа потоков, связанных с репликацией: поток ввода/вывода реплики, поток SQL реплики и рабочие потоки, которые применяются только при использовании параллельной репликации.

При использовании репликации с несколькими источниками, каждое независимое подключение к репликации имеет свои собственные потоки реплики каждого типа.

Поток ввода/вывода реплики

Поток ввода/вывода реплики получает события двоичного лога от примарного узла и записывает их в свой relay лог.

Позиция двоичного лога

Позицию двоичного лога потока ввода/вывода реплики можно проверить, выполнив оператор SHOW SLAVE STATUS. Она будет показана в столбцах Master_Log_File и Read_Master_Log_Pos.

Позицию двоичного лога потока ввода/вывода реплики можно установить, задав параметры MASTER_LOG_FILE и MASTER_LOG_POS с помощью оператора CHANGE MASTER.

Позиция двоичного лога потока ввода/вывода реплики и значения большинства других параметров CHANGE MASTER записываются в файл по умолчанию master.info или в файл, настроенный параметром master_info_file. Поток ввода/вывода реплики поддерживает обновление этой позиции двоичного лога по мере скачивания событий только при установке параметра MASTER_USE_GTID в значение NO. В противном случае файл не обновляется для каждого события. Дополнительную информацию см. в разделе CHANGE MASTER TO: Сохранение параметров.

Поток SQL реплики

Поток SQL реплики считывает события из relay лога. Что он с ними делает, зависит от того, используется ли параллельная репликация. Если параллельная репликация не используется, то поток SQL применяет события к своей локальной копии данных. Если параллельная репликация используется, то поток SQL передает события своим рабочим потокам для параллельного применения.

Позиция relay лога

Позицию relay лога потока SQL реплики можно проверить, выполнив оператор SHOW SLAVE STATUS. Она будет показана в столбцах Relay_Log_File и Relay_Log_Pos.

Позицию relay лога потока SQL реплики можно установить, задав параметры RELAY_LOG_FILE и RELAY_LOG_POS с помощью оператора CHANGE MASTER.

Позиция relay лога потока SQL реплики записывается в файл по умолчанию relay-log.info или в файл, настроенный переменной системы relay_log_info_file. Поток SQL реплики поддерживает обновление этой позиции relay лога по мере применения событий. Дополнительную информацию см. в разделе CHANGE MASTER TO: Сохранение параметров.

Позиция двоичного лога

Соответствующую позицию двоичного лога текущей позиции relay лога потока SQL реплики можно проверить, выполнив оператор SHOW SLAVE STATUS. Она будет показана в столбцах Relay_Master_Log_File и Exec_Master_Log_Pos.

Позиция GTID

Если реплика реплицирует события двоичного лога, содержащие GTID, то поток SQL реплики запишет каждый GTID, который он применит, в таблицу mysql.gtid_slave_pos. Этот GTID можно просмотреть и изменить с помощью системной переменной gtid_slave_pos.

Если на реплике включена системная переменная log_slave_updates и если на реплике включён двоичный лог, то каждая запись потока SQL реплики также будет попадать в двоичный лог реплики. Это означает, что GTID реплицированных транзакций будут отражены в значении системной переменной gtid_binlog_pos.

Дополнительную информацию см. в разделе CHANGE MASTER TO: Сохранение GTID.

Рабочие потоки

При использовании параллельной репликации, поток SQL передает события своим рабочим потокам для параллельного применения.