DBインスタンスは仮想機器とインストールされたPostgreSQLを包含する概念で、RDS for PostgreSQLが提供するPostgreSQLの単位です。 DBインスタンスのOSに直接アクセスすることはできず、DBインスタンス作成時に入力したポートを介してデータベースにのみアクセスできます。使用できるポート範囲には下記のような制約があります。
DBインスタンスは、顧客が付与する名前と自動的に付与される32バイトのIDで識別されます。 DBインスタンス名は下記のような制約があります。
以下の設定を通じてDBインスタンスを作成できます。
NHN Cloudは、物理的なハードウェアの問題で発生する障害に備えるため、システム全体を複数のアベイラビリティゾーンに分けています。このアベイラビリティゾーンごとに、ストレージシステム、ネットワークスイッチ、ラック、電源装置がすべて別々に構成されています。一つのアベイラビリティゾーン内で発生する障害は他のアベイラビリティゾーンに影響を与えないため、サービス全体の可用性が高くなります。DBインスタンスを複数のアベイラビリティゾーンに分けて構築すれば、サービスの可用性をさらに高めることができます。複数のアベイラビリティゾーンに分散して作成されたDBインスタンス同士でネットワーク通信が可能で、この時発生するネットワーク使用費用は請求されません。
[注意] 既に作成したDBインスタンスのアベイラビリティゾーンは変更できません。
下記のバージョンを使用できます。
バージョン | 備考 |
---|---|
PostgreSQL 14.6 |
DBインスタンスはタイプによって異なるCPUコア数とメモリ容量を持っています。 DBインスタンスを作成する際、データベースのワークロードに応じて適切なDBインスタンスタイプを選択する必要があります。
タイプ | 説明 |
---|---|
m2 | CPUとメモリをバランスよく設定したタイプです。 |
c2 | CPUの性能を高く設定したインスタンスタイプです。 |
r2 | のリソースに比べ、メモリ使用量が多い場合に使用できます。 |
x1 | 高スペックのCPUとメモリをサポートするタイプです。高性能が必要なサービスやアプリケーションに使用します。 |
既に作成したDBインスタンスのタイプはコンソールから簡単に変更可能です。
[注意] 既に作成したDBインスタンスのタイプを変更すると、DBインスタンスが終了するため、多少のダウンタイムが発生します。
データストレージにデータベースのデータファイルを保存します。DBインスタンスはHDD、SSDの2種類のデータストレージタイプをサポートします。データストレージのタイプによって性能と価格が異なるため、データベースのワークロードに応じて適切なタイプを選択する必要があります。データストレージは20GB~2TBで作成できます。
[注意] 既に作成したDBインスタンスのデータストレージタイプは変更できません。
[参考] データストレージを2TB以上使用する場合は、NHN Cloudサポートにお問い合わせください。
以下の作業は、データストレージのI/O容量を使用するため、進行中にDBインスタンスの性能が低下する可能性があります。
DBインスタンスの基本情報を設定します。インスタンス名、説明、DBポートと基本的に作成するユーザー情報を入力できます。 入力したユーザーIDはDDL権限で作成されます。
DDL * CRUD権限を含み、DDLクエリを実行できる権限を持っています。
CRUD * 照会権限を含み、データを変更する権限を持っています。 * CRUDユーザーは、DBインスタンス作成完了後、DB &ユーザータブで作成できます。
[注意] DDLユーザーは、DBインスタンスごとに1つだけ作成することができ、すでに作成したユーザーの権限は変更できません。
外部からDBインスタンスにアクセスするには、Floating IPをDBインスタンスに接続する必要があります。Internet Gatewayが接続されたサブネットを接続する場合のみ、Floating IPを作成できます。Floating IPは使用と同時に課金され、これとは別にFloating IPを介したインターネット方向のトラフィックが発生した場合は別途課金されます。
パラメータグループは、DBインスタンスにインストールされたデータベースを設定できるパラメータの集合です。DBインスタンス作成時に必ず一つのパラメータグループを選択する必要があります。パラメータグループは、作成後も自由に変更できます。パラメータグループの詳細はパラメータグループの項目を参照してください。
DBセキュリティグループは、外部からの侵入に備えて接続を制限するために使用します。送受信トラフィックに対して特定のポート範囲またはデータベースポートに対してアクセスを許可できます。DBインスタンスに複数のDBセキュリティグループを適用できます。DBセキュリティグループの詳細はDBセキュリティグループの項目を参照してください。
DBインスタンスのデータベースを定期的にバックアップするように設定したり、コンソールを通じて好きなタイミングでバックアップを作成できます。バックアップが実行される間、性能低下が発生する可能性があります。サービスに影響を与えないように、サービスの負荷が少ない時間にバックアップすることを推奨します。バックアップによる性能低下を望まない場合は、リードレプリカからバックアップを行うことができます。バックアップファイルは内部バックアップストレージに保存され、バックアップ容量に応じて課金されます。予期せぬ障害に備えるため、定期的にバックアップを実行するように設定することを推奨します。バックアップの詳細はバックアップと復元の項目を参照してください。
定期的にDBインスタンスの安定化のための作業を実行するように設定します。ファイルI/Oを使用する場合、メンテナンス作業が実行されている間、性能が低下する可能性があります。サービスへの影響を避けるために、サービスの負荷が少ない時間帯に自動メンテナンス作業を実行することを推奨します。
サービスの動作に影響を与えない保管されたトランザクションログ(Archived Write Ahead Log)の整理を行います。サービスの動作に影響を与えない保管されたトランザクションログとは、自動バックアップを利用して現時点までの復元を実行する際に使用されないログを指します。
DBインスタンス作成時、基本通知を設定できます。基本通知を設定すると、{DBインスタンス名}-default
という名前で新しい通知グループが作成され、下記の通知項目が自動的に設定されます。基本通知で作成された通知グループは自由に修正、削除できます。通知グループの詳細は通知グループの項目を参照してください。
項目 | 比較方法 | しきい値 | 持続時間 |
---|---|---|---|
CPU使用率 | >= | 80% | 5分 |
Storage残り使用量 | <= | 5,120MB | 5分 |
Database Connection Status | <= | 0 | 0分 |
Storage使用量 | >= | 95% | 5分 |
データストレージの障害 | <= | 0 | 0分 |
Connection Ratio | >= | 85% | 5分 |
メモリ使用量 | >= | 90% | 5分 |
コンソールで作成されたDBインスタンスを確認できます。DBインスタンスグループ単位でまとめて見たり、個々のDBインスタンスで見ることができます。
❶ DBインスタンス画面モードを変更できます。 ❷南京錠アイコンをクリックすると、削除保護設定を変更できます。 ❸最近収集されたモニタリング指標を表示します。 ❹現在の状態を確認できます。 ❺進行中の作業がある場合、スピナーが表示されます。 ❻検索条件を変更できます。
DBインスタンスの状態は以下のような値で構成され、ユーザーの行為と現在の状態によって変更されます。
状態 | 説明 |
---|---|
BEFORE_CREATE | 作成前 |
AVAILABLE | 使用可能 |
STORAGE_FULL | 容量不足 |
FAIL_TO_CREATE | 作成失敗 |
FAIL_TO_CONNECT | 接続失敗 |
REPLICATION_DELAY | 複製遅延 |
REPLICATION_STOP | 複製中断 |
SHUTDOWN | 停止 |
変更できる検索条件は次のとおりです。
❶ DBインスタンスの状態をフィルタリング条件として検索できます。 ❷アベイラビリティゾーンをフィルタリング条件として検索できます。
DBインスタンスを選択すると、詳細情報を確認できます。
❶接続情報のドメインをクリックすると、IPアドレスを確認できるポップアップウィンドウが表示されます。 ❷ DBセキュリティグループをクリックすると、DBセキュリティルールを確認できるポップアップウィンドウが表示されます。 ❸パラメータグループをクリックすると、パラメータを確認できる画面に移動します。 ❹マウスでドラッグ&ドロップして詳細情報パネルの高さを調整できます。 ❺詳細情報パネルの高さをあらかじめ指定した高さに調整できます。
DBインスタンス作成時に内部ドメインを発行します。内部ドメインは、ユーザーのVPCサブネットに属するIPアドレスを指します。
Floating IPを作成した場合、外部ドメインを追加で発行します。外部ドメインはFloating IPのアドレスを指します。外部ドメインまたはFloating IPは外部からアクセスが可能なので、DBセキュリティグループのルールを適切に設定してDBインスタンスを保護する必要があります。
DBインスタンスのログタブでは、各種ログファイルの閲覧や、ダウンロードを行うことができます。ログファイルは下記のように決められた設定でローテーションされます。一部のログファイルは、パラメータグループで有効または無効にできます。
項目 | ローテーション設定 | 変更するかどうか |
---|---|---|
postgresql.log | 100MB 40個 | 固定 |
backup.log | 毎日10個 | 固定 |
❶ ログ表示をクリックすると、ログファイルの内容を確認できるポップアップウィンドウが表示されます。最大65,535Bytesのログを確認できます。 ❷ インポートをクリックすると、DBインスタンスのログファイルをダウンロードできるようにリクエストします。 ❸ダウンロードの準備が整うと、ダウンロードボタンが表示されます。クリックすると、ログをダウンロードします。
[注意] インポートをクリックすると、約5分間、ログファイルがバックアップストレージにアップロードされ、ログファイルのサイズ分だけバックアップストレージの容量が課金されます。 ダウンロードをクリックすると、ログファイルのサイズ分だけインターネットトラフィックが課金されます。
DBインスタンスのデータベース&ユーザータブでは、DBエンジンに作成されたデータベースとユーザーを照会および制御できます。
❶ + 作成をクリックすると、データベースの名前を入力できるポップアップウィンドウが表示されます。 ❷データベース名を入力した後、作成をクリックしてデータベースを作成できます。
データベース名には以下のような制約があります。
postgres
information_schema
performance_schema
repmgr
db_helper
sys
mysql
rds_maintenance
pgpool
nsight
watchdog
barman
rman
はデータベース名に使用できません。❶修正するデータベース行の修正をクリックすると、データベース情報を修正できるポップアップウィンドウが表示されます。 ❷ 修正をクリックして修正をリクエストできます。 ❸ 変更予定アクセス制御即時適用をチェックすると、アクセス制御ルールにも修正内容が即時適用されます。
❶削除するデータベースを選択し、削除をクリックすると、削除確認ポップアップウィンドウが表示されます。 ❷ 削除をクリックして削除をリクエストできます。
❶ + 作成をクリックすると、ユーザー追加ポップアップウィンドウが表示されます。 ❷ユーザーIDを入力します。
ユーザーIDには以下のような制約があります。
postgres
repmgr
barman
rman
pgpool
nsight
watchdog
dba
manager
mysql.session
mysql.sys
mysql.infoschema
sqlgw
admin
etladm
alertman
prom
rds_admin
rds_mha
rds_repl
mariadb.sys
はユーザーIDとして使用できません。❸パスワードを入力します。
パスワードには以下の制約があります。
❹ユーザーに付与する権限を選択します。付与できる権限と説明は次のとおりです。
❺作成するユーザーに全データベースへのアクセス権を与えるための基本アクセス制御ルールを追加するように設定できます。基本アクセス制御ルールを追加しない場合、別途のアクセス制御ルールを設定すると、データベースへのアクセスが可能です。
❶修正するユーザー行の修正をクリックすると、ユーザー情報を修正できるポップアップウィンドウが表示されます。 ❷パスワードを入力しないと変更されません。 ❸ 変更予定アクセス制御即時適用をチェックすると、アクセス制御ルールにも修正内容が即時適用されます。
❶削除するユーザーを選択し、ドロップダウンメニューをクリックします。 ❷ 削除をクリックすると、削除確認ポップアップウィンドウが表示されます。確認をクリックして削除をリクエストできます。
DBインスタンスのアクセス制御タブでは、特定のデータベースとユーザーに対するDBエンジンのアクセスルールを照会及び制御できます。ここで設定したルールはpg_hba.conf
ファイルに適用されます。
❶アクセス制御ルールの適用状態を確認できます。 ❷進行中の作業があれば、スピナーが表示されます。 ❸検索キーワードを入力して検索できます。
アクセス制御の状態は以下のような値で構成され、ユーザーの行為と現在の状態に基づいて変更されます。
状態 | 予約状態 | 説明 |
---|---|---|
CREATED | CREATE | 作成予約(適用必要) |
CREATED | MODIFY | 修正予約(適用必要) |
CREATED | DELETE | 削除予約(適用必要) |
APPLIED | NONE | 適用済み |
- | - | 適用不可 |
[注意] 特定のデータベースとユーザーを選択して追加したルールの対象がすべて削除された場合、適用不可の状態と表示され、設定ファイルには適用されません。
❶ + 作成をクリックすると、アクセス制御ルールの追加ポップアップウィンドウが表示されます。 ❷ルール適用対象を全体対象に指定するか、特定のデータベースやユーザーを選択して指定できます。 - ユーザー指定を選択すると、データベース&ユーザータブで追加したデータベース、ユーザーを選択するドロップダウンメニューが表示されます。 ❸ルールを適用する接続アドレスをCIDR形式で入力します。 ❹認証方法を選択します。RDS for PostgreSQLでサポートする認証方式は次のとおりです。
認証方式 | DBエンジン設定値 | 説明 |
---|---|---|
信頼(パスワード不要) | trust | パスワードや他の認証なしですべての接続を許可します。 |
接続ブロック | reject | 全ての接続を遮断します。 |
パスワード(SCRAM-SHA-256) | scram-sha-256 | データベース&ユーザータブで設定したパスワードでSCRAM-SHA-256認証を行うようにします。 |
❺上/下矢印ボタンでルールを適用する順序を調整します。 - アクセス制御ルールは上から順番に適用され、先に適用されたルールが優先されます。 - 上部に登録されたアクセス許可ルールが先に適用されると、下部にアクセス遮断ルールがあってもアクセスが許可されます。 - 逆に、下部にアクセス許可ルールがあっても、上段に登録されたアクセス遮断ルールが先に適用されている場合はアクセスができません。 ❻設定を終えた後、変更事項の適用をクリックしてDBインスタンスにアクセス制御設定を適用します。 ❼ DBインスタンスに適用されると、状態が適用済みに変更されます。
❶修正するアクセス制御ルール行の修正をクリックすると、既存の情報を修正できるポップアップウィンドウが表示されます。 ❷修正したルールは変更事項の適用をクリックしてDBインスタンスにアクセス制御設定を適用する必要があります。
❶削除するユーザーを選択し、削除をクリックすると、削除確認ポップアップウィンドウが表示されます。 ❷削除したルールは、変更の適用をクリックしてDBインスタンスにアクセス制御設定を適用する必要があります。
DBインスタンスの拡張管理タブでは、SUPERUSER権限が必要な拡張機能を照会及び制御できます。
❶ インストールをクリックすると、選択した拡張機能をインストールするデータベースを選択できるポップアップウィンドウが表示されます。 ❷ 強制インストールをチェックすると、依存関係にある拡張機能を強制的にインストールします。 ❸インストールするデータベースを選択した後、確認をクリックするとインストール作業が予約されます。 ❹ キャンセルをクリックすると、予約された作業をキャンセルできます。 ❺ 変更事項適用をクリックしてDBインスタンスに拡張機能をインストールします。
❸削除するデータベースの行で削除をクリックすると、削除確認ポップアップウィンドウが表示されます。 ❷ 強制削除をチェックすると、依存関係にある拡張機能を強制的に削除します。 ❸ 削除をクリックすると削除作業が予約されます。 ❹ キャンセルをクリックすると、予約された作業をキャンセルできます。 ❺ 変更事項適用をクリックしてDBインスタンスにインストールされた拡張機能を削除します。
❶ 同期をクリックすると、同期確認 ポップアップウィンドウが表示されます。 ❷ 確認をクリックして同期をリクエストできます。
コンソールを通じて作成されたDBインスタンスの様々な項目を簡単に変更できます。変更をリクエストした項目は、順次DBインスタンスに適用します。適用過程で再起動が必要な場合、すべての変更を適用した後、DBインスタンスを再起動します。変更不可能な項目と再起動が必要な項目は次のとおりです。
項目 | 変更可否 | 再起動が必要かどうか |
---|---|---|
アベイラビリティゾーン | いいえ | |
DBバージョン | はい | はい |
DBインスタンスタイプ | はい | はい |
データストレージの種類 | いいえ | |
データストレージサイズ | はい | はい |
名前 | はい | いいえ |
説明 | はい | いいえ |
DBポート | はい | はい |
VPCサブネット | いいえ | |
Floating IP | はい | いいえ |
パラメータグループ | はい | 変更されたパラメータの再起動可否によって決定 |
DBセキュリティグループ | はい | いいえ |
バックアップ設定 | はい | いいえ |
データベース&ユーザー制御 | はい | いいえ |
アクセス制御 | はい | いいえ |
使用しないDBインスタンスは削除できます。マスターを削除すると、そのレプリケーショングループに属するリードレプリカも一緒に削除されます。削除されたDBインスタンスは復旧できないため、重要なDBインスタンスは削除保護設定を有効にすることを推奨します。
障害状況に備えて、DBインスタンスのデータベースを復旧できるように事前に準備できます。必要なときにコンソールでバックアップを実行したり、定期的にバックアップが実行されるように設定できます。詳細は、バックアップを参照してください。
バックアップを利用して希望の時点にデータを復元できます。復元時は常に新しいDBインスタンスが作成され、既存のDBインスタンスに復元することはできません。詳細は復元の項目を参照してください。
急激な負荷でWALログが過剰に作成されてデータストレージの容量が不足する場合、コンソールの容量確保機能を利用してWALログを削除できます。コンソールで容量確保を選択すると、DBインスタンスのWALログを選択できるポップアップウィンドウが表示されます。WALログを選択した後、OKを押して、選択した項目以前に作成されたすべてのWALログを削除します。容量確保機能は一時的に容量を確保する機能です。継続して容量が不足している場合は、サービス負荷に合わせてデータストレージのサイズを拡張する必要があります。
[注意] 削除されたWALログによっては、特定の時点に復元されない場合があります。
DBインスタンスに接続されたパラメータグループの設定が変更されても、この変更はDBインスタンスに自動的に適用されません。もし、DBインスタンスに適用されたパラメータと接続されたパラメータグループの設定が異なる場合、コンソールにパラメータボタンが表示されます。
次のいずれかの方法を使用してDBインスタンスにパラメータグループの変更を適用できます。
❶対象DBインスタンスの パラメータをクリックするか ❷対象DBインスタンスを選択した後、ドロップダウンメニューからパラメータグループの変更内容を適用メニューをクリックします。
パラメータグループで再起動を必要とするパラメータが変更された場合、変更内容を適用する過程でDBインスタンスが再起動されます。
❶ 変更事項の比較をクリックして変更されたパラメータを確認できます。 ❷変更事項を確認した後、確認をクリックしてDBインスタンスに変更されたパラメータを適用します。
読み取り性能を向上させるために、読み取り専用に使用できるリードレプリカを作成できます。リードレプリカは一つのマスターに対して最大5個まで作成できます。リードレプリカのリードレプリカは作成できません。
リードレプリカを作成するには、複製グループに属するDBインスタンスで作成されたバックアップファイルが必要です。バックアップファイルがない場合、次の順序でバックアップを実行するDBインスタンスを選択します。
❶自動バックアップを設定したリードレプリカ ❷自動バックアップ設定したマスター
条件に合致するDBインスタンスがない場合、リードレプリカの作成リクエストは失敗します。
[注意] マスターのデータベースサイズに比例して、リードレプリカの作成時間が長くなる場合があります。 バックアップが実行されるDBインスタンスの場合、リードレプリカの作成過程でストレージI/O性能が低下することがあります。 [参考] リードレプリカの作成過程で必要なデータストレージサイズ分、バックアップストレージの課金が発生する可能性があります。 リードレプリカを作成するには、コンソールで
❶原本DBインスタンスを選択した後、リードレプリカ作成をクリッすると、リードレプリカを作成するためのページに移動します。
以下の設定でリードレプリカを作成できます。
リードレプリカを作成する際、下記の項目は元のDBインスタンスの設定に従うため、変更できません。
リードレプリカのアベイラビリティゾーンを選択します。詳しい説明はアベイラビリティゾーンを参照してください。
リードレプリカは、マスターと同じ仕様またはより高い仕様で作成することを推奨します。低い仕様で作成すると、複製遅延が発生する可能性があります。
元のDBインスタンスと同じサイズで作成することを推奨します。サイズを小さく設定する場合、データストレージ容量不足で複製が中断される可能性があります。
リードレプリカのFloating IPを使用するかどうかを選択します。詳しい説明はFloating IPを参照してください。
リードレプリカのパラメータグループを選択する際、レプリケーション関連設定を変更する必要がない場合は、元のDBインスタンスと同じパラメータグループを選択することを推奨します。パラメータグループの詳しい説明はパラメータグループを参照してください。
リードレプリカに適用するDBセキュリティグループを選択します。複製に必要なルールは自動的に適用されるため、DBセキュリティグループに別途追加する必要はありません。 DBセキュリティグループの詳細については、DBセキュリティグループのを参照してください。
リードレプリカのバックアップ設定を選択します。バックアップの詳しい説明はバックアップ及び復元を参照してください。
基本通知を使用するかどうかを選択します。詳しい説明は、基本通知を参照してください。
削除保護を使用するかどうかを選択します。詳しい説明は削除保護を参照してください。
マスターとの複製関係を解除して、リードレプリカを独立したマスターに転換する過程を昇格といいます。昇格されたマスターは独立したDBインスタンスとして動作します。昇格したいリードレプリカとマスターの間に複製遅延が存在する場合、その遅延が解決されるまで昇格が行われません。一度昇格されたDBインスタンスは、以前のレプリケーション関係に戻すことはできません。
[注意] マスターDBインスタンスの状態が異常な場合は、昇格作業を進めることができません。
マスターの状態とは関係なく、リードレプリカの現在時点のデータに基づいて強制昇格を行います。複製遅延がある場合、待機時間を設定して遅延が解消されるまで待機させることができますが、遅延解消の有無に関係なく昇格を進行するため、データ損失が発生する可能性があります。したがって、リードレプリカを緊急にサービスに投入しなければならない状況でない限り、この機能の使用は推奨しません。
リードレプリカの昇格または強制昇格中に複製遅延が解消されるまで待機している場合、待機作業を終了するには、コンソールで
❶ 複製遅延待機終了をクリックすると、待機作業を終了することができるポップアップウィンドウが表示されます。 ❷ 確認をクリックして待機作業を終了します。
リードレプリカは様々な理由で複製が中断されることがあります。リードレプリカの状態が「複製中断」である場合、すぐに原因を確認して正常化する必要があります。複製中断」状態が長時間続く場合、複製の遅延が長くなります。正常化に必要なWALログがない場合は、リードレプリカを再構築する必要があります。
リードレプリカの複製問題を解決できない場合、再構築により正常な状態に復元できます。この過程で、リードレプリカのすべてのデータベースを削除し、マスターデータベースを基に新たに再構築します。再構築中は、リードレプリカは使用できません。リードレプリカを再構築するには、レプリケーショングループに属するDBインスタンスで作成されたバックアップファイルが必要です。バックアップファイルがない場合、動作および注意事項はリードレプリカの作成を参照してください。
[参考] 再構築後も接続情報(ドメイン、IP)は変更されません。
PostgreSQLを再起動したい時、DBインスタンスを再起動できます。再起動時間を最小化するため、サービス負荷が低い時間帯に実行することを推奨します。
DBインスタンスの再起動を行うにはコンソールで
❶再起動したいDBインスタンスを選択した後、ドロップダウンメニューからDBインスタンスの再起動メニューをクリックします。
DBインスタンスのPostgreSQLが正常に動作しない場合、強制的に再起動できます。強制再起動の場合、PostgreSQLにSIGTERMコマンドを実行して正常終了するのを10分間待ちます。10分以内にPostgreSQLが正常終了したら、仮想マシンを再起動します。10分以内に正常終了しない場合は、仮想マシンを強制的に再起動します。仮想マシンが強制的に再起動されると、作業中の一部のトランザクションが失われる可能性があり、データボリュームが破損して復旧が不可能になる可能性があります。強制再起動後、DBインスタンスの状態が使用可能な状態に戻らない場合があります。このような状況が発生した場合はサポートにお問い合わせください。
[注意] データが失われたり、データボリュームが破損する可能性があるため、この機能は緊急かつ不可避的な状況以外では使用を控えてください。
DBインスタンスを強制的に再起動するには、コンソールで
❶再起動するDBインスタンスを選択し、ドロップダウンメニューからDBインスタンス強制再起動メニューをクリックします。
削除保護を有効にすると、誤ってDBインスタンスが削除されないように保護できます。削除保護を無効にするまで、該当DBインスタンスを削除できません。削除保護設定を変更するには
❶削除保護設定を変更したいDBインスタンスを選択した後、ドロップダウンメニューから削除保護設定の変更メニューをクリックすると、ポップアップウィンドウが表示されます。
❷削除保護設定を変更した後、確認をクリックします。
高可用性DBインスタンスは、可用性とデータの耐久性を高め、障害許容が可能なデータベースを提供します。高可用性DBインスタンスはマスター、予備マスターで構成され、異なるアベイラビリティゾーンに作成されます。予備マスターは障害に備えたDBインスタンスで、普段は使用できません。高可用性DBインスタンスの場合、予備マスターでバックアップが行われます。
[参考] 高可用性DBインスタンスの場合、PostgreSQLクエリ文で他のDBインスタンスまたは外部PostgreSQLのマスターから強制的に複製するように設定すると、高可用性及び一部の機能が正常に動作しません。
予備マスターには障害を検知するためのプロセスが存在し、定期的にマスターの状態を検知します。このような検出周期をPing間隔と呼び、4回連続状態チェックに失敗した場合、フェイルオーバーを行います。 Ping間隔が短いほど障害に敏感に反応し、Ping間隔が長いほど障害に鈍感に反応します。サービス負荷に合わせて適切なPing間隔を設定することが重要です。
[参考] マスターのデータストレージの使用量がいっぱいになると、高可用性監視プロセスが障害として検知し、フェイルオーバーを実行するので注意してください。
予備マスターでマスターの状態チェックに4回連続で失敗した場合、マスターがサービスを提供できないと判断し、自動的にフェイルオーバーを実行します。スプリットブレインを防止するため、障害が発生したマスターに割り当てられた全てのユーザーセキュリティグループの接続を解除して外部からの接続を遮断し、予備マスターがマスターの役割を代行します。接続のための内部仮想IPは障害が発生したマスターから予備マスターに変更されるので、アプリケーションの変更は必要ありません。フェイルオーバーが完了すると、障害が発生したマスターの種類はフェイルオーバーが行われたマスターに、予備マスターの種類はマスターに変更されます。フェイルオーバーの過程で障害が発生したマスターに対する自動復旧が行われ、自動復旧に成功した場合、フェイルオーバーが行われたマスターは再び予備マスターとして機能します。フェイルオーバーが行われたマスターを復旧または再構築するまでフェイルオーバーは実行されません。昇格したマスターは、フェイルオーバーが行われたマスターの全ての自動バックアップを引き継ぎます。 昇格したマスターで新規にバックアップが行われた時間から時点復元を行うことができます。
[参考] 高可用性機能はドメインを基盤にしているため、接続を試みるクライアントがDNSサーバーに接続できないネットワーク環境である場合、ドメインを介してDBインスタンスに接続することができず、フェイルオーバー発生時に正常な接続ができません。 内部仮想IPが予備マスターからマスターに変更される過程で、一時的に接続が中断されることがあります。
障害が発生してフェイルオーバーが行われたマスターをフェイルオーバーが行われたマスターといいます。フェイルオーバーが行われたマスターの自動バックアップは行われず、フェイルオーバーが行われたマスターの復旧、再構築、分離、削除を除く他の全ての機能は実行できません。
フェイルオーバーの過程でデータの整合性が崩れず、障害が発生した時点から復旧を試みる時点まで保管されたトランザクションログ(Archived Write Ahead Log)が消失していなければ、フェイルオーバーが行われたマスターと昇格したマスターを再びHA構成で復旧できます。フェイルオーバーが行われたマスターのデータベースをそのまま昇格したマスターと複製関係を再設定するため、データの整合性が崩れたり、復旧に必要な保管されたトランザクションログ(Archived Write Ahead Log)が消失している場合、復旧は失敗します。フェイルオーバーが行われたマスターの復旧に失敗した場合、再構築を通じて再び高可用性機能を有効にできます。
フェイルオーバーが行われたマスターを復旧するにはコンソールで
❶復旧したいフェイルオーバーが行われたマスターを選択し、ドロップダウンメニューからフェイルオーバーが行われたマスター復旧メニューをクリックします。
フェイルオーバーが行われたマスターの復旧に失敗した場合、再構築を利用して再び高可用性機能を有効にできます。再構築は復旧とは異なり、フェイルオーバーが行われたマスターのデータベースを全て削除し、昇格したマスターのデータベースを基に再構築します。フェイルオーバーが行われたマスターを再構築するにはレプリケーショングループに属するDBインスタンスのうち、バックアップファイル及び保管されたトランザクションログ(Archived Write Ahead Log)が必要です。バックアップファイルがない場合、次の順序でバックアップを実行するDBインスタンスを選択します。
❶自動バックアップを設定したリードレプリカ ❷自動バックアップを設定したマスター
条件に合うDBインスタンスがない場合、フェイルオーバーが行われたマスター再構築リクエストは失敗します。
[注意] マスターのデータベースサイズに比例して、フェイルオーバーが行われたマスターの再構築時間が長くなる場合があります。 バックアップが実行されるDBインスタンスの場合、フェイルオーバーが行われたマスターの再構築過程でストレージI/O性能が低下する可能性があります。
フェイルオーバーが行われたマスターを再構築するには、コンソールで
❶再構築したいフェイルオーバーが行われたマスターを選択し、ドロップダウンメニューからフェイルオーバーが行われたマスター再構築メニューをクリックします。
フェイルオーバーが行われたマスターの復旧に失敗してデータ補正が必要な場合、フェイルオーバーが行われたマスターを分離して高可用性機能を無効にできます。分離されたマスターと昇格したマスター間の複製関係が切断され、それぞれ一般DBインスタンスとして動作します。分離された後は、元の構成に復旧することはできません。
フェイルオーバーが行われたマスターを分離するにはコンソールで
❶分離したいフェイルオーバーが行われたマスターを選択し、ドロップダウンメニューからフェイルオーバーが行われたマスター分離*メニューをクリックします。
高可用性DBインスタンスの場合、再起動を伴う作業を実行すると、フェイルオーバーを利用した再起動を行うかどうかを選択することができ、該当作業は次のとおりです。
フェイルオーバーを利用した再起動をする場合、予備マスターを先に再起動します。その後、フェイルオーバーを通じて予備マスターをマスターに昇格させ、既存マスターは予備マスターの役割をすることになります。昇格時、接続のための内部仮想IPはマスターから予備マスターに変更されるため、アプリケーションソフトウェアの変更は必要ありません。昇格したマスターは以前のマスターの全ての自動バックアップを継承します。
[参考] 高可用性機能はドメインを基盤にしているため、接続を試みるクライアントがDNSサーバーに接続できないネットワーク環境である場合、ドメインを介してDBインスタンスに接続することができず、フェイルオーバー発生時に正常な接続ができません。
[注意] 予備マスターとレプリケーショングループに含まれるリードレプリカの複製遅延値が1以上の場合、複製遅延が発生したとみなし、このとき、手動フェイルオーバーは失敗します。負荷が小さい時間に手動フェイルオーバーを行うことを推奨します。複製遅延による再起動失敗はイベント画面で確認できます。
フェイルオーバーを利用した再起動の際、次の項目を追加で選択して安定性を高めることができます。
フェイルオーバーを利用した再起動が完了した後、すぐに手動バックアップを進行できます。
予備マスターに変更を先に適用した後、その推移を観察したり、正確な時間にフェイルオーバーを実行したい場合、コンソールでフェイルオーバーのタイミングを直接制御できます。フェイルオーバー手動制御を選択すると、予備マスターが再起動された後、❶コンソールにフェイルオーバーボタンが表示されます。このボタンをクリックするとフェイルオーバーが実行され、最大5日間実行を待機できます。5日以内にフェイルオーバーを実行しない場合、その作業は自動的にキャンセルされます。
[注意] フェイルオーバーを待機している間は、自動フェイルオーバーは実行されません。
複製遅延解消待機オプションを有効にすると、予備マスターとレプリケーショングループに含まれるリードレプリカの複製遅延がなくなるまで待機できます。
複製遅延を解消する間、書き込み負荷を追加的に遮断する選択が可能です。書き込み負荷を遮断すると、フェイルオーバーを実行する直前にマスターが読み取り専用モードに切り替わり、全ての変更クエリが失敗するように設定されます。
一時的な作業による接続中断や大量の負荷が予想される状況で、一時的に高可用性機能を停止できます。高可用性機能が一時停止されると、障害が検知されないため、フェイルオーバーを実行しません。高可用性機能が一時停止された状態で再起動が必要な作業を実行しても、一時停止された高可用性機能が再開されません。高可用性機能が一時停止されてもデータ複製は正常に行われ、障害が検知されないため、長時間一時停止状態に維持することは推奨しません。
ネットワークの切断、他のマスターからの複製設定など、様々な原因で予備マスターの複製が中断されることがあります。複製中断状態の予備マスターは、自動フェイルオーバーが実行されません。予備マスターの複製中断を解決するには、予備マスターを再構築する必要があります。予備マスターの再構築時には、予備マスターのデータベースを全て削除し、マスターのデータベースを基に再構築します。この過程で、再構築に必要なバックアップファイルがマスターデータベースに存在しない場合、マスターでバックアップが行われ、バックアップによる性能低下が発生する可能性があります。
pg_dump -h {rds_instance_floating_ip} -U {db_id} -p {db_port} -d {database_name} -f {local_path_and_file_name}
pg_dump -h {rds_instance_floating_ip} -U {db_id} -p {db_port} -d {database_name} | psql -h {external_db_host} -U {external_db_id} -p {external_db_port} -d {external_database_name}
NHN Cloudは定期的にDBインスタンスのハイパーバイザーソフトウェアをアップデートし、セキュリティと安定性を向上させています。 点検対象ハイパーバイザーで稼働中のDBインスタンスは、マイグレーションを通じて点検が完了したハイパーバイザーに移動する必要があります。
DBインスタンスのマイグレーションは、NHN Cloudコンソールから開始できます。 下記のガイドに従って、コンソールにあるマイグレーション機能をご利用ください。 点検対象に指定されたDBインスタンスがあるプロジェクトに移動します。
名前の横にマイグレーションボタンがあるDBインスタンスが点検対象インスタンスです。
マイグレーションボタンの上にマウスポインタを置くと、詳細な点検スケジュールを確認できます。
DBに接続されたサービスに影響を与えないように適切な措置を取ってください。 サービスに影響を及ぼすことが避けられない場合は、NHN Cloudサポートにご連絡いただければ、適切な対応をご案内いたします。
DBインスタンスの状態が変更されない場合は、「更新」を行ってください。
DBインスタンスがマイグレーションされている間は、何の操作もできません。 DBインスタンスのマイグレーションが正常に完了しない場合、自動的に管理者に報告され、NHN Cloudから別途ご連絡いたします。