15.4.2.4 START REPLICA Statement — MySQL 8.4

15.4.2.4 Заявление START REPLICA

START REPLICA [thread_types] [until_option] [connection_options] [channel_option]

thread_types:
    [thread_type [, thread_type] ... ]

thread_type:
    IO_THREAD | SQL_THREAD

until_option:
    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set
          |   SOURCE_LOG_FILE = 'log_name', SOURCE_LOG_POS = log_pos
          |   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
          |   SQL_AFTER_MTS_GAPS  }

connection_options:
    [USER='user_name'] [PASSWORD='user_pass'] [DEFAULT_AUTH='plugin_name'] [PLUGIN_DIR='plugin_dir']


channel_option:
    FOR CHANNEL channel

gtid_set:
    uuid_set [, uuid_set] ...
    | ''

uuid_set:
    uuid:interval[:interval]...

uuid:
    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh

h:
    [0-9,A-F]

interval:
    n[-n]

    (n >= 1)

START REPLICA запускает потоки репликации, либо вместе, либо по отдельности.

START REPLICA требует привилегия REPLICATION_SLAVE_ADMIN (или устаревшую привилегию SUPER). START REPLICA вызывает неявную фиксацию текущей транзакции. См. Раздел 15.3.3, «Заявления, вызывающие неявную фиксацию».

Для типов потоков можно указать IO_THREAD, SQL_THREAD, оба этих типа или ни один из них. Только запущенные потоки затронуты этим заявлением.

START REPLICA без опций типа потока запускает все потоки репликации, как и START REPLICA с обеими опциями типа потока.
IO_THREAD запускает поток получателя репликации, который считывает события с сервера-источника и сохраняет их в релейном журнале.
SQL_THREAD запускает поток приложения репликации, который считывает события из релейного журнала и выполняет их. Мультипоточная реплика (с replica_parallel_workers > 0) применяет транзакции с помощью координатора и нескольких потоков приложения, и SQL_THREAD запускает все эти потоки.

Важно

START REPLICA отправляет подтверждение пользователю после запуска всех потоков репликации. Однако поток получателя репликации может еще не подключиться к источнику успешно, или поток приложения может остановиться при применении события сразу после запуска. START REPLICA не продолжает отслеживать потоки после их запуска, поэтому не предупреждает вас, если они впоследствии остановятся или не смогут подключиться. Вы должны проверить журнал ошибок реплики на наличие сообщений об ошибках, сгенерированных потоками репликации, или проверить их успешную работу с помощью SHOW REPLICA STATUS. Успешное выполнение START REPLICA вызывает SHOW REPLICA STATUS, чтобы отобразить Replica_SQL_Running=Yes, но может или не может отобразить Replica_IO_Running=Yes, так как Replica_IO_Running=Yes отображается только если поток получателя работает и подключен. Дополнительная информация в Разделе 19.1.7.1, «Проверка статуса репликации».

Необязательная FOR CHANNEL channel-оператор позволяет указать, к какому каналу репликации применяется это заявление. Указание FOR CHANNEL channel -оператор применяется к определенному каналу репликации. Если не указан канал и дополнительных каналов нет, заявление применяется к по умолчанию. Если START REPLICA-заявление не определяет канал при использовании нескольких каналов, это заявление запускает указанные потоки для всех каналов. Дополнительная информация в Разделе 19.2.2, «Каналы репликации».

Каналы репликации для Group Replication (group_replication_applier и group_replication_recovery) управляются автоматически экземпляром сервера. START REPLICA вообще нельзя использовать с каналом group_replication_recovery и следует использовать только с каналом group_replication_applier, когда Group Replication не запущена. Канал group_replication_applier имеет только поток приложения и не имеет потока получателя, поэтому его можно запустить при необходимости, используя SQL_THREAD опцию без IO_THREAD опции.

START REPLICA поддерживает подключаемую аутентификацию пользователя/пароля (см. Раздел 8.2.17, «Подключаемая аутентификация») с помощью опций USER, PASSWORD, DEFAULT_AUTH и PLUGIN_DIR, как описано в следующем списке. При использовании этих опций необходимо запустить поток получателя (опция IO_THREAD) или все потоки репликации; нельзя запустить только поток приложения репликации (опция SQL_THREAD).

USER: Имя пользователя для учетной записи. Требуется, если используется PASSWORD. Опция не может быть пустой или null.
PASSWORD: Пароль для учетной записи указанного пользователя.
DEFAULT_AUTH: Имя плагина аутентификации. По умолчанию используется собственная аутентификация MySQL.
PLUGIN_DIR: Путь к плагину аутентификации.

Важно

