web-dev-qa-db-ja.com

停電によるSSDの破損を防ぐ方法はありますか？

Linux、ローカルWebサーバー、PostgreSQLがインストールされているコンシューマターミナルのグループがあります。問題のあるマシンのフィールドレポートを取得しています。調査の結果、停電が発生してディスクに問題があるようです。

問題はデータベースが破損したり、最近の変更を含むファイルが混乱したりすることだと思っていましたが、他にも奇妙な報告があります。

  • 間違った権限を持つファイル
  • ディレクトリになったファイル（たとえば、index.phpはディレクトリになりました）
  • ファイルになったディレクトリ
  • スクランブルされたデータを含むファイル

データベースが破損する問題がありますが、それは私が予想できることです。私がもっと驚いたのは、より基本的なファイルシステムの問題です。たとえば、アクセス許可やディレクトリへのファイルの変更などです。問題は、最近変更されていないファイル（ソフトウェアコードや構成など）でも発生しています。

SSDの破損の場合、これは「正常」ですか？もともとは、一部の安価なSSDで発生すると考えていましたが、これは有名ブランド（コンシューマーグレード）でも発生しています。

FWIW、私たちは汚れたブートでautofsckを実行していません（理由はわかりません-私は新しいです）。 UPSは一部の場所に設置されていますが、正常に実行されない場合もあります。これは修正する必要がありますが、それでも人々が端末の電源をきれいに落とすことができないなどの理由で、完全な保証はありません。ファイルシステムはext4です。

質問：システムレベルで問題を軽減するためにできることはありますか？

ハードウェアキャッシュをオフにするか、ドライブを同期モードでマウントすることについて言及している記事をいくつか見つけましたが、それがこの場合に役立つかどうかはわかりません（メタデータの破損と最近ではない変更）。また、読み取り専用モードでのファイルシステムのマウントに関するリファレンスも読みました。作成する必要があるため、それはできませんが、それが役立つ場合は、コードと構成用に読み取り専用パーティションを作成できます。

これはドライブの例ですSudo hdparm -i /dev/sda1：

Model=Kingston RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7
ssdelectrical-powerext4corruption
15
Yehosef

突然電源が失われた場合、MLC/TLC/QLC SSDには2障害モードがあります。

  • 実行中およびDRAM内のみの書き込みは失われます。
  • プログラムされているNANDセルの下位ページに保存されている保存データを破壊する可能性があります。

最初の障害状態は明らかです。電源保護がなければ、安定したストレージ（つまり、NAND自体）になく、揮発性キャッシュのみ（DRAM）にあるデータは失われます。同じことが従来のメカニカルディスクでも起こります（それだけでは、fsyncを適切に発行しないファイルシステムで大混乱を引き起こす可能性があります）。

2番目の障害状態はMLC + SSDの問題です。新しいデータを格納するために上位ページビットを再プログラムするとき、予期しない電力損失により下位ビットが破壊/変更される可能性があります（つまり、以前のコミットデータ）。

唯一の真の、そして最も明白な解決策は、ハイエンドRAIDコントローラーによって永遠に行われてきたように、（通常はバッテリー/スーパーキャップを使用して）電力損失から保護されたDRAMキャッシュを統合することです。ただし、これによりドライブのコスト/価格が増加します。コンシューマドライブには通常、電力損失から保護されたキャッシュがありません。むしろ、彼らは次のようなより経済的なソリューションの配列を使用しています。

  • 部分的に保護された書き込みキャッシュ（例：Crucial M500/M550/M600 +）。
  • NANDはジャーナルを変更します（例：Samsungドライブ、SMART PoR属性を参照）。
  • リスクのある以前のデータなしで新しい書き込みを吸収する特別なSLC /疑似SLC NANDリージョン（Sandisk、Samsungなど）。

質問に戻ります。Kingstoneドライブは非常に安価なドライブであり、指定されていないコントローラーを使用しており、基本的に公開仕様はありません。突然の停電で以前のデータが破損したことは、私を驚かせません。残念ながら、ディスクのDRAMキャッシュを無効にしても（コマンドのパフォーマンスが大幅に低下するため）、not以前のデータ（つまり、保存データ）が問題を解決できるため、予期しない電力損失。それらが古いSandforceコントローラに基づいている場合、「正しい」状況下ではドライブ全体のブリックさえ期待できます。

UPSを見直し、中期的にはこれらの古いドライブを交換することを強くお勧めします。

PostgreSQLと他のLinuxデータベースに関する最後の注意：それらはnotディスクのキャッシュを無効にします--notはそうするように期待されるべきです。むしろ、キーデータを安定したストレージにコミットするために、定期的/必須のfsync/FUAを発行します。 very説得力のある理由（つまり、ATA FLUSHES/FUAについてあるドライブ）が存在しない限り、これは物事が行われる方法です。

編集：可能な場合は、ZFSまたはBTRFSとしてチェックサムファイルシステムに移行することを検討してください。少なくとも、ジャーナルチェックサムがあり、最近ではメタデータチェックサムさえあるXFSを検討してください。 EXT4の使用を強制される場合は、起動時にauto-fsckを有効にすることを検討してください（fsck.ext4は破損の修復に非常に優れています）。

14
shodanshok

うん。超安価なSSDを入手しないでください。ローエンドのコンシューマーマーケット以外には、コンデンサーと電力損失に対する完全な保護機能があります。 AMDは実際にはそれ以上の費用はかかりません。

11
TomTom

最初に行うことは、復旧時間と目標復旧時点を定義することです。これらの端末の1つを回復する必要がある期間と、許容できるデータの特定の時点は？おそらく数時間以内に、先週のバックアップに回復できるようにする必要があります。

処理中の書き込みが失われると、あらゆる種類の奇妙なことがファイルに発生する可能性があります。ファイルシステムの優先順位は、独自のメタデータの整合性を維持することであり、データに対して同じ保証を提供しない場合があります。言い換えると、fsckがデータを回復することは保証されていません。その仕事は、マウントするファイルシステムを取得することです。

だから、力。 UPSがシステムを正常にシャットダウンすることをインストール、設定、テストします。これにより、ファイルシステムキャッシュとドライブ自体が書き込むことができます。

そして、ディスクへの書き込みの耐久性。 PostgreSQLの信頼性の章 を読んでください。使用 diskchecker.plそこにリンクされているスクリプトは、クラッシュテストを行い、書き込みが不揮発性ストレージに到達した場合にSSDが嘘をついているかどうかを判断します。損失がある場合は、停電保護機能があることがわかっているSSDと交換することを検討してください。

編集：書き込みキャッシュが有効になったという詳細を追加しました。あなたはそれを無効にすることを試みることができます：hdparm -W0 /dev/sdaまたはハードウェアアレイの適切なコマンド。参照： RHELストレージ管理ガイド 。

ファイルシステムの書き込みバリアは、ジャーナルコミットの順序を強制します。データが完全であることを保証するものではありませんが、揮発性キャッシュを備えたファイルシステムにとってはより安全です。これはデフォルトですが、「バリア」マウントオプションを追加すると、パフォーマンスよりも一貫性を重視することが明確に示されます。

最後に、最後の防衛線。復元テストを実行して、アプリケーションとデータベースを目的の時点に到達できることを確認します。これは、電源障害だけでなく、あらゆる種類のデータ損失に役立ちます。

7
John Mahowald