コンテンツにスキップ
日本語

スタンバイホストと引き継ぎ

アプリケーションとデータベースは同じホストに置く必要はありません。本番は外部 PostgreSQL を使え、もう一台のアプリケーションホストが同じデータベースを指します。二台目が単一インスタンスのロックを取れなくても終了しません。引き継ぎページでロックの解放を待ちます。管理者はそのページで元ホストが止まったことを確認して引き継げます。設定ファイルは直しません。

元のホストが止まったことを確認してから、スタンバイが引き継ぎます4 / 4

スタンバイが引き継ぎと起動を終えると、サービスを出すホストになります。
  1. スタンバイは起動時に単一インスタンスのロックを取れず、守衛ページで止まり、引き継ぎまで業務サービスは提供しません。
  2. 運用担当が先に元のホストが止まったことを確認します。
  3. 管理者はスタンバイのページで確認コードを再入力し、資格情報を検証します。引き継ぎの操作は名前が付いて記録に残ります。
  4. スタンバイが引き継ぎと起動を終えると、サービスを出すホストになります。

docker-compose.external-database.yml でアプリケーションを外部 PostgreSQL につなぎます。外部データベースでのクイックスタートは DB_PASSWORD を勝手に作りません。データベース側にあるパスワードを使い、値が無ければ起動を拒否します。

二台のアプリケーションホストが同じデータベースを指すとき、単一インスタンスのロックを持つのは一度に一台です。スタンバイが引き継ぎページにいるあいだは、データベースの移行も書き込みもしません。

INSTANCE_GUARD_ACK の環境変数パスは、スクリプトからの引き継ぎにまだ使えます。ページからの引き継ぎはファイルを直しません。

サービスがまだ起きていないあいだ、封印解除と引き継ぎは二欄です。左は状態と元に戻せない警告、右は番号つきの手順です。冷却や前回の失敗は同じ位置に固定されます。

  1. スタンバイは引き継ぎページにいて、ロックが取れないことを示します。
  2. 相手のアプリケーションホストが止まったことを確認します。
  3. acknowledgement code を入れ直します。
  4. ローカルの管理者アカウントでログインします。
  5. ページが引き継ぎを終え、コンテナの再起動は要りません。

操作は名前つきで残ります。確認コードと管理者の検証が通ってから先へ進みます。

バックアップ、復元、鍵材料の置き場所は バックアップと復元、鍵管理 です。委託モードで再起動したあとは、封印解除のページで保管者の資格情報を再度渡します。鍵管理のページを見てください。

  • ページからの引き継ぎの確認と管理者の検証は、名前つきで残ります。
  • スタンバイが halted のあいだ、移行も書き込みもありません。