HDD 上に ZFS があり、SSD 上に ZIL SLOG があります。
関係があるなら、SSD 上に LARC キャッシュもあります。
SSD の障害によってデータの不整合 (write()単一スレッドで 2 つの操作が連続して実行され、その内容が混在するなど、POSIX ファイルシステム呼び出しの結果ルールに準拠していない状態) が発生しないようにするには、どのように再構成すればよいでしょうか。
SSD を復元せずに HDD のバックアップ スナップショットを復元した場合に、ZFS 上の PostgreSQL DB が不整合にならないようにしたいと考えています。(PostgreSQL にバグがない限り、POSIX 準拠のファイルシステムによって DB が不整合にならないように、PostgreSQL を同期するための対策を講じています。)
答え1
ZIL は、安定したディスクへのコミットされていない書き込みを短期間だけ保持することになっています。電源障害と SSD 障害が同時に発生した場合、これは問題になる可能性があります。ただし、他の状況が正常であるときに SSD に障害が発生した場合、ZFS は RAID ライトバックに相当するモードから RAID ライトスルー モードに移行するだけです。パフォーマンスは低下する可能性がありますが、すぐに破損することはありません。
ZIL のポイントは、変更を不揮発性ストレージにすばやく書き込んで、アプリケーションにすぐに続行するように指示できるようにすることです。変更が安定したストレージ (ディスク) に書き込まれる前に電源が落ちた場合は、電源投入後に zfs ボリュームが次にマウントされたときに、変更が ZIL から安定したストレージにコピーされます。
ファイルシステムのスナップショットの重要な点は、アクティブに書き込みが行われていないファイルシステムの安定したバージョンをコピーすることです。これは ZIL とは何の関係もありません。スナップショットは書き込み可能ではないため、ZIL には保留中の書き込みはありません。
そうは言っても、postgreSQL はファイルシステムのスナップショットを復元することに満足しないかもしれません。postgreSQL に ZFS スナップショットの直前にスナップショットまたは一時停止するように指示しない限り、zfs スナップショットには部分的な postgreSQL 書き込みが含まれる可能性があり、これが問題になる可能性があります。postgreSQL データベースを適切にバックアップする方法について、別の質問をすることをお勧めします。(...他の誰かがここでそれについて説明しない限り。)
答え2
SLOG はデータセットから独立していると考えることができます。つまり、pg データがディスクにフラッシュされると、データセットのスナップショットを作成してバックアップすることができ、ログ デバイスの有無にかかわらず、スナップショットを (同じプールまたは別のプールに) 復元できます。
プールからlog(SLOG) または(L2ARC) デバイスを物理的に削除する場合は、当然ながら、まず論理的に削除する必要があります。cache
zpool remove [poolname] [logdevice|cachedevice]
（見るman zpool-remove）
SLOG を適切に削除しないと、次回の再起動時にプールのインポートに失敗する可能性があります。この状態からの回復は、(SLOG にフラッシュされていないデータがない場合) かなり簡単ですが、データの破損を受け入れずに回復するのは困難/不可能です。2 つの SLOG デバイスをミラー ペアとして追加することが推奨される理由は、まさにこの問題を回避するためです。つまり、プールを破損させる可能性のある単一障害点を回避するためです。
私は、テキストダンプの方がバイナリよりも信頼性が高いと考えているため、定期的にバックアップ（独自のスナップショットとバックアップスケジュールを持つ別のデータセットへのバックアップ）を作成しますpg_dump。特に、バイナリスナップショットがPostgreSQLサーバーがまだ実行されている間に作成された場合（サーバー5月スナップショットが作成された時点では、メモリ内のすべてがディスクに書き込まれているわけではありませんが、サーバーをシャットダウンすると、再起動に必要なすべてのものが同じ状態で書き込まれます。また、重要なデータに関しては、バックアップが多いほど良いからです。
ところで、私は数年前に、すべてをダンプし、次にpgグローバル（ロールなど）、次に各データベースとテーブルのスキーマ、次にデータ（COPY ... FROMとして）、そして列挿入として再度データをダンプする簡単なpostgresqlバックアップスクリプトを書きました。私は約20年間、そのバリエーションを使用しています。私はそのバージョンをServerFaultに投稿しました。PostgreSQL データベースのバックアップを自動化する最良の方法は何ですか?2009年に遡ります。
そのバージョンでは、おそらくいくつかの小さな調整が必要です (特に、DBS=( $($PSQL --list --tuples-only ...) )データベースのリストを取得する行)。また、バックアップ ディレクトリが独自のスナップショット スケジュールを持つ zfs データセットである場合は、古いバックアップを削除するために YMD サブディレクトリや は必要ありません。また、またはを にfind ... -mtime +30 ...パイプする必要はなく、バックアップ データセットで圧縮を使用するだけです。pg_dumppg_dumpallgzip