마스터와 슬레이브에 MySQL 복제의 경우 데이터베이스가 다른 경우 MySQL 데이터베이스를 다시 동기화하는 방법

MySQL Server1은 MASTER 로 실행 중 입니다.
MySQL Server2은 SLAVE 로 실행 중 입니다.

이제 DB 복제가 MASTER 에서 SLAVE로 진행되고 있습니다.

Server2네트워크에서 제거하고 하루 후에 다시 연결하십시오. 이 후 master 및 slave의 데이터베이스에 불일치가 있습니다.

마스터에서 슬레이브로 가져온 DB를 복원 한 후에도 DB를 다시 동기화하는 방법으로도 문제가 해결되지 않습니까?

다음은 마스터-슬레이브 복제를 처음부터 다시 동기화하는 전체 단계별 절차입니다.

마스터에서 :

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

그리고 마지막 명령 의 결과 값을 어딘가에 복사하십시오 .

클라이언트에 대한 연결을 닫지 않고 (읽기 잠금을 해제하므로) 명령을 실행하여 마스터 덤프를 가져 오십시오.

mysqldump -u root -p --all-databases > /a/path/mysqldump.sql

덤프가 아직 종료되지 않은 경우에도 잠금을 해제 할 수 있습니다. 이를 수행하려면 MySQL 클라이언트에서 다음 명령을 수행하십시오.

UNLOCK TABLES;

이제 scp 또는 선호하는 도구를 사용하여 덤프 파일을 슬레이브에 복사하십시오.

노예에서 :

mysql에 대한 연결을 열고 다음을 입력하십시오.

STOP SLAVE;

이 콘솔 명령으로 마스터의 데이터 덤프를로드하십시오.

mysql -uroot -p < mysqldump.sql

슬레이브 및 마스터 로그 동기화 :

RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;

위의 필드 값은 이전에 복사 한 값입니다.

마지막으로 다음을 입력하십시오.

START SLAVE;

입력 후 모든 것이 다시 작동하는지 확인하려면 다음을 수행하십시오.

SHOW SLAVE STATUS;

넌 봐야 해:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

그게 다야!

MySQL 사이트에서 이에 대한 문서가 구식이며 구식 건 (예 : interactive_timeout)으로 가득 차 있습니다. 마스터 내보내기의 일부로 읽기 잠금으로 FLUSH 테이블을 발행하는 것은 일반적으로 LVM 또는 zfs와 같은 스토리지 / 파일 시스템 스냅 샷과 조정될 때만 의미가 있습니다.

mysqldump를 사용하려는 경우 --master-data 옵션을 사용하여 인적 오류를 방지하고 가능한 빨리 마스터의 잠금을 해제해야합니다.

마스터가 192.168.100.50이고 슬레이브가 192.168.100.51이고 각 서버에 고유 한 서버 ID가 구성되어 있고 마스터에 이진 로깅이 있고 슬레이브가 my.cnf에서 읽기 전용 = 1 인 것으로 가정합니다.

덤프를 가져온 직후에 슬레이브가 복제를 시작할 수 있도록 준비하려면 CHANGE MASTER 명령을 실행하되 로그 파일 이름과 위치는 생략하십시오.

slaveserver> CHANGE MASTER TO MASTER_HOST='192.168.100.50', MASTER_USER='replica', MASTER_PASSWORD='asdmk3qwdq1';

슬레이브가 사용할 마스터에 GRANT를 발행하십시오.

masterserver> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.100.51' IDENTIFIED BY 'asdmk3qwdq1';

압축을 사용하고 올바른 이진 로그 좌표를 자동으로 캡처하여 마스터를 화면에서 내 보냅니다.

mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz

replication.sql.gz 파일을 슬레이브에 복사 한 다음 zcat를 사용하여 슬레이브에서 실행중인 MySQL 인스턴스로 가져옵니다.

zcat replication.sql.gz | mysql

슬레이브에 명령을 발행하여 복제를 시작하십시오.

slaveserver> START SLAVE;

선택적으로 슬레이브에서 /root/.my.cnf를 업데이트하여 마스터와 동일한 루트 비밀번호를 저장하십시오.

5.1 이상인 경우 먼저 마스터의 binlog_format을 MIXED 또는 ROW로 설정하는 것이 가장 좋습니다. 기본 키가없는 테이블의 경우 행 기록 이벤트가 느려집니다. 일반적으로 binlog_format = statement (마스터에서)의 대체 (및 기본) 구성보다 우수합니다. 슬레이브에서 잘못된 데이터를 생성 할 가능성이 적기 때문입니다.

복제를 필터링해야하지만 (아마도 안 됨) 슬레이브 옵션 인 replicate-wild-do-table = dbname. % 또는 replicate-wild-ignore-table = badDB. %로 수행하고 binlog_format = row 만 사용하십시오.

