%20BBU%20%E3%81%AE%E7%94%A8%E9%80%94%E3%81%AF%E4%BD%95%E3%81%A7%E3%81%99%E3%81%8B%3F.png)
BBU の目的は何でしょうか。私の最初の理解は、停電時にキャッシュがデータをディスクに書き込むことができるようにするというものでした。しかし、一部の仕様では、BBU は最大 72 時間データを保持できるとされています。ディスクにまだ電源が入っている場合、データは数ミリ秒以内にディスクに書き込まれると予想されます。
では、BBU はキャッシュだけでなく、数秒間ディスク全体も保護する必要がありますか? キャッシュ データがキャッシュ内に残って再び電源を待つのではなく、ディスクに書き込まれるので、さらに安全ではないでしょうか? 1 秒ほど経つと、ディスクをシャットダウンできます。
答え1
ディスクに電源は投入されず、マシンがオンラインに戻るまで、キャッシュ内のデータが (この場合) 最大 72 時間保持されるだけです。マシンの電源を再び投入すると、キャッシュの内容がディスクに書き戻されます。
この機能の目的は、停電から保護することだけです。何らかの理由でマシンの電源が落ち、データがディスクに完全に書き出されない場合、バッテリーがキャッシュの内容をマシンを再起動するまで維持します。
ディスクは外部ディスク アレイ内にある場合や、別の電源回路にある場合もあるため、これはディスク用の UPS ではありません。UPS でも故障する可能性があります。
答え2
それはこのように動作します:
ほとんどのオペレーティング システムには、いわゆる「同期書き込み」を可能にするシステム コールがあります。つまり、書き込み操作中に書き込みが完了すると、その書き込みがディスクにコミットされたことが保証されます。
したがって、同期書き込みはキャッシュされません。完了するまでアプリケーションをブロックします。この種の操作は、ディスクが十分にアイドル状態になるまで OS メモリにデータを保持し、その後データを書き込むキャッシュ書き込みよりも明らかに低速です。
データベース ソフトウェアなどの一部の重要なソフトウェアでは、停電時に更新内容が半分書き込まれるとデータベースの整合性に悪影響を与える可能性があるため、重要なデータに対して同期書き込みを実行します。
RAID コントローラは RAID-5 の書き込みが非常に遅いことで有名です。そのため、アプリケーション ソフトウェアが同期書き込みを頻繁に使用する場合は問題になります。このため、RAID-5 コントローラには独自のキャッシュが装備されています。
RAID コントローラは、代わりにデータをキャッシュに書き込み、OS に嘘をついて、データが実際にはまだ RAID キャッシュ内にあるにもかかわらず、データをディスクにコミットしたと伝えます。
しかし、データが RAID コントローラのバッファ内にある間に電源が失われたらどうなるでしょうか? ディスクには半分書き込まれた、おそらく一貫性のないデータが残ることになります。
この動作は同期書き込みの目的に反すると言うかもしれません... キャッシュ書き込みが問題なければ、アプリ ソフトウェアはそもそも同期書き込みを要求しません。
妥協点は次のとおりです。RAID コントローラは、データをディスクにコミットしたことを OS に伝えますが、停電の際にこの重要なデータを保護するために、RAID コントローラには、電源が回復するまでしばらくキャッシュを維持するバッテリーが搭載されています。
したがって、電源が復旧し、ディスクが回転して初期化された後も、バッテリーのおかげでコントローラーのキャッシュにそのデータが保持され、トランザクションをディスクに書き込むことができます。
みんな幸せです。
このため、RAID コントローラでは通常、機能していて充電されたバッテリー ユニットがない限り、書き込みキャッシュを有効にできません。
答え3
最近のディスク コントローラには、通常の 72 時間よりはるかに長い期間データを保持する高速フラッシュ キャッシュが搭載されているものがあり、その容量もかなり大きい (約 1 GB) ことが多いことにも注意してください。部品の詳細が必要な場合は、お知らせください。
答え4
停電はめったに起こらないものの、特に DB サーバーでは 100 ドルのバッテリーを入手することが必須です。取引が有効になっている場合でもこれらの変更がキャッシュからディスクにコミットされる前にサーバーの電源が切れると、クエリが不完全になったり、データが破損したりします。