CHANGE MASTER TO option [, option] ...option:    MASTER_BIND = 'interface_name'  | MASTER_HOST = 'host_name'  | MASTER_USER = 'user_name'  | MASTER_PASSWORD = 'password'  | MASTER_PORT = port_num  | MASTER_CONNECT_RETRY = interval  | MASTER_RETRY_COUNT = count  | MASTER_DELAY = interval  | MASTER_HEARTBEAT_PERIOD = interval  | MASTER_LOG_FILE = 'master_log_name'  | MASTER_LOG_POS = master_log_pos  | MASTER_AUTO_POSITION = {0|1}  | RELAY_LOG_FILE = 'relay_log_name'  | RELAY_LOG_POS = relay_log_pos  | MASTER_SSL = {0|1}  | MASTER_SSL_CA = 'ca_file_name'  | MASTER_SSL_CAPATH = 'ca_directory_name'  | MASTER_SSL_CERT = 'cert_file_name'  | MASTER_SSL_CRL = 'crl_file_name'  | MASTER_SSL_CRLPATH = 'crl_directory_name'  | MASTER_SSL_KEY = 'key_file_name'  | MASTER_SSL_CIPHER = 'cipher_list'  | MASTER_SSL_VERIFY_SERVER_CERT = {0|1}  | IGNORE_SERVER_IDS = (server_id_list)server_id_list:    [server_id [, server_id] ... ]

