ログファイルにRAID 5を使用することが推奨されないのはなぜですか？
SQL Server Query Performance Tuning をGrant Fritcheyが書いているときに、次の部分を理解するのが難しいことに気付きました：tはRAID 5を避けてください-ログ。書き込みリクエストごとに、RAID 5ディスクアレイでは、RAID 1またはRAID 10に比べて2倍のディスクI/Oが発生します。
RAID 5は、そのパリティ機能によって他のRAIDと区別されることを知っています。つまり、一部のドライブに障害が発生した場合、他のドライブから失われたデータを回復することが可能です。トランザクションログファイルにRAID 5を使用することが推奨されない理由を知りたいのですが。本の説明だけでは十分理解できませんでした。多分誰かが私にそれを説明したり、良い記事を提供したりできます。
トランザクションログの書き込みが発生した場合、それは同期操作です。つまり、ログ書き込みの原因となったアクティビティは、ログI/Oが完了するまで待機してから、実行中の処理を続行する必要があります。その結果、ログの書き込みは、基盤となるストレージの書き込みスループットに非常に敏感です。
あなたが述べたように、RAID-5デバイスへのすべての書き込みにはオーバーヘッドがあります1 データブロックに加えてパリティブロックを計算して書き込む方法。どんなに小さくても、RAID-5が各書き込み操作で実行するこの余分な作業が、ログストレージにRAID-5を使用しないことを推奨する理由です。
1-詳細は このQ＆A
RAID-5は、データにN-1ディスクを使用し、データのXORに1ディスクを使用することで冗長性を維持します（実際には、すべてのパリティに使用される同じディスクではなく、RAID-4です。 RAID-5は、パリティをすべてのディスクに分散し、「ストライプ」境界ごとに変更します。） https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5
最大のRAID-5書き込みオーバーヘッド（そのブロックのパリティディスクの読み取り+再書き込み）は、短い書き込みにのみ適用されます。フルストライプ書き込み（たとえば、大きなシーケンシャルI/Oの一部としてなし sync/flushを小さなステップの後に実行する）では、データストライプからパリティストライプを計算し、それらをすべて並行して書き込むことができます。ディスクから何かを読み取る。
Mustaccioが指摘しているように、トランザクションログの書き込みは、後でディスクへの書き込みを許可する前に、ディスクにヒットする必要があります。 （または、少なくともRAIDコントローラーのバッテリーでバックアップされたメモリ。つまり、永続的になります。）これは通常、それらを大きな連続したフルストライプ書き込みにバッファーできないことを意味します。
最適なケースでは、NディスクRAID-5 sequential書き込み帯域幅は、理論的にはディスクごとの帯域幅時間N-1に等しくなります。 （さらにいくつかのCPU時間、またはXORパリティ計算がハードウェアRAIDコントローラーにオフロードされている場合でもそうではありません。）
悲惨なケースでは、はい、RAID-5は古いデータとパリティを読み取るために追加のディスクI/Oを実行し、古いデータをパリティにXORして（削除するために）更新してから、新しいデータをXORする必要があります。
それだけではないことに注意してください計算大きなオーバーヘッドを追加するパリティ。新しいパリティを計算するために必要なデータは、小さな書き込みの場合、メモリではなくディスク上にある可能性があるということです
RAID-5は、小さな書き込みでは（非常に）悪く、大量の書き込みでは非常に良好（RAID-0とほぼ同じ）で、一般的には読み取りに適しています。
歴史的に、一部のRAIDコントローラーはストライプの全長を読み取ってパリティを更新していましたが、少なくともLinuxソフトウェアRAIDは実際の小さな書き込みに対応するセクターのみを読み取ります。これは一部には役立ちますが、32kや64k（私は思う）のような小さめのストライプサイズは通常は適切です（そのため、フルストライプ書き込みは、メガバイトのデータをバッファーする必要がないため、より一般的です）。
それでも、RAID10やRAID1と比較して、「非常に非常に悪い」から「非常に悪い」へと移行し、書き込み中のブロックを保持する両方のディスクで小さな書き込みが発生する可能性があります。