MySQLでsync_binlogをオンにすると、こんにちはディスクI / Oとクラッシュ
非常に奇妙な動作をするMySQLマスターサーバー（MariaDB 10.0.17）があります。それからデータをフェッチするスレーブが1つあります。
set global sync_binlog = 1、サーバーI/Oが非常に高くなり、数時間後にサーバーがクラッシュします。以下のグラフでは、15：20にサーバーがクラッシュします。次に、15：20から15:40まで、1億2000万行を超えるMyISAMテーブルを回復しています。その後、15：40に通常の動作に戻ります。 sync_binlogのブート構成は0です
16:15、私はset global sync_binlog = 1、I/Oが再び上昇します。 16:45、私はset global sync_binlog = 1とI/Oがダウンします。
なぜこれが起こっているのですか？この高いI/Oとクラッシュを回避する方法はありますか？
MySQLドキュメンテーションの内容 sync_binlog を覚えておいてください。
この変数の値が0より大きい場合、MySQLサーバーは、sync_binlogコミットグループがバイナリログに書き込まれた後、バイナリログをディスクに同期します（fdatasync（）を使用）。 sync_binlogのデフォルト値は0で、ディスクと同期しません。この場合、サーバーはオペレーティングシステムに依存して、他のファイルと同様にバイナリログの内容を時々フラッシュします。クラッシュが発生した場合、バイナリログから最大1つのコミットグループを失うため、値1が最も安全な選択です。ただし、これは最も遅い選択でもあります（ディスクにバッテリバックアップ式のキャッシュがあり、同期が非常に高速にならない限り）。
どうやら、あなたはバイナリログへの1回の書き込み操作で多くのコミットグループを書いています。
- sync_binlog を0に設定すると、OSがコミットグループをディスクにフラッシュします（独自の時間に）
- sync_binlog を1に設定すると、mysqldは各書き込み時にコミットグループをディスクにフラッシュします
sync_binlog > 1を設定して、mysqldのバイナリログのフラッシュを抑制できます。
sync_binlog を設定すると、ディスクI/Oが増えるのではなく、増えることが予想されます。
DBサーバーがベアメタルサーバーの場合は、ディスクコントローラーを確認し、バッテリーを交換するか、より良いディスクコントローラーを入手する必要があります。
UPDATE 2015-04-02 10:57 EST
あなたのコメント でSSDを使用していると述べました。私は1年以上前に（ SSD上のMySQL-欠点は何ですか？ ）投稿を書いたが、SSDはシーケンシャル書き込みにそれほど適していないと述べた。あなたの場合、順次書き込みはバイナリログで発生しています。 SSD書き込みパフォーマンスは、シーケンシャル書き込みとランダム書き込みに関係なく同じです。 SSDではなくHDDにバイナリログを移動することを検討します。