17.4.5 복제 버그 또는 문제를보고하는 방법
관련된 사용자 오류는 없다고 판단하더라도, 여전히 복제가 전혀 작동하지 않거나 불안정하면 버그 리포트를 보내시기입니다. 버그를 찾아 내기 위해 가능한 한 많은 정보를 사용자로부터 입수해야합니다. 좋은 버그 보고서를 준비하기 위해 어느 정도의 시간과 노력을 투자 주시기를 부탁드립니다.
그 버그를 명확하게 나타내는 재현 가능한 테스트 케이스가 있다면, 섹션 1.7 "질문이나 버그를보고하는 방법" 에서 설명하는 절차를 사용하여 오라클의 버그 데이터베이스에 입력 해 주시기를 부탁드립니다. "유령"문제 (뜻대로 재현 할 수없는 것)의 경우 다음 단계를 사용하십시오.
사용자 오류가 관계하고 있지 않은지 확인합니다. 예를 들어, 슬레이브 쓰레드 이외의 장소에서 노예를 업데이트하면 데이터가 동기화를 잃고 갱신 할 때 고유 키 위반이 발생할 수 있습니다. 이 경우 슬레이브 쓰레드가 중지되고 사용자가 수동으로 테이블을 정리하고 동기화 된 상태로 되돌릴 때까지 기다립니다. 이것은 복제의 문제가 아닙니다. 외부 간섭의 문제에서 복제가 실패합니다.
--log-slave-updates및--log-bin옵션으로 슬레이브를 실행합니다. 이 옵션은 슬레이브는 마스터로부터받은 업데이트 로그를 그 자체의 바이너리 로그에 기록합니다.복제 상태를 재설정하기 전에 모든 증거를 저장합니다. 정보가 없거나 불완전한 정보 밖에 없거나하면 오라클은 문제를 파악하기가 어렵거나 불가능합니다. 수집해야 할 증거 :
마스터에서 모든 바이너리 로그 파일
슬레이브에서 모든 바이너리 로그 파일
문제를 발견 한 시점의 마스터에서
SHOW MASTER STATUS출력문제를 발견 한 시점의 노예에서
SHOW SLAVE STATUS출력마스터 및 슬레이브에서의 오류 로그
mysqlbinlog를 사용하여 바이너리 로그를 확인합니다. 다음 것은 문제의 문을 찾는 데 도움이됩니다.
log_file및log_pos은SHOW SLAVE STATUS에서Master_Log_File및Read_Master_Log_Pos입니다.shell>
mysqlbinlog --start-position=log_poslog_file| head
문제의 증거를 수집 한 후에는 먼저 그들을 개별 테스트 케이스로 분리 해보십시오. 게다가, 섹션 1.7 "질문이나 버그를보고하는 방법" 의 지침을 사용하여 문제 및 가능한 한 많은 정보를 오라클의 버그 데이터베이스에 입력하십시오.