最終更新日 2022年12月13日(火)

Heroku Private Space​ は、Heroku 開発者のエクスペリエンスを使用して Heroku アプリをデプロイできる、独自の専用ネットワークを備えている分離されたランタイム環境です。Heroku Postgres は、Private Space の境界内で動作できます​。

このドキュメントにある移行手順は、現在の Heroku Common Runtime​ 環境から Private Space へのデータベースの移動に適用されます。

フォロワーの切り替えを使用して移行する

フォロワーの切り替えの方法を使用すると、元のデータベースが引き続き動作している間に本番データベースを移行できます。これは、Standard、Premium、Enterprise 層のデータベース (または従来の本番データベース) でのみ使用できます。

フォロワーの切り替えによるデータベースの移行では、新しい Private Space 内にデータベースのフォロワーをプロビジョニングする必要があります。このプロセスにより、そのフォロワーが古いデータベースに追いつけるようになり、それをターゲットアプリケーションのプライマリデータベースにプロモートできます。

フォロワーのアップグレードの利点は、それに必要なダウンタイムが短いことです (通常は 1 分未満)。切り替えの前に、新しいフォロワーの準備に数時間かかる (その間、アプリケーションは引き続きアクティブなまま) 場合があるため、それに応じて計画してください。

1. フォロワーを作成する

初めに、Common Runtime データベースの新しいフォロワーを作成します。

最初に、heroku pg:info​ を使用してフォローしたいデータベースのリソース名を見つけます。

$ heroku pg:info --app common-runtime-sushi
=== DATABASE_URL, HEROKU_POSTGRESQL_GREEN_URL
Plan:        Standard 0
Status:      available
Add-on:      looking-simply-2449
...

リソース名が見つかったら、common-runtime-sushi​ のメインデータベースを使用してそれにフォロワーをアタッチするために、次のコマンドを入力します。

$ heroku addons:create heroku-postgresql:private-4 --follow looking-simply-2449 -a private-spaces-sushi
Adding heroku-postgresql:private-4 to sushi... done, v71 ($1500/mo)
Attached as HEROKU_POSTGRESQL_PURPLE
Follower will become available for read-only queries when up-to-date

Use `heroku pg:wait` to track status

その後、このフォロワーがリーダーデータベースに追いつくまで待ちます。

$ heroku pg:wait --app private-spaces-sushi
Waiting for database HEROKU_POSTGRESQL_PURPLE_URL... available

フォロワーが追いついたときは、一般に、データベースまで 200 コミット以内になります。pg:info​ コマンドを使用して、フォロワーが遅れているコミット数を監視します (フォロワーデータベースの Behind By​ 行を参照)。

$ heroku pg:info --app private-spaces-sushi
=== HEROKU_POSTGRESQL_PURPLE
Plan:        Private 4
Status:      available
...
Behind By:   125 commits

2. 新しいデータベース更新を防ぐ

移行プロセス中は、ソースシステム上のアプリケーションに新しいデータが書き込まれないようにすることが重要です。そうしないと、そのデータが新しいデータベースに転送されません。新しい更新を防ぐには、ソースアプリをメンテナンスモード​にします。スケジューラージョブも実行されている場合は、これを無効にします。

$ heroku maintenance:on  --app private-spaces-sushi
Enabling maintenance mode for private-spaces-sushi... done

メンテナンスモードでは、どの dyno も自動的にスケールダウンされません。どの接続もデータベースにデータを書き込んでいないようにするために、Web dyno や Web 以外の dyno をスケールダウンする必要があります。

$ heroku ps:scale worker=0 --app private-spaces-sushi
Scaling worker processes... done, now running 0

3. フォロワーをプロモートする

dyno がスケールダウンされており、開かれたどの接続もデータを書き込んでいない場合、メンテナンスモードではリーダーデータベースに新しいデータは書き込まれません。フォロワーデータベースがリーダーに追いつくまで待ちます (0 commits​ 遅れていることで示される)。

$ heroku pg:info --app private-spaces-sushi
=== HEROKU_POSTGRESQL_PURPLE_URL
Plan:        Private 4
Status:      available
...
Behind By:   0 commits

フォロワーが追いつき、新しいデータが生成されなくなったら、フォロー解除コマンドを発行して、そのフォロワーの動作を放棄し、それを完全な書き込み可能なデータベースにします。それをプロモートすると、ターゲットアプリケーションによって使用されるプライマリデータベース (場所は DATABASE_URL​) として設定されます。

$ heroku pg:unfollow HEROKU_POSTGRESQL_PURPLE_URL
$ heroku pg:promote HEROKU_POSTGRESQL_PURPLE
Promoting HEROKU_POSTGRESQL_PURPLE_URL to DATABASE_URL... done

これで、フォロワーデータベースがプライマリデータベースになりました (ただし、アプリケーションはまだ新しいリクエストを受信していない)。

4. ターゲットアプリケーションをアクティブにする

通常のアプリケーション動作を再開するには、Web dyno 以外のスケールを元のレベルに戻します(アプリケーションで Web dyno 以外が使用されていなかった場合、不要な dyno のスケーリングを防ぐためにこのステップをスキップします)。

$ heroku ps:scale worker=1

最後に、メンテナンスモードをオフにします。

$ heroku maintenance:off

アプリケーションが、移行されたデータベースインスタンスへのリクエストを受信するようになりました。これは、heroku pg:info​ を実行することによって確認できます。DATABASE_URL​ で示されるデータベースはプライマリデータベースとみなされます。

移行後に実行する手順

データベースをアップグレードした後、未使用のデータベースに対する支払いが発生しないように、古いデータベースをプロビジョニング解除する必要があります。

$ heroku addons:destroy HEROKU_POSTGRESQL_GREEN_URL --app common-runtime-sushi

古いデータベースに関連付けられていたデータクリップを新しいデータベースに再割り当てする必要があります。これらのデータクリップを復旧するには、help.heroku.com​ 経由でサポートチケットを開いてください。