Heroku Postgres フォロワーデータベース
この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。
最終更新日 2022年12月15日(木)
heroku pg:psql
をフォロワーで使用して、本番データに対してアドホックなクエリを安全に実行することもできます。
データベースレプリケーションを数多くの目的 (リーダー - フォロワー設定による読み取りスループットの向上、ホットスタンバイによる追加可用性、レポーティングデータベースとしての役割、シームレスな移行とアップグレードなど) に使用できます。これらの方法はすべてさまざまな目的に使用できますが、これらはすべてリードデータベースのコピーを作成および管理できる能力に基づいています。Heroku Postgres で、この機能は以下の特徴として公開されています。
フォロワーがサポートされているのは Standard、Premium、および Private と Shield tier のデータベースプランだけです。Essential 層のプランから別の層のプランにアップグレードするには、次の手順に従ってください。
フォロワー (たとえばすべての Heroku Postgres データベース) には、フォロワーのプランに基づいて、日割り料金がかかります。
データベースフォロワーとは、リーダーデータベースの読み取り専用コピーであり、リーダーデータベースの最新データを維持しています。書き込みおよび他のデータ修正がリーダーデータベースでコミットされると、変更はリアルタイムでフォロワーデータベースへストリーミングされます。
フォロワーを作成する
フォロワーをあらゆる Standard、Premium、または Enterprise tier のデータベース (このデータベースがフォロワーでない場合) に作成できます (つまり、フォロワーをチェーンでつなぐことはできません)。フォロワーは新しくフォークしたデータベースで一定期間作成することができません (これは、明示的なフォークとフォロー解除)を通して作成されたフォークの両方に該当)。正確なタイムフレームは、フォローされるデータベースのサイズに応じて変わりますが、一般には数分間から数時間の間です。
次の表は、フォロワーを実装できる場所と方法を要約しています。
リーダー | フォロワー | 許可 |
---|---|---|
Common Runtime | Common Runtime | あり |
Common Runtime | Private Space | あり |
Private Space | Common Runtime | あり 1 |
Private Space | Private Space (同じリーダーの Space) | あり |
Private Space | Private Space (リーダーの Space とは異なる) | あり 1 |
Shield Private Space | Shield Private Space (同じリーダーの Space) | あり |
Shield Private Space | Shield Private Space (リーダーの Space とは異なる) | あり 2 |
Shield Private Space | Private Space/Common Runtime | なし |
注意事項:
- データサービスでのフォロワーのラグを回避するには、信頼済み IP 範囲を有効にしてください。
- データサービスでの信頼済み IP 範囲は現在 Shield Space では使用できないため、複製でラグが発生します。
フォロワーは、リーダーデータベースの現在のデータボリュームに対応する必要があります。データボリュームに対応できないフォロワーを作成しようとすると、フォロワーは作成されず、エラーメッセージに必要な最小限のプランが示されます。
1 つのリーダーに対するフォロワーの数は制限されています。正確な制限は、プラン、データコネクタの数、既存のフォロワーの数などによって異なります。計算された制限を超えるフォロワーを作成しようとすると、エラーメッセージが表示されます。一般に、同じリーダーに対して 10 を超えるフォロワーを作成することはお勧めできません。
データベースでフォロワーをサポートする準備ができると、その情報が heroku pg:info
で表示されます。
$ heroku pg:info
=== DATABASE_URL, HEROKU_POSTGRESQL_PURPLE_URL
...
Fork/Follow: Available
...
リーダーデータベースとフォロワーデータベース間のラグは、データ更新の量と頻度に応じて大きく変わります。フォロワー上でクエリが長時間実行されることでラグ時間が増加する可能性がありますが、これらのクエリが実行されるとフォロワーが追いつきます。通常の使用状況では、フォロワーがリーダーの数秒間以内であるというのは普通のことです。
フォロワーデータベースを作成するには、最初にリーダーデータベースのアドオン名を知っていなければなりません。heroku pg:info
を使用してその HEROKU_POSTGRESQL_*COLOR*_URL
名を見つけてください。
$ heroku pg:info
=== DATABASE_URL, HEROKU_POSTGRESQL_CHARCOAL_URL
Plan: Standard 0
Status: available
...
複数のデータベースがリストされた場合は、現在リーダーの働きをしているデータベースが DATABASE_URL
に割り当てられているデータベース (データベース名の後にリストされている) である可能性が高いでしょう。
新しい heroku-postgresql Standard 層以上のアドオンデータベースをプロビジョニングすることによりフォロワーデータベースを作成し、フォローするリーダーデータベースを --follow
フラグで指定します。このフラグには、同じアプリでのデータベースの環境設定名、フォーム appname::HEROKU_POSTGRES_COLOR_URL
の引数、任意の Heroku Postgres データベースのフル URL のいずれかを使用できます。
フォロワーがリーダーと同じデータベースプランである必要はありません。フォロワーのプラン数は、フォロワーのプランにバースタブル特性 (Postgres プラン特性)) がなければリーダーのプランより下の最大 4 プランにすることが可能です。バースタブル特性がある場合、フォロワーの可能なプラン数はリーダーのプランより下の 1 プランまでです。プランをダウングレードしていない限り、リーダーデータベース以上のプランを使用してフォロワーを作成することが推奨されます。
$ heroku addons:create heroku-postgresql:standard-2 --follow HEROKU_POSTGRESQL_CHARCOAL_URL
Adding heroku-postgresql:standard-2 to sushi... done, v71 ($200/mo)
Attached as HEROKU_POSTGRESQL_WHITE
Follower will become available for read-only queries when up-to-date
Use `heroku pg:wait` to track status
フォロワーの準備では、データセットのサイズに応じて、数分間から数時間かかります。heroku pg:wait
コマンドによって、新規データベースのプロビジョニングステータスが出力されます。
$ heroku pg:wait
Waiting for database HEROKU_POSTGRESQL_WHITE_URL... available
Heroku Data Dashboard を使用したフォロワーの作成
フォロワーを Web ダッシュボードから作成することもできます。
- data.heroku.com に移動します。
- 検索を使用して、フォロワーの作成元となるデータベースを選択します。
Durability
(耐久性) タブをクリックします。- 「Followers」 (フォロワー) セクションまでスクロールダウンします。
Add a Follower
(フォロワーを追加) ボタンをクリックします。- フォロワーのプランを選択します。プランのサイズの選択に関する注記については、Create a follower (フォロワーを作成する) セクションを参照してください。
Add follower
(フォロワーを追加) ボタンをクリックします。
ダッシュボードには、フォロワーデータベースのステータスと、プロビジョニングが完了したときの更新情報が表示されます。
フォロワーを別のアプリで作成する
各フォロワーを同じアプリケーションに結び付ける必要はありません。共有型アドオンを使えば、各データベースを異なる 2 つのアプリケーションに配置することができます。手順はフォロワーを同じアプリケーションで作成する場合で説明した手順と同じですが、わずかな違いがあります。
最初に、heroku pg:info
を使用してフォローしたいデータベースのリソース名を見つけます。
$ heroku pg:info -a sushi
=== DATABASE_URL, HEROKU_POSTGRESQL_CHARCOAL_URL
Plan: Standard 0
Status: available
Add-on: looking-simply-2449
...
リソース名が見つかったら、アドオンコマンドを入力して、アタッチしたいアプリでフォロワーを作成します。たとえば、2 番目のアプリケーションが other-app
と呼ばれていて、sushi
のメインデータベースを使用してそのアプリケーションにフォロワーをアタッチしたい場合は次のようにします。
$ heroku addons:create heroku-postgresql:standard-0 --follow looking-simply-2449 -a other-app
フォロー解除
heroku pg:unfollow
コマンドによってフォロワーはそのリーダーデータベースから更新を受け取るのを止めて、その時点までに受け取ったすべてのデータを含むフル読み取り/書き込みデータベースに変換されます。このコマンドによりデータベースフォークが作成されます。
$ heroku pg:unfollow HEROKU_POSTGRESQL_WHITE_URL
! HEROKU_POSTGRESQL_WHITE_URL will become writable and no longer
! follow HEROKU_POSTGRESQL_CHARCOAL. This cannot be undone.
! WARNING: Potentially Destructive Action
! This command will affect the app: sushi
! To proceed, type "sushi" or re-run this command with --confirm sushi
> sushi
Unfollowing... done
データベースのフォロー解除は、プロビジョニング解除と同じではありません。引き続きデータベースの料金がかかります。データベースを完全にプロビジョニング解除するには、heroku addons:destroy HEROKU_POSTGRESQL_WHITE
コマンドを使用します。
変更があるデータベースのアップグレードと移行
フォロワーは、データ冗長性を提供するだけでなく、データベースプラン、基盤となるインフラストラクチャ、あるいはマイナーバージョンを最小限のダウンタイムで変更するためにも使用できます。フォロワーがあるデータベースを更新するには、このガイドの Heroku Postgres の更新を参照してください。
フォロワーを監視する
各フォロワーの更新は非同期で行われるため、各フォロワーはリーダーよりも数コミット遅れる場合があります。フォロワーが遅れているコミット数を表示するには、heroku pg:info
を実行します。フォロワーが遅れているコミット数が増えている場合は、データベースで長時間実行中のトランザクションが原因の場合があります。pg-extras プラグインを使用して、heroku pg:ps
を実行して現在実行中のトランザクションを取り出せます。想定より長く実行されているトランザクションがある場合は、これらのトランザクションを以下のコマンドでキャンセルできます。
$ heroku pg:kill PROCESSID
キャンセルできない場合は、-f
パラメータで終了してみてください。
Heroku Postgres には自動でフォロワーを監視するシステムがあります。このシステムは、フォロワーの遅れている先行書き込みログが 64 個 (1024 MB) を超えているかどうかを調べます。ラグの原因が長時間実行しているトランザクション/クエリの場合、いくつかのトランザクション/クエリが原因でラグが生じていることをメールでお知らせします。
この状況が 1 時間たっても改善しない場合は、長時間実行しているトランザクション/クエリを自動的に終了します。終了したトランザクション/クエリについて terminating connection due to administrator command
のログエントリが表示されます。
フォロワーについての高可用性
一般的な慣行として、高可用性のためにホットスタンバイを使用します。
- 標準のプライマリデータベースの場合、フォロワーを追加することによって独自のスタンバイを作成します。読み取りレプリカとして積極的に使用されていなくても、フォロワーを作成することで、プライマリデータベースが破損したり使用不可能な状況で、プロモーション用に使用可能になります。
- Heroku Postgres の Premium、Private、および Shield プランのプライマリデータベースには、非表示のスタンバイを作成する自動フェイルオーバー付きの HA 機能があります。高可用性を実現するためにフォロワーを作成する必要はありません。
フォロワーデータベースには非表示のスタンバイがありませんプライマリデータベースに加えてフォロワー自体に高可用性が必要な場合、複数のフォロワーをプロビジョニングします。
フォロワーデータベースは、地理的に離れたインフラストラクチャでプロビジョニングされることが、プライマリデータベースよりも保証されます。
フェイルオーバーイベントでのフォロワーの手動プロモート
Heroku は、プライマリデータベースが壊れたりアクセス不可能になった時、フォロワーデータベースを自動的にプロモートしません。この機能が必要な場合は、HA が可能な Premium または Enterprise 層プランを使用してください。手動データベースフェイルオーバーの実行は、メンテナンスモードに入る手順で始まるデータベース移行と同じプロセスです。
アプリ読み取りをフォロワーに分散する
Heroku では、新たな dyno を追加して容量を満たすことで、アプリを容易に水平方向へ拡張できます。同様に、上記で説明したとおり、Heroku Postgres でデータベースを水平方向に拡張する際は、リードデータベースに読み取り専用フォロワーを追加します。これらのフォロワーは解析目的に最適です。また、アプリケーションから使用して、データに対する読み取り専用クエリを処理することもできます。このタイプのアーキテクチャを使用して、アプリのパフォーマンスを向上させたり、Heroku Postgres の接続制限を回避したりできます。
アプリの読み取り操作を 1 つ以上のフォロワーにリダイレクトするには、アプリのコードレベルでの変更が必要になります。Heroku における各アプリはさまざまのため、対処方法について提案するのは不可能です。アプリがフレームワークを使用してビルドされている場合、そのフレームワークが複数のデータベースの使用をサポートする可能性があります。その他の場合、サードパーティ製ライブラリが複数データベースの処理に役立ちます。場合によっては、アプリがさらに複雑になると、カスタムコードの記述が必要になります。