MySQL 마스터-슬레이브 동기화 지연의 이유와 해결 방법

Mysql 마스터-슬레이브 기본 원리, 주요 형태 및 마스터-슬레이브 동기화 지연 원리(읽기-쓰기 분리)로 인해 마스터-슬레이브 데이터 불일치 문제 및 해결 방법

1. 마스터-슬레이브 데이터베이스의 차이점

슬레이브 데이터베이스(Slave)는 마스터 데이터베이스(Master)가 변경되면 슬레이브 데이터베이스를 업데이트해야 하는 데이터베이스 소프트웨어입니다. 이는 정보 보안을 강화하기 위한 수단입니다. 마스터 및 슬레이브 데이터베이스 서버는 동일한 지리적 위치에 있지 않으므로 사고 발생 시 데이터베이스를 저장할 수 있습니다.

(1) 마스터-슬레이브 분업

마스터는 쓰기 작업의 부하를 담당합니다. 즉, 모든 쓰기 작업은 마스터에서 수행되고 읽기 작업은 슬레이브에 할당됩니다. 이렇게 하면 읽기 효율성이 크게 향상될 수 있습니다. 일반적인 인터넷 응용 프로그램에서는 일부 데이터 조사를 통해 읽기/쓰기 비율이 약 10:1이라는 결론을 내렸습니다. 이는 많은 수의 데이터 작업이 읽기 작업에 집중되어 있음을 의미하므로 다중 슬레이브 이유가 있습니다. 그런데 왜 읽기와 쓰기를 분리해야 할까요? DB에 익숙한 R&D 인력은 쓰기 작업에 행 잠금, 테이블 잠금, 블록 잠금 등 잠금 문제가 포함되어 시스템 실행 효율성이 상대적으로 떨어진다는 것을 모두 알고 있습니다. 우리의 분리는 쓰기 작업을 한 노드에 집중하고 읽기 작업은 다른 N 노드에서 수행하는 것입니다. 이를 통해 읽기 효율성이 효과적으로 향상되고 시스템의 고가용성이 보장됩니다.

(2) 기본 프로세스
1) MySQL의 마스터-슬레이브 동기화는 마스터(메인 데이터베이스)의 데이터가 변경되면 실시간으로 슬레이브(슬레이브 데이터베이스)에 동기화되는 것을 의미합니다.
2) 마스터-슬레이브 복제는 데이터베이스의 로드 용량, 내결함성, 고가용성 및 데이터 백업을 수평적으로 확장할 수 있습니다.

3) 삭제, 업데이트, 삽입, 함수나 저장 프로시저 생성 등은 모두 마스터에 있습니다. 마스터가 작업을 수행하면 슬레이브가 이러한 작업을 신속하게 수신하고 동기화를 수행합니다.

(3) 목적 및 조건
1), mysql 마스터-슬레이브 복제 목적
●실시간 재해 복구, Failover에 사용
●읽기-쓰기 분리, 쿼리 서비스 제공
●업무에 영향을 주지 않도록 백업
2 ), 마스터-슬레이브 배포에 필요한 조건:
●메인 라이브러리에서 binlog 활성화(log-bin 매개변수 설정)
●마스터-슬레이브 서버 ID가 다름
●슬레이브 서버가 메인 라이브러리에 연결할 수 있음

2. 마스터-슬레이브 동기화 세분성, 원리 및 형식:

(1), 세 가지 주요 구현 세분성
자세한 마스터-슬레이브 동기화에는 주로 세 가지 형식이 있습니다: 문, 행, 혼합
　1), 명령문: 데이터베이스 작업의 SQL을 처리합니다. 명령문은 binlog에 기록됩니다.
　2), 행: binlog에 있는 각 데이터 조각의 변경 사항을 기록합니다.
3), 혼합: 문과 행이 혼합된 것입니다. MySQL은 언제 binlog를 명령문 형식으로 작성할 것인지, 언제 binlog를 행 형식으로 작성할 것인지를 결정합니다.

(2), 주요 구현 원리, 특정 작업, 회로도

