지연 시간이 긴 상호 연결이 MySQL 복제에 영향을 줍니까?

서로 다른 데이터 센터에 상주하는 바닐라 마스터 및 슬레이브 MySQL 설정이 있고 마스터와 동일한 데이터 센터에 다른 슬레이브가 있습니다.

데이터 센터 간의 대역폭은 꽤 높지만 (네트워크 벤치 마크에서 초당 15MB에 도달 할 수 있음) 대기 시간이 존재하며 약 28ms입니다. 결코 높지는 않지만 동일한 데이터 센터에서 1 초 미만의 대기 시간보다 훨씬 높습니다.

경우에 따라 로컬 슬레이브가 최신 상태를 유지하는 동안 슬레이브 제거와 관련하여 심각한 지연 (2000 초 이상)이 발생하는 경우가 있습니다. 지연된 원격 슬레이브를 볼 때 일반적으로 SQL 스레드는 IO 스레드가 릴레이 로그를 업데이트하기를 기다리는 시간을 소비합니다. 마스터는 "순간 대기 중"또는 이와 비슷한 것을 보여줍니다.

그것은 그것이 네트워크라는 것을 의미하지만, 우리는 여전히 이런 상황이 발생했을 때 무료 대역폭을 가지고 있습니다.

내 질문은 : 데이터 센터 간의 대기 시간이 복제 성능에 영향을 줄 수 있습니까? 슬레이브 io 스레드는 마스터가 이벤트 전송을 중지 할 때까지 이벤트를 스트리밍합니까? 아니면 이벤트간에 마스터를 풀링합니까?

귀하의 질문에 대한 직접적인 대답은 예이지만 실행중인 MySQL의 버전에 따라 다릅니다. MySQL 5.5 이전에는 복제가 다음과 같이 작동했습니다.

• 마스터는 SQL을 실행
• 이진 로그에 마스터 레코드 SQL 이벤트
• 슬레이브는 마스터 이진 로그에서 SQL 이벤트를 읽습니다.
• 슬레이브는 I / O 스레드를 통해 릴레이 로그에 SQL 이벤트를 저장합니다
• 슬레이브는 SQL 스레드를 통해 릴레이 로그에서 다음 SQL 이벤트를 읽습니다.
• 슬레이브는 SQL을 실행
• 슬레이브는 SQL 이벤트의 완전한 실행 마스터를 인정

MySQL 5.5에서 Semisynchronous Replication을 사용 하면 이제 복제가 다음과 같이 작동합니다.

• 마스터는 SQL을 실행
• 이진 로그에 마스터 레코드 SQL 이벤트
• 슬레이브는 마스터 이진 로그에서 SQL 이벤트를 읽습니다.
• 슬레이브는 SQL 이벤트 수신 마스터를 인정
• 슬레이브는 I / O 스레드를 통해 릴레이 로그에 SQL 이벤트를 저장합니다
• 슬레이브는 SQL 스레드를 통해 릴레이 로그에서 다음 SQL 이벤트를 읽습니다.
• 슬레이브는 SQL을 실행
• 슬레이브는 SQL 이벤트의 완전한 실행 마스터를 인정

이 새로운 패러다임은 슬레이브가 마스터와 더 가깝게 동기화되도록합니다.

그럼에도 불구하고 네트워크 내 지연 시간으로 인해 MySQL 세미 싱크 복제가 이전 스타일의 비동기식 복제로 되돌아 갈 때까지 방해가 될 수 있습니다. 왜 ? 슬레이브가 트랜잭션을 확인하지 않고 시간 초과가 발생하면 마스터는 비동기 복제로 되돌아갑니다. 적어도 하나의 반동기 슬레이브가 따라 오면 마스터는 반동기 복제로 돌아갑니다.

업데이트 2011-08-08 14:22 EDT

MySQL 5.5 Semisynchronous Replication의 구성은 간단합니다

