mysql 마스터-슬레이브 동기화 및 비동기 사용 시나리오 분석

이 콘텐츠에 대해 연구를 수행하는 이유는 주로 이전에 직면했던 두 가지 풀리지 않는 의심을 해결하기 위한 것입니다.

아. 온라인 상태의 시스템이 있습니다. 반동기 상태는 종종 반동기 상태에서 비동기 상태로 변경되었다가 즉시 반동기 상태로 돌아갑니다. 이전에 추측한 바 있지만 아직 확실하지 않습니다.

b. 얼마 전 비즈니스 시나리오 요구 사항으로 인해 기계실 간 비동기 복제 테스트를 수행했습니다. mysql write qps가 매우 높은 경우 슬레이브 라이브러리로 전송되는 시간이 부족한 로그가 많은 것으로 나타났습니다. 즉, 메인 라이브러리의 binlog 로그 생성 속도가 슬레이브 라이브러리로 전송되는 속도보다 빠른 것입니다. 이런 속도차이는 항상 존재하기 때문에 메인 라이브러리가 계속해서 high 상태가 되면 압력을 받아 binlog가 생성되면서 점점 더 많은 binlog가 슬레이브 라이브러리로 전송되지 않게 되는데, 당시 네트워크 트래픽은 18M/S 정도에 불과했습니다. 하나의 마스터, 하나의 슬레이브). 기존 지식에 따르면 기가비트 네트워크 전송 속도는 100M에 도달할 수 있지만 현재 마스터와 슬레이브 간의 binlog 전송 속도는 약 18M에 불과합니다. 네트워크 문제인가요? 아니면 다른 이유로.

마스터-슬레이브 복제 원리 덤프 스레드 및 io 스레드

마스터-슬레이브 복제 관계가 성립되면 마스터 라이브러리에 덤프 스레드가 있는데, 이는 마스터 라이브러리에서 생성된 binlog 로그를 전송하는 데 사용되며, 슬레이브 라이브러리의 io 스레드는 전송된 데이터를 수신하는 데 사용됩니다. 덤프 스레드를 통해 네트워크 binlog 로그를 통해 슬레이브 라이브러리에 전달되고 이를 릴레이 로그에 기록합니다. 이는 마스터-슬레이브 복제 메커니즘입니다. 동시에 비동기식 복제이기 때문에 전송 프로세스에는 확인 확인이 필요하지 않습니다.

질문도 여기에 있습니다. 비동기식 전송이기 때문에 단순히 binlog 파일의 직접 네트워크 전송으로 이해하면 속도가 매우 빨라야 하지만 실제 상황에서는 테스트 환경에서 binlog 로그의 전송 속도가 이는 로그에서 생성된 약 22M/s의 속도보다 느린 18M/s에 불과합니다. 왜 이 속도로만 작동하고 네트워크 대역폭을 완전히 사용하지 않습니까? 이유는 무엇입니까?

로그 전달 세부정보

마스터-슬레이브 복제 구조에서는 마스터 라이브러리에 하나의 덤프 스레드가 있고 슬레이브 라이브러리에 하나의 io 스레드가 있으므로 여러 스레드를 동시에 보내고 받을 수 없습니다. binlog의 작동 메커니즘만 이해하면 됩니다. 모든 세부 사항을 이해하려면 스레드를 덤프하십시오.

binlog 파일을 분석하면 트랜잭션에 여러 이벤트가 포함될 수 있음을 알 수 있습니다. 가장 간단한 것은 binlog에 기록되는 정보입니다.

으아악

xxxxx 세그먼트마다 이벤트가 있습니다.

Binlog_sender::send_events 함수는 binlog:

에 이벤트 이벤트를 보내는 함수입니다. 기능 매개변수:

end_pos, 현재 읽고 있는 binlog 파일의 끝 위치입니다.

log_cache, 기록은 전송된 binlog 로그의 위치와 binlog 로그 파일을 포함한 현재 전송된 로그의 정보입니다.

기능 논리 분석:

현재 전송된 위치 log_pos가 획득한 파일의 끝 위치 end_pos보다 작다면 아직 전송되지 않은 binlog 로그가 남아 루프에 진입했음을 나타냅니다.

체내 순환:

a. 이벤트 이벤트를 얻으려면 먼저 read_event 함수를 호출하세요.

b.Log_event_type 이벤트_유형= (Log_event_type)event_ptr[EVENT_TYPE_OFFSET];

이 문은 이벤트 유형을 얻은 다음 유형 검사를 수행하는 데 사용됩니다

check_event_type(event_type, log_file, log_pos), 검사를 통과하지 못한 경우 상위 함수에 직접 1이 반환됩니다.

c.log_pos= my_b_tell(log_cache); log_pos 위치를 업데이트합니다. 즉, binlog 위치를 읽는 커서를 현재 위치로 이동합니다.

d. 그런 다음 send_packet() 함수를 호출하여 binlog를 보냅니다.

현재 슬레이브 라이브러리에 동기화되지 않은 binlog의 수에 관계없이 binlog를 보내는 마스터 라이브러리의 세분성은 여전히 이벤트를 하나씩 보내는 것으로 나타났습니다. 보내기 전에 이벤트 유형을 확인해야 합니다. 작은 패킷으로 전송되기 때문에 네트워크 트래픽이 크지 않습니다.

하지만 이 현상에 대한 전제 조건을 설명해야 합니다. 테스트 환경에서는 당시 데이터베이스의 쓰기 qps가 50,000을 넘었기 때문에 비동기적으로라도 전송해야 하는 이벤트가 많았습니다. 스레드 덤프 스레드에 현재 생성된 이벤트 로그를 보낼 시간이 없습니다.

작성된 qps가 엄청날 경우 로그 전송이 너무 늦어지는 상황이 발생할 수 있습니다.

요약

이제 온라인에서 발생한 문제를 되돌아보겠습니다. “동기화 상태가 종종 반동기 상태에서 비동기 상태로 변경되었다가 시간이 지나면 반동기 상태로 복원됩니다.” 분석 시스템이며 때로는 일괄 업데이트 및 일괄 가져오기를 수행합니다. 동시에, 데이터베이스에 의해 설정된 binlog 형식은 행 모드입니다. 여러 행을 업데이트하는 트랜잭션의 경우 많은 이벤트(한 행은 이벤트임)가 포함되어 있으므로 이 트랜잭션의 binlog를 보내는 데 시간이 오래 걸리고 불가능합니다. 1초 이내에 전송되므로(반동기화 시간 초과가 1로 설정됨) 반동기화 상태가 비동기화됩니다.

위 내용은 mysql 마스터-슬레이브 동기화 및 비동기 사용 시나리오 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!