ASPECT # 1 : 복제
나는 그렇게 생각하지 않는다
replicate-wild-do-table = db_backup.%
replicate-rewrite-db = db->db_backup
함께 속해 있습니다.
다른 사람들도 이것에 대해 궁금해했습니다
주문 복제 규칙이 처리되면 문제가 발생합니다. 복제 규칙에 대한 MySQL 설명서에 따르면 :
--replicate-rewrite-db 옵션이 지정된 경우 --replicate- * 필터링 규칙을 테스트하기 전에 적용됩니다.
replicate-rewrite-db 의 MySQL 설명서 조차도 말합니다.
--replicate- * 규칙을 테스트하기 전에 데이터베이스 이름 변환이 수행됩니다.
는 replicate-wild-do-table재 작성 후 적용됩니다. 이 순서가 어떻게 든 데이터가 이미있는 테이블에 INSERT를 부과했는지는 놀라운 일이 아닙니다.
데이터가 어떻게 도착했는지 묻고 있습니까?
ASPECT # 2 : mysqldump
mysqldump --single-transaction특정 시점의 데이터 덤프를 수행 하는 가장 좋은 방법 인 것 같습니다. 불행히도, mysqldump --single-transaction아킬레스 건이 있습니다 : ALTER TABLE. 테이블에 ALTER TABLEa DROP TABLE와 같은 명령 이 적용 CREATE TABLE되면 mysqldump가 덤프를 시도한 트랜잭션의 무결성을 손상시킬 수 있습니다. 테이블을 자르고 (MySQL Universe의 DDL) 인덱스 삭제 및 추가 또한 파괴적입니다.
이에 대한 자세한 정보는 MySQL Performance Blog의 Best keeped MySQLDump Secret 에서 확인할 수 있습니다 . 나는 실제로 mysqldump의 트랜잭션의 무결성을 깰 수있는 12 가지 명령을 설명하는 지난 질문 에서이 점을 다루었습니다 : MySQL backup InnoDB
경고
발문
측면 중 하나 또는 둘 다가 다시 작성 규칙 또는 mysqldump의 격리로 인해 존재하지 않아야하는 mysqldump 동안 행이 미끄러 져 들어가는 데 기여했을 수 있습니다.
제안
mysqldump 시작 이후 모든 릴레이 로그의 mysqlbinlog 덤프를 수행하여 슬레이브가 처리 할 모든 INSERT를 확인하고 해당 행이 슬레이브에 이미 존재하는지 확인합니다. 그들이한다면, 아마 두 가지 일을 할 수있을 것입니다 :
1 : 모든 중복 키 오류 건너 뛰기
이것을 슬레이브의 my.cnf에 추가하기 만하면됩니다.
[mysqld]
slave-skip-errors=1062
skip-slave-start
mysql을 다시 시작하십시오. 그런 다음 실행START SLAVE;
모든 중복 키 오류가 무시됩니다. Seconds_Behind_Master0에 도달 하면 해당 줄을 제거하고 mysql을 다시 시작하십시오.
2 : percona 도구 다운로드
필요한 도구는
이것을 사용하여 슬레이브의 차이점을 찾은 다음 수정하십시오.