19.5.5 How to Report Replication Bugs or Problems

19.5.5 Replication Bugs 또는 문제를 보고하는 방법

사용자 오류가 개입되지 않았음을 확인했는데도 Replication이 전혀 동작하지 않거나 불안정하다면, 이제 우리에게 버그 리포트를 보낼 때입니다. 버그를 추적하기 위해서는 여러분으로부터 가능한 한 많은 정보를 얻어야 합니다. 좋은 버그 리포트를 준비하는 데 약간의 시간과 노력을 들이시기 바랍니다.

버그를 재현할 수 있는 테스트 케이스가 있다면, Section 1.6, “How to Report Bugs or Problems”에 제시된 지침에 따라 우리의 버그 데이터베이스에 입력해 주십시오. 마음대로 재현할 수 없는 “phantom” problem(임의로 중복해서 발생시키기 어려운 문제)이 있는 경우에는, 다음 절차를 사용하십시오:

1. 사용자 오류가 개입되지 않았음을 확인하십시오. 예를 들어, Replication 스레드 외부에서 replica를 업데이트하면 데이터가 비동기화되고, 업데이트 시 고유 키 위반이 발생할 수 있습니다. 이 경우 Replication 스레드는 중지하고, 테이블을 수동으로 정리하여 동기화를 맞출 때까지 기다립니다. 이는 replication problem이 아닙니다. 이는 외부 간섭으로 인해 replication이 실패한 문제입니다.

2. replica가 바이너리 로깅이 활성화된 상태(log_bin 시스템 변수)를 사용하고 있으며, source로부터 수신한 업데이트를 자체 바이너리 로그에 기록하게 하는 --log-replica-updates 옵션이 활성화되어 있는지 확인하십시오. 이 설정들은 기본값입니다.

3. Replication 상태를 리셋하기 전에 모든 증거를 저장하십시오. 정보가 없거나 대략적인 정보만 있는 경우, 문제를 추적하는 것이 어렵거나 불가능해집니다. 수집해야 할 증거는 다음과 같습니다:

   • source의 모든 바이너리 로그 파일

   • replica의 모든 바이너리 로그 파일

   • 문제가 발견된 시점의 source에서 실행한 SHOW BINARY LOG STATUS의 output

   • 문제가 발견된 시점의 replica에서 실행한 SHOW REPLICA STATUS의 output

   • source와 replica의 에러 로그

4. mysqlbinlog을 사용하여 바이너리 로그를 검사하십시오. 다음 내용은 문제 statement를 찾는 데 도움이 됩니다. log_file 및 _log_pos_는 SHOW REPLICA STATUS에서 가져온 Master_Log_File 및 Read_Master_Log_Pos 값입니다.

1$> mysqlbinlog --start-position=log_pos log_file | head

문제에 대한 증거를 모두 수집한 후, 먼저 이를 별도의 테스트 케이스로 분리하여 격리해 보십시오. 그런 다음 Section 1.6, “How to Report Bugs or Problems”의 지침에 따라 가능한 한 많은 정보를 포함하여 우리의 버그 데이터베이스에 문제를 입력하십시오.