START SLAVE [thread_types] [until_option] [connection_options]thread_types:    [thread_type [, thread_type] ... ]thread_type:     IO_THREAD | SQL_THREADuntil_option:    UNTIL {   {SQL_BEFORE_GTIDS | SQL_AFTER_GTIDS} = gtid_set          |   MASTER_LOG_FILE = 'log_name', MASTER_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']gtid_set:    uuid_set [, uuid_set] ...    | ''uuid_set:    uuid:interval[:interval]...uuid:    hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhhh:    [0-9,A-F]interval:    n[-n]    (n >= 1) 

START SLAVE без thread_type опции запускают оба из ведомых потоков. Поток ввода-вывода читает события из главного сервера и хранит их в релейном журнале. Поток SQL читает события из релейного журнала и выполняет их. START SLAVE требует SUPER полномочие.

Если START SLAVE преуспевает в том, чтобы запустить ведомые потоки, это возвращается без любой ошибки. Однако, даже в этом случае, могло бы случиться так, что ведомые потоки запускаются и затем более поздняя остановка (например, потому что они не управляют соединиться с ведущим устройством или считать ее двоичный журнал, или некоторую другую проблему). START SLAVE не предупреждает Вас об этом. Следует проверить журнал ошибок ведомого устройства на сообщения об ошибках, сгенерированные ведомыми потоками, или проверить, что они работают удовлетворительно с SHOW SLAVE STATUS.

В MySQL 5.7, START SLAVE вызывает неявную фиксацию продолжающейся транзакции. См. Раздел 13.3.3, "Операторы Который Причина Неявная Фиксация".

Начинание с MySQL 5.7.1, gtid_next должен быть установлен в AUTOMATIC прежде, чем сделать это заявление (Ошибка #16062608).

MySQL 5.7 поддерживает сменную пользовательскую аутентификацию по паролю с START SLAVE с USER, PASSWORD, DEFAULT_AUTH и PLUGIN_DIR опции, как описано в следующем списке:

Невозможно использовать SQL_THREAD опция, определяя USER, PASSWORD, или оба.

См. Раздел 6.3.7, "Сменная Аутентификация", для получения дополнительной информации.

Если небезопасное соединение используется с какими-либо этими опциями, сервер выходит, пароли Отправки предупреждения в простом тексте без SSL/TLS чрезвычайно небезопасно.

START SLAVE ... UNTIL поддерживает две дополнительных опции для использования с глобальными идентификаторами транзакции (GTIDs) (см. Раздел 16.1.3, "Репликация с Глобальными Идентификаторами транзакции"). Каждое из этих взятий ряд того или более глобальных идентификаторов транзакции gtid_set как параметр (см. наборы GTID, для получения дополнительной информации).

Когда нет thread_type определяется, START SLAVE UNTIL SQL_BEFORE_GTIDS причины и ведомый SQL распараллеливают, чтобы обработать и ведомый поток ввода-вывода, чтобы выбрать транзакции, пока они оба не достигли первой транзакции, GTID которой перечисляется в gtid_set. START SLAVE UNTIL SQL_AFTER_GTIDS заставляет ведомые потоки обрабатывать все транзакции до last транзакция в gtid_set был обработан обоими потоками. Другими словами, START SLAVE UNTIL SQL_BEFORE_GTIDS заставляет ведомый SQL обрабатывать и потоки ввода-вывода, чтобы выбрать все транзакции, происходящие перед первым GTID в gtid_set достигается, и START SLAVE UNTIL SQL_AFTER_GTIDS заставляет ведомые потоки обрабатывать все транзакции, включая тех, GTIDs которых находятся в gtid_set, пока каждый не встретился с транзакцией, GTID которой не является частью набора. SQL_BEFORE_GTIDS и SQL_AFTER_GTIDS каждая поддержка SQL_THREAD и IO_THREAD опции.

Например, START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56 заставляет ведомый поток SQL обрабатывать все транзакции, происходящие от ведущего устройства чей server_uuid 3E11FA47-71CA-11E1-9E33-C80AA9429562 пока это не встречается с транзакцией, имеющей порядковый номер 11; это тогда останавливается, не обрабатывая эту транзакцию. Другими словами все транзакции до и включая транзакцию с порядковым номером 10 обрабатываются. Выполнение START SLAVE IO_THREAD UNTIL SQL_AFTER_GTIDS = 3E11FA47-71CA-11E1-9E33-C80AA9429562:11-56, с другой стороны, заставил бы ведомый поток ввода-вывода получать все транзакции, только упомянутые от ведущего устройства, включая все транзакции, имеющие порядковые номера 11 - 56, и затем останавливаться, не обрабатывая дополнительных транзакций; то есть, транзакция, имеющая порядковый номер 56, была бы последней транзакцией, выбранной ведомым потоком ввода-вывода.

Ни с одним SQL_THREAD опция, ни IO_THREAD опция, предыдущий оператор заставил бы ведомый поток SQL выполнять все транзакции, происходящие от этого ведущего устройства, включая все транзакции с порядковыми номерами 11 - 56, и затем останавливаться, не обрабатывая дополнительных транзакций. Та же самая команда также заставила бы ведомый поток ввода-вывода запускаться. Когда поток SQL достигает условия, он останавливается. Другими словами, START SLAVE UNTIL SQL_BEFORE_GTIDS имеет тот же самый эффект как START SLAVE SQL_THREAD, IO_THREAD UNTIL SQL_BEFORE_GTIDS; ведомый поток SQL и ведомый поток ввода-вывода каждый запускаются, и поток SQL продолжает выполнять транзакции, пока условие остановки для того потока не соблюдают. (Точно так же START SLAVE UNTIL SQL_AFTER_GTIDS эффективно то же самое как START SLAVE SQL_THREAD, IO_THREAD UNTIL SQL_AFTER_GTIDS.)

START SLAVE UNTIL SQL_AFTER_MTS_GAPS заставляет потоки SQL многопоточного ведомого устройства работать, пока больше разрывов не находится в релейном журнале, и затем остановиться. Этот оператор может взять SQL_THREAD опция, но эффекты оператора остается неизменной. Это не имеет никакого эффекта на ведомый поток ввода-вывода (и не может использоваться с IO_THREAD опция). START SLAVE UNTIL SQL_AFTER_MTS_GAPS должен использоваться прежде, чем переключить ведомое устройство от многопоточного режима до однопоточного режима (то есть, сбрасывая slave_parallel_workers назад к 0 от положительного, ненулевого значения) после того, как ведомое устройство перестало работать с ошибками в многопоточном режиме.

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

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;SET @@GLOBAL.slave_parallel_workers = 0;START SLAVE SQL_THREAD;

Если Вы выполняли отказавшее многопоточное ведомое устройство с relay_log_recovery включенный, тогда следует выйти START SLAVE UNTIL SQL_AFTER_MTS_GAPS до выполнения CHANGE MASTER TO. Иначе последние сбои оператора.

START SLAVE отправляет подтверждение пользователю после того, как и поток ввода-вывода и поток SQL запустились. Однако, поток ввода-вывода еще, возможно, не соединился. Поэтому успешное START SLAVE причины SHOW SLAVE STATUS показать Slave_SQL_Running=Yes, но это не гарантирует это Slave_IO_Running=Yes (потому что Slave_IO_Running=Yes только если поток ввода-вывода работает и соединенный). Для получения дополнительной информации см. Раздел 13.7.5.33,"SHOW SLAVE STATUS Синтаксис", и Раздел 16.1.5.1, "Проверяя Состояние Репликации".

Можно добавить IO_THREAD и SQL_THREAD опции к оператору, чтобы назвать, который из потоков, чтобы запуститься. SQL_THREAD опция отвергается, определяя USER, PASSWORD, или оба (Ошибка #13083642).

UNTIL пункт (until_option, в предыдущей грамматике), может быть добавлен, чтобы определить, что ведомое устройство должно запуститься и работать, пока поток SQL не достигает данной точки в основном двоичном журнале или в ведомом релейном журнале. Когда поток SQL достигает той точки, он останавливается. Если SQL_THREAD опция определяется в операторе, она запускает только поток SQL. Иначе, это запускает оба ведомых потока. Если поток SQL работает, UNTIL пункт игнорируется, и предупреждение выпускается. Невозможно использовать UNTIL пункт с IO_THREAD опция.

Это также возможно с START SLAVE UNTIL чтобы определить остановку указывают относительно данного GTID или набора GTIDs на использование одной из опций SQL_BEFORE_GTIDS или SQL_AFTER_GTIDS, как объяснено ранее в этом разделе. При использовании одной из этих опций можно определить SQL_THREAD, IO_THREAD, оба из них, или ни один из них. Если Вы определяете только SQL_THREAD, тогда только на ведомый поток SQL влияет оператор; если только IO_THREAD используется, тогда только на ведомый ввод-вывод влияют. Если оба SQL_THREAD и IO_THREAD используются, или если ни один из них не используется, то и на SQL и на потоки ввода-вывода влияет оператор.

UNTIL пункт не поддерживается для многопоточных ведомых устройств кроме тех случаев, когда также использование SQL_AFTER_MTS_GAPS.

Для UNTIL пункт, следует определить любое из следующего:

Не смешивайте основные и релейные опции журнала. Не смешивайте опции файла журнала с опциями GTID.

Любой UNTIL условие сбрасывается последующим STOP SLAVE оператор, a START SLAVE оператор, который включает нет UNTIL пункт, или перезапуск сервера.

Определяя файл журнала и позицию, можно использовать IO_THREAD опция с START SLAVE ... UNTIL даже при том, что только на поток SQL влияет этот оператор. IO_THREAD опция игнорируется в таких случаях. Предыдущее ограничение не применяется при использовании одной из опций GTID (SQL_BEFORE_GTIDS и SQL_AFTER_GTIDS); опции GTID поддерживают обоих SQL_THREAD и IO_THREAD, как объяснено ранее в этом разделе.

UNTIL пункт может быть полезным для того, чтобы отладил репликацию, или заставил репликацию продолжаться, пока непосредственно перед тем, как точкой, где Вы хотите избежать иметь ведомое устройство, не тиражируют событие. Например, если неблагоразумное DROP TABLE оператор выполнялся на ведущем устройстве, можно использовать UNTIL сказать ведомому устройству выполняться до той точки, но не дальше. Чтобы найти, каково событие, используйте mysqlbinlog с основным двоичным журналом или ведомым релейным журналом, или при использовании a SHOW BINLOG EVENTS оператор.

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

SHOW SLAVE STATUS оператор включает выходные поля, которые выводят на экран текущую стоимость UNTIL условие.

В очень старых версиях MySQL (перед 4.0.5), вызвали этот оператор SLAVE START. В MySQL 5.7 тот синтаксис производит ошибку.