마스터가 오프라인 상태가되면 슬레이브 MySQL 변경 사항으로 마스터 MySQL DB를 어떻게 다시 동기화합니까?

11

MySQL 서버 1이 마스터로 실행 중입니다.
MySQL Server 2는 Slave로 실행 중입니다.

두 DB가 모두 온라인 상태이면 "완벽한 동기화"상태입니다. 슬레이브가 오프라인 상태가 되어도 마스터가 여전히 온라인 상태이면 아무런 문제가 없습니다. 슬레이브가 다시 온라인 상태가되면 동기화됩니다.

서버 구성 외에도 마스터가 오프라인 상태가되면 슬레이브 DB에 대한 연결 (JSP 코드 사용)을 리디렉션했습니다 (물론 /etc/init.d/mysqld 중지로 테스트했습니다).

마스터가 다시 온라인 상태가되면 마스터를 슬레이브 업데이트와 동기화하는 자동 방법이 있습니까?

mysql replication

— RolandoMySQLDBA
소스

8

이러한 특성을 끌어내는 좋은 방법 중 하나는 마스터 마스터 복제 또는 순환 복제를 설정하는 것입니다. 이것은 MultiMaster Replciation과 혼동되어서는 안됩니다.

Master-Slave Replication을 설정 한 경우 순환 복제 설정이 매우 쉽습니다. 구성하려면 다음을 수행해야합니다.

이 예에서는 Master-Slave Replication이 활성화되어 있다고 가정하지만 약간의 다운 타임 (1-2 분)이 발생합니다.

단계 1)이 줄을 마스터의 /etc/my.cnf에 추가하십시오.

로그 슬레이브 업데이트

2 단계) 다음 행을 슬레이브의 /etc/my.cnf에 추가하십시오.

log-bin = mysql-bin (또는 마스터가 가지고있는 것을 갖습니다) log-slave-updates

경고 : 여기에 짧은 가동 중지 시간이 있습니다!

3 단계) 슬레이브에서 mysql restart 서비스

슬레이브에서 바이너리 로그를 활성화합니다

4 단계) 마스터에서 mysql stop 서비스

5 단계) rsync를 사용하여 슬레이브의 / var / lib / mysql 폴더를 마스터로 복사합니다.

경고 : 여기 더 긴 가동 중지 시간이 있습니다 !!!

6 단계) 슬레이브에서 mysql stop 서비스

7 단계) 슬레이브에서 마지막 이진 로그를 찾습니다.

8 단계) 슬레이브에서 마지막 이진 로그의 파일 크기를 찾습니다.

단계 9) rsync를 사용하여 슬레이브의 / var / lib / mysql 폴더를 마스터로 복사하십시오. 더 빠른 사본이어야합니다.

단계 10) 마스터
에서 슬레이브의 마지막 이진 로그를 사용하여 master.info의 2 행을 편집 하십시오.
슬레이브의 마지막 이진 로그 파일 크기가있는 master.info의 3 행.
슬레이브 IP와 master.info의 4 행.
5 행은 복제 사용자의 사용자 ID입니다 (터치하지 마십시오)
6 행은 복제 사용자의 비밀번호입니다 (터치하지 마십시오)

11 단계) 마스터의 모든 이진 로그 및 이진 로그 인덱스 파일을 삭제합니다.

단계 12) 슬레이브에서 mysql 서비스를 시작하고 15 초간 기다립니다.

13 단계) 마스터에서 mysql start 서비스

14 단계) 마스터에서 STOP SLAVE를 실행하십시오. 마스터 상태 표시;

15 단계) Slave에서 CHANGE MASTER TO MASTER_HOST = 'Slave의 IP', MASTER_USER = '10 단계의 사용자 복제 사용자 ID ', MASTER_PASSWORD = '10 단계의 사용자 복제 비밀번호', MASTER_LOG_FILE = '14 단계의 이진 로그 ', MASTER_LOG_POS = 14 단계의 LogPos.

단계 16) 슬레이브에서 START SLAVE를 실행하십시오.

단계 17) 마스터에서 START SLAVE를 실행하십시오.

내가 대답 한 다른 StackExchange 질문에 대해 이와 비슷한 단계를 수행했습니다 .

시도 해봐 !!!

— RolandoMySQLDBA
소스

