13.4.2.1 CHANGE MASTER TO Syntax

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 는 슬레이브 서버가 마스터 서버에 접속 마스터 바이너리 로그의 읽기 및 슬레이브 릴레이 로그를 읽는 데 사용하는 매개 변수를 변경합니다. 또한 마스터 정보 및 릴레이 로그 정보 저장소의 내용을 업데이트합니다 ( 섹션 17.2.2 "복제 릴레이 및 상태 로그" 를 참조하십시오). CHANGE MASTER TO 를 사용하려면 슬레이브 복제 스레드를 중지해야합니다 (필요한 경우 STOP SLAVE 를 사용합니다). MySQL 5.6.11 이후에서는 gtid_next 도 AUTOMATIC 으로 설정해야합니다 (Bug # 16062608).

다음의 설명에 표시된 것을 제외하고 지정되지 않은 옵션은 그 값을 유지합니다. 따라서 대부분의 경우 변경되지 않는 옵션을 지정할 필요가 없습니다. 예를 들어, MySQL 마스터에 연결하기위한 암호가 변경된 경우 새 암호에 대한 슬레이브에 통지하기 위해서 다음 문을 실행하기 만하면됩니다.

 STOP SLAVE; - if replication was running
 CHANGE 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 사용에 대한 정보를 제공합니다. 이들은 섹션 6.3.10.4 "SSL 명령 옵션" 및 섹션 17.3.7 "SSL을 사용하여 복제 설정" 에 설명되어있는 --ssl- xxx 옵션에 해당합니다. 이 옵션은 SSL 지원없이 컴파일 된 슬레이브에서도 변경할 수 있습니다. 이들은 마스터 정보 저장소에 저장되지만 슬레이브에서 SSL 지원이 활성화되어 있지 않으면 무시됩니다. MASTER_SSL_CRL 과 MASTER_SSL_CRLPATH 는 MySQL 5.6.3에서 추가되었습니다.

MASTER_CONNECT_RETRY 은 연결 재시도 사이의 시간 (초)을 지정합니다. 기본값은 60입니다.

MASTER_RETRY_COUNT (MySQL 5.6.1에서 추가되었다)은 재 연결 시도 횟수를 제한하고 SHOW SLAVE STATUS (이것도 MySQL 5.6.1에서 추가되었다)의 출력의 Master_Retry_Count 컬럼의 값을 업데이트 합니다. 기본값은 24 * 3600 = 86400입니다. MASTER_RETRY_COUNT 오래된 --master-retry-count 서버 옵션의 대체를 목적으로하고 있으며, 현재는이 제한을 설정하기위한 권장되는 방법입니다. 새로운 어플리케이션에서는 --master-retry-count 에 의존하지 않도록하고, 이전 버전의 MySQL에서 MySQL 5.6.1 이상으로 업그레이드하는 경우 이에 의존하는 기존의 모든 응용 프로그램을 대신 CHANGE MASTER TO ... MASTER_RETRY_COUNT 을 사용하도록 업데이트하는 것이 좋습니다.

MASTER_DELAY 는 슬레이브가 마스터에서 지연 할 필요가있다 (초)을 지정합니다. 마스터로부터 수신 된 이벤트는 마스터에서 실행보다 적어도 interval 초 후가 될 때까지 실행되지 않습니다. 기본값은 0입니다. interval 이 0에서 2 ³¹ -1까지의 범위 음수가 아닌 정수가 아닌 경우 오류가 발생합니다. 자세한 내용은 섹션 17.3.9 "지연 복제" 를 참조하십시오. 이 옵션은 MySQL 5.6.0에서 추가되었습니다.

MASTER_BIND 는 다중 네트워크 인터페이스를 갖춘 리플리케이션 슬레이브에서 사용되는 것을 목적으로하고 있으며, 마스터에 연결 슬레이브 어떤 네트워크 인터페이스가 선택 될지를 결정합니다.

이 옵션을 사용하여 구성된 주소 (있는 경우)은 SHOW SLAVE STATUS 의 출력 Master_Bind 컬럼에서 확인할 수 있습니다. 슬레이브 상태 로그 테이블을 사용하는 (서버를 --master-info-repository=TABLE 로 시작하는) 경우,이 값은 또한 mysql.slave_master_info 테이블 Master_bind 컬럼으로도 확인할 수 있습니다.

복제 슬레이브를 특정 네트워크 인터페이스에 바인딩하는 기능은 MySQL 5.6.2에서 추가되었습니다. 이것은 또한 MySQL Cluster NDB 7.3.1 이상에서 지원되고 있습니다.

MASTER_HEARTBEAT_PERIOD 복제 하트 비트 사이의 간격 (초)을 설정합니다. 이벤트에 의해 마스터의 바이너리 로그가 업데이트 될 때마다 다음 하트 비트의 대기 기간이 재설정됩니다. interval 은 0에서 4294967 초까지의 범위 및 밀리 초 단위의 해상도를 가진 10 진수 값입니다. 0이 아닌 최소값은 0.001입니다. 하트 비트가 마스터에 의해 전송되는 바이너리 로그 파일에 보내지 않은 이벤트가 interval 보다 오랜 기간 동안 존재하지 않는 경우뿐입니다.

마스터 연결 정보를 테이블에 기록하는 경우, MASTER_HEARTBEAT_PERIOD 은 mysql.slave_master_info 테이블의 Heartbeat 컬럼의 값으로 확인할 수 있습니다.

interval 을 0으로 설정하면 하트 비트가 완전히 해제됩니다. interval 의 기본값은 slave_net_timeout 을 2로 나눈 값에 동일 해집니다.

@@global.slave_net_timeout 을 현재의 하트 비트 간격보다 작은 값으로 설정하면 경고가 발행됩니다. 하트 비트 간격에 RESET SLAVE 를 발행하는 효과는 그 간격의 기본값으로 재설정합니다.

MASTER_LOG_FILE 과 MASTER_LOG_POS 는 슬레이브 I / O 스레드가 다음 스레드가 시작되면 마스터에서 읽기를 시작해야 할 좌표입니다. 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 의 모두 지정되어 있지 않은 경우, 슬레이브는 CHANGE MASTER TO 가 발행되기 전에 슬레이브 SQL 스레드의 마지막 좌표를 사용합니다. 그러면 예를 들어, 단순히 사용하는 암호 만 변경하는 경우, 슬레이브 SQL 쓰레드가 슬레이브 I / O 쓰레드에 비해 늦어졌다하더라도 복제에 불연속성이 발생하지 않는 것이 보증됩니다.

MASTER_AUTO_POSITION 은 MySQL 5.6.5에서 추가되었습니다. MASTER_AUTO_POSITION = 1 이 CHANGE MASTER TO 함께 사용 된 경우, 슬레이브는 GTID 기반 복제 프로토콜을 사용하여 마스터에 연결하려고합니다.

GTID를 사용하는 경우, 슬레이브는 어떤 트랜잭션 수신 또는 실행, 혹은 그 양쪽 모두를 이미 행하고 있는지를 마스터에 통지합니다. 이 세트를 계산하기 위해 슬레이브는 gtid_executed 전역 값과 SHOW SLAVE STATUS 에서 Retrieved_gtid_set 컬럼의 값을 읽습니다. Retrieved_gtid_set 에 마지막으로 전송 된 트랜잭션 GTID이 트랜잭션이 부분적으로 전송되지 않은 경우에도 포함되어 있기 때문에 마지막에 수신 된 GTID이 집합에서 제외됩니다. 따라서 슬레이브는 다음 세트를 계산합니다.

 UNION (@@ global.gtid_executed, Retrieved_gtid_set - last_received_GTID )

이 세트는 초기 핸드 쉐이크의 일부로 마스터로 전송되며 마스터는 실행 중 그 세트에 포함되어 있지 않은 모든 트랜잭션을 되돌립니다. 이러한 트랜잭션 중 하나가 이미 마스터의 바이너리 로그에서 제거 된 경우 마스터에서 슬레이브에 오류 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS가 전송되어 복제가 시작되지 않습니다.

GTID 기반 복제가 사용되는 경우 MASTER_LOG_FILE 과 MASTER_LOG_POS 의해 표현 된 좌표는 사용되지 않고 대신 글로벌 트랜잭션 식별자가 사용됩니다. 따라서 이러한 옵션 중 하나 또는 모두를 MASTER_AUTO_POSITION 함께 사용하면 오류가 발생합니다.

MySQL 5.6.10에서는 SHOW SLAVE STATUS 의 출력을 체크하여 자동 포지셔닝이 유효한 상태에서 복제가 실행되고 있는지를 확인할 수 있습니다. (Bug # 15992220)

CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1 을 발행하기 전에 gtid_mode 도 활성화해야합니다. 그렇지 않으면,이 문은 오류로 실패합니다.

GTID를 사용한 후에 이전 파일 기반의 복제 프로토콜로 되돌리려는 MASTER_LOG_FILE 또는 MASTER_LOG_POSITION 중 하나뿐만 아니라 MASTER_AUTO_POSITION = 0 을 지정하는 새로운 CHANGE MASTER TO 문을 발행 할 수 있습니다.

CHANGE MASTER TO 는 RELAY_LOG_FILE 또는 RELAY_LOG_POS 가 지정되어 있지 않은 한, 모든 릴레이 로그 파일을 삭제하고 새로운 릴레이 로그 파일을 시작합니다. 지정되는 경우, 릴레이 로그 파일은 유지되고 relay_log_purge 전역 변수는 암시 적으로 0으로 설정됩니다.

MySQL 5.6.2 이전에는 RELAY_LOG_FILE 절대 경로가 필요했습니다. MySQL 5.6.2에서 경로를 상대 경로 일 수 있습니다. 이 경우, 슬레이브의 데이터 디렉토리를 기준으로하는 것으로 간주됩니다. (Bug # 12190)

IGNORE_SERVER_IDS 는 0 개 이상의 서버 ID의 쉼표로 구분 된 목록을받습니다. 해당 서버에서 발생되는 이벤트는 다시 계속 릴레이 로그에 기록되는 로그 회전 및 삭제 이벤트를 제외하고 무시됩니다.

순환 복제는 원래 서버는 일반적으로 독자적인 이벤트 터미네이터 역할을하기 때문에 이러한 이벤트가 여러 번 적용되는 것은 아닙니다. 따라서이 옵션은 순환의 서버 중 하나가 제거 된 때의 순환 복제에 도움이됩니다. 1,2,3 및 4의 서버 ID를 가진 4 대의 서버를 포함하는 순환 복제 설치가 존재할 때, 서버 3에 오류가 발생했다고합니다. 서버 2 서버 4에 복제를 시작하고이 격차를 브리징 할 경우 서버 4에서 발행하는 CHANGE MASTER TO 문에 IGNORE_SERVER_IDS = (3) 를 포함하여 서버 4에 그 마스터로 서버 3 대신 서버 2를 사용하도록 지시 할 수 있습니다. 그로 인하여 서버 4는 사용되지 않게하는 서버에서 발신 된 모든 문을 무시하고 전파 없습니다.

CHANGE MASTER TO 문이 IGNORE_SERVER_IDS 옵션없이 발행 된 경우 기존의 목록이 그대로 유지됩니다. 무시되는 서버 목록을 지우려면이 옵션을 하늘의 목록과 함께 사용해야합니다.

 CHANGE MASTER TO IGNORE_SERVER_IDS = ();

RESET SLAVE ALL 서버 ID 목록에는 영향을주지 않습니다. 이 문제는 MySQL 5.7에서 수정되어 있습니다. (Bug # 18816897)

IGNORE_SERVER_IDS 서버의 자신의 ID가 포함되어있을 때, --replicate-same-server-id 옵션이 활성화 된 상태에서 서버가 실행 된 경우 오류가 발생합니다.

MySQL 5.6에서는 마스터 정보 저장소 및 SHOW SLAVE STATUS 의 출력은 현재 무시되고있는 서버의 목록이 제공됩니다. 자세한 내용은 섹션 17.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 옵션 지정 (더미 값도)은 서버에 그것이 슬레이브이라고 생각하는 데 필요합니다.

다음 표는 문자열 값 옵션에 허용되는 최대 길이를 보여줍니다.