이 프로세스는 mysqldump 명령 동안 마스터에 대한 전역 잠금을 유지하지만 마스터에 영향을 미치지 않습니다.

mysqldump --master-data --all-databases --single-transaction (InnoDB 테이블 만 사용하기 때문에)을 사용하고 싶다면 MySQL Enterprise Backup 또는 xtrabackup이라는 오픈 소스 구현을 사용하는 것이 좋습니다. 퍼 코나)

슬레이브 (Server2)에 직접 쓰지 않는 한 유일한 문제는 Server2에 연결이 끊어진 이후 발생한 업데이트가 누락 된 것입니다. "START SLAVE;"로 슬레이브를 다시 시작하기 만하면됩니다. 모든 것을 속도로 되돌려 야합니다.

Maatkit utilits가 도움이된다고 생각합니다! mk-table-sync를 사용할 수 있습니다. 이 링크를 참조하십시오 : http://www.maatkit.org/doc/mk-table-sync.html

나는이 질문에 매우 늦었지만이 문제가 발생하여 많은 검색을 한 후 Bryan Kennedy에서 다음 정보를 찾았습니다 .http : //plusbryan.com/mysql-replication-without-downtime

마스터에서 다음과 같은 백업을 수행하십시오.
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data = 2 -A> ~ / dump.sql

이제 파일의 헤드를 검사하고 MASTER_LOG_FILE 및 MASTER_LOG_POS의 값을 적어 두십시오. 나중에 필요할 것입니다 : head dump.sql -n80 | grep "MASTER_LOG"

"dump.sql"파일을 슬레이브로 복사하고 복원하십시오 : mysql -u mysql-user -p <~ / dump.sql

슬레이브 mysql에 연결하고 CHANGE MASTER TO MASTER_HOST = 'master-server-ip', MASTER_USER = 'replication-user', MASTER_PASSWORD = 'slave-server-password', MASTER_LOG_FILE = '상기 값', MASTER_LOG_POS = 위의 값; 슬레이브 시작;

슬레이브의 진행 상황을 확인하려면 : SHOW SLAVE STATUS;

모든 것이 정상이면 Last_Error가 비어 있고 Slave_IO_State는 "마스터가 이벤트를 기다리는 중"을보고합니다. 뒤가 얼마나 먼지를 나타내는 Seconds_Behind_Master를 찾으십시오. YMMV. :)

다음은 일반적으로 mysql 슬레이브가 동기화되지 않을 때 수행하는 작업입니다. mk-table-sync를 살펴 봤지만 위험 섹션이 무섭다고 생각했습니다.

마스터에서 :

SHOW MASTER STATUS

출력 된 열 (File, Position)은 우리에게 조금 사용될 것입니다.

슬레이브에서 :

STOP SLAVE

그런 다음 마스터 DB를 덤프하여 슬레이브 DB로 가져 오십시오.

그런 다음 다음을 실행하십시오.

CHANGE MASTER TO
  MASTER_LOG_FILE='[File]',
  MASTER_LOG_POS=[Position];
START SLAVE;

여기서 [파일] 및 [위치]는 "SHOW MASTER STATUS"에서 출력 된 값입니다.

도움이 되었기를 바랍니다!

다윗의 대답에 따르면 ...

를 사용 SHOW SLAVE STATUS\G하면 사람이 읽을 수있는 결과를 얻을 수 있습니다.

때로는 노예에게도 킥을 주어야합니다

시험

stop slave;    
reset slave;    
start slave;    
show slave status;

아주 자주, 노예, 그들은 단지 갇힌 사람을 얻는다 :)

다음은 희망적으로 다른 사람들을 도울 완전한 답변입니다 ...

마스터와 슬레이브를 사용하여 mysql 복제를 설정하고 싶습니다. 알고있는 유일한 것은 로그 파일을 사용하여 동기화하는 것입니다. 슬레이브가 오프라인 상태가되고 동기화되지 않으면 이론적으로는 다시 연결하면됩니다. 사용자 malonso가 언급했듯이 로그 파일을 마스터에서 계속 중단하고 로그 파일을 읽습니다.

다음은 마스터 및 슬레이브를 구성한 후의 테스트 결과입니다. http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html ...

권장되는 마스터 / 슬레이브 구성을 사용하고 슬레이브 (Mysql-server 5.x에 관한 한)에 쓰기를하지 않는 경우. "START SLAVE;"를 사용할 필요조차 없었습니다. 그것은 단지 그 주인에게 붙잡 혔습니다. 그러나 기본 88000은 60 초마다 재 시도하므로 기본적으로 슬레이브를 시작하거나 다시 시작해야 할 수도 있습니다. 어쨌든, 노예가 오프라인으로 돌아가고 다시 백업되는지 알고 싶었던 저와 같은 사람들에게는 수동 개입이 필요합니다. 아니, 그렇지 않습니다.

