sync_binlog 매개 변수 mysql

Question

sync_binlog 매개 변수에 대한 설명서를 살펴본 결과 sync_binlog 매개 변수 설명서에 불일치가 있음을 발견했습니다.

는

문서는 여기 http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_sync_binlog는 말한다 : 충돌의 경우에 당신은 바이너리 로그에서 그룹을 커밋 대부분 하나 잃어 버려

가

1의 값이 가장 안전한 선택입니다.

이는 본질적으로 데이터가 업데이트되지만 binlogs에는 없을 수 있음을 의미합니다.

그러나, 여기 http://dev.mysql.com/doc/refman/5.6/en/binary-log.html 바이너리 로그 설명서에 말한다 :

예를 들어, 당신이 InnoDB 테이블을 사용하고 MySQL 서버가 COMMIT 문을 처리하는 경우, 그것은 순서로 바이너리 로그에 많은 준비가 트랜잭션을 기록, 바이너리 로그를 동기화 한 다음이 트랜잭션을 InnoDB에 커밋한다. 이 두 작업 사이에 서버가 충돌하면 트랜잭션은 다시 시작할 때 InnoDB에 의해 롤백되지만 여전히 바이너리 로그에 존재합니다.

기본적으로 트랜잭션이 처음에는 binlog에 기록 된 다음 InnoDB에 커밋됨을 의미하므로 크래시 발생시 행이 binlog에 있지만 데이터베이스에는 존재하지 않을 가능성이 있습니다.

나는 mysql 포럼에서이 질문을하고 응답을 기다리고 있지만,이 매개 변수를 사용하는 사람이 다음 두 가지 동작 중 어느 부분에 대한 세부 정보를 줄 수 있는지 정말 고맙겠습니다.

감사합니다.

Answer 1

서버 자체에서 동기화하는 것은 복제 설정에서 슬레이브와 동기화하는 것과 다릅니다.

바이너리 로그 (따라서,하지 sync_binlog 및 "그룹 커밋") 이노 테이블 마스터에 의 무결성 사용하지 된다. 그러나 사용자가 지적한대로 은입니다.

로그가 로컬 시스템에 기록 된 후에 사용자가 언급 한 충돌이 발생하므로 로컬 시스템 (복구시 다시 복구 될 수 있음)이 복구 될 수 있습니다. 그러나 "그룹 커밋"은 노예들에게 그것을하지 않을 수도 있습니다. binlog에 도착하더라도 슬레이브 (모든 슬레이브가 훨씬 적음)가 아직 값을 얻지 못했다는 것을 보장하지 않습니다.

"semi-sync"복제를 참조하십시오. 여기서 적어도 하나의 슬레이브는 COMMIT가 ack 될 때까지 확인해야합니다.

트랜잭션이 슬레이브에 도착할 수 있지만 마스터에서 롤백 될 수 있음을 나타내는 내용을 인용했습니다. 나는이 사건에 공개 된 버그가 있다고 생각한다.

GTID도이 문제를 혼동합니다. 선행 GTID를 작성하고 업데이트해야하는 따옴표가있을 수 있습니다.

http://bugs.mysql.com에 신고 해주세요.