AUTOINCREMENT로 인해 마스터 복제가 "키 'PRIMAY'에 대한 중복 항목"으로 중단되었습니다.

AUTOINCREMENT로 인해 마스터 복제가 "키 'PRIMAY'에 대한 중복 항목"으로 중단되었습니다.

Master-Master 복제를 사용하여 복제본에 쓰기가 실제 마스터와 동기화되지 않는 상황을 방지하고 마스터를 전환하고자 합니다.단, AUTO INCREMENT 필드에는 이미 알려진 문제가 있어 지금까지 좋은 해결책을 찾지 못해 이 질문을 하고 있습니다.

상황: 양쪽 마스터가 AUTO INCREMENT 필드가 있는 테이블에 INSERT 문을 가져옵니다.양쪽이 동시에 삽입하면(네, 같은 번호의 경우...), 양쪽 모두 다른 마스터로부터의 스테이트먼트를 기동하지 못하고, 레플리케이션프로세스가 정지합니다.

이 문제는 충분히 흔한 문제인 것 같아요. 제가 발견한 현재의 해결책은 불충분합니다.

먼저, 이 문제가 발생했을 때 양쪽 서버에서 기동하기 위한 대책을 나타냅니다(특정 행이 중요하지 않은 경우).

STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; SELECT sleep(0.5); SHOW SLAVE STATUS\G\

이러한 에러가 모두 진행되도록, 필요에 따라서 몇번이나 기동할 수 있습니다.

https://mariadb.com/kb/en/auto_increment/ #replication에서 제안하는 다른 솔루션은 다음과 같습니다.

마스터 또는 Galera에서 AUTO_INCREMENT를 안전하게 사용하려면 시스템 변수 auto_increment_increment 및 auto_increment_offset을 사용하여 각 서버에 고유한 값을 생성해야 합니다.

문제는 이 설정이 모든 테이블에 "구멍"을 만들 때 순차 ID를 사용하지 않는다는 것입니다.

ON DUPLICE가 무언가를 실행하는 것과 같은 상황에 대한 더 나은 해결책이 있습니까?

https://mariadb.com/kb/en/binary-log-formats/을 들여다보면 MIXED mode가 INSERT 스테이트먼트가 안전하지 않다고 생각되지 않는 이유가 궁금해지기도 합니다.

★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★INSERT ON DUPLICATE...복제는 적어도 바이너리 로그에 커밋하고 쓰는 데 걸리는 시간만큼 지연되기 때문입니다.두 인스턴스가 모두 쓰기 가능한 경우 언제든지 "분할 브레인" 효과를 얻을 수 있습니다.

자동 증분 증분을 사용하지 않고 이 문제를 해결하는 방법은 한 인스턴스는 쓰기 가능하고 다른 인스턴스는 읽기 전용으로 만드는 것입니다.마스터를 전환할 필요가 있는 경우는, 양쪽 모두를 읽기 전용으로 짧게 설정하고, 레플리케이션이 완전하게 흐르도록 해 동기화한 후, 2번째 인스턴스를 읽기/쓰기로 설정합니다.

---

위의 질문에 추가한 한 가지 사항에 대한 답변을 업데이트하십시오.

트랜잭션이 다른 인스턴스에서 INSERT를 수행할 때 감지할 수 있는 모드 또는 binlog 형식(예: MIXED)은 없습니다.인스턴스가 소스에서 실행된 내용을 알 수 있는 유일한 방법은 binlog 이벤트를 읽는 것이지만 다른 인스턴스는 트랜잭션을 커밋할 때까지 binlog에 쓰지 않습니다.

분산 시스템에서 충돌을 방지할 수 있는 유일한 방법은 한 인스턴스가 트랜잭션을 시작할 수 있도록 하는 일종의 글로벌 잠금 기능을 사용하는 것입니다.그러나 MySQL 복제는 그렇지 않습니다.

언급URL : https://stackoverflow.com/questions/73605098/master-master-replication-broken-with-duplicate-entry-for-key-primary-due-to