CHANGE MASTER TO изменяет параметры, которые ведомый сервер использует для того, чтобы соединиться с главным сервером, для того, чтобы считать основной двоичный журнал, и считать ведомый релейный журнал. Это также обновляет содержание основной информации и релейных репозитариев информации журнала (см. Раздел 16.2.2, "Реле репликации и Журналы Состояния"). Использовать CHANGE MASTER TO, ведомые потоки репликации должны быть остановлены (использование STOP SLAVE в случае необходимости). В MySQL 5.6.11 и позже, gtid_next должен также быть установлен в AUTOMATIC (Ошибка #16062608).

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

STOP SLAVE; -- if replication was runningCHANGE MASTER TO MASTER_PASSWORD='new3cret';START SLAVE; -- if you want to restart replication

MASTER_HOST, MASTER_USER, MASTER_PASSWORD, и MASTER_PORT предоставьте информацию ведомому устройству о том, как соединиться с его ведущим устройством:

MASTER_SSL_xxx опции предоставляют информацию об использовании SSL для соединения. Они соответствуют --ssl-xxx опции, описанные в Разделе 6.3.9.4, "Опции Команды SSL", и Раздел 16.3.7, "Устанавливая Репликацию Используя SSL". Эти опции могут быть изменены даже на ведомых устройствах, которые компилируются без поддержки SSL. Они сохраняются к основному репозитарию информации, но игнорируются, если ведомому устройству не включали поддержке SSL. MASTER_SSL_CRL и MASTER_SSL_CRLPATH были добавлены в MySQL 5.6.3.

MASTER_CONNECT_RETRY определяет, сколько секунд, чтобы ожидать между соединяет повторения. Значение по умолчанию 60.

MASTER_RETRY_COUNT, добавленный в MySQL 5.6.1, ограничивает число перепопыток подключения и обновляет значение Master_Retry_Count столбец в выводе SHOW SLAVE STATUS (также добавленный в MySQL 5.6.1). Значение по умолчанию 24 * 3600 = 86400. MASTER_RETRY_COUNT предназначается, чтобы заменить более старое --master-retry-count параметр сервера, и является теперь привилегированным методом для того, чтобы установить этот предел. Вы поощряетесь не положиться --master-retry-count в новых приложениях и, обновляя до MySQL 5.6.1 или позже от более ранних версий MySQL, чтобы обновить любые существующие приложения, которые полагаются на это, так, чтобы они использовали CHANGE MASTER TO ... MASTER_RETRY_COUNT вместо этого.

MASTER_DELAY определяет, сколько секунд позади ведущего устройства ведомое устройство должно отстать. Событие, полученное от ведущего устройства, не выполняется до, по крайней мере, interval на несколько секунд позже чем его выполнение на ведущем устройстве. Значение по умолчанию 0. Ошибка происходит если interval не неотрицательное целое число в диапазоне от 0 до ^231–1. Для получения дополнительной информации см. Раздел 16.3.9, "Задержанная Репликация". Эта опция была добавлена в MySQL 5.6.0.

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

Адрес, сконфигурированный с этой опцией, если таковые вообще имеются, может быть замечен в Master_Bind столбец вывода от SHOW SLAVE STATUS. Если Вы используете ведомые таблицы журнала состояния (сервер, запущенный с --master-info-repository=TABLE), значение может также быть замечено как Master_bind столбец mysql.slave_master_info таблица.

Возможность связать ведомое устройство репликации определенного сетевого интерфейса была добавлена в MySQL 5.6.2. Это также поддерживается MySQL Cluster NDB 7.3.1 и позже.

MASTER_HEARTBEAT_PERIOD устанавливает интервал в секундах между биениями репликации. Всякий раз, когда двоичный журнал ведущего устройства обновляется с событием, время ожидания для следующего биения сбрасывается. interval десятичное значение, имеющее диапазон от 0 до 4294967 секунд и разрешения в миллисекундах; самое маленькое ненулевое значение 0.001. Биения отправляются ведущим устройством, только если нет никаких неотправленных событий в двоичном файле журнала в течение периода дольше чем interval.

Если Вы регистрируете основную информацию о соединении к таблицам, MASTER_HEARTBEAT_PERIOD может быть замечен как значение Heartbeat столбец mysql.slave_master_info таблица.

Установка interval к 0 отключает биения в целом. Значение по умолчанию для interval равно значению slave_net_timeout разделенный на 2.

Установка @@global.slave_net_timeout к значению меньше чем тот из текущего интервала биения приводит к выпускаемому предупреждению. Эффект издания RESET SLAVE на биении интервал должен сбросить это к значению по умолчанию.

MASTER_LOG_FILE и MASTER_LOG_POS координаты, в которых ведомый поток ввода-вывода должен начать читать от ведущего устройства в следующий раз, когда поток запускается. RELAY_LOG_FILE и RELAY_LOG_POS координаты, в которых ведомый поток SQL должен начать читать из журнала реле в следующий раз, когда поток запускается. Если Вы определяете любой из MASTER_LOG_FILE или MASTER_LOG_POS, невозможно определить RELAY_LOG_FILE или RELAY_LOG_POS. В MySQL 5.6.5 и позже, если Вы определяете любой из MASTER_LOG_FILE или MASTER_LOG_POS, также невозможно определить MASTER_AUTO_POSITION = 1 (описанный позже в этом разделе). Если ни один из MASTER_LOG_FILE или MASTER_LOG_POS определяется, ведомое устройство использует последние координаты ведомого потока SQL прежде CHANGE MASTER TO был выпущен. Это гарантирует, что нет никакого разрыва в репликации, даже если ведомый поток SQL был поздно по сравнению с ведомым потоком ввода-вывода, когда Вы просто хотите изменить, скажем, пароль, чтобы использовать.

MASTER_AUTO_POSITION был добавлен в MySQL 5.6.5. Если MASTER_AUTO_POSITION = 1 используется с CHANGE MASTER TO, ведомое устройство пытается соединиться с ведущим устройством, использующим GTID-на-основе протокол репликации. В этом случае, координаты, представленные MASTER_LOG_FILE и MASTER_LOG_POS не используются, и глобальные идентификаторы транзакции используются вместо этого. Таким образом использование или или обе из этих опций вместе с MASTER_AUTO_POSITION вызывает ошибку.

Начиная с MySQL 5.6.10, можно видеть, работает ли репликация с авторасположением включенного, проверяя вывод SHOW SLAVE STATUS. (Ошибка #15992220)

gtid_mode должен также быть включен перед изданием CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1. Иначе, оператор перестал работать с ошибкой.

Чтобы вернуться к более старому основанному на файле протоколу репликации после использования GTIDs, можно выпустить новое CHANGE MASTER TO оператор, который определяет MASTER_AUTO_POSITION = 0, так же как по крайней мере один из MASTER_LOG_FILE или MASTER_LOG_POSITION.

CHANGE MASTER TO удаляет все релейные файлы журнала и запускает новый, если Вы не определяете RELAY_LOG_FILE или RELAY_LOG_POS. В этом случае релейные файлы журнала сохраняются; relay_log_purge глобальная переменная устанавливается тихо в 0.

До MySQL 5.6.2, RELAY_LOG_FILE требуемый абсолютный путь. Начинаясь с MySQL 5.6.2, путь может быть относительным, когда это, как предполагается, относительно каталога данных ведомого устройства. (Ошибка #12190)

IGNORE_SERVER_IDS берет список разделенных запятой значений 0 или больше ID сервера. События, происходящие из соответствующих серверов, игнорируются, за исключением событий вращения и удаления журнала, которые все еще записываются в релейном журнале.

В круговой репликации инициирующий сервер обычно действует как разделитель его собственных событий, так, чтобы они не были применены не раз. Таким образом эта опция полезна в круговой репликации, когда один из серверов в кругу удаляется. Предположите, что у Вас есть круговая установка репликации с 4 серверами, имея ID сервера 1, 2, 3, и 4, и сервером 3 сбоя. Соединяя разрыв мостом, запуская репликацию с сервера 2 к серверу 4, можно включать IGNORE_SERVER_IDS = (3) в CHANGE MASTER TO заявление, которое Вы делаете на сервере 4, чтобы сказать этому использовать сервер 2 в качестве его ведущего устройства вместо сервера 3. Выполнение так причины это, чтобы проигнорировать а не распространить любые операторы, которые произошли с сервером, который больше не находится в использовании.

Если a CHANGE MASTER TO заявление делается ни с кем IGNORE_SERVER_IDS опция, любой существующий список сохраняется; RESET SLAVE также не имеет никакого эффекта на список ID сервера. Чтобы очистить список проигнорированных серверов, необходимо использовать опцию с пустым списком:

CHANGE MASTER TO IGNORE_SERVER_IDS = ();

Если IGNORE_SERVER_IDS содержит собственный ID сервера, и сервер был запущен с --replicate-same-server-id включенная опция, ошибка заканчивается.

В MySQL 5.6, основном репозитарии информации и выводе SHOW SLAVE STATUS обеспечьте список серверов, которые в настоящий момент игнорируются. Для получения дополнительной информации см. Раздел 16.2.2.2, "Ведомые Журналы Состояния", и Раздел 13.7.5.35,"SHOW SLAVE STATUS Синтаксис".

В MySQL 5.6, вызывая CHANGE MASTER TO вызывает предыдущие значения для MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE, и MASTER_LOG_POS быть записанным журналу ошибок, наряду с другой информацией о состоянии ведомого устройства до выполнения.

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

CHANGE MASTER TO полезно для установки ведомого устройства, когда Вы имеете снимок ведущего устройства и записали основные двоичные координаты журнала, соответствующие времени снимка. После загрузки снимка в ведомое устройство, чтобы синхронизировать это с ведомым устройством, можно работать CHANGE MASTER TO MASTER_LOG_FILE='log_name', MASTER_LOG_POS=log_pos на ведомом устройстве, чтобы определить координаты, в которых ведомое устройство должно начать читать основной двоичный журнал.

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

CHANGE MASTER TO  MASTER_HOST='master2.mycompany.com',  MASTER_USER='replication',  MASTER_PASSWORD='bigs3cret',  MASTER_PORT=3306,  MASTER_LOG_FILE='master2-bin.001',  MASTER_LOG_POS=4,  MASTER_CONNECT_RETRY=10;

Следующий пример показывает работу, которая менее часто используется. Это используется, когда у ведомого устройства есть релейные файлы журнала, которые Вы хотите, чтобы это выполнило снова по некоторым причинам. Сделать это, основная потребность не быть достижимым. Вы должны только использовать CHANGE MASTER TO и запустите поток SQL (START SLAVE SQL_THREAD):

CHANGE MASTER TO  RELAY_LOG_FILE='slave-relay-bin.006',  RELAY_LOG_POS=4025;

Можно даже использовать вторую работу в установке нерепликации с автономным, неведомым сервером для восстановления после катастрофического отказа. Предположите, что Ваш сервер отказал, и Вы восстановили его от резервного копирования. Вы хотите воспроизвести собственные двоичные файлы журнала сервера (не релейные файлы журнала, но регулярные двоичные файлы журнала), названный (например) myhost-bin.*. Во-первых, сделайте резервную копию этих двоичных файлов журнала в некотором безопасном месте, в случае, если Вы точно не следуете за процедурой ниже и случайно имеете чистку сервера двоичный журнал. Использовать SET GLOBAL relay_log_purge=0 для дополнительной безопасности. Затем запустите сервер без --log-bin опция, Вместо этого использует --replicate-same-server-id, --relay-log=myhost-bin (чтобы заставить сервер полагать, что эти регулярные двоичные файлы журнала являются релейными файлами журнала), и --skip-slave-start опции. После того, как сервер запускается, сделайте эти заявления:

CHANGE MASTER TO  RELAY_LOG_FILE='myhost-bin.153',  RELAY_LOG_POS=410,  MASTER_HOST='some_dummy_string';START SLAVE SQL_THREAD;

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

Определение MASTER_HOST опция (даже с фиктивным значением) обязана заставлять сервер думать, что это - ведомое устройство.

Следующая таблица показывает максимальную допустимую длину для оцененных строке опций.