ネットワークマウントされたDockerボリュームでデータベースを実行できますか？

エヴァ・ウォン

IceWhale author

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

Can You Run a Database From a Network-Mounted Docker Volume? - Zima Store Online

場合によっては可能ですが、データベースがネットワークファイルシステムのセマンティクスとレイテンシを明示的にサポートしている場合に限ります。ローカルの永続ストレージをデフォルトにする方が安全です。

この判断が重要になるのは、コンテナ化したPostgreSQL、MariaDB、またはSQLiteのワークロードを、集中管理しやすいNFSやSMB上のストレージに配置する場合です。競合する状態は、ロック、fsync、障害時のセマンティクスがサポートされていることと、レイテンシ、キャッシュ、ロック、再接続の挙動がデータベースの期待に反することです。保存済みの設定と使い捨てデータから始め、一度に1つの分岐だけを観察し、データ損失、権限、可用性のリスクが拡大する場合は中止してください。

ネットワークストレージ上のデータベースファイルに関する判断の条件を定義する

変更前に、ソフトウェアとファームウェアのバージョン、デバイスの識別情報、マウント先またはネットワークパス、空き容量、権限、観測可能な症状を記録します。ベースラインには、コンテナ化したPostgreSQL、MariaDB、またはSQLiteのワークロードを、集中管理しやすいNFSやSMB上のストレージに配置した状態を再現できるだけの詳細を残す必要があります。

最初の候補は、ロック、fsync、障害時のセマンティクスがサポートされていることです。2つ目は、レイテンシ、キャッシュ、ロック、再接続の挙動がデータベースの期待に反することです。現在のNFS上のPostgreSQLは、テストで使用する仕組みまたはコマンドの境界を定義しますが、この特定のホームサーバーでの観測に取って代わるものではありません。

判別テストを実行する前に、合格条件と中止条件を書き出します。合格とは、いずれかの分岐が予測した証拠が変化し、無関係なサービスは変更されないことです。不合格の場合は、推測に基づく修正を連鎖させるのではなく、システムを保存済みの状態に戻せなければなりません。

元の要件を下げずに主張を検証する

次の判別テストを使用します。使い捨てのデータベースを正確なマウント先に復元し、整合性とクラッシュリカバリのテストを実行して、短時間のネットワーク停止を再現します。結果を変更した変数に帰属できるよう、ワークロード、クライアント、パス、ファイルセット、タイミングを一定に保ちます。

データベースでネットワークファイルシステムを使用するリスクを参考に、分岐を実際に切り分けられる項目を選び、そのタイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショットの識別情報、レイテンシ、転送バイト数、権限、リカバリ状態を記録します。識別情報、永続性、アプリケーション状態がテスト対象の場合、コマンドが正常終了しただけでは不十分です。

再起動、再接続、再マウント、またはキャッシュのコールド状態が元の条件に含まれる場合は、そのイベントの後にテストを1回繰り返します。最初の実行でデータが破壊される場合や、環境を復元できない場合は中止し、代わりに使い捨てのコピーで再現してください。

テスト: トランザクションを継続実行 -> ネットワーク中断 -> 再マウント -> データベースのリカバリ -> チェック

合格、不合格、例外の結果を解釈する

合格: 対象のレイテンシとマウントオプションの下で、トランザクションの永続性が保たれ、破損なくリカバリに成功する。結論が普遍的な主張にならないよう、合格した正確なバージョン、識別情報、ワークロードを記録します。

不合格: データベースがハングする、ロックまたはfsyncエラーを報告する、または障害発生後に不整合な状態で復帰する。不合格だからといって、直ちに反対の分岐が証明されるわけではありません。ネットワーク、メモリ、権限、ソースの整合性が両方の分岐に影響する可能性があるため、エスカレーションする前に共有依存関係を切り分けます。

例外または曖昧な結果: データベースファイルをローカルの永続ストレージに戻し、アプリケーション層でバックアップまたはレプリケーションを行います。復元可能なコピーが存在するまで、ログを保持し、修復、プルーニング、破棄、再パーティション、再帰的な所有者変更のコマンドを実行しないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

元のワークロードで判断を確認する

観測した分岐に対応するアクションを適用し、その後、縮小した代替テストではなく、元の条件を繰り返します。対象のレイテンシとマウントオプションの下で、2サイクル、または該当する再起動、スリープ、中断、負荷遷移を通じて、トランザクションの永続性が保たれ、破損なくリカバリに成功した場合にのみ、その判断は有効です。

データベースダンプのワークフローを使用して、最も近い依存ワークフローを確認しますが、元のトリガーは変更しないでください。無関係なデータセット、共有、コンテナ、ユーザー、リカバリポイントは、以前のアクセス状態とタイミングを維持する必要があります。

中止の境界は明確です。データベースがハングする、ロックまたはfsyncエラーを報告する、または障害発生後に不整合な状態で復帰する場合は、最後に検証済みの設定に戻し、証拠を保持します。分岐が再現可能な場合に限り、より深いプラットフォームまたはハードウェアのテストへエスカレーションしてください。

対象の結果が得られたら、NFSのタイムアウト動作と比較し、修正によって隣接するサービスにリスクが移っていないことを確認します。新たなバックアップ、識別情報、タイムアウト、可用性の障害が発生するなら、対象テストが成功していても変更は失敗です。

よくある質問

ネットワークストレージ上のデータベースファイルについて、残る検索は通常、「データベースファイルにはNFSとSMBのどちらが安全か」「データベースのWALをローカルに置いたままデータをリモートにできるか」「ネットワークDockerボリュームはホストのNFSマウントと異なるか」に関するものです。以下では、これらの境界事例を主な判断から分けて扱います。

合格の境界は変わりません。対象のレイテンシとマウントオプションの下で、トランザクションの永続性が保たれ、破損なくリカバリに成功することです。後続の条件によってファイルシステム、識別情報、ネットワークパス、アプリケーションのバージョンが変わる場合は、その変更の影響を受ける判別テストだけを繰り返します。

データベースがハングする、ロックまたはfsyncエラーを報告する、または障害発生後に不整合な状態で復帰する場合は、実験を広げるのをやめてください。その時点でデータベースファイルをローカルの永続ストレージに戻し、アプリケーション層でバックアップまたはレプリケーションを行います。プラットフォーム、ストレージ、またはハードウェアの担当者へエスカレーションする前に、証拠を保持してください。

データベースファイルにはNFSとSMBのどちらが安全ですか？

プロトコル名だけでは不十分です。データベースのサポート状況、サーバーの実装、マウントセマンティクス、レイテンシのすべてが重要です。

データベースのWALをローカルに置いたまま、データをリモートにできますか？

分離できる構成もありますが、障害時とリカバリのセマンティクスが複雑になるため、テストが必要です。

ネットワークDockerボリュームはホストのNFSマウントと異なりますか？

コンテナの抽象化によって、基盤となるネットワークファイルシステムの挙動がなくなるわけではありません。

ネットワークストレージ上のデータベースファイルに対する実際の答えは、引き続き条件付きです。対象のレイテンシとマウントオプションの下で、トランザクションの永続性が保たれ、破損なくリカバリに成功する必要があります。データベースがハングする、ロックまたはfsyncエラーを報告する、または障害発生後に不整合な状態で復帰する場合は、データベースファイルをローカルの永続ストレージに戻し、アプリケーション層でバックアップまたはレプリケーションを行ってください。元のワークロードに耐えられない部分的な成功は、互換性とはいえません。