1 단계)이 네 줄을 /etc/my.cnf에 추가하십시오

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
#rpl_semi_sync_master_enabled
#rpl_semi_sync_master_timeout=5000
#rpl_semi_sync_slave_enabled

2 단계) MySQL 재시작

service mysql restart

3 단계) MySQL 클라이언트에서이 명령을 실행하십시오.

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave  SONAME 'semisync_slave.so';

4 단계) plugin-dir 옵션 다음에 세 개의 rpm_semi_sync 옵션의 주석을 해제하십시오

[mysqld]
plugin-dir=/usr/lib64/mysql/plugin
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout=5000
rpl_semi_sync_slave_enabled

5 단계) MySQL 재시작

service mysql restart

다됐다 !!! 이제 평소와 같이 MySQL 복제를 설정하십시오.

Rolando가 복제가 수행하는 일련의 작업을 어떻게 묘사했는지 정말 좋아합니다. 그러나 다른 구성 요소 인 클라이언트를 추가하면 더 분명하다고 생각합니다.

클라이언트에서 비동기 복제에 대한 작업 순서는 다음과 같습니다.

1. 클라이언트는 트랜잭션을 사용하여 마스터에 SQL 쿼리 (예 : 삽입)를 보냅니다.

2. 마스터가 트랜잭션을 실행합니다. 성공하면 레코드가 디스크에 저장되지만 트랜잭션은 아직 커밋되지 않습니다.

3. 마스터는 삽입 이벤트를 마스터 이진 로그에 기록합니다. 마스터가 이진 로그에 마스터를 저장할 수없는 경우 트랜잭션이 롤백되었습니다.

4. 클라이언트는 마스터 (성공 또는 롤백)로부터 응답을받습니다.

5. 트랜잭션이 성공하면 마스터의 덤프 스레드는 이진 로그에서 이벤트를 읽고 슬레이브 I / O 스레드로 보냅니다.

6. 슬레이브 I / O 스레드는 이벤트를 수신하여 릴레이 로그 파일의 끝에 기록합니다.

7. 이벤트가 릴레이 로그에 들어가면 슬레이브 SQL 스레드
   는 이벤트를 실행 하여 변경 사항을 슬레이브의 데이터베이스에 적용합니다.

이 시나리오에서 마스터는 슬레이브에 신경 쓰지 않으며 클라이언트는 "SHOW SLAVE STATUS"명령을 수동으로 실행하여 슬레이브에 문제가 있음을 알고 있습니다.

반 동기식 복제의 경우 작업 순서는 다음과 같습니다.

1. 클라이언트는 트랜잭션을 사용하여 SQL 쿼리 (예 : 삽입)를 마스터에 보냅니다.

2. 마스터가 트랜잭션을 실행합니다. 성공하면 레코드가 디스크에 저장되지만 트랜잭션은 커밋되지 않습니다.

3. 마스터는 삽입 이벤트를 마스터 이진 로그에 기록합니다. 마스터가 이진 로그에 마스터를 저장할 수없는 경우 롤백 된 경우에만 트랜잭션이 롤백되고 클라이언트가 응답을받습니다.

4. 마스터에서의 트랜잭션 성공으로 인해 마스터의 덤프 스레드는 2 진 로그에서 이벤트를 읽고 슬레이브 I / O 스레드로 보냅니다.

5. 슬레이브 I / O 스레드는 이벤트를 수신하여 릴레이 로그 파일의 끝에 기록합니다.

6. 슬레이브는 릴레이 로그 파일에 이벤트 기록을 마스터에게 승인합니다.

7. 마스터가 삽입 트랜잭션을 커밋합니다.

8. 클라이언트는 마스터 (성공)로부터 응답을받습니다.

9. 이벤트가 릴레이 로그에 들어가면 슬레이브 SQL 스레드
   가 이벤트를 실행 합니다. 마스터와 클라이언트는 실행의 성공 여부를 모릅니다.

