MySQL 5.6 한글메뉴얼

17.3.6 장애 발생시 Master 전환

GTID 기반 복제를 사용하는 경우 ( 섹션 17.1.3 "글로벌 트랜잭션 식별자를 사용한 복제" 를 참조하십시오) 장애 발생시 MySQL Utilities에서 제공되는 mysqlfailover을 사용하여 마스터와 슬레이브 간의 장애 조치 를 제공 할 수 있습니다. 자세한 내용은 mysqlfailover - Automatic replication health monitoring and failover 를 참조하십시오. 그렇지 않은 경우는 마스터와 하나 이상의 슬레이브을 설치해야합니다. 그 때 시작하고 있는지 여부를 확인하기 위해 마스터를 모니터하는 응용 프로그램 또는 스크립트를 작성하거나 장애시 다른 마스터로 변경하도록 슬레이브 및 응용 프로그램에 지시 할 필요가 있습니다. 이 섹션에서는이 방법으로 페일 오버를 설정할 때 발생하는 몇 가지 문제에 대해 설명합니다.

CHANGE MASTER TO 문을 사용하여 새 마스터로 전환하도록 슬레이브에 지시 할 수 있습니다. 슬레이브는 마스터 데이터베이스가 슬레이브의 것과 호환 여부를 확인하지 않습니다. 단순히 새로운 마스터의 바이너리 로그의 지정된 좌표에서 이벤트를 읽고 실행하면됩니다. 장애 조치 상황에서는 그룹의 모든 서버가 동일한 바이너리 로그 파일에서 동일한 이벤트를 실행하는 것이 일반적이기 때문에 이벤트의 소스를 변경하더라도 변경 때주의하여 데이터베이스의 구조 또는 완전성에 영향을 미치지 않을 것입니다.

슬레이브는 --log-bin 옵션과 함께, --log-slave-updates 없이 실행해야합니다. 이 방법에서는 슬레이브는 슬레이브 mysqld를 다시 시작하지 않고 주인이 될 준비가되어 있습니다. 그림 17.4 "복제를 사용하는 중복 초기 구조" 에서 보여주는 구조를 상정합니다.

그림 17.4 복제를 사용하는 중복 초기 구조

이 그림에서는 MySQL Master 마스터 데이터베이스를 유지하고 MySQL Slave 호스트는 리플리케이션 슬레이브에서 Web Client 머신은 데이터베이스 읽기 및 쓰기를 발행하고 있습니다. 읽기만을 발행하는 (그리고 일반적으로 슬레이브에 연결되어있는) Web 클라이언트는 표시되지 않습니다. 장애시 새로운 서버로 전환 필요가 없기 때문입니다. 읽기 / 쓰기 확장 복제 구조의 자세한 예는 섹션 17.3.3 "확장을 위해 복제 사용" 을 참조하십시오.

각 MySQL Slave ( Slave 1 , Slave 2 , Slave 3 )은 --log-bin 있음, --log-slave-updates 없이 작동하고있는 슬레이브입니다. --log-slave-updates 가 지정되지 않는 한 슬레이브가 마스터로부터받은 업데이트 로그는 바이너리 로그에 기록되지 않기 때문에 각 슬레이브의 바이너리 로그는 처음에는 비어 있습니다. 어떠한 원인에 의해 MySQL Master 를 사용할 수 없게 된 경우, 슬레이브 중 하나를 선택 새 마스터 할 수 있습니다. 예를 들어, Slave 1 을 선택하면 모든 Web Clients 를 Slave 1 (바이너리 로그에 업데이트를 기록)로 리디렉션되는 것입니다. 그러자 Slave 2 와 Slave 3 는 Slave 1 에서 복제되는 것입니다.

--log-slave-updates 없이 슬레이브를 실행하는 이유는 슬레이브 중 하나를 새로운 마스터로했기 때문에 노예가 업데이트를 두 번받지 않게하는 것입니다. Slave 1 은 그 --log-slave-updates 가 유효한 경우는 Master 로부터받은 업데이트를 자신의 바이너리 로그에 기록합니다. 이것은 Slave 2 의 마스터가 Master 에서 Slave 1 로 변경되면 Slave 1 이 이미 Master 에서 받았다 업데이트를받을 수 있음을 의미합니다.

