ディスクのサイレントデータ破損（Silent Data Corruption）とは、ストレージシステムがアプリケーションに損傷したデータを提供する際に、いかなる警告も発せずに行われる現象を指します。例えば、メディアの損傷によりディスク上に不良ブロックが発生し、アプリケーションがそのブロックを読み取ろうとした際に誤ったデータが読み込まれることがあります。
ディスクのサイレントエラーが発生する確率はそれほど高くありませんが、恐ろしい点はエラー発生時に一切警告がないことです。アプリケーションがデータの正確性を検証していない場合、プロセスのクラッシュやデータの損失など、奇妙なアプリケーション異常が引き起こされる可能性があります。データベースのようなアプリケーションにとって、システムの安定性は非常に重要であり、データの損失は許容できません。データの正確性と完全性は、データベースシステムの生命線となります。
OceanBaseデータベースはどのようにディスクのサイレントエラーを防ぐのか
OceanBaseデータベースに保存されるデータには、主に2つの部分があります。1つ目はRedoLog、すなわちトランザクションログであり、RedoLogは再生された後、メモリ内のMemTableを構成します。2つ目はSSTable、すなわちLSM-Tree内の静的データです。MemTableとSSTableは共同でユーザーデータのレプリカを形成します。
マルチレプリカメカニズム
OceanBaseデータベースは分散型データベースとして、マルチレプリカによる災害復旧方式を採用しています。ディスクのサイレントエラーが発生する確率はそれほど高くないため、同一データブロックに対して複数のレプリカで同時にサイレントエラーが発生する可能性は極めて低いです。あるレプリカでディスクのサイレントエラーが発生したことが分かれば、残りの正常なレプリカからデータをコピーしてこのエラーを修復することが可能です。現在、OceanBaseデータベースはレプリカ単位での修復をサポートしており、ディスクのサイレントエラーが発生した場合、運用担当者はまずエラーのあるレプリカを削除し、他のマシンから正しいレプリカを補完することができます。
RedoLogの検証メカニズム
各RedoLogのヘッダーには、そのログのチェックサムが記録されます。ネットワーク転送やログ再生を行う際には、各ログのチェックサムを強制的に検証します。これにより、3つのレプリカに同期されるログが正確かつ一貫していることを保証します。もし1つのログ内のデータにサイレントエラーが発生した場合、そのログは他のレプリカに同期されることはありません。
SSTableの検証メカニズム
SSTableのデータは個々のマクロブロックに格納され、マクロブロックの長さは固定されており2MBです。マクロブロックのヘッダーには、そのマクロブロックのチェックサムが記録されます。マクロブロック内部では複数のミクロブロックに分割され、ミクロブロックの長さは固定されておらず、通常は16KBです。ミクロブロックのヘッダーにも、そのミクロブロックのチェックサムが記録されます。SSTableの読み取りI/Oはミクロブロックを基本単位とし、書き込みI/Oはマクロブロックを基本単位とします。ミクロブロックを読み取る際には、ミクロブロックヘッダーのチェックサムを強制的に検証し、ユーザーが読み取るミクロブロックデータが正確であることを保証します。移行やバックアップなどのマクロブロックを複製するシナリオでは、ターゲット側でマクロブロックを書き込む前にも、マクロブロックのチェックサムを強制的に検証し、書き込まれるデータが正確であることを保証し、ディスクのサイレントエラーの拡散を防ぎます。
データブロックの正確性を読み書き時にチェックするだけでなく、ディスクのサイレントエラーを早期に検出することも望まれます。OceanBaseデータベースでは、バックグラウンドで巡回検査タスクを開始し、定期的に全マクロブロックをスキャンしてそのチェックサムをチェックすることができます。ディスクのサイレントエラーが検出された場合、アラートが発報されます。
コールドバックアップメカニズム
マルチレプリカのデプロイメントシナリオがない場合、または実際に複数のレプリカで同時にディスクのサイレントエラーが発生した場合、どのようにデータを救うべきでしょうか？OceanBaseデータベースはバックアップ・リカバリ機能を提供しており、データをNFSやOSSなどの外部メディアにバックアップすることができます。ディスクのサイレントエラーが発生した後、外部メディアから正しいデータを再びデータベースに復元することが可能です。