다음 측면에서 우리는 일관성 없는 MySQL 마스터-슬레이브 복제 문제를 다룰 것입니다.

Mysql 마스터-슬레이브 구성을 설정할 때 마스터가 슬레이브와 동기화되거나 오류 또는 지연이 발생하는 경우가 종종 있습니다. 아래에서는 이러한 측면에 따라 오류를 해결할 수 있습니다.

소규모 웹사이트에서는 기본적으로 mysql 마스터-슬레이브 복제를 구성합니다. 한편, mysql 마스터-슬레이브는 데이터베이스 읽기와 쓰기를 분리하는 데 사용됩니다. mysql 자체는 그다지 강력하지 않습니다. 일반적으로 마스터-슬레이브 복제를 사용합니다. 아키텍처에서는 슬레이브에서 데이터 백업을 수행합니다.

MySQL 마스터-슬레이브 복제 프로세스에는 다소 마스터-슬레이브 동기화 상황이 있습니다. 이 기사에서는 데이터 마스터-슬레이브 동기화 상황을 간략하게 요약합니다. 데이터베이스 수준의 데이터베이스 불일치.
1. 네트워크 지연

mysql 마스터-슬레이브 복제는 binlog 기반의 비동기 복제이기 때문에 binlog 파일은 네트워크를 통해 전송됩니다. 물론 네트워크 지연은 마스터-슬레이브 동기화의 가장 큰 원인입니다. 전산실은 데이터 동기화 확률이 매우 높으므로 읽기와 쓰기를 분리하고 비즈니스 계층에서 초기 설계에 주의하십시오.

2. 마스터와 슬레이브 머신의 로드가 일치하지 않습니다

mysql 마스터-슬레이브 복제는 마스터 데이터베이스에서 1개의 io 스레드를 시작하고 위에서부터 1개의 sql 스레드와 1개의 io 스레드를 시작하기 때문에 머신 중 하나에서 로드가 매우 높고 너무 바빠서 결과적으로 스레드 중 하나에 리소스가 부족하고 마스터-슬레이브 불일치가 발생합니다.

3. Max_allowed_packet 설정이 일치하지 않습니다

마스터 데이터베이스에 설정된 max_allowed_packet이 슬레이브 데이터베이스의 설정보다 큽니다. 마스터 데이터베이스에서 대규모 SQL 문을 실행할 수 있는 경우 슬레이브 데이터베이스의 설정이 너무 작습니다. 실행될 수 없으므로 마스터 Never inconsistency가 발생합니다.

4. 키 자동 증가 키에서 시작하는 키 값과 자동 증가 단계 설정 간의 불일치로 인해 발생하는 마스터-슬레이브 불일치.

5. mysql이 비정상적으로 다운되었을 때 sync_binlog=1 또는 innodb_flush_log_at_trx_commit=1이 설정되지 않은 경우 binlog 또는 Relaylog 파일이 손상되어 마스터-슬레이브 불일치가 발생할 가능성이 매우 높습니다.

6. 마스터-슬레이브 동기화는 mysql 자체의 버그로 인해 발생합니다.

7. 버전이 일치하지 않습니다. 특히 상위 버전이 마스터이고 하위 버전이 슬레이브인 경우 마스터 데이터베이스에서 지원하는 기능이 슬레이브 데이터베이스에서 지원되지 않습니다.

위는 몇 가지 일반적인 마스터-슬레이브 동기화 상황입니다. 다른 동기화되지 않은 상황이 있을 수 있습니다. 발생한 마스터-슬레이브 불일치 상황에 대해 알려주십시오.

위 상황을 바탕으로 먼저 max_allowed_packet, 자동 증가 키 시작점 및 성장점 설정이 일치하는지 확인한 다음 성능의 일부를 희생하여 메인 서버에서 sync_binlog를 활성화하는 것이 좋습니다. innodb를 사용하는 라이브러리의 경우. 다음 내용을 구성하세요

1.innodb_flush_logs_at_trx_commit = 1
2.innodb-support_xa = 1 # Mysql 5.0 이상
3.innodb_safe_binlog​​​​​​​​​​ 환경에서 발생하는 문제에 대한 해결책.

관련 기사:

Mycat의 MySQL 마스터-슬레이브 복제 기반 읽기-쓰기 분리 예시

Docker를 사용하여 MySQL 마스터-슬레이브 복제 환경을 빠르게 구축하는 방법에 대한 자세한 내용

위 내용은 다음 측면에서 우리는 일관성 없는 MySQL 마스터-슬레이브 복제 문제를 다룰 것입니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!