Пароль, установленный с помощью START REPLICA, маскируется при записи в журналы сервера MySQL, таблицы Performance Schema и при выполнении заявлений SHOW PROCESSLIST. Однако он отправляется в открытом виде по соединению с экземпляром сервера реплики. Для защиты пароля во время передачи используйте шифрование SSL/TLS, туннель SSH или другой метод защиты соединения от несанкционированного просмотра для соединения между экземпляром сервера реплики и клиентом, используемым для выдачи START REPLICA.

Оператор UNTIL заставляет реплику начать репликацию, обработать транзакции до указанной в операторе UNTIL точки, а затем снова остановиться. Оператор UNTIL может быть использован, чтобы реплика продолжала выполняться до точки, непосредственно перед которой нужно пропустить ненужную транзакцию, и затем пропустить эту транзакцию, как описано в Разделе 19.1.7.3, «Пропускание транзакций». Для идентификации транзакции можно использовать mysqlbinlog с двоичным журналом источника или релейным журналом реплики, или использовать заявление SHOW BINLOG EVENTS.

Также можно использовать оператор UNTIL для отладки репликации, обрабатывая транзакции по одной или частями. Если используется оператор UNTIL для этого, запустите реплику с помощью --skip-replica-start для предотвращения запуска SQL-потока при запуске сервера реплики. Удалите опцию или настройку системной переменной после завершения процедуры, чтобы не забыть её в случае непредвиденной перезагрузки сервера.

Заявление SHOW REPLICA STATUS включает поля вывода, отображающие текущие значения условия UNTIL. Условие UNTIL действует до тех пор, пока затронутые потоки всё ещё работают, и удаляется, когда они останавливаются.

Оператор UNTIL работает с потоком приложения репликации (опция SQL_THREAD). Можно использовать опцию SQL_THREAD или позволить реплике по умолчанию запустить оба потока. Если используется только опция IO_THREAD, оператор UNTIL игнорируется, так как поток приложения не запускается.

Точка, указанная в операторе UNTIL, может быть любой из следующих опций (и только одной):

SOURCE_LOG_FILE и SOURCE_LOG_POS

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

Эти параметры по-прежнему могут использоваться, когда параметр GTID_ONLY был установлен в операторе CHANGE REPLICATION SOURCE TO для прекращения сохранения имён файлов и позиций в файлах в репозиториях метаданных репликации. Имена файлов и позиции отслеживаются в памяти.

RELAY_LOG_FILE и RELAY_LOG_POS

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

SQL_BEFORE_GTIDS

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

SQL_AFTER_GTIDS

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

С помощью SQL_AFTER_GTIDS потоки репликации останавливаются после обработки всех транзакций в наборе GTID. Транзакции обрабатываются в порядке получения, поэтому возможно, что это включает транзакции, которые не являются частью набора GTID, но которые получены (и обработаны) до того, как все транзакции в наборе будут завершены. Например, выполнение START REPLICA UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 заставляет реплику получить (и обработать) все транзакции с источника до тех пор, пока не будут обработаны все транзакции с номерами последовательности от 11 до 56, а затем останавливаться без обработки дополнительных транзакций после достижения этой точки.

В более ранних версиях MySQL этот параметр нельзя было использовать с replica_parallel_workers > 1. В MySQL 8.4 это больше не проблема, и SQL_AFTER_GTIDS можно использовать без возврата реплики в однопоточный режим.

SQL_AFTER_MTS_GAPS

Только для реплики с несколькими потоками (с replica_parallel_workers > 0), этот параметр заставляет реплику обрабатывать транзакции до той точки, где больше нет пробелов в последовательности выполненных из журнала репликации транзакций. При использовании многопоточной реплики есть вероятность возникновения пробелов в следующих ситуациях:

Поток координатора остановлен.
В потоках приложения произошла ошибка.
mysqld неожиданно завершил работу.

Если в канале репликации есть пробелы, база данных реплики находится в состоянии, которое, возможно, никогда не существовало на источнике. Реплика отслеживает пробелы внутри и не допускает операторов CHANGE REPLICATION SOURCE TO, которые могли бы удалить информацию о пробеле при их выполнении.

По умолчанию все реплики многопоточные. Когда replica_preserve_commit_order=ON на реплике (по умолчанию), пробелы не должны возникать, за исключением конкретных ситуаций, перечисленных в описании этой переменной. Если replica_preserve_commit_order равно OFF, порядок фиксации транзакций не сохраняется, поэтому вероятность возникновения пробелов намного выше.

Если GTID не используются, и вам необходимо изменить неисправную многопоточную реплику на однопоточную, вы можете выполнить следующую последовательность инструкций в указанном порядке:

START REPLICA UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.replica_parallel_workers = 0;
START REPLICA SQL_THREAD;