VPN이 끊긴 뒤의 MySQL 복제: 먼저 두 단계를 읽으세요

VPN이 끊기면 복제 모니터링이 빨갛게 변하고, 본능적으로 위치를 초기화하고 싶어진다. 그 본능이 네트워크 중단을 데이터 문제로 만든다. 끊긴 경로는 복제본이 무엇을 받았는지 또는 적용했는지에 대해 아무것도 말해 주지 않으며, 그것은 두 상태를 가진 두 단계다. 무엇이든 바꾸기 전에 둘을 따로 읽어야 한다.

두 단계, 두 개의 별도 답

일반적인 비동기 복제본은 두 가지 일을 한다. 수신기는 소스에 연결해 이벤트를 가져와 로컬의 릴레이 로그에 기록한다. 적용기는 그 로그를 읽고 이벤트를 복제본에서 실행한다. 경로가 끊기면 수신기는 즉시 멈추지만, 적용기는 이미 디스크에 있는 밀린 작업을 계속 처리한다. 따라서 한 번의 장애는 연결이 돌아왔는가, 그리고 쌓인 작업이 적용되었는가라는 두 가지 다른 질문을 만든다. 둘을 하나의 질문으로 다루면 두 상태가 평균되어 오해를 부르는 답이 된다.

수신기가 복구되었다는 것은 경로가 살아 있다는 뜻이다. 적용기가 얼마나 뒤처졌는지, 또는 연결이 끊긴 동안 오류를 만났는지에 대해서는 아무것도 말하지 않는다.

올바른 문장으로 채널을 읽으세요

MySQL 8.4에서 SHOW REPLICA STATUS 는 구성된 채널마다 한 행을 반환하므로, 목록의 첫 행이 아니라 의도한 채널의 행을 읽어야 한다. Replica_IO_Running 는 연결된 수신기와 연결 중이거나 멈춘 수신기를 구분하고, Replica_SQL_Running 는 적용기를 설명한다. 다시 연결했다가 곧바로 실패하는 수신기는 어떤 상태 플래그도 보여 주지 않는 메시지를 남기므로, 그 옆의 오류 열도 함께 읽어야 한다. 오래된 릴리스는 다른 열 이름을 쓰므로 명령 이름만 바꿔서 옛 방법을 번역해서는 안 된다.

소스의 정체성과 구성된 필터도 확인해야 한다. 잘못된 소스를 가리키거나 생각보다 좁게 필터된 복제본은 기대와 다른 것을 복제하면서도 건강하다고 보고한다.

지연 영이라는 숫자가 거짓말할 수 있는 이유

지연 값은 마지막으로 적용된 이벤트의 타임스탬프를 현재 시각과 비교한다. 수신기가 한 시간 동안 멈춰 있었다면 적용기는 밀린 작업을 처리해 받은 것의 끝에 도달할 수 있고, 그때 숫자는 영으로 떨어지지만 복제본은 소스보다 한 시간 뒤처져 있다. 이 지표는 적용기의 대기열을 측정할 뿐, 복제본의 최신성을 측정하지 않는다.

대신 실행된 트랜잭션을 소스가 보유한 것과 비교해야 한다. 그 비교는 멈춘 수신기에도 견딘다.

실제 복구 가능 구간은 보존 설정이 정한다

따라잡으려면 소스가 복제본에 필요한 트랜잭션을 아직 보관하고 있어야 한다. 그것이 정리되면 복제본은 가져올 수 없고, 아무리 다시 연결해도 달라지지 않는다.

GTID 자동 위치 지정에서는 복제본이 소스가 더 이상 보관하지 않는 이력을 요구하고 계속 진행하기를 거부하므로 실패가 분명하다. 그때 선택지는 아직 가지고 있는 소스에서 빠진 이벤트를 얻거나, 백업에서 다시 구축해 따라잡게 하는 것이다. 간격을 건너뛰는 것은 따라잡는 것이 아니며, 데이터가 조용히 불완전한 복제본을 남긴다. 예상 장애 시간과 소스의 바이너리 로그 보존, 변경률이라는 그 세 숫자가 장애를 복구할 수 있는지 자체를 결정하므로, 그것들을 비교해 구간을 계획해야 한다.

지표의 색이 아니라 따라잡았는지를 검증하세요

이름 확인과 전송 보안을 포함해 경로를 복구하고, 기존 채널이 자체 정책에 따라 다시 연결되는지 지켜본다. 개입하기 전에 정해진 간격을 주고, 그 간격의 양 끝에서 수신과 적용 진행 상황을 기록한다. 다시 시작한 채널과 최신 상태인 채널은 다른 발견이다.

옛 밀린 작업의 끝이 아니라 적용기가 소스의 현재 위치에 도달했는지 확인해야 한다. 실패한 이벤트 하나가 진행을 멈추는데도 수신기는 계속 연결되어 있다고 보고하므로, 적용기에 오류가 대기하고 있지 않은지도 확인해야 한다. 그다음 채널 이름, 두 단계의 상태, 실행된 위치, 시각이라는 증거를 기록한다. 초록 지표는 주장이고, 위치는 사실이다.