MySQL 고가용성 아키텍처에서는 기본 데이터베이스 복제가 매우 일반적인 유형입니다.
기본 데이터베이스가 다운되면, 서비스 가용성을 보장하기 위해 슬레이브 데이터베이스를 새 기본 데이터베이스로 업그레이드할 수 있습니다. 동시에, 전체 클러스터의 QPS는 슬레이브 라이브러리를 확장함으로써 개선할 수 있습니다.
마스터-슬레이브 복제 아키텍처 하에서 MySQL은 마스터-슬레이브 데이터 일관성을 위해 binlog를 사용합니다.
위 그림에서 보듯이, MySQL 마스터-슬레이브 복제는 주로 다음과 같은 단계로 구성됩니다
1. 이진 로그에 변경 사항을 마스터 로그합니다
2. 슬레이브 io_thread 메인 라이브러리의 빈로그를 요청하여 생성된 빈로그 로그를 릴레이 로그에 기록합니다
3. 슬레이브 sql_thread 릴레이 로그에서 이벤트를 다시 진행
MySQL 마스터-슬레이브 복제의 링크 역할 외에도 binlog는 다른 목적도 수행합니다. 예를 들면:
1. mysqlbinlog 도구를 사용해 binlog 파일을 파싱하여 시점 데이터베이스 복구를 수행합니다.
2. binlog 이벤트를 기반으로 한 데이터베이스 플래시백 (MariaDB는 플래시백에 mysqlbinlog를 직접 사용할 수 있음)
3. Github의 오픈소스 온라인 테이블 변경 도구 gh-ost도 binlog를 통해 구현됩니다
4. 빈로그를 파싱하여 점진적으로 구독하고 소비할 수도 있습니다
Binlog는 매우 유용하지만, 일상적인 운영 및 유지보수 과정에서 몇 가지 문제를 겪는 것은 불가피합니다. 여기 빈로그 관련 오류들이 있습니다.
자주 묻는 질문 중 하나입니다
현상
mysqlbinlog5.5가 mysql5.7을 파싱하는데, binlog 파일이 나타납니다
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
원인 분석
MySQL 5.6과 기타 고급 버전의 binlog 파일에서는 GTID 이벤트와 같은 새로운 binlog 이벤트가 추가되었습니다.
MySQL5.5의 MySQLbinlog는 이러한 binlog 이벤트를 인식하지 못합니다.
우회 방법
상위 버전의 mysqlbinlog를 사용해 하위 버전에서 생성된 binlog를 해결하세요
자주 묻는 질문 2
현상
건강한 MySQL 서버에서 슬레이브 상태 표시
Last_SQL_Error:릴레이 로그 읽기 실패: 릴레이 로그 이벤트 항목을 파싱할 수 없습니다.
가능한 이유는 다음과 같습니다: 마스터의 바이너리 로그가 손상되었고(이진 로그에 'mysqlbinlog'를 실행해 확인할 수 있습니다),
슬레이브의 릴레이 로그가 손상되어 있습니다(릴레이 로그에서 'mysqlbinlog'를 실행하면 확인할 수 있습니다).
네트워크 문제나 마스터 또는 슬레이브 MySQL 코드의 버그일 수도 있습니다.
마스터의 바이너리 로그나 슬레이브 릴레이 로그를 확인하고 싶다면,
이 슬레이브에 'SHOW SLAVE STATUS'를 발급하면 그들의 이름을 알 수 있습니다.
원인 분석
릴레이 로그의 항목은 마스터 라이브러리의 빈로그 오류, 슬레이 라이브러리의 릴레이 로그 오류, 네트워크 문제 및 버그로 인해 읽을 수 없습니다. 보통 네트워크 장애나 슬레이브 라이브러리에 과도한 압력이 가해져 잘못된 릴레이 로그 형식이 발생하여 발생합니다.
우회 방법
현재 동기화 시점을 찾고 마스터-슬레이브 동기화를 초기화하면 새로운 릴레이 로그가 생성되고 마스터-슬레이브 동기화가 복원됩니다.
"show slave status\G" 출력에서 다음 정보를 찾을 수 있습니다:
Relay_Master_Log_File: mysql-bin.002540 // 슬레이브 라이브러리가 읽는 마스터 binlogExec_Master_Log_Pos: 950583017 // 슬레이브에서 실행된 위치 위치 지점
슬레이브를 멈추고 슬레이브가 읽은 빈로그 파일과 실행된 위치에서 동기화를 다시 설정하세요.
Relay_Master_Log_File: mysql-bin.002540 // 슬레이브 라이브러리가 읽는 마스터 binlogExec_Master_Log_Pos: 950583017 // 슬레이브에서 실행된 위치 위치 지점
자주 묻는 질문 3
현상
다운타임 후 슬레이브 상태 표시 복원:
Last_SQL_Error: 릴레이 로그 위치 초기화 오류: 이진 로그에서 헤더를 읽는 I/O 오류
Last_SQL_Error: 릴레이 로그 위치 초기화 오류: Binlog의 매직 넘버가 잘못됨; 이 MySQL 버전에서 사용할 수 있는 이진 로그 파일이 아닙니다
원인 분석
전원 차단, 메인보드 타버링 등, 또는 불법 종료로 인한 릴레이 빈 파일 손상 등의 다운타임
우회 방법
같은 질문 두 번째.
relay_log_recovery = 1도 설정할 수 있습니다.
슬레이브가 라이브러리에서 내려가면, 릴레이 로그가 손상되어 일부 로그가 처리되지 않으면 릴레이 로그가 자동으로 포기되고 로그가 마스터에서 다시 가져와 릴레이 로그 복구가 완료됩니다.
자주 묻는 질문 4
현상
라이브러리 머신에서 재부팅이 중단된 후 마스터를 변경할 때 나타납니다
오류 (코드 1201): 마스터 정보 구조를 초기화할 수 없음; 더 많은 오류 메시지는 MySQL 오류 로그에서 확인할 수 있습니다
또는
오류 1872 (HY000): 슬레이브가 저장소에서 릴레이 로그 정보 구조를 초기화하지 못했습니다
원인 분석
전원 차단, 메인보드 타버림 등, 불법 종료로 인해 master.info 또는 realy-log.info 파일이 손상되는 등의 다운타임 등이 발생했습니다
우회 방법
슬레이브> 슬레이브 모두 초기화하고, 마스터를 다음으로 변경하세요
예방 조치
프로필 설정
relay_log_info_repository=테이블
master_info_repository=테이블
MySQL 5.6.5 mysql.slave_master_info 및 mysql.slave_relay_log_info의 스토리지 엔진은 기본적으로 MyISAM으로 설정되어 있으니, InnoDB의 스토리지 엔진으로 변경해야 합니다
ALTER 테이블 mysql.slave_master_info 엔진=InnoDB;
ALTER 테이블 mysql.slave_relay_log_info 엔진=INNODB;
mysql.slave_master_info 표는 sync_master_info 이벤트 후에 업데이트됩니다.
mysql.slave_relay_log_info 테이블은 각 트랜잭션 커밋마다 업데이트됩니다.
자주 묻는 질문 5
현상
마스터 슬레이브는 원래 문장으로 binlog_format binlog_format, 메인 데이터베이스를 행으로 변경한 후 라이브러리에서 슬레이브 상태 표시가 나타납니다:
Last_Error: 실행 오류 실행 행 이벤트: '실행 불가: 명령문이 행 형식이고 BINLOG_FORMAT = 진술이기 때문에 이진 로그에 쓰는 것이 불가능하다.'
원인 분석
주요 데이터베이스 binlog_format가 행이고 슬레이브 라이브러리 binlog_format 문장일 때, 위의 오류가 나타납니다.
하지만 메인 라이브러리는 진술binlog_format, 슬레이브 라이브러리는 binlog_format 행입니다;
또는 메인 데이터베이스 binlog_format가 행이라면, 데이터베이스 binlog_format가 혼합되어 있으면 오류가 보고되지 않습니다.
만약 당신의 SQL 스레드가 실제로 다음과 같이 구성되어 있다면요.
binlog_format=STATEMENT는 ROW 이벤트를 받으면 중단됩니다. 그
그 이유는 STATEMENTformat(때로는 ROW 주입이라고 부르기도 함)으로 해당 ROW 이벤트를 로그할 수 없기 때문입니다.
BINLOG 문이나 슬레이브의 SQL 스레드가 실행하는 ROW 이벤트)
자세한 이유 참고:https://bugs.mysql.com/bug.php?id=69095
우회 방법
노예> 노예 멈춰라;
SLAVE> 전 세계 binlog_format=혼합;
SLAVE> 시작은 SLAVE;
자주 묻는 질문 6번
현상
mysql5.6을 mysql5.5와 동기화할 때 발생한 오류
Last_IO_Error: 이진 로그에서 데이터를 읽을 때 마스터로부터 치명적인 오류 1236이 발생했습니다: '슬레이브는 마스터가 로그하도록 설정된 체크섬으로 복제 이벤트를 처리할 수 없습니다; 첫 번째 이벤트 'mysql-bin.000001'은 4에서, 마지막 이벤트는 'mysql-bin.000001'에서 120에서 읽었고, 마지막 바이트는 'mysql-bin.000001'에서 120에서 읽혔습니다.
원인 분석
주 서버에서 실행되는 SQL 문이 소프트웨어, 하드웨어 또는 네트워크 전송 오류로 인해 서버에서 실행되는 SQL 문과 불일치하는 문제(이벤트 손상)를 해결하기 위해 MySQL 5.6은 복제 이벤트 체크섬 기능을 추가합니다. 이벤트가 이진 로그에 기록되면 체크섬도 이진 로그에 기록되고, 이벤트가 네트워크를 통해 슬레이브에게 전송된 후 슬레이브에서 검증되어 슬레이브의 릴레이 로그에 기록됩니다. 각 단계마다 이벤트와 체크섬이 기록되기 때문에 문제를 빠르게 파악할 수 있습니다.
mysql5.6.5 및 이후 버전에서는 기본 값이 crc32 binlog_checksum,
이전 버전의 기본 값binlog_checksum 00이었습니다
용액
Slave> set global binlog_checksum=none
자주 묻는 질문 7
현상
디스크가 가득 찼을 때, binlog 파일과 mysql-bin.index 파일을 수동으로 정리하세요
이진 로그는 비어 있지만, 마스터 상태는 정상입니다.
mysql> 이진 로그 표시; Empty set (0.00 sec)mysql> show master status;
+------------------+-----------+--------------+------------------+
| 파일 | 위치 | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
원인 분석
mysql-bin.index 파일을 확인한 후 첫 번째 빈 줄을 찾았습니다.
mysql 소스 코드 rpl_master.cc:show_binlogs()에서 다음 코드를 찾을 수 있습니다:
/* The file ends with EOF or empty line */
반면 ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
빈 줄은 문서의 끝으로 간주됩니다
(참고문헌.)https://yq.aliyun.com/articles/213657기사)
예방 조치
binlog를 수동으로 삭제하지 말고, mysql-bin.index 파일을 직접 편집하지 마세요. 무엇을 하는지 잘 모른다면 그렇지 않으면 스스로 지뢰를 놓는 셈이 될 수 있습니다!
요약
DBA는 MySQL 새 버전마다 binlog 개선점(예: 버전 5.6에 추가된 gtid 기능, 버전 5.7의 향상된 멀티스레드 슬레이브)에 주목하고, 각 매개변수의 의미를 상세히 이해하여 오류를 발견하고 문제를 쉽게 해결할 수 있어야 합니다.
|
게시됨 2018. 9. 25. 오전 10:31:40
|
|
|
|
