19.5.4 Troubleshooting Replication

19.5.4 Troubleshooting Replication

지침을 모두 따랐는데도 replication 설정이 동작하지 않는다면, 가장 먼저 해야 할 일은 _에러 log에서 메시지를 확인하는 것_입니다. 많은 사용자가 문제를 겪은 직후에 이를 충분히 빨리 수행하지 않아 시간을 허비하곤 합니다.

에러 log만으로는 문제가 무엇인지 알 수 없다면, 다음 기법들을 시도해 보십시오:

• SHOW BINARY LOG STATUS statement를 실행하여 source에서 binary logging이 활성화되어 있는지 확인합니다. Binary logging은 기본적으로 활성화되어 있습니다. Binary logging이 활성화되어 있으면 Position이 0이 아닙니다. Binary logging이 활성화되어 있지 않다면, --skip-log-bin option과 같이 binary logging을 비활성화하는 설정으로 source를 실행하고 있지 않은지 확인하십시오.

• server_id system variable이 source와 replica 모두에서 startup 시에 설정되었는지, 그리고 각 server에서 ID 값이 고유한지 확인합니다.

• replica가 실행 중인지 확인합니다. SHOW REPLICA STATUS를 사용하여 Replica_IO_Running과 Replica_SQL_Running 값이 둘 다 Yes인지 확인합니다. 그렇지 않다면 replica server를 시작할 때 사용한 option들을 확인하십시오. 예를 들어, --skip-replica-start는 START REPLICA statement를 실행할 때까지 replication thread들이 시작되는 것을 막습니다.

• replica가 실행 중이라면, source에 대한 connection이 설정되었는지 확인합니다. SHOW PROCESSLIST를 사용하여 I/O (receiver) thread와 SQL (applier) thread를 찾고, 그들의 State column이 무엇을 표시하는지 확인합니다. Section 19.2.3, “Replication Threads”를 참조하십시오. Receiver thread state가 Connecting to master라고 표시한다면, 다음 항목들을 확인하십시오:

  • source에서 replication user의 privileges를 확인합니다.

  • source의 host name이 올바른지, 그리고 source에 연결하기 위해 올바른 port를 사용하고 있는지 확인합니다. Replication에 사용되는 port는 클라이언트 네트워크 통신에 사용되는 port와 동일합니다(기본값은 3306입니다). Host name의 경우, 그 이름이 올바른 IP address로 resolve되는지 확인합니다.

  • 설정 파일에서 skip_networking system variable이 source 또는 replica에서 네트워킹을 비활성화하도록 enable되어 있는지 확인합니다. 그렇다면, 이 설정을 주석 처리하거나 제거하십시오.

  • source에 firewall 또는 IP filtering configuration이 있는 경우, MySQL에 사용되는 네트워크 port가 filtering되고 있지 않은지 확인합니다.

  • ping 또는 traceroute/tracert를 사용하여 host에 도달할 수 있는지 확인해 source에 도달할 수 있는지 점검합니다.

• replica가 이전에는 실행 중이었지만 중지되었다면, 보통 그 이유는 source에서 성공한 어떤 statement가 replica에서 실패했기 때문입니다. Source의 적절한 스냅샷을 생성하고, replication thread 외부에서 replica의 데이터를 절대 수정하지 않았다면, 이런 일은 절대로 발생해서는 안 됩니다.

  Replica가 예기치 않게 중지된다면, 이는 bug이거나 Section 19.5.1, “Replication Features and Issues”에 설명된 알려진 replication 제한 사항 중 하나를 만난 것입니다. Bug인 경우에는 Section 19.5.5, “How to Report Replication Bugs or Problems”를 참조하여 이를 보고하는 방법에 대한 지침을 확인하십시오.

• Source에서 성공한 statement가 replica에서 실행되기를 거부한다면, replica의 데이터베이스들을 삭제하고 source에서 새 스냅샷을 복사해 오는 방식으로 전체 데이터베이스 재동기화를 수행하는 것이 현실적이지 않은 경우, 다음 절차를 시도해 보십시오:

1. Replica에서 영향을 받는 table이 source의 table과 다른지 확인합니다. 이러한 일이 어떻게 발생했는지 이해하려고 시도하십시오. 그런 다음 replica의 table을 source의 table과 동일하게 만들고 START REPLICA를 실행합니다.

2. 앞 단계가 작동하지 않거나 적용되지 않는다면, 수동으로 update를 수행하는 것이 (필요한 경우) 안전한지, 그리고 그 다음 source의 statement를 무시해도 되는지 이해하려고 시도하십시오.

3. Replica가 source의 다음 statement를 건너뛰어도 된다고 판단되면, 다음 statement들을 실행합니다:

1mysql> SET GLOBAL sql_replica_skip_counter = N;
2mysql> START REPLICA;

Source의 다음 statement가 AUTO_INCREMENT 또는 LAST_INSERT_ID()를 사용하지 않는다면 N 값은 1이어야 합니다. 그렇지 않다면 값은 2여야 합니다. AUTO_INCREMENT 또는 LAST_INSERT_ID()를 사용하는 statement의 경우 값 2를 사용하는 이유는, 그것들이 source의 binary log에서 두 개의 이벤트를 사용하기 때문입니다.

4. Replica가 처음에는 source와 완전히 동기화된 상태였고, replication thread 외부에서 관련 table이 아무도 update하지 않았다고 확신할 수 있다면, 그 차이는 아마도 bug의 결과일 것입니다. 최신 버전의 MySQL을 실행 중이라면, 이 문제를 보고해 주십시오. 이전 버전을 실행 중이라면, 최신 프로덕션 릴리스로 upgrade하여 문제가 계속되는지 확인해 보십시오.