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つのバイナリログからグループをコミットで最も失うので、1の値が最も安全な選択肢です。

これは、基本的にデータが更新されるが、binlogsには存在しない可能性があることを意味します。

はしかし、ここでhttp://dev.mysql.com/doc/refman/5.6/en/binary-log.htmlバイナリログのマニュアルに書かれています：

は、たとえば、あなたがInnoDBテーブルを使用していて、MySQLサーバがCOMMIT文を処理する場合、それは順番にバイナリログに多くの準備されたトランザクションを書き込み、バイナリログを同期させた後、このトランザクションをInnoDBにコミットします。これらの2つの操作の間にサーバがクラッシュした場合、トランザクションはInnoDBによってロールバックされますが、バイナリログにはまだ存在します。

これは基本的にトランザクションが最初にbinlogで書かれ、その後InnoDBにコミットされたことを意味します。したがって、クラッシュの場合、行はbinlogにありますが、データベースには存在しません。

私はこの質問をmysqlフォーラムで尋ねて、応答を待っていますが、このパラメータを使用している人が次の2つの動作のどちらが正しいかを詳しく説明できますか？

あなたのお手伝いをお待ちしております。

Answer 1

サーバー自体の同期は、複製セットアップでのスレーブとの同期とは異なります。

バイナリログ（したがって、ないsync_binlogおよび「グループコミット」）InnoDBテーブルマスターにの完全性にを使用しないれます。しかし、あなたが指摘しているように、それはであり、それはです。

ログはローカルマシンに書き込まれた後にクラッシュするため、ローカルマシン（復旧した場合）が復旧できます。しかし、 "グループコミット"は奴隷にすることはできません。 binlogになっても、スレーブ（ずっと少ない、すべてのスレーブ）がまだ価値を得ていることは保証されません。

「semi-sync」レプリケーションも参照してください。ここでは、COMMITがackされる前に少なくとも1つのスレーブが確認応答する必要があります。

あなたは、トランザクションがスレーブに到達してもマスター上でロールバックできることを意味するものを引用しました。私はその事件に未解決のバグがあると思う。

GTIDも問題を混乱させます。それは、あなたが前のGTIDを作成して更新する必要がある引用のいくつかである可能性があります。

http://bugs.mysql.comに報告することを検討してください。