復元力とパフォーマンスの間には常にトレードオフがあります。
ext4でMySQLを使用している場合、barriers = 1のデフォルトは実際にスローダウンを引き起こしますが、最初のアクションはジャーナリングを無効にすることやdata = writebackをオンにすることではありません。
第一に、復元力が非常に重要な場合、バッテリーバックアップRAIDは確かに価値があります。
私が選択したマウントオプションは、特にバッテリーを使用しないRAIDでの選択です。
/dev/mapper/vg-mysql--data /var/lib/mysql/data ext4 defaults,noatime,nodiratime,barrier=1,data=ordered 0 0
これは、意図的にdata = writebackを使用していないためです。ファイルシステムが破損して「クラッシュおよびジャーナルリカバリの後にファイルに表示される古いデータ」（引用元はman mount）になるリスクを回避したいからです。
I / O関連の設定を完全に復元するためのmy.cnfの理想的な構成は次のとおりです。
[mysqld]
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
パフォーマンスを向上させるために、次の一連のトレードオフを選択しました。
sync_binlog = 0：これは、完全な復元力から変更した最初のMySQL構成です。この理由は、特にbinlog_format=row（残念ながらJiraに必要な）パフォーマンスが大幅に向上するためです。クラスターで十分なMySQLレプリカを使用しているため、電力損失シナリオによってバイナリログが破損した場合、別のレプリカからバイナリコピーを作成します。innodb_flush_log_at_trx_commit = 2：ACIDに完全に準拠するには値1が必要ですが、値2は「コミットごとにログバッファーがファイルに書き出されますが、ディスクへのフラッシュ操作は実行されません。ただし、値が2の場合も、ログファイルは1秒間に1回発生します。プロセスのスケジューリングの問題により、1秒間に1回のフラッシュは毎秒100％発生するとは限りません。（MySQLドキュメントからの引用）- を使用するようにマウントオプションを更新します
data=writeback。これがルートファイルシステムである場合は、カーネルコマンドラインオプションも渡す必要があることに注意してください。coderwallでいくつかの手順をまとめました。
- のさまざまな値をテストします
innodb_flush_method。O_DIRECTは、一部のワークロードでパフォーマンスを改善することが示されていますが、これが環境で機能することは当然ではありません。
- その場合、あなたはまた増加することをお勧めします、のSSDへのアップグレード
innodb_io_capacityなど、とチューンinnodb_adaptive_flushing、innodb_read_io_threads、innodb_write_io_threads、innodb_purge_threads、、その他の可能な設定。