1. 문제 배경
2월 27일 이른 아침, 프로덕션 환경의 MySQL 스탠바이 데이터베이스에서 FLUSH TABLES WITH READ LOCK이 해제되지 않아 스탠바이 데이터베이스의 복제 지연이 증가하는 현상이 발생했습니다. 거의 25분 동안 공개됐다.
버전:
- MySQL 5.7.21
- PXB 2.4.18
느린 쿼리 로그:
백업 스크립트의 백업 명령:
mysql_kill.sh의 주요 논리적 내용은 다음과 같습니다.
백업 매개변수:
2. 문제 재발 및 분석
2.1 문제 분석
- 144는 SQL 스레드, 병렬 복제의 코디네이터 스레드입니다.
- 145/146은 병렬 복제를 위한 작업자 스레드로, 145/146 작업자 스레드 큐의 트랜잭션을 병렬로 실행할 수 있습니다.
- 스레드 162는 innobackup에 의해 실행된 읽기 잠금으로 테이블을 플러시하는 데 사용됩니다.
144 코디네이터 스레드가 릴레이 로그에 트랜잭션을 배포했을 때 해당 트랜잭션을 실행할 수 없고 이전 트랜잭션이 제출을 완료할 때까지 기다려야 했기 때문에 종속 트랜잭션이 커밋되기를 기다리는 상태였습니다. 스레드 145/146 및 백업 스레드 162는 교착 상태를 형성합니다. 스레드 145는 스레드 162의 전역 읽기 잠금이 해제될 때까지 기다립니다. 스레드 162는 전역 커밋 잠금을 적용할 때 차단됩니다. 스레드 146은 MDL을 차지합니다. :: 커밋 잠금은 슬레이브 라이브러리가 슬레이브 라이브러리의 binlog 제출 순서를 보장하기 위해slave_preserve_commit_order=1로 설정하고 146 스레드 실행 트랜잭션에 해당하는 binlog가 뒤에 있기 때문입니다. 145의 거래가 제출을 기다리고 있습니다. 마지막으로 145->162->146->145의 무한 루프가 형성되어 교착 상태가 발생합니다.
세 개의 스레드가 서로 교착 상태를 형성하는 경우는 여전히 드뭅니다.
2.2 관련 매개변수가 적용되지 않는 이유
--ftwrl-wait-timeout =60은 FTWRL을 실행하기 전에 긴 SQL이 감지되면 지정된 시간(초) 동안 대기한다는 의미입니다. 시간 초과 후에도 여전히 긴 SQL이 있으면 백업이 오류와 함께 종료됩니다. 기본값은 0이며 즉시 실행을 의미합니다.
--ftwrl-wait-threshold =5는 FTWRL을 실행하기 전에 긴 SQL을 탐지하는 방법을 의미합니다. 플러시를 실행하기 전에 지정된 시간(초) 이상 실행된 SQL이 있는 경우 해당 SQL을 긴 SQL로 정의합니다. SQL. 기본값은 60입니다.
--kill-long-queries_timeout=0 FTWRL을 실행한 후 플러시 작업이 N초 동안 차단되면 이를 차단하는 스레드가 종료됩니다. 기본 설정인 0은 플러시가 실행될 때까지 SQL 차단 플러시가 종료되지 않음을 의미합니다. SQL이 완료되었습니다.
위의 각 매개변수에 대한 설명에서 --ftwrl-wait-* 매개변수는 FTWRL이 실행되기 전의 긴 SQL 감지 메커니즘을 위한 것이며 FTWRL이 실행될 때 도움이 되지 않는다는 것을 쉽게 알 수 있습니다. -long-* 매개변수는 기본값을 0으로 설정하며 효과가 없습니다.
3. 결론 및 제안
- PXB 백업에서 FTWRL을 실행하여 전역 읽기 잠금을 추가하고 SQL 스레드에 교착 상태를 일으키는 것은 이번에 슬레이브 데이터베이스 지연이 너무 높은 이유입니다.
- 활성화
--kill-long-queries\_type및--kill-long-queries\_timeout매개 변수는 플러시가 차단되었음을 감지한 후 해당 스레드를 종료하는 작업을 실행합니다. 백업 데이터베이스에 대한 비즈니스 액세스가 없는 경우 이는 더 폭력적이고 더 큰 위험을 수반합니다. --safe-slave-backup교착 상태를 방지하기 위해 백업을 수행할 때 SQL 스레드를 중지하는 매개변수를 활성화합니다 . 비즈니스 액세스 권한이 없는 대기 데이터베이스에서만 실행하는 것이 좋습니다.- MySQL 매개변수를 설정하고
slave\_preserve\_commit\_order=0슬레이브 데이터베이스에서 binlog의 순차적 제출을 끄면 이 매개변수를 끄면 슬레이브 데이터베이스의 병렬 복제 트랜잭션의 제출 순서에만 영향을 미치며 최종 데이터 일관성에는 영향을 미치지 않습니다. 특별한 요구 사항이 있는 경우 슬레이브 데이터베이스의 binlog 순서는 기본 라이브러리와 일치해야 하며slave\_preserve\_commit\_order=0교착 상태를 피하기 위해 설정을 고려할 수 있습니다.
GreatSQL을 즐겨보세요 :)
GreatSQL 소개
GreatSQL은 금융 수준의 애플리케이션에 적합한 국내 독립 오픈소스 데이터베이스로, 고성능, 높은 신뢰성, 높은 사용 편의성, 높은 보안성 등 많은 핵심 기능을 갖추고 있으며 MySQL 또는 Percona Server를 대체하여 사용할 수 있습니다. 온라인 생산 환경에서 사용되며 완전 무료이며 MySQL 또는 Percona Server와 호환됩니다.
관련 링크: GreatSQL 커뮤니티 Gitee GitHub Bilibili
GreatSQL 커뮤니티:
커뮤니티 보상 제안 및 피드백: https://greatsql.cn/thread-54-1-1.html
커뮤니티 블로그 수상작 제출 세부정보: https://greatsql.cn/thread-100-1-1.html
(기사에 대해 궁금한 점이 있거나 남다른 통찰력이 있다면 공식 커뮤니티 홈페이지에 가서 질문하거나 공유해 보세요~)
기술교류그룹:
위챗 & QQ 그룹:
QQ 그룹: 533341697
WeChat 그룹: GreatSQL 커뮤니티 도우미(WeChat ID: wanlidbc)를 친구로 추가하고 커뮤니티 도우미가 귀하를 그룹에 추가할 때까지 기다립니다.