아주 좋아요! "마스터-마스터-마스터"솔루션과 같이 하나 이상의 슬레이브 데이터베이스를 마스터에 동기화 할 수 있습니까?

— Herberth Amaral

이것은 수리를 넘어서 내 설정을 깨뜨렸다. VPS를 완전히 다시 설치해야했습니다. 다음 번에는 끔찍한 조언을 읽기 전에 스냅 샷을 찍을 것 같습니다.

— Vasili Syrakis

트윗 담아 가기 그럼에도 불구하고 MySQL DBA로 10 년 동안 복제를 위해 이진 로그를 다시 정렬 할 때 VPS 또는 MySQL 설치를 한 번도 파괴 한 적이 없습니다. 나는 Drupal과 Wordpress 고객을 위해 몇 년 동안 사고없이 이것을 해왔습니다. 내 조언에 대해 죄송합니다.

— RolandoMySQLDBA

흠. rsync를 사용하여 실행중인 인스턴스를 복사하지 않는 것이 좋습니다. Percona XtraBackup을 사용 하여 슬레이브에서 마스터를 다시 초기화합니다 . 또한 log-slave-updates마스터에 추가 슬레이브 가없는 한 필요하지 않습니다 .

— Bill Karwin

2

MySQL이 제공하는 비동기식 복제는 아닙니다. 방금 MySQL 즉시 복제 (5.5 이전)가 고 가용성 솔루션이 아닌 이유에 대한 속담을 깨달았습니다. 반 동기식 복제 (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html)를 사용하면 5.5가 약간 개선되지만 마스터가 노예에서 ack.

마스터가 다운 될 때 데이터 손실 가능성을 받아들이는 것이 옵션이 아니라면 간단한 마스터 / 슬레이브보다 더 복잡한 설정이 필요합니다.

마스터에서 마스터로의 복제는 많은 MySQL 유명한 사람들이 얻는 이점보다 더 많은 문제로 간주되었습니다 (MySQL AB 자체도 더 이상 고 가용성 솔루션으로 권장하지 않음). 따라서 DRBD 설정을 사용하여 블록 레벨 사본을 사용하여 활성 마스터와 수동 슬레이브를 동기화 상태로 유지하는 것이 실제로 필요한 것입니다.

— TechieGurl
소스

1

DRBD를 좋아합니다. 장애 조치 메커니즘으로 ucarp를 사용하는 많은 클라이언트에서 정기적으로 작업합니다. 데이터베이스가 모두 InnoDB 인 경우 DRBD는 실제로 HA에 적합하고 선호됩니다. 장애 조치 중 열린 MyISAM 테이블은 DRBD 보조에서도 충돌로 표시됩니다. InnoDB는 새로운 DRBD 1 차로 장애 조치 할 때 응급 복구를 수행합니다. 그래서 DRBD와 InnoDB가 함께 사용되는 것을 볼 수 있습니다. DRBD를 시작해 주셔서 감사합니다. 답변을 +1하십시오.

— RolandoMySQLDBA

고맙습니다 :) 내 대답에 따르면 복제본 간의 데이터 일관성에 대해 너무 신경

— 쓰면

1

IMHO, 우선, 다중 마스터가 아닌 (마스터 / 슬레이브) 구성에서 슬레이브는 절대 쓰기를하지 않아야합니다. 슬레이브 my.cnf를 설정하고 서버를 시작해야합니다 :

# Flag to not take writes from network
read-only

다음으로, 쓰기 가능한 슬레이브가 실수로 쓰기를 수행하는 것과 동기화되지 않은 마스터의 문제를 해결하려면 두 호스트의 데이터를 서로 비교해야합니다. 키 충돌이없는 경우 이전 슬레이브 호스트를 마스터하도록 승격하고 이전 마스터를 새 마스터에서 복제하는 슬레이브 호스트로 다시 이미지화해야합니다. (여기에 데이터 문제가있을 수 있습니다.)

마지막으로, 이 중단 / 중단 시간 시나리오가 계속 진행될 가능성이있는 경우 두 호스트를 다중 마스터 (log-bin, server-id, 오프셋 등)로 설정하십시오. 이렇게하면 중단 및 다운 타임을 어느 정도 완화 할 수 있습니다.

master / slave를 실행해야하는 경우 ACL 및 응용 프로그램에서 읽기 및 쓰기 사용자 연결을 분리하기위한 보너스 포인트가 필요합니다.

— 랜덤
소스