突然の停電とSIGKILLランチャーの違いは何ですか？
データベースを使用するマイクロサービスがあります。私は突然の停電（通常のシャットダウンではありませんが、UPSなしで電源プラグを抜くこと）をシミュレートする自動化されたテストを作成する任務を務めました。その目的は、停電後もデータベースがまだ一貫していることを確認することです。を使用する予定ですkillall -9 microservice_name。このシミュレーションはどれほど良いですか？どちらかを行う方が有害ですか？特にファイルバッファをフラッシュ（またはフラッシュしない）することについて心配していますが、他の違いがありますか？
ボーナス質問：実際の電力ではなく、仮想マシンの突然のシャットダウンを比較するとどうなりますか？
答え1
プロセスの観点から大きな違いはありません。 ＡはSIGKILL（可能であれば）要求せずに直ちにプロセスを終了する。
だが周辺の話は違った。ディスクへの書き込みを検討してください。プロセス呼び出しがwrite()成功すると、オペレーティングシステムに責任が渡されます。今プロセスを終了しても、作成されたデータは失われません。これを保証するのはOSの使命です。ただし、オペレーティングシステムがまだデータをディスクに送信していないか、ディスクがまだ永続ストレージに書き込まれていない可能性があるため、データはまだ永続ストレージに安全に保存されません。
システム全体のプラグを抜くと、オペレーティングシステムのすべてのメモリキャッシュ（通常は完全なシャットダウンを保証するためにUPSを使用する必要がある理由）とストレージデバイスの揮発性キャッシュ（高価な製品に独自のバッテリがある理由）の両方が消去されます。 。
仮想マシンを強制的にシャットダウンするのはその間どこかにあります。仮想マシンマネージャがシャットダウンすると、その中のすべてのコンテンツが失われます。ただし、ホストシステムに送信されたすべてのエントリは安全でなければなりません。
どれだけ大きな違いがあるかは、シナリオ（およびリスク評価）によって異なります。ハードウェア障害に対する回復力のある低レベルのデータベースをテストする場合は、実際にプラグを抜いてテストすることが重要です。ただし、この種のタスクを処理するデータベースを使用する高度なアプリケーションをテストする場合は、すべてを直接テストする必要はありません。
私はすべての深刻なデータベースアプリケーションが少なくとも努力する具体的には、SQLiteを使用して停電を賢く処理するためにこれを行うための作業を説明する多くの記事があります。https://www.sqlite.org/atomiccommit.htmlそしてhttps://www.sqlite.org/howtocorrupt.html。
注：私はSIGKILLに「できれば」と言いました。オペレーティングシステムによっては、SIGKILLがプロセスを終了できない場合があります。たとえば、Linuxでは、「ノンストップスリープ」状態（D）のプロセスは解決されるまで終了しません。たとえば、次を参照してください。SIGKILL信号を送信するときにプログラムは何をしますか？そして終了できないジョブを終了する方法（無中断？）