19.4.8 Switching Sources During Failover

19.4.8 장애 조치 시 Source 전환

CHANGE REPLICATION SOURCE TO statement를 사용하여 replica에 새로운 source로 변경하도록 지시할 수 있습니다. replica는 source의 데이터베이스가 replica의 데이터베이스와 호환되는지 확인하지 않고, 단순히 새로운 source의 바이너리 로그에서 지정된 좌표부터 이벤트를 읽고 실행하기 시작합니다. 장애 조치 상황에서는 그룹의 모든 서버가 일반적으로 동일한 바이너리 로그 파일에서 동일한 이벤트를 실행하고 있으므로, 이벤트의 source를 변경하더라도, 변경을 신중하게 수행하기만 하면 데이터베이스의 구조나 무결성에 영향을 주지 않아야 합니다.

replica는 바이너리 로깅이 활성화된 상태(기본값인 --log-bin 옵션)로 실행해야 합니다. 복제에 GTID를 사용하지 않는다면, replica는 또한 --log-replica-updates=OFF (replica 업데이트 로깅은 기본적으로 활성화됨)로 실행해야 합니다. 이렇게 하면 replica는 replica의 mysqld를 재시작하지 않고도 source가 될 준비가 됩니다. Figure 19.4, “Redundancy Using Replication, Initial Structure”에 표시된 구조를 가지고 있다고 가정해 봅니다.

Figure 19.4 Redundancy Using Replication, Initial Structure

이 다이어그램에서 Source는 source 데이터베이스를 보유하고, Replica* 호스트는 replica이며, Web Client 머신은 데이터베이스 읽기와 쓰기를 수행합니다. 읽기만 실행하는 웹 클라이언트(일반적으로 replica에 연결되는 클라이언트)는, 장애 발생 시 새로운 서버로 전환할 필요가 없으므로, 표시하지 않았습니다. 읽기/쓰기 스케일 아웃 복제 구조에 대한 좀 더 자세한 예시는 Section 19.4.5, “Using Replication for Scale-Out”를 참조하십시오.

각 MySQL replica (Replica 1, Replica 2, Replica 3)는 바이너리 로깅이 활성화된 replica이며, --log-replica-updates=OFF로 실행됩니다. --log-replica-updates=OFF가 지정되면 replica가 source로부터 수신한 업데이트는 바이너리 로그에 기록되지 않으므로, 각 replica의 바이너리 로그는 초기에는 비어 있습니다. 어떤 이유로든 Source를 사용할 수 없게 되면, replica 중 하나를 선택하여 새로운 source로 지정할 수 있습니다. 예를 들어 Replica 1을 선택하면, 모든 Web Clients는 Replica 1으로 리디렉트되어야 하며, 이 서버는 업데이트를 자신의 바이너리 로그에 기록합니다. 그런 다음 Replica 2와 Replica 3는 Replica 1으로부터 복제를 수행해야 합니다.

replica를 --log-replica-updates=OFF로 실행하는 이유는 replica 중 하나를 새로운 source로 설정했을 때 replica가 업데이트를 두 번 받는 것을 방지하기 위해서입니다. Replica 1에서 기본값인 --log-replica-updates가 활성화되어 있으면, 이 서버는 Source로부터 수신한 업데이트를 자신의 바이너리 로그에도 기록합니다. 이는 Replica 2가 source를 Source에서 Replica 1으로 변경할 때, 이미 Source로부터 수신한 업데이트를 Replica 1로부터 다시 수신하게 될 수 있음을 의미합니다.

모든 replica가 릴레이 로그에 있는 스테이트먼트를 처리했는지 확인하십시오. 각 replica에서 STOP REPLICA IO_THREAD를 실행한 다음, SHOW PROCESSLIST의 출력에서 Has read all relay log가 표시될 때까지 확인합니다. 모든 replica에서 이 조건이 충족되면, 새로운 설정으로 재구성할 수 있습니다. source로 승격될 replica Replica 1에서 STOP REPLICA와 RESET BINARY LOGS AND GTIDS를 실행합니다.

다른 replica인 Replica 2와 Replica 3에서는 STOP REPLICA를 사용하고, CHANGE REPLICATION SOURCE TO SOURCE_HOST='Replica1' (여기서 'Replica1'은 Replica 1의 실제 호스트 이름을 나타냄)을 실행합니다. CHANGE REPLICATION SOURCE TO를 사용할 때, Replica 2 또는 Replica 3에서 Replica 1에 연결하는 방법에 대한 모든 정보( user, password, port)를 추가합니다. 이 시나리오에서 스테이트먼트를 실행할 때는, 읽어들일 Replica 1의 바이너리 로그 파일 이름과 로그 포지션을 지정할 필요가 없습니다. 첫 번째 바이너리 로그 파일과 포지션 4가 기본값이기 때문입니다. 마지막으로 Replica 2와 Replica 3에서 START REPLICA를 실행합니다.

새 복제 구성이 완료되면, 각 Web Client에 스테이트먼트를 Replica 1으로 보내도록 지시해야 합니다. 그 시점부터 Web Client가 Replica 1으로 보내는 모든 업데이트는 Replica 1의 바이너리 로그에 기록되며, 이 로그에는 Source를 사용할 수 없게 된 이후 Replica 1으로 전송된 모든 업데이트가 포함됩니다.

결과적인 서버 구조는 Figure 19.5, “Redundancy Using Replication, After Source Failure”에 나와 있습니다.

Figure 19.5 Redundancy Using Replication, After Source Failure

Source를 다시 사용할 수 있게 되면, 이를 Replica 1의 replica로 만들어야 합니다. 이를 위해, Source에서 이전에 Replica 2와 Replica 3에서 실행했던 것과 동일한 CHANGE REPLICATION SOURCE TO 스테이트먼트를 실행합니다. 그러면 Source는 Replica 1의 replica가 되어, 오프라인 상태였던 동안 놓쳤던 Web Client 쓰기를 이어받습니다.

Source를 다시 source로 만들기 위해서는, Replica 1을 사용할 수 없고 Source가 새로운 source가 되어야 하는 상황이라고 가정하고 앞의 절차를 사용합니다. 이 절차 동안, Replica 1, Replica 2, Replica 3을 Source의 replica로 만들기 전에 Source에서 RESET BINARY LOGS AND GTIDS를 실행하는 것을 잊지 마십시오. 이 작업을 수행하지 않으면, replica가 Source를 사용할 수 없게 되기 이전 시점에 Web Client 애플리케이션에서 발생한 오래된 쓰기를 다시 가져오게 될 수 있습니다.

replica는, 동일한 source를 공유하더라도 서로 간에 동기화되지 않으며, 따라서 일부 replica는 다른 replica보다 상당히 앞서 있을 수 있다는 점을 알고 있어야 합니다. 이는 어떤 경우에는 앞의 예시에서 설명한 절차가 예상대로 동작하지 않을 수 있음을 의미합니다. 그러나 실제로는 모든 replica의 릴레이 로그가 서로 비교적 근접한 상태여야 합니다.

애플리케이션이 source의 위치를 인지하도록 유지하는 한 가지 방법은 source 호스트에 대해 동적 DNS 엔트리를 사용하는 것입니다. BIND를 사용하면, nsupdate를 이용해 DNS를 동적으로 업데이트할 수 있습니다.