MySQL의 마스터-슬레이브 데이터베이스 동기화 지연 문제 해결

최근에 MySQL 마스터-슬레이브 데이터베이스 동기화 테스트를 하다가 몇 가지 문제점을 발견했는데, 그중 마스터-슬레이브 동기화 지연 문제가 그중 하나입니다. 다음 내용은 인터넷에서 찾은 설명 중 일부입니다.

MySQL 마스터-슬레이브 동기화 다음과 같은 장점이 있는 매우 성숙한 아키텍처입니다. ① 쿼리 작업을 슬레이브 서버에서 수행할 수 있어(즉, 흔히 읽기 기능이라고 함) 마스터 서버에 대한 부담을 줄일 수 있습니다. 백업 기간 동안 마스터 서버 서비스에 영향을 주지 않도록 슬레이브 마스터 서버에서 수행됩니다. ③ 마스터 서버에 문제가 있는 경우 슬레이브 서버로 전환할 수 있습니다.

이러한 이점은 이미 다들 잘 알고 계시리라 생각하며, 이 솔루션은 프로젝트 배포에도 사용됩니다. 그런데 MySQL의 마스터-슬레이브 동기화에는 항상 슬레이브 데이터베이스 지연 문제가 있었는데, 이런 문제는 왜 발생하는 걸까요? 이 문제를 해결하는 방법?

1. MySQL 데이터베이스 마스터-슬레이브 동기화 지연 원리.

2. MySQL 데이터베이스에서 마스터-슬레이브 동기화 지연은 어떻게 발생합니까?

3. MySQL 데이터베이스 마스터-슬레이브 동기화 지연 솔루션.

1. MySQL 데이터베이스 마스터-슬레이브 동기화 지연 원리.

답변: MySQL 데이터베이스의 마스터-슬레이브 동기화 지연 원리에 대해 이야기할 때 mysql 데이터베이스 마스터-슬레이브 복제의 원리부터 시작해야 합니다. Mysql의 마스터-슬레이브 복제는 기본 데이터베이스가 생성하는 작업입니다. binlog는 순차적으로 작성되기 때문에 효율성이 매우 높습니다. 슬레이브의 Slave_IO_Running 스레드가 로그를 가져오기 위해 메인 라이브러리로 이동하는데, 다음 단계가 매우 효율적입니다. 슬레이브의 Slave_SQL_Running 스레드는 슬레이브에서 기본 라이브러리의 DDL 및 DML 작업을 구현합니다. DML 및 DDL의 IO 작업은 순차적이 아닌 무작위이며 비용이 훨씬 높습니다. 슬레이브에 대한 다른 쿼리도 잠금 경합을 일으킬 수 있습니다. Slave_SQL_Running도 단일 스레드이므로 DDL 카드 마스터를 실행하는 데 10분이 걸립니다. 그러면 모든 후속 DDL은 계속하기 전에 이 DDL이 실행될 때까지 기다리므로 지연이 발생합니다. 어떤 친구들은 "메인 라이브러리의 동일한 DDL도 10분 동안 실행해야 합니다. 슬레이브가 지연되는 이유는 무엇입니까?"라고 묻습니다. 대답은 마스터는 동시에 실행할 수 있지만 Slave_SQL_Running 스레드는 실행할 수 없다는 것입니다.

2. MySQL 데이터베이스에서 마스터-슬레이브 동기화 지연은 어떻게 발생합니까?

답변: 메인 라이브러리의 TPS 동시성이 높을 때 생성된 DDL 수가 슬레이브의 SQL 스레드 하나가 감당할 수 있는 범위를 초과하여 지연이 발생합니다. 물론 잠금 대기로 인해 발생할 수도 있습니다. 슬레이브의 대형 쿼리문.

3. MySQL 데이터베이스 마스터-슬레이브 동기화 지연 솔루션