1), 마스터 머신에서의 작업:
마스터의 데이터가 변경되면 이벤트 변경 내용이 순서대로 빈에 기록됩니다. -통나무. 슬레이브가 마스터에 연결되면 마스터 시스템은 슬레이브에 대한 binlog 덤프 스레드를 시작합니다. 마스터의 binlog가 변경되면 bin-log 덤프 스레드는 슬레이브에 알리고 해당 binlog 콘텐츠를 슬레이브에 보냅니다.
2) 슬레이브 머신에서의 작업:

마스터-슬레이브 동기화가 켜지면 슬레이브에 IO 스레드라는 두 개의 스레드가 생성됩니다. 이 스레드는 마스터 시스템에 연결되며 마스터 시스템의 binlog 덤프 스레드는 binlog의 내용을 IO 스레드로 보냅니다. binlog 콘텐츠를 수신한 후 I/O 스레드는 해당 콘텐츠를 로컬 릴레이 로그에 기록합니다. 이 스레드는 I/O 스레드가 작성한 ralay 로그를 읽습니다. 그리고 릴레이 로그에 따르면. 그리고 릴레이 로그의 내용에 따라 슬레이브 데이터베이스에 해당 작업을 수행합니다.

3) MySQL 마스터-슬레이브 복제의 도식은 다음과 같습니다.

슬레이브 라이브러리는 I/O 스레드 하나와 SQL 스레드 하나, 두 개의 스레드를 생성합니다.
i/o 스레드는 binlog를 요청합니다. 획득한 binlog 로그는 릴레이 로그 파일에 기록됩니다.
메인 라이브러리는 binlog를 슬레이브 라이브러리 I/O 스레드로 전송하기 위해 로그 덤프 스레드를 생성합니다.
SQL 스레드는 릴레이 로그 파일을 읽습니다. 일관된 마스터-슬레이브 작업 및 일관된 최종 데이터를 달성하기 위해 특정 작업으로 구문 분석됩니다.

(2), 마스터-슬레이브 형식

mysql 마스터-슬레이브 복제는 유연합니다
● 하나의 마스터, 하나의 슬레이브
● 마스터-마스터 복제
● 하나의 마스터와 여러 개의 슬레이브---읽기가 슬레이브 라이브러리에서 이루어지기 때문에 시스템 읽기 성능을 확장합니다.
● 다중 마스터와 하나의 슬레이브---5.7부터 지원

● 계단식 복제---

3. 마스터-슬레이브 동기화 지연 등의 문제, 원인 및 해결 방법:

(1), mysql 데이터베이스 슬레이브 동기화 지연 문제

　1) 관련 매개 변수:

먼저 실행합니다. 서버 쇼 슬레이브 상태를 보면 많은 동기화된 매개변수를 볼 수 있습니다:

Master_Log_File: SLAVE의 I/O 스레드가 현재 읽고 있는 마스터 서버 바이너리 로그 파일의 이름.
Read_Master_Log_Pos: 현재 마스터 서버 바이너리 로그에서 SLAVE의 I/O 스레드가 읽은 위치. : SQL 현재 스레드가 읽고 실행하고 있는 릴레이 로그 파일 이름
relay_log_pos : 현재 릴레이 로그에서 SQL 스레드가 읽고 실행한 위치
relay_master_log_file : 로그 파일 이름 aslave_io_running : I/O 여부 O 스레드가 시작되어 메인 서버에 성공적으로 연결되었습니다.
SLAVE_SQL_Running: SQL 스레드가 시작되었는지 여부
Seconds_Behind_Master: 단위는 초입니다.
슬레이브 동기화 지연이 발생합니다. ● 슬레이브 상태 표시 매개변수 Seconds_Behind_Master가 0이 아니며, 이 값이 매우 클 수 있습니다.
● 슬레이브 상태 표시 매개변수 Relay_Master_Log_File과 Master_Log_File은 bin-log의 수가 매우 다르다는 것을 보여줍니다. bin-log가 있습니다. 슬레이브 데이터베이스가 시간에 맞춰 동기화되지 않아 최근 실행된 bin-log와 현재 IO 스레드에서 읽은 bin-log가 매우 다릅니다.
● mysql-relay-log가 많습니다. mysql 슬레이브 데이터베이스 데이터 디렉터리에 있는 로그는 로그 동기화가 완료된 후 시스템에 의해 자동으로 삭제되며 로그가 많아 마스터-슬레이브 동기화 지연이 매우 심각함을 나타냅니다