모든 슬레이브가 각각의 릴레이 로그에있는 명령문을 처리했는지 확인하십시오. 각 슬레이브에서 STOP SLAVE IO_THREAD 을 실행하여 Has read all relay log 를 볼 때까지 SHOW PROCESSLIST 의 출력을 확인하십시오. 이 모든 슬레이브로 true의 경우, 그들을 새로운 설정으로 재구성 할 수 있습니다. 승격 마스터가 될 슬레이브 Slave 1 에서 STOP SLAVE 및 RESET MASTER 을 발행하십시오.

다른 슬레이브 Slave 2 와 Slave 3 에서 STOP SLAVE 및 CHANGE MASTER TO MASTER_HOST='Slave1' 를 사용합니다 (여기서 'Slave1' 는 Slave 1 의 실제 호스트 이름을 나타냅니다). CHANGE MASTER TO 를 사용하려면 Slave 2 또는 Slave 3 에서 Slave 1 에 연결하는 방법에 대한 모든 정보 ( user , password , port )를 추가하십시오. 여기에서 CHANGE MASTER TO 문을 발행하는 경우에는 Slave 1 바이너리 로그 파일의 이름 또는 읽을 로그 위치를 지정할 필요가 없습니다 (첫 번째 바이너리 로그 파일 및 위치 4 기본값). 마지막으로, Slave 2 와 Slave 3 에서 START SLAVE 를 실행합니다.

새 복제 설치가 실행 된 후 각 Web Client 가 각각 문을 Slave 1 에 보내도록해야합니다. 이 시점에서 Web Client 에서 Slave 1 에 보내진 모든 업데이트 문이 Slave 1 의 바이너리 로그에 기록됩니다 ( Master 정지 이후에 Slave 1 에 보내진 모든 업데이트 문이 포함되어 있습니다).

결과의 서버 구조를 그림 17.5 "복제를 사용하는 중복 마스터 장애 후" 입니다.

그림 17.5 복제를 사용하는 중복 마스터 장애 후

Master 를 다시 사용할 수있게되면 그것을 Slave 1 의 노예로해야합니다. 이렇게하려면 방금 Slave 2 와 Slave 3 에서 발행 한 것과 동일한 CHANGE MASTER TO 문을 Master 로 발행합니다. 그러자 Master 가 Slave 1 슬레이브가 오프라인 인 경우받지 않았다 Web Client 쓰기를받습니다.

Master 를 다시 마스터하려면 (예를 들어, 이것이 가장 강력한 머신이기 때문에), Slave 1 가 사용할 수없는 상태에서 Master 가 새로운 주인이 될 수 있도록 앞의 단계를 사용합니다. 이 단계에서는 Master 의 Slave 1 , Slave 2 및 Slave 3 을 작성하기 전에 Master 에서 RESET MASTER 를 실행하는 것을 잊지 마십시오. 이렇게하지 않으면 슬레이브가 Web Client 응용 프로그램에서 Master 를 사용할 수 없게 된 시점 이전의 오래된 쓰기를받을 수 있습니다.

슬레이브 간의 동기화가 없기 때문에 (그들이 동일한 마스터를 공유하고 있어도) 일부 슬레이브가 다른 것보다 꽤 진행 될 가능성이 있다는 것을 알고 있습니다. 이것은 경우에 따라서는 앞의 예에서 설명한 절차가 예상대로 작동하지 않을 수 있음을 의미합니다. 그러나 실제로는 모든 슬레이브의 릴레이 로그는 서로 꽤 가까운 것입니다.

응용 프로그램이 마스터의 위치를 항상 알고위한 하나의 방법은 마스터의 동적 DNS 엔트리를 가지는 것입니다. bind 에서 nsupdate 를 사용하여 DNS를 동적으로 업데이트 할 수 있습니다.