Immichデータベースのメンテナンスまたは交換が必要な兆候

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Signs That an Immich Database Needs Maintenance or Replacement - Zima Store Online

単に動作が遅いだけのImmichデータベースでは、通常のPostgreSQLメンテナンスやリソースの改善が必要な場合があります。一方、整合性エラーや復旧失敗が繰り返し発生するデータベースでは、検証済みのバックアップからの復元または置き換えが必要になることがあります。

「データベースを再構築する」を、汎用的なパフォーマンス改善策として使わないでください。まず、通常のデータ増加、肥大化、古い統計情報、メンテナンスのブロック、ストレージの遅延と、破損または回復不能なクラスタ状態を切り分けます。侵襲的な作業の前に復旧ポイントを確保し、メンテナンスの変更は一度に一つずつ測定してください。現在のデータベースを信頼できない、または安全に修復できないことを示す証拠がある場合にのみ、クリーンな復元へ移行します。

パフォーマンス低下と整合性障害を切り分ける

まず、正確な症状を確認します。検索の遅延、タイムラインクエリの遅延、データベースサイズの増大、ディスクアクティビティの高騰、PostgreSQLエラーの繰り返し、クラッシュリカバリのループ、または完了できないImmichのマイグレーションなどです。パフォーマンス上の症状と整合性上の症状ではリスクが異なるため、最初に行う修復も同じであってはなりません。

PostgreSQLを原因と判断する前に、ホストのストレージが正常で、十分な空き容量があり、メモリの動作が通常どおりで、Immichのバックグラウンドジョブが暴走していないことを確認します。飽和状態または故障中のディスクは、正常なデータベースを遅く見せるだけでなく、基盤ストレージの信頼性が失われた場合には実際のデータベース損傷を引き起こす可能性もあります。

侵襲的なメンテナンスの前に、ログ、データベースのバージョン、拡張機能のバージョン、最近のアップグレード履歴、バックアップまたはスナップショットを保存します。データベースの唯一のコピーが破損している可能性がある場合、エラーが消えるか確認するためだけに破壊的なクリーンアップを実行しないでください。慎重に復元を判断するために必要な証拠を保持します。

測定可能なメンテナンスの兆候を確認する

データベースが起動し、内部的には使用可能な状態を保っているものの、クエリのパフォーマンスやディスク使用量が時間とともに悪化している場合、通常のメンテナンスが有力な対策になります。蓄積する不要行、テーブルまたはインデックスの不均衡な増大、追いつかない自動バキューム、古いプランナー統計情報、または他のセッションによって長時間のメンテナンスがブロックされていることなどが、有用な証拠になります。

不要タプル、肥大化、フリーズ処理の負荷、ブロックされたVACUUM、バキューム頻度の不足は、PostgreSQLのメンテナンスとクエリパフォーマンスに影響を与えます。データベースファイルが大きいというだけで置き換えが必要だと判断せず、時間の経過に伴うテーブルレベルのVACUUMシグナルを確認してください。

統計情報から特定のテーブルまたはインデックスが原因だと分かった場合は、その結果に対して、サポートされている最も侵襲性の低いメンテナンスを選び、再度測定します。すぐにVACUUM FULL、広範囲なREINDEX、またはクラスタ全体への根拠のない自動バキューム調整を行うのは避けてください。これらの処理はロック、I/O、追加のディスク容量を必要とする可能性があり、実際のボトルネックを解決できない場合もあります。

肥大化やインデックスの増大が遅い処理と一致するか確認する

遅いImmichの処理に関係するオブジェクトについて、テーブルとインデックスのサイズ、行の更新量、クエリの動作を比較します。肥大化によって有効な行を見つけるための処理量が増えたり、インデックスの効率が低下したりする場合は問題になりますが、ライブラリとメタデータが大きいためにデータベース全体が大きくなっているだけの場合もあります。

テーブルの肥大化とインデックスの肥大化は別々に評価してください。過度な肥大化によってクエリに必要な処理量が増えることはありますが、それだけでデータベースの破損を意味するわけではありません。データベース全体のサイズを診断結果とみなすのではなく、測定に基づくPostgreSQLの肥大化チェックを使って確認されたオブジェクトを対象にし、必要に応じてプランナー統計情報を更新します。

メンテナンス後は、遅かったImmichの操作を正確に再実行し、ユーザーが体感する遅延とデータベースおよびストレージの動作を比較します。改善しない場合は、可能であれば以前のチューニングに戻し、さらにデータベースの変更を重ねるのではなく、ストレージ、クエリパターン、バックグラウンドジョブ、アプリケーションレベルの原因を調査します。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

整合性が不確かな場合は復元または置き換えに進む

置き換えが正当化されるのは、現在のPostgreSQLの状態を信頼できない、または安全に復旧できないことを示す証拠がある場合であり、単に古いからではありません。たとえば、ページ破損やチェックサム破損が繰り返し発生する場合、正常なストレージ上でも起動またはリカバリの失敗が続く場合、ストレージ障害が不完全な状態で発生した後にクラスタが破損した場合、サポートされている手順では修復できないマイグレーション状態などです。

データベースが失われたと判断する前に、正常であることが確認されたバックアップを、互換性のあるクリーンなPostgreSQL環境へ復元でき、Immichから読み取れることを確認します。クリーンな復元は正常に動作する一方で、現在のクラスタでは同じ整合性エラーが繰り返されるなら、インプレース修復を続けるよりもデータベースの状態を置き換えるべきだという、はるかに強い根拠になります。

不確かな永続状態を保持しながら、局所的で可逆的な障害を修復します。再構築は、復旧元が検証済みで、対象を再現可能な場合にのみ行ってください。このImmichの修復と再構築の境界をデータベースにも適用します。「置き換え」とは、既知の正常なソースから互換性のあるPostgreSQLの状態を復元することであり、クエリが遅くなったから別のデータベースへ切り替えることではありません。

読み取り、書き込み、バックアップ操作でデータベースを検証する

メンテナンスを実施した場合でも、クリーンなデータベースを復元した場合でも、PostgreSQLが正常に起動しただけで完了とせず、Immichを通じて結果を検証します。古いアルバムとアセットを開き、検索を実行し、代表的な動画を読み込み、ユーザーと共有状態が想定どおり表示されることを確認します。

使い捨て可能なアセットをアップロードするなど、安全な新規書き込みを1件実行し、通常のサービス再起動後もアクセスできることを確認します。読み取りと書き込みの処理が動作している間、PostgreSQLとImmichのログに、整合性、マイグレーション、拡張機能、権限に関するエラーが繰り返し記録されていないか監視します。

最後に、通常の方法で新しいデータベースバックアップを作成し、可能であれば分離した対象へ復元テストを行います。現在のシステムが使用可能であり、次の復旧ポイントが、インシデントのきっかけとなった状態より明らかに健全であることを確認して初めて、メンテナンスまたは置き換えの判断は完了します。