세미 동기식 복제는 슬레이브 또는 네트워크가 죽고 마스터가 계속 진행할 때 중요한 한 가지 경우를 해결했습니다. 그런 다음 마스터가 종료되고 해당 노드를 수정했기 때문에 기존 슬레이브를 새 마스터로 다시 시작하려고합니다.

따라서 해당 노드를 새 마스터로 시작하고 이전 마스터를 수정했으며 이제이를 슬레이브로 사용하려고합니다. 해당 노드에는 여전히 데이터가 있지만 새 슬레이브가 시작된 위치에서 새 슬레이브가 시작되면 중복 레코드가 있습니다.

대기 기간이 무한한 경우 마스터 이진 로그 위치는 슬레이브의 모든 쿼리가 성공적이라고 가정 할 때 항상 슬레이브 릴레이 로그 위치와 동기화됩니다. 이 가정이 얼마나 현실적인가?

나는 그것이 매우 현실적이라고 생각합니다. 슬레이브 쿼리 실패의 가장 일반적인 경우 중 하나는 "중복 레코드"입니다. 마스터가 가지고 있지 않은 경우 중복 레코드가 슬레이브에 온 곳은 어디입니까? 복제를 시작하기 위해 슬레이브에 주어진 잘못된 위치에서 나왔습니다. 시작 복제 위치에는 이미 복제 된 레코드가 포함되었습니다. 반동기 복제의 경우이 상황이 발생하지 않습니다.

제이콥 니놈

한정자 : 저는 MySQL 사용자가 아니기 때문에 주로 인터넷에 대한 연구입니다.

아시다시피, MySQL 복제의 가장 큰 한계는 단일 스레드라는 것입니다. 따라서 스레드가 사내 슬레이브로 데이터를 전송하는 중이지만 원격 슬레이브로 데이터를 전송할 수는 없습니다. 이것은 여기에 있습니다 .

당 여기 :

당신이해야 할 한 가지는 거래 시간을 줄이는 것입니다. 이를 통해 복제 스레드는 데이터베이스에서 진행중인 작업을 따라 잡을 수 있습니다. 거래가 가능한 한 짧아야합니다.

이를 수행하는 한 가지 방법은 쿼리 자르기를 통한 것입니다. WHERE 절을 사용하여 UPDATE 또는 DELETE에 의해 변경된 행을 제한하십시오. 루프 안에 그것을 넣으면 매번 트랜잭션을 시작하고 커밋하여 목록을 반복 할 수 있습니다. (첫 번째, 세 번째, 세 번째, 그리고 마지막 세 번째는 각각 자체 트랜잭션에서 업데이트 / 삭제합니다.) 나는 당신이 트랜잭션 사이에서 테이블의 데이터가 변경 될 가능성에 자신을 열었 기 때문에 이것을하지 말 것을 강력히 권합니다. 그러나 다른 사람이 테이블을 망칠 것이 아니라고 확신 하지 않으면이 성능을 향상시킬 수 있습니다 .

또 다른 가능성은 오래 실행 된 트랜잭션을 복제하지 않고 마스터 (로컬 슬레이브에 복제)에서 모두 실행 한 다음 원격 슬레이브에서 개별적으로 실행하는 것입니다. 이렇게하면 복제 스레드가 해제되어 30 분 이상 표시되지 않습니다.

당 여기 :

마지막 가능성은 TCP 버퍼의 크기를 조정하는 것입니다. 목표는 마스터와 슬레이브 간의 통신 수를 줄이는 것입니다. 이는 대기 시간을 줄이는 데 도움이 될 수 있습니다.

개인적으로, 나는 다른 모든 것이 실패하면 이것을 시도 할 것입니다. 네트워크 대기 시간이 아닌 단일 스레드 복제 시스템으로 인해 문제가 더 많은 것으로 의심됩니다. 네트워크는 일반적으로 30 분이되기 전에 시간이 초과됩니다. (30 분?!)

JHammerb의 Delicious 북마크 에는 mysql replication에 대한 몇 가지 링크가 있으며 체크 아웃해야 할 수도 있습니다.

도움이 되길 바랍니다.