답변: 슬레이브 동기화 지연을 줄이는 가장 간단한 솔루션은 아키텍처를 최적화하고 기본 데이터베이스의 DDL이 빠르게 실행되도록 노력하는 것입니다. 또한 메인 라이브러리가 sync_binlog=1, innodb_flush_log_at_trx_commit = 1 및 기타 설정과 같이 높은 데이터 보안을 갖고 있다는 사실도 있습니다. 슬레이브에는 이러한 높은 데이터 보안이 필요하지 않습니다. sync_binlog를 0으로 설정하거나 binlog를 끌 수 있습니다. . innodb_flushlog를 0으로 설정하여 SQL 실행 효율성을 높일 수도 있습니다. 다른 하나는 메인 라이브러리보다 좋은 하드웨어 장치를 슬레이브로 사용하는 것입니다.

mysql-5.6.3은 이미 다중 스레드 마스터-슬레이브 복제를 지원합니다. 원칙은 Ding Qi가 테이블을 다중 스레드로 사용하는 반면 Oracle은 데이터베이스(스키마)를 다중 스레드를 수행하는 단위로 사용하는 것과 유사합니다.

sync_binlog=1

이렇게 하면 MySQL은 트랜잭션을 커밋할 때마다 바이너리 로그의 내용을 디스크에 동기화합니다.

기본적으로 binlog는 기록될 때마다 하드 디스크와 동기화되지 않습니다. 따라서 운영 체제나 시스템(MySQL 서버뿐만 아니라)이 충돌하는 경우 binlog의 마지막 명령문이 손실될 수 있습니다. 이를 방지하려면 sync_binlog 전역 변수(1이 가장 안전한 값이지만 가장 느림)를 사용하여 N개의 binlog 쓰기 후에 binlog를 하드 디스크와 동기화할 수 있습니다. sync_binlog를 1로 설정하더라도 충돌이 발생하면 테이블 내용과 binlog 내용 사이에 불일치가 발생할 수 있습니다. InnoDB 테이블을 사용하는 경우 MySQL 서버는 COMMIT 문을 처리하고 전체 트랜잭션을 binlog에 기록하고 해당 트랜잭션을 InnoDB에 커밋합니다. 두 작업 사이에 충돌이 발생하면 다시 시작할 때 트랜잭션이 InnoDB에 의해 롤백되지만 binlog에는 여전히 존재합니다. --innodb-safe-binlog 옵션을 사용하여 InnoDB 테이블 내용과 binlog 간의 일관성을 높일 수 있습니다. (참고: --innodb-safe-binlog는 MySQL 5.1에서 필요하지 않습니다. 이 옵션은 도입으로 인해 더 이상 사용되지 않습니다.) 그리고 (기본적으로 true) InnoDB 로그는 하드 디스크와 동기화됩니다. 충돌 후 다시 시작할 때 트랜잭션이 롤백된 후 MySQL 서버는 binlog에서 롤백된 InnoDB 트랜잭션을 잘라냅니다. 이렇게 하면 binlog가 InnoDB 테이블 등의 정확한 데이터를 피드백하고 슬레이브 서버가 마스터 서버와 동기화된 상태를 유지합니다(롤백 문 수신 없이).

innodb_flush_log_at_trx_commit(매우 잘 작동함)

Innodb가 MyISAM보다 100배 느리다고 불평하시나요? 그렇다면 아마도 이 값을 조정하는 것을 잊었을 것입니다. 기본값 1은 트랜잭션 외부의 모든 트랜잭션 커밋 또는 명령이 하드 디스크에 로그를 기록(플러시)해야 함을 의미하며 이는 매우 시간이 많이 걸립니다. 특히 배터리 백업 캐시를 사용할 때 더욱 그렇습니다. 2로 설정하는 것은 많은 응용 프로그램, 특히 MyISAM 테이블에서 전송된 응용 프로그램에 적합합니다. 이는 하드 디스크에 쓰는 것이 아니라 시스템 캐시에 쓰는 것을 의미합니다. 로그는 여전히 매초 디스크에 플러시되므로 일반적으로 1~2초 이상의 업데이트가 손실되지 않습니다. 0으로 설정하면 속도가 빨라지지만 보안이 취약하여 MySQL이 중단되더라도 트랜잭션 데이터가 손실될 수 있습니다. 값 2는 전체 운영 체제가 중단된 경우에만 데이터 손실을 발생시킵니다.

위 내용은 MySQL의 마스터-슬레이브 데이터베이스 동기화 지연 문제 해결의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!