원본 포스터가 로그 파일에서 손상되었을 수 있습니까? 그러나 아마도 아마도 하루 동안 서버가 오프라인 상태가 아닙니다.

/usr/share/doc/mysql-server-5.1/README.Debian.gz에서 가져 왔는데 비 데비안 서버에서도 마찬가지입니다.

* 복제에 대한 추가 정보
================================
MySQL 서버가 복제 슬레이브로 작동하는 경우
--tmpdir을 설정하여 메모리 기반 파일 시스템의 디렉토리를 가리 키거나
서버 호스트가 다시 시작될 때 지워지는 디렉토리 복제
슬레이브는 머신 재시작 후에도 임시 파일이 필요합니다.
임시 테이블 또는 LOAD DATA INFILE 조작을 복제 할 수 있습니다. 만약
서버가 다시 시작되면 임시 파일 디렉토리의 파일이 손실됩니다.
복제가 실패합니다.

sql과 같은 것을 사용할 수 있습니다 : 'tmpdir'과 같은 변수 표시; 알아 내다.

이 오류를 포함하기 위해 인기있는 답변에 추가 :

"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",

한 번에 슬레이브에서 복제 :

하나의 터미널 창에서 :

mysql -h <Master_IP_Address> -uroot -p

연결 후

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

상태는 다음과 같이 나타납니다. 위치 번호가 다릅니다.

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      98  | your_DB      |                  |
+------------------+----------+--------------+------------------+

" 다른 터미널 사용 "에 설명 된 것과 유사한 덤프를 내보내십시오 !

종료하고 자신의 DB (슬레이브)에 연결하십시오.

mysql -u root -p

아래 명령을 입력하십시오 :

STOP SLAVE;

언급 한대로 덤프를 반입하고 (물론 다른 터미널에서도) 아래 명령을 입력하십시오.

RESET SLAVE;
CHANGE MASTER TO 
  MASTER_HOST = 'Master_IP_Address', 
  MASTER_USER = 'your_Master_user', // usually the "root" user
  MASTER_PASSWORD = 'Your_MasterDB_Password', 
  MASTER_PORT = 3306, 
  MASTER_LOG_FILE = 'mysql-bin.000001', 
  MASTER_LOG_POS = 98; // In this case

일단 로그되면 server_id 매개 변수를 설정하십시오 (보통 새 / 복제되지 않은 DB의 경우 기본적으로 설정되지 않음).

set global server_id=4000;

이제 노예를 시작하십시오.

START SLAVE;
SHOW SLAVE STATUS\G;

출력은 설명 된 것과 동일해야합니다.

  Slave_IO_Running: Yes
  Slave_SQL_Running: Yes

참고 : 일단 복제되면 마스터와 슬레이브는 동일한 비밀번호를 공유합니다!

LVM을 사용하여 슬레이브 재 구축

Linux LVM을 사용하여 MySQL 슬레이브를 재 구축하는 데 사용하는 방법은 다음과 같습니다. 이를 통해 마스터에서 중단 시간을 최소화하면서 일관된 스냅 샷을 보장 할 수 있습니다.

마스터 MySQL 서버에서 innodb max dirty pages percent를 0으로 설정하십시오. 이렇게하면 MySQL이 모든 페이지를 디스크에 쓰게되어 재시작 속도가 크게 빨라집니다.

set global innodb_max_dirty_pages_pct = 0;

더티 페이지 수를 모니터하려면 다음 명령을 실행하십시오.

mysqladmin ext -i10 | grep dirty

숫자가 감소를 멈 추면 계속 진행할 수 있습니다. 다음으로 이전 bin 로그 / 릴레이 로그를 지우려면 마스터를 재설정하십시오.

RESET MASTER;

lvdisplay를 실행하여 LV 경로를 얻습니다.

lvdisplay

출력은 다음과 같습니다

--- Logical volume ---
LV Path                /dev/vg_mysql/lv_data
LV Name                lv_data
VG Name                vg_mysql

명령을 사용하여 마스터 데이터베이스 종료

service mysql stop

다음으로 스냅 샷을 작성하면 mysql_snapshot이 새로운 논리적 볼륨 이름이됩니다. binlog가 OS 드라이브에 있으면 스냅 샷도 필요합니다.

lvcreate --size 10G --snapshot --name mysql_snapshot /dev/vg_mysql/lv_data

명령으로 마스터를 다시 시작하십시오.

service mysql start

더티 페이지 설정을 기본값으로 복원

set global innodb_max_dirty_pages_pct = 75;

lvdisplay를 다시 실행하여 스냅 샷이 있고 표시되는지 확인하십시오.

lvdisplay

산출:

--- Logical volume ---
LV Path                /dev/vg_mysql/mysql_snapshot
LV Name                mysql_snapshot
VG Name                vg_mysql

