ストレージと復旧
プロセスの再起動、新しいデプロイ、またはホスト障害をまたいで保持する必要があるデータに応じてストレージを選択してください。これらはそれぞれ異なるイベントです。永続ストレージ自体は、バックアップ、復元ポイント、高可用性を提供しません。
| データ | 保管場所 | 境界 |
|---|---|---|
| アプリケーションレコード | Managed Postgres または別のデータベース | 再起動と、削除または破損したデータの復元は別です。別個のエクスポートおよび復元経路をテストしてください。 |
| キャッシュおよびキューデータ | Managed Redis | ワークロードが状態を再構築できるのか、独自の復旧計画が必要なのかを判断してください。 |
| アプリケーション間で共有されるファイル | Managed Object Storage | 非公開データをアップロードする前に、bucket のアクセス ポリシーを設定してください。自動作成される default bucket は public-read です。 |
sandbox の実行中はファイルとプロセスを維持します。停止後、別の sandbox で使えるのは、接続した Persistent Volume の /workspace に保存したファイルだけです。ボリュームがなければ /workspace は一時領域です。各ボリュームは同時に 1 つの sandbox に接続し、単一ノードに保存します。ノード障害後も必要なファイルは別の場所へ書き出してください。
sandbox の終了後もファイルを保持する
Persistent Volumes タブで名前付きボリュームと接続を管理します。sandbox の作成時にボリュームを接続し、/workspace に書き込んでください。別の sandbox に接続する前に、現在の sandbox を停止します。
データベースの復元を計画する
データを変更する移行またはリリースの前に:
- 使用中のデータベースとバージョンに対するエクスポート方法を選択します。
- 変更対象のリソースとは別の場所にエクスポートを保存します。
- 別個のテスト用データベースに復元し、アプリケーションがそれを読み取れることを確認します。
- 復元にかかる時間と、エクスポートに含まれる最新データを記録します。
データベースがマネージドであることを理由に、定期バックアップ、ポイントインタイムリカバリ、マルチノード レプリケーション、または復元時間の保証を想定しないでください。現在のサービス契約と、そのリソースで利用できる制御を確認してください。
環境参照
アプリケーションは、環境参照からデータベース接続を読み取るべきです。接続文字列は認証情報です。更新を確認するためにそれを出力するのは避けてください。SELECT 1 のような接続確認は、shell 内で変数を見るよりも多くを証明します。