(2 ), MySql 데이터베이스 슬레이브 동기화 지연 문제

1), MySQL 데이터베이스 마스터-슬레이브 동기화 지연 원리 mysql 마스터-슬레이브 동기화 원리: 쓰기 작업의 경우 마스터 라이브러리가 binlog를 순차적으로 작성하고 슬레이브 라이브러리가 마스터로 이동 단일 스레드가 있는 라이브러리는 "쓰기 작업의 binlog"를 순차적으로 읽습니다. 슬레이브 라이브러리에서 얻은 binlog는 마스터-슬레이브 데이터의 논리적 일관성을 보장하기 위해 있는 그대로(무작위로 기록됨) 로컬로 실행됩니다. mysql의 마스터-슬레이브 복제는 단일 스레드 작업이므로 기본 라이브러리는 모든 DDL 및 DML에 대해 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 스레드 하나가 감당할 수 있는 수준을 초과하면 지연이 발생할 수도 있습니다. 물론 슬레이브의 대규모 쿼리 문으로 인해 잠금 대기가 발생할 수도 있습니다. 주된 이유: 데이터베이스는 비즈니스에서 읽고 쓰는 데 너무 많은 부담을 받고 있고, CPU 컴퓨팅 부하가 높으며, 네트워크 카드 부하가 크고, 하드 디스크 임의 IO가 너무 높습니다. 두 번째 이유: 읽기 및 쓰기가 성능에 미치는 영향이 너무 높습니다. binlog 작성 및 네트워크 전송 지연.

(3), 데이터베이스의 MySql 데이터베이스 동기화 지연 솔루션

1), 아키텍처

1. 비즈니스 지속성 계층의 구현은 하위 데이터베이스 아키텍처를 채택하며 MySQL 서비스는 다음을 수행할 수 있습니다. 병렬로 확장되어 압력을 분산시킵니다.

2. 하나의 마스터와 여러 슬레이브, 마스터 쓰기 및 슬레이브 읽기 등 단일 라이브러리에서 읽기 및 쓰기를 분리하여 압력을 분산시킵니다. 이런 방식으로 슬레이브 라이브러리의 압력이 메인 라이브러리보다 높아 메인 라이브러리를 보호합니다.

3. 서비스 인프라는 비즈니스와 mysql 사이에 memcache 또는 redis 캐시 레이어를 추가합니다. mysql의 읽기 압력을 줄입니다.

4. 다양한 비즈니스를 위한 MySQL은 압력을 분산시키기 위해 물리적으로 다른 시스템에 배치됩니다.

5. 슬레이브 요약으로 메인 라이브러리보다 더 나은 하드웨어 장비를 사용하면 MySQL이 부담이 덜하고 지연도 자연스럽게 줄어듭니다.

2) 하드웨어 측면에서

1. 좋은 서버를 사용하세요. 예를 들어 4u는 2u보다 성능이 훨씬 좋고, 2u는 1u보다 성능이 훨씬 좋습니다.

2. SSD나 디스크 어레이 또는 SAN을 스토리지로 사용하여 임의 쓰기 성능을 향상시킵니다.

3. 마스터와 슬레이브는 동일한 스위치 및 10G 환경에 있음이 보장됩니다.

결론적으로 하드웨어가 강하면 딜레이는 자연스럽게 작아지겠죠. 즉, 지연 시간을 최소화하는 솔루션은 돈과 시간입니다.

3), mysql 마스터-슬레이브 동기화 가속

1. 슬레이브 측에서는 sync_binlog가 0으로 설정됩니다

2. –logs-slave-updates 마스터 서버에서 슬레이브 서버가 수신한 업데이트는 기록되지 않습니다. 바이너리 로그에 있습니다.

3. 슬레이브 측에서 binlog를 직접 비활성화합니다

4. 슬레이브 측에서 사용되는 스토리지 엔진이 innodb_flush_log_at_trx_commit =2

4) 파일 시스템 자체의 속성 관점에서 최적화합니다.