스냅 샷 마운트

mkdir /mnt/mysql_snapshot
mount /dev/vg_mysql/mysql_snapshot /mnt/mysql_snapshot

기존 MySQL 슬레이브가 실행중인 경우 중지해야합니다.

service mysql stop

다음으로 MySQL 데이터 폴더를 지워야합니다.

cd /var/lib/mysql
rm -fr *

마스터로 돌아 가기 이제 스냅 샷을 MySQL 슬레이브로 재 동기화

rsync --progress -harz /mnt/mysql_snapshot/ targethostname:/var/lib/mysql/

rsync가 완료되면 스냅 샷을 마운트 해제하고 제거 할 수 있습니다

umount /mnt/mysql_snapshot
lvremove -f /dev/vg_mysql/mysql_snapshot

이전 복제 사용자가 없거나 비밀번호를 알 수없는 경우 마스터에서 복제 사용자를 작성하십시오.

GRANT REPLICATION SLAVE on *.* to 'replication'@'[SLAVE IP]' identified by 'YourPass';

mysql 사용자가 / var / lib / mysql 데이터 파일을 소유하고 있는지 확인하여 다음 명령을 생략 할 수 있습니다.

chown -R mysql:mysql /var/lib/mysql

다음으로 binlog 위치를 기록하십시오.

ls -laF | grep mysql-bin

당신은 같은 것을 볼 것입니다

..
-rw-rw----     1 mysql mysql  1073750329 Aug 28 03:33 mysql-bin.000017
-rw-rw----     1 mysql mysql  1073741932 Aug 28 08:32 mysql-bin.000018
-rw-rw----     1 mysql mysql   963333441 Aug 28 15:37 mysql-bin.000019
-rw-rw----     1 mysql mysql    65657162 Aug 28 16:44 mysql-bin.000020

여기서 마스터 로그 파일은 순서대로 가장 높은 파일 번호이고 bin 로그 위치는 파일 크기입니다. 다음 값을 기록하십시오.

master_log_file=mysql-bin.000020
master_log_post=65657162

다음으로 슬레이브 MySQL을 시작하십시오

service mysql start

다음을 실행하여 슬레이브에서 change master 명령을 실행하십시오.

CHANGE MASTER TO 
master_host="10.0.0.12", 
master_user="replication", 
master_password="YourPass", 
master_log_file="mysql-bin.000020", 
master_log_pos=65657162; 

마지막으로 노예를 시작

SLAVE START;

슬레이브 상태 확인 :

SHOW SLAVE STATUS;

슬레이브 IO가 실행 중이고 연결 오류가 없는지 확인하십시오. 행운을 빕니다!

BR, Juha Vehnia

나는 최근에 여기에있는 내 블로그에 이것을 썼습니다 ... 더 자세한 내용은 없지만 이야기는 동일합니다.

http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html

이 문제를 빠르게 해결하기 위해 스크립트로 GitHub 저장소를 만들었습니다. 몇 가지 변수를 변경하고 실행하기 만하면됩니다 (먼저 스크립트가 데이터베이스 백업을 생성 함).

나는 이것이 당신 (그리고 다른 사람들도)을 돕기를 바랍니다.

MySQL 마스터-슬레이브 복제를 재설정 (재 동기화)하는 방법

우리는 MySQL의 마스터 마스터 복제 기술을 사용하고 있으며 하나의 MySQL 서버가 네트워크에서 1이라고 말하면 연결이 복원 된 후 다시 연결되고 네트워크에있는 서버 2에서 커밋 된 모든 레코드가 전송됩니다 복원 후 연결이 끊어진 서버 1로 연결됩니다. MySQL의 슬레이브 스레드는 기본적으로 60 초마다 마스터에 연결하기 위해 재 시도합니다. 이 속성은 MySQL에서 플래그 "master_connect_retry = 5"로 변경 될 수 있으며 여기서 5는 초입니다. 이것은 5 초마다 재 시도를 원한다는 것을 의미합니다.

그러나 연결이 끊어진 서버가 중복 키를 얻을 때 데이터베이스에서 커밋을 표시하지 않는지 확인해야합니다. 키 오류 오류 코드 : 1062

마스터 :

mysqldump -u root -p --all-databases --master-data | gzip > /tmp/dump.sql.gz  

scp master:/tmp/dump.sql.gz slave:/tmp/ 덤프 파일을 슬레이브 서버로 이동

노예:

STOP SLAVE;

zcat /tmp/dump.sql.gz | mysql -u root -p

START SLAVE;
SHOW SLAVE STATUS;  

참고 :
마스터 SET GLOBAL expire_logs_days = 3에서 슬레이브 문제가있는 경우 3 일 동안 binlog를 유지하도록 실행할 수 있습니다.