mysql replication relay log relay-bin.999999 bug

mysql 리플리케이션 운영중 슬레이브 서버에 문제가 발생

 

mysql 리플리케이션 구동방식이

 

데이터 업데이트 > master에서 업데이트된 쿼리를 bin로그에 기록 > slave의 io쓰레드에서 bin log를 토대로 relay  로그를 작성 > sql쓰레드에서 relay 로그를 토대로 slave의 DB 업데이트 > relay 로그 쓸모가 없어지면(master의 bin log가 삭제되면) relay 퍼지 옵션 디폴트가 on이기 때문에 자동으로 삭제됨

 

근데... slave서버에서 상태를 보면 

                Relay_Log_File: localhost-relay-bin.999999

위와같이 릴레이 로그-999999 를 보고 있따. 

[root@localhost data]# ls -lat localhost-relay-bin.11* | more
-rw-rw---- 1 mysql mysql  2891938 May  3 09:35 localhost-relay-bin.1157093

실제로는 위 파일을 바라봐야 한다.

 

order by limit 1 주고 계속 확인해보면 다행히도 실시간으로 동기화는 잘 되고 있다..
select count(*) from table 같은걸로 레코드 수 새보면 좋겠찌만... 실서비스중인데 부하 생길포인트 만드는건 쫌 아닌것같다.

 

여튼 상황 정리하면 아래와 같다.
1.디비 동기화는 잘 되고 있음
2.마스터 서버의 bin 로그는 잘 삭제되고 있음
3.슬레이브 서버의 relay bin 로그를 999999를 바라보고 있음
ㄴ실제로는 1157093 을 봐야함

4.relay 로그 삭제가 안되고 있음
5.error log는 없음

 

inc_group_relay_log_pos() 이 함수에 문제가 있다고 한다.
strcmp() 라는 함수를 통해 전/후 두개의 relay log를 비교하는데 이때 둘다 6자리까지는 정상적으로 비교가 되는데 6자리에서 7자리로 바뀔 때 즉, 999999 => 1000000 이때 문제가 있다고 한다.

추가로 handle_queued_pos_update() 라는 함수에서도 7자리로 변경될 때 parallel replication 이슈가 발생할 수 있다고 한다.

https://jira.mariadb.org/browse/MDEV-8134

 

패치는 뭐... 재컴파일하기엔 좀 무리가 있으니... 일단 relaylog 전부 reset으로 날리고 다시 맞춰준다음 relay log 용량을 10M(디폴트)에서 512M로 바꿔야겠다. 그럼 그렇게 많이 차진 않겠찌...
그래도 많이 차면 패치하고 재컴파일 해야할듯

 

----조치 한 사항---

1.우선 데이터 백업 한번 해주고

2.새벽에(접속자 최대한 없을 때)웹페이지 공지 띄우고 디비서버로의 접근 차단(마스터 서버 업데이트 없도록)
ㄴiptables 에서 마스터-슬레이브만 3306 포트 통신하도록 변경하고 나머지는 전체 차단, 웹에서도 차단
ㄴ마스터서버 binlog 파일 넘버랑 로그 포지션 안바뀌는거 확인

3.stop slave

4.reset slave
ㄴreset slave 하니까 삭제되지 않던 relay log 파일도 전부 삭제됨

5.start slave

6.CHANGE MASTER TO MASTER_LOG_FILE='<master-bin.number>', MASTER_LOG_POS=;

7.위와같이 작업하고 bin 로그파일 넘버랑 로그 포지션 넘버 동일한지 확인

 

위와같이 슬레이브 서버들 전부 진행하니까 잘 해결됐다.

추가로 10MB씩 쌓이던 relay 로그 파일 512MB로 변경함