마스터 측은 Linux 및 Unix 파일 시스템에서 파일의 etime 속성을 수정합니다. OS는 파일을 읽을 때마다 읽기 작업 시간을 디스크에 다시 기록하므로 읽기 작업이 자주 수행되는 데이터베이스 파일에는 이 작업이 필요하지 않습니다. , 디스크 시스템의 부담만 증가시키고 I/O 성능에 영향을 미칩니다. 파일 시스템의 마운트 속성을 설정하여 atime 정보를 기록하도록 운영 체제를 구성할 수 있습니다. Linux에서의 작업은 다음과 같습니다. /etc/fstab을 열고 noatime 매개변수 /dev/sdb1 /data reiserfs noatime 1 2를 추가한 다음 파일 시스템 #mount -oremount /data

5), 동기화 매개변수 조정 sync_binlog=1, innodb_flush_log_at_trx_commit = 1 및 기타 설정이 필요하지만 슬레이브는 그렇지 않습니다. 이렇게 높은 데이터가 필요합니다. sync_binlog를 0으로 설정하거나 binlog를 끌 수도 있습니다. Innodb_flushlog를 0으로 설정하여 SQL의 실행 효율성을 높일 수도 있습니다. 1. sync_binlog=1 oMySQL은 binlog를 제어하는 ​​매개변수를 제공합니다. 데이터베이스를 디스크로 플러시합니다. 기본적으로 sync_binlog=0은 MySQL이 binlog 새로 고침을 제어하지 않고 파일 시스템 자체가 캐시 새로 고침을 제어한다는 의미입니다. 이때의 퍼포먼스는 최고지만 리스크도 가장 높다. 시스템이 충돌하면 binlog_cache의 모든 binlog 정보가 손실됩니다.

sync_binlog>0이면 모든 sync_binlog 트랜잭션이 제출되었음을 의미하며 MySQL은 파일 시스템의 새로 고침 작업을 호출하여 캐시를 플러시합니다. 가장 안전한 설정은 sync_binlog=1입니다. 이는 트랜잭션이 제출될 때마다 MySQL이 binlog를 플러시함을 의미합니다. 이는 가장 안전한 설정이지만 성능 손실이 가장 큽니다. 이 경우 데이터베이스가 위치한 호스트의 운영체제가 손상되거나 갑자기 전원이 꺼지는 경우에만 시스템은 한 트랜잭션의 데이터를 잃을 수 있다. 그러나 binlog는 순차 IO이지만 sync_binlog=1로 설정하고 여러 트랜잭션을 동시에 제출하는 경우에도 MySQL 및 IO 성능에 큰 영향을 미칩니다. 그룹 커밋 패치를 통해 완화할 수 있지만 새로 고침 빈도가 너무 높으면 IO에 큰 영향을 미칩니다.

동시 트랜잭션이 많은 시스템의 경우 "sync_binlog"가 0으로 설정되고 1로 설정된 시스템 간의 쓰기 성능 격차가 최대 5배 이상 클 수 있습니다. 따라서 많은 MySQL DBA가 설정하는 sync_binlog는 가장 안전한 1이 아니라 2 또는 0입니다. 이는 더 높은 동시성과 성능을 달성하기 위해 일정량의 일관성을 희생합니다. 기본적으로 binlog는 기록될 때마다 하드 디스크와 동기화되지 않습니다. 따라서 운영 체제나 시스템(MySQL 서버뿐만 아니라)이 충돌하는 경우 binlog의 마지막 명령문이 손실될 수 있습니다. 이를 방지하려면 sync_binlog 전역 변수(1이 가장 안전한 값이지만 가장 느림)를 사용하여 N개의 binlog 쓰기 후에 binlog를 하드 디스크와 동기화할 수 있습니다. sync_binlog를 1로 설정하더라도 충돌이 발생하면 테이블 내용과 binlog 내용이 일치하지 않을 수 있습니다.

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

3. ls(1) 명령을 사용하여 파일의 atime, ctime 및 mtime을 나열할 수 있습니다.

