なぜinnodb_flush_method = O_DSYNCは、SANベースのストレージでこのようなパフォーマンスの向上を提供するのですか？
私はいくつかの people を見てきましたが、SANでO_DSYNCを使用することをお勧めします。
MySQLドキュメントには、一般的にO_DSYNCについて述べる this があります。
GNU/LinuxとUnixの一部のバージョンでは、Unixのfsync（）呼び出し（InnoDBがデフォルトで使用）を使用してファイルをディスクにフラッシュすると、他の同様のメソッドが驚くほど遅くなります。データベースの書き込みパフォーマンスに不満がある場合は、innodb_flush_methodパラメータをO_DSYNCに設定してみてください。 O_DSYNCフラッシュメソッドは、ほとんどのシステムでパフォーマンスが低下するように見えますが、実際にはそうではない可能性があります。
そして 特に SANでの使用に関して：
InnoDBデータとログファイルがSANに配置されている一部のシステムでは、主にSELECTステートメントを使用する読み取りが多いワークロードの場合、デフォルト値またはO_DSYNCの方が速い場合があります。このパラメーターは、実稼働環境を反映する同じタイプのハードウェアとワークロードで常にテストしてください。
彼らは人がテストすべきだと提案しているが、言葉遣いはとてもうんざりしている（つまり、「一部のシステム、そうかもしれない」）ので、テストをしなくてもデフォルト（fdatasync）のままなら、許されるかもしれない。 （非科学的）テストO_DSYNCがパフォーマンスに多大な利益をもたらすことがわかった-少なくともいくつかの面倒なSELECTクエリでは。
SANを使用するときに、このオプションがこのような利点を提供できる理由を誰かがより詳細に説明できるかどうか疑問に思っていました。 good book はもちろんこのオプションについて説明していますが、SANのコンテキストでは説明していません。
私が使用しています：
- RHEL 6上のInnoDBプラグインを備えたMySQL 5.1（x86_64）
- 仮想化環境（vSphere）; SAN FC相互接続を備えたIaaSプロバイダーによって提供されます
- バリア= 0マウントオプションを使用したext4ファイルシステム
- I/Oスケジューラーは締め切りです
O_DSYNCは、検証なしで書き込みを実行するため、O_DIRECTより高速です。O_DIRECTは偏執的ですが、より一貫性のあるデータです
私はこれについて前に書きました： MySQLの明確化innodb_flush_method変数
私の理解は次のとおりです。歴史的にInnoDBは、大きなバッファープールではうまく拡張できませんでした。したがって、-またはRAM-OSディスクキャッシュはパフォーマンスに大きな影響を与える可能性があります-> O_DIRECTがこれらの環境で正しく実行されなかった理由です（O_DIRECTはOSディスクキャッシュから何の助けも得ないためです）。MySQL5.6これらの問題が解決されており、最近のバージョンでは、バッファープールをRAMの最大75％に設定できます。RAMの大部分がバッファープールに使用される場合-OSディスクキャッシュを使用する理由はありませんInnoDB、したがってO_DIRECTははるかに優れたパフォーマンスを発揮するはずです。例 innodb_flush_method = O_DIRECT vs LVMディスクパーティションを使用するext3でのO_DSYNCパフォーマンスへの影響
TLDR：（SANの有無にかかわらず）最高のパフォーマンスが必要な場合-大量のRAMを取得し、MySQLを5.6または5.7にアップグレードし、innodb_buffer_poolをできるだけ大きく設定して、O_DIRECTを使用します。