Master와 Slave의 데이터베이스가 다른 경우 Mysql DB를 다시 동기화하려면 어떻게 해야 합니까?

Master와 Slave의 데이터베이스가 다른 경우 Mysql DB를 다시 동기화하려면 어떻게 해야 합니까?

MysqlServer1마스터로서 동작하고 있습니다.
MysqlServer2는 슬레이브로서 동작하고 있습니다.

현재 마스터에서 슬레이브로 DB 복제가 진행 중입니다.

Server2네트워크에서 삭제되고 1일 후에 다시 연결합니다.그 후 마스터와 슬레이브의 데이터베이스가 일치하지 않습니다.

마스터에서 슬레이브로 가져온 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 등)으로 가득 차 있습니다.마스터 내보내기의 일부로 Read Lock이 포함된 플래시 테이블을 발행하는 것은 일반적으로 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=스테이트먼트(마스터 상)의 대체(기본) 구성보다 좋습니다.

복제를 필터링해야 하지만 필터링해서는 안 되는 경우에는 slave 옵션 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(Percona의 courtesy)이라는 오픈 소스 구현을 사용하는 것이 좋습니다.

슬레이브(Server2)에 직접 쓰는 경우를 제외하고 유일한 문제는 Server2가 접속 해제 후 발생한 업데이트가 누락되어 있다는 것입니다.「START SLAVE;」를 사용해 슬레이브를 재기동하는 것만으로, 모든 것이 정상으로 돌아옵니다.

마트킷 유틸리티가 도움이 될 것 같아요!mk-table-sync 를 사용할 수 있습니다.다음 링크를 참조하십시오.http://www.maatkit.org/doc/mk-table-sync.html

나는 이 질문에 매우 늦었지만, 나는 이 문제에 직면했고, 많은 검색 끝에 Bryan Kennedy로부터 이 정보를 발견했다: http://plusbryan.com/mysql-replication-without-downtime

마스터에서 다음과 같이 백업을 수행합니다.
sqlmysqldump --sqdump-lock-transaction --sqdump-blob --master-data=2 -A > ~/sqdump.sql

이제 파일 헤드를 살펴보고 MASTER_LOG_FILE 및 MASTER_LOG_POS 값을 적어둡니다.나중에 head dump.sql -n80 | grep "MASTER_LOG" 가 필요합니다.

"dump.sql" 파일을 슬레이브에 복사하여 복원합니다.mysql - u mysql - user - p < ~ / dump . sql

슬레이브 mysql에 연결하고 위의 '마스터_호스트='마스터-서버-ip', 'MASTER_USER='replication-user', 'MASTER_PASSWORD='slave-server-password', '위의 값', 'MASTER_LOG_FILE='와 같은 명령을 실행합니다.

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

모든 것이 정상일 경우 Last_Error는 공백이 되고 Slave_는 공백이 됩니다.IO_State는 "Waiting for master to send event"를 보고합니다.Seconds_Behind_Master를 찾습니다.이것보다 얼마나 뒤처져 있는지를 나타냅니다.YMMV. :)

mysql 슬레이브가 동기화되지 않을 때 보통 이렇게 합니다.mk-table-sync를 봤는데 리스크 섹션이 무섭다고 생각했어요.

마스터:

SHOW MASTER STATUS

출력되는 열(파일, 위치)은 잠시 후 도움이 됩니다.

슬레이브:

STOP SLAVE

그런 다음 마스터 db를 덤프하고 슬레이브 db로 가져옵니다.

그런 다음 다음을 실행합니다.

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

여기서 [File] 및 [Position]은 위에서 실행한 "SHOW MASTER STATUS"에서 출력되는 값입니다.

이게 도움이 됐으면 좋겠네요!

데이빗의 대답에 이어서...

「」를 사용합니다.SHOW SLAVE STATUS\G을 사용하다

여기 다른 사람들에게 도움이 되길 바라는 완벽한 답이 있습니다.

---

마스터와 슬레이브를 사용하여 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에서 꺼낸 파일입니다.이것은 debian 이외의 서버에서도 유효할 가능성이 있습니다.

* 레플리케이션에 관한 기타 주의사항===============================MySQL 서버가 복제 슬레이브 역할을 하는 경우,set --tmpdir는 메모리 기반 파일 시스템의 디렉토리를 가리키거나서버 호스트가 재시작되면 지워지는 디렉토리.레플리케이션slave는 머신을 재기동하기 위해 임시 파일의 일부를 필요로 합니다.임시 테이블 또는 LOAD DATA INFILE 작업을 복제할 수 있습니다.한다면서버가 재기동하면, 임시 파일 디렉토리에 있는 파일이 없어집니다.복제가 실패합니다.

예를 들어 'tmpdir'와 같은 변수를 표시하는 sql을 사용할 수 있습니다.

일반적인 답변에 추가하여 다음 오류를 포함합니다.

"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;

설명한 대로 (물론 다른 터미널에서) Dump를 Import하고 다음 명령을 입력합니다.

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

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

마스터:

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

scp master:/tmp/dump.sql.gz slave:/tmp/ dump file to slave server(덤프 을 슬레이브 )

슬레이브:

STOP SLAVE;

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

START SLAVE;
SHOW SLAVE STATUS;  

주의:
에서는 실행이 합니다.SET GLOBAL expire_logs_days = 3슬레이브 문제 발생 시 빈로그를 3일간 보관합니다.

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

숫자가 감소하는 것을 멈추면 계속해야 하는 지점에 도달한 것입니다.다음으로 마스터를 리셋하여 오래된 빈 로그/릴레이 로그를 클리어합니다.

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은 새로운 논리볼륨명이 됩니다.OS 드라이브에 binlog가 배치되어 있는 경우는, 이러한 로그도 스냅샷이 됩니다.

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가 실행 중이고 연결 오류가 없는지 확인합니다.행운을 빕니다.

제가 최근에 블로그에 쓴 건데...거기에는 몇 가지 더 자세한 내용이 있지만 이야기는 같다.

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

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

이것이 당신(그리고 다른 사람들도)에게 도움이 되길 바랍니다.

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

가끔은 노예도 발로 차야 해

해라

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

꽤 자주, 노예들, 그들은 그냥 갇히게 된다:)

MySQL의 마스터 마스터 복제 기술을 사용하고 있으며, 1대의 MySQL 서버가 네트워크에서 삭제되었다고 하면 접속이 복원된 후 자동으로 재연결되며, 네트워크 내의 서버 2에서 커밋된 모든 레코드는 복원 후 연결이 끊긴 서버 1로 전송됩니다.MySQL의 슬레이브 스레드는 기본적으로 60초마다 마스터 연결을 재시도합니다.이 속성은 MySQL ha 플래그 "master_connect_sec=5"로 변경할 수 있습니다. 여기서 5는 초 단위입니다.즉, 5초마다 재시도해야 합니다.

그러나 연결이 끊긴 서버가 데이터베이스에서 커밋하지 않음을 확인해야 합니다.키 오류 코드: 1062

언급URL : https://stackoverflow.com/questions/2366018/how-to-re-sync-the-mysql-db-if-master-and-slave-have-different-database-incase-o