atime 파일의 액세스 시간 파일을 읽거나 파일을 실행할 때 변경되는 ctime 파일 쓰기 시 inode의 내용이 변경될 때 변경되는 파일 생성 시간, 소유자, 권한 또는 링크 설정 변경 mtime 수정 시간 파일을 가져올 때 파일 내용이 변경되면 파일이 변경됩니다. ls -lc filename은 파일의 atimels를 나열합니다. -l filename은 파일의 mtimestat 파일 이름을 나열합니다. , mtime, ctimeatime은 파일에 접근한 후 반드시 삭제되지는 않습니다. 수정: ext3 파일 시스템을 사용할 때 마운트 시 noatime 매개 변수를 사용하면 atime 정보가 업데이트되지 않습니다. 이 3개의 타임스탬프는 inode에 위치하는데, mtime과 atime을 수정하면 inode가 변경되므로 ctime도 변경되게 된다. 시스템은 읽기 성능을 향상시키기 위해 너무 많은 수정을 하고 싶지 않습니다

(4), MySql 데이터베이스 슬레이브 동기화 기타 문제 및 솔루션

1), mysql 마스터-슬레이브 복제 문제:

● 마스터 데이터베이스 다운타임 후 데이터가 손실될 수 있습니다. ● 슬레이브 라이브러리에 SQL 스레드가 하나만 있고 기본 라이브러리에 쓰기 부담이 가중되어 복제가 지연될 가능성이 있습니다. 2) 해결 방법: ● 반동기 복제--. -데이터 손실 문제 해결 ● 병렬 복제--- -라이브러리 복사 지연 문제 해결

3) 반동기 복제 mysql semi-sync(반동기 복제) 반동기 복제: ● 5.5는 mysql에 통합되어 플러그인 형태로 존재하며 별도로 설치해야 함 ● 보장 트랜잭션이 제출된 후 binlog가 하나 이상의 슬레이브 라이브러리로 전송됩니다. ● 슬레이브 라이브러리가 이 트랜잭션의 binlog 적용을 완료했다는 보장은 없습니다. ● 성능이 어느 정도 저하되고 응답 시간이 길어집니다. ● 네트워크 이상 또는 슬레이브 라이브러리 다운타임으로 인해 타임아웃되거나 슬레이브 라이브러리가 복원될 때까지 메인 라이브러리가 정체됩니다. 4) 마스터-슬레이브 복제-- 비동기 복제, 반동기 복제 및 병렬 복제의 원리 비교

a. 비동기 복제 원칙:

b. 반동기 복제 원칙:

트랜잭션이 메인 라이브러리에 binlog를 작성한 후 슬레이브 라이브러리는 승인된 메시지를 반환해야 합니다. ;5.5는 mysql에 통합되어 플러그인 형태로 존재하며, 트랜잭션 제출 후 binlog가 하나 이상의 슬레이브 라이브러리로 전송되도록 별도로 설치해야 합니다. 트랜잭션을 완료하기 위한 슬레이브 라이브러리 애플리케이션의 네트워크 이상이 어느 정도 감소합니다. 또는 슬레이브 라이브러리가 다운되고 메인 라이브러리가 시간 초과되거나 슬레이브 라이브러리가 복구될 때까지 멈춥니다.

c, 병렬 복사 mysql 병렬 복사 ● Community Edition 5.6의 새로운 기능 ● 병렬은 라이브러리의 다중 스레드 적용 binlog를 나타냅니다. ● 라이브러리 수준의 병렬 애플리케이션 binlog, 동일한 라이브러리의 데이터 변경 사항은 여전히 ​​직렬입니다(버전 5.7의 병렬 복제는 트랜잭션 그룹을 기반으로 함). set globalslave_parallel_workers=10; SQL 스레드 수를 10으로 설정

원리: 라이브러리의 다중 스레드 적용 binlog는 커뮤니티 5.6에 새로운 라이브러리 수준을 추가합니다. binlog를 병렬로 적용하면 동일한 데이터베이스의 데이터 변경 사항이 계속 직렬화됩니다. 버전 5.7의 병렬 복제는 트랜잭션 그룹을 기반으로 합니다.

더 많은 MySQL 관련 기술 기사를 보려면 MySQL Tutorial 칼럼을 방문하여 알아보세요!

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