# Amazon RDS for PostgreSQL
Amazon RDS では、PostgreSQL の複数のバージョンを実行する DB インスタンスがサポートされています。利用可能なバージョンのリストについては、「[利用可能な PostgreSQL データベースのバージョン](PostgreSQL.Concepts.General.DBVersions.md)」を参照してください。
DB インスタンス、DB スナップショット、ポイントインタイムの復元とバックアップを作成できます。PostgreSQL を実行する DB インスタンスでは、マルチ AZ 配置、リードレプリカ、プロビジョンド IOPS がサポートされています。これらのインスタンスは、仮想プライベートクラウド (VPC) 内で作成できます。PostgreSQL を実行する DB インスタンスには Secure Socket Layer (SSL) でも接続できます。
DB インスタンスを作成する前に、必ず「[Amazon RDS 環境のセットアップ](CHAP_SettingUp.md)」の手順を完了してください。
スタンダード的な SQL クライアントアプリケーションを使用して、クライアントコンピュータからインスタンスに対してコマンドを実行できます。例えば、pgAdmin (PostgreSQL 用に普及しているオープンソースの管理および開発ツール) や psql (PostgreSQL インストールに含まれるコマンドラインユーティリティ) などのアプリケーションを使用できます。マネージド型サービスエクスペリエンスを提供するために、Amazon RDS では DB インスタンスへのホストアクセスが許可されません。また、アドバンストの特権を必要とする特定のシステムの手順やテーブルへのアクセスも制限されいます。Amazon RDS は、任意のスタンダード SQL クライアントアプリケーションによる、DB インスタンス上のデータベースへのアクセスがサポートされています。Amazon RDS では、Telnet またはセキュアシェル (SSH) を使用しての、DB インスタンスへのダイレクトホストアクセスは許可されません。
Amazon RDS for PostgreSQL は、多くの業界スタンダードに準拠しています。例えば、Amazon RDS for PostgreSQL データベースを使用して、HIPAA 準拠アプリケーションをビルドしたり、医療関連の情報を保存したりできます。これには、AWS との間で締結された事業提携契約 (BAA) に基づく保護されるべき医療情報 (PHI) の保存が含まれます。また、Amazon RDS for PostgreSQL は、Federal Risk and Authorization Management Program (FedRAMP) のセキュリティ要件を満たしています。Amazon RDS for PostgreSQL は、AWS GovCloud (US) リージョンにおいて、FedRAMP Joint Authorization Board (JAB) の Provisional Authority to Operate (P-ATO) として、FedRAMP High ベースラインの認証を受けています。サポートされるコンプライアンススタンダードの詳細については、[AWS クラウドコンプライアンス](https://aws.amazon.com/compliance/)を参照してください。
PostgreSQL データを DB インスタンスにインポートするには、「[Amazon RDS の PostgreSQL にデータをインポートする](PostgreSQL.Procedural.Importing.md)」セクションの説明に従ってください。
**重要**
RDS for PostgreSQL DB インスタンスで問題が発生した場合、AWS サポートエージェントはデータベースのヘルスに関する詳細情報を必要とする場合があります。目標は、AWS サポートが必要な情報をできるだけ早く取得できるようにすることです。
PG コレクターを使用すると、統合された HTML ファイルに貴重なデータベース情報を収集できます。PG コレクター、その実行方法、HTML レポートのダウンロード方法の詳細については、「[PG Collector](https://github.com/awslabs/pg-collector)」を参照してください。
正常に完了すると、特に指定しない限り、スクリプトは読み取り可能な HTML 形式で出力を返します。スクリプトは、ビジネスを危険にさらす可能性があるデータやセキュリティの詳細を HTML から除外するように設計されています。また、データベースや環境を変更することはありません。ただし、HTML 内に共有したくない情報がある場合は、HTML をアップロードする前に該当の情報を削除してください。HTML が許容できる内容となったら、サポートケースの [ケースの詳細] で [添付ファイル] セクションを使用してアップロードします。
**Topics**
+ [
# Amazon RDS for PostgreSQL の一般的な管理タスク
](CHAP_PostgreSQL.CommonTasks.md)
+ [
# データベースプレビュー環境の使用
](working-with-the-database-preview-environment.md)
+ [
# 利用可能な PostgreSQL データベースのバージョン
](PostgreSQL.Concepts.General.DBVersions.md)
+ [
# RDS for PostgreSQL 増分リリースプロセスについて
](PostgreSQL.Concepts.General.ReleaseProcess.md)
+ [
# サポートされている PostgreSQL 拡張機能バージョン
](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md)
+ [
# Amazon RDS for PostgreSQL でサポートされている PostgreSQL の機能を使用する
](PostgreSQL.Concepts.General.FeatureSupport.md)
+ [
# PostgreSQL データベースエンジンを実行する DB インスタンスへの接続
](USER_ConnectToPostgreSQLInstance.md)
+ [
# SSL/TLS を使用して RDS for PostgreSQL への接続を保護する
](PostgreSQL.Concepts.General.Security.md)
+ [
# Amazon RDS for PostgreSQL で Kerberos 認証を使用する
](postgresql-kerberos.md)
+ [
# アウトバウンドネットワークアクセスでカスタム DNS サーバーを使用する
](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
+ [
# RDS for PostgreSQL DB エンジンのアップグレード
](USER_UpgradeDBInstance.PostgreSQL.md)
+ [
# PostgreSQL DB スナップショットエンジンのバージョンのアップグレード
](USER_UpgradeDBSnapshot.PostgreSQL.md)
+ [
# Amazon RDS for PostgreSQL でのリードレプリカの使用
](USER_PostgreSQL.Replication.ReadReplicas.md)
+ [
# Amazon RDS Optimized Reads による RDS for PostgreSQL のクエリパフォーマンスの向上
](USER_PostgreSQL.optimizedreads.md)
+ [
# Amazon RDS の PostgreSQL にデータをインポートする
](PostgreSQL.Procedural.Importing.md)
+ [
# RDS for PostgreSQL DB インスタンスから Amazon S3 へのデータのエクスポート
](postgresql-s3-export.md)
+ [
# RDS for PostgreSQL DB インスタンスから AWS Lambda 関数を呼び出す
](PostgreSQL-Lambda.md)
+ [
# Amazon RDS for PostgreSQL の一般的な DBA タスク
](Appendix.PostgreSQL.CommonDBATasks.md)
+ [
# RDS for PostgreSQL の待機イベントでのチューニング
](PostgreSQL.Tuning.md)
+ [
# Amazon DevOps Guru のプロアクティブインサイトによる RDS for PostgreSQL のチューニング
](PostgreSQL.Tuning_proactive_insights.md)
+ [
# Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用する
](Appendix.PostgreSQL.CommonDBATasks.Extensions.md)
+ [
# Amazon RDS for PostgreSQL でサポートされている外部データラッパーを使用する
](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)
+ [
# Trusted Language Extensions for PostgreSQL を使用した操作
](PostgreSQL_trusted_language_extension.md)
# Amazon RDS for PostgreSQL の一般的な管理タスク
以下に示しているのは、Amazon RDS for PostgreSQL DB インスタンスで実行する一般的な管理タスクと、各タスクの関連ドキュメントへのリンクです。
| タスク領域 | 関連資料 |
| --- | --- |
| **Amazon RDS を初めてセットアップして使う** DB インスタンスを作成する前に、いくつかの前提条件を満たしていることを確認してください。例えば、DB インスタンスが作成されると、アクセスを禁止するファイアウォールがデフォルトで設定されます。したがって、DB インスタンスにアクセスするために、IP アドレスとネットワーク設定が正しく指定されたセキュリティグループを作成する必要があります。 | [Amazon RDS 環境のセットアップ](CHAP_SettingUp.md) |
| **Amazon RDS DB インスタンスを理解する** 本稼働用に DB インスタンスを作成する場合、インスタンスクラス、ストレージタイプ、およびプロビジョンド IOPS が Amazon RDS でどのように機能するか理解する必要があります。 | [ DB インスタンスクラス](Concepts.DBInstanceClass.md) [Amazon RDS ストレージタイプ](CHAP_Storage.md#Concepts.Storage) [プロビジョンド IOPS SSD ストレージ](CHAP_Storage.md#USER_PIOPS) |
| **利用可能な PostgreSQL バージョンの検索** Amazon RDS は、PostgreSQL の複数のバージョンをサポートします。 | [利用可能な PostgreSQL データベースのバージョン](PostgreSQL.Concepts.General.DBVersions.md) |
| **高可用性およびフェイルオーバーサポートのセットアップ** 本稼働 DB インスタンスは、マルチ AZ 配置を使用する必要があります。マルチ AZ 配置は、DB インスタンスの拡張された可用性、データ堅牢性、および耐障害性を提供します。 | [Amazon RDS でのマルチ AZ 配置の設定と管理](Concepts.MultiAZ.md) |
| **Amazon Virtual Private Cloud (VPC) ネットワークについて** AWS アカウントにデフォルト VPC がある場合、DB インスタンスがデフォルト VPC 内に自動的に作成されます。場合によっては、アカウントにデフォルトの VPC がないため、VPC に DB インスタンスが必要な場合もあります。このような場合、DB インスタンスを作成する前に VPC とサブネットグループを作成します。 | [VPC 内の DB インスタンスの使用](USER_VPC.WorkingWithRDSInstanceinaVPC.md) |
| **Amazon RDS PostgreSQL にデータをインポートする** Amazon RDS の PostgreSQL DB インスタンスにデータをインポートするには、さまざまなツールを使用できます。 | [Amazon RDS の PostgreSQL にデータをインポートする](PostgreSQL.Procedural.Importing.md) |
| **読み取り専用リードレプリカ (プライマリおよびスタンバイ) のセットアップ** RDS for PostgreSQL では、同じ AWS リージョン、および、プライマリインスタンスとは別の AWS リージョンの両方で、リードレプリカがサポートされます。 | [DB インスタンスのリードレプリカの操作](USER_ReadRepl.md) [Amazon RDS for PostgreSQL でのリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.md) [別の でのリードレプリカの作成AWS リージョン](USER_ReadRepl.XRgn.md) |
| **セキュリティグループの理解** デフォルトでは、DB インスタンスが作成されると、アクセスを禁止するファイアウォールが設定されます。そのファイアウォールを介してアクセスできるようにするには、DB インスタンスをホストする VPC に関連付けられている VPC セキュリティグループのインバウンドルールを編集します。 | [セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md) |
| **パラメータグループおよび機能のセットアップ** DB インスタンスのデフォルトパラメータを変更するには、カスタム DB パラメータグループを作成し、設定をそのパラメータグループに変更します。DB インスタンスを作成する前にこの操作を行うと、インスタンスの作成時にカスタム DB パラメータグループを選択できます。 | [Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md) |
| **PostgreSQL DB インスタンスへの接続** セキュリティグループを作成し、それを DB インスタンスに関連付けると、`psql` や `pgAdmin` などの標準的な SQL クライアントアプリケーションを使用して DB インスタンスに接続できます。 | [PostgreSQL データベースエンジンを実行する DB インスタンスへの接続](USER_ConnectToPostgreSQLInstance.md) [PostgreSQL DB インスタンスで SSL を使用する](PostgreSQL.Concepts.General.SSL.md) |
| **DB インスタンスのバックアップと復元** バックアップが自動的に作成されるように DB インスタンスを設定したり、スナップショットを手動で作成したりできます。そうすることで後で、そのバックアップまたはスナップショットからインスタンスを復元できます。 | [データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md) |
| **DB インスタンスのアクティビティとパフォーマンスのモニタリング** CloudWatch Amazon RDS メトリクス、イベント、および拡張モニタリングを使用することで、PostgreSQL DB インスタンスをモニタリングできます。 | [Amazon RDS コンソールでのメトリクスの表示](USER_Monitoring.md) [Amazon RDS イベントの表示](USER_ListEvents.md) |
| **PostgreSQL データベースバージョンのアップグレード** PostgreSQL DB インスタンスのメジャーバージョンとマイナーバージョンの両方をアップグレードできます。 | [RDS for PostgreSQL DB エンジンのアップグレード](USER_UpgradeDBInstance.PostgreSQL.md) [RDS for PostgreSQL のメジャーバージョンアップグレードの選択](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md) |
| **ログファイルの操作** PostgreSQL DB インスタンスのログファイルにアクセスできます。 | [ RDS for PostgreSQL データベースログファイル](USER_LogAccess.Concepts.PostgreSQL.md) |
| **PostgreSQL DB インスタンスに関するベストプラクティスの理解** Amazon RDS での PostgreSQL の使用に関するいくつかのベストプラクティスが見つかります。 | [PostgreSQL を使用するためのベストプラクティス](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL) |
RDS for PostgreSQL の重要な機能の理解と使用に役立つ、このガイドの他のセクションのリストは次のとおりです。
+ [PostgreSQL のロールとアクセス権限について](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [PostgreSQL データベースへのユーザーアクセスのコントロールPostgreSQL へのユーザーアクセスのコントロール](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [RDS for PostgreSQL DB インスタンスでのパラメータの使用](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
+ [RDS for PostgreSQL でサポートされているログ記録メカニズムについて](Appendix.PostgreSQL.CommonDBATasks.md#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [アウトバウンドネットワークアクセスでカスタム DNS サーバーを使用する](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)
# データベースプレビュー環境の使用
PostgreSQL コミュニティは、ベータバージョンを含め、新しい PostgreSQL バージョンとエクステンションを絶えずリリースしています。これにより、PostgreSQL ユーザーは新しい PostgreSQL バージョンを早期に試すことができます。PostgreSQL コミュニティのベータリリースプロセスの詳細については、PostgreSQL ドキュメントの「[ベータ情報](https://www.postgresql.org/developer/beta/)」を参照してください。同様に、Amazon RDS では特定の PostgreSQL ベータバージョンをプレビューリリースとして提供するようにしています。これにより、プレビューバージョンを使用して DB インスタンスを作成し、その機能をデータベースプレビュー環境でテストできます。
データベースプレビュー環境の RDS for PostgreSQL DB インスタンスは、機能的に他の RDS for PostgreSQL インスタンスに似ています。ただし、プレビューバージョンは本稼働に使用できません。
次の重要な制約事項に留意してください。
+ すべての DB インスタンスは、作成から 60 日後にバックアップおよびスナップショットとともに削除されます。
+ DB インスタンスは、Amazon VPC サービスに基づく仮想プライベートクラウド (VPC) でのみ作成できます。
+ 汎用 SSD およびプロビジョンド IOPS SSD ストレージのみを使用できます。
+ DB インスタンスに関して AWS サポートからヘルプを受けることはできません。代わりに、AWS マネージド Q&A コミュニティ、[AWS re:Post](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service) に質問を投稿できます。
+ DB インスタンスのスナップショットを本稼働環境にコピーすることはできません。
プレビューでは、以下のオプションがサポートされています。
+ DB インスタンスは、M6i、R6i、M6g、M5、T3、R6g、および R5 インスタンスタイプのみで作成できます。RDS インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
+ シングル AZ 配置とマルチ AZ 配置の両方を使用できます。
+ スタンダードの PostgreSQL ダンプおよびロード機能を使用して、データベースをデータベースプレビュー環境にエクスポートしたり、データベースプレビュー環境にインポートしたりできます。
**Topics**
+ [
## データベースプレビュー環境でサポートされない機能
](#preview-environment-exclusions)
+ [
## データベースプレビュー環境の PostgreSQL バージョン 17
](#PostgreSQL.Concepts.General.version17)
+ [
# データベースプレビュー環境での新しい DB インスタンスの作成
](create-db-instance-in-preview-environment.md)
## データベースプレビュー環境でサポートされない機能
以下の機能は、データベースプレビュー環境で使用できません。
+ クロスリージョンスナップショットのコピー
+ クロスリージョンリードレプリカ
## データベースプレビュー環境の PostgreSQL バージョン 17
**注記**
これは Amazon RDS PostgreSQL バージョン 17 のプレビュードキュメントです。このドキュメントは変更される可能性があります。
PostgreSQL バージョン 17.0 が Amazon RDS データベースプレビュー環境で利用可能になりました。PostgreSQL バージョン 17 には、次の PostgreSQL ドキュメントに記載されているいくつかの改善点が含まれています: 「[PostgreSQL 17 がリリースされました](https://www.postgresql.org/docs/17/release-17.html)」。
データベースプレビュー環境の詳細については、「[データベースプレビュー環境の使用](#working-with-the-database-preview-environment)」を参照してください。コンソールからプレビュー環境にアクセスするには、[https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/) を選択します。
# データベースプレビュー環境での新しい DB インスタンスの作成
プレビュー環境で DB インスタンスを作成するには、次の手順を使用します。
**データベースプレビュー環境で新しい DB インスタンスを作成するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**ダッシュボード**] を選択します。
1. [Dashboard] (ダッシュボード) ページで、次の図に示すように、[Dashboard] (ダッシュボード) ページの **[Database Preview Environment]** (データベースプレビュー環境) セクションを見つけます。
![\[RDS コンソール、ダッシュボードにリンクが表示されたプレビュー環境セクション\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png)
また、[[データベースプレビュー環境]](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#) に直接移動することもできます。先に進む前に、制限事項を確認して同意する必要があります。
![\[プレビュー環境制約事項ダイアログ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/preview-environment-console.png)
1. RDS for PostgreSQL DB インスタンスを作成するには、任意の Amazon RDS DB インスタンスを作成する場合と同じプロセスに従います。詳細については、[DB インスタンスの作成](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating) 下の [コンソール](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) 手順を参照してください。
RDS API または AWS CLI を使用してデータベースプレビュー環境でインスタンスを作成するには、次のエンドポイントを使用します。
```
rds-preview.us-east-2.amazonaws.com
```
# 利用可能な PostgreSQL データベースのバージョン
Amazon RDS では、PostgreSQL の複数のエディションを実行する DB インスタンスがサポートされています。新しい DB インスタンスを作成する際、現在利用可能な PostgreSQL バージョンであればどれでも指定できます。メジャーバージョン (PostgreSQL 14 など) と、指定したメジャーバージョンで利用可能な任意のマイナーバージョンを指定できます。バージョンを指定しない場合、Amazon RDS では、利用可能なバージョン (通常は最新バージョン) がデフォルトで設定されます。マイナーバージョンではなく、メジャーバージョンを指定した場合は、Amazon RDS では、お客様が指定したメジャーバージョンの最新リリースにデフォルトで設定されます。
利用可能なバージョンのリストと、新しく作成された DB インスタンスのデフォルト設定を表示するには、AWS CLI の [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) コマンドを使用します。例えば、デフォルトの PostgreSQL エンジンのバージョンを表示するには、次のコマンドを使用します。
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
Amazon RDS でサポートされている PostgreSQL バージョンの詳細については、[https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/Welcome.html)を参照してください。[describe-db-major-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-major-engine-versions.html) AWS CLI コマンドを実行するか、[DescribeDBMajorEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBMajorEngineVersions.html) RDS API オペレーションを使用して、メジャーエンジンバージョンのサポート日に関する情報を表示することもできます。
RDS 標準サポート終了日より前に新しいメジャーエンジンバージョンに手動でアップグレードする準備ができていない場合、Amazon RDS は RDS 標準サポート終了日以降にデータベースを Amazon RDS 延長サポートに自動的に登録します。その後、RDS for PostgreSQL バージョン 11 以降を引き続き実行できます。詳細については、「[Amazon RDS の Amazon RDS 延長サポート](extended-support.md)」および「[Amazon RDS の料金](https://aws.amazon.com/rds/pricing/)」を参照してください。
## Amazon RDS for PostgreSQL の非推奨バージョン
以下の廃止バージョンに注意してください。
+ RDS for PostgreSQL 10 は 2023 年 2 月に廃止されました。
+ RDS for PostgreSQL 9.6 は 2022 年 3 月に廃止されました。
+ RDS for PostgreSQL 9.5 は、2021 年 3 月に廃止されました。
RDS for PostgreSQL の非推奨ポリシーの詳細については、「[Amazon RDS のよくある質問](https://aws.amazon.com/rds/faqs/)」を参照してください。PostgreSQL のバージョンの詳細については、PostgreSQL のドキュメントの「[Versioning Policy](https://www.postgresql.org/support/versioning/)」(バージョニングポリシー) を参照してください。
# RDS for PostgreSQL 増分リリースプロセスについて
RDS for PostgreSQL は、マイナーバージョンの互換性を維持しながら、増分リリースを通じてセキュリティ修正、パフォーマンスの向上、新機能を提供します。これらのリリースには、R1、R2、R3 などのラベルが付けられます。
**リリースバージョンの命名規則**
+ R1 はマイナーバージョンの初期リリースです。これには、新機能、拡張機能、または既存の拡張機能へのアップグレードが含まれることがあります。
+ 以降のリリースバージョン (R2、R3 以降) には以下が含まれます。
+ セキュリティ更新
+ フォーマンスの向上
+ バグ修正
+ 拡張機能の更新
## RDS for PostgreSQL 増分リリースプロセスの利点
増分リリースプロセスには、次の利点があります。
+ 新しい PostgreSQL コミュニティリリースを迅速に導入し、以降のリリースで RDS 固有の機能強化を個別に管理します。これにより、リリースプロセスが合理化され、重要な更新を迅速に配信できます。
+ PostgreSQL マイナーバージョンとの互換性を維持しながら、バグ修正、新機能、セキュリティ更新、拡張機能の更新にアクセスできます。
## リリース更新の管理
Amazon RDS は、AWS マネジメントコンソールで保留中のメンテナンスアクションを通じて、新しい増分リリースについて通知します。データベースは、次のいずれかの方法を使用して更新できます。
+ スケジュールされたメンテナンス期間中に自動更新を有効にする。
+ 保留中のメンテナンスアクションを通じて更新を手動で適用する。
+ ダウンタイムを最小限に抑えるには、物理レプリケーションでブルー/グリーンデプロイを使用します。詳細については、[「ブルー/グリーンデプロイ RDS for PostgreSQL におけるマイナーバージョンアップグレードをサポート](https://aws.amazon.com/about-aws/whats-new/2024/11/rds-blue-green-deployments-upgrade-rds-postgresql/)」を参照してください。
データベースを更新する前に次の重要な点を考慮してください。
+ 物理レプリケーションでブルー/グリーンデプロイを使用しない場合、更新にはデータベースの再起動が必要です。
+ 一部の増分リリース、特にセキュリティ修正を含むリリースは必須です。
Amazon RDS DB インスタンスの更新の詳細については、「[PostgreSQL 信頼できるエクステンション](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted)」および「[apply-pending-maintenance-action](https://docs.aws.amazon.com/cli/latest/reference/rds/apply-pending-maintenance-action.html)」を参照してください。
# サポートされている PostgreSQL 拡張機能バージョン
RDS for PostgreSQL は、多くの PostgreSQL エクステンションをサポートしています。PostgreSQL コミュニティでは、これらをモジュールと呼ぶことがあります。エクステンションは、PostgreSQL エンジンが提供する機能を拡張します。Amazon RDS がサポートするエクステンションのリストは、該当する PostgreSQL バージョンのデフォルトの DB パラメータグループで確認できます。また、次の例に示すように、`psql` で `rds.extensions` パラメータを表示することで、最新のエクステンションのリストを確認することもできます。
```
SHOW rds.extensions;
```
**注記**
マイナーバージョンのリリースで追加されたパラメータは、`rds.extensions` で `psql` パラメータを使用する際に正しく表示されない場合があります。
RDS for PostgreSQL 13 以降、`rds_superuser` 以外のデータベースユーザーがインストールできる拡張機能があります。これらは、*信頼できる拡張機能*として知られています。詳細については[PostgreSQL 信頼できるエクステンション](#PostgreSQL.Concepts.General.Extensions.Trusted)を参照してください。
RDS for PostgreSQL の特定のバージョンでは、`rds.allowed_extensions` パラメータに対応しています。このパラメータにより、`rds_superuser` は RDS for PostgreSQL DB インスタンスにインストールできる拡張機能を制限します。(詳しくは、「[PostgreSQL エクステンションのインストールを制限する](#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction)」を参照してください。)
利用できる各 RDS for PostgreSQL バージョンでサポートされている PostgreSQL 拡張機能のリストについては、*Amazon RDS for PostgreSQL リリースノート*の「[Amazon RDS でサポートされる PostgreSQL の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html)」を参照してください。
## PostgreSQL エクステンションのインストールを制限する
PostgreSQL DB インスタンスにインストールできるエクステンションを制限できます。デフォルトでは、このパラメータは設定されていないため、ユーザーに権限がある場合は、サポートされている任意の拡張機能を追加できます。そのためには、`rds.allowed_extensions` パラメータをカンマで区切った拡張子名の文字列に設定します。このパラメータに拡張機能のリストを追加すると、RDS for PostgreSQL DB インスタンスで使用できる拡張機能が明示的に特定できます。その後、PostgreSQL DB インスタンスにインストールできるのは、これらのエクステンションだけです。
`rds.allowed_extensions` パラメータのデフォルトの文字列は '\$1' です。これは、そのエンジンのバージョンで使用できるエクステンションは何でもインストールできることを意味します。動的パラメータであるため、`rds.allowed_extensions` パラメータを変更しても、データベースを再起動する必要はありません。
`rds.allowed_extensions` パラメータを使用するには、PostgreSQL DB インスタンスエンジンは次のバージョンのいずれかである必要があります。
+ すべての PostgreSQL 16 バージョン
+ PostgreSQL 15 以降のすべてのバージョン
+ PostgreSQL 14 以降のすべてのバージョン
+ PostgreSQL 13.3 以降のマイナーバージョン
+ PostgreSQL 12.7 以降のマイナーバージョン
どのエクステンションのインストールが許可されているかを確認するには、次の psql コマンドを使用します。
```
postgres=> SHOW rds.allowed_extensions;
rds.allowed_extensions
------------------------
*
```
エクステンションが `rds.allowed_extensions` パラメータのリストから除外される前にインストールされていた場合でも、エクステンションは正常に使用でき、`ALTER EXTENSION` や `DROP EXTENSION` などのコマンドは引き続き機能します。ただし、エクステンションが制限されると、制限されたエクステンションの `CREATE EXTENSION` コマンドは失敗します。
`CREATE EXTENSION CASCADE` とのエクステンションの依存関係のインストールも制限されています。エクステンションとその依存関係は、`rds.allowed_extensions` で指定する必要があります。拡張依存のインストールが失敗すると、`CREATE EXTENSION CASCADE` 文全体が失敗します。
`rds.allowed_extensions` パラメータにエクステンションが含まれていない場合、インストールしようとすると、次のようなエラーが表示されます。
```
ERROR: permission denied to create extension "extension-name"
HINT: This extension is not specified in "rds.allowed_extensions".
```
## PostgreSQL 信頼できるエクステンション
ほとんどの PostgreSQL エクステンションをインストールするには、`rds_superuser` 権限が必要です。PostgreSQL 13 では、信頼できるエクステンションが導入されました。これにより、一般ユーザーに `rds_superuser` 特権を付与する必要が少なくなります。この機能を使用すると、ユーザーは、`CREATE` ロールを要求する代わりに、現在のデータベースに対する `rds_superuser` 権限を持っている場合、多くのエクステンションをインストールできます。詳細については、PostgreSQL ドキュメントの SQL [CREATE EXTENSION](https://www.postgresql.org/docs/current/sql-createextension.html) コマンドを参照してください。
以下に、現在のデータベースに対する `CREATE` 権限を持ち、`rds_superuser` ロールを必要としないユーザーがインストールできるエクステンションを示します。
+ bool\$1plperl
+ [btree\$1gin](http://www.postgresql.org/docs/current/btree-gin.html)
+ [btree\$1gist](http://www.postgresql.org/docs/current/btree-gist.html)
+ [citext](http://www.postgresql.org/docs/current/citext.html)
+ [cube](http://www.postgresql.org/docs/current/cube.html)
+ [dict\$1int](http://www.postgresql.org/docs/current/dict-int.html)
+ [fuzzystrmatch](http://www.postgresql.org/docs/current/fuzzystrmatch.html)
+ [hstore](http://www.postgresql.org/docs/current/hstore.html)
+ [ intarray](http://www.postgresql.org/docs/current/intarray.html)
+ [isn](http://www.postgresql.org/docs/current/isn.html)
+ jsonb\$1plperl
+ [ltree](http://www.postgresql.org/docs/current/ltree.html)
+ [pg\$1trgm](http://www.postgresql.org/docs/current/pgtrgm.html)
+ [pgcrypto](http://www.postgresql.org/docs/current/pgcrypto.html)
+ [plperl](https://www.postgresql.org/docs/current/plperl.html)
+ [plpgsql](https://www.postgresql.org/docs/current/plpgsql.html)
+ [pltcl](https://www.postgresql.org/docs/current/pltcl-overview.html)
+ [tablefunc](http://www.postgresql.org/docs/current/tablefunc.html)
+ [tsm\$1system\$1rows](https://www.postgresql.org/docs/current/tsm-system-rows.html)
+ [tsm\$1system\$1time](https://www.postgresql.org/docs/current/tsm-system-time.html)
+ [unaccent](http://www.postgresql.org/docs/current/unaccent.html)
+ [uuid-ossp](http://www.postgresql.org/docs/current/uuid-ossp.html)
利用できる各 RDS for PostgreSQL バージョンでサポートされている PostgreSQL 拡張機能のリストについては、*Amazon RDS for PostgreSQL リリースノート*の「[Amazon RDS でサポートされる PostgreSQL の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html)」を参照してください。
# Amazon RDS for PostgreSQL でサポートされている PostgreSQL の機能を使用する
Amazon RDS for PostgreSQL は、PostgreSQL の代表的な機能の多くをサポートしています。例えば、PostgreSQL には、データベースの定期的なメンテナンスを実行する自動バキューム機能があります。autovacuum 機能は、デフォルトでアクティブになっています。この機能をオフにすることはできますが、オンにしておくことを強くお勧めします。この機能を理解し、それを正しく動作させるために何ができるかを把握することは、どの DBA にとっても基本的なタスクです。自動バキュームの詳細については、「[Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)」を参照してください。その他の一般的な DBA タスクの詳細については、「[Amazon RDS for PostgreSQL の一般的な DBA タスク](Appendix.PostgreSQL.CommonDBATasks.md)」を参照してください。
RDS for PostgreSQL では、DB インスタンスに重要な機能性を追加する拡張機能もサポートされています。例えば、PostGIS 拡張機能を使用して空間データを操作したり、pg\$1cron 拡張機能を使用してインスタンス内からメンテナンスをスケジュールしたりできます。PostgreSQL 拡張機能の詳細については、「[Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用する](Appendix.PostgreSQL.CommonDBATasks.Extensions.md)」を参照してください。
外部データラッパーは、RDS for PostgreSQL DB インスタンスが他の商用データベースまたはデータ型と連携できるように設計された特定のタイプの拡張機能です。RDS for PostgreSQL でサポートされている外部データラッパーの詳細については、「[Amazon RDS for PostgreSQL でサポートされている外部データラッパーを使用する](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)」を参照してください。
RDS for PostgreSQL でサポートされているその他の機能については、次で説明します。
**Topics**
+ [
# RDS for PostgreSQL でのカスタムデータ型および列挙型
](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md)
+ [
# RDS for PostgreSQL のイベントトリガー
](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md)
+ [
# RDS for PostgreSQL の ヒュージページ
](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md)
+ [
# Amazon RDS for PostgreSQL の論理レプリケーションの実行
](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)
+ [
# 論理レプリケーション接続の IAM 認証の設定
](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md)
+ [
# stats\$1temp\$1directory の RAM ディスク
](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md)
+ [
# RDS for PostgreSQL のテーブルスペース
](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md)
+ [
# EBCDIC やその他のメインフレーム移行のための RDS for PostgreSQL 照合順序
](PostgreSQL.Collations.mainframe.migration.md)
+ [
# RDS for PostgreSQL の論理スロット同期の管理
](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md)
# RDS for PostgreSQL でのカスタムデータ型および列挙型
PostgreSQL では、カスタムデータ型の作成と列挙型の操作がサポートされています。列挙型とその他のデータ型の作成および操作の詳細については、「PostgreSQL のドキュメント」の「[列挙型](https://www.postgresql.org/docs/14/datatype-enum.html)」を参照してください。
次は、列挙型として型を作成し、テーブルに値を挿入する例です。
```
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors
--------
red
orange
(2 rows)
postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=> SELECT * from t1;
colors
---------
crimson
orange
(2 rows)
```
# RDS for PostgreSQL のイベントトリガー
現在すべての PostgreSQL バージョンでイベントトリガーをサポートしているため、RDS for PostgreSQL のすべての利用可能なバージョンも、同様にイベントトリガーをサポートしています。メインユーザーアカウント (デフォルトでは `postgres`) を使用して、イベントトリガーを作成、変更、名前変更、および削除できます。イベントトリガーは DB インスタンスレベルであるため、インスタンスのすべてのデータベースに適用できます。
例えば、次のコードは、各データ定義言語 (DDL) コマンドの最後に現在のユーザーを表示するイベントトリガーを作成します。
```
CREATE OR REPLACE FUNCTION raise_notice_func()
RETURNS event_trigger
LANGUAGE plpgsql AS
$$
BEGIN
RAISE NOTICE 'In trigger function: %', current_user;
END;
$$;
CREATE EVENT TRIGGER event_trigger_1
ON ddl_command_end
EXECUTE PROCEDURE raise_notice_func();
```
PostgreSQL イベントトリガーの詳細については、PostgreSQL ドキュメントの「[Event Triggers](https://www.postgresql.org/docs/current/static/event-triggers.html)」を参照してください。
Amazon RDS で PostgreSQL イベントトリガーを使用する場合、いくつかの制限があります。これには以下が含まれます。
+ リードレプリカでイベントトリガーを作成することはできません。ただし、イベントトリガーはリードレプリカソースで作成できます。作成したイベントトリガーは、リードレプリカにコピーされます。リードレプリカのイベントトリガーは、ソースから変更がプッシュされたときにリードレプリカでは起動しません。ただし、リードレプリカが昇格されると、データベースオペレーションが発生したときに既存のイベントトリガーが起動します。
+ イベントトリガーを使用する PostgreSQL DB インスタンスへのメジャーバージョンアップグレードを実行する場合は、インスタンスのアップグレード前に必ずイベントトリガーを削除してください。
# RDS for PostgreSQL の ヒュージページ
*Huge pages* はメモリ管理機能です。DB インスタンスが、共有バッファで使用されるような、大きく連続したメモリチャンクで動作しているときのオーバーヘッドを軽減します。この PostgreSQL の機能は、現在の PostgreSQL バージョンで利用可能なすべての RDS でサポートされています。`mmap`または`SYSV`共有メモリへの呼び出しを使用して、アプリケーションに巨大なページを割り当てます。RDS for PostgreSQL では、4 KB と 2 MB の両方のページサイズがサポートされています。
`huge_pages` パラメータの値を変更することで、Huge pages のオンとオフを切り替えることができます。この機能は、micro、small、medium 以外のすべての DB インスタンスクラスで、デフォルトでオンになっています。
RDS for PostgreSQL では、利用可能な共有メモリに基づき、ヒュージページを使用します。共有メモリの制約のために DB インスタンスが巨大なページを使用できない場合、Amazon RDS は DB インスタンスの起動を防ぎます。この場合、Amazon RDS により、DB インスタンスのステータスが互換性のないパラメータ状態に設定されます。これが起こると、`huge_pages`パラメータを`off`に設定して Amazon RDS で DB インスタンスの起動を許可します。
`shared_buffers` パラメータは huge ページを使用するために必要な共有メモリプールの設定に重要です。`shared_buffers`パラメータのデフォルト値は、データベースパラメータマクロを使用します。このマクロは、DB インスタンスのメモリで使用できる 8 KBのページの合計のパーセント割合を設定します。巨大なページを使用する場合、それらのページは巨大なページと一緒に配置されます。共有メモリパラメータで DB インスタンスの 90 パーセントを超えるメモリを使用するように設定すると、Amazon RDS は DB インスタンスを互換性のないパラメータ状態に設定します。
PostgreSQL のメモリ管理については、PostgreSQL のドキュメントの「[Resource Consumption](https://www.postgresql.org/docs/current/static/runtime-config-resource.html)」(資源の消費) を参照してください。
# Amazon RDS for PostgreSQL の論理レプリケーションの実行
バージョン 10.4 以降、RDS for PostgreSQL は、PostgreSQL 10 で導入されたパブリケーションおよびサブスクリプション SQL 構文をサポートしています。詳細については、「PostgreSQL のドキュメント」の「[論理レプリケーション](https://www.postgresql.org/docs/current/logical-replication.html)」を参照してください。
**注記**
PostgreSQL 10 で導入されたネイティブの PostgreSQL 論理レプリケーション機能に加えて、PostgreSQL 用 RDS は `pglogical` 拡張機能もサポートしています。詳細については、「[pglogical を使用してインスタンス間でデータを同期する](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)」を参照してください。
RDS for PostgreSQL DB インスタンスに対する論理レプリケーションの設定については、次で説明します。
**Topics**
+ [
## 論理レプリケーションと論理デコードについて
](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding)
+ [
## 論理的なレプリケーションスロットの使用
](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots)
+ [
## 論理レプリケーションを使用したテーブルレベルのデータのレプリケーション
](#PostgreSQL.Concepts.LogicalReplication.Tables)
## 論理レプリケーションと論理デコードについて
RDS for PostgreSQL は、PostgreSQL の論理レプリケーションスロットを使用した、ログ先行書き込み (WAL) 変更のストリーミングをサポートしています。また、ロジカルデコーディングの使用もサポートしています。インスタンスで論理的なレプリケーションスロットをセットアップし、それらのスロットを通じてデータベースの変更を `pg_recvlogical` などのクライアントにストリーミングできます。データベースレベルで論理レプリケーションスロットを作成すると、1 つのデータベースへのレプリケーション接続がサポートされます。
PostgreSQL 論理レプリケーション用の最も一般的なクライアントは、AWS Database Migration Service、または Amazon EC2 インスタンスのカスタム管理ホストです。論理レプリケーションスロットには、ストリームの受信者に関する情報が含まれていません。また、ターゲットをレプリカデータベースとする必要はありません。論理的なレプリケーションスロットをセットアップし、スロットから読み取りを行わない場合、データが書き込まれて、DB インスタンスのストレージがすぐにいっぱいになる可能性があります。
パラメータ、レプリケーション接続タイプ、およびセキュリティロールを使用して、Amazon RDS の PostgreSQL 論理レプリケーションおよび論理デコードをオンにします。論理デコード用のクライアントは、PostgreSQL DB インスタンスのデータベースにレプリケーション接続を確立できる任意のクライアントとすることができます。
**RDS for PostgreSQL DB インスタンスに対して論理デコードをオンにするには**
1. 使用しているユーザーアカウントに次のロールがあることを確認します。
+ 論理レプリケーションをオンにできるようにする `rds_superuser` ロール
+ 論理スロットを管理し、論理スロットを使用してデータをストリーミングするためのアクセス許可を付与する `rds_replication` ロール
1. `rds.logical_replication` 静的パラメータを 1 に設定します。このパラメータを適用する一環として、`wal_level`、`max_wal_senders`、`max_replication_slots`、`max_connections` の各パラメータも設定します。これらのパラメータの変更により、生成される WAL が増えることがあるため、論理スロットを使用する場合にのみ、`rds.logical_replication` パラメータを設定してください。
1. 静的 `rds.logical_replication` パラメータの DB インスタンスを再起動して有効にします。
1. 次のセクションの説明に従って論理的なレプリケーションスロットを作成します。このプロセスでは、デコードプラグインを指定する必要があります。現在、RDS for PostgreSQL は、PostgreSQL に付属する出力プラグイン test\$1decoding および wal2json をサポートしています。
PostgreSQL 論理的なデコードの使用の詳細については、[PostgreSQL のドキュメント](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html)を参照してください。
## 論理的なレプリケーションスロットの使用
SQL コマンドを使用して、論理的なスロットを操作できます。例えば、次のコマンドは、デフォルトの PostgreSQL 出力プラグイン `test_slot` を使用して、`test_decoding` という論理的なスロットを作成します。
```
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)
```
論理的なスロットを一覧表示するには、次のコマンドを使用します。
```
SELECT * FROM pg_replication_slots;
```
論理的なスロットを削除するには、次のコマンドを使用します。
```
SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)
```
論理的なレプリケーションスロットのその他の使用例については、PostgreSQL ドキュメントの「[Logical Decoding Examples](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html)」を参照してください。
論理的なレプリケーションスロットを作成すると、ストリーミングをスタートできます。次の例は、ストリーミングレプリケーションプロトコルで論理的なデコードがどのように制御されるかを示しています。この例では、PostgreSQL ディストリビューションに含まれているプログラム pg\$1recvlogical を使用しています。これを行うには、レプリケーション接続を許可するようにクライアント認証が設定されている必要があります。
```
pg_recvlogical -d postgres --slot test_slot -U postgres
--host -instance-name.111122223333.aws-region.rds.amazonaws.com
-f - --start
```
`pg_replication_origin_status`ビューの内容を表示するには、`pg_show_replication_origin_status` 関数を照会します。
```
SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)
```
## 論理レプリケーションを使用したテーブルレベルのデータのレプリケーション
論理レプリケーションを使用して、RDS for PostgreSQL のソーステーブルからターゲットテーブルにデータをレプリケートできます。論理レプリケーションは、まずソーステーブルから既存のデータの初期ロードを実行し、引き続いて以降の変更をレプリケートします。
1.
**ソーステーブルを作成する**
RDS for PostgreSQL DB インスタンスのソースデータベースに接続します。
```
source=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
1.
**ソーステーブルにデータを挿入する**
```
source=> INSERT INTO testtab VALUES (generate_series(1,1000));
INSERT 0 1000
```
1.
**ソーステーブルのパブリケーションを作成する**
+ ソーステーブルのパブリケーションを作成します。
```
source=> CREATE PUBLICATION testpub FOR TABLE testtab;
CREATE PUBLICATION
```
+ SELECT クエリを使用して、作成したパブリケーションの詳細を確認します。
```
source=> SELECT * FROM pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
--------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
115069 | testpub | 16395 | f | t | t | t | t | f
(1 row)
```
+ ソーステーブルがパブリケーションに追加されていることを確認します。
```
source=> SELECT * FROM pg_publication_tables;
pubname | schemaname | tablename
---------+------------+-----------
testpub | public | testtab
(1 rows)
```
+ データベース内のすべてのテーブルをレプリケートするには、以下を使用します。
```
CREATE PUBLICATION testpub FOR ALL TABLES;
```
+ パブリケーションが個々のテーブル用に既に作成されており、新しいテーブルを追加する必要がある場合は、以下のクエリを実行して、既存のパブリケーションに新しいテーブルを追加できます。
```
ALTER PUBLICATION add table ;
```
1.
**ターゲットデータベースに接続し、ターゲットテーブルを作成する**
+ ターゲット DB インスタンスのターゲットデータベースに接続します。ソーステーブルと同じ名前でターゲットテーブルを作成します。
```
target=> CREATE TABLE testtab (slno int primary key);
CREATE TABLE
```
+ ターゲットテーブルに対して SELECT クエリを実行し、ターゲットテーブルにデータが存在しないことを確認します。
```
target=> SELECT count(*) FROM testtab;
count
-------
0
(1 row)
```
1.
**ターゲットデータベースでサブスクリプションを作成および検証する**
+ ターゲットデータベースにサブスクリプションを作成します。
```
target=> CREATE SUBSCRIPTION testsub
CONNECTION 'host= port=5432 dbname= user= password='
PUBLICATION testpub;
NOTICE: Created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
+ SELECT クエリを使用して、サブスクリプションが有効になっていることを確認します。
```
target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16434 | testsub | t | testsub | {testpub}
(1 row)
```
+ サブスクリプションが作成されると、ソーステーブルからターゲットテーブルにすべてのデータがロードされます。ターゲットテーブルに対して SELECT クエリを実行し、初期データがロードされていることを確認します。
```
target=> SELECT count(*) FROM testtab;
count
-------
1000
(1 row)
```
1.
**ソースデータベースのレプリケーションスロットを確認する**
ターゲットデータベースにサブスクリプションを作成すると、ソースデータベースにレプリケーションスロットが作成されます。ソースデータベースに対して次の SELECT クエリを実行して、レプリケーションスロットの詳細を確認します。
```
source=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size
----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------
testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved |
(1 row)
```
1.
**レプリケーションのテスト**
+ ソーステーブルに行を挿入して、ソーステーブルのデータ変更がターゲットテーブルにレプリケートされているかどうかをテストします。
```
source=> INSERT INTO testtab VALUES(generate_series(1001,2000));
INSERT 0 1000
source=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
+ ターゲットテーブル内の行数を確認して、新しい挿入がレプリケートされていることを確認します。
```
target=> SELECT count(*) FROM testtab;
count
-------
2000
(1 row)
```
1.
**テーブルを追加した後のサブスクリプションの更新**
+ 既存のパブリケーションに新しいテーブルを追加する場合、変更を有効にするにはサブスクリプションを更新する必要があります。
```
ALTER SUBSCRIPTION REFRESH PUBLICATION;
```
+ このコマンドは、パブリッシャーから欠落しているテーブル情報を取得し、サブスクリプションの作成または最終更新以降にサブスクライブ先のパブリケーションに追加されたテーブルのレプリケーションを開始します。
# 論理レプリケーション接続の IAM 認証の設定
RDS for PostgreSQL バージョン 11 以降では、レプリケーション接続に AWS Identity and Access Management (IAM) 認証を使用できます。この機能は、パスワードの代わりに IAM ロールを使用してデータベースアクセスを管理できるようにすることで、セキュリティを強化します。クラスターとインスタンスの両方の粒度で動作し、標準の IAM 認証と同じセキュリティモデルに従います。
レプリケーション接続の IAM 認証はオプトイン機能です。有効にするには、DB クラスターまたは DB パラメータグループの `rds.iam_auth_for_replication` パラメータを 1 に設定します。これは動的パラメータであるため、DB クラスターまたはインスタンスを再起動する必要がなく、ダウンタイムなしで既存のワークロードで IAM 認証を活用できます。この機能を有効にする前に、以下の前提条件を満たす必要があります。
**Topics**
+ [
## 前提条件
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites)
+ [
## レプリケーション接続の IAM 認証の有効化
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling)
+ [
## レプリケーション接続の IAM 認証の無効化
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling)
+ [
## 制約事項と考慮事項
](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations)
## 前提条件
レプリケーション接続に IAM 認証を使用するには、以下のすべての要件を満たす必要があります。
+ RDS for PostgreSQL DB インスタンスはバージョン 11 以降である必要があります。
+ パブリッシャー RDS for PostgreSQL DB インスタンスの場合:
+ IAM データベース認証を有効にする。詳細については、「[IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)」を参照してください。
+ `rds.logical_replication` パラメータを 1 に設定して、論理レプリケーションを有効にします。
論理レプリケーションでは、パブリッシャーはサブスクライバーデータベースにデータを送信するソース RDS for PostgreSQL データベースです。詳細については、「[Amazon RDS for PostgreSQL の論理レプリケーションの実行](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)」を参照してください。
**注記**
パブリッシャー RDS for PostgreSQL DB インスタンスで IAM 認証と論理レプリケーションの両方を有効にする必要があります。どちらかが有効になっていない場合、レプリケーション接続に IAM 認証を使用することはできません。
## レプリケーション接続の IAM 認証の有効化
レプリケーション接続の IAM 認証を有効にするには、次の手順を実行します。
**レプリケーション接続の IAM 認証を有効にするには**
1. RDS for PostgreSQL DB クラスターまたはインスタンスが、レプリケーション接続による IAM 認証のすべての前提条件を満たしていることを確認します。詳細については、「[前提条件](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites)」を参照してください。
1. RDS for PostgreSQL の設定に基づいて `rds.iam_auth_for_replication` パラメータを設定します。
+ RDS for PostgreSQL DB インスタンスの場合: DB パラメータグループを変更します。
+ マルチ AZ クラスターの場合: DB クラスターパラメータグループを変更します。
`rds.iam_auth_for_replication` を 1 に設定します。これは、再起動を必要とせずにすぐに有効になる動的パラメータです。
**注記**
マルチ AZ クラスターは、DB クラスターパラメータグループのみを使用します。マルチ AZ クラスターでは、個々のインスタンスパラメータグループを変更することはできません。
1. データベースに接続し、必要なロールをレプリケーションユーザーに付与します。
次の SQL コマンドは、レプリケーション接続の IAM 認証を有効にするために必要なロールを付与します。
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
これらのステップを完了した後、指定されたユーザーはレプリケーション接続に IAM 認証を使用する必要があります。
**重要**
この機能を有効にすると、`rds_iam` ロールと `rds_replication` ロールの両方を持つユーザーは、レプリケーション接続に IAM 認証を使用する必要があります。これは、ロールがユーザーに直接割り当てられているか、他のロールを通じて継承されているかにかかわらず適用されます。
## レプリケーション接続の IAM 認証の無効化
レプリケーション接続の IAM 認証を無効にするには、次のいずれかの方法を使用します。
+ DB インスタンスの DB パラメータグループまたはマルチ AZ クラスターの DB クラスターパラメータグループで、`rds.iam_auth_for_replication` パラメータを 0 に設定します。
+ または、RDS for PostgreSQL DB クラスターまたはインスタンスで次のいずれかの機能を無効にすることもできます。
+ `rds.logical_replication` パラメータを 0 に設定して論理レプリケーションを無効にする
+ IAM 認証の無効化
この機能を無効にすると、レプリケーション接続では認証にデータベースパスワードを使用できるようになります。
**注記**
`rds_iam` ロールを持たないユーザーのレプリケーション接続は、この機能が有効になっている場合でもパスワード認証を使用できます。
## 制約事項と考慮事項
論理レプリケーション接続に IAM 認証を使用する場合、以下の制限と考慮事項を考慮してください。
+ この機能は、RDS for PostgreSQL バージョン 11 以降でのみ使用できます。
+ パブリッシャーは、レプリケーション接続の IAM 認証をサポートする必要があります。
+ IAM 認証トークンは、デフォルトで 15 分後に期限切れになります。トークンの有効期限が切れる前に、長時間実行されるレプリケーション接続を更新する必要がある場合があります。
# stats\$1temp\$1directory の RAM ディスク
RDS for PostgreSQL パラメータ `rds.pg_stat_ramdisk_size` を使用して、PostgreSQL `stats_temp_directory` を保存する RAM ディスクに割り当てられたシステムメモリを指定できます。RAM ディスクパラメータは、RDS for PostgreSQL バージョン 14 以下のバージョンでのみ利用できます。
特定のワークロードでは、このパラメータを設定することでパフォーマンスが向上し、I/O 要件を軽減することができます。`stats_temp_directory` の詳細については、[PostgreSQL のドキュメント](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY)を参照してください。
`stats_temp_directory` の RAM ディスクをセットアップにするには、`rds.pg_stat_ramdisk_size` パラメータを、DB インスタンスで使用されるパラメータグループの整数リテラル値に設定します。このパラメータは MB を表すため、整数値を使用する必要があります。表現、数式、関数が `rds.pg_stat_ramdisk_size` パラメータに対して有効ではありません。変更が反映されるように、DB インスタンスを再起動してください。パラメータの設定の詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
例えば、次の AWS CLI コマンドは、RAM ディスクパラメータを 256 MB に設定します。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name pg-95-ramdisk-testing \
--parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"
```
再起動後は、次のコマンドを実行して `stats_temp_directory` のステータスを確認します。
```
postgres=> SHOW stats_temp_directory;
```
コマンドは次の情報を返します。
```
stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)
```
# RDS for PostgreSQL のテーブルスペース
RDS for PostgreSQL では、互換性のためにテーブルスペースがサポートされています。すべてのストレージが 1 つの論理ボリューム上にあるため、I/O 分割または分離にテーブルスペースを使用することはできません。当社のベンチマークと経験は、ほとんどのユースケースで 単一の論理的なボリュームが最適なセットアップであることを示しています。
RDS for PostgreSQL DB インスタンスでテーブルスペースを作成して使用するには、`rds_superuser` ロール が必要です。RDS for PostgreSQL DB インスタンスのメインユーザーアカウント (デフォルトの名前は `postgres`) は、このロールのメンバーです。詳細については、「[PostgreSQL のロールとアクセス権限について](Appendix.PostgreSQL.CommonDBATasks.Roles.md)」を参照してください。
表空間の作成時にファイル名を指定する場合、パスの接頭辞は `/rdsdbdata/db/base/tablespace` になります。次の例では、`/rdsdbdata/db/base/tablespace/data`に表空間ファイルを配置しています。この例では、`dbadmin` ユーザー (ロール) が存在し、テーブルスペースの操作に必要な `rds_superuser` ロールが付与されていることを前提としています。
```
postgres=> CREATE TABLESPACE act_data
OWNER dbadmin
LOCATION '/data';
CREATE TABLESPACE
```
PostgreSQL テーブルスペースの詳細については、PostgreSQL のドキュメントの「[Tablespaces](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html)」(テーブル空間) を参照してください。
# EBCDIC やその他のメインフレーム移行のための RDS for PostgreSQL 照合順序
RDS for PostgreSQL バージョン 10 以降には ICU バージョン 60.2 が含まれています。これは Unicode 10.0 に基づいており、Unicode Common Locale Data Repositor、CLDR 32 からの照合順序が含まれています。これらのソフトウェア国際化ライブラリにより、オペレーティングシステムやプラットフォームに関係なく、文字エンコーディングが一貫した方法で表示されます。Unicode CLDR-32 の詳細については、Unicode CLDR のウェブサイトの「[CLDR 32 リリースノート](https://cldr.unicode.org/index/downloads/cldr-32)」を参照してください。Unicode の国際化コンポーネント (ICU) については、[ICU 技術委員会 (ICU-TC)](https://icu.unicode.org/home) のウェブサイトで詳しく説明されています。ICU-60 の詳細については、「[ICU 60 のダウンロード](https://icu.unicode.org/download/60)」を参照してください。
バージョン 14.3 以降、RDS for PostgreSQL には、EBCDIC ベースのシステムからのデータ統合と変換に役立つ照合順序も含まれています。Extended Binary Coded Decimal Interchange Code (*EBCDIC*) エンコーディングはメインフレームのオペレーティングシステムで一般的に使用されます。マッピングAmazon RDS が提供するこれらの照合順序は、EBCDIC コードページに直接マッピングされる Unicode 文字のみをソートするように狭義に定義されています。文字は、変換後のデータ検証を可能にするために、EBCDIC コードポイント順にソートされます。これらの照合順序には、非正規化された形式や、ソース EBCDIC コードページの文字に直接マッピングされない Unicode 文字は含まれていません。
EBCDIC コードページと Unicode コードポイント間の文字マッピングは、IBM が公開している表に基づいています。一式は、IBM から[圧縮ファイル](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip)としてダウンロード可能です。RDS for PostgreSQL は、ICU から提供されたツールでこれらのマッピングを使用して、このセクションの表にリストされている照合順序を作成しました。照合順序名には、ICU が要求する言語と国が含まれます。ただし、EBCDIC コードページでは言語が指定されておらず、一部の EBCDIC コードページは複数の国を対象としています。つまり、テーブル内の照合名の言語と国の部分は任意であり、現在のロケールと一致する必要はありません。つまり、コードページ番号はこの表の照合順序名の最も重要な部分です。次の表に示す照合順序は、どの RDS for PostgreSQL データベースでも使用できます。
+ [Unicode to EBCDIC collations table](#ebcdic-table) — メインフレームのデータ移行ツールの中には、LATIN1 または LATIN9 を内部的に使用してデータのエンコードと処理を行うものがあります。こういったツールは、ラウンドトリップスキームを使用してデータの整合性を維持し、逆変換をサポートします。この表の照合順序は、特別な処理を必要としない LATIN1 エンコーディングを使用してデータを処理するツールで使用できます。
+ [Unicode to LATIN9 collations table](#latin9-table) — これらの照合順序は、どの RDS for PostgreSQL データベースでも使用できます。
次の表に、EBCDIC コードページを Unicode コードポイントにマッピングする RDS for PostgreSQL の照合順序を示します。IBM コードページの順序に基づいてソートする必要があるアプリケーション開発には、この表の照合順序を使用することをお勧めします。
| PostgreSQL 照合順序名 | コードページのマッピングとソート順序の説明 |
| --- | --- |
| da-DK-cp277-x-icu | IBM EBCDIC コードページ 277 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 277 コードポイント順にソートされます。 |
| de-DE-cp273-x-icu | IBM EBCDIC コードページ 273 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 273 コードポイント順にソートされます。 |
| en-GB-cp285-x-icu | IBM EBCDIC コードページ 285 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 285 コードポイント順にソートされます。 |
| en-US-cp037-x-icu | IBM EBCDIC コードページ 037 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 037 コードポイント順にソートされます。 |
| es-ES-cp284-x-icu | IBM EBCDIC コードページ 284 (変換表ごと) に直接マッピングされる Unicode 文字は、IBM CP 284 コードポイント順にソートされます。 |
| fi-FI-cp278-x-icu | IBM EBCDIC コードページ 278 (変換表ごと) に直接マップされる Unicode 文字は、IBM CP 278 コードポイント順にソートされます。 |
| fr-fr-cp297-X-ICU | IBM EBCDIC コードページ 297 (変換表ごと) に直接マップされる Unicode 文字は、IBM CP 297 コードポイント順にソートされます |
| it-IT-cp280-x-icu | IBM EBCDIC コードページ 280 (変換表ごと) に直接マップされる Unicode 文字は、IBM CP 280 コードポイント順にソートされます |
| nl-BE-cp500-x-icu | IBM EBCDIC コードページ 500 (変換テーブルごと) に直接マップされる Unicode 文字は、IBM CP 500 コードポイント順にソートされます |
Amazon RDS には、IBM が公開しているテーブルを使用して、LATIN9 文字にマッピングされる Unicode コードポイントをソースデータの EBCDIC コードページに従って元のコードポイントの順序でソートする追加の照合セットが用意されています。
| PostgreSQL 照合順序名 | コードページのマッピングとソート順序の説明 |
| --- | --- |
| da-DK-cp1142m-x-icu | IBM EBCDIC コードページ 1142 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1142 コードポイント順にソートされます。 |
| de-DE-cp1141m-x-icu | IBM EBCDIC コードページ 1141 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1141 コードポイント順にソートされます。 |
| en-GB-cp1146m-x-icu | IBM EBCDIC コードページ 1146 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1146 コードポイント順にソートされます。 |
| en-US-cp1140m-x-icu | IBM EBCDIC コードページ 1140 (変換テーブルごと) から最初に変換された LATIN9 文字にマップされる Unicode 文字は、IBM CP 1140 コードポイント順にソートされます。 |
| es-ES-cp1145m-x-icu | IBM EBCDIC コードページ 1145 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1145 コードポイント順にソートされます。 |
| fi-FI-cp1143m-x-icu | IBM EBCDIC コードページ 1143 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1143 コードポイント順にソートされます。 |
| fr-FR-cp1147m-x-icu | IBM EBCDIC コードページ 1147 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1147 コードポイント順にソートされます。 |
| it-IT-cp1144m-x-icu | IBM EBCDIC コードページ 1144 (変換テーブルごと) から最初に変換された LATIN9 文字にマッピングされる Unicode 文字は、IBM CP 1144 コードポイント順にソートされます。 |
| nl-BE-cp1148m-x-icu | IBM EBCDIC コードページ 1148 (変換テーブルごと) から最初に変換された LATIN9 文字にマップされる Unicode 文字は、IBM CP 1148 コードポイント順にソートされます。 |
以下に、RDS for PostgreSQL 照合順序の使用例を示します。
```
db1=> SELECT pg_import_system_collations('pg_catalog');
pg_import_system_collations
-----------------------------
36
db1=> SELECT '¤' < 'a' col1;
col1
------
t
db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;
col1
------
f
```
IBM コードページの順序に基づいてソートする必要があるアプリケーション開発には、[Unicode to EBCDIC collations table](#ebcdic-table) と [Unicode to LATIN9 collations table](#latin9-table) の照合順序を使用することをお勧めします。次の照合順序 (接尾辞に「b」の文字が付いている) は、`pg_collation` でも表示されますが、特定のコードポイントシフトを持つコードページをマッピングする AWS のメインフレームデータ統合および移行ツールで使用することを目的としており、照合順序で特別な処理が必要です。つまり、以下の照合順序の使用は推奨されません。
+ da-DK-277b-x-icu
+ da-DK-1142b-x-icu
+ de-DE-cp273b-x-icu
+ de-DE-cp1141b-x-icu
+ en-GB-cp1146b-x-icu
+ en-GB-cp285b-x-icu
+ en-US-cp037b-x-icu
+ en-US-cp1140b-x-icu
+ es-ES-cp1145b-x-icu
+ es-ES-cp284b-x-icu
+ fi-FI-cp1143b-x-icu
+ fr-FR-cp1147b-x-icu
+ fr-FR-cp297b-x-icu
+ it-IT-cp1144b-x-icu
+ it-IT-cp280b-x-icu
+ nl-BE-cp1148b-x-icu
+ nl-BE-cp500b-x-icu
メインフレーム環境から AWS へのアプリケーションの移行に関する詳細については、[「AWSMainframe Modernization とは?」](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html)を参照してください。
PostgreSQL における照合順序の管理の詳細については、PostgreSQL のドキュメントの「[Collation Support](https://www.postgresql.org/docs/current/collation.html)」(照合順序のサポート) を参照してください。
# RDS for PostgreSQL の論理スロット同期の管理
コミュニティ PostgreSQL 17 以降、プライマリサーバーからスタンバイサーバーに論理レプリケーションスロットを自動的に同期する新機能が、パラメータ `sync_replication_slots` や関連する関数 `pg_sync_replication_slots()` を通じて導入されました。これは、実行時にスロットを手動で同期します。
これらの機能は、RDS for PostgreSQL 17 以降で使用できます。一般的なセットアップには、プライマリインスタンスとその[リードレプリカ](USER_PostgreSQL.Replication.ReadReplicas.md)と、プライマリへの論理レプリケーションサブスクライバーがあります。
サブスクリプションがフェイルオーバーオプションを true に設定して作成されていることを確認します。
```
CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true);
```
これにより、フェイルオーバーを有効にした状態でパブリッシャーに論理スロットが作成されます。
```
postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots;
slot_name | slot_type | failover
-----------+-----------+----------
subname | logical | t
(1 row)
```
スロット同期を有効にすると、プライマリのすべてのフェイルオーバー論理レプリケーションスロットが物理スタンバイに自動的に作成され、定期的に同期されます。[パラメータグループ](USER_WorkingWithParamGroups.Associating.md)を通じて次の値が設定されていることを確認します。
+ 論理レプリケーションを有効にするには `rds.logical_replication` が `1` である必要があります。
+ `hot_standby_feedback` はスタンバイ時に `1` である必要があります。
+ スタンバイの `rds.logical_slot_sync_dbname` には有効なデータベース名を設定する必要があります。
パラメータのデフォルト値は `postgres` です。論理パブリッシングインスタンスに `postgres` データベースがある場合、デフォルトのパラメータを変更する必要はありません。
+ プライマリの `synchronized_standby_slots` は、同期するスタンバイの物理レプリケーションスロットに設定する必要があります。
+ 自動同期を有効にするには `sync_replication_slots` が `1` である必要があります。
フェイルオーバー対応のサブスクリプションスロットと上記のパラメータ値を使用すると、スタンバイが昇格したとき、サブスクライバーはサブスクリプションをこの新しく昇格されたインスタンスに変更し、論理レプリケーションをシームレスに続行できます。
# PostgreSQL データベースエンジンを実行する DB インスタンスへの接続
Amazon RDS によって DB インスタンスがプロビジョニングされると、スタンダードの SQL クライアントアプリケーションを使用してインスタンスに接続できます。接続する前に、DB インスタンスが使用可能でアクセス可能である必要があります。VPC の外部からインスタンスに接続できるかどうかは、Amazon RDS DB インスタンスの作成方法によって異なります。
+ DB インスタンスを*公開*で作成した場合、VPC 外部のデバイスと Amazon EC2 インスタンスからデータベースに接続できます。
+ DB インスタンスを*プライベート*で作成した場合、Amazon VPC 内の Amazon EC2 インスタンスとデバイスのみがデータベースに接続できます。
DB インスタンスがパブリックかプライベートかを確認するには、AWS マネジメントコンソール を使用してインスタンスの **[Connectivity & security]** (接続とセキュリティ) タブを確認します。**[Security]** (セキュリティ) では、「パブリックアクセス可能」の値を見つけることができます。プライベートの場合は [No] (いいえ)、パブリックの場合は [Yes] (はい) です。
Amazon RDS および Amazon VPC のさまざまな設定、およびそれらがアクセシビリティに与える影響の詳細については、「[VPC の DB インスタンスにアクセスするシナリオ](USER_VPC.Scenarios.md)」を参照してください。
**Contents**
+ [
## psql クライアントをインストールする
](#install-psql)
+ [
## RDS for PostgreSQL DB インスタンスの接続情報の検索
](#postgresql-endpoint)
+ [
# pgAdmin を使用して RDS PostgreSQL DB インスタンスに接続する
](USER_ConnectToPostgreSQLInstance.pgAdmin.md)
+ [
# psql を使用したRDS for PostgreSQL DB インスタンスへの接続
](USER_ConnectToPostgreSQLInstance.psql.md)
+ [
# Amazon Web Services (AWS) JDBC ドライバーを使用した RDS for PostgreSQL への接続
](PostgreSQL.Connecting.JDBCDriver.md)
+ [
# Amazon Web Services (AWS) Python ドライバーを使用した RDS for PostgreSQL への接続
](PostgreSQL.Connecting.PythonDriver.md)
+ [
# RDS for PostgreSQL インスタンスへの接続に関するトラブルシューティング
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md)
+ [
## – 致命的エラー: データベース*名*が存在しません。
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [
## - サーバー接続失敗エラー: 接続がタイムアウトしました。
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [
## セキュリティグループのアクセスルールのエラー
](USER_ConnectToPostgreSQLInstance.Troubleshooting.md#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## psql クライアントをインストールする
EC2 インスタンスから DB インスタンスに接続するには、EC2 インスタンスに PostgreSQL クライアントをインストールします。最新バージョンの psql クライアントを Amazon Linux 2023 にインストールするには、次のコマンドを実行します。
```
sudo dnf install postgresql
```
最新バージョンの psql クライアントを Amazon Linux 2 にインストールするには、次のコマンドを実行します。
```
sudo yum install -y postgresql
```
最新バージョンの psql クライアントを Ubuntu にインストールするには、次のコマンドを実行します。
```
sudo apt install -y postgresql-client
```
## RDS for PostgreSQL DB インスタンスの接続情報の検索
DB インスタンスが利用可能でアクセス可能な場合は、SQL クライアントアプリケーションに次の情報を提供することによって接続できます。
+ DB インスタンスのエンドポイントで、インスタンスのホスト名 (DNS 名)として機能します。
+ DB インスタンスがリッスンするポート。PostgreSQL のデフォルトポートは 5432 です。
+ DB インスタンスのユーザーネームとパスワード。PostgreSQL のデフォルトの「マスターユーザーネーム」は`postgres`です。
+ データベースの名前とパスワード (DB 名)です。
これらの詳細は、AWS マネジメントコンソール、AWS CLI[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)コマンド、またはAmazon RDS API [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html)オペレーションを使用して取得できます。
**エンドポイント、ポート番号、および DB 名を検索するにはAWS マネジメントコンソールを使用します。**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. RDS コンソールを開き、[**データベース**] を選択して、DB インスタンスを一覧表示します。
1. PstgreSQL DB インスタンス名を選択して、詳細を表示します。
1. **接続とセキュリティ** タブで、エンドポイントをコピーします。また、ポート番号を書き留めます。DB インスタンスに接続するには、エンドポイントとポート番号の両方が必要です。
![\[RDS コンソールからエンドポイントを取得する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/PostgreSQL-endpoint.png)
1. **設定**タブで、DB 名をメモします。RDS for PostgreSQL インスタンスの作成時にデータベースを作成した場合は、DB 名に名前が表示されます。データベースを作成しなかった場合、DB 名にダッシュ (‐) が表示されます。
![\[RDS コンソールから DB 名を取得する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/PostgreSQL-db-name.png)
以下に、PostgreSQL DB インスタンスに接続する 2 つの方法を示します。初期の例では、オープンソースの PostgreSQL 向け管理開発ツールとして人気のある pgAdmin を使用します。2 番目の例では、PostgreSQL に付属するコマンドラインユーティリティである psql を使用します。
# pgAdmin を使用して RDS PostgreSQL DB インスタンスに接続する
オープンソースのツール pgAdmin を使用して、RDS for PostgreSQL DB インスタンスに接続できます。クライアントコンピュータに PostgreSQL のローカルインスタンスがなくても、pgAdmin を[http://www.pgadmin.org/](http://www.pgadmin.org/) からダウンロードして使用できます。
**pgAdmin を使用して、 RDS for PostgreSQL DB インスタンスに接続するには**
1. クライアントコンピュータの pgAdmin アプリケーションを起動します。
1. **[Dashboard]** (ダッシュボード) タブで、**[Add New Server]** (新しいサーバーの追加) を選択します。
1. **[Create - Server]** (作成 - サーバー) ダイアログボックスの **[General]** (全般) タブで名前を入力して、pgAdmin のサーバーを特定します。
1. **[Connection]** (接続) タブで、DB インスタンスから以下の情報を入力します。
+ **[ホスト]** に、エンドポイントを入力します (例: `mypostgresql.c6c8dntfzzhgv0.us-east-2.rds.amazonaws.com`)。
+ **[Port]** (ポート) には、割り当てられているポートを入力します。
+ **ユーザーネーム**では、DB インスタンスの作成時に入力したユーザーネームを入力します (「マスターユーザーネーム」をデフォルトから変更した場合、`postgres`)。
+ **パスワード** に、DB インスタンスの作成時に入力したパスワードを入力します。
![\[DB インスタンスの作成時に入力したパスワードを入力します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/Postgres-Connect01.png)
1. **[保存]** を選択します。
接続に問題がある場合は、[RDS for PostgreSQL インスタンスへの接続に関するトラブルシューティング](USER_ConnectToPostgreSQLInstance.Troubleshooting.md) を参照してください。
1. pgAdmin ブラウザでデータベースにアクセスするには、[**Servers**] (サーバー)、DB インスタンス、および **[Databases]** (データベース) を展開します。DB インスタンスのデータベース名を選択します。
![\[pgAdmin ブラウザで DB インスタンスのデータベース名を選択します\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/Postgres-Connect02.png)
1. SQL コマンドを入力できるパネルを開くには、**[Tools]** (ツール)、**[Query Tool]** (クエリツール) の順に選択します。
# psql を使用したRDS for PostgreSQL DB インスタンスへの接続
psql コマンドラインユーティリティのローカルインスタンスを使用して、RDS for PostgreSQL DB インスタンスに接続できます。PostgreSQL またはクライアントコンピュータにインストールされた psql クライアントのいずれかが必要です。
PostgreSQL クライアントは、[PostgreSQL](https://www.postgresql.org/download/) のウェブサイトからダウンロードできます。オペレーティングシステムのバージョンに対応した手順に従い、psql をインストールします。
psql を使用して RDS for PostgreSQL DB インスタンスに接続するには、ホスト (DNS) 情報とアクセス認証情報、データベース名を指定する必要があります。
RDS for PostgreSQL DB インスタンスに接続するには、以下の形式のいずれかを使用します。接続時にパスワードを求められます。バッチジョブまたはスクリプトには、`--no-password` オプションを使用します。このオプションは、セッション全体に対して設定されます。
**注記**
サーバーがパスワード認証を要求し、他の出典からパスワードを取得できない場合、`--no-password` との接続試行に失敗します。詳細については、[psql ドキュメント](https://www.postgresql.org/docs/13/app-psql.html)を参照してください。
この DB インスタンスに初めて接続する場合、またはこの RDS for PostgreSQL インスタンスのデータベースをまだ作成していない場合、「マスターユーザーネーム」とパスワードを使用して**Postgres**のデータベースに接続できます。
Unix の場合、次の形式を使用します。
```
psql \
--host= \
--port= \
--username= \
--password \
--dbname=
```
Windows の場合、次の形式を使用します。
```
psql ^
--host= ^
--port= ^
--username= ^
--password ^
--dbname=
```
例えば、次のコマンドは、架空の認証情報を使用して、`mypgdb` という PostgreSQL DB インスタンス上の `mypostgresql` というデータベースに接続します。
```
psql --host=mypostgresql.c6c8mwvfdgv0.us-west-2.rds.amazonaws.com --port=5432 --username=awsuser --password --dbname=mypgdb
```
# Amazon Web Services (AWS) JDBC ドライバーを使用した RDS for PostgreSQL への接続
Amazon Web Services (AWS) JDBC ドライバーは、高度な JDBC ラッパーとして設計されています。このラッパーは、既存の JDBC ドライバーの機能を補完し、拡張します。ドライバーには、コミュニティ pgJDBC ドライバーとドロップイン互換性があります。
AWS JDBC ドライバーをインストールするには、AWS JDBC ドライバーの .jar ファイル (`CLASSPATH` アプリケーション内) を追加して、それぞれのコミュニティドライバーへの参照を保持します。対応する接続 URL プレフィックスを次のように更新します。
+ `jdbc:postgresql://`～`jdbc:aws-wrapper:postgresql://`
AWS JDBC ドライバーおよびその使用方法の詳細については、「[Amazon Web Services (AWS) JDBC ドライバー GitHub リポジトリ](https://github.com/awslabs/aws-advanced-jdbc-wrapper)」を参照してください。
# Amazon Web Services (AWS) Python ドライバーを使用した RDS for PostgreSQL への接続
Amazon Web Services (AWS) Python ドライバーは、高度な Python ラッパーとして設計されています。このラッパーは、オープンソースの Psycopg ドライバーの機能を補完し、拡張します。AWS Python ドライバーは Python バージョン 3.8 以降をサポートしています。`aws-advanced-python-wrapper` パッケージは、`pip` コマンドと `psycopg` オープンソースパッケージを使用してインストールできます。
AWS Python ドライバーおよびその使用方法の詳細については、「[Amazon Web Services (AWS) Python Driver GitHub repository](https://github.com/awslabs/aws-advanced-python-wrapper)」を参照してください。
# RDS for PostgreSQL インスタンスへの接続に関するトラブルシューティング
**Topics**
+ [
## – 致命的エラー: データベース*名*が存在しません。
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-DBname)
+ [
## - サーバー接続失敗エラー: 接続がタイムアウトしました。
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-timeout)
+ [
## セキュリティグループのアクセスルールのエラー
](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)
## – 致命的エラー: データベース*名*が存在しません。
接続時に`FATAL: database name does not exist`のようなエラーが発生する場合、デフォルトのデータベース名 **postgres** を `--dbname` オプションに使用してみてください。
## - サーバー接続失敗エラー: 接続がタイムアウトしました。
DB インスタンスに接続できない場合、最も一般的なエラーは `Could not connect to server: Connection timed out.` です。このエラーを受け取った場合、以下を確認します。
+ 使用しているホスト名が DB インスタンスのエンドポイントであること、および使用しているポート番号が正しいことを確認します。
+ DB インスタンスのパブリックアクセシビリティが**はい**に設定され、外部接続が許可されていることを確認します。**パブリックアクセス**設定を変更するには 、[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md) を参照してください。
+ データベースに接続するユーザーに CONNECT アクセス権があることを確認してください。次のクエリを使用して、データベースへの接続アクセスを提供できます。
```
GRANT CONNECT ON DATABASE database name TO username;
```
+ 接続で経由する可能性のあるファイアウォールを通過するアクセス許可のルールが、DB インスタンスに割り当てられたセキュリティグループに設定されていることを確認します。例えば、DB インスタンスをデフォルトポート 5432 で作成した場合、会社のファイアウォールルールにより、外部企業デバイスから当該ポートへの接続がブロックされる可能性があります。
この問題を解決するには、別のポートを使用するよう DB インスタンスを変更します。また、DB インスタンスに適用されているセキュリティグループが、その新しいポートへの接続を許可していることも確認します。**データベースポート**の設定を変更するには 、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください 。
+ 使用しようとしているポートが PostgreSQL のローカルインスタンスまたはコンピュータで実行している別のサービスによって既に占有されているかどうかを確認します。例えば、同じポート (デフォルトは 5432) でローカル PostgreSQL データベースを実行している場合、RDS for PostgreSQL DB インスタンスに正常に接続できない場合があります。ポートが空いていることを確認するか、可能であれば別のポート番号で接続してみてください。
+ 「[セキュリティグループのアクセスルールのエラー](#USER_ConnectToPostgreSQLInstance.Troubleshooting-AccessRules)」も参照してください。
## セキュリティグループのアクセスルールのエラー
最も一般的な接続の問題は、DB インスタンスに割り当てられているセキュリティグループのアクセスルールに関係するものです。DB インスタンスの作成時にデフォルトのセキュリティグループを使用した場合、恐らくそのセキュリティグループにはインスタンスへのアクセスを許可するルールはありません。
接続が機能するには、作成時に DB インスタンスに割り当てたセキュリティグループが DB インスタンスへのアクセスを許可する必要があります。例えば、DB インスタンスが VPC で作成された場合、接続を承認する VPC セキュリティグループが必要です。アプリケーションが実行中のデバイスまたはAmazon EC2 インスタンスからの接続を承認しないセキュリティグループを使用して、 DB インスタンスを作成したかどうかを確認します。
セキュリティグループでインバウンドのルールを追加または編集できます。**出典** に対して **マイ IP** を選択すると、ブラウザで検出された IP アドレスから DB インスタンスにアクセスできます。詳細については、「[セキュリティグループを作成して VPC 内の DB インスタンスへのアクセスを提供する](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup)」を参照してください。
または、DB インスタンスが VPC の外部で作成された場合は、それらの接続を承認するデータベースセキュリティグループが必要です。
Amazon RDS セキュリティグループの詳細については、「[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md)」を参照してください。
# SSL/TLS を使用して RDS for PostgreSQL への接続を保護する
RDS for PostgreSQL では、PostgreSQL DB インスタンスの Secure Socket Layer (SSL) 暗号化がサポートされています。SSL を使用して、アプリケーションと PostgreSQL DB インスタンスとの PostgreSQL 接続を暗号化できます。また、PostgreSQL DB インスタンスへのすべての接続に SSL の使用を強制することができます。RDS for PostgreSQL では、SSL の後継プロトコルである Transport Layer Security (TLS) もサポートされています。
Amazon RDS およびデータ保護 (SSL/TLS を使用した接続の暗号化を含む) の詳細については、「[Amazon RDS でのデータ保護](DataDurability.md)」を参照してください。
**Topics**
+ [
# PostgreSQL DB インスタンスで SSL を使用する
](PostgreSQL.Concepts.General.SSL.md)
+ [
# 新しい SSL/TLS 証明書を使用して PostgreSQL DB インスタンスに接続するようにアプリケーションを更新する
](ssl-certificate-rotation-postgresql.md)
# PostgreSQL DB インスタンスで SSL を使用する
Amazon RDS は、PostgreSQL DB インスタンスの Secure Socket Layer (SSL) 暗号化をサポートします。SSL を使用して、アプリケーションと PostgreSQL DB インスタンスとの PostgreSQL 接続を暗号化できます。デフォルトでは、RDS for PostgreSQL は SSL/TLS を使用し、すべてのクライアントが SSL/TLS を使用して接続することを想定していますが、必須にすることもできます。RDS for PostgreSQL は、Transport Layer Security (TLS) バージョン 1.1、1.2、および 1.3 をサポートしています。
SSL サポートおよび PostgreSQL データベースの一般情報については、PostgreSQL ドキュメントの「[SSL Support](https://www.postgresql.org/docs/11/libpq-ssl.html)」を参照してください。JDBC を介した SSL 接続の使用については、PostgreSQL ドキュメントの「[Configuring the Client](https://jdbc.postgresql.org/documentation/head/ssl-client.html)」を参照してください。
PostgreSQL 用の SSL は、すべての AWS リージョンで利用が可能です。インスタンスの作成時に、PostgreSQL DB インスタンス用の SSL 証明書が、Amazon RDS により作成されます。SSL 証明書認証を有効にした場合、SSL 証明書には、なりすまし攻撃から保護するために、SSL 証明書の共通名 (CN) として DB インスタンスのエンドポイントが含まれます。
**Topics**
+ [
## SSL 経由での PostgreSQL DB インスタンスへの接続
](#PostgreSQL.Concepts.General.SSL.Connecting)
+ [
## PostgreSQL DB インスタンスへの SSL 接続を必須にする
](#PostgreSQL.Concepts.General.SSL.Requiring)
+ [
## SSL 接続ステータスを確認する
](#PostgreSQL.Concepts.General.SSL.Status)
+ [
## RDS for PostgreSQL の SSL 暗号スイート
](#PostgreSQL.Concepts.General.SSL.Ciphers)
## SSL 経由での PostgreSQL DB インスタンスへの接続
**SSL を使用して PostgreSQL DB インスタンスに接続するには**
1. 証明書をダウンロードします。
証明書のダウンロードについては、[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。
1. SSL 経由の PostgreSQL DB インスタンスへの接続
SSL を使用して接続するとき、クライアントでは証明書チェーンを検証するかどうかを選択できます。接続パラメータで `sslmode=verify-ca` または `sslmode=verify-full` を指定すると、RDS CA 証明書が信頼ストアに存在するか、または接続 URL で参照されることをクライアントは要求します。この要求は、データベース証明書に署名する証明書チェーンを検証するためのものです。
psql や JDBC など、クライアントに SSL サポートが設定されている場合、クライアントは初期にデフォルトで SSL を使用してデータベースへの接続を試みます。クライアントが SSL を使用して接続できない場合、SSL を使用しない接続に戻ります。使用されるデフォルトの `sslmode` モードは、libpq ベースのクライアント (psql など) と JDBC では異なります。libpq ベースのクライアントおよび JDBC クライアントはデフォルトで `prefer` に設定されます。
`sslrootcert` パラメータを使用して証明書を参照します (`sslrootcert=rds-ssl-ca-cert.pem` など)。
以下は、証明書検証で SSL を使用して PostgreSQL DB インスタンスに接続するために `psql` を使用する例です。
```
$ psql "host=db-name.555555555555.ap-southeast-1.rds.amazonaws.com
port=5432 dbname=testDB user=testuser sslrootcert=rds-ca-rsa2048-g1.pem sslmode=verify-full"
```
## PostgreSQL DB インスタンスへの SSL 接続を必須にする
`rds.force_ssl` パラメータを使用することで、PostgreSQL DB インスタンスへの接続に SSL の使用を必須にすることができます。RDS for PostgreSQL バージョン 15 以降では、`rds.force_ssl` パラメータのデフォルト値は 1 (オン) です。その他すべての RDS for PostgreSQL メジャーバージョン 14 以前では、このパラメータのデフォルト値は 0 (オフ) です。`rds.force_ssl` パラメータを 1 (オン) に設定すれば、DB クラスターへの接続で SSL/TLS を必須にすることができます。`rds.force_ssl` パラメータを 1 に設定すれば、DB インスタンスへの接続に SSL を必須にすることができます。
このパラメータの値を変更するには、カスタム DB パラメータグループを作成する必要があります。次に、カスタム DB パラメータグループ内で `rds.force_ssl` の値を `1` に変更して、この機能をオンにします。RDS for PostgreSQL DB インスタンスを作成する前にカスタム DB パラメータグループを準備する場合は、作成プロセス中に (デフォルトのパラメータグループではなく) そのパラメータグループを選択できます。RDS for PostgreSQL DB インスタンスが既に実行された後でこれを行う場合は、インスタンスがカスタムパラメータグループを使用するようにインスタンスを再起動する必要があります。詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
DB インスタンスで `rds.force_ssl` 機能がアクティブになっている場合、SSL を使用していない接続試行は拒否され、次のメッセージが表示されます。
```
$ psql -h db-name.555555555555.ap-southeast-1.rds.amazonaws.com port=5432 dbname=testDB user=testuser
psql: error: FATAL: no pg_hba.conf entry for host "w.x.y.z", user "testuser", database "testDB", SSL off
```
## SSL 接続ステータスを確認する
接続の暗号化ステータスは、DB インスタンスに接続するときにログオンバナーに表示されます。
```
Password for user master:
psql (10.3)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
また、`sslinfo` エクステンションをロードしてから、`ssl_is_used()` 関数を呼び出して、SSL が使用されているかどうかを調べることもできます。この関数は、この接続が SSL を使用している場合に `t` を返し、それ以外の場合に `f` を返します。
```
postgres=> CREATE EXTENSION sslinfo;
CREATE EXTENSION
postgres=> SELECT ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
詳細については、次のクエリを使用して `pg_settings` から情報を取得できます。
```
SELECT name as "Parameter name", setting as value, short_desc FROM pg_settings WHERE name LIKE '%ssl%';
Parameter name | value | short_desc
----------------------------------------+-----------------------------------------+-------------------------------------------------------
ssl | on | Enables SSL connections.
ssl_ca_file | /rdsdbdata/rds-metadata/ca-cert.pem | Location of the SSL certificate authority file.
ssl_cert_file | /rdsdbdata/rds-metadata/server-cert.pem | Location of the SSL server certificate file.
ssl_ciphers | HIGH:!aNULL:!3DES | Sets the list of allowed SSL ciphers.
ssl_crl_file | | Location of the SSL certificate revocation list file.
ssl_dh_params_file | | Location of the SSL DH parameters file.
ssl_ecdh_curve | prime256v1 | Sets the curve to use for ECDH.
ssl_key_file | /rdsdbdata/rds-metadata/server-key.pem | Location of the SSL server private key file.
ssl_library | OpenSSL | Name of the SSL library.
ssl_max_protocol_version | | Sets the maximum SSL/TLS protocol version to use.
ssl_min_protocol_version | TLSv1.2 | Sets the minimum SSL/TLS protocol version to use.
ssl_passphrase_command | | Command to obtain passphrases for SSL.
ssl_passphrase_command_supports_reload | off | Also use ssl_passphrase_command during server reload.
ssl_prefer_server_ciphers | on | Give priority to server ciphersuite order.
(14 rows)
```
また、次のクエリを使用して、RDS for PostgreSQL DB インスタンスの SSL 使用状況に関するすべての情報をプロセス、クライアント、およびアプリケーション別に収集することもできます。
```
SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
FROM pg_stat_ssl
JOIN pg_stat_activity
ON pg_stat_ssl.pid = pg_stat_activity.pid
ORDER BY ssl;
Database name | User name | ssl | client_addr | application_name | backend_type
---------------+-----------+-----+----------------+------------------------+------------------------------
| | f | | | autovacuum launcher
| rdsadmin | f | | | logical replication launcher
| | f | | | background writer
| | f | | | checkpointer
| | f | | | walwriter
rdsadmin | rdsadmin | t | 127.0.0.1 | | client backend
rdsadmin | rdsadmin | t | 127.0.0.1 | PostgreSQL JDBC Driver | client backend
postgres | postgres | t | 204.246.162.36 | psql | client backend
(8 rows)
```
SSL 接続に使用される暗号を識別するには、次のようにクエリを実行します。
```
postgres=> SELECT ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
`sslmode` オプションの詳細については、*PostgreSQL ドキュメント*の「[Database connection control functions](https://www.postgresql.org/docs/11/libpq-connect.html#LIBPQ-CONNECT-SSLMODE)」を参照してください。
## RDS for PostgreSQL の SSL 暗号スイート
PostgreSQL 設定パラメータ [ssl\$1ciphers](https://www.postgresql.org/docs/current/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SSL) は、TLS 1.2 以下のバージョンを使用する際、SSL 接続で許可される暗号スイートのカテゴリを指定します。
RDS for PostgreSQL 16 以降では、許可リストに登録された暗号スイートから特定の値を使用するように `ssl_ciphers` パラメータを変更できます。これは、データベースインスタンスの再起動を必要としない動的パラメータです。許可リストに登録された暗号スイートを表示するには、Amazon RDS コンソールまたは次の AWS CLI コマンドを使用します。
```
aws rds describe-db-parameters --db-parameter-group-name --region --endpoint-url --output json | jq '.Parameters[] | select(.ParameterName == "ssl_ciphers")'
```
次の表に、デフォルトの暗号スイートと、カスタム設定をサポートするバージョンの許可された暗号スイートの両方を示します。
| PostgreSQL エンジンのバージョン | デフォルトの ssl\$1cipher スイート値 | 許可リストに登録されたカスタム ssl\$1cipher スイート値 |
| --- | --- | --- |
| 18 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 17 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 16 | HIGH:\$1aNULL:\$13DES | `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256` `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` |
| 15 | HIGH:\$1aNULL:\$13DES | カスタム ssl\$1ciphers はサポートされていません |
| 14 | HIGH:\$1aNULL:\$13DES | カスタム ssl\$1ciphers はサポートされていません |
| 13 | HIGH:\$1aNULL:\$13DES | カスタム ssl\$1ciphers はサポートされていません |
| 12 | HIGH:\$1aNULL:\$13DES | カスタム ssl\$1ciphers はサポートされていません |
| 11.4 以降のマイナーバージョン | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | カスタム ssl\$1ciphers はサポートされていません |
| 11.1、11.2 | HIGH:MEDIUM:\$13DES:\$1aNULL | カスタム ssl\$1ciphers はサポートされていません |
| 10.9 以降のマイナーバージョン | HIGH:MEDIUM:\$13DES:\$1aNULL:\$1RC4 | カスタム ssl\$1ciphers はサポートされていません |
| 10.7 以前のマイナーバージョン | HIGH:MEDIUM:\$13DES:\$1aNULL | カスタム ssl\$1ciphers はサポートされていません |
`TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384` 暗号スイートを使用するようにすべてのインスタンス接続を設定するには、次の例に示すようにパラメータグループを変更します。
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_ciphers',ParameterValue='TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384',ApplyMethod=immediate"
```
この例では ECDSA 暗号を使用しています。この方式では、接続を確立するために、インスタンスが楕円曲線暗号 (ECC) に対応した認証機関を使用する必要があります。Amazon RDS が提供する認証機関の詳細については、「[認証機関](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/singWithRDS.SSL.html#UsingWithRDS.SSL.RegionCertificateAuthorities)」を参照してください。
使用中の暗号は、「[SSL 接続ステータスの決定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Concepts.General.SSL.html#PostgreSQL.Concepts.General.SSL.Status)」で説明されている方法で確認できます。
暗号の名前はコンテキストによって異なる場合があります。
+ パラメータグループで設定できる許可リストに登録された暗号は、その IANA 名で参照されます。
+ `sslinfo` および `psql` ログオンバナーは、OpenSSL 名を使用した暗号を参照します。
デフォルトでは、RDS for PostgreSQL 16 以降の `ssl_max_protocol_version` の値は TLS v1.3 です。TLS v1.3 は パラメータで指定された暗号設定を使用しないため、この `ssl_ciphers` パラメータの値を TLS v1.2 に設定する必要があります。値を TLS v1.2 として設定すると、接続は `ssl_ciphers` で定義した暗号のみを使用します。
```
aws rds modify-db-parameter-group --db-parameter-group-name --parameters "ParameterName='ssl_max_protocol_version',ParameterValue='TLSv1.2',ApplyMethod=immediate"
```
データベース接続で SSL が使用されるようにするには、パラメータグループで `rds.force_ssl parameter` を 1 に設定します。パラメータとパラメータグループの詳細については、「[Amazon RDS のパラメータグループ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.html)」を参照してください。
# 新しい SSL/TLS 証明書を使用して PostgreSQL DB インスタンスに接続するようにアプリケーションを更新する
Secure Socket Layer または Transport Layer Security (SSL/TLS) に使用される証明書には、通常、設定されたライフタイムがあります。サービスプロバイダーが認証局 (CA) 証明書を更新する際、クライアントでは、新しい証明書を使用するようにアプリケーションを更新する必要があります。以下で、クライアントアプリケーションが SSL/TLS を使用して、Amazon RDS for PostgreSQL DB インスタンスに接続されているかどうかの判別方法についての情報を参照できます。また、これらのアプリケーションが接続時にサーバーの証明書を検証しているかどうかを、確認する方法についても説明します。
**注記**
SSL/TLS 接続の前にサーバー証明書を検証するように構成されたクライアントアプリケーションでは、クライアントのトラストストアに有効な CA 証明書を持つ必要があります。新しい証明書が必要となった場合は、クライアントトラストストアも更新を行います。
クライアントアプリケーションの信頼ストアで CA 証明書を更新した後、DB インスタンスで証明書をローテーションできます。これらの手順は、非本番環境でテストしてから、本番環境で実装することを強くお勧めします。
証明書のローテーションの詳細については、「[SSL/TLS 証明書のローテーション](UsingWithRDS.SSL-certificate-rotation.md)」を参照してください。証明書のダウンロードの詳細については、[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。PostgreSQL DB インスタンスで SSL/TLS を使用する方法については、「[PostgreSQL DB インスタンスで SSL を使用する](PostgreSQL.Concepts.General.SSL.md)」を参照してください。
**Topics**
+ [
## アプリケーションが SSL を使用して PostgreSQL DB インスタンスに接続しているかどうかの確認
](#ssl-certificate-rotation-postgresql.determining-server)
+ [
## クライアントが接続するために証明書の検証を必要とするかどうかの確認
](#ssl-certificate-rotation-postgresql.determining-client)
+ [
## アプリケーション信頼ストアの更新
](#ssl-certificate-rotation-postgresql.updating-trust-store)
+ [
## 各種アプリケーションでの SSL/TLS 接続の使用
](#ssl-certificate-rotation-postgresql.applications)
## アプリケーションが SSL を使用して PostgreSQL DB インスタンスに接続しているかどうかの確認
DB インスタンスの設定で `rds.force_ssl` パラメータの値を確認します。デフォルトでは、バージョン 15 より前のバージョンの PostgreSQL を使用する DB インスタンスの `rds.force_ssl` パラメータは `0` (オフ) に設定されています。デフォルトでは、`rds.force_ssl` は、PostgreSQL バージョン 15 以降のメジャーバージョンを使用する DB インスタンスでは`1` (オン) に設定されています。`rds.force_ssl` パラメータが `1` (オン) に設定されている場合、クライアントは接続に SSL/TLS を使用する必要があります。パラメータグループの詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
RDS PostgreSQL バージョン 9.5 以降のメジャーバージョンを使用していて、`rds.force_ssl` が `1` (オン) に設定されていない場合、`pg_stat_ssl` ビューに対してクエリを実行して SSL を使用している接続をチェックします。例えば次のクエリは、SSL 接続、および SSL を使用するクライアントに関する情報のみを返します。
```
SELECT datname, usename, ssl, client_addr
FROM pg_stat_ssl INNER JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid
WHERE ssl is true and usename<>'rdsadmin';
```
SSL/TLS 接続を使用する行のみが、接続に関する情報とともに表示されます。以下は出力例です。
```
datname | usename | ssl | client_addr
----------+---------+-----+-------------
benchdb | pgadmin | t | 53.95.6.13
postgres | pgadmin | t | 53.95.6.13
(2 rows)
```
このクエリでは、クエリ実行時点の接続のみが表示されます。結果が表示されなくても、SSL 接続を使用しているアプリケーションが存在しないわけではありません。それ以降に別の SSL 接続が確立される場合もあります。
## クライアントが接続するために証明書の検証を必要とするかどうかの確認
psql や JDBC など、クライアントに SSL サポートが設定されている場合、クライアントは初期にデフォルトで SSL を使用してデータベースへの接続を試みます。クライアントが SSL を使用して接続できない場合、SSL を使用しない接続に戻ります。libpq ベースのクライアント (psql など) と JDBC の両方で使用されるデフォルトの `sslmode` モードは、`prefer` に設定されています。サーバー上の証明書が検証されるのは、`sslmode` が `verify-ca` または `verify-full` に設定されて、`sslrootcert` が指定されている場合のみです。証明書が無効な場合は、エラーがスローされます。
`PGSSLROOTCERT` を使用して、`PGSSLMODE` 環境変数で証明書を検証します (`PGSSLMODE` は `verify-ca` または `verify-full` に設定)。
```
PGSSLMODE=verify-full PGSSLROOTCERT=/fullpath/ssl-cert.pem psql -h pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com -U masteruser -d postgres
```
`sslrootcert` 引数を使用して、接続文字列形式で `sslmode` を使用して証明書を検証します (証明書を検証するには、`sslmode` は `verify-ca` または `verify-full` に設定します)。
```
psql "host=pgdbidentifier.cxxxxxxxx.us-east-2.rds.amazonaws.com sslmode=verify-full sslrootcert=/full/path/ssl-cert.pem user=masteruser dbname=postgres"
```
例えば前述の例の場合、無効なルート証明書を使用していると、クライアントで次のようなエラーが表示されます。
```
psql: SSL error: certificate verify failed
```
## アプリケーション信頼ストアの更新
PostgreSQL アプリケーション信頼ストアの更新については、PostgreSQL ドキュメントの「[Secure TCP/IP Connections with SSL](https://www.postgresql.org/docs/current/ssl-tcp.html)」を参照してください。
ルート証明書のダウンロードについては、[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。
証明書をインポートするサンプルスクリプトについては、[証明書を信頼ストアにインポートするためのサンプルスクリプト](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script) を参照してください。
**注記**
信頼ストアを更新するとき、新しい証明書を追加できるだけでなく、古い証明書を保持できます。
## 各種アプリケーションでの SSL/TLS 接続の使用
以下に、各種アプリケーションでの SSL/TLS 接続の使用に関する情報を示します。
+ **psql**
接続文字列または環境可変としてオプションを指定することで、クライアントがコマンドラインから呼び出されます。SSL/TLS 接続の場合、関連するオプションは `sslmode` (環境可変 `PGSSLMODE`)、`sslrootcert` (環境可変 `PGSSLROOTCERT`) です。
オプションの詳細なリストについては、PostgreSQL ドキュメントの「[Parameter Key Words](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-PARAMKEYWORDS)」を参照してください。環境可変の詳細なリストについては、PostgreSQL ドキュメントの「[Environment Variables](https://www.postgresql.org/docs/current/libpq-envars.html)」を参照してください。
+ **pgAdmin**
このブラウザベースのクライアントは、PostgreSQL データベースに接続するために使用できる使いやすいインターフェイスです。
接続の設定については、[pgAdmin のドキュメント](https://www.pgadmin.org/docs/pgadmin4/latest/server_dialog.html)を参照してください。
+ **JDBC**
JDBC は、Java アプリケーションとのデータベース接続を可能にします。
JDBC を使用した PostgreSQL データベースへの接続に関する一般情報については、PostgreSQL JDBC ドライバードキュメントの「[データベースへの接続](https://jdbc.postgresql.org/documentation/use/#connecting-to-the-database)」を参照してください。SSL/TLS を使用した接続については、PostgreSQL JDBC ドライバードキュメントの「[クライアントの設定](https://jdbc.postgresql.org/documentation/ssl/#configuring-the-client)」を参照してください。
+ **Python**:
PostgreSQL データベースに接続するために一般的に使用される Python ライブラリは、`psycopg2` です。
`psycopg2` の使用については、[psycopg2 のドキュメント](https://pypi.org/project/psycopg2/)を参照してください。PostgreSQL データベースへの接続方法に関する簡単なチュートリアルについては、「[Psycopg2 Tutorial](https://wiki.postgresql.org/wiki/Psycopg2_Tutorial)」を参照してください。connect コマンドで受け入れられるオプションについては、「[The psycopg2 module content](http://initd.org/psycopg/docs/module.html#module-psycopg2)」を参照してください。
**重要**
データベース接続で SSL/TLS を使用することを決定し、アプリケーションの信頼ストアを更新したら、rds-ca-rsa2048-g1 証明書を使用するようにデータベースを更新できます。ステップについては、「[DB インスタンスまたはクラスターの変更による CA 証明書の更新](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating)」のステップ 3 を参照してください。
# Amazon RDS for PostgreSQL で Kerberos 認証を使用する
ユーザーが PostgreSQL が実行されている DB インスタンスに接続する場合、Kerberos を使用してそのユーザーを認証できます。そのためには、Kerberos 認証に AWS Directory Service for Microsoft Active Directory を使用するように DB インスタンスを設定します。AWS Directory Service for Microsoft Active Directory は AWS Managed Microsoft AD とも呼ばれます。これは、Directory Service で利用できる機能です。詳細については、「*AWS Directory Service 管理ガイド*」の「[Directory Service とは](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html)」を参照してください。
まず、ユーザー認証情報を格納する AWS Managed Microsoft AD ディレクトリを作成します。次に、Active Directory のドメインおよびその他の情報を PostgreSQL DB インスタンスに提供します。ユーザーが PostgreSQL DB インスタンスを使用して認証を実行すると、認証要求は AWS Managed Microsoft AD ディレクトリに転送されます。
同じディレクトリにすべての認証情報を保持することで時間と労力を節約できます。複数の DB インスタンスの認証情報を一元的に保存および管理できます。また、ディレクトリを使用することで、セキュリティプロファイル全体を向上できます。
また、独自のオンプレミスの Microsoft Active Directory から認証情報にアクセスできます。そのためには、信頼するドメイン関係を作成して、AWS Managed Microsoft AD ディレクトリがオンプレミスの Microsoft Active Directory を信頼するようにします。これにより、ユーザーは、オンプレミスネットワークのワークロードにアクセスするときと同じ Windows シングルサインオン (SSO) の使い方で、PostgreSQL インスタンスにアクセスできます。
データベースは、パスワード認証または、Kerberos 認証または AWS Identity and Access Management (IAM) 認証のいずれかによるパスワード認証を使用できます。IAM 認証の詳細については、「[MariaDB、MySQL、および PostgreSQL の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)」を参照してください。
**注記**
RDS for PostgreSQL は、Active Directory グループの Kerberos 認証をサポートしていません。
**Topics**
+ [
## 利用可能なリージョンとバージョン
](#postgresql-kerberos.RegionVersionAvailability)
+ [
## PostgreSQL DB インスタンスの Kerberos 認証の概要
](#postgresql-kerberos-overview)
+ [
# PostgreSQL DB インスタンスの Kerberos 認証のセットアップ
](postgresql-kerberos-setting-up.md)
+ [
# Active Directory ドメインの RDS for PostgreSQL DB インスタンスの管理
](postgresql-kerberos-managing.md)
+ [
# PostgreSQL を Kerberos 認証と接続する
](postgresql-kerberos-connecting.md)
## 利用可能なリージョンとバージョン
機能の可用性とサポートは、各データベースエンジンの特定のバージョン、および AWS リージョン によって異なります。Kerberos 認証を使用した RDS for PostgreSQL のバージョンとリージョンの可用性の詳細については、「[Amazon RDS での Kerberos データベース認証でサポートされているリージョンと DB エンジン](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md)」を参照してください。
## PostgreSQL DB インスタンスの Kerberos 認証の概要
PostgreSQL DB インスタンスに Kerberos 認証を設定するには、以下で説明するステップを実行します。
1. AWS Managed Microsoft AD を使用して AWS Managed Microsoft AD ディレクトリを作成します。AWS マネジメントコンソール、AWS CLI、Directory Service API を使用して、ディレクトリを作成できます。ディレクトリがインスタンスと通信できるように、ディレクトリセキュリティグループで関連するアウトバウンドポートを必ず開いてください。
1. AWS Managed Microsoft AD ディレクトリを呼び出すためのアクセスを Amazon RDS に許可するロールを作成します。これにより、マネージド IAM ポリシー `AmazonRDSDirectoryServiceAccess` を使用する AWS Identity and Access Management (IAM) ロールが作成されます。
IAM ロールによるアクセスを許可するには、AWS Security Token Service (AWS STS) エンドポイントを AWS アカウントの AWS リージョンでアクティベートする必要があります。AWS STS エンドポイントはすべての AWS リージョン でデフォルトでアクティブになっているため、他のアクションを実行せずに、エンドポイントを使用することができます。詳細については、*IAM ユーザーガイド*の「[AWS STS リージョンでの AWS のアクティブ化と非アクティブ化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate)」を参照してください。
1. Microsoft Active Directory のツールを使用して、AWS Managed Microsoft AD ディレクトリでユーザーとグループを作成し、設定します。Active Directory にユーザーを作成する方法の詳細については、*AWS 管理ガイド*の「[Directory Service マネージド Microsoft AD でユーザーとグループを管理する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html)」を参照してください。
1. 異なる AWS アカウントまたは Virtual Private Cloud (VPC) 内にディレクトリおよび DB インスタンスを配置する場合は、VPC ピア接続を設定します。詳細については、*Amazon VPC Peering Guide*の「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html)」を参照してください。
1. 以下のいずれかの方法を使用して、コンソール、CLI、RDS API から PostgreSQL DB インスタンスを作成または変更します。
+ [Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)
+ [Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)
+ [DB インスタンスへの復元](USER_RestoreFromSnapshot.md)
+ [Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md)
インスタンスは、ディレクトリと同じ Amazon Virtual Private Cloud (VPC)、または別の AWS アカウントまたは VPC にあります。PostgreSQL DB インスタンスの作成または変更時に、次のステップを行います。
+ ディレクトリの作成時に、生成されたドメイン識別子 (`d-*` 識別子) を指定します。
+ 作成した IAM ロール名を指定します。
+ DB インスタンスのセキュリティグループが、ディレクトリのセキュリティグループからインバウンドトラフィックを受信できることを確認します。
1. RDS マスターユーザー認証情報を使用して、PostgreSQL DB インスタンスインスタンスに接続します。外部で識別されるように PostgreSQL でユーザーを作成します。外部で識別されたユーザーは、Kerberos 認証を使用して PostgreSQL DB インスタンスにログインできます。
# PostgreSQL DB インスタンスの Kerberos 認証のセットアップ
AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) を使用して、PostgreSQL DB インスタンスに Kerberos 認証をセットアップします。Kerberos 認証をセットアップするには、次のステップに従います。
**Topics**
+ [
## ステップ 1: AWS Managed Microsoft AD を使用してディレクトリを作成する
](#postgresql-kerberos-setting-up.create-directory)
+ [
## ステップ 2: (オプション) オンプレミスの Active Directory と Directory Service との間の信頼関係を作成する
](#postgresql-kerberos-setting-up.create-trust)
+ [
## ステップ 3: Amazon RDS が Directory Service にアクセスするための IAM ロールを作成する
](#postgresql-kerberos-setting-up.CreateIAMRole)
+ [
## ステップ 4: ユーザーを作成して設定する
](#postgresql-kerberos-setting-up.create-users)
+ [
## ステップ 5: ディレクトリと DB インスタンスの間のクロス VPC トラフィックを有効にする
](#postgresql-kerberos-setting-up.vpc-peering)
+ [
## ステップ 6: PostgreSQL DB インスタンスを作成または変更する
](#postgresql-kerberos-setting-up.create-modify)
+ [
## ステップ 7: Kerberos プリンシパル用の PostgreSQL ユーザーを作成する
](#postgresql-kerberos-setting-up.create-logins)
+ [
## ステップ 8: PostgreSQL クライアントを設定する
](#postgresql-kerberos-setting-up.configure-client)
## ステップ 1: AWS Managed Microsoft AD を使用してディレクトリを作成する
Directory Service はフルマネージド型の Active Directory を AWS クラウド内に作成します。AWS Managed Microsoft AD ディレクトリを作成すると、Directory Service が 2 つのドメインコントローラーと DNS サーバーを作成します。ディレクトリサーバーは、VPC 内の異なるサブネットで作成されます。この冗長性によって、障害が発生してもディレクトリにアクセス可能な状態を維持できます。
AWS Managed Microsoft AD ディレクトリを作成すると、AWS Directory Service がユーザーに代わって次のタスクを実行します。
+ VPC 内に Active Directory を設定します。
+ ユーザー名 `Admin` と指定されたパスワードを使用してディレクトリ管理者アカウントを作成します。このアカウントを使用してディレクトリを管理します。
**重要**
このパスワードは必ず保管してください。Directory Service にはこのパスワードは保存されず、復元やリセットもできません。
+ ディレクトリコントローラー用セキュリティグループを作成します。セキュリティグループは、PostgreSQL DB インスタンスとの通信を許可する必要があります。
AWS Directory Service for Microsoft Active Directory を起動すると、AWS は組織単位 (OU) を作成します。OU にはディレクトリのオブジェクトがすべて含まれています。この OU はドメインルートにあります。OU にはディレクトリを作成する際に入力した NetBIOS 名があります。ドメインルートは AWS が所有し、管理します。
`Admin` ディレクトリに作成された AWS Managed Microsoft AD アカウントには、OU に対して頻繁に実行される管理行為の権限が含まれています。
+ ユーザーを作成、更新、削除する
+ ファイルやプリントサーバーなどのドメインにリソースを追加して、追加したリソースへのアクセス許可を OU のユーザーとグループに割り当てる
+ 追加の OU やコンテナを作成する
+ 権限を委譲する
+ 削除されたオブジェクトを Active Directory のごみ箱から元に戻す
+ Active Directory Web Service で Windows PowerShell 用の Active Directory と Domain Name Service (DNS) モジュールを実行する。
`Admin` アカウントには、ドメイン全体に関係するアクティビティを実行する権限もあります。
+ DNS 設定 (レコード、ゾーン、フォワーダーの追加、削除、更新) を管理する
+ DNS イベントログを参照する
+ セキュリティイベントログを参照する
**AWS Managed Microsoft AD でディレクトリを作成するには**
1. [Directory Serviceコンソール](https://console.aws.amazon.com/directoryservicev2/)のナビゲーションペインで、[**ディレクトリ**]、[**ディレクトリのセットアップ**] の順に選択します。
1. **AWS Managed Microsoft AD** を選択します。現在、 Amazon RDS での使用では AWS Managed Microsoft AD のオプションのみがサポートされています。
1. [**次へ**] を選択します。
1. [**ディレクトリ情報の入力**] ページに、以下の情報を指定します。
**エディション**
目的の要件を満たすエディションを選択します。
**ディレクトリの DNS 名**
ディレクトリの完全修飾名 (例: **corp.example.com**)。
**ディレクトリの NetBIOS 名**
ディレクトリの短縮名 (例: `CORP`)。
**ディレクトリの説明**
必要に応じて、ディレクトリの説明。
**Admin パスワード**
ディレクトリ管理者のパスワードです。ディレクトリの作成プロセスでは、ユーザー名 `Admin` とこのパスワードを使用して管理者アカウントが作成されます。
ディレクトリ管理者のパスワードには、「admin」の単語を含めることはできません。パスワードは大文字と小文字を区別し、8-64 文字にします。また、以下の 4 つのカテゴリうち 3 つから少なくとも 1 文字を含める必要があります。
+ 小文字 (a～z)
+ 大文字 (A～Z)
+ 数字 (0～9)
+ 英数字以外の文字 (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/)
**パスワードを確認**
管理者のパスワードをもう一度入力します。
このパスワードは必ず保管してください。Directory Service にはこのパスワードは保存されず、復元やリセットもできません。
1. [**Next (次へ)**] を選択します。
1. [**VPC とサブネットの選択**] ページで、以下の情報を指定します。
**VPC**
ディレクトリ用の VPC を選択します。PostgreSQL DB インスタンスは、この同じ VPC または異なる VPC で作成できます。
**Subnets**
ディレクトリサーバーのサブネットを選択します。2 つのサブネットは、異なるアベイラビリティーゾーンに存在している必要があります。
1. [**Next (次へ)**] を選択します。
1. ディレクトリの情報を確認します。変更が必要な場合は、[**戻る**] を選択し、変更を行います。情報が正しい場合は、[**Create directory (ディレクトリの作成)**] を選択します。
![\[ディレクトリの詳細ページ\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/WinAuth2.png)
ディレクトリが作成されるまで、数分かかります。正常に作成されると、[**Status**] 値が [**Active**] に変わります。
ディレクトリに関する情報を表示するには、ディレクトリの一覧で、そのディレクトリ ID を選択します。**ディレクトリ ID** 値を書き留めます。PostgreSQL DB インスタンスを作成または変更する場合は、この値が必要です。
![\[詳細ページの画像\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/WinAuth3.png)
## ステップ 2: (オプション) オンプレミスの Active Directory と Directory Service との間の信頼関係を作成する
独自のオンプレミスの Microsoft Active Directory を使用する予定がない場合は、[ステップ 3: Amazon RDS が Directory Service にアクセスするための IAM ロールを作成する](#postgresql-kerberos-setting-up.CreateIAMRole) に進みます。
オンプレミスの Active Directory を使用して Kerberos 認証を取得するには、オンプレミスの Microsoft Active Directory と (AWS Managed Microsoft AD で作成された) [ステップ 1: AWS Managed Microsoft AD を使用してディレクトリを作成する](#postgresql-kerberos-setting-up.create-directory) ディレクトリとの間に、フォレストの信頼を使用して、信頼するドメイン関係を作成する必要があります。信頼は一方向にすることができます。この場合、AWS Managed Microsoft AD ディレクトリはオンプレミスの Microsoft Active Directory を信頼します。信頼は、両方の Active Directory が相互に信頼する双方向にすることもできます。Directory Service を使用して信頼関係を設定する方法の詳細については、「*AWS Directory Service 管理ガイド*」の「[信頼関係を作成する場合](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_setup_trust.html)」を参照してください。
**注記**
オンプレミスの Microsoft Active Directory を使用している場合、Windows クライアントは rds.amazonaws.com の代わりにエンドポイント内の Directory Service のドメイン名を使用して接続します。詳細については[PostgreSQL を Kerberos 認証と接続する](postgresql-kerberos-connecting.md)を参照してください。
オンプレミスの Microsoft Active Directory ドメイン名に、新しく作成された信頼関係に対応する DNS サフィックスルーティングが含まれていることを確認してください。次のスクリーンショットは、例を示しています。
![\[作成された信頼に対応している DNS ルーティング\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/kerberos-auth-trust.png)
## ステップ 3: Amazon RDS が Directory Service にアクセスするための IAM ロールを作成する
Amazon RDS が Directory Service を呼び出すには、AWS アカウントにマネージド IAM ポリシー `AmazonRDSDirectoryServiceAccess` を使用する IAM ロールが必要です。このロールにより、Amazon RDS は Directory Service を呼び出すことが可能になります。
AWS マネジメントコンソール を使用して DB インスタンスを作成し、コンソールユーザーが `iam:CreateRole` アクセス許可を持っている場合、コンソールは必要な IAM ロールを自動的に作成します。この場合、ロール名は `rds-directoryservice-kerberos-access-role` です。それ以外の場合は、IAM ロールを手動で作成する必要があります。IAM ロールを作成する場合、[`Directory Service`] を選択し、それに AWS マネージドポリシー `AmazonRDSDirectoryServiceAccess` をアタッチします。
サービス用の IAM ロールを作成する方法の詳細については、「*IAM ユーザーガイド*」の「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
**注記**
RDS for Microsoft SQL Server の Windows 認証に使用される IAM ロールは、Amazon RDS for PostgreSQL に使用できません。
`AmazonRDSDirectoryServiceAccess` マネージドポリシーを使用する代わりに、必要なアクセス許可を使用してポリシーを作成することもできます。これを行うには、IAM ロールに次の IAM 信頼ポリシーが必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.amazonaws.com",
"rds.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
また、ロールには、以下の IAM ロールポリシーも必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ds:DescribeDirectories",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:GetAuthorizedApplicationDetails"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
オプトインの AWS リージョンの場合は、IAM ロールの信頼ポリシーでリージョン固有のサービスプリンシパルを使用します。これらのリージョンでサービスの信頼ポリシーを作成するときは、サービスプリンシパルでリージョンコードを指定します。
次の例では、リージョン固有のサービスプリンシパルを含む信頼ポリシーを示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"directoryservice.rds.REGION-CODE.amazonaws.com",
"rds.REGION-CODE.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
REGION-CODE を、特定のリージョンのコードに置き換えます。例えば、アジアパシフィック (メルボルン) リージョンでは、次のサービスプリンシパルを使用します。
```
"Service": [
"directoryservice.rds.ap-southeast-4.amazonaws.com",
"rds.ap-southeast-4.amazonaws.com"
]
```
## ステップ 4: ユーザーを作成して設定する
Active Directory ユーザーとコンピューターツールを使用してユーザーを作成できます。これは Active Directory Domain Services ツールおよび Active Directory Lightweight Directory Services ツールの 1 つです。詳細については、Microsoft のドキュメントの「[ユーザーとコンピュータを Active Directory ドメインに追加する](https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/create-an-active-directory-server#add-users-and-computers-to-the-active-directory-domain)」を参照してください。この場合、ユーザーは個人またはその他のエンティティです。例えば、ドメインの一部であり、その ID がディレクトリで管理されているコンピュータなどです。
Directory Service ディレクトリにユーザーを作成するには、Directory Service ディレクトリのメンバーである Windows ベースの Amazon EC2 インスタンスに接続している必要があります。同時に、ユーザーを作成する権限を持つユーザーとしてログインしていなければなりません。詳細については、*AWS Directory Service 管理ガイド*の「[ユーザーの作成](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups_create_user.html)」を参照してください。
## ステップ 5: ディレクトリと DB インスタンスの間のクロス VPC トラフィックを有効にする
同じ VPC 内にディレクトリおよび DB インスタンスを配置する場合は、このステップをスキップして [ステップ 6: PostgreSQL DB インスタンスを作成または変更する](#postgresql-kerberos-setting-up.create-modify) に進みます。
ディレクトリと DB インスタンスを別の VPC に配置する場合は、VPC ピア接続または [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) を使用してクロス VPC トラフィックを設定します。
次の手順では、VPC ピア接続を使用して VPC 間のトラフィックを有効にします。*Amazon Virtual Private Cloud ピアリング接続ガイド*の「[VPC ピア機能とは](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html)」の手順に従います。
**VPC ピア接続を使用してクロス VPC トラフィックを有効にするには**
1. 適切な VPC ルーティングを設定し、ネットワークトラフィックが双方向にフローするようにします。
1. DB インスタンスのセキュリティグループが、ディレクトリのセキュリティグループからインバウンドトラフィックを受信できることを確認します。
1. トラフィックをブロックするネットワークのアクセス制御リスト (ACL) ルールがないことを確認します。
別の AWS アカウントがディレクトリを所有している場合は、ディレクトリを共有する必要があります。
**AWS アカウント間でディレクトリを共有するには**
1. DB インスタンスを作成する AWS アカウントとの間でディレクトリの共有をスタートするには、*AWS 管理ガイド*の「[チュートリアル: Directory Service マネージド Microsoft AD ディレクトリを共有して、シームレスに EC2 ドメインを結合する](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_directory_sharing.html)」の手順を実行します。
1. DB インスタンスのアカウントを使用して、Directory Service コンソールにサインインし、続行する前にドメインが必ず `SHARED` ステータスであることを確認します。
1. DB インスタンスのアカウントを使用して Directory Service コンソールにサインインしている間に、[**ディレクトリ ID**] の値を書き留めておきます。このディレクトリ ID は、DB インスタンスをドメインに結合するために使用します。
## ステップ 6: PostgreSQL DB インスタンスを作成または変更する
ディレクトリで使用する PostgreSQL DB インスタンスを作成または変更します。コンソール、CLI、RDS API を使用して DB インスタンスとディレクトリを関連付けることができます。これには以下の 2 つの方法があります。
+ コンソール、[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI コマンド、または [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API オペレーションを使用して新しい PostgreSQL DB インスタンスを作成します。手順については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ コンソール、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンド、または [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API オペレーションを使用して、既存の PostgreSQL DB インスタンスを変更します。手順については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
+ コンソール、[DB スナップショットから DB インスタンスを復元する](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) CLI コマンド、または [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API オペレーションを使用して、DB スナップショットから PostgreSQL DB インスタンスを復元します。手順については、「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
+ コンソール、[restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI コマンド、または [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API オペレーションを使用して、PostgreSQL インスタンスをポイントインタイムに復元します。手順については、「[Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md)」を参照してください。
Kerberos 認証は、VPC 内の PostgreSQL DB インスタンスでのみサポートされています。DB インスタンスは、ディレクトリと同じ VPC または異なる VPC 内にあります。DB インスタンスがディレクトリと通信する場合、そのインスタンスは、ディレクトリの VPC 内での送受信を許可するセキュリティグループを使用する必要があります。
### コンソール
DB インスタンスを作成、変更、復元するためにコンソールを使用する場合は、**データベースの認証**セクションの [**パスワードと Kerberos 認証**] を選択します。次に、[**ディレクトリのブラウジング**] を選択します。Directory Service を使用するには、ディレクトリを選択するか、[**新しいディレクトリの作成**] を選択します。
![\[認証に Kerberos を選択し、使用するディレクトリを特定します。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/rpg-authentication-use-kerberos.png)
### AWS CLI
AWS CLI を使用する場合は、DB インスタンスが、作成したディレクトリを使用できるように、以下のパラメータが必要です。
+ `--domain` パラメータには、ディレクトリの作成時に生成されたドメイン識別子 ("d-\$1" 識別子) を使用します。
+ `--domain-iam-role-name` パラメータには、マネージド IAM ポリシー `AmazonRDSDirectoryServiceAccess` を使用する作成済みのロールを使用します。
例えば、以下の CLI コマンドはディレクトリを使用するように DB インスタンスを変更します。
```
aws rds modify-db-instance --db-instance-identifier mydbinstance --domain d-Directory-ID --domain-iam-role-name role-name
```
**重要**
DB インスタンスを変更して Kerberos 認証を有効にした場合、変更後、その DB インスタンスを再起動します。
## ステップ 7: Kerberos プリンシパル用の PostgreSQL ユーザーを作成する
この時点で、 RDS for PostgreSQL DB インスタンスが AWS Managed Microsoft AD ドメインに参加しました。[ステップ 4: ユーザーを作成して設定する](#postgresql-kerberos-setting-up.create-users) のディレクトリに作成したユーザーを PostgreSQL データベースユーザーとして設定し、データベースにログインする権限を付与する必要があります。そのためには、`rds_superuser` 権限を持つデータベースユーザーとしてサインインします。例えば、RDS for PostgreSQL DB インスタンス、の作成時にデフォルト値を受け入れた場合は、次のステップに示すように `postgres` を使用します。
**Kerberos プリンシパル用の PostgreSQL データベースユーザーを作成するには**
1. `psql` を使用して、の RDS for PostgreSQL DB インスタンスのエンドポイントに `psql` を使用して接続します。次の例では、`postgres` ロールにデフォルトの `rds_superuser` アカウントを使用しています。
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. データベースにアクセスする Kerberos プリンシパル (Active Directory ユーザー名) ごとにデータベースユーザー名を作成します。Active Directory インスタンスで定義されている正規のユーザー名 (ID) を使用します。つまり、そのユーザー名には、小文字 `alias` (Active Directory 内のユーザー名) と Active Directory ドメインの大文字の名前を使用します。Active Directory ユーザー名は外部認証されたユーザーなので、次に示すように名前を引用符で囲んでください。
```
postgres=> CREATE USER "username@CORP.EXAMPLE.COM" WITH LOGIN;
CREATE ROLE
```
1. データベースユーザーに `rds_ad` ロールを付与します。
```
postgres=> GRANT rds_ad TO "username@CORP.EXAMPLE.COM";
GRANT ROLE
```
Active Directory ユーザー ID のすべての PostgreSQL ユーザーの作成が完了すると、ユーザーは Kerberos 認証情報を使用して RDS for PostgreSQL DB インスタンス にアクセスできます。
Kerberos を使用して認証するデータベースユーザーは、Active Directory ドメインのメンバーであるクライアントマシンから認証を行う必要があります。
`rds_ad` ロールを付与されたデータベースユーザーもその `rds_iam` ロールを持つことはできません。これは、ネストされたメンバーシップにも適用されます。詳細については、「[MariaDB、MySQL、および PostgreSQL の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)」を参照してください。
## ステップ 8: PostgreSQL クライアントを設定する
PostgreSQL クライアントを設定するには、次のステップを実行します。
+ ドメインを指す krb5.conf ファイル (または同等) を作成します。
+ クライアントホストと Directory Service 間でトラフィックが流れることを確認します。次の目的で Netcat などのネットワークユーティリティを使用します。
+ ポート 53 の DNS 経由のトラフィックを確認します。
+ ポート 53 および Kerberos の TCP/UDP 上のトラフィックを確認します。これには、Directory Service の場合ポート 88 および 464 が含まれます。
+ データベースポートを介してクライアントホストと DB インスタンス間でトラフィックが流れることを確認します。例えば、psql を使用してデータベースに接続し、アクセスします。
以下は、AWS Managed Microsoft AD 向けの krb5.conf の内容のサンプルです 。
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
```
以下は、オンプレミスの Microsoft Active Directory 向けの krb5.conf の内容のサンプルです。
```
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = example.com
admin_server = example.com
}
ONPREM.COM = {
kdc = onprem.com
admin_server = onprem.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
.onprem.com = ONPREM.COM
onprem.com = ONPREM.COM
.rds.amazonaws.com = EXAMPLE.COM
.amazonaws.com.rproxy.goskope.com.cn = EXAMPLE.COM
.amazon.com = EXAMPLE.COM
```
# Active Directory ドメインの RDS for PostgreSQL DB インスタンスの管理
コンソール、CLI、RDS API を使用して、 DB インスタンスと Microsoft Active Directory との関係を管理できます。例えば、Kerberos 認証を有効化するために、Microsoft Active Directory を関連付けることができます。また、Microsoft Active Directory の関連付けを解除して、Kerberos 認証を無効化することもできます。さらに、1 つの Microsoft Active Directory によって外部に認証される DB インスタンスをもう 1 つの Microsoft Active Directory に移動することもできます。
例えば、CLI を使用して次を実行できます。
+ メンバーシップが失敗した Kerberos 認証を再度有効化するには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンドを使用します。`--domain` オプションに現在のメンバーシップのディレクトリ ID を指定します。
+ DB インスタンスの Kerberos 認証を無効にするには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンドを使用します。`none` オプションで、`--domain` を指定します。
+ DB インスタンスをあるドメインから別のドメインに移動するには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンドを使用します。`--domain` オプションの新しいドメインのドメイン識別子を指定します。
## ドメインのメンバーシップを理解する
DB インスタンスを作成または変更すると、ドメインのそれがメンバーになります。DB インスタンスのドメインメンバーシップのステータスは、コンソールで表示したり、[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) CLI コマンドを実行して表示したりすることができます。DB インスタンスのステータスは、以下のいずれかです。
+ `kerberos-enabled` - DB インスタンスは Kerberos 認証を有効化しました。
+ `enabling-kerberos` - AWS は、この DB インスタンスで Kerberos 認証を有効化中です。
+ `pending-enable-kerberos` - この DB インスタンスでは、Kerberos 認証の有効化が保留中になっています。
+ `pending-maintenance-enable-kerberos` - AWS は、次にスケジュールされたメンテナンスウィンドウで、DB インスタンスでの Kerberos 認証の有効化を試みます。
+ `pending-disable-kerberos` - この DB インスタンスでは、Kerberos 認証の無効化が保留中になっています。
+ `pending-maintenance-disable-kerberos` - AWS は、次にスケジュールされたメンテナンスウィンドウで、DB インスタンスでの Kerberos 認証の無効化を試みます。
+ `enable-kerberos-failed` - 設定の問題により、AWS が DB インスタンスで Kerberos 認証を有効化できませんでした。DB インスタンスを変更するコマンドを再発行する前に、設定の問題を修正します。
+ `disabling-kerberos` - AWS は、この DB インスタンスで Kerberos 認証を無効化中です。
ネットワーク接続の問題や正しくない IAM ロールのために、Kerberos 認証を有効化するリクエストは失敗する可能性があります。場合によっては、DB インスタンスを作成または変更するときに、Kerberos 認証を有効にしようとすると失敗する可能性があります。その場合、正しい IAM ロールを使用していることを確認してから、DB インスタンスを変更し、ドメインに接続します。
**注記**
PostgreSQL で RDS を使用する Kerberos 認証でのみ、ドメインの DNS サーバーにトラフィックが送信されます。他のすべての DNS リクエストは、PostgreSQL を実行している DB インスタンスでアウトバウンドのネットワークアクセスとして扱われます。RDS for PostgreSQL を使用したアウトバウンドネットワークアクセスの詳細については、「[アウトバウンドネットワークアクセスでカスタム DNS サーバーを使用する](Appendix.PostgreSQL.CommonDBATasks.CustomDNS.md)」を参照してください。
# PostgreSQL を Kerberos 認証と接続する
pgAdmin インターフェイスまたは psql などのコマンドラインインターフェイスを使用して、Kerberos 認証で PostgreSQL に接続できます。接続の詳細については、「[PostgreSQL データベースエンジンを実行する DB インスタンスへの接続](USER_ConnectToPostgreSQLInstance.md) 」を参照してください。エンドポイント、ポート番号、および接続に必要なその他の詳細情報を取得する方法について詳細は、「[PostgreSQL DB インスタンスへの接続](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md#CHAP_GettingStarted.Connecting.PostgreSQL)」を参照してください。
**注記**
PostgreSQL の GSSAPI 認証と暗号化は、Kerberos ライブラリ `libkrb5.so` によって実装されます。`postgres_fdw` や `dblink` などの機能は、Kerberos 認証または暗号化によるアウトバウンド接続についても同じライブラリに依存します。
## pgAdmin
pgAdmin を使用して、PostgreSQL を Kerberos 認証に接続するには、以下のステップを実行します。
1. クライアントコンピュータの pgAdmin アプリケーションを起動します。
1. [**Dashboard**] (ダッシュボード) タブで、[**Add New Server**] (新しいサーバーの追加) を選択します。
1. [**Create - Server (作成 - サーバー)**] ダイアログボックスで、[**General (全般)**] タブに名前を入力し、pgAdmin のサーバーを特定します。
1. **[Connection]** (接続) タブで、 RDS for PostgreSQL データベースから次の情報を入力します。
+ **[Host]** (ホスト) では、のエンドポイントを入力します。RDS for PostgreSQL DB インスタンス。エンドポイントは次のようになります。
```
RDS-DB-instance.111122223333.aws-region.rds.amazonaws.com
```
Windows クライアントからオンプレミスの Microsoft Active Directory に接続するには、ホストエンドポイントで `rds.amazonaws.com` の代わりに AWS Managed Active Directory のドメイン名を使用します。例えば、AWS Managed Active Directory のドメイン名が `corp.example.com` であるとします。この場合、**[Host]** (ホスト) では、エンドポイントは次のように指定されます。
```
RDS-DB-instance.111122223333.aws-region.corp.example.com
```
+ [**Port (ポート)**] に、割り当てられたポートを入力します。
+ [**Maintenance database (メンテナンスデータベース)**] に、クライアントが接続する初期データベースの名前を入力します。
+ [**ユーザーネーム**] に、「[ステップ 7: Kerberos プリンシパル用の PostgreSQL ユーザーを作成する](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins)」で Kerberos 認証用に入力したユーザーネームを入力します。
1. [**保存**] を選択します。
## Psql
psql を使用して、PostgreSQL を Kerberos 認証に接続するには、以下のステップを実行します。
1. コマンドプロンプトで、次のコマンドを実行します。
```
kinit username
```
*`username`* をユーザー名で置き換えます。プロンプトで Microsoft Active Directory に保存されているユーザーのパスワードを入力します。
1. PostgreSQL DB インスタンスがパブリックにアクセス可能な VPC を使用している場合は、EC2 クライアントの `/etc/hosts` ファイルに、DB インスタンスエンドポイントの IP アドレスを記述します。例えば、次のコマンドは IP アドレスを取得し、それを `/etc/hosts` ファイルに入れます。
```
% dig +short PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com
;; Truncated, retrying in TCP mode.
ec2-34-210-197-118.AWS-Region.compute.amazonaws.com.
34.210.197.118
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com" >> /etc/hosts
```
Windows クライアントからオンプレミスの Microsoft Active Directory を使用している場合は、特別なエンドポイントを使用して接続する必要があります。ホストエンドポイントで Amazon ドメイン `rds.amazonaws.com` を使用する代わりに、AWS Managed Active Directory のドメイン名を使用します。
例えば、AWS Managed Active Directory のドメイン名が `corp.example.com` であるとします。次に、エンドポイントの形式 `PostgreSQL-endpoint.AWS-Region.corp.example.com` を使用して、これを `/etc/hosts` ファイルに配置します。
```
% echo " 34.210.197.118 PostgreSQL-endpoint.AWS-Region.corp.example.com" >> /etc/hosts
```
1. 次の psql コマンドを使用して、Active Directory と統合されている PostgreSQL DB インスタンスにログインします。
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.rds.amazonaws.com postgres
```
オンプレミスの Active Directory を使用して、Windows クライアントから PostgreSQL DB クラスターにログインするには、前のステップ (`corp.example.com`) のドメイン名を指定して次の psql コマンドを使用します。
```
psql -U username@CORP.EXAMPLE.COM -p 5432 -h PostgreSQL-endpoint.AWS-Region.corp.example.com postgres
```
# アウトバウンドネットワークアクセスでカスタム DNS サーバーを使用する
RDS for PostgreSQL では、DB インスタンスでのアウトバウンドネットワークアクセスをサポートし、お客様が所有するカスタム DNS サーバーからのドメインネームサービス (DNS) 解決を許可します。カスタム DNS サーバーを介して、RDS for PostgreSQL DB インスタンスの完全修飾ドメイン名のみを解決できます。
**Topics**
+ [
## カスタム DNS 解決をオンにする
](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Enable)
+ [
## カスタム DNS 解決をオフにする
](#Appendix.PostgreSQL.CommonDBATasks.CustomDNS.Disable)
+ [
## カスタム DNS サーバーのセットアップ
](#Appendix.Oracle.CommonDBATasks.CustomDNS.Setup)
## カスタム DNS 解決をオンにする
ユーザーの VPC で DNS 解決をオンにするには、まずカスタム DB パラメータグループを RDS for PostgreSQL インスタンスに関連付けます。次に、`rds.custom_dns_resolution` パラメータを 1 に設定してオンにしてから、変更を反映させるために DB インスタンスを再起動します。
## カスタム DNS 解決をオフにする
ユーザーの VPC で DNS 解決をオフにするには、まずカスタム DB パラメータグループの `rds.custom_dns_resolution` パラメータを 0 に設定してオフにします。その後、変更を反映させるために DB インスタンスを再起動します。
## カスタム DNS サーバーのセットアップ
カスタム DNS ネームサーバーを設定後、変更を DB インスタンスに反映させるまで約 30 分ほどかかります。DB インスタンスへの変更が反映されたら、すべてのアウトバウンドネットワークトラフィックのポート 53 の DNS サーバーにおいて DNS ルックアップクエリを行う必要があります。
**注記**
カスタム DNS サーバーを設定せず、`rds.custom_dns_resolution` が 1 に設定されている場合、ホストは Amazon Route 53 プライベートゾーンを使用して解決されます。詳細については、「[プライベートホストゾーンの使用](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html)」を参照してください。
**RDS for PostgreSQL DB インスタンスのカスタム DNS サーバーをセットアップするには**
1. VPC にアタッチされた Dynamic Host Configuration Protocol (DHCP) オプションセットで、`domain-name-servers` オプションを DNS ネームサーバーの IP アドレスに設定します。詳細については、「[DHCP オプションセット](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)」を参照してください。
**注記**
`domain-name-servers` オプションが許可する値は 4 つまでになりますが、Amazon RDS DB インスタンスが使用するのは初期の値のみです。
1. DNS サーバーが、パブリック DNS 名、Amazon EC2 プライベート DNS 名、ユーザー固有の DNS 名を含むすべてのルックアップクエリを解決できることを確認します。DNS サーバーが処理できない DNS ルックアップがアウトバウンドネットワークトラフィックにある場合は、状況に適したアップストリーミング DNS プロバイダを必ず設定してください。
1. 512 バイト以下の User Datagram Protocol (UDP) レスポンスを生成するように DNS サーバーを設定します。
1. 1,024 バイト以下の Transmission Control Protocol (TCP) レスポンスを生成するように DNS サーバーを設定します。
1. ポート 53 で Amazon RDS DB インスタンスからのインバウンドトラフィックを許可するように DNS サーバーを設定します。DNS サーバーが Amazon VPC にある場合、VPC にはポート 53 で UDP と TCP トラフィックを許可するインバウンドルールを含むセキュリティグループが必要になります。DNS サーバーが Amazon VPC にない場合は、ポート 53 で UDP と TCP インバウンドトラフィックを許可できるように、適切なファイアウォール設定が必要になります。
詳細については、「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」と「[ルールの追加と削除](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules)」を参照してください。
1. ポート 53 でアウトバウンドトラフィックを許可するため、Amazon RDS DB インスタンスの VPC を設定します。VPC には、ポート 53 で UDP および TCP トラフィックを許可するアウトバウンドルールを含むセキュリティグループが必要になります。
詳細については、「*Amazon VPC ユーザーガイド*」の「[Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」(VPC のセキュリティグループ) と「[Adding and removing rules](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#AddRemoveRules)」(ルールの追加および削除) を参照してください。
1. Amazon RDS DB インスタンスと DNS サーバー間のルーティングパスが、DNS トラフィックを許可するように適切に設定されていることを確認してください。
Amazon RDS DB インスタンスと DNS サーバーが同じ VPC に存在しない場合は、それらの間でピアリング接続がセットアップされていることを確認してください。詳細については、「*Amazon VPC ピアリングガイド*」の「[VPC ピアリングとは](https://docs.aws.amazon.com/vpc/latest/peering/Welcome.html)」を参照してください。
# RDS for PostgreSQL DB エンジンのアップグレード
PostgreSQL データベースで管理できる 2 つのタイプのアップグレードがあります。
+ OS の更新 - では、Amazon RDS は、セキュリティの修正や OS の変更を適用するために、データベースの基になるオペレーティングシステムの更新が必要になる場合があります。RDS コンソール、AWS Command Line Interface (AWS CLI)、または RDS API を使用して、Amazon RDS に OS の更新を適用するタイミングを指定できます。OS 更新接続の詳細については、「[DB インスタンスへの更新の適用](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades)」を参照してください
+ データベースエンジンの更新 - Amazon RDS が新バージョンのデータベースエンジンをサポートすると、データベースをその新バージョンにアップグレードできます。
このコンテキストの*データベース*とは、RDS for PostgreSQL DB インスタンスまたはマルチ AZ DB クラスターです。
PostgreSQL データベースのエンジンアップグレードには、メジャーバージョンアップグレードとマイナーバージョンアップグレードの 2 種類があります。
**メジャーバージョンのアップグレード**
*メジャーバージョンのアップグレード*には、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれる場合があります。そのため、データベースのメジャーバージョンアップグレードは手動で実行する必要があります。メジャーバージョンアップグレードをスタートするには、DB インスタンスまたはマルチ AZ DB クラスターを変更します。メジャーバージョンアップグレードを行う前に、「[RDS for PostgreSQL のメジャーバージョンアップグレードの選択](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)」で説明されているステップを実行することをお勧めします。
Amazon RDS は、次の方法でマルチ AZ メジャーバージョンのアップグレードを処理します。
+ **マルチ AZ DB インスタンスデプロイ** – Amazon RDS はプライマリインスタンスとスタンバイインスタンスを同時にアップグレードします。アップグレードが完了するまで、データベースが数分間使用できない場合があります。
+ **マルチ AZ DB クラスターデプロイ** – Amazon RDS はリーダーインスタンスとライターインスタンスを同時にアップグレードします。アップグレードが完了するまで、データベースが数分間使用できない場合があります。
リージョン内リードレプリカがある DB インスタンスをアップグレードする場合、Amazon RDS はプライマリ DB インスタンスと共にレプリカもアップグレードします。
Amazon RDS は、マルチ AZ DB クラスターのリードレプリカをアップグレードしません。マルチ AZ DB クラスターのメジャーバージョンアップグレードを実行すると、リードレプリカのレプリケーション状態が**終了**に変わります。アップグレードの完了後、リードレプリカを手動で削除し、再作成する必要があります。
ブルー/グリーンデプロイを使用することで、メジャーバージョンアップグレードに必要なダウンタイムを最小限に抑えることができます。詳細については、「[データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する](blue-green-deployments.md)」を参照してください。
**マイナーバージョンのアップグレード**
それに対して、*マイナーバージョンのアップグレード*に含まれるのは、既存のアプリケーションとの下位互換性がある変更のみです。マイナーバージョンのアップグレードを手動で行うには、データベースを変更します。または、データベースの作成時または変更時に、**[マイナーバージョン自動アップグレード]** を有効にすることができます。これにより、Amazon RDS は、新しいバージョンがテストおよび承認されると、データベースを自動的にアップグレードします。
Amazon RDS は、マルチ AZ マイナーバージョンアップグレードを次の方法で処理します。
+ **マルチ AZ DB インスタンスデプロイ** – Amazon RDS はプライマリインスタンスとスタンバイインスタンスを同時にアップグレードします。アップグレードが完了するまで、データベースが数分間使用できない場合があります。
+ **マルチ AZ DB クラスターデプロイ** – Amazon RDS はリーダー DB インスタンスを一度に 1 つずつアップグレードします。その後、リーダー DB インスタンスの 1 つが新しいライター DB インスタンスに切り替わります。次に、Amazon RDS は、古いライターインスタンス (今ではリーダーインスタンス) をアップグレードします。マルチ AZ DB クラスターは、通常、マイナーバージョンアップグレードのダウンタイムを約 35 秒に短縮します。RDS Proxy と併用すると、ダウンタイムをさらに 1 秒以下に短縮できます。詳細については、「[Amazon RDS Proxy ](rds-proxy.md)」を参照してください。または、[ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/)、[PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/)、[AWS Advanced JDBC Wrapper Driver](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/) などのオープンソースデータベースプロキシを使用することもできます。
データベースに複数のリードレプリカがある場合は、ソースインスタンスまたはクラスターをアップグレードする前に、すべてのリードレプリカをアップグレードする必要があります。
詳細については、「[RDS for PostgreSQL のマイナーバージョンの自動アップグレード](USER_UpgradeDBInstance.PostgreSQL.Minor.md)」を参照してください。マイナーバージョンアップグレードの手動での実行に関する詳細は、「[エンジンバージョンの手動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual)」を参照してください。
データベースエンジンのバージョン、およびデータベースエンジンのバージョンを廃止するためのポリシーの詳細については、Amazon RDS FAQ の「[データベースエンジンのバージョン](https://aws.amazon.com/rds/faqs/#Database_Engine_Versions)」を参照してください。
**Topics**
+ [
## PostgreSQL アップグレードに関する考慮事項
](#USER_UpgradeDBInstance.PostgreSQL.Considerations)
+ [
## 有効なアップグレードターゲットの検索
](#USER_UpgradeDBInstance.PostgreSQL.FindingTargets)
+ [
# PostgreSQL のバージョン番号
](USER_UpgradeDBInstance.PostgreSQL.VersionID.md)
+ [
# RDS for PostgreSQL の RDS バージョン番号
](USER_UpgradeDBInstance.PostgreSQL.rds.version.md)
+ [
# RDS for PostgreSQL のメジャーバージョンアップグレードの選択
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
+ [
# RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法
](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)
+ [
# RDS for PostgreSQL のマイナーバージョンの自動アップグレード
](USER_UpgradeDBInstance.PostgreSQL.Minor.md)
+ [
# RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード
](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)
+ [
# イベントによる RDS for PostgreSQL エンジンのアップグレードのモニタリング
](USER_UpgradeDBInstance.PostgreSQL.Monitoring.md)
## PostgreSQL アップグレードに関する考慮事項
データベースを安全にアップグレードするために、Amazon RDS では、「[PostgreSQL ドキュメント](https://www.postgresql.org/docs/current/pgupgrade.html)」で示されている `pg_upgrade` ユーティリティを使用します。
バックアップ保存期間が 0 を超える値の場合、Amazon RDS はアップグレードプロセス中に 2 つの DB スナップショットを収得します。初期の DB スナップショットは、アップグレードの変更が行われる前のデータベースから作成されます。アップグレードがデータベースに対して失敗した場合は、このスナップショットを復元して、以前のバージョンを実行するデータベースを作成できます。アップグレードの完了後に 2 番目の DB スナップショットが作成されます。これらの DB スナップショットは、バックアップ保持期間が終了すると自動的に削除されます。
**注記**
データベースのバックアップ保持期間を 0 より大きく設定した場合にのみ、Amazon RDS は、アップグレード中に DB スナップショットを作成します。DB インスタンスのバックアップ保持期間を変更するには、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。マルチ AZ DB クラスターのカスタムバックアップ保持期間を設定することはできません。
DB インスタンスのメジャーバージョンアップグレードを実行すると、任意のリージョン内リードレプリカも自動的にアップグレードされます。アップグレードワークフローがスタートされると、リードレプリカは、`pg_upgrade` がプライマリ DB インスタンスで正常に完了するまで待ちます。次に、プライマリ DB インスタンスのアップグレードは、リードレプリカのアップグレードが完了するまで待ちます。アップグレードが完了するまで停止が発生します。マルチ AZ DB クラスターののメジャーバージョンを実行すると、すべてのリードレプリカのレプリケーション状態が**終了**に変わります。
アップグレードが完了したら、DB エンジンの前のバージョンに戻すことはできません。前のバージョンに戻す必要がある場合は、アップグレードの前に作成された DB スナップショットを復元して、新しいデータベースを作成します。
## 有効なアップグレードターゲットの検索
AWS マネジメントコンソール を使用してデータベースをアップグレードする場合、データベースの有効なアップグレードターゲットが表示されます。次の AWS CLI コマンドを使用して、データベースの有効なアップグレードターゲットを特定することもできます。
Linux、macOS、Unix の場合:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version version-number \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Windows の場合:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version version-number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
例えば、PostgreSQL バージョン 16.1 データベースの有効なアップグレードターゲットを特定するには、次の AWS CLI コマンドを実行します。
Linux、macOS、Unix の場合:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
Windows の場合:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
# PostgreSQL のバージョン番号
PostgreSQL データベースエンジンのバージョン番号は、次のように付けられています。
+ PostgreSQL バージョン 10 以降では、エンジンのバージョン番号は*メジャー.マイナー*の形式になります。メジャーバージョンの番号は、バージョン番号の整数の部分です。マイナーバージョンの番号は、バージョン番号の小数の部分です。
メジャーバージョンのアップグレードでは、10.*マイナー*から 11.*マイナー*のように、バージョン番号の整数の部分が大きくなります。
+ 10 より前のバージョンの PostgreSQL では、エンジンのバージョン番号は*メジャー.メジャー.マイナー*の形式になります。エンジンのメジャーバージョンの番号は、バージョン番号の整数と 1 つ目の小数の部分の両方です。例えば、9.6 はメジャーバージョンです。マイナーバージョンの番号は、バージョン番号の 3 つ目の部分です。例えば、バージョン 9.6.12 では、12 がマイナーバージョンの番号です。
メジャーバージョンのアップグレードでは、バージョン番号の主要な部分が大きくなります。例えば、*9.6*.12 から 11.14 へのアップグレードはメジャーバージョンのアップグレードであり、*9.6* と *11* はメジャーバージョン番号です。
RDS 延長サポートのバージョン番号付けの詳細については、「[Amazon RDS 延長サポートバージョンの命名規則](extended-support-versions.md#extended-support-naming)」を参照してください。
# RDS for PostgreSQL の RDS バージョン番号
RDS バージョン番号は `major.minor.patch` 命名規則を使用します。RDS パッチバージョンには、リリース後にマイナーバージョンに追加された重要なバグ修正が含まれています。RDS 延長サポートのバージョン番号付けの詳細については、「[Amazon RDS 延長サポートバージョンの命名規則](extended-support-versions.md#extended-support-naming)」を参照してください。
データベースの Amazon RDS バージョン番号を識別するには、まず次のコマンドを使用して `rds_tools` 拡張機能を作成する必要があります。
```
CREATE EXTENSION rds_tools;
```
PostgreSQL バージョン 15.2-R2 のリリース以降、次の SQL クエリを使用して RDS for PostgreSQL データベースの RDS バージョン番号を確認できるようになりました。
```
postgres=> SELECT rds_tools.rds_version();
```
例えば、RDS for PostgreSQL 15.2 データベースをクエリすると、次が返されます。
```
rds_version
----------------
15.2.R2
(1 row)
```
# RDS for PostgreSQL のメジャーバージョンアップグレードの選択
メジャーバージョンのアップグレードには、以前のバージョンのデータベースと下位互換性のない変更が含まれる場合があります。新しい機能により、既存のアプリケーションが適切に動作しなくなることがあります。このため、Amazon RDS では、メジャーバージョンアップグレードは自動的に適用されません。メジャーバージョンのアップグレードを行うには、データベースを手動で変更します。本稼働データベースにアップグレードを適用する前に、アップグレードを徹底的にテストしてアプリケーションが正常に動作することを確認してください。PostgreSQL メジャーバージョンアップグレードを行うには、「[RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)」に記載されているステップを実施することをお勧めします。
PostgreSQL シングル AZ DB インスタンスまたはマルチ AZ DB インスタンス配置を次のメジャーバージョンにアップグレードすると、データベースに関連付けられている任意のリードレプリカも次のメジャーバージョンにアップグレードされます。場合によっては、アップグレード時に上位のメジャーバージョンにスキップできます。アップグレードでメジャーバージョンがスキップされると、リードレプリカもターゲットのメジャーバージョンにアップグレードされます。他のメジャーバージョンをスキップするバージョン 11 へのアップグレードには、特定の制限があります。詳細については、[RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md) で説明する手順を参照してください。
PostgreSQL のほとんどの拡張機能は、PostgreSQL エンジンのアップグレード時にアップグレードされません。拡張機能は、個別にアップグレードする必要があります。詳細については、「[RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)」を参照してください。
次の AWS CLI クエリを実行すると、RDS for PostgreSQL データベースで利用できるメジャーバージョンを確認できます。
```
aws rds describe-db-engine-versions --engine postgres --engine-version your-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text
```
使用可能なすべてのバージョンに対するこのクエリの結果の概要を次の表に示します。バージョン番号のアスタリスク (\$1) は、そのバージョンのサポートが終了したことを示します。現在のバージョンがサポートされていない場合は、最新のマイナーバージョンのアップグレードターゲットにアップグレードするか、そのバージョンで利用可能な他のアップグレードターゲットにアップグレードすることをお勧めします。
| 現在のソースバージョン | アップグレードターゲット |
| --- | --- |
| 17.6 | なし |
| 17.5 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 17.4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) |
| 17.3\$1、17.2 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) |
| 17.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) |
| 16.10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) |
| 16.9 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 16.8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) |
| 16.7\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5 ](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.7 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.6 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) |
| 16.5\$1、16.4 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)、[16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) |
| 16.3 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)、[16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166)、[16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) |
| 16.2\$1、16.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)、[16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166)、[16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164)、[16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) |
| 15.14 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) |
| 15.13 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 15.12、15.11\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) |
| 15.10 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)、[16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) |
| 15.9\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)、[15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15.8 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)、[16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166)、[16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)、[15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) |
| 15.7 | [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、1[6.8、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)16[.7、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version167)6.[6、16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166).5[、16.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version165)4、[16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、1[5.12、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)15[.11、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511)5.[10、15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510).9[、15.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159)8[15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) |
| 15.6\$1、15.5\$1、15.4\$1、15.3\$1、15.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6、16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166).4[、16.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164)3[16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)、[15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510)、[15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158)、[15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) |
| 14.19 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) |
| 14.18 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 14.17、14.16\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) |
| 14.15 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)、[15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) |
| 14.14\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)15[.12、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)5.[10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)、[14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) |
| 14.13 | [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、1[5.12、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)15[.11、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511)5.[10、15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510).9[、15.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159)8[15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、1[4.17、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)14[.16、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416)4.[15、14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415).1[4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414) |
| 14.12 | [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、1[5.12、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)15[.11、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1511)5.[10、15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510).9[、15.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version159)8、[15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、1[4.17、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)14[.16、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1416)4.[15、14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415).1[4、14.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414)13[14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) |
| 14.11\$1、14.10\$1、14.9\$1、14.8\$1、14.7\$1、14.6\$1、14.5\$1、14.4\$1、14.3\$1、14.2\$1、14.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6、16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166).4[、16.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164)3[16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)15[.12、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)5.[10、15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510).8[、15.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158)7[15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)、[14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415)、[14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413)、[14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) |
| 13.22 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419) |
| 13.21 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322) |
| 13.20、13.19\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)15[.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 13.18、13.17\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)15[.12、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)5.[10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)、[14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、[13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) |
| 13.16 | [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、1[4.17、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)14[.15、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415)4.[14、14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414).1[3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、1[3.20、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)13[.19、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319)3.[18、13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318).1[7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317) |
| 13.15 | [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158)、1[5.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、1[4.17、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)14[.15、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415)4.[14、14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1414).1[3、14.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413)12[14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、1[3.20、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)13[.19、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1319)3.[18、13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318).1[7、13.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1317)16[13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) |
| 13.14\$1、13.13\$1、13.12\$1、13.11\$1、13.10\$1、13.9\$1、13.8\$1、13.7\$1、13.6\$1、13.5\$1、13.4\$1、13.3\$1、13.2\$1、13.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6、16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166).4[、16.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164)3[16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)15[.12、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)5.[10、15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510).8[、15.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158)7[15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、1[4.18、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)14[.17、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)4.[15、14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415).1[3、14.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413)12[14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、[13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)、[13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318)、[13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316)、[13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) |
| 12.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、1[4.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) |
| 12.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)15[.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、1[4.18、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)14[.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、[13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.22、12.21\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)、[16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)、[15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)、[14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、[13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)、[13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)、[12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.20\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)、[16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166)、[16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)、[15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510)、[15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)、[14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415)、[14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、[13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)、[13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318)、[13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222)、[12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)、[12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 12.19\$1、12.18\$1、12.17\$1、12.16\$1、12.15\$1、12.14\$1、12.13\$1、12.12\$1、12.11\$1、12.10\$1、12.9\$1、12.8\$1、12.7\$1、12.6\$1、12.5\$1、12.4\$1、12.3\$1、12.2\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6、16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166).4[、16.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164)3[16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)15[.12、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)5.[10、15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510).8[、15.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158)7[15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、1[4.18、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)14[.17、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)4.[15、14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415).1[3、14.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413)12[14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、1[3.21、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)13[.20、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)3.[18、13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318).1[6、13.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316)15[13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222)、[12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)、[12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250508 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321) [12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) |
| 11.22-rds.20250220 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、[13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320) [12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)、[12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22-rds.20240509 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、1[6.9、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)16[.8、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)6.[6、16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166).4[、16.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164)3[16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、1[5.13、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)15[.12、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)5.[10、15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510).8[、15.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158)7[15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、1[4.18、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)14[.17、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)4.[15、14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415).1[3、14.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413)12[14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、1[3.21、](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)13[.20、1](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)3.[18、13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318).1[6、13.](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316)15[13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222)、[12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)、[12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808)、[11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121)、[11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220)、[11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
| 11.22、11.21\$1、11.20\$1、11.19\$1、11.18\$1、11.17\$1、11.16\$1、11.15\$1、11.14\$1、11.13\$1、11.12\$1、11.11\$1、11.10\$1、11.9\$1、11.8\$1、11.7\$1、11.6\$1、11.5\$1、11.4\$1、11.2\$1、11.1\$1 | [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version176)、[17.5](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version175)、[17.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version174)、[17.2](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version172) [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1610)、[16.9](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version169)、[16.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version168)、[16.6](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version166)、[16.4](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version164)、[16.3](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version163) [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1514)、[15.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1513)、[15.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1512)、[15.10](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1510)、[15.8](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version158)、[15.7](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version157) [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1419)、[14.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1418)、[14.17](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1417)、[14.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1415)、[14.13](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1413)、[14.12](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1412) [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1322)、[13.21](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1321)、[13.20](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1320)、[13.18](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1318)、[13.16](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1316)、[13.15](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1315) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222)、[12.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250220)、[12.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1222rds20250508) [11.22-rds.20240418](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240418)、[11.22-rds.20240509](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240509)、[11.22-rds.20240808](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20240808)、[11.22-rds.20241121](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20241121)、[11.22-rds.20250220](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250220)、[11.22-rds.20250508](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version1122rds20250508) |
\$1 このバージョンは現在サポートされていません。
# RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法
Amazon RDS for PostgreSQL データベースでメジャーバージョンのアップグレードを実行する場合は、以下のプロセスをお勧めします。
1. **バージョンとの互換性を持つパラメータグループの準備** - カスタムパラメータグループを使用している場合は、2 つのオプションがあります。新しい DB エンジンバージョンのデフォルトのパラメータグループを指定します。または、新しい DB エンジンバージョンの独自のカスタムパラメータグループを作成します。詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」および「[マルチ AZ DB クラスターの DB クラスターパラメータグループを使用する](USER_WorkingWithDBClusterParamGroups.md)」を参照してください。
1. **サポートされていないデータベースクラスを確認する** - データベースのインスタンスクラスが、アップグレード先の PostgreSQL バージョンと互換性があることを確認します。詳細については、「[DB インスタンスクラスでサポートされている DB エンジン](Concepts.DBInstanceClass.Support.md)」を参照してください。
1. **サポートされていない使用の確認**
+ **準備済みのトランザクション** - アップグレードを実行する前に、すべての準備済みのトランザクションをコミットまたはロールバックします。
次のクエリを使用して、開いている準備済みのトランザクションがデータベースにないことを確認します。
```
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
```
+ **Reg\$1 データ型** - アップグレードの実施前に *reg\$1* データ型の使用をすべて削除します。`regtype` と `regclass` を除き、*reg\$1* データ型をアップグレードすることはできません。このデータ型はアップグレードで使用されているため、 `pg_upgrade` ユーティリティで維持することはできません。
サポートされていない *reg\$1* データ型が使用されていないことを確認するには、データベースごとに次のクエリを使用します。
```
SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
WHERE c.oid = a.attrelid
AND NOT a.attisdropped
AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
'pg_catalog.regprocedure'::pg_catalog.regtype,
'pg_catalog.regoper'::pg_catalog.regtype,
'pg_catalog.regoperator'::pg_catalog.regtype,
'pg_catalog.regconfig'::pg_catalog.regtype,
'pg_catalog.regdictionary'::pg_catalog.regtype)
AND c.relnamespace = n.oid
AND n.nspname NOT IN ('pg_catalog', 'information_schema');
```
1. **無効なデータベースがないかチェックします。**
+ 無効なデータベースがないことを確認します。`pg_database` カタログの `datconnlimit` 列には、`DROP DATABASE` オペレーション中に中断されたデータベースを無効としてマークする `-2` という値が含まれています。
次のクエリを使用して、無効なデータベースをチェックします。
```
SELECT datname FROM pg_database WHERE datconnlimit = - 2;
```
+ 前のクエリは無効なデータベース名を返します。`DROP DATABASE invalid_db_name;` を使用して無効なデータベースを削除できます。また、次のコマンドを使用して、無効なデータベースを削除することもできます。
```
SELECT 'DROP DATABASE ' || quote_ident(datname) || ';' FROM pg_database WHERE datconnlimit = -2 \gexec
```
無効なデータベースの詳細については、「[無効なデータベースでの自動バキュームの動作を理解する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/appendix.postgresql.commondbatasks.autovacuumbehavior.html)」を参照してください。
1. **論理レプリケーションスロットの処理** — データベースに論理レプリケーションスロットがある場合、アップグレードは実行できません。論理レプリケーションスロットは通常、データベースからデータレイク、BI ツール、およびその他のターゲットへのテーブルのレプリケートおよび AWS DMS に使用されます。アップグレードする前に、使用中の論理レプリケーションスロットの目的を確認し、削除しても問題ないことを確認してください。論理レプリケーションスロットがまだ使用されている場合は、それらを削除しないでください。また、その場合、アップグレードを続行することはできません。
論理レプリケーションスロットが不要な場合は、次の SQL を使用して削除できます。
```
SELECT * FROM pg_replication_slots WHERE slot_type NOT LIKE 'physical';
SELECT pg_drop_replication_slot(slot_name);
```
`pglogical` 拡張機能を使用する論理レプリケーション設定でも、メジャーバージョンアップグレードを正常に行うには、スロットを削除する必要があります。`pglogical` 拡張機能を使用して作成されたスロットを識別して削除する方法については、「[ RDS for PostgreSQL 用ロジカルレプリケーションスロットの管理](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)」を参照してください。
ソースバージョン 17 以降では、non-read-replicas の論理レプリケーションスロットはアップグレードを通じて保持されます。リードレプリカで作成された論理レプリケーションスロットは、アップグレード中は保持されません。
アップグレードを開始する前に、すべてのトランザクションと論理デコードメッセージがスロットから消費されていることを確認します。論理レプリケーションスロットによって保持されている消費されていない先行書き込みログファイル (WAL) がある場合、アップグレードは失敗し、問題のスロットを識別するメッセージが表示されます。詳細については、「[PostgreSQL ドキュメント](https://www.postgresql.org/docs/current/logical-replication-upgrade.html)」を参照してください。
ソースバージョンが 17.8 または 18.2 より前のマルチ AZ クラスターでは、`flow_control` が無効になっていることを確認します。詳細については、「[マルチ AZ DB クラスターのフロー制御のオンとオフ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/multi-az-db-clusters-concepts.html#multi-az-db-clusters-concepts-replica-lag)」を参照してください。フロー制御を無効にするには、`shared_preload_libraries` から拡張機能を削除するか、DB インスタンスを再起動します。
1. **リードレプリカの処理** - シングル AZ DB インスタンスまたはマルチ AZ DB インスタンス配置のアップグレードでは、プライマリ DB インスタンスと共にリージョン内リードレプリカもアップグレードされます。Amazon RDS は、マルチ AZ DB クラスターのリードレプリカをアップグレードしません。
リードレプリカを個別にアップグレードすることはできません。個別にアップグレードできるとすると、プライマリインスタンスとレプリカデータベースの PostgreSQL メジャーバージョンが一致しないという状況が生じる可能性があります。ただし、リードレプリカをアップグレードすると、プライマリ DB インスタンスのダウンタイムが増加する場合があります。リードレプリカのアップグレードを防ぐには、レプリカをスタンドアロンインスタンスに昇格させるか、アップグレードプロセスをスタートする前にレプリカを削除します。
アップグレードプロセスでは、リードレプリカの現在のパラメータグループに基づいて、リードレプリカのパラメータグループが再作成されます。アップグレードの完了後にのみ、リードレプリカを変更してカスタムパラメータグループをリードレプリカに適用できます。リードレプリカの詳細については、「[Amazon RDS for PostgreSQL でのリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.md)」を参照してください。
1. **ラージオブジェクトの処理** – PostgreSQL では、通常の列データ型で許可される最大サイズを超える大きなバイナリオブジェクト (ファイル、画像、動画など) を保存および管理するために、ラージオブジェクト (BLOB とも呼ばれます) が使用されます。詳細については、[PostgreSQL ラージオブジェクトのドキュメント](https://www.postgresql.org/docs/current/largeobjects.html)を参照してください。
数百万のラージオブジェクトがあり、アップグレード中にインスタンスがそれらを処理できない場合、アップグレードはメモリ不足になり、失敗する可能性があります。PostgreSQL メジャーバージョンのアップグレードプロセスは、大きく分けて 2 つのフェーズで構成されます。pg\$1dump によるスキーマダンプと、pg\$1restore による復元です。データベースに数百万のラージオブジェクトがある場合は、アップグレード中に pg\$1dump と pg\$1restore を処理するために十分なメモリがインスタンスにあることを確認し、より大きなインスタンスタイプにスケールする必要があります。
アップグレードを開始する前に、データベースにラージオブジェクトがあるかどうかを確認します。カタログには、ラージオブジェクトに関連付けられたメタデータ `pg_largeobject_metadata` が格納されます。実際のラージオブジェクトデータは `pg_largeobject` に保存されます。次のクエリを使用して、ラージオブジェクトの数を確認します。
```
SELECT count(*) FROM pg_largeobject_metadata;
```
既存のラージオブジェクトまたは孤立したラージオブジェクトをクリーンアップするには、「[lo モジュールを使用したラージオブジェクトの管理](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_large_objects_lo_extension.html)」を参照してください。
メジャーバージョンのアップグレードを計画する際、データベースに 2,500～3,000 万個のラージオブジェクトが含まれている場合は、少なくとも 32 GB のメモリを備えたインスタンスタイプを使用することをお勧めします。この推奨事項は当社のテストに基づいており、特定のワークロードとデータベース設定によって異なる場合があります。データベースに追加のオブジェクト (テーブル、インデックス、マテリアライズドビューなど) が含まれている場合は、アップグレードプロセス中に最適なパフォーマンスを確保するために、より大きなインスタンスタイプを選択することをお勧めします。
1. **ゼロ ETL 統合の処理** – 既存の[ゼロ ETL 統合](zero-etl.md)がある場合は、これを[削除](zero-etl.deleting.md)してから、メジャーバージョンアップグレードを実行してください。次に、アップグレードが完了したら、統合を再作成します。
ソースのメジャーバージョン 17 以降では、ゼロ ETL 統合はアップグレードを通じて保持できます。
1. **バックアップの実行** - データベースの復元ポイントを認識できるように、メジャーバージョンアップグレードを実行する前にはバックアップを実行しておくことをお勧めします。バックアップ保持期間を 0 より大きい値に設定すると、アップグレードプロセスにおいて、アップグレード前後にデータベースの DB スナップショットが作成されます。バックアップ保持期間を変更するには、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」と「[Amazon RDS のマルチ AZ DB クラスターの変更](modify-multi-az-db-cluster.md)」を参照してください。
手動でバックアップを実行するには、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」と「[Amazon RDS のマルチ AZ DB クラスターのスナップショットの作成](USER_CreateMultiAZDBClusterSnapshot.md)」を参照してください。
1. **メジャーバージョンのアップグレード前に特定のエクステンションを更新する** - アップグレードでメジャーバージョンをスキップする場合、メジャーバージョンのアップグレード*前*に特定のエクステンションを更新する必要があります。例えば、バージョン 9.5.x または 9.6.x からバージョン 11.x 以降へのアップグレードでは、メジャーバージョンがスキップされます。更新する拡張機能には、空間データを処理するための PostGIS および関連する拡張機能が含まれます。
+ `address_standardizer`
+ `address_standardizer_data_us`
+ `postgis_raster`
+ `postgis_tiger_geocoder`
+ `postgis_topology`
`rdkit` バージョン 4.6.0 以前、および PostgreSQL バージョン 16 以前を使用している場合は、`rdkit` に互換性がないため、PostgreSQL バージョン 17 に直接アップグレードすることはできません。アップグレードオプションは次のとおりです。
+ PostgreSQL バージョン 13 以前を使用している場合は、まずバージョン 14.14 以降のバージョン 14、15.9 以降のバージョン 15、または 16.5 以降のバージョン 16 へのメジャーバージョンアップグレードを実行してから、PostgreSQL 17 にアップグレードする必要があります。
+ PostgreSQL バージョン 14、15、または 16 を使用している場合は、バージョン 14.14 以降のバージョン 14、15.9 以降のバージョン 15、または 16.5 以降のバージョン 16 へのマイナーバージョンアップグレードを実行してから、PostgreSQL 17 にアップグレードする必要があります。
使用している拡張機能ごとに以下のコマンドを実行します。
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
詳細については、「[RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)」を参照してください。PostGIS のアップグレードの詳細については、「[ステップ 6: PostGIS 拡張機能を更新する](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)」を参照してください。
1. **メジャーバージョンアップグレードの前に特定の拡張機能を削除する** - ターゲットバージョンでサポートされていない拡張機能は削除する必要があります。削除しない場合、アップグレードは失敗します。
`plrust` 拡張機能は RDS PostgreSQL 18 から削除されます。既知の問題のため、RDS PostgreSQL バージョン 18.1 および 18.2 では `postgis_topology` 拡張機能を使用できません [[1](https://trac.osgeo.org/postgis/ticket/5983)]、[[2](https://trac.osgeo.org/postgis/ticket/6016)]。これらの拡張機能は、アップグレードする前に削除する必要があります。
メジャーバージョンをバージョン 11.x にスキップするアップグレードは、`pgRouting` 拡張機能の更新をサポートしていません。バージョン 9.4.x、9.5.x、または 9.6.x からバージョン 11.x へのアップグレードでは、メジャーバージョンがスキップされます。`pgRouting` エクステンションを削除し、アップグレード後に互換性のあるバージョンに再インストールできます。更新できるエクステンションのバージョンについては、[サポートされている PostgreSQL 拡張機能バージョン](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md) をご覧ください。
`tsearch2` および `chkpass` のエクステンションは、PostgreSQL バージョン 11 以降では現在サポートされていません。
拡張機能がインストールされているかどうかは、次のクエリで確認できます。
```
SELECT * FROM pg_extension WHERE extname in ('extension_name');
```
1. **unknown データ型の削除** - ターゲットのバージョンに応じて、`unknown` データ型を削除します。
PostgreSQL バージョン 10 では、`unknown` データ型のサポートは終了しています。バージョン 9.6 のデータベースで `unknown` データ型を使用している場合、バージョン 10 にアップグレードすると次のようなエラーメッセージが表示されます。
```
Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."
```
データベース内の `unknown` データ型を検索して、問題の列を削除したり、サポートされているデータ型に変更したりするには、次の SQL を使用します。
```
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
```
1. **リハーサル更新の実行** - プロダクションデータベースのアップグレードを行う前に、プロダクションデータベースの複製でメジャーバージョンアップグレードをテストすることを強くお勧めします。複製されたテストデータベースの実行計画を監視して、実行計画のリグレッションが発生していないかどうかを確認し、そのパフォーマンスを評価できます。テストインスタンスの複製を作成するには、データベースを最新スナップショットから復元するか、ポイントインタイムの復元を実行して復元可能な直近の時間でデータベースを復元します。
詳細については、「[スナップショットからの復元](USER_RestoreFromSnapshot.md#USER_RestoreFromSnapshot.Restoring)」または「[Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md)」を参照してください。マルチ AZ DB クラスターについては、「[スナップショットからマルチ AZ DB クラスターへの復元](USER_RestoreFromMultiAZDBClusterSnapshot.Restoring.md)」または「[マルチ AZ DB クラスターを指定の時点の状態に復元する](USER_PIT.MultiAZDBCluster.md)」を参照してください。
アップグレードの実施の詳細については、「[エンジンバージョンの手動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual)」を参照してください。
バージョン 9.6 のデータベースをバージョン 10 にアップグレードする場合、PostgreSQL 10 では、デフォルトで並列クエリが有効になることに注意してください。テストデータベースの `max_parallel_workers_per_gather` パラメータを 2 に変更することで、アップグレードする*前*に並列処理による影響をテストできます。
**注記**
`default.postgresql10` DB パラメータグループでは、`max_parallel_workers_per_gather` パラメータのデフォルト値は 2 です。
詳細については、「PostgreSQL ドキュメント」の「[Parallel Query](https://www.postgresql.org/docs/10/parallel-query.html)」(並列クエリ) を参照してください。バージョン 10 で並列処理を無効にするには、`max_parallel_workers_per_gather` パラメータを 0 に設定します。
メジャーバージョンのアップグレード中、`public` データベースと `template1` データベース、およびすべてのデータベースの `public` スキーマは、一時的に名前が変更されます。これらのオブジェクトは、元の名前とランダム文字列を組み合わせた名前でログに表示されます。この文字列は、メジャーバージョンアップグレード時に `locale` や `owner` などのカスタム設定が保持されるように追加されます。アップグレードが完了したら、これらのオブジェクト名は元の名前に戻ります。
**注記**
メジャーアップグレードのプロセス中に、DB インスタンスまたはマルチ AZ DB クラスターのポイントインタイムの復元を実行することはできません。Amazon RDS でアップグレードが完了すると、データベースの自動バックアップが実施されます。ポイントインタイムの復元を実行できるのは、アップグレードのスタート前およびデータベースの自動バックアップ完了後です。
1. **事前チェック手順エラーでアップグレードが失敗した場合、問題を解決します** - メジャーバージョンのアップグレードプロセス中に、Amazon RDS for PostgreSQL は初期に事前チェック手順を実行して、アップグレードの失敗の原因となる可能性のある問題を特定します。事前チェック手順は、インスタンス内のすべてのデータベースにわたって潜在的な互換性のない条件をすべてチェックします。
事前チェックで問題が発生した場合、アップグレード事前チェックが失敗したことを示すログイベントが作成されます。事前確認プロセスの詳細は、データベースのすべてのデータベースの `pg_upgrade_precheck.log` と名前が付けられたアップグレードログにあります。Amazon RDS では、ファイル名にタイムスタンプが追加されます。ログの表示の詳細については、「[Amazon RDS ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。
リードレプリカのアップグレードが事前チェックで失敗した場合、失敗したリードレプリカのレプリケーションは中断され、リードレプリカは終了状態になります。リードレプリカを削除し、アップグレードしたプライマリ DB インスタンスに基づいて、新しいリードレプリカを再作成します。
事前チェックログで特定されたすべての問題を解決してから、メジャーバージョンのアップグレードを再試行します。事前チェックログの例は次のようになります。
```
------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.
* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.
* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].
* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.
```
1. **データベースのアップグレード中にリードレプリカのアップグレードが失敗した場合は、問題を解決します** - 失敗したリードレプリカは `incompatible-restore` 状態になり、レプリケーションはデータベースで終了します。リードレプリカを削除し、アップグレードしたプライマリ DB インスタンスに基づいて、新しいリードレプリカを再作成します。
**注記**
Amazon RDS は、マルチ AZ DB クラスターのリードレプリカをアップグレードしません。マルチ AZ DB クラスターのメジャーバージョンアップグレードを実行すると、リードレプリカのレプリケーション状態が**終了**に変わります。
リードレプリカのアップグレードは、次の理由で失敗することがあります。
+ 待機時間が経過してもプライマリ DB インスタンスにキャッチアップできなかった。
+ ストレージ不足、互換性のない復元など、最終状態または互換性のないライフサイクル状態であった。
+ プライマリ DB インスタンスのアップグレードのスタート時に、リードレプリカで別のマイナーバージョンのアップグレードが実行されていた。
+ リードレプリカで互換性のないパラメータを使用していた。
+ リードレプリカがプライマリ DB インスタンスと通信できず、データフォルダを同期できなかった。
1. **本番稼働用データベースのアップグレード** - リハーサルのメジャーバージョンアップグレードに成功すれば、自信を持って本番稼働用のプロダクションデータベースをアップグレードできます。詳細については、「[エンジンバージョンの手動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.Manual)」を参照してください。
1. `ANALYZE` 操作を実行して `pg_statistic` テーブルを更新します。これは、すべての PostgreSQL データベースのすべてのデータベースに対して行う必要があります。Optimizer の統計情報はメジャーバージョンのアップグレード中には転送されないため、パフォーマンスの問題を回避するためにすべての統計情報を再生成する必要があります。次のようにパラメータを指定せずにコマンドを実行して、現在のデータベース内のすべての標準テーブルの統計情報を生成します。
```
ANALYZE VERBOSE;
```
`VERBOSE` フラグはオプションですが、使用することで進行状況を表示できます。詳細については、「PostgreSQL ドキュメント」の「[ANALYZE](https://www.postgresql.org/docs/10/sql-analyze.html)」を参照してください。
ANALYZE VERBOSE を使用する代わりに特定のテーブルを分析する場合は、次のようにテーブルごとに ANALYZE コマンドを実行します。
```
ANALYZE table_name;
```
パーティションテーブルの場合は、常に親テーブルを分析します。このプロセスでは、以下の操作を行います。
+ すべてのパーティションにわたって行を自動的にサンプリングする
+ パーティションごとに統計を再帰的に更新する
+ 重要な計画統計を親レベルで維持する
親テーブルには実際のデータは保存されませんが、クエリの最適化には親テーブルの分析が不可欠です。個々のパーティションに対してのみ ANALYZE を実行すると、効率的なパーティション間計画に必要な包括的な統計をオプティマイザで利用できないため、クエリパフォーマンスが低下する可能性があります。
**注記**
パフォーマンスの問題を回避するため、アップグレード後にシステムで ANALYZE を実行してください。
メジャーバージョンのアップグレードが完了したら、次のことをお勧めします。
+ PostgreSQL アップグレードでは、PostgreSQL エクステンションはアップグレードされません。エクステンションをアップグレードするには、「[RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)」を参照してください。
+ オプションで、Amazon RDS を使用して、`pg_upgrade` ユーティリティによって作成される 2 つのログを表示できます。表示できるのは `pg_upgrade_internal.log` および `pg_upgrade_server.log` です。Amazon RDS では、これらのログのファイル名にタイムスタンプが追加されます。これらのログも、他のログと同様、表示できます。詳細については、「[Amazon RDS ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。
Amazon CloudWatch Logs にアップグレードログをアップロードすることもできます。詳細については、「[Amazon CloudWatch Logs への PostgreSQL ログの発行](USER_LogAccess.Concepts.PostgreSQL.md#USER_LogAccess.Concepts.PostgreSQL.PublishtoCloudWatchLogs)」を参照してください。
+ すべてが期待どおりに機能することを確認するには、同様のワークロードでアップグレードされたデータベースでアプリケーションをテストします。アップグレードが確認されたら、このテストインスタンスを削除できます。
# RDS for PostgreSQL のマイナーバージョンの自動アップグレード
DB インスタンスまたはマルチ AZ DB クラスターの作成時または変更時に、**[マイナーバージョン自動アップグレード]** を有効にした場合、データベースを自動的にアップグレードできます。
Amazon RDS は、複数のデータベースリソースと AWS アカウントにわたるマイナーバージョンの自動アップグレードを管理するためのアップグレードロールアウトポリシーもサポートしています。詳細については、「[自動マイナーバージョンアップグレードの AWS Organizations アップグレードロールアウトポリシーの使用](RDS.Maintenance.AMVU.UpgradeRollout.md)」を参照してください。
RDS for PostgreSQL の各メジャーバージョンでは、RDS によって 1 つのマイナーバージョンが自動アップグレードバージョンとして指定されます。Amazon RDS でマイナーバージョンのテストと承認が完了すると、メンテナンスウィンドウの間にマイナーバージョンアップグレードが自動的に行われます。RDS では、新しくリリースされたマイナーバージョンが自動アップグレードバージョンとして自動的に設定されることはありません。RDS によって新しい自動アップグレードバージョンが指定される前に、以下のような複数の基準が考慮されます。
+ 既知のセキュリティの問題
+ PostgreSQL コミュニティバージョンのバグ
+ マイナーバージョンがリリースされてからのフリート全体の安定性
次の AWS CLI コマンドを使用して、特定の AWS リージョン で指定された PostgreSQL マイナーバージョンの現在の自動マイナーアップグレードターゲットバージョンを確認できます。
Linux、macOS、Unix の場合:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version minor-version \
--region region \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output text
```
Windows の場合:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version minor-version ^
--region region ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output text
```
例えば、次の AWS CLI コマンドは、米国東部 (オハイオ) AWS リージョン (us-east-2) の PostgreSQL マイナーバージョン 16.1 の自動マイナーアップグレードターゲットを決定します。
Linux、macOS、Unix の場合:
```
aws rds describe-db-engine-versions \
--engine postgres \
--engine-version 16.1 \
--region us-east-2 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
--output table
```
Windows の場合:
```
aws rds describe-db-engine-versions ^
--engine postgres ^
--engine-version 16.1 ^
--region us-east-2 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^
--output table
```
以下のような出力が生成されます。
```
----------------------------------
| DescribeDBEngineVersions |
+--------------+-----------------+
| AutoUpgrade | EngineVersion |
+--------------+-----------------+
| False | 16.2 |
| True | 16.3 |
| False | 16.4 |
| False | 16.5 |
| False | 16.6 |
| False | 17.1 |
| False | 17.2 |
+--------------+-----------------+
```
この例では、`AutoUpgrade` 値は、`True` for PostgreSQL バージョン 16.3 です。したがって、自動マイナーアップグレードターゲットは PostgreSQL バージョン 16.3 であり、出力で強調表示されています。
PostgreSQL データベースは、以下の基準を満たしている場合、メンテナンスウィンドウの間に自動的にアップグレードされます。
+ データベースは、**[マイナーバージョン自動アップグレード]** オプションを有効にしています。
+ データベースでは、現在の自動アップグレードマイナーバージョン未満の DB エンジンのマイナーバージョンが実行されています。
詳細については、「[マイナーエンジンバージョンの自動アップグレード](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades)」を参照してください。
**注記**
PostgreSQL のアップグレードでは、PostgreSQL のエクステンションはアップグレードされません。エクステンションをアップグレードするには、「[RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード](USER_UpgradeDBInstance.PostgreSQL.ExtensionUpgrades.md)」を参照してください。
# RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード
PostgreSQL エンジンのアップグレードでは、PostgreSQL のほとんどのエクステンションはアップグレードされません。バージョンアップグレードの後にエクステンションを更新するには、`ALTER EXTENSION UPDATE` のコマンドを使用します。
**注記**
PostGIS 拡張機能の更新については、「[PostGIS 拡張機能を使用した空間データの管理](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) ([ステップ 6: PostGIS 拡張機能を更新する](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update))」を参照してください。
`pg_repack` 拡張機能を更新する場合、拡張機能をドロップしてアップグレードされたデータベースに新しいバージョンを作成します。詳細については、「`pg_repack` ドキュメント」の「[pg\$1repack installation](https://reorg.github.io/pg_repack/)」(pg\$1repack のインストール) を参照してください。
エクステンションをアップグレードするには、次のコマンドを使用します。
```
ALTER EXTENSION extension_name UPDATE TO 'new_version';
```
PostgreSQL エクステンションのサポートされているバージョンのリストについては、「[サポートされている PostgreSQL 拡張機能バージョン](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md)」を参照してください。
現在インストールされているエクステンションを一覧表示するには、次のコマンドで PostgreSQL の [pg\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) カタログを使用します。
```
SELECT * FROM pg_extension;
```
インストールで使用可能な特定の拡張機能バージョンのリストを表示するには、次のコマンドで PostgreSQL の [pg\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) ビューを使用します。
```
SELECT * FROM pg_available_extension_versions;
```
# イベントによる RDS for PostgreSQL エンジンのアップグレードのモニタリング
RDS for PostgreSQL データベースのエンジンバージョンをアップグレードすると、Amazon RDS はプロセスの各フェーズで特定のイベントを発行します。アップグレードの進行状況を追跡するには、これらのイベントを表示またはサブスクライブします。
RDS イベントの詳細については、「[Amazon RDS イベントのモニタリング](working-with-events.md)」を参照してください。
エンジンのアップグレード中に発生する特定の Amazon RDS イベントの詳細については、「[ Amazon RDS イベントカテゴリとイベントメッセージ](USER_Events.Messages.md)」を参照してください。
# PostgreSQL DB スナップショットエンジンのバージョンのアップグレード
Amazon RDS を使用すると、PostgreSQL DB インスタンスのストレージボリュームの DB スナップショットを作成できます。作成した DB スナップショットは Amazon RDS インスタンスが使用するエンジンバージョンに基づいています。DB スナップショットのエンジンバージョンをアップグレードできます。
新しいエンジンバージョンにアップグレードした DB スナップショットをリストアしたら、アップグレードに問題がないか必ずテストしてください。主なバージョンアップグレードの詳細は、[RDS for PostgreSQL DB エンジンのアップグレード](USER_UpgradeDBInstance.PostgreSQL.md) を参照してください。DB スナップショットをリストアする方法については [DB インスタンスへの復元](USER_RestoreFromSnapshot.md) をご覧ください。
暗号化されている場合またはされていない場合でも、マニュアル DB スナップショットをアップグレードすることができます。
RDS for PostgreSQL DB スナップショットで使用できるエンジンバージョンを表示するには、次の AWS CLI 例を使用します。
```
aws rds describe-db-engine-versions --engine postgres --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text --include-all
```
RDS for PostgreSQL DB スナップショットで使用できるエンジンバージョンの詳細については、「[RDS for PostgreSQL のメジャーバージョンアップグレードの選択](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)」を参照してください。
**注記**
自動バックアップ処理中に作成された自動 DB スナップショットをアップグレードすることはできません。
## コンソール
**DB スナップショットをアップグレードするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、「**Snapshots**」 を選択します。
1. アップグレードしたいスナップショットを選択します。
1. [**アクション**] は、[**スナップショットのアップグレード**] を選択します。[**スナップショットのアップグレード**] ページが表示されます。
1. アップグレードする [**新しいエンジンバージョン**] を選択します。
1. [**変更を保存**] を選択してスナップショットをアップグレードします。
アップグレード中は、この DB スナップショットに関するスナップショット操作が、すべて無効になります。また、DB スナップショットのステータスは**利用可能**から**アップグレード中**に変わり、プロセスが完了すると**有効**になります。スナップショットの破損問題で DB スナップショットをアップグレードできない場合、ステータスは**使用不可**になります。この状態からスナップショットを復元することはできません。
**注記**
DB スナップショットアップグレードが失敗した場合、スナップショットは元の状態にロールバックします。
## AWS CLI
DB スナップショットを新しいバージョンのデータベースエンジンにアップグレードするには、AWS CLI の [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html) コマンドを使用します。
**パラメータ**
+ `--db-snapshot-identifier` – アップグレードする DB スナップショットの識別子です。識別子は独自の Amazon リソースネーム (ARN) にしてください。詳細については、「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
+ `--engine-version` – DB スナップショットをこのエンジンバージョンにアップグレードする。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds modify-db-snapshot \
2. --db-snapshot-identifier my_db_snapshot \
3. --engine-version new_version
```
Windows の場合:
```
1. aws rds modify-db-snapshot ^
2. --db-snapshot-identifier my_db_snapshot ^
3. --engine-version new_version
```
## RDS API
DB スナップショットを新しいバージョンのデータベースエンジンにアップグレードするには、Amazon RDS API の [ModifyDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) オペレーションを呼び出します。
+ `DBSnapshotIdentifier` – アップグレードする DB スナップショットの識別子です。識別子は独自の Amazon リソースネーム (ARN) にしてください。詳細については、「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
+ `EngineVersion` – DB スナップショットをこのエンジンバージョンにアップグレードする。
# Amazon RDS for PostgreSQL でのリードレプリカの使用
リードレプリカをインスタンスに追加することによって、Amazon RDS for PostgreSQL DB インスタンスの読み取りをスケーリングできます。他の Amazon RDS データベースエンジンと同様、RDS for PostgreSQL は PostgreSQL のネイティブレプリケーションメカニズムを使用して、ソース DB の更新がリードレプリカに反映されるようにします。リードレプリカと Amazon RDS の概要については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
RDS for PostgreSQL でのリードレプリカの使用に関する特定の情報については、以下を参照してください。
## PostgreSQL でのリードレプリカの制限
PostgreSQL リードレプリカの制限は以下のとおりです。
+ PostgreSQL リードレプリカは読み取り専用です。リードレプリカは書き込み可能な DB インスタンスではありませんが、リードレプリカをスタンドアロンの RDS for PostgreSQL DB インスタンスに昇格させることができます。ただし、このプロセスを元に戻すことはできません。
+ RDS for PostgreSQL DB インスタンスで、14.1 より前のバージョンの PostgreSQL が実行されている場合、別のリードレプリカからリードレプリカを作成することはできません。RDS for PostgreSQL でカスケードリードレプリカがサポートされているのは、RDS for PostgreSQL バージョン 14.1 以降のリリースのみです。詳細については、「[RDS for PostgreSQL でのカスケードリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md)」を参照してください。
+ PostgreSQL リードレプリカを昇格させると、書き込み可能な DB インスタンスになります。これにより、ソース DB インスタンスからの先書きログ (WAL) ファイルの受信が停止し、読み取り専用インスタンスではなくなります。RDS for PostgreSQL DB インスタンスと同様に、昇格した DB インスタンスから新しいリードレプリカを作成できます。詳細については、「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」を参照してください。
+ レプリケーションチェーン内 (一連のカスケードリードレプリカ) から PostgreSQL リードレプリカを昇格させると、既存のダウンストリームリードレプリカは、昇格したインスタンスから WAL ファイルを自動的に受信し続けます。詳細については、「[RDS for PostgreSQL でのカスケードリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md)」を参照してください。
+ ソース DB インスタンスでユーザートランザクションが実行されていない場合、関連付けられた PostgreSQL リードレプリカは、最長 5 分のレプリケーションの遅延を報告します。レプリカラグは `currentTime - lastCommitedTransactionTimestamp` として計算され、トランザクションが処理されていない場合、先書きログ (WAL) セグメントが切り替わるまでの一定期間、レプリカラグの値が増加することを意味します。デフォルトでは、RDS for PostgreSQL は 5 分ごとに WAL セグメントを切り替えます。これにより、トランザクションレコードが生成され、報告されるラグが減少します。
+ RDS for PostgreSQL 14.1 より前のバージョンの PostgreSQL リードレプリカでは、自動バックアップをオンにすることはできません。リードレプリカの自動バックアップは、RDS for PostgreSQL 14.1 以降のバージョンでのみサポートされます。RDS for PostgreSQL 13 以前のバージョンでバックアップが必要な場合は、リードレプリカのスナップショットを作成します。
+ リードレプリカでは、ポイントインタイムリカバリ (PITR) はサポートされません。PITR は、リードレプリカではなく、プライマリ (ライター) インスタンスでのみ使用できます。詳細については[Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md)を参照してください。
+ PostgreSQL バージョン 12 以前のリードレプリカは、60～90 日間のメンテナンスウィンドウ中に自動的に再起動し、パスワードのローテーションを適用します。スケジュールされた再起動前にレプリカからソースへの接続が切断された場合も、再起動してレプリケーションを再開します。PostgreSQL バージョン 13 以降では、パスワードのローテーションプロセス中にリードレプリカでレプリケーションの切断と再接続が短時間発生する場合があります。
# PostgreSQL でのリードレプリカの設定
RDS for PostgreSQL では、PostgreSQL ネイティブストリーミングレプリケーションを使用して、ソース DB インスタンスの読み取り専用コピーを作成します。このリードレプリカ DB インスタンスは、非同期的に作成されたソース DB インスタンスの物理レプリカです。これは、先書きログ (WAL) のデータをソース DB インスタンスからリードレプリカに送信する特別な接続によって作成されます。詳細については、PostgreSQL ドキュメントの「[Streaming Replication](https://www.postgresql.org/docs/14/warm-standby.html#STREAMING-REPLICATION)」(ストリーミングレプリケーション) を参照してください。
ソース DB インスタンスでデータベースの変更が行われた場合、PostgreSQL は、非同期的に安全な接続に変更をストリーミングします。クライアントアプリケーションからソース DB インスタンスまたはリードレプリカへの通信を暗号化するには、`ssl` パラメータを `1` に設定します。詳細については、「[PostgreSQL DB インスタンスで SSL を使用する](PostgreSQL.Concepts.General.SSL.md)」を参照してください。
PostgreSQL は*レプリケーション*ロールを使用して、ストリーミングレプリケーションを実行します。このロールには特権がありますが、データの変更には使用できません。PostgreSQL ではレプリケーション処理に 1 つのプロセスを使用します。
ソース DB インスタンスのオペレーションとユーザーに影響を与えることなく、PostgreSQL リードレプリカを作成できます。Amazon RDS では、サービスに影響を与えることなく、ソース DB インスタンスとリードレプリカに必要なパラメータとアクセス許可を設定できます。ソース DB インスタンスのスナップショットが取得され、このスナップショットを使用してリードレプリカが作成されます。将来のある時点でリードレプリカを削除しても、停止は発生しません。
同一リージョン内の 1 つの ソース DB インスタンスから、最大 15 個のリードレプリカを作成できます。さらに、RDS for PostgreSQL 14.1 以降では、ソース DB インスタンスから最大 3 層のリードレプリカのチェーン (カスケード) を作成することもできます。詳細については、「[RDS for PostgreSQL でのカスケードリードレプリカの使用](USER_PostgreSQL.Replication.ReadReplicas.Cascading.md)」を参照してください。いずれの場合も、ソース DB インスタンスで自動バックアップを設定する必要があります。これを行うには、DB インスタンスのバックアップ保持期間を 0 以外の値に設定します。詳細については、「[リードレプリカの作成](USER_ReadRepl.Create.md)」を参照してください。
RDS for PostgreSQL DB インスタンス用のリードレプリカをソース DB インスタンスとして同じ AWS リージョン 内に作成できます。これは、*リージョン内*レプリケーションと呼ばれます。また、ソース DB インスタンスと異なる AWS リージョン にリードレプリカを作成することもできます。これは、*クロスリージョン*レプリケーションと呼ばれます。クロスリージョンリードレプリカの設定に関する詳細は、「[別の でのリードレプリカの作成AWS リージョン](USER_ReadRepl.XRgn.md)」を参照してください。「[RDS for PostgreSQL のバージョンが異なる場合のストリーミングレプリケーションの仕組み](USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.md)」で説明されているように、リージョン内およびクロスリージョンのレプリケーションプロセスをサポートするさまざまなメカニズムは、RDS for PostgreSQL のバージョンによって若干異なります。
レプリケーションを効率的に実行するには、各リードレプリカにソース DB インスタンスと同程度のコンピューティングリソースとストレージリソースが必要です。ソース DB インスタンスをスケールした場合は、リードレプリカもスケールする必要があります。
互換性のないパラメータがあり、それが原因でリードレプリカを起動できない場合、Amazon RDS によってリードレプリカのパラメータ値が上書きされます。例えば、リードレプリカよりもソース DB インスタンスの方が `max_connections` パラメータ値が高いとします。この場合は、Amazon RDS によって、リードレプリカのパラメータがソース DB インスタンスのパラメータと同じ値になるように更新されます。
RDS for PostgreSQL リードレプリカは、ソース DB インスタンスの外部データラッパー (FDW) を介して利用可能な外部データベースにアクセスできます。例えば、RDS for PostgreSQL DB インスタンスで、`mysql_fdw` ラッパーを使用して RDS for MySQL のデータにアクセスするとします。その場合、リードレプリカはそのデータにもアクセスできます。サポートされているその他の FDW には、`oracle_fdw`、`postgres_fdw`、および `tds_fdw` があります。詳細については、「[Amazon RDS for PostgreSQL でサポートされている外部データラッパーを使用する](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md)」を参照してください。
## マルチ AZ 構成で RDS for PostgreSQL リードレプリカを使用する
リードレプリカは、シングル AZ DB インスタンスから、またはマルチ AZ DB インスタンスから作成できます。重要なデータの耐久性と可用性を高めるために、1 つのスタンバイレプリカを備えたマルチ AZ 配置を使用できます。*スタンバイレプリカ*は、ソース DB がフェイルオーバーした場合にワークロードを引き受けることができる専用のリードレプリカです。スタンバイレプリカを使用して読み取りトラフィックを処理することはできません。ただし、トラフィックの多いマルチ AZ DB インスタンスのリードレプリカを作成して、読み取り専用クエリをオフロードできます。マルチ AZ 配置についての詳細は、「[Amazon RDS のマルチ AZ DB インスタンスデプロイ](Concepts.MultiAZSingleStandby.md)」を参照してください。
マルチ AZ 配置のソース DB インスタンスがスタンバイにフェイルオーバーすると、関連付けられているリードレプリカがスタンバイ (現在はプライマリ) をレプリケーションのソースとして使用するよう切り替わります。以下のように、RDS for PostgreSQL のバージョンによっては、リードレプリカの再起動が必要になる場合があります。
+ **PostgreSQL 13 以降のバージョン** – 再起動は必要ありません。リードレプリカは、新しいプライマリと自動的に同期されます。ただし、場合によっては、クライアントアプリケーションがリードレプリカのドメインネームサービス (DNS) の詳細をキャッシュすることがあります。その場合は、有効期限 (TTL) 値を 30 秒未満に設定します。これにより、リードレプリカは古い IP アドレスを保持できなくなります (したがって、新しいプライマリと同期されません)。このベストプラクティスおよびその他のベストプラクティスの詳細については、「[Amazon RDS の基本的な操作のガイドライン](CHAP_BestPractices.md#CHAP_BestPractices.DiskPerformance)」を参照してください。
+ **PostgreSQL 12 およびそれ以前のすべてのバージョン** – スタンバイレプリカにフェイルオーバーした後にリードレプリカが自動的に再起動します。スタンバイ (現在のプライマリ) の IP アドレスとインスタンス名が異なるためです。再起動すると、リードレプリカが新しいプライマリと同期されます。
フェイルオーバーの詳細については、「[Amazon RDS 用のマルチ AZ DB インスタンスのフェイルオーバー](Concepts.MultiAZ.Failover.md)」を参照してください。リードレプリカがマルチ AZ 配置でどのように機能するかについての詳細は、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
リードレプリカのフェイルオーバーをサポートするため、リードレプリカをマルチ AZ DB インスタンスとして作成できます。これにより、Amazon RDS は、別のアベイラビリティーゾーン (AZ) にレプリカのスタンバイを作成できます。リードレプリカは、ソースのデータベースがマルチ AZ DB インスタンスであるかどうかに関係なく、マルチ AZ DB インスタンスとして作成できます。
# リードレプリカの論理デコード
RDS for PostgreSQL は、PostgreSQL 16.1 を使用したスタンバイからの論理レプリケーションをサポートしています。これにより、読み取り専用スタンバイから論理デコードを作成し、プライマリ DB インスタンスの負荷を軽減できます。複数のシステム間でデータを同期する必要があるアプリケーションで可用性を高めることができます。この機能により、データウェアハウスとデータ分析のパフォーマンスが向上します。
また、特定のスタンバイのレプリケーションスロットは、そのスタンバイのプライマリへの昇格を保持します。つまり、プライマリ DB インスタンスのフェイルオーバーやスタンバイから新しいプライマリへの昇格の際にも、レプリケーションスロットは保持され、以前のスタンバイサブスクライバーには影響しません。
**リードレプリカに論理デコードを作成するには**
1. **論理レプリケーションを有効にする** – スタンバイで論理デコードを作成するには、ソース DB インスタンスとその物理レプリカで論理レプリケーションを有効にする必要があります。詳細については、「[PostgreSQL でのリードレプリカの設定](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md)」を参照してください。
+ **新しく作成された RDS for PostgreSQL DB インスタンスの論理レプリケーションを有効にするには** – 新しい DB カスタムパラメータグループを作成し、静的パラメータ `rds.logical_replication` を `1` に設定します。次に、この DB パラメータグループをソース DB インスタンスとその物理リードレプリカに関連付けます。詳細については、「[Amazon RDS で DB パラメータグループを DB インスタンスに関連付ける](USER_WorkingWithParamGroups.Associating.md)」を参照してください。
+ **既存の RDS for PostgreSQL DB インスタンスの論理レプリケーションを有効にするには** — ソース DB インスタンスとその物理リードレプリカの DB カスタムパラメータグループを変更して、静的パラメータ `rds.logical_replication` を `1` に設定します。詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
**注記**
これらのパラメータの変更を適用するには、DB インスタンスを再起動する必要があります。
次のクエリを使用して、ソース DB インスタンスとその物理リードレプリカの `wal_level` および `rds.logical_replication` の値を確認できます。
```
Postgres=>SELECT name,setting FROM pg_settings WHERE name IN ('wal_level','rds.logical_replication');
name | setting
-------------------------+---------
rds.logical_replication | on
wal_level | logical
(2 rows)
```
1. **ソースデータベースにテーブルを作成する** – ソース DB インスタンスのデータベースに接続します。詳細については、「[PostgreSQL データベースエンジンを実行する DB インスタンスへの接続](USER_ConnectToPostgreSQLInstance.md)」を参照してください。
次のクエリを使用して、ソースデータベースにテーブルを作成し、値を挿入します。
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
```
Postgres=>INSERT INTO LR_test VALUES (generate_series(1,10000));
INSERT 0 10000
```
1. **ソーステーブルのパブリケーションを作成する** – 次のクエリを使用して、ソース DB インスタンスにテーブルのパブリケーションを作成します。
```
Postgres=>CREATE PUBLICATION testpub FOR TABLE LR_test;
CREATE PUBLICATION
```
SELECT クエリを使用して、ソース DB インスタンスと物理リードレプリカインスタンスの両方で作成されたパブリケーションの詳細を確認します。
```
Postgres=>SELECT * from pg_publication;
oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot
-------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------
16429 | testpub | 16413 | f | t | t | t | t | f
(1 row)
```
1. **論理レプリカインスタンスからサブスクリプションを作成する** – 論理レプリカインスタンスとして別の RDS for PostgreSQL DB インスタンスを作成します。この論理レプリカインスタンスが物理リードレプリカインスタンスにアクセスできるように、VPC が正しく設定されていることを確認します。詳細については、「[Amazon VPC と Amazon RDS](USER_VPC.md)」を参照してください。ソース DB インスタンスがアイドル状態の場合、接続の問題が発生し、プライマリがデータをスタンバイに送信しない可能性があります。
```
Postgres=>CREATE SUBSCRIPTION testsub CONNECTION 'host=Physical replica host name port=port
dbname=source_db_name user=user password=password' PUBLICATION testpub;
NOTICE: created replication slot "testsub" on publisher
CREATE SUBSCRIPTION
```
```
Postgres=>CREATE TABLE LR_test (a int PRIMARY KEY);
CREATE TABLE
```
SELECT クエリを使用して、論理レプリカインスタンスのサブスクリプションの詳細を確認します。
```
Postgres=>SELECT oid,subname,subenabled,subslotname,subpublications FROM pg_subscription;
oid | subname | subenabled | subslotname | subpublications
-------+---------+------------+-------------+-----------------
16429 | testsub | t | testsub | {testpub}
(1 row)
postgres=> select count(*) from LR_test;
count
-------
10000
(1 row)
```
1. **論理レプリケーションスロットの状態を確認する** – ソース DB インスタンスの物理レプリケーションスロットのみを表示できます。
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
---------------------------------------------+-----------+---------------------
rds_us_west_2_db_dhqfsmo5wbbjqrn3m6b6ivdhu4 | physical |
(1 row)
```
ただし、リードレプリカインスタンスでは、アプリケーションが論理変更をアクティブに消費すると、論理レプリケーションスロットと `confirmed_flush_lsn` 値の変化を確認できます。
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/500002F0
(1 row)
```
```
Postgres=>select slot_name, slot_type, confirmed_flush_lsn from pg_replication_slots;
slot_name | slot_type | confirmed_flush_lsn
-----------+-----------+---------------------
testsub | logical | 0/5413F5C0
(1 row)
```
# RDS for PostgreSQL でのカスケードリードレプリカの使用
バージョン 14.1 以降の RDS for PostgreSQL では、カスケードリードレプリカがサポートされています。*カスケードリードレプリカ*により、ソースの RDS for PostgreSQL DB インスタンスにオーバーヘッドを追加せずに読み取りをスケーリングできます。ソース DB インスタンスでは、WAL ログへの更新が各リードレプリカに送信されません。代わりに、カスケード層内の各リードレプリカは、その層内の次のリードレプリカに WAL ログの更新を送信します。これにより、ソース DB インスタンスへの負荷が軽減されます。
カスケードリードレプリカを使用すると、RDS for PostgreSQL DB インスタンスは、チェーン内の最初のリードレプリカに WAL データを送信します。その後、そのリードレプリカは、チェーン内の 2 番目のレプリカに WAL データを送信し、その動作が順に続いていきます。その結果、チェーン内のすべてのリードレプリカに RDS for PostgreSQL DB インスタンスの更新が送信されますが、ソース DB インスタンスでのオーバーヘッドは発生しません。
ソースの RDS for PostgreSQL DB インスタンスから、チェーン内にリードレプリカを 3 層まで作成することができます。例えば、RDS for PostgreSQL 14.1 DB インスタンス、`rpg-db-main` があるとします。以下の操作を行うことができます。
+ `rpg-db-main` で開始し、チェーン内に最初のリードレプリカ、`read-replica-1` を作成します。
+ 次に、`read-replica-1` で、チェーン内に次のリードレプリカ、`read-replica-2` を作成します。
+ 最後に、`read-replica-2` で、チェーン内に 3 番目のリードレプリカ、`read-replica-3` を作成します。
`rpg-db-main` の層では、この 3 番目のカスケードリードレプリカに続く、別のリードレプリカを作成することはできません。一連の完全なインスタンス (RDS for PostgreSQL のソース DB インスタンスから、この層の最後のカスケードリードレプリカまで) は、最大 4 つの DB インスタンスで構成できます。
カスケードリードレプリカを設定するには、RDS for PostgreSQL で自動バックアップを有効にします。まずリードレプリカを作成し、RDS for PostgreSQL DB インスタンスで自動バックアップを有効にします。このプロセスは、他の Amazon RDS DB エンジンと同じです。詳細については、「[リードレプリカの作成](USER_ReadRepl.Create.md)」を参照してください。
他のリードレプリカと同様に、カスケードの一部となっているリードレプリカを昇格できます。リードレプリカのチェーン内でリードレプリカを昇格させると、そのレプリカはチェーンから削除されます。例えば、`rpg-db-main` DB インスタンスのワークロードの一部を新しいインスタンスに移動するとします。この新しいインスタンスは経理部でのみ使用します。この例では、3 つのリードレプリカから成るチェーンがある仮定し、`read-replica-2` を昇格させることにします。チェーンは以下のような影響を受けます。
+ 昇格する `read-replica-2` は、レプリケーションチェーンから削除されます。
+ このリードレプリカは、完全な読み取り/書き込み DB インスタンスになります。
+ 昇格前と同じように、`read-replica-3` へのレプリケーションを継続します。
+ `rpg-db-main` は、`read-replica-1` へのレプリケーションを継続します。
リードレプリカの昇格についての詳細は、「[リードレプリカをスタンドアロン DB インスタンスに昇格させる](USER_ReadRepl.Promote.md)」を参照してください。
**注記**
RDS for PostgreSQL は、カスケードレプリカのメジャーバージョンアップグレードをサポートしていません。メジャーバージョンアップグレードを実行する前に、カスケードレプリカを削除する必要があります。ソース DB インスタンスと第 1 レベルのレプリカのアップグレードが完了したら、再作成できます。
カスケードリードレプリカの場合、RDS for PostgreSQL は、レプリケーションの第 1 レベルではソース DB インスタンスごとに 15 個のリードレプリカを、レプリケーションの第 2 レベルと 第 3 レベルではソース DB インスタンスごとに 5 個のリードレプリカをサポートします。
# RDS for PostgreSQL を使用したクロスリージョンカスケーディングリードレプリカの作成
RDS for PostgreSQL は、クロスリージョンカスケーディングリードレプリカをサポートします。ソース DB インスタンスからクロスリージョンレプリカを作成し、そこから同じリージョンレプリカを作成できます。ソース DB インスタンスから同じリージョンレプリカを作成し、そこからクロスリージョンレプリカを作成することもできます。
**クロスリージョンレプリカを作成してから、同じリージョンレプリカを作成する**
バージョン 14.1 以降 (`rpg-db-main`) の RDS for PostgreSQL DB インスタンス を使用して、以下を実行できます。
1. `rpg-db-main` (US-EAST-1) で開始し、チェーンに最初のクロスリージョンリードレプリカ `read-replica-1` (US-WEST-2) を作成します。
1. 最初のクロスリージョン `read-replica-1` (US-WEST-2) を使用して、チェーンに 2 番目のリードレプリカ `read-replica-2` (US-WEST-2) を作成します。
1. `read-replica-2` を使用して、チェーンに 3 番目のリードレプリカ `read-replica-3` (US-WEST-2) を作成します。
**同じリージョンレプリカを作成してから、クロスリージョンレプリカを作成する**
バージョン 14.1 以降 (`rpg-db-main`) の RDS for PostgreSQL DB インスタンス を使用して、以下を実行できます。
1. `rpg-db-main` (US-EAST-1) で開始し、チェーンに最初のリードレプリカ `read-replica-1` (US-EAST-1) を作成します。
1. `read-replica-1` (US-EAST-1) を使用して、チェーンに最初のクロスリージョンリードレプリカ `read-replica-2` (US-WEST-2) を作成します。
1. `read-replica-2` (US-WEST-2) を使用して、チェーンに 3 番目のリードレプリカ `read-replica-3` (US-WEST-2) を作成します。
**クロスリージョンリードレプリカの作成に関する制限事項**
+ データベースレプリカのクロスリージョンカスケーディングチェーンは、最大 2 つのリージョンにまたがることができ、最大 4 つのレベルがあります。4 つのレベルには、1 つのデータベースソースと 3 つのリードレプリカが含まれます。
**カスケーディングリードレプリカを使用する利点**
+ 読み取りスケーラビリティの向上 – 読み取りクエリを複数のレプリカに分散することで、カスケーディングレプリケーションは負荷均衡に役立ちます。これにより、ライターデータベースの負荷を軽減することで、特に読み取り負荷の高いアプリケーションのパフォーマンスが向上します。
+ 地理的分散 — カスケーディングレプリカは、異なる地理的場所に配置できます。これにより、プライマリデータベースから離れた場所にあるユーザーのレイテンシーが軽減され、ローカルリードレプリカが提供され、パフォーマンスとユーザーエクスペリエンスが向上します。
+ 高可用性とディザスタリカバリ — プライマリサーバーに障害が発生した場合、レプリカをプライマリに昇格させ、継続性を確保できます。カスケーディングレプリケーションは、複数のフェイルオーバーオプションを提供し、システムの全体的な耐障害性を向上させることで、これをさらに強化します。
+ 柔軟性とモジュール式の成長 — システムが成長するにつれて、プライマリデータベースの大規模な再設定を行わずに、新しいレプリカをさまざまなレベルで追加できます。このモジュール方式により、レプリケーション設定をスケーラブルかつ管理しやすい方法で拡張できます。
**クロスリージョンリードレプリカを使用するためのベストプラクティス**
+ レプリカを昇格させる前に、追加のレプリカを作成します。これにより、時間を節約し、ワークロードを効率的に処理できます。
# RDS for PostgreSQL のバージョンが異なる場合のストリーミングレプリケーションの仕組み
「[PostgreSQL でのリードレプリカの設定](USER_PostgreSQL.Replication.ReadReplicas.Configuration.md)」で説明したとおり、RDS for PostgreSQL は PostgreSQL のネイティブストリーミングレプリケーションプロトコルを使用して、ソース DB インスタンスから WAL データを送信します。リージョン内とクロスリージョンの両方のリードレプリカにソース WAL データを送信します。バージョン 9.4 では、レプリケーションプロセスのサポートメカニズムとして、PostgreSQL に物理レプリケーションスロットが導入されました。
*物理レプリケーションスロット*は、WAL データがすべてのリードレプリカで消費される前に、ソース DB インスタンスによってデータが削除されることを防ぎます。各リードレプリカは、ソース DB インスタンスに独自の物理スロットを持ちます。このスロットは、レプリカが必要とする可能性のある最も古い WAL (論理シーケンス番号、LSN) を追跡します。すべてのスロットと DB との接続が指定した WAL (LSN) を超過して進行すると、その LSN は次のチェックポイントで削除候補になります。
Amazon RDS は、Amazon S3 を使用して WAL データをアーカイブします。リージョン内リードレプリカの場合は、必要に応じて、このアーカイブされたデータを使用してリードレプリカを復旧できます。その例として、何らかの理由でソース DB とリードレプリカ間の接続が中断された場合が挙げられます。
次の表は、PostgreSQL のバージョンの相違点と、RDS for PostgreSQL で使用されるリージョン内およびクロスリージョンのサポートメカニズムの相違点の概要です。
| バージョン | リージョン内 | クロスリージョン |
| --- | --- | --- |
| PostgreSQL 14.1 以降のバージョン | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
| PostgreSQL 13 以前のバージョン | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Replication.ReadReplicas.Mechanisms-versions.html) |
詳細については、「[レプリケーションプロセスのモニタリングとチューニング](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md)」を参照してください。
## PostgreSQL レプリケーションを制御するパラメータについて
以下のパラメータはレプリケーションプロセスに影響を与えます。また、リードレプリカがソース DB インスタンスの更新をどの程度反映するかを決定します。
**max\$1wal\$1senders**
`max_wal_senders` パラメータは、ストリーミングレプリケーションプロトコルに対して、ソース DB インスタンスが同時にサポートできる接続の最大数を指定します。
デフォルト値は RDS for PostgreSQL バージョンによって異なります。
+ バージョン 13、14、15 の場合、デフォルト値は 20 です。
+ バージョン 16 以降では、デフォルト値は 35 です。
このパラメータは、実際のリードレプリカの数よりわずかに大きな値に設定する必要があります。リードレプリカの数に対してこのパラメータの設定が低すぎる場合は、レプリケーションが停止します。
詳細については、PostgreSQL のドキュメントの「[max\$1wal\$1senders](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-WAL-SENDERS)」セクションを参照してください。
`max_wal_senders` パラメータは静的であるため、変更を有効にするには、DB インスタンスを再起動する必要があります。
**wal\$1keep\$1segments**
`wal_keep_segments` パラメータは、ソース DB インスタンスが `pg_wal` ディレクトリで保持する先書きログ (WAL) ファイルの数を指定します。デフォルトの設定は 32 です。
`wal_keep_segments` がデプロイで十分な大きさの値に設定されていない場合、リードレプリカでのストリーミングに大幅な遅延が発生し、レプリケーションが停止します。その場合、Amazon RDS でレプリケーションエラーが報告され、リードレプリカで復旧が開始されます。これは、ソース DB インスタンスのアーカイブされた WAL データを Amazon S3 で再生することによって行われます。この復旧プロセスは、レプリケーションのストリーミングを続行するのに十分なだけリードレプリカの遅延が解消されるまで続きます。このプロセスを PostgreSQL ログがキャプチャしている様子については、「[例: リードレプリカがレプリケーションの中断から復旧する方法例: リードレプリカのレプリケーションの中断からの復旧](#USER_PostgreSQL.Replication.example-how-it-works)」で確認できます。
PostgreSQL バージョン 13 では、`wal_keep_segments` パラメータの名前は `wal_keep_size` です。このパラメータも `wal_keep_segments` と同じ目的を果たしますが、デフォルト値は、ファイル数ではなくメガバイト (MB) (2048 MB) です。詳細については、PostgreSQL ドキュメントの「[wal\$1keep\$1segments](https://www.postgresql.org/docs/12/runtime-config-replication.html#GUC-WAL-KEEP-SEGMENTS)」と「[wal\$1keep\$1size](https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE)」を参照してください。
**max\$1slot\$1wal\$1keep\$1size**
`max_slot_wal_keep_size` パラメータは、RDS for PostgreSQL DB インスタンスが `pg_wal` ディレクトリで保持する WAL データの量を制御して、スロットを提供します。このパラメータは、レプリケーションスロットを使用する構成に使用されます。このパラメータのデフォルト値は `-1` です。つまり、ソース DB インスタンスに保持される WAL データの量は無制限です。レプリケーションスロットのモニタリングについては、「[RDS for PostgreSQL DB インスタンスのレプリケーションスロットのモニタリング](USER_PostgreSQL.Replication.ReadReplicas.Monitor.md#USER_PostgreSQL.Replication.ReadReplicas.Monitor-monitor-replication-slots)」を参照してください。
このパラメータの詳細については、PostgreSQL ドキュメントの「[max\$1slot\$1wal\$1keep\$1size](https://www.postgresql.org/docs/devel/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE)」を参照してください。
リードレプリカに WAL データを提供するストリームが中断した場合、PostgreSQL は復旧モードに切り替わります。リードレプリカの復元は、Amazon S3 のアーカイブ済み WAL データを使用するか、レプリケーションスロットに関連付けられている WAL データを使用して行われます。このプロセスが完了すると、PostgreSQL でストリーミングレプリケーションが再構築されます。
### 例: リードレプリカがレプリケーションの中断から復旧する方法
次の例では、リードレプリカの復旧プロセスを示すログの詳細を示します。この例は、同じ AWS リージョンで PostgreSQL バージョン 12.9 をソース DB として実行している RDS for PostgreSQL DB インスタンスの例です。そのため、レプリケーションスロットは使用されません。復旧プロセスは、リージョン内リードレプリカでバージョン 14.1 より前の PostgreSQL を実行している他の RDS for PostgreSQL DB インスタンスでも同じです。
リードレプリカがソース DB インスタンスとの接続を失った場合、Amazon RDS は問題を `FATAL: could not receive data from WAL stream` メッセージとして `ERROR: requested WAL segment ... has already been removed` とともにログに記録します。太字の行は、アーカイブされた WAL ファイルを再生することで Amazon RDS によりレプリカが復旧されたことを示しています。
```
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: switched WAL source from archive to stream after failure
2014-11-07 19:01:10 UTC::@:[11575]:LOG: started streaming WAL from primary at 1A/D3000000 on timeline 1
2014-11-07 19:01:10 UTC::@:[11575]:FATAL: could not receive data from WAL stream:
ERROR: requested WAL segment 000000010000001A000000D3 has already been removed
2014-11-07 19:01:10 UTC::@:[23180]:DEBUG: could not restore file "00000002.history" from archive: return code 0
2014-11-07 19:01:15 UTC::@:[23180]:DEBUG: switched WAL source from stream to archive after failure recovering 000000010000001A000000D3
2014-11-07 19:01:16 UTC::@:[23180]:LOG: restored log file "000000010000001A000000D3" from archive
```
Amazon RDS がレプリカで遅延を解消するのに十分な、アーカイブされた WAL データを再生すると、リードレプリカへのストリーミングが再開されます。ストリーミングが再開されると、Amazon RDS によって次のようなエントリがログファイルに書き込まれます。
```
2014-11-07 19:41:36 UTC::@:[24714]:LOG:started streaming WAL from primary at 1B/B6000000 on timeline 1
```
## 共有メモリを制御するパラメータの設定
設定したパラメータによって、トランザクション ID、ロック、準備済みトランザクションを追跡するための共有メモリのサイズが決まります。**スタンバイインスタンスの共有メモリ構造は、プライマリインスタンスの共有メモリ構造と同じかそれ以上でなければなりません。**これにより、リカバリ中に前者の共有メモリが不足することがなくなります。レプリカのパラメータ値がプライマリのパラメータ値よりも小さい場合、Amazon RDS はレプリカのパラメータを自動的に調整し、エンジンを再起動します。
影響を受けるパラメータは以下のとおりです。
+ max\$1connections
+ max\$1worker\$1processes
+ max\$1wal\$1senders
+ max\$1prepared\$1transactions
+ max\$1locks\$1per\$1transaction
メモリ不足が原因でレプリカが RDS で再起動されるのを防ぐため、パラメータの変更を各レプリカにローリング再起動として適用することをお勧めします。パラメータ設定時には、次のルールを適用する必要があります。
+ **パラメータ値を増やす:**
+ 必ず最初にすべてのリードレプリカのパラメータ値を増やし、すべてのレプリカのローリングリブートを実行する必要があります。次に、パラメータの変更をプライマリインスタンスに適用し、再起動します。
+ **パラメータ値を減らす:**
+ まず、プライマリインスタンスのパラメータ値を減らし、再起動する必要があります。次に、パラメータの変更を関連するすべてのリードレプリカに適用し、ローリングリブートを実行します。
# レプリケーションプロセスのモニタリングとチューニング
RDS for PostgreSQL DB インスタンスとリードレプリカを定期的にモニタリングすることを強くお勧めします。リードレプリカがソース DB インスタンスの変更に対応していることを確認する必要があります。Amazon RDS では、レプリケーションプロセスで中断が発生した場合に、リードレプリカを透過的に復旧できます。ただし、最善なのは、復旧の必要性を最初から避けることです。レプリケーションスロットを使用した復旧は、Amazon S3 アーカイブを使用するよりも高速ですが、復旧プロセスは読み取りパフォーマンスに影響する可能性があります。
リードレプリカが最新のソース DB インスタンスにどの程度対応しているかを判断するには、次の操作を行います。
+ **ソース DB インスタンスとレプリカ間の `ReplicaLag` の量を確認する。***レプリカ遅延*は、ソース DB インスタンスに対するリードレプリカの遅延時間 (秒単位) です。このメトリクスは、次のクエリの結果を返します。
```
SELECT extract(epoch from now() - pg_last_xact_replay_timestamp()) AS "ReplicaLag";
```
レプリカ遅延は、リードレプリカがソース DB インスタンスの変更をどの程度反映しているかを示します。これは、ソース DB インスタンスと特定のリードインスタンス間のレイテンシーの量です。レプリカ遅延の値が大きい場合は、ソース DB インスタンスとそのリードレプリカで使用される DB インスタンスクラスまたはストレージタイプ (またはその両方) の不一致を示している可能性があります。DB ソースインスタンスとすべてのリードレプリカの DB インスタンスクラスとストレージタイプは同じである必要があります。
レプリカ遅延は、断続的な接続問題の結果でもあります。Amazon CloudWatch のレプリケーションのラグをモニタリングするには、Amazon RDS `ReplicaLag` メトリクスを表示します。`ReplicaLag` についての詳細および Amazon RDS のその他のメトリクスについては、「[Amazon RDS の Amazon CloudWatch メトリクス](rds-metrics.md)」を参照してください。
+ **PostgreSQL ログで、設定を調整するために使用できる情報を確認する。**次の例に示すように、PostgreSQL ログでは、すべてのチェックポイントで、リサイクルされるトランザクションログファイルの数がキャプチャされます。
```
2014-11-07 19:59:35 UTC::@:[26820]:LOG: checkpoint complete: wrote 376 buffers (0.2%);
0 transaction log file(s) added, 0 removed, 1 recycled; write=35.681 s, sync=0.013 s, total=35.703 s;
sync files=10, longest=0.013 s, average=0.001 s
```
この情報を使用して、指定された期間にリサイクルされるトランザクションファイルの数を把握できます。必要に応じて、`wal_keep_segments` の設定を変更できます。例えば、`checkpoint complete` の PostgreSQL ログが 5 分間隔で `35 recycled` を表示するとします。この場合、`wal_keep_segments` のデフォルト値 32 では、ストリーミングアクティビティのペースを維持するには不十分です。そのため、このパラメータの値を大きくする必要があります。
+ **Amazon CloudWatch を使用して、レプリケーションの問題を予測できるメトリクスをモニタリングする。**PostgreSQL ログを直接分析する代わりに、Amazon CloudWatch を使用することで、収集されたメトリクスを確認できます。例えば、`TransactionLogsGeneration` メトリクスの値を確認すると、ソース DB インスタンスによって生成されている WAL データの量を把握できます。場合によっては、DB インスタンスのワークロードによって大量の WAL データが生成されることがあります。その場合、ソース DB インスタンスとリードレプリカの DB インスタンスクラスを変更する必要があります。高いネットワークパフォーマンス (10 Gbps) のインスタンスクラスを使用すると、レプリカの遅延を低減することができます。
## RDS for PostgreSQL DB インスタンスのレプリケーションスロットのモニタリング
RDS for PostgreSQL のすべてのバージョンでは、クロスリージョンのリードレプリカにレプリケーションスロットを使用します。RDS for PostgreSQL 14.1 以降のバージョンでは、リージョン内のリードレプリカにレプリケーションスロットを使用します。リージョン内のリードレプリカは、Amazon S3 を使用して WAL データをアーカイブします。つまり、DB インスタンスとリードレプリカが PostgreSQL 14.1 以降を実行している場合、レプリケーションスロットと Amazon S3 アーカイブの両方を使用してリードレプリカを復旧できます。レプリケーションスロットを使用したリードレプリカの復旧は、Amazon S3 アーカイブからの復旧よりも高速です。そのため、レプリケーションスロットおよび関連するメトリクスをモニタリングすることをお勧めします。
RDS for PostgreSQL DB インスタンスのレプリケーションスロットは、次に示すように、`pg_replication_slots` ビューをクエリすることで表示できます。
```
postgres=> SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
rds_us_west_1_db_555555555 | | physical | | | f | t | 13194 | | | 23/D8000060 | | reserved | | f
(1 row)
```
`wal_status`/`reserved` の値は、`max_wal_size` パラメータの境界内のスロットで保持されている WAL データの量を示します。つまり、レプリケーションスロットは適切にサイズ設定されています。その他のステータス値は次のとおりです。
+ `extended` – スロットは `max_wal_size` 設定を超過しますが、WAL データは保持されます。
+ `unreserved` – スロットに必要な WAL データがすべて含まれていません。データの一部は次のチェックポイントで削除されます。
+ `lost` – 必要な WAL データの一部が削除されました。スロットは使用できません。
`wal_status` の `unreserved` および `lost` 状態は、`max_slot_wal_keep_size` が負でない場合にのみ表示されます。
`pg_replication_slots` ビューには、レプリケーションスロットの現在の状態が表示されます。レプリケーションスロットのパフォーマンスを評価する場合、Amazon CloudWatch を使用すると、次のメトリクスをモニタリングできます。
+ **`OldestReplicationSlotLag`** – 最も長い遅延が発生しているレプリカによって消費されていないソースの先書きログ (WAL) データの量を表示します。
+ **`TransactionLogsDiskUsage`** – WAL データに使用されているストレージの量を示します。リードレプリカが著しく遅れると、このメトリクスの値が大幅に増加する可能性があります。
RDS for PostgreSQL での Amazon CloudWatch とそのメトリクスの使用のについての詳細は、「[Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。RDS for PostgreSQL DB インスタンスでストリーミングレプリケーションをモニタリングする方法の詳細については、*AWS データベースブログ*の「[Best practices for Amazon RDS PostgreSQL replication](https://aws.amazon.com/blogs/database/best-practices-for-amazon-rds-postgresql-replication/)」(Amazon RDS PostgreSQL レプリケーションのベストプラクティス) を参照してください。
# RDS for PostgreSQL での遅延レプリケーションの設定
## 概要と利点
RDS for PostgreSQL の遅延レプリケーション機能を使用すると、プライマリデータベースから 1 つ以上のスタンバイ (リードレプリカ) サーバーへのデータ変更のレプリケーションを意図的に遅延できます。これにより、データの破損、偶発的なデータ損失、またはすべてのレプリカにすぐに伝播される可能性のある誤ったトランザクションに対する貴重な保護が提供されます。
遅延レプリケーションは、以下の RDS for PostgreSQL バージョンでサポートされています。
+ 14.19 以降の 14 バージョン
+ 15.14 以降の 15 バージョン
+ 16.10 以降の 16 バージョン
+ 17.6 以降の 17 バージョン
レプリケーションプロセスにタイムラグを導入することで、データ関連のインシデントが DB クラスター全体に影響を与える前に、それを検出して対応する機会が得られます。遅延レプリケーションの主な利点は次のとおりです。
+ 偶発的な削除、更新、その他の論理的なミスから復旧できます。
+ DB クラスター全体の破損したデータの分散に対するバッファを提供します。
+ 従来のバックアップ戦略を補完する追加の復旧ポイントオプションを提供します。
+ 組織固有のニーズとリスク許容度に基づいて遅延期間を設定できます。
## 遅延レプリケーションの有効化と設定
RDS for PostgreSQL リードレプリカで遅延レプリケーションを有効にするには、次の手順に従います。
**注記**
カスケードされたリードレプリカの場合は、以下で説明するのと同じ `recovery_min_apply_delay` パラメータと手順を使用します。
**遅延レプリケーションを有効にするには**
1. 新しいカスタムパラメータグループを作成するか、既存のものを変更します。詳細については、「[Amazon RDS DB インスタンスの DB パラメータグループ](USER_WorkingWithDBInstanceParamGroups.md)」を参照してください。
1. パラメータグループの `recovery_min_apply_delay` パラメータを設定します。
+ 希望する遅延の値をミリ秒単位で設定します。例えば、1 時間の遅延の場合は 3600000 です。
+ 許可される範囲: 0～86400000 ms (0～24 時間)
+ デフォルト: 0
1. パラメータグループを、遅延レプリケーション用に設定するリードレプリカインスタンスに適用します。
1. 変更を有効にするために、リードレプリカインスタンスを再起動します。
**注記**
`recovery_min_apply_delay` パラメータは動的です。インスタンスに既にアタッチされている既存のパラメータグループを変更すると、その変更は再起動を必要とせずにすぐに有効になります。ただし、インスタンスに新しいパラメータグループを適用する場合は、変更を有効にするために再起動する必要があります。
## 遅延レプリケーションリカバリの管理
遅延レプリケーションは、従来のポイントインタイムリカバリ方法が不十分な場合や時間がかかりすぎる場合に特に役立ちます。
遅延レプリケーション期間中は、次の PostgreSQL 関数を使用して復旧プロセスを管理できます。
+ `pg_wal_replay_pause()`: 遅延レプリカの復旧プロセスを一時停止するようにリクエストします。
+ `pg_wal_replay_resume()`: 以前に一時停止していた場合は、復旧プロセスを再起動します。
+ `pg_is_wal_replay_paused()`: 復旧プロセスが現在一時停止されているかどうかを確認します。
+ `pg_get_wal_replay_pause_state()`: 復旧プロセスの現在の状態を取得します (一時停止、リクエスト、一時停止なし)。
`rds_superuser` ロールを持つユーザーには、`pg_wal_replay_pause()` および `pg_wal_replay_resume()` に対する EXECUTE 権限があります。他のデータベースユーザーがこれらの関数にアクセスする必要がある場合は、`rds_superuser` ロールを付与する必要があります。`rds_superuser` ロールの詳細については、「[rds\$1superuser ロールを理解する](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)」を参照してください。
`pg_is_wal_replay_paused()` や `pg_get_wal_replay_pause_state()` などの他の関数へのアクセスには、`rds_superuser` ロールは必要ありません。
次の復旧ターゲットパラメータを使用して、遅延レプリカが復旧する時点を正確に制御できます。これらのパラメータは静的であり、変更を適用するにはデータベースを再起動する必要があります。
+ recovery\$1target
+ recovery\$1target\$1lsn
+ recovery\$1target\$1name
+ recovery\$1target\$1time
+ recovery\$1target\$1xid
+ recovery\$1target\$1inclusive
**重要**
一度に指定できる復旧先パラメータは 1 つだけです。設定ファイルに複数の復旧先パラメータを設定すると、エラーが発生します。
## 計画に関する考慮事項
RDS for PostgreSQL で遅延レプリケーションを計画する場合は、次の点を考慮してください。
+ `rdsrepladmin` 認証情報の自動ローテーション中 (90 日ごとに発生)、遅延リードレプリカが一時的に `REPLICATION_ERROR` 状態になることがあります。遅延レプリカに設定された遅延を維持するのに十分な WAL ログがある場合、WAL レシーバープロセスが一時停止し、ソースに WAL が蓄積される可能性があります。ストレージがいっぱいにならないように、レプリカのレプリケーションステータスとソースのストレージ消費量をモニタリングする必要があります。
+ 遅延リードレプリカでシステムイベント (再起動や再起動など) が発生すると、設定された遅延期間が終了するまで WAL レシーバープロセスが非アクティブのままになる `REPLICATION_ERROR` 状態になります。この動作により、ソースインスタンスに WAL が蓄積され、ストレージが枯渇する可能性があります。以下の予防策を検討してください。
+ ソースインスタンスのストレージ使用率をモニタリングするように CloudWatch アラームを設定します。
+ ストレージの自動スケーリングを有効にして、予期しない WAL の増加を処理します。
+ レプリケーションスロットあたりの WAL 保持を制限するには、レプリケート元インスタンスの `max_slot_wal_keep_size` パラメータを設定します。
+ レプリケーションラグとスロットステータスを定期的にモニタリングします。
+ 遅延が長くなると、レプリカの WAL ログが増加し、より多くのストレージが消費されます。CloudWatch アラームを使用したストレージスペースのモニタリング、自動スケーリングの有効化、または必要に応じてレプリカのキャッチアップを行います。
+ 遅延リードレプリカを昇格する場合、`recovery_min_apply_delay` パラメータは受け入れられず、保留中のすべての WAL レコードがすぐに適用されます。
+ `recovery_min_apply_delay` パラメータは、カスケードレプリケーション設定の各レベルで独立しています。レプリカに遅延を設定しても、カスケードされたレプリカの遅延には追加されません。
詳細については、「[RDS for PostgreSQL リードレプリカのドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)」と「[RDS for PostgreSQL ディザスタリカバリのドキュメント](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PostgreSQL.Disaster-Recovery.html)」を参照してください。
## 制限を理解する
Amazon RDS for PostgreSQL の遅延レプリケーション機能には、次の制限があります。
+ ブルー/グリーンデプロイでは、遅延レプリケーションを設定するときに以下の制限があります。
+ **グリーンソースインスタンス** – パラメータグループで設定されていても、`recovery_min_apply_delay parameter` は無視されます。グリーンソースインスタンスの遅延設定は有効になりません。
+ **グリーンレプリカインスタンス** – `recovery_min_apply_delay parameter` は完全にサポートされ、PostgreSQL 設定ファイルに適用されます。遅延設定は、スイッチオーバーワークフロー中に想定どおりに機能します。
+ メジャーバージョンアップグレード用の RDS ブルー/グリーンデプロイ
+ メジャーバージョンのアップグレード中、遅延したリードレプリカは自動的に終了され、ソースインスタンスが最小限のダウンタイムを確保するためにアップグレードプロセスを続行できるようになります。ソースインスタンスのアップグレードが完了したら、遅延レプリカを手動で再作成する必要があります。
+ 遅延レプリケーションは、以下の機能と互換性がありません。
+ RDS for PostgreSQL の論理的なレプリケーション
+ RDS for PostgreSQL マルチ AZ クラスター (インバウンドレプリケーションとアウトバウンドレプリケーションの両方を含む)
+ Aurora PostgreSQL
# RDS for PostgreSQL リードレプリカのトラブルシューティング
RDS for PostgreSQL リードレプリカに関するよくある問題のトラブルシューティングについてのアイデアをいくつか以下に紹介します。
**リードレプリカの遅延の原因となるクエリを終了する**
トランザクションの状態がアクティブまたはアイドルであり、データベース内で長時間実行されているトランザクションは、WAL レプリケーションプロセスへの妨害となる可能性があります。これは、レプリケーション遅延の悪化につながります。このため、PostgreSQL `pg_stat_activity` ビューを使用して、このようなトランザクションのランタイムを必ずモニタリングしてください。
プライマリインスタンスで次のようなクエリを実行して、長時間実行されているクエリのプロセス ID (PID) を検索します。
```
SELECT datname, pid,usename, client_addr, backend_start,
xact_start, current_timestamp - xact_start AS xact_runtime, state,
backend_xmin FROM pg_stat_activity WHERE state='active';
```
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
クエリの PID を特定したら、そのクエリを終了することができます。
プライマリインスタンスで次のようなクエリを実行して、長時間実行されているクエリを終了します。
```
SELECT pg_terminate_backend(PID);
```
# Amazon RDS Optimized Reads による RDS for PostgreSQL のクエリパフォーマンスの向上
Amazon RDS Optimized Reads によって、RDS for PostgreSQL の高速クエリ処理を実現できます。RDS Optimized Reads を使用する RDS for PostgreSQL DB インスタンスまたはマルチ AZ DB クラスターは、これを使用しないものに比べて、クエリ処理を最大 2 倍高速化できます。
**Topics**
+ [
## PostgreSQL の RDS Optimized Reads の概要
](#USER_PostgreSQL.optimizedreads-overview)
+ [
## RDS Optimized Reads のユースケース
](#USER_PostgreSQL.optimizedreads-use-cases)
+ [
## RDS Optimized Reads のベストプラクティス
](#USER_PostgreSQL.optimizedreads-best-practices)
+ [
## RDS Optimized Reads の使用
](#USER_PostgreSQL.optimizedreads-using)
+ [
## RDS Optimized Reads を使用する DB インスタンスのモニタリング
](#USER_PostgreSQL.optimizedreads-monitoring)
+ [
## PostgreSQL の RDS Optimized Reads についての制限事項
](#USER_PostgreSQL.optimizedreads-limitations)
## PostgreSQL の RDS Optimized Reads の概要
NVMe ベースの DB インスタンスクラスを使用する場合、RDS for PostgreSQL バージョン 15.2 以上、14.7 以上、13.10 以上では、Optimized Reads をデフォルトで利用できます。NVMe を使用するインスタンスを示すハードウェア仕様については、「[ DB インスタンスクラスのハードウェア仕様](Concepts.DBInstanceClass.Summary.md)」を参照してください。
RDS Optimized Reads が有効になっている RDS for PostgreSQL DB インスタンスまたはマルチ AZ DB クラスターを使用する場合、それがローカルの不揮発性メモリエクスプレス (NVMe) ベースのソリッドステートドライブ (SSD) ブロックレベルストレージを使用することで、クエリのパフォーマンスが最大 2 倍高速化されます。PostgreSQL によって生成された一時テーブルをローカルストレージに配置することで、クエリ処理を高速化できます。これにより、ネットワーク経由の Elastic Block Storage (EBS) へのトラフィックが減少します。
PostgreSQL では、一時オブジェクトは一時的な名前空間に割り当てられ、セッションの終了時に自動的に削除されます。ドロップ中の一時的な名前空間は、テーブル、関数、演算子、さらには拡張機能などのスキーマ修飾オブジェクトを含む、セッションに依存するオブジェクトをすべて削除します。
RDS for PostgreSQL では、`temp_tablespaces` パラメータは一時オブジェクトが格納されるこの一時的な作業領域に設定されます。
次のクエリは、テーブルスペースの名前とその場所を返します。
```
postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
rds_temp_tablespace
(1 row)
```
`rds_temp_tablespace` は、NVMe ローカルストレージを指す RDS によって設定された表領域です。`Parameter group` 内のこのパラメータを AWS マネジメントコンソール を使用して変更し、`rds_temp_tablespace` 以外の任意のテーブルスペースを指すようにすることで、いつでも Amazon EBS ストレージに戻すことができます。詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。SET コマンドを使用して、セッションレベルで `temp_tablespaces` パラメータの値を `pg_default` に変更することもできます。パラメータを変更すると、一時的な作業領域が Amazon EBS にリダイレクトされます。Amazon EBS に戻すことは、RDS インスタンスまたはクラスターのローカルストレージが特定の SQL 操作を実行するのに十分でない場合に役立ちます。
```
postgres=> SET temp_tablespaces TO 'pg_default';
SET
```
```
postgres=> show temp_tablespaces;
temp_tablespaces
------------------
pg_default
```
## RDS Optimized Reads のユースケース
以下に、Optimized Reads を使用することでメリットが得られるユースケースをいくつか紹介します。
+ テーブル共通式 (CTE)、派生テーブル、グループ化オペレーションを含む分析クエリ。
+ アプリケーションの最適化されていないクエリを処理するリードレプリカ。
+ GROUP BY や ORDER BY などの複雑な操作を伴うオンデマンドまたは動的なレポートクエリで、常に適切なインデックスを使用できるとは限らないもの。
+ 内部の一時テーブルを使用するその他のワークロード。
+ ソート用の `CREATE INDEX` または `REINDEX` 操作。
## RDS Optimized Reads のベストプラクティス
RDS Optimized Reads を使用するベストプラクティスは次のとおりです。
+ インスタンスストアが実行中にストレージ不足によって失敗した場合に備えて、読み取り専用クエリの再試行ロジックを追加します。
+ CloudWatch メトリクスの `FreeLocalStorage` を使用して、インスタンスストアで使用可能なストレージ容量をモニタリングします。DB インスタンスまたはマルチ AZ DB クラスターのワークロードが原因でインスタンスストアが上限に達している場合は、より大きな DB インスタンスクラスを使用するように変更します。
## RDS Optimized Reads の使用
シングル AZ DB インスタンスデプロイ、マルチ AZ DB インスタンスデプロイ、またはマルチ AZ DB クラスターデプロイで、NVMe ベースの DB インスタンスクラスのいずれかを使用して RDS for PostgreSQL DB インスタンスをプロビジョニングすると、DB インスタンスは自動的に RDS Optimized Reads を使用します。
マルチ AZ 配置については、「[Amazon RDS でのマルチ AZ 配置の設定と管理](Concepts.MultiAZ.md)」を参照してください。
RDS Optimized Reads をオンにするには、次のいずれかの操作を行います。
+ NVMe ベースの DB インスタンスクラスの 1 つを使用して、RDS for PostgreSQL DB インスタンスまたはマルチ AZ DB クラスターを作成します。詳細については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ NVMe ベースの DB インスタンスクラスの 1 つを使用して、既存の RDS for PostgreSQL DB インスタンスまたはマルチ AZ DB クラスターを変更します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
RDS Optimized Reads は、ローカル NVMe SSD ストレージのある DB インスタンスクラスの 1 つ以上がサポートされているすべての AWS リージョン で使用できます。詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
最適化されていない読み取り RDS インスタンスに戻すには、RDS インスタンスまたはクラスターの DB インスタンスクラスを、データベースワークロードの EBS ストレージのみをサポートする同様のインスタンスクラスに変更します。例えば、現在の DB インスタンスクラスが db.r6gd.4xlarge の場合、db.r6g.4xlarge を選択して元に戻します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
## RDS Optimized Reads を使用する DB インスタンスのモニタリング
RDS Optimized Reads を使用する DB インスタンスは、次の CloudWatch メトリクスでモニタリングできます。
+ `FreeLocalStorage`
+ `ReadIOPSLocalStorage`
+ `ReadLatencyLocalStorage`
+ `ReadThroughputLocalStorage`
+ `WriteIOPSLocalStorage`
+ `WriteLatencyLocalStorage`
+ `WriteThroughputLocalStorage`
これらのメトリクスでは、利用可能なインスタンスストアストレージ、IOPS、スループットに関するデータを提供します。これらのメトリクスの詳細については、「[Amazon RDS の Amazon CloudWatch インスタンスレベルのメトリクス](rds-metrics.md#rds-cw-metrics-instance)」を参照してください。
ローカルストレージの現在の使用状況をモニタリングするには、データベースにログインして次のクエリを実行します。
```
SELECT
spcname AS "Name",
pg_catalog.pg_size_pretty(pg_catalog.pg_tablespace_size(oid)) AS "size"
FROM
pg_catalog.pg_tablespace
WHERE
spcname IN ('rds_temp_tablespace');
```
一時ファイルとその使用方法の詳細については、「[PostgreSQL による一時ファイルの管理](PostgreSQL.ManagingTempFiles.md)」を参照してください。
## PostgreSQL の RDS Optimized Reads についての制限事項
PostgreSQL の RDS Optimized Reads には次の制限事項が適用されます。
+ トランザクションは、インスタンスストアが満杯になるとエラーになる可能性があります。
# Amazon RDS の PostgreSQL にデータをインポートする
Amazon RDS に移動させる既存の PostgreSQL デプロイがあるとします。タスクの複雑さは、データベースのサイズと転送するデータベースオブジェクトの種類に依存しています。例えば、データベースにギガバイトのオーダーのデータセット、さらにストアドプロシージャとトリガーが含まれているとします。このようなデータベースは、単純なデータベース (数メガバイトのテストデータを含むだけで、トリガーやストアドプロシージャを含まないもの) よりも複雑になります。
次の条件で、ネイティブ PostgreSQL データベース移行ツールを使用することをお勧めします。
+ ターゲットデータベースエンジンと同じデータベースエンジンを持つデータベースから移行する、同機種移行である。
+ データベース全体を移行する。
+ ネイティブツールでは、最小のダウンタイムでシステムを移行することができます。
他の多くの場合、データベースの移行には、AWS Database Migration Service (AWS DMS) を使用することが最良のアプローチとなります。AWSDMS により、ダウンタイムなしでデータベースを移行できます。また、多くのデータベースエンジンでは、ターゲットデータベースへの切り替え準備ができるまで、進行中のレプリケーションを続行することができます。AWS DMS を使用することで、同じデータベースエンジン、または異なるデータベースエンジンへの移行が可能です。ソースデータベースとは別のデータベースエンジンへ移行する場合は、AWS Schema Conversion Tool (AWS SCT) を使用できます。AWS SCT を使用して、AWS DMS で移行されないスキーマオブジェクトを移行します。AWS DMS の詳細については、「[AWS Database Migration Service とは](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html)」を参照してください。
DB パラメータグループを変更し、次の*インポート専用*の設定を含めます。DB インスタンスサイズの最も効率的な設定を見つけるために、パラメータ設定をテストする必要があります。さらに、インポートが完了したら、これらのパラメータを本番稼働用の値に戻す必要があります。
DB インスタンスの設定を次のように変更します。
+ DB インスタンスのバックアップを無効にします (backup\$1retention を 0 に設定します)。
+ マルチ AZ を無効にする。
次の設定を含むように DB パラメータグループを変更します。これらの設定は、データのインポート時にのみ使用してください。DB インスタンスサイズの最も効率的な設定を見つけるために、パラメータ設定をテストする必要があります。さらに、インポートが完了したら、これらのパラメータを本番稼働用の値に戻す必要があります。
| Parameter | インポート時の推奨値 | 説明 |
| --- | --- | --- |
| `maintenance_work_mem` | 524288、1048576、2097152、または 4194304 (KB 単位)。これらの設定は、512 MB、1 GB、2 GB、および 4 GB と同等です。 | この設定の値は、ホストのサイズによって異なります。このパラメータは、CREATE INDEX ステートメントで使用され、各パラレルコマンドがこの量のメモリを使用できます。この設定値が大きすぎてメモリ不足が生じることのないように、最適な値を計算します。 |
| `max_wal_size` | 256 (バージョン 9.6 の場合)、4096 (バージョン 10 以降の場合) | 自動チェックポイント中に WAL を拡張するための最大サイズ。このパラメータを増やすと、クラッシュ回復に必要な時間が長く可能性があります。PostgreSQL 9.6 以降では、このパラメータは `checkpoint_segments` を置き換えられます。 PostgreSQL バージョン 9.6 の場合、この値は 16 MB 単位です。それ以降のバージョンでは、値は 1 MB 単位です。例えば、バージョン 9.6 では、128 は、それぞれ 16 MB のサイズである 128 個のチャンクを意味します。バージョン 12.4 では、2048 は、それぞれ 1 MB のサイズである 2048 個のチャンクを意味します。 |
| `checkpoint_timeout` | 1800 | この値に設定すると、WAL ローテーションの頻度を低くすることができます。 |
| `synchronous_commit` | オフ | この設定を無効にすると、書き込みが速くなります。このパラメータをオフにすると、サーバークラッシュ時にデータが損失するリスクを下げることができます (FSYNC はオフにしないでください)。 |
| `wal_buffers` | 8192 | この値は、8 KB 単位です。これも WAL の生成速度に貢献します。 |
| `autovacuum` | 0 | リソースが使用されないように、データのロード時に PostgreSQL の自動バキュームパラメータを無効にします。 |
これらの設定で、`pg_dump -Fc` (圧縮) または `pg_restore -j` (パラレル) コマンドを使用します。
**注記**
PostgreSQL コマンド `pg_dumpall` の実行には SUPER\$1USER 権限が必要ですが、この権限は DB インスタンスの作成時に付与されません。そのため、このコマンドをデータのインポートに使用することはできません。
**Topics**
+ [
# Amazon EC2 インスタンスから PostgreSQL データベースをインポートする
](PostgreSQL.Procedural.Importing.EC2.md)
+ [
# \$1copy コマンドを使用して PostgreSQL DB インスタンスのテーブルにデータをインポートする
](PostgreSQL.Procedural.Importing.Copy.md)
+ [
# Amazon S3 から RDS for PostgreSQL DB インスタンスにデータをインポートする
](USER_PostgreSQL.S3Import.md)
+ [
# DB インスタンス 間での PostgreSQL データベースの移行
](PostgreSQL.TransportableDB.md)
# Amazon EC2 インスタンスから PostgreSQL データベースをインポートする
Amazon EC2 インスタンス上の PostgreSQL サーバーにデータがあり、そのデータを PostgreSQL DB インスタンスに移動する場合は、次のプロセスに従ってデータを移行できます。
1. pg\$1dump を使用して、ロードするデータを格納したファイルを作成する
1. ターゲット DB インスタンスを作成する
1. *psql* を使用して、DB インスタンスにデータベースを作成し、データをロードする
1. DB インスタンスの DB スナップショットを作成する
次のセクションでは、上記の各ステップについて詳しく説明します。
## ステップ 1: ロードするデータが含まれている pg\$1dump を使用してファイルを作成する
`pg_dump` ユーティリティでは、COPY コマンドを使用して、PostgreSQL データベースのスキーマとデータダンプを作成します。`pg_dump` によって生成されるダンプスクリプトは、同じ名前のデータベースにデータをロードし、テーブル、インデックス、外部キーを再作成します。`pg_restore` コマンドと `-d` パラメータを使用して、データを別の名前でデータベースに復元できます。
データダンプの作成前に、ダンプするテーブルに対してクエリを実行して行数を取得し、ターゲット DB インスタンスでその行数を確認できるようにする必要があります。
以下のコマンドでは、mydb2 というデータベース用に mydb2dump.sql というダンプファイルを作成しています。
```
prompt>pg_dump dbname=mydb2 -f mydb2dump.sql
```
## ステップ 2: ターゲット DB インスタンスを作成する
Amazon RDS コンソール、AWS CLI、または API のいずれかを使用して、ターゲット PostgreSQL DB インスタンスを作成します。バックアップの保持設定を 0 にし、マルチ AZ を無効にして、インスタンスを作成します。これにより、データのインポートが高速化されます。データをダンプする前に、インスタンスにデータベースを作成する必要があります。データベースは、ダンプしたデータが含まれていたデータベースと同じ名前で作成できます。または、別の名前でデータベースを作成できます。この場合は、`pg_restore` コマンドと `-d` パラメータを使用して、新しい名前のデータベース内にデータを復元します。
例えば、データベースのダンプ、復元、名前変更に以下のコマンドを使用できます。
```
pg_dump -Fc -v -h [endpoint of instance] -U [master username] [database] > [database].dump
createdb [new database name]
pg_restore -v -h [endpoint of instance] -U [master username] -d [new database name] [database].dump
```
## ステップ 3: psql を使用して DB インスタンスにデータベースを作成し、データをロードする
pg\$1dump コマンドの実行に使用した同じ接続を使用して、ターゲット DB インスタンスに接続し、データベースを再作成できます。*psql* により、マスターユーザー名とマスターパスワードを使用して DB インスタンスにデータベースを作成できます。
以下の例では、*psql* と、mydb2dump.sql という名前のダンプファイルを使用して、mypginstance という PostgreSQL DB インスタンスに mydb2 というデータベースを作成しています。
Linux、macOS、Unix の場合:
```
psql \
-f mydb2dump.sql \
--host mypginstance.555555555555.aws-region.rds.amazonaws.com \
--port 8199 \
--username myawsuser \
--password password \
--dbname mydb2
```
Windows の場合:
```
psql ^
-f mydb2dump.sql ^
--host mypginstance.555555555555.aws-region.rds.amazonaws.com ^
--port 8199 ^
--username myawsuser ^
--password password ^
--dbname mydb2
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
## ステップ 4: DB インスタンスの DB スナップショットを作成する
データが DB インスタンスにロードされたことを確認したら、ターゲット PostgreSQL DB インスタンスの DB スナップショットを作成することをお勧めします。DB スナップショットは DB インスタンスの完全なバックアップであり、DB インスタンスを既知の状態に復元するために使用できます。ロード直後に DB スナップショットを作成しておくと、何らかの事故のときにそのスナップショットを使用すれば、データを再ロードせずに済みます。また、そのスナップショットを使用して、新しい DB インスタンスをシードすることもできます。DB スナップショットの作成については、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」を参照してください。
# \$1copy コマンドを使用して PostgreSQL DB インスタンスのテーブルにデータをインポートする
PostgreSQL の `\copy` コマンドは、`psql` の対話型クライアントツールでメタコマンドを利用できます。`\copy` を使うと、RDS for PostgreSQL DB インスタンスで、テーブルにデータをインポートできます。`\copy` コマンドを使うには、まず対象のDB インスタンスにテーブル構造を作成して、`\copy` がデータをコピーする先を用意する必要があります。
`\copy` を使用すると、クライアントのワークステーションにエクスポートして保存しておいた、カンマ区切り値 (CSV) 形式のファイルなどから、データを読み込むことができます。
CSV データを対象の RDS for PostgreSQL DB インスタンスにインポートするには、まず `psql` を使用して、対象の DB インスタンスに接続します。
```
psql --host=db-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=target-db
```
その後、次のパラメータを指定して `\copy` コマンドを実行し、対象のデータとその形式を識別します。
+ `target_table` — CSV ファイルからコピーされるデータを受け取るテーブルの名前。
+ `column_list` — テーブルの列の仕様。
+ `'filename'` — ローカルワークステーションにある CSV ファイルの絶対パス。
```
\copy target_table from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV;
```
CSV ファイルに列見出しがある場合は、このバージョンのコマンドとパラメータを使用できます。
```
\copy target_table (column-1, column-2, column-3, ...)
from '/path/to/local/filename.csv' WITH DELIMITER ',' CSV HEADER;
```
`\copy` コマンドが失敗した場合は、PostgreSQL はエラーメッセージを出力します。
以下の例で示すように、`\copy` メタコマンドを指定した `psql` コマンドで、データベースプレビュー環境に新しい DB インスタンスを作成します。この例では、ソーステーブル名として *source-table*、.csv ファイルとして *source-table.csv*、ターゲットデータベースとして *target-db* を使用しています。
Linux、macOS、Unix の場合:
```
$psql target-db \
-U \
-p \
-h \
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
Windows の場合:
```
$psql target-db ^
-U ^
-p ^
-h ^
-c "\copy source-table from 'source-table.csv' with DELIMITER ','"
```
`\copy` コマンドの詳細については、PostgreSQL のドキュメント の 「[psql](http://www.postgresql.org/docs/current/static/app-psql.html)」ページにある、「*メタコマンド*」セクションを参照してください。
# Amazon S3 から RDS for PostgreSQL DB インスタンスにデータをインポートする
Amazon Simple Storage Service を使用して保存されたデータを、 RDS for PostgreSQL DB インスタンス上のテーブルにインポートできます。これを行うには、 RDS for PostgreSQL `aws_s3`拡張機能を最初にインストールします。この拡張機能には、Amazon S3 バケットからのデータのインポートに使用する関数が含まれます。*バケット*とは、Amazon S3 のオブジェクトおよびファイルのコンテナです。データは、カンマ区切り値 (CSV) ファイル、テキストファイル、または圧縮 (gzip) ファイルでインポートできます。次に、拡張機能のインストール方法と、Amazon S3 からテーブルにデータをインポートする方法について説明します。
Amazon S3 から RDS for PostgreSQL にインポートするには、データベースで PostgreSQL バージョン 10.7 以降を実行している必要があります。
Amazon S3 にデータが保存されていない場合は、まずバケットを作成し、データを保存する必要があります。詳細については、*Amazon Simple Storage Service コンソールユーザーガイド*の以下のトピックを参照してください。
+ [バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)
+ [バケットにオブジェクトを追加する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#uploading-an-object-bucket)
Amazon S3 からのクロスアカウントインポートがサポートされています。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[クロスアカウントアクセス許可の付与](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html)」を参照してください。
S3 からデータをインポートする際は、カスタマーマネージドキーを暗号化に使用できます。詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[AWS KMS に保存される KMS キー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html)」を参照してください。
**Topics**
+ [
# aws\$1s3 拡張機能のインストール
](USER_PostgreSQL.S3Import.InstallExtension.md)
+ [
# Amazon S3 データからのデータのインポートの概要
](USER_PostgreSQL.S3Import.Overview.md)
+ [
# Amazon S3 バケットへのアクセスを設定する
](USER_PostgreSQL.S3Import.AccessPermission.md)
+ [
# Amazon S3 から RDS for PostgreSQL DB インスタンスにデータをインポートする
](USER_PostgreSQL.S3Import.FileFormats.md)
+ [
# 関数リファレンス
](USER_PostgreSQL.S3Import.Reference.md)
# aws\$1s3 拡張機能のインストール
RDS for PostgreSQL DB インスタンスで Amazon S3 を使用する前に、`aws_s3` 拡張機能をインストールする必要があります。この拡張機能には、Amazon S3 からデータをインポートするための関数が含まれます。また、 RDS for PostgreSQL DB インスタンスから Amazon S3 バケットへデータをエクスポートするための関数も含まれています。詳しくは、「[RDS for PostgreSQL DB インスタンスから Amazon S3 へのデータのエクスポート](postgresql-s3-export.md)」を参照してください。`aws_s3` 拡張機能は `aws_commons` 拡張機能の一部のヘルパー関数に依存しており、必要に応じて自動的にインストールされます。
**`aws_s3` 拡張機能をインストールするには**
1. `rds_superuser` 権限があるユーザーとして、psql (または pgAdmin) を使用して RDS for PostgreSQL DB インスタンスに接続します。設定プロセス中にデフォルトの名前を保持している場合は、`postgres` として接続します。
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. 拡張機能をインストールするには、次のコマンドを実行します。
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. 拡張機能がインストールされていることを確認するには、psql `\dx` メタコマンドを使用します。
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Amazon S3 からデータをインポートし、データを Amazon S3 にエクスポートするための関数が使用できるようになりました。
# Amazon S3 データからのデータのインポートの概要
**S3 データを Amazon RDS にインポートするには**
まず、関数で指定する必要がある詳細情報を収集します。この情報には、 RDS for PostgreSQL DB インスタンスのテーブルの名前、バケット名、ファイルパス、ファイルタイプ、Amazon S3 データが保存される AWS リージョンが含まれます。詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[オブジェクトの表示](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html)」を参照してください。
**注記**
Amazon S3 からのマルチパートデータインポートは現在サポートされていません。
1. `aws_s3.table_import_from_s3` 関数によってデータがインポートされるテーブルの名前を取得します。例えば、次のコマンドにより、後の手順で使用されるテーブル `t1` が作成されます。
```
postgres=> CREATE TABLE t1
(col1 varchar(80),
col2 varchar(80),
col3 varchar(80));
```
1. Amazon S3 バケットの詳細とインポートするデータを取得します。これを実行するには、Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開き、**[Bucket]** (バケット) を選択します。リストで、データを含むバケットを探します。バケットを選択し、オブジェクト概要ページを開き、[Properties] (プロパティ) を選択します。
バケット名、パス、AWS リージョン、およびファイルタイプを書き留めておきます。IAM ロールによる Amazon S3 へのアクセスを設定するには、後で Amazon リソースネーム (ARN) が必要になります。詳細については、「[Amazon S3 バケットへのアクセスを設定する](USER_PostgreSQL.S3Import.AccessPermission.md)」を参照してください。次のイメージは例を示しています。
![\[Amazon S3 バケット内のファイルオブジェクトの画像。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/aws_s3_import-export_s3_bucket-info.png)
1. AWS CLI コマンド `aws s3 cp` を使用して、Amazon S3 バケットのデータへのパスを確認できます。情報が正しい場合、このコマンドは Amazon S3 ファイルのコピーをダウンロードします。
```
aws s3 cp s3://amzn-s3-demo-bucket/sample_file_path ./
```
1. RDS for PostgreSQL DB インスタンスに対するアクセス許可を設定して、Amazon S3 バケット上のファイルへのアクセスを許可します。これを行うには、AWS Identity and Access Management (IAM) ロールまたはセキュリティ認証情報を使用します。詳しくは、「[Amazon S3 バケットへのアクセスを設定する](USER_PostgreSQL.S3Import.AccessPermission.md)」を参照してください。
1. 収集したパスと他の Amazon S3 オブジェクトの詳細 (ステップ 2 を参照) を `create_s3_uri` 関数で指定し、Amazon S3 URI オブジェクトを構成します。この関数の詳細については、「[aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri)」を参照してください。psql セッション中にこのオブジェクトを構成する例は次のとおりです。
```
postgres=> SELECT aws_commons.create_s3_uri(
'docs-lab-store-for-rpg',
'versions_and_jdks_listing.csv',
'us-west-1'
) AS s3_uri \gset
```
次のステップでは、このオブジェクト (`aws_commons._s3_uri_1`) を `aws_s3.table_import_from_s3` 関数に渡して、データをテーブルにインポートします。
1. `aws_s3.table_import_from_s3` 関数を呼び出して、Amazon S3 からテーブルにデータをインポートします。参考情報については、「[aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3)」を参照してください。例については「[Amazon S3 から RDS for PostgreSQL DB インスタンスにデータをインポートする](USER_PostgreSQL.S3Import.FileFormats.md)」を参照してください。
# Amazon S3 バケットへのアクセスを設定する
Amazon S3 ファイルからデータをインポートするには、RDS for PostgreSQL DB インスタンスに、ファイルが含まれている Amazon S3 バケットへのアクセス許可を与える必要があります。次のトピックで説明する 2 つの方法のいずれかで、Amazon S3 バケットへのアクセスを提供します。
**Topics**
+ [
## IAM ロールを使用した Amazon S3 バケットへのアクセス
](#USER_PostgreSQL.S3Import.ARNRole)
+ [
## セキュリティ認証情報を使用して Amazon S3 バケットにアクセスする
](#USER_PostgreSQL.S3Import.Credentials)
+ [
## Amazon S3 へのアクセスのトラブルシューティング
](#USER_PostgreSQL.S3Import.troubleshooting)
## IAM ロールを使用した Amazon S3 バケットへのアクセス
Amazon S3 ファイルからデータをロードするには、ファイルが含まれる Amazon S3 バケットへのアクセス許可を RDS for PostgreSQL DB インスタンスに与えます。こうすれば、追加の認証情報を管理したり、[aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) 関数呼び出しで提供したりする必要はありません。
これを行うには、Amazon S3 バケットへのアクセスを提供する IAM ポリシーを作成します。IAM ロールを作成して、ポリシーをロールにアタッチします。次に、IAM ロールを DB インスタンスに割り当てます。
**IAM ロールを使用して、Amazon S3 へのアクセス権を RDS for PostgreSQL DB インスタンスに付与するには**
1. IAM ポリシーを作成します。
ポリシーは、RDS for PostgreSQL DB インスタンスに Amazon S3 へのアクセスを許可するバケットとオブジェクトのアクセス許可を付与します。
ポリシーに、Amazon S3 バケットから Amazon RDS へのファイル転送を許可ための次の必須アクションを含めます。
+ `s3:GetObject`
+ `s3:ListBucket`
ポリシーに次のリソースを含めて、Amazon S3 バケットとバケット内のオブジェクトを識別します。これは、Amazon S3 にアクセスするための Amazon リソースネーム (ARN) 形式を示しています。
+ arn:aws:s3:::*amzn-s3-demo-bucket*
+ arn:aws:s3:::*amzn-s3-demo-bucket*/\$1
RDS for PostgreSQL の IAM ポリシーの作成の詳細については、「[IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)」を参照してください。*IAM ユーザーガイド*の「[チュートリアル: はじめてのカスタマー管理ポリシーの作成とアタッチ](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html)」も参照してください。
以下の AWS CLI コマンドでは、これらのオプションを指定して、`rds-s3-import-policy` という名前の IAM ポリシーを作成します。*amzn-s3-demo-bucket* という名前のバケットへのアクセスを許可します。
**注記**
このコマンドによって返されるポリシー のAmazon リソースネーム (ARN) をメモしておきます。ポリシーを IAM ロールにアタッチする場合、後続のステップで ARN が必要です。
**Example**
Linux、macOS、Unix の場合:
```
aws iam create-policy \
--policy-name rds-s3-import-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
Windows の場合:
```
aws iam create-policy ^
--policy-name rds-s3-import-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. IAM ロールを作成します。
これを行うと、Amazon RDS がユーザーに代わってこの IAM ロールを引き受け、Amazon S3 バケットにアクセスできます。詳細については、*IAM ユーザーガイド*の「[IAM ユーザーにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。
リソースポリシー内では `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` および `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` のグローバル条件コンテキストキーを使用して、サービスに付与するリソースへのアクセス許可を制限することをお勧めします。これは、[混乱した使節の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)に対する最も効果的な保護方法です。
グローバル条件コンテキストキーの両方を使用し、`aws:SourceArn` の値にアカウント ID が含まれている場合、同じポリシーステートメントで使用する場合は、`aws:SourceArn` の値と `aws:SourceAccount` の値のアカウントでは同じアカウント ID を使用する必要があります。
+ 単一リソースに対するクロスサービスアクセスが必要な場合は `aws:SourceArn` を使用します。
+ そのアカウント内の任意のリソースをクロスサービス使用に関連付けることを許可する場合、`aws:SourceAccount`を使用します。
ポリシーでは、必ずリソースの完全な ARN を持つ `aws:SourceArn` グローバル条件コンテキストキーを使用してください。以下の例は、AWS CLI コマンドを使用して、`rds-s3-import-role` という名前のロールを作成する方法を示しています。
**Example**
Linux、macOS、Unix の場合:
```
aws iam create-role \
--role-name rds-s3-import-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Windows の場合:
```
aws iam create-role ^
--role-name rds-s3-import-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. 作成した IAM ポリシーを、作成した IAM ロールにアタッチします。
次の AWS CLI コマンドは、先ほどのステップで作成したポリシーを `rds-s3-import-role` という名前のロールに添付し、`your-policy-arn` を前のステップでメモしたポリシー ARN に置き換えます。
**Example**
Linux、macOS、Unix の場合:
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-import-role
```
Windows の場合:
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-import-role
```
1. DB インスタンスに IAM ロールを追加します。
これを行うには、以下で説明するように、AWS マネジメントコンソール または AWS CLI を使用します。
### コンソール
**コンソールを使用して PostgreSQL DB インスタンスの IAM ロールを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. 詳細を表示するには、PostgreSQL DB インスタンスの名前を選択します。
1. [**接続とセキュリティ**] タブの [**IAM ロールの管理**] セクションで、**このインスタンスに [IAM ロールを追加**] で追加するロールを選択します。
1. [**Feature**] で、[**s3Import**] を選択します。
1. [**Add role**] を選択します。
### AWS CLI
**CLI を使用して PostgreSQL DB インスタンスの IAM ロールを追加するには**
+ 次のコマンドを使用して、`my-db-instance` という名前の PostgreSQL DB インスタンスにロールを追加します。*`your-role-arn`* を、以前のステップで書き留めたロール ARN に置き換えます。`s3Import` オプションの値に `--feature-name` を使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Import \
--role-arn your-role-arn \
--region your-region
```
Windows の場合:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Import ^
--role-arn your-role-arn ^
--region your-region
```
### RDS API
Amazon RDS API を使用して PostgreSQL DB インスタンスに IAM ロールを追加するには、 [AddRoleToDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddRoleToDBInstance.html) オペレーションを呼び出します。
## セキュリティ認証情報を使用して Amazon S3 バケットにアクセスする
必要に応じて、IAM ロールでアクセスを提供する代わりに、セキュリティ認証情報を使用して Amazon S3 バケットへのアクセスを提供できます このためには、[aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) 関数呼び出しで `credentials` パラメータを指定します。
`credentials` パラメータは、型の構造体 `aws_commons._aws_credentials_1` で、AWS 認証情報を含みます。[aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) 関数を使用して、`aws_commons._aws_credentials_1` 構造でアクセスキーおよびシークレットキーを設定します。以下に例を示します。
```
postgres=> SELECT aws_commons.create_aws_credentials(
'sample_access_key', 'sample_secret_key', '')
AS creds \gset
```
`aws_commons._aws_credentials_1 ` 構造を作成したら、以下に示すように、[aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) 関数を `credentials` パラメータと共に使用してデータをインポートします。
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
:'creds'
);
```
または、[aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) 関数の呼び出しのインラインを `aws_s3.table_import_from_s3` 関数の呼び出し内に含めることもできます。
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
## Amazon S3 へのアクセスのトラブルシューティング
Amazon S3 からデータをインポートしようとしたときに接続の問題が発生した場合は、次の推奨事項を参照してください。
+ [Amazon RDS のアイデンティティおよびアクセスのトラブルシューティング](security_iam_troubleshoot.md)
+ *Amazon Simple Storage Service ユーザーガイド* の「[Troubleshooting Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html)」
+ *IAM ユーザーガイド* の [Amazon S3 のトラブルシューティングと IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html)
# Amazon S3 から RDS for PostgreSQL DB インスタンスにデータをインポートする
aws\$1s3 拡張機能の `table_import_from_s3` 関数を使用して Amazon S3 バケットからデータをインポートします。参考情報については、「[aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3)」を参照してください。
**注記**
以下の例では、IAM ロールメソッドを使用して、Amazon S3 バケットへのアクセスを許可します。したがって、`aws_s3.table_import_from_s3` 関数呼び出しには認証情報パラメータは含まれません。
次の例は、代表的な例を示しています。
```
postgres=> SELECT aws_s3.table_import_from_s3(
't1',
'',
'(format csv)',
:'s3_uri'
);
```
パラメータは次のとおりです。
+ `t1` - データのコピー先となる PostgreSQL DB インスタンス内のテーブルの名前。
+ `''` - データベーステーブル内の列のオプションのリスト。S3 データをコピーする列とテーブル列を指定するには、このパラメータを使用します。列を指定しない場合は、すべての列がテーブルにコピーされます。列のリストの使用例については、[カスタム区切り文字を使用する Amazon S3 ファイルをインポートする](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter) を参照してください。
+ `(format csv)` - PostgreSQL COPY 引数。このコピープロセスでは、[PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) コマンドの引数と形式を使用してデータをインポートします。フォーマットとしては、この例のようなカンマ区切り値 (CSV)、テキスト、およびバイナリを指定できます。デフォルトではテキストに設定されています。
+ `s3_uri` - Amazon S3 ファイルを識別する情報を含む構造。[aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) 関数を使用して `s3_uri` 構造を作成する例については、「[Amazon S3 データからのデータのインポートの概要](USER_PostgreSQL.S3Import.Overview.md)」を参照してください。
この関数の詳細については、「[aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3)」を参照してください。
この`aws_s3.table_import_from_s3`関数はテキストを返します。Amazon S3 バケットからインポートする他の種類のファイルを指定するには、次の例のいずれかを参照してください。
**注記**
0 バイトファイルをインポートすると、エラーが発生します。
**Topics**
+ [
## カスタム区切り文字を使用する Amazon S3 ファイルをインポートする
](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter)
+ [
## Amazon S3 圧縮 (gzip) ファイルをインポートする
](#USER_PostgreSQL.S3Import.FileFormats.gzip)
+ [
## エンコードされた Amazon S3 ファイルをインポートする
](#USER_PostgreSQL.S3Import.FileFormats.Encoded)
## カスタム区切り文字を使用する Amazon S3 ファイルをインポートする
以下の例では、カスタム区切り文字を使用するファイルのインポート方法を示します。また、`column_list` 関数の [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) パラメータを使用して、データベースのデータを置く場所を制御する方法を示します。
この例では、次の情報が Amazon S3 ファイル内のパイプ区切りの列に編成されているとします。
```
1|foo1|bar1|elephant1
2|foo2|bar2|elephant2
3|foo3|bar3|elephant3
4|foo4|bar4|elephant4
...
```
**カスタム区切り文字を使用するファイルをインポートするには**
1. インポートされたデータのテーブルをデータベースに作成します。
```
postgres=> CREATE TABLE test (a text, b text, c text, d text, e text);
```
1. データを Amazon S3 からインポートするには、次の形式の [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) 関数を使用します。
または、[aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) 関数の呼び出しのインラインを `aws_s3.table_import_from_s3` 関数の呼び出し内に含めて、ファイルを指定することもできます。
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test',
'a,b,d,e',
'DELIMITER ''|''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'pipeDelimitedSampleFile', 'us-east-2')
);
```
データが、次の列のテーブル内に入りました。
```
postgres=> SELECT * FROM test;
a | b | c | d | e
---+------+---+---+------+-----------
1 | foo1 | | bar1 | elephant1
2 | foo2 | | bar2 | elephant2
3 | foo3 | | bar3 | elephant3
4 | foo4 | | bar4 | elephant4
```
## Amazon S3 圧縮 (gzip) ファイルをインポートする
以下の例では、gzip で圧縮されているファイルを Amazon S3 からインポートする方法を示します。インポートするファイルには、次の Amazon S3 メタデータが必要です。
+ キー: `Content-Encoding`
+ 値: `gzip`
AWS マネジメントコンソール を使用してファイルをアップロードする場合、通常このメタデータは、システムにより適用されます。AWS マネジメントコンソール、AWS CLI、または API による Amazon S3 へのファイルのアップロードについては、「*Amazon Simple Storage Service ユーザーガイド*」の「[オブジェクトのアップロード](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html)」を参照してください。
Amazon S3 のメタデータに関する情報、およびシステム提供メタデータの詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 コンソールでのオブジェクトメタデータの編集](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html)」を参照してください。
以下に示されているように、gzip ファイルを RDS for PostgreSQL DB インスタンスにインポートします。
```
postgres=> CREATE TABLE test_gzip(id int, a text, b text, c text, d text);
postgres=> SELECT aws_s3.table_import_from_s3(
'test_gzip', '', '(format csv)',
'amzn-s3-demo-bucket', 'test-data.gz', 'us-east-2'
);
```
## エンコードされた Amazon S3 ファイルをインポートする
以下の例では、Windows-1252 でエンコードされているファイルを Amazon S3 からインポートする方法を示します。
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test_table', '', 'encoding ''WIN1252''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'SampleFile', 'us-east-2')
);
```
# 関数リファレンス
**Topics**
+ [
## aws\$1s3.table\$1import\$1from\$1s3
](#aws_s3.table_import_from_s3)
+ [
## aws\$1commons.create\$1s3\$1uri
](#USER_PostgreSQL.S3Import.create_s3_uri)
+ [
## aws\$1commons.create\$1aws\$1credentials
](#USER_PostgreSQL.S3Import.create_aws_credentials)
## aws\$1s3.table\$1import\$1from\$1s3
Amazon S3 データを Amazon RDS テーブルにインポートします。`aws_s3` 拡張機能には、`aws_s3.table_import_from_s3` 関数が含まれます。戻り値はテキストです。
### 構文
必須のパラメータは、`table_name`、`column_list`、`options` です。これらのパラメータを使用して、データベースを特定し、データをテーブルにコピーする方法を指定します。
また、次のパラメータを使用することもできます。
+ `s3_info` パラメータは、インポートする Amazon S3 ファイルを指定します。このパラメータを使用する場合、PostgreSQL DB インスタンスの IAM ロールを使用して、Amazon S3 へのアクセス権を付与します。
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1
)
```
+ `credentials` パラメータは、Amazon S3 にアクセスするための認証情報を指定します。このパラメータを使用する場合、IAM ロールは使用しません。
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
```
### パラメータ
*table\$1name*
データのインポート先となる PostgreSQL データベーステーブルの名前を含む必須のテキスト文字列。
*column\$1list*
データをコピーする PostgreSQL データベーステーブル列のオプションリストを含む必須のテキスト文字列。文字列が空の場合、テーブルの列がすべて使用されます。例については、「[カスタム区切り文字を使用する Amazon S3 ファイルをインポートする](USER_PostgreSQL.S3Import.FileFormats.md#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter)」を参照してください。
*オプション*
PostgreSQL `COPY` コマンドの引数を含む必須のテキスト文字列。これらの引数は PostgreSQL のテーブルにデータをコピーする方法を指定します。詳細については、「[PostgreSQL COPY ドキュメント](https://www.postgresql.org/docs/current/sql-copy.html)」を参照してください。
*s3\$1info*
S3 オブジェクトに関する以下の情報を含む `aws_commons._s3_uri_1` 複合型。
+ `bucket` - ファイルを含む Amazon S3 バケット名。
+ `file_path` - Amazon S3ファイルのパスを含むファイル名。
+ `region` - ファイルがある AWS リージョン。AWS リージョン名と関連する値のリストについては、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
*credentials*
インポートオペレーションに使用する次の認証情報を含む `aws_commons._aws_credentials_1` 複合型。
+ アクセスキー
+ シークレットキー
+ セッショントークン
`aws_commons._aws_credentials_1` 複合構造を作成する方法については、「[aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials)」を参照してください。
### 代替構文
テストしやすいように、`s3_info` パラメータや `credentials` パラメータではなく、拡張されたパラメータセットを使用することができます。以下は、`aws_s3.table_import_from_s3` 関数の構文のバリエーションです。
+ Amazon S3 ファイルを識別するために `s3_info` パラメータを使用する代わりに、`bucket`、`file_path`、および `region` パラメータの組み合わせを使用します。この関数の形式を使用する場合は、PostgreSQL DB インスタンスの IAM ロールを使用して、Amazon S3 へのアクセス権を付与します。
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text
)
```
+ Amazon S3 アクセスを指定するために `credentials` パラメータを使用する代わりに、`access_key`、`session_key`、および `session_token` パラメータの組み合わせを使用します。
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text
)
```
### 代替パラメータ
*バケット*
ファイルを含む Amazon S3 バケットの名前を含むテキスト文字列。
*file\$1path*
ファイルのパスを含むAmazon S3ファイル名を含むテキスト文字列。
*リージョン*
ファイルの AWS リージョンの場所を識別するテキスト文字列。AWS リージョン 名と関連する値のリストについては、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
*access\$1key*
インポートオペレーションに使用するアクセスキーを含むテキスト文字列。デフォルトは NULL です。
*secret\$1key*
インポートオペレーションに使用するシークレットキーを含むテキスト文字列。デフォルトは NULL です。
*session\$1token*
(オプション) インポートオペレーションに使用するセッションキーを含むテキスト文字列。デフォルトは NULL です。
## aws\$1commons.create\$1s3\$1uri
Amazon S3 ファイル情報を保持するように、`aws_commons._s3_uri_1` 構造を作成します。`aws_commons.create_s3_uri` 関数の結果は、`s3_info` 関数の [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3) パラメータで使用します。
### 構文
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```
### パラメータ
*バケット*
ファイルの Amazon S3 バケット名を含む必須のテキスト文字列。
*file\$1path*
ファイルのパスを含む Amazon S3 ファイル名を含む必須テキスト文字列。
*リージョン*
ファイルがある AWS リージョン を含む必須のテキスト文字列。AWS リージョン 名と関連する値のリストについては、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
## aws\$1commons.create\$1aws\$1credentials
`aws_commons._aws_credentials_1` 構造でアクセスキーとシークレットキーを設定します。`aws_commons.create_aws_credentials` 関数の結果は、`credentials` 関数の [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3) パラメータで使用します。
### 構文
```
aws_commons.create_aws_credentials(
access_key text,
secret_key text,
session_token text
)
```
### パラメータ
*access\$1key*
Amazon S3 ファイルのインポートに使用するアクセスキーを含む必須のテキスト文字列。デフォルトは NULL です。
*secret\$1key*
Amazon S3 ファイルのインポートに使用するシークレットキーを含む必須のテキスト文字列。デフォルトは NULL です。
*session\$1token*
Amazon S3 ファイルのインポートに使用するセッショントークンを含む必須のテキスト文字列。デフォルトは NULL です。オプションの `session_token` を指定した場合は、一時的な認証情報を使用することができます。
# DB インスタンス 間での PostgreSQL データベースの移行
Amazon RDS の PostgreSQL トランスポータブルデータベースを使用することで、2 つの DB インスタンス間で PostgreSQL データベースを移行できます。この手法により、異なる DB インスタンス間での大規模なデータベースの移行が大幅に高速化されます。このアプローチを使用するには、対象の DB インスタンスの両方で、PostgreSQL の同じ主要バージョンを実行している必要があります。
この機能を使用するには、移行元の DB インスタンスと移行先の DB インスタンスで、ともに `pg_transport` 拡張機能をインストールします。`pg_transport` 拡張は、最小限のプロセスでデータベースファイルを移動するための、物理的な移行メカニズムを提供します。このメカニズムにより、ダンプとロードによる従来のプロセスと比較してデータの移行が大幅に高速化され、ダウンタイムが最小限に抑えられます。
**注記**
PostgreSQL トランスポータブルデータベースは、RDS for PostgreSQL 11.5 以降、および RDS for PostgreSQL のバージョン 10.10 以降で利用可能です。
ある RDS for PostgreSQL DB インスタンスから別のインスタンスへの、PostgreSQL DB インスタンスの移行を行うには、最初に、「[ 移行に向けた DB インスタンスの設定](PostgreSQL.TransportableDB.Setup.md)」での説明に従いながら、ソースインスタンスとデスティネーションインスタンスの設定を行います。その後、「[ PostgreSQL データベースの移行](PostgreSQL.TransportableDB.Transporting.md)」で説明されている関数を使用してデータベースを移行します。
**Topics**
+ [
## データベースの移行中に何が起こるか
](#PostgreSQL.TransportableDB.DuringTransport)
+ [
## PostgreSQL トランスポータブルデータベースの使用に関する制約事項
](#PostgreSQL.TransportableDB.Limits)
+ [
# PostgreSQL データベース移行の設定
](PostgreSQL.TransportableDB.Setup.md)
+ [
# 移行元から移行先への PostgreSQL データベースの転送
](PostgreSQL.TransportableDB.Transporting.md)
+ [
# トランスポータブルデータベースの関数リファレンス
](PostgreSQL.TransportableDB.transport.import_from_server.md)
+ [
# トランスポータブルデータベースのパラメータリファレンス
](PostgreSQL.TransportableDB.Parameters.md)
## データベースの移行中に何が起こるか
PostgreSQL のトランスポータブルデータベース機能は、移行先 DB インスタンスが移行元 DB インスタンスからデータベースをインポートするプルモデルを使用します。`transport.import_from_server` 関数を使うと、移行先 DB インスタンスで移行中のデータベースが作成されます。移行中、移行中のデータベースは、移行先 DB インスタンスではアクセスすることはできません。
移行スタートの際は、移行元データベースのすべての現在のセッションが終了します。移行元 DB インスタンスの移行元データベース以外のすべてのデータベースには移行による影響はありません。
移行元データベースは、特別な読み取り専用モードとなります。このモードの最中は、移行元データベースにアクセス可能で、読み取り専用のクエリを実行できます。ですが、書き込み可能なクエリやその他の種類のコマンドはブロックされます。移行された特定の移行元データベースのみがこれら制限による影響を受けます。
移行中、移行元 DB インスタンスは、ポイントインタイムの復元はできません。これは、移行がトランザクションではなく、変更を記録するための PostgreSQL ログ先行書き込みを使用しないからです。移行先 DB インスタンスの自動バックアップが有効になっていれば、移行後に、バックアップが自動で実行されます。ポイントインタイムの復元は、バックアップが終了した*後*に実行が可能になります。
移行に失敗した場合、`pg_transport` のエクステンションが、移行先/元 DB インスタンスで行ったすべての変更をやり直します。これには、移行先で一部のみ移行されたデータベースの削除も含まれます。失敗の内容によっては、移行元データベースで引き続き、書き込み可能クエリが拒否されます。これが発生した場合、以下のコマンドを使い、書き込み可能クエリを許可します。
```
ALTER DATABASE db-name SET default_transaction_read_only = false;
```
## PostgreSQL トランスポータブルデータベースの使用に関する制約事項
トランスポータブルデータベースには以下の制限があります。
+ **リードレプリカ** - リードレプリカまたはリードレプリカの親インスタンスでは、トランスポータブルデータベースを使用できません。
+ **サポートされていない列タイプ** - このメソッドを使用して移行するすべてのデータベーステーブル内の `reg` データ型を使用することはできません。これらタイプは、システムカタログオブジェクト ID (OID) に依存し、移行中に変わることがあります。
+ **テーブルスペース** -すべてのソースデータベースオブジェクトは既定の `pg_default` テーブルスペースに既存しなければいけません。
+ **互換性** - 移行先および移行元両方の DB インスタンスは、PostgreSQL の同じ主要バージョンを実行しなければなりません。
+ **拡張機能** – 移行元 DB インスタンスには、`pg_transport` のみがインストールされています。
+ **ロールおよび ACL** - 移行元データベースのアクセス権限および所有権情報は、移行先データベースには移行されません。すべてのデータベースオブジェクトは、移行するローカルの移行先ユーザーが作成および所有します。
+ **同時移行数** – ワーカープロセスが適切に設定されていれば、単一の DB インスタンスで同時に最大 32 個の (インポートとエクスポートの両方を含む) 移行をサポートできます。
+ **RDS for PostgreSQL DB インスタンスのみ** – PostgreSQL のトランスポータブルデータベースは、RDS for PostgreSQL DB インスタンスでのみサポートされます。オンプレミスのデータベースや Amazon EC2 で実行されているデータベースでは使用できません。
# PostgreSQL データベース移行の設定
この作業を開始する前に、対象の RDS for PostgreSQL DB インスタンスが、以下の要件を満たしていることを確認してください。
+ 移行先および移行元両方の RDS for PostgreSQL DB インスタンスは、PostgreSQL の同じバージョンを実行している必要があります。
+ 移行先の DB は、移行する元である DB と同じ名前のデータベースを持つことはできません。
+ 移行を実行するために使用するアカウントでは、移行元と移行先の両方の DB で、`rds_superuser` の権限が付与される必要があります。
+ 移行元 DB インスタンスのセキュリティグループは、移行先 DB インスタンスからのインバウンドアクセスを許可する必要があります。この許可は、移行元と移行先の DB インスタンスが VPC 内に存在する場合には、既に設定されている場合があります。セキュリティグループの詳細については、[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md) を参照してください。
データベースを移行元 DB インスタンスから移行先 DB インスタンスに移行する際には、各インスタンスに関連付けられた DB パラメータグループをいくつか変更する必要があります。つまり、移行元の DB インスタンスと移行先の DB インスタンスのそれぞれのために、カスタムの DB パラメータグループを作成する必要があります。
**注記**
DB インスタンスで、カスタム DB パラメータグループの使用が設定済みである場合は、以下の手順のステップ 2 から開始できます。
**データベースを移行するためのカスタム DB グループパラメータを構成するには**
以下の手順では、`rds_superuser` の権限を持つアカウントを使用します。
1. 移行元と移行先の DB インスタンスがデフォルトの DB パラメータグループを使用している場合は、そのインスタンス用として適切なバージョンの、カスタム DB パラメータグループを作成する必要があります。これにより、複数のパラメータの値を変更できるようになります。詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
1. カスタム DB パラメータグループ内で、以下のパラメータの値を変更します。
+ `shared_preload_libraries` – ライブラリのリストに `pg_transport` を追加します。
+ `pg_transport.num_workers` – デフォルト値は 3 です。データベースの必要に応じて、この値を増減します。200 GB のデータベースでは、8 以下を推奨します。このパラメータのデフォルト値を増加させた場合は、`max_worker_processes` の値も増やす必要があることに注意してください。
+ `pg_transport.work_mem` – デフォルト値は、PostgreSQL のバージョンによって 128 MB または 256 MB のどちらかになります。デフォルト設定は、通常、特に変更する必要はありません。
+ `max_worker_processes` — このパラメータの値は、次の計算を使用して設定する必要があります。
```
(3 * pg_transport.num_workers) + 9
```
この値は、トランスポートに関連するさまざまなバックグラウンドワーカープロセスを処理するために、接続先で必要です。`max_worker_processes,` の詳細については、PostgreSQL ドキュメントの「[Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html)」(資源の消費) を参照してください。
`pg_transport` パラメータの詳細については、「[トランスポータブルデータベースのパラメータリファレンス](PostgreSQL.TransportableDB.Parameters.md)」を参照してください。
1. 移行元と移行先の RDS for PostgreSQL DB インスタンスをともに再起動して、パラメータの設定を有効にします。
1. 移行元の RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=source-instance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. DB インスタンスのパブリックスキーマから無関係な拡張機能を削除します。実際の移行オペレーション中に使用が許可されるのは、`pg_transport` 拡張機能のみです。
1. 次のように `pg_transport` 拡張機能をインストールします。
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
1. 移行先の RDS for PostgreSQL DB インスタンスに接続します。無関係な拡張機能をすべて削除した上で、`pg_transport` 拡張機能をインストールします。
```
postgres=> CREATE EXTENSION pg_transport;
CREATE EXTENSION
```
# 移行元から移行先への PostgreSQL データベースの転送
[PostgreSQL データベース移行の設定](PostgreSQL.TransportableDB.Setup.md) で記載したプロセスを完了すると、移行をスタートすることが可能です。移行をスタートするには、移行先 DB インスタンスで `transport.import_from_server` 関数を実行します。次の構文では、関数に使用するパラメータを確認できます。
```
SELECT transport.import_from_server(
'source-db-instance-endpoint',
source-db-instance-port,
'source-db-instance-user',
'source-user-password',
'source-database-name',
'destination-user-password',
false);
```
この例での `false` 値は、この処理がドライランではないことを関数に伝えます。移行の設定をテストするには、以下のように、関数の呼び出し時に `dry_run` オプションで `true` を指定します。
```
postgres=> SELECT transport.import_from_server(
'docs-lab-source-db.666666666666aws-region.rds.amazonaws.com', 5432,
'postgres', '********', 'labdb', '******', true);
INFO: Starting dry-run of import of database "labdb".
INFO: Created connections to remote database (took 0.03 seconds).
INFO: Checked remote cluster compatibility (took 0.05 seconds).
INFO: Dry-run complete (took 0.08 seconds total).
import_from_server
--------------------
(1 row)
```
`pg_transport.timing` パラメータがデフォルト値の `true` に設定されているため、INFO 行が出力されます。次に示すように、`dry_run` に `false` を設定してコマンドを実行し、データベースを移行元から移行先にインポートします。
```
INFO: Starting import of database "labdb".
INFO: Created connections to remote database (took 0.02 seconds).
INFO: Marked remote database as read only (took 0.13 seconds).
INFO: Checked remote cluster compatibility (took 0.03 seconds).
INFO: Signaled creation of PITR blackout window (took 2.01 seconds).
INFO: Applied remote database schema pre-data (took 0.50 seconds).
INFO: Created connections to local cluster (took 0.01 seconds).
INFO: Locked down destination database (took 0.00 seconds).
INFO: Completed transfer of database files (took 0.24 seconds).
INFO: Completed clean up (took 1.02 seconds).
INFO: Physical transport complete (took 3.97 seconds total).
import_from_server
--------------------
(1 row)
```
この関数には、データベースユーザーパスワードを入力する必要があります。よって、移行完了後は、使用したユーザーロールのパスワードを変更することをお勧めします。または、SQL のバインド可変を使用するとユーザーロールを一時的に作成することができます。このようなテンポラリロールを移行に使ったら、破棄することが可能です。
移行が成功しなかった場合、次のようなエラーメッセージが表示されることがあります。
```
pg_transport.num_workers=8 25% of files transported failed to download file data
```
「failed to download file data (ファイルデータのダウンロードに失敗しました)」というエラーメッセージは、データベースのサイズに対してワーカープロセスの数が正しく設定されていないことを示します。`pg_transport.num_workers` に設定した値の増減が必要な場合があります。失敗が発生するたびに、処理の完了率がレポートされるため、変更の影響度合いを確認できます。例えば、あるケースで設定を 8 から 4 に変更した場合、次のような結果になります。
```
pg_transport.num_workers=4 75% of files transported failed to download file data
```
`max_worker_processes` パラメーターは、移行のプロセス中にも考慮されることにご留意ください。つまり、データベースを正常に移行するためには、`pg_transport.num_workers` と `max_worker_processes` の両方で変更が必要な場合があります。`pg_transport.num_workers` に 2 を設定することで、最終的にこの例は正しく機能します。
```
pg_transport.num_workers=2 100% of files transported
```
`transport.import_from_server` 関数とそのパラメータの詳細については、「[トランスポータブルデータベースの関数リファレンス](PostgreSQL.TransportableDB.transport.import_from_server.md)」を参照してください。
# トランスポータブルデータベースの関数リファレンス
`transport.import_from_server` 関数は、PostgreSQL データベースを移行元 DB インスタンスから移行先 DB インスタンスにインポートします。これは、物理的なデータベース接続移行メカニズムを使って実行されます。
この関数は、移行元と移行先の DB インスタンスが同じバージョンであり、移行のための互換性があることを、移行の開始前に確認します。また、移行先の DB インスタンスに、移行元のサイズに見合うの十分な領域があることも確認します。
**[Syntax]** (構文)
```
transport.import_from_server(
host text,
port int,
username text,
password text,
database text,
local_password text,
dry_run bool
)
```
**戻り値**
なし。
パラメータ****
`transport.import_from_server` 関数パラメータの説明に関しては、以下のテーブルをご参照ください。
****
| Parameter | 説明 |
| --- | --- |
| host | 移行元 DB インスタンスのエンドポイント。 |
| port | 整数は、移行元 DB インスタンスを表しています。PostgreSQL DB インスタンスは、通常ポート 5432 を使います。 |
| username | 移行元 DB インスタンスのユーザー。このユーザーは、`rds_superuser` ロールのメンバーでなければなりません。 |
| password | 移行元 DB インスタンスのユーザーパスワード。 |
| database | 移行する移行元 DB インスタンスのデータベース名。 |
| local\$1password | 移行先 DB インスタンスの現在のユーザーのローカルパスワード。このユーザーは、`rds_superuser` ロールのメンバーでなければなりません。 |
| dry\$1run | リハーサルを実施するかどうかを判断する任意のブール値。デフォルトは、`false` で、移行を実行することを意味します。実際に移行せずに、移行元と移行先 DB インスタンスの互換性を確認するには、dry\$1run を true に設定します。 |
**例**
例については、「[移行元から移行先への PostgreSQL データベースの転送](PostgreSQL.TransportableDB.Transporting.md)」を参照してください。
# トランスポータブルデータベースのパラメータリファレンス
複数のパラメータにより、`pg_transport` 拡張機能の動作が制御されます。以下で、これらのパラメータの説明を参照してください。
**`pg_transport.num_workers`**
移行プロセスに使用するワーカー数。デフォルトは 3 です。有効な値は、1-32 です。大規模なデータベースを移行する場合でも、通常必要なワーカー数は 8 未満です。移行中には、移行先 DB インスタンスの設定が、移行先および移行元の両方の DB インスタンスで使用されます。
**`pg_transport.timing` **
移行中にタイミング情報を報告するかどうかを指定します。デフォルトは `true` で、タイミング情報が報告されることを意味します。進行状況を監視できるようにするため、このパラメータは `true` に設定しておくことをお勧めします。出力例については、「[移行元から移行先への PostgreSQL データベースの転送](PostgreSQL.TransportableDB.Transporting.md)」を参照してください。
**`pg_transport.work_mem`**
メモリの最大容量を各ワーカーに配分する。PostgreSQL のバージョンに応じて、この設定のデフォルトは、131,072 キロバイト (KB) または 262,144 KB (256 MB) のどちらかになります。最小値は 64 メガバイト (65,536 KB) です。2 進法ベースの 2 ユニット (1 KB = 1,024 バイト) なので、有効値は、キロバイト (KB) で表記されます。
移行は、このパラメータで指定されたメモリより少ないメモリを使う場合があります。移行するデータベースが大規模な場合でも、通常必要なメモリは、ワーカー当たり 256 MB (262,144 KB) 未満です。
# RDS for PostgreSQL DB インスタンスから Amazon S3 へのデータのエクスポート
RDS for PostgreSQL DB インスタンスからデータをクエリし、Amazon S3 バケットに保存されているファイルに直接エクスポートできます。これを行うには、 RDS for PostgreSQL `aws_s3`拡張機能を最初にインストールします。このエクステンションでは、Amazon S3 へのクエリの結果のエクスポートに使用する関数が利用できます。次に、拡張機能のインストール方法と Amazon S3 へのデータのエクスポート方法を説明します。
**注記**
クロスアカウントでの Amazon S3 はサポートされていません。
現在利用可能な RDS for PostgreSQL のバージョンでは、データの Amazon Simple Storage Service へのエクスポートがサポートされています。詳細なバージョン情報については、「*Amazon RDS for PostgreSQL リリースノート*」の「[Amazon RDS for PostgreSQL の更新](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html)」を参照してください。
エクスポートにバケットを設定していない場合は、*Amazon Simple Storage Service ユーザーガイド*で次のトピックを参照してください。
+ [Amazon S3 のセットアップ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html)
+ [バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)
デフォルトでは、RDS for PostgreSQL から Amazon S3 にエクスポートされたデータは、AWS マネージドキー によるサーバー側の暗号化が使用されます。バケット暗号化を使用している場合は、Amazon S3 バケットは AWS Key Management Service (AWS KMS) キー (SSE-KMS) で暗号化されている必要があります。現在、Amazon S3 マネージドキー (SSE-S3) で暗号化されたバケットはサポートされていません。
**注記**
AWS マネジメントコンソール、AWS CLI、または Amazon RDS API を使用して、DB スナップショットのデータを Amazon S3 に保存できます。詳しくは、「[Amazon RDS の Amazon S3 への DB スナップショットデータのエクスポート](USER_ExportSnapshot.md)」を参照してください。
**Topics**
+ [
## aws\$1s3 拡張機能のインストール
](#USER_PostgreSQL.S3Export.InstallExtension)
+ [
## Amazon S3 へのデータのエクスポートの概要
](#postgresql-s3-export-overview)
+ [
## エクスポート先の Amazon S3 ファイルパスを指定する
](#postgresql-s3-export-file)
+ [
# Amazon S3 バケットへのアクセスを設定する
](postgresql-s3-export-access-bucket.md)
+ [
# aws\$1s3.query\$1export\$1to\$1s3 関数を使用したクエリデータのエクスポート
](postgresql-s3-export-examples.md)
+ [
# 関数リファレンス
](postgresql-s3-export-functions.md)
+ [
# Amazon S3 へのアクセスのトラブルシューティング
](postgresql-s3-export-troubleshoot.md)
## aws\$1s3 拡張機能のインストール
RDS for PostgreSQL DB インスタンスで Amazon Simple Storage Service を使用する前に、`aws_s3` 拡張機能をインストールする必要があります。この拡張機能には、 RDS for PostgreSQL DB インスタンスから Amazon S3 バケットへデータをエクスポートするための関数も含まれています。また、Amazon S3 からデータをインポートするための関数も含まれます。詳しくは、「[Amazon S3 から RDS for PostgreSQL DB インスタンスにデータをインポートする](USER_PostgreSQL.S3Import.md)」を参照してください。`aws_s3` 拡張機能は `aws_commons` 拡張機能の一部のヘルパー関数に依存しており、必要に応じて自動的にインストールされます。
**`aws_s3` 拡張機能をインストールするには**
1. `rds_superuser` 権限があるユーザーとして、psql (または pgAdmin) を使用して RDS for PostgreSQL DB インスタンスに接続します。設定プロセス中にデフォルトの名前を保持している場合は、`postgres` として接続します。
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. 拡張機能をインストールするには、次のコマンドを実行します。
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. 拡張機能がインストールされていることを確認するには、psql `\dx` メタコマンドを使用します。
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
Amazon S3 からデータをインポートし、データを Amazon S3 にエクスポートするための関数が使用できるようになりました。
### ご使用の RDS for PostgreSQL バージョンで、Amazon S3 へのエクスポートがサポートされていることを確認します
`describe-db-engine-versions` コマンドを使用して、RDS for PostgreSQL バージョンが Amazon S3 へのエクスポートをサポートしていることを確認できます。次に、バージョン 10.14 のサポートを確認する例を示します。
```
aws rds describe-db-engine-versions --region us-east-1
--engine postgres --engine-version 10.14 | grep s3Export
```
出力に `"s3Export"` の文字列が含まれている場合 、エンジンは Amazon S3 エクスポートをサポートします。それ以外の場合、エンジンはエクスポートをサポートしません。
## Amazon S3 へのデータのエクスポートの概要
RDS for PostgreSQL データベースに格納されたデータを Amazon S3 バケットにエクスポートするには、以下の手順に従います。
**RDS for PostgreSQL データを S3 にエクスポートするには**
1. データのエクスポートに使用する Amazon S3 ファイルパスを指定します。このプロセスの詳細については、「[エクスポート先の Amazon S3 ファイルパスを指定する](#postgresql-s3-export-file)」を参照してください。
1. Amazon S3 バケットへのアクセス許可を提供します。
Amazon S3 ファイルにデータをエクスポートするには、RDS for PostgreSQL DB インスタンスに、エクスポートの際に保存に使用される Amazon S3 バケットへのアクセス許可を付与する必要があります。これには、次のステップが含まれます。
1. エクスポート先の Amazon S3 バケットへのアクセスを提供する IAM ポリシーを作成します。
1. IAM ロールを作成します。
1. 作成したポリシーを、作成したロールにアタッチします。
1. この IAM ロールを DB インスタンスに追加します。
このプロセスの詳細については、「[Amazon S3 バケットへのアクセスを設定する](postgresql-s3-export-access-bucket.md)」を参照してください。
1. データを取得するためのデータベースクエリを識別します。`aws_s3.query_export_to_s3` 関数を呼び出して、クエリデータをエクスポートします。
前述の準備タスクを完了したら、[aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) 関数を使用してクエリ結果を Amazon S3 にエクスポートします。このプロセスの詳細については、「[aws\$1s3.query\$1export\$1to\$1s3 関数を使用したクエリデータのエクスポート](postgresql-s3-export-examples.md)」を参照してください。
## エクスポート先の Amazon S3 ファイルパスを指定する
次の情報を指定して、Amazon S3 データのエクスポート先となる場所を指定します。
+ バケット名 - *バケット*は、Amazon S3 オブジェクトまたはファイルのコンテナです。
Amazon S3 を使用したデータの保存の詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)」と「[オブジェクトの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-downloading-objects.html)」を参照してください。
+ ファイルパス - ファイルパスは、Amazon S3 バケット内のエクスポートが格納される場所を識別します。ファイルパスは、次のもので構成されます。
+ 仮想フォルダパスを識別するオプションのパスプレフィックス。
+ 保存する 1 つ以上のファイルを識別するファイルプレフィックス。より大きなエクスポートは複数のファイルに格納され、それぞれの最大サイズは約 6 GB です。追加のファイル名には、同じファイルプレフィックスが付いていますが、末尾に `_partXX` が付加されます。`XX` は、2、3 などを表します。
例えば、`exports` フォルダとファイルプレフィックスを持つ `query-1-export` ファイルパスは `/exports/query-1-export` です。
+ AWS リージョン (オプション) - Amazon S3 バケットがある AWS リージョン。AWS リージョンの値を指定しない場合、Amazon RDS は、エクスポートする DB インスタンスと同じ AWS リージョンの Amazon S3 にファイルを保存します。
**注記**
現在、AWS リージョンは、エクスポートする DB インスタンスのリージョンと同じである必要があります。
AWS リージョン名と関連する値のリストについては、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
エクスポートの保存先に関する Amazon S3 ファイル情報を保持するには、 [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) 関数を使用して、次のように `aws_commons._s3_uri_1` 複合構造を作成します。
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
その後、この `s3_uri_1` 値を [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) 関数の呼び出しでパラメータとして指定します。例については、「[aws\$1s3.query\$1export\$1to\$1s3 関数を使用したクエリデータのエクスポート](postgresql-s3-export-examples.md)」を参照してください。
# Amazon S3 バケットへのアクセスを設定する
データを Amazon S3 にエクスポートするには、PostgreSQL DB インスタンスに、ファイルが入る Amazon S3 バケットに対するアクセス許可を付与します。
これには、以下の手順を使用します。
**IAM ロールを介して PostgreSQLDB のインスタンスに Amazon S3 へのアクセスを許可するには**
1. IAM ポリシーを作成します。
このポリシーは、PostgreSQL DB インスタンスに、Amazon S3 のバケットとオブジェクトに対するアクセス許可を付与します。
このポリシーの作成の一環として、次のステップを実行します。
1. ポリシーに、PostgreSQL DB インスタンスから Amazon S3 バケットへのファイル転送を許可するための以下の必須アクションを含めます。
+ `s3:PutObject`
+ `s3:AbortMultipartUpload`
1. Amazon S3 バケットとバケット内のオブジェクトを識別する Amazon リソースネーム (ARN) を含めます。Amazon S3 アクセス用の ARN 形式は `arn:aws:s3:::amzn-s3-demo-bucket/*` です。
Amazon RDS for PostgreSQL の IAM ポリシーの作成の詳細については、[IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md) を参照してください。*IAM ユーザーガイド*の「[チュートリアル: はじめてのカスタマー管理ポリシーの作成とアタッチ](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html)」も参照してください。
以下の AWS CLI コマンドでは、これらのオプションを指定して、`rds-s3-export-policy` という名前の IAM ポリシーを作成します。*amzn-s3-demo-bucket* という名前のバケットへのアクセスを許可します。
**警告**
特定のバケットにアクセスするようにエンドポイントポリシーが設定されているプライベート VPC 内にデータベースをセットアップすることをお勧めします。詳細については、Amazon VPC ユーザーガイドの「[Amazon S3 のエンドポイントポリシーの使用](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html#vpc-endpoints-policies-s3)」を参照してください。
すべてのリソースへのアクセスを持つポリシーを作成しないことを強くお勧めします。このアクセスは、データセキュリティにとって脅威になる可能性があります。`S3:PutObject` を使用してすべてのリソースへのアクセスを `"Resource":"*"` に許可するポリシーを作成すると、エクスポート権限を持つユーザーはアカウント内のすべてのバケットにデータをエクスポートできます。さらに、ユーザーは *AWS リージョン内のパブリックに書き込み可能なバケットにデータをエクスポートできます*。
ポリシーを作成したら、そのポリシーの Amazon リソースネーム (ARN) を書き留めます。ポリシーを IAM ロールにアタッチする場合、後続のステップで ARN が必要です。
```
aws iam create-policy --policy-name rds-s3-export-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3export",
"Action": [
"s3:PutObject*",
"s3:ListBucket",
"s3:GetObject*",
"s3:DeleteObject*",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. IAM ロールを作成します。
これを行うと、Amazon RDS がユーザーに代わってこの IAM ロールを引き受け、Amazon S3 バケットにアクセスできます。詳細については、*IAM ユーザーガイド*の「[IAM ユーザーにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)」を参照してください。
リソースポリシー内では `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` および `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` のグローバル条件コンテキストキーを使用して、サービスに付与するリソースへのアクセス許可を制限することをお勧めします。これは、[混乱した使節の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)に対する最も効果的な保護方法です。
グローバル条件コンテキストキーの両方を使用し、`aws:SourceArn` の値にアカウント ID が含まれている場合、同じポリシーステートメントで使用する場合は、`aws:SourceArn` の値と `aws:SourceAccount` の値のアカウントでは同じアカウント ID を使用する必要があります。
+ 単一リソースに対するクロスサービスアクセスが必要な場合は `aws:SourceArn` を使用します。
+ そのアカウント内の任意のリソースをクロスサービス使用に関連付けることを許可する場合、`aws:SourceAccount`を使用します。
ポリシーでは、必ずリソースの完全な ARN を持つ `aws:SourceArn` グローバル条件コンテキストキーを使用してください。以下の例は、AWS CLI コマンドを使用して、`rds-s3-export-role` という名前のロールを作成する方法を示しています。
**Example**
Linux、macOS、Unix の場合:
```
aws iam create-role \
--role-name rds-s3-export-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
Windows の場合:
```
aws iam create-role ^
--role-name rds-s3-export-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:db:dbname"
}
}
}
]
}'
```
1. 作成した IAM ポリシーを、作成した IAM ロールにアタッチします。
次の AWS CLI コマンドは、先ほど作成したポリシーを `rds-s3-export-role.` という名前のロールにアタッチします。`your-policy-arn` を前のステップでメモしたポリシー ARN に置き換えます。
```
aws iam attach-role-policy --policy-arn your-policy-arn --role-name rds-s3-export-role
```
1. DB インスタンスに IAM ロールを追加します。これを行うには、以下で説明するように、AWS マネジメントコンソール または AWS CLI を使用します。
## コンソール
**コンソールを使用して PostgreSQL DB インスタンスの IAM ロールを追加するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. 詳細を表示するには、PostgreSQL DB インスタンスの名前を選択します。
1. [**接続とセキュリティ**] タブの [**IAM ロールの管理**] セクションで、[**このインスタンスに IAM ロールを追加**] で追加するロールを選択します。
1. [**Feature**] で、[**s3Export**] を選択します。
1. [**Add role**] を選択します。
## AWS CLI
**CLI を使用して PostgreSQL DB インスタンスの IAM ロールを追加するには**
+ 次のコマンドを使用して、`my-db-instance` という名前の PostgreSQL DB インスタンスにロールを追加します。*`your-role-arn`* を、以前のステップで書き留めたロール ARN に置き換えます。`s3Export` オプションの値に `--feature-name` を使用します。
**Example**
Linux、macOS、Unix の場合:
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-db-instance \
--feature-name s3Export \
--role-arn your-role-arn \
--region your-region
```
Windows の場合:
```
aws rds add-role-to-db-instance ^
--db-instance-identifier my-db-instance ^
--feature-name s3Export ^
--role-arn your-role-arn ^
--region your-region
```
# aws\$1s3.query\$1export\$1to\$1s3 関数を使用したクエリデータのエクスポート
[aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) 関数を呼び出して、PostgreSQL データを Amazon S3 にエクスポートします。
**Topics**
+ [
## 前提条件
](#postgresql-s3-export-examples-prerequisites)
+ [
## aws\$1s3.query\$1export\$1to\$1s3 の呼び出し
](#postgresql-s3-export-examples-basic)
+ [
## カスタム区切り文字を使用する CSV ファイルへのエクスポート
](#postgresql-s3-export-examples-custom-delimiter)
+ [
## エンコードを使用したバイナリファイルへのエクスポート
](#postgresql-s3-export-examples-encoded)
## 前提条件
`aws_s3.query_export_to_s3` 関数を使用する前に、以下の前提条件を満たしていることを確認してください。
+ 「[Amazon S3 へのデータのエクスポートの概要](postgresql-s3-export.md#postgresql-s3-export-overview)」の説明に従って、必要な PostgreSQL エクステンションをインストールします。
+ 「[エクスポート先の Amazon S3 ファイルパスを指定する](postgresql-s3-export.md#postgresql-s3-export-file)。」の説明に従って、データの Amazon S3 のエクスポート先を決定します。
+ 「[Amazon S3 バケットへのアクセスを設定する](postgresql-s3-export-access-bucket.md)」の説明にとおり、DB インスタンスが Amazon S3 へのエクスポートアクセス権があることを確認します。
次の例では、`sample_table` というデータベーステーブルを使用しています。次の例では、データを *amzn-s3-demo-bucket* というバケットにエクスポートします。サンプルのテーブルとデータは、psql で次の SQL ステートメントを使用して作成されます。
```
psql=> CREATE TABLE sample_table (bid bigint PRIMARY KEY, name varchar(80));
psql=> INSERT INTO sample_table (bid,name) VALUES (1, 'Monday'), (2,'Tuesday'), (3, 'Wednesday');
```
## aws\$1s3.query\$1export\$1to\$1s3 の呼び出し
次に、 [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) 関数を呼び出す基本的な方法を示します。
これらの例では、可変 `s3_uri_1` を使用して、Amazon S3 ファイルを識別する情報を含む構造を指定しています。[aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) 関数を使用して構造を作成します。
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
以下の 2 つの `aws_s3.query_export_to_s3` 関数呼び出しのパラメータは異なりますが、これらの例の結果は同じです。`sample_table` テーブルのすべての行が *amzn-s3-demo-bucket* というバケットにエクスポートされます。
```
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1');
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1', options :='format text');
```
パラメータの説明は次のとおりです。
+ `'SELECT * FROM sample_table'` - 初期のパラメータは、SQL クエリを含む必須のテキスト文字列です。PostgreSQL エンジンはこのクエリを実行します。クエリの結果は、他のパラメータで指定された S3 バケットにコピーされます。
+ `:'s3_uri_1'` - このパラメータは、Amazon S3 ファイルを識別する構造です。この例では、可変を使用して、前に作成した構造を指定します。代わりに、以下のように `aws_commons.create_s3_uri` 関数呼び出し内にインラインで `aws_s3.query_export_to_s3` 関数呼び出しを含めることで、同じ構造を作成できます。
```
SELECT * from aws_s3.query_export_to_s3('select * from sample_table',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'sample-filepath', 'us-west-2')
);
```
+ `options :='format text'` - `options` パラメータは、PostgreSQL `COPY` 引数を含むオプションのテキスト文字列です。このコピープロセスでは、[PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) コマンドの引数と形式を使用します。
指定したファイルが Amazon S3 バケットに存在しない場合は、作成されます。このファイルが存在している場合は、上書きされます。Amazon S3 でエクスポートされたデータにアクセスするための構文は次のとおりです。
```
s3-region://bucket-name[/path-prefix]/file-prefix
```
より大きなエクスポートは複数のファイルに格納され、それぞれの最大サイズは約 6 GB です。追加のファイル名には、同じファイルプレフィックスが付いていますが、末尾に `_partXX` が付加されます。`XX` は、2、3 などを表します。例えば、次のようにデータファイルを格納するパスを指定するとします。
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
```
エクスポートで 3 つのデータファイルを作成する必要がある場合、Amazon S3 バケットには次のデータファイルが含まれます。
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part2
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part3
```
この関数の完全なリファレンスと、それを呼び出すその他の方法については、「[aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3)」を参照してください。Amazon S3 でファイルにアクセスする方法の詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[View an object](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html)」を参照してください。
## カスタム区切り文字を使用する CSV ファイルへのエクスポート
次の例は、[aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) 関数を呼び出して、カスタム区切り文字を使用するファイルにデータをエクスポートする方法を示しています。この例では、[PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) コマンドの引数を使用して、カンマ区切り値 (CSV) 形式とコロン (:) 区切り文字を指定します。
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format csv, delimiter $$:$$');
```
## エンコードを使用したバイナリファイルへのエクスポート
次の例は、[aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) 関数を呼び出して、Windows-1253 エンコーディングのバイナリファイルにデータをエクスポートする方法を示しています。
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format binary, encoding WIN1253');
```
# 関数リファレンス
**Topics**
+ [
## aws\$1s3.query\$1export\$1to\$1s3
](#aws_s3.export_query_to_s3)
+ [
## aws\$1commons.create\$1s3\$1uri
](#aws_commons.create_s3_uri)
## aws\$1s3.query\$1export\$1to\$1s3
PostgreSQL クエリ結果を Amazon S3 バケットにエクスポートします。`aws_s3` エクステンションには、`aws_s3.query_export_to_s3` 関数が含まれます。
2 つの必須パラメータは、`query` および `s3_info` です。これらは、エクスポートするクエリを定義し、エクスポート先の Amazon S3 バケットを特定します。`options` と呼ばれるオプションのパラメータは、さまざまなエクスポートパラメータを定義するために用意されています。`aws_s3.query_export_to_s3` 関数の使用例については、「[aws\$1s3.query\$1export\$1to\$1s3 関数を使用したクエリデータのエクスポート](postgresql-s3-export-examples.md)」を参照してください。
**構文**
```
aws_s3.query_export_to_s3(
query text,
s3_info aws_commons._s3_uri_1,
options text,
kms_key text
)
```入力パラメータ
*query*()
PostgreSQL エンジンが実行する SQL クエリを含む必須のテキスト文字列。このクエリ結果は、 `s3_info` パラメータで指定された S3 バケットにコピーされます。
*s3\$1info*
S3 オブジェクトに関する以下の情報を含む `aws_commons._s3_uri_1` 複合型。
+ `bucket` - ファイルを格納する Amazon S3 バケットの名前。
+ `file_path` - Amazon S3 ファイル名とパス
+ `region` - バケットが存在する AWS リージョン。AWS リージョン名と関連する値のリストについては、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
現在、この値は、エクスポートする DB DB インスタンスの AWS リージョンと同じリージョンである必要があります。デフォルトは、エクスポートする DB DB インスタンスの AWS リージョンです。
`aws_commons._s3_uri_1` 複合構造を作成するには、[aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri) 関数を参照してください。
*options*
PostgreSQL `COPY` コマンドの引数を含むオプションのテキスト文字列。これらの引数は、エクスポート時のデータのコピー方法を指定します。詳細については、「[PostgreSQL COPY ドキュメント](https://www.postgresql.org/docs/current/sql-copy.html)」を参照してください。
*kms\$1key text*
データのエクスポート先となる S3 バケットのカスタマーマネージド KMS キーを含む任意のテキスト文字列。
### 代替入力パラメータ
テストしやすいように、`s3_info` パラメータではなく、拡張されたパラメータセットを使用することができます。以下は、`aws_s3.query_export_to_s3` 関数の構文のバリエーションです。
Amazon S3 ファイルを識別するために `s3_info` パラメータを使用する代わりに、`bucket`、`file_path`、および `region` パラメータの組み合わせを使用します。
```
aws_s3.query_export_to_s3(
query text,
bucket text,
file_path text,
region text,
options text,
kms_key text
)
```
*query*()
PostgreSQL エンジンが実行する SQL クエリを含む必須のテキスト文字列。このクエリ結果は、 `s3_info` パラメータで指定された S3 バケットにコピーされます。
*バケット*
ファイルを含む Amazon S3 バケットの名前を含む必須テキスト文字列。
*file\$1path*
ファイルのパスを含む Amazon S3 ファイル名を含む必須テキスト文字列。
*リージョン*
バケットが存在する AWS リージョンを含むオプションのテキスト文字列。AWS リージョン名と関連する値のリストについては、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
現在、この値は、エクスポートする DB DB インスタンスの AWS リージョンと同じリージョンである必要があります。デフォルトは、エクスポートする DB DB インスタンスの AWS リージョンです。
*options*
PostgreSQL `COPY` コマンドの引数を含むオプションのテキスト文字列。これらの引数は、エクスポート時のデータのコピー方法を指定します。詳細については、「[PostgreSQL COPY ドキュメント](https://www.postgresql.org/docs/current/sql-copy.html)」を参照してください。
*kms\$1key text*
データのエクスポート先となる S3 バケットのカスタマーマネージド KMS キーを含む任意のテキスト文字列。
### 出力パラメータ
```
aws_s3.query_export_to_s3(
OUT rows_uploaded bigint,
OUT files_uploaded bigint,
OUT bytes_uploaded bigint
)
```
*rows\$1uploaded*
指定されたクエリで Amazon S3 に正常にアップロードされたテーブルローの数。
*files\$1uploaded*
Amazon S3 にアップロードされたファイルの数。ファイルは、約 6 GB のサイズで作成されます。作成される各追加ファイルは、名前に `_partXX` が付加されています。`XX` は、必要に応じて 2、3 などを表します。
*bytes\$1uploaded*
Amazon S3 にアップロードされた合計バイト数。
### 例
```
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2','format text');
```
## aws\$1commons.create\$1s3\$1uri
Amazon S3 ファイル情報を保持するように、`aws_commons._s3_uri_1` 構造を作成します。`aws_commons.create_s3_uri` 関数の結果は、`s3_info` 関数の [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3) パラメータで使用します。`aws_commons.create_s3_uri` 関数の使用例については、「[エクスポート先の Amazon S3 ファイルパスを指定する](postgresql-s3-export.md#postgresql-s3-export-file)」を参照してください。
**Syntax**
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```入力パラメータ
*バケット*
ファイルの Amazon S3 バケット名を含む必須のテキスト文字列。
*file\$1path*
ファイルのパスを含む Amazon S3 ファイル名を含む必須テキスト文字列。
*リージョン*
ファイルがある AWS リージョンを含む必須のテキスト文字列。AWS リージョン名と関連する値のリストについては、「[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)」を参照してください。
# Amazon S3 へのアクセスのトラブルシューティング
Amazon S3 へのデータのエクスポート試行時に接続の問題が発生した場合は、まず DB インスタンスに関連付けられた VPC セキュリティグループのアウトバウンドアクセスルールがネットワーク接続を許可していることを確認します。具体的には、DB インスタンスにポート 443 および任意の IPv4 アドレス (0.0.0.0/0) への TCP トラフィックの送信を許可するルールをセキュリティグループに作成します。詳細については、「[セキュリティグループを作成して VPC 内の DB インスタンスへのアクセスを提供する](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup)」を参照してください。
推奨事項については、以下も参照してください。
+ [Amazon RDS のアイデンティティおよびアクセスのトラブルシューティング](security_iam_troubleshoot.md)
+ *Amazon Simple Storage Service ユーザーガイド* の「[Troubleshooting Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html)」
+ *IAM ユーザーガイド* の [Amazon S3 のトラブルシューティングと IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html)
# RDS for PostgreSQL DB インスタンスから AWS Lambda 関数を呼び出す
AWS Lambda は、サーバーのプロビジョニングや管理を行わなくてもコードの実行が可能な、イベント駆動型のコンピューティングサービスです。この機能は、RDS for PostgreSQL を含む多くの AWS サービスで利用可能です。例えば、データベースからのイベント通知の処理や、新しいファイルが Amazon S3 にアップロードされるたびに行うファイルからのデータロードのために、Lambda を使用することができます。詳細については、「*AWS Lambda デベロッパーガイド*の「[AWS Lambda とは](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)」を参照してください。
**注記**
RDS for PostgreSQL では、以下のバージョンで AWS Lambda 関数の呼び出しがサポートされています。
すべての PostgreSQL 18 バージョン
すべての PostgreSQL 17 バージョン
すべての PostgreSQL 16 バージョン
すべての PostgreSQL 15 バージョン
PostgreSQL 14.1 以降のマイナーバージョン
PostgreSQL 13.2 以降のマイナーバージョン
PostgreSQL 12.6 以降のマイナーバージョン
RDS for PostgreSQL で Lambda 関数を操作するためのセットアップは、AWS Lambda、IAM、VPC、および RDS for PostgreSQL DB インスタンスが関係する複数ステップのプロセスとなります。以下に、必要なステップの概要を示します。
Lambda 関数の詳細については、「*AWS Lambda デベロッパーガイド*」の「[Lambda の開始方法](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html)」および「[AWS Lambda の基礎](https://docs.aws.amazon.com/lambda/latest/dg/lambda-foundation.html)」を参照してください。
**Topics**
+ [
## ステップ 1: RDS for PostgreSQL DB インスタンスで、AWS Lambda へのアウトバウンド接続を設定する。
](#PostgreSQL-Lambda-network)
+ [
## ステップ 2: RDS for PostgreSQL DB インスタンスおよび AWS Lambda のために IAM を設定する
](#PostgreSQL-Lambda-access)
+ [
## ステップ 3: RDS for PostgreSQL DB インスタンス用に `aws_lambda` 拡張機能をインストールする
](#PostgreSQL-Lambda-install-extension)
+ [
## ステップ 4: RDS for PostgreSQL DB インスタンスで Lambda のヘルパー関数を使用する (オプション)
](#PostgreSQL-Lambda-specify-function)
+ [
## ステップ 5: RDS for PostgreSQL DB インスタンスから Lambda 関数を呼びだす
](#PostgreSQL-Lambda-invoke)
+ [
## ステップ 6: Lambda 関数を呼び出すその他のユーザー許可を付与する
](#PostgreSQL-Lambda-grant-users-permissions)
+ [
# 例: RDS for PostgreSQL DB インスタンスから Lambda 関数を呼びだす
](PostgreSQL-Lambda-examples.md)
+ [
# Lambda 関数のエラーメッセージ
](PostgreSQL-Lambda-errors.md)
+ [
# AWS Lambda 関数とパラメータのリファレンス
](PostgreSQL-Lambda-functions.md)
## ステップ 1: RDS for PostgreSQL DB インスタンスで、AWS Lambda へのアウトバウンド接続を設定する。
Lambda 関数は、常に AWS Lambda サービスが所有する Amazon VPC 内で実行されます。Lambda はこの VPC にネットワークアクセスとセキュリティルールを適用し、この VPC を自動的にモニタリングおよび維持します。RDS for PostgreSQL DB インスタンスは、Lambda サービスの VPC にネットワークトラフィックを送信します。このための構成方法は、DB インスタンスが、パブリックであるかプライベートであるかにより異なります。
+ **パブリック RDS for PostgreSQL DB インスタンス** — VPC のパブリックサブネット内に置かれた DB インスタンスで、「PubliclyAccessible」プロパティに `true` が設定されている場合、そのインスタンスはパブリックです。このプロパティの値は、AWS CLI コマンド [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) を使用して確認できます。または、AWS マネジメントコンソール を使用して **[Connectivity & security]** (接続とセキュリティ) タブを開き、**[Publicly accessible]** (パブリックアクセス可能) が「**はい**」となっているかを確認します。インスタンスが VPC のパブリックサブネット内に置かれていることを確認するには、AWS マネジメントコンソール または AWS CLI を使用します。
Lambda へのアクセスを設定するには、AWS マネジメントコンソール または AWS CLI を使用して、VPC のセキュリティグループでアウトバウンドルールを作成します。アウトバウンドルールでは、TCP がポート 443 を使用して任意の IPv4 アドレス (0.0.0.0/0) にパケットを送信するように定義しています。
+ **プライベートRDS for PostgreSQL DB インスタンス** — この例では、インスタンスの「PubliclyAccessible」プロパティが `false` に指定されているか、インスタンスがプライベートサブネット内に置かれています。インスタンスが Lambda で動作できるようにするには、ネットワークアドレス変換 (NAT) ゲートウェイを使用します。詳細については、「[NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」を参照してください。または、VPC で Lambda の VPC エンドポイントを設定できます。詳細については、*Amazon VPC ユーザーガイド*の「[VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html)」を参照してください。このエンドポイントは、RDS for PostgreSQL DB インスタンスが Lambda 関数に対して発行した、呼び出しに対して応答します。VPC エンドポイントは、独自のプライベートな DNS 解決を使用します。`rds.custom_dns_resolution` の値がデフォルトの 0 (有効化されていない) から 1 に変更されない限り、RDS for PostgreSQL は、Lambda VPC エンドポイントを使用することはできません。そのためには、次の操作を行います。
+ カスタム DB パラメータグループを作成します。
+ `rds.custom_dns_resolution` パラメータの値を、デフォルトの `0` から `1` に変更します。
+ カスタムの DB パラメータグループを使用するように DB インスタンスを変更します。
+ 修正されたパラメータを反映させるために、インスタンスを再起動します。
ご使用の VPC は、ネットワークレベルで AWS Lambda VPC とやり取りできるようになります。次に、IAM を使用してアクセス権限を設定します。
## ステップ 2: RDS for PostgreSQL DB インスタンスおよび AWS Lambda のために IAM を設定する
RDS for PostgreSQL DB インスタンスからの Lambda 関数の呼び出しには、特定の権限が必要です。必要な権限を設定するには、Lambda 関数の呼び出しを許可する IAM ポリシーを作成し、そのポリシーをロールに割り当てた上で、そのロールを DB インスタンスに適用することをお勧めします。このアプローチでは、指定された Lambda 関数をユーザーに代わって呼び出すための権限を、DB インスタンスに対し付与します。以下のステップで、AWS CLI を使用してこれを行う方法を示します。
**Amazon RDS インスタンスで Lambda を使用するために IAM のアクセス許可を設定するには**
1. AWS CLI コマンド [create-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-policy.html) を実行して、指定された Lambda 関数を、RDS for PostgreSQL DB インスタンスが呼び出すことを許可する、IAM ポリシーを作成します。(ステートメント ID (Sid) は、ポリシーステートメントのオプションの記述であり、使用には影響しません。) このポリシーは、DB インスタンスに対し、指定された Lambda 関数を呼び出すための最小限のアクセス許可を付与します。
```
aws iam create-policy --policy-name rds-lambda-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:aws-region:444455556666:function:my-function"
}
]
}'
```
または、任意の Lambda 関数の呼び出しを許可する、事前定義済みの `AWSLambdaRole` ポリシーを使用することもできます。詳細については、「[Lambda のアイデンティティベースの IAM ポリシー](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#access-policy-examples-aws-managed)」を参照してください。
1. AWS CLI コマンド [create-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html) を使用して、実行時にポリシーが引き受けることができる IAM ロールを作成します。
```
aws iam create-role --role-name rds-lambda-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
1. AWS CLI コマンド [attach-role-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-role-policy.html) を使用して、このポリシーをロールに適用します。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::444455556666:policy/rds-lambda-policy \
--role-name rds-lambda-role --region aws-region
```
1. AWS CLI コマンド [add-role-to-db-instance](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/add-role-to-db-instance.html) を使用して、このロールを RDS for PostgreSQL DB インスタンスに適用します。この最後のステップにより、DB インスタンスのデータベースユーザーに対し、Lambda 関数の呼び出しを許可します。
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-instance-name \
--feature-name Lambda \
--role-arn arn:aws:iam::444455556666:role/rds-lambda-role \
--region aws-region
```
VPC と IAM の設定が完了したので、ここで `aws_lambda` 拡張をインストールできます。(拡張機能は任意のタイミングでインストールできますが、先に VPC サポートと IAM 権限を適切に設定する必要があります。`aws_lambda` 拡張機能は、RDS for PostgreSQL DB インスタンスの機能に対し何も追加しません。)
## ステップ 3: RDS for PostgreSQL DB インスタンス用に `aws_lambda` 拡張機能をインストールする
RDS for PostgreSQL DB インスタンスで AWS Lambda を使用し、RDS for PostgreSQL DB インスタンスに対し `aws_lambda` PostgreSQL 拡張機能を追加します。この拡張機能は、RDS for PostgreSQL DB インスタンスに対し、PostgreSQL からの Lambda 関数呼び出し機能を追加します。
**RDS for PostgreSQL DB インスタンスに `aws_lambda` 拡張機能をインストールするには**
PostgreSQL の `psql` コマンドライン、または pgAdmin ツールを使用して、RDS for PostgreSQL DB インスタンスに接続します。
1. RDS for PostgreSQL DB インスタンスに、`rds_superuser` 権限を持つユーザーとして接続します。例では、デフォルトの `postgres` ユーザが示されています。
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. `aws_lambda` 拡張機能をインストールします。`aws_commons` 拡張機能も必要です。これは、`aws_lambda` や、他の多数の PostgreSQL向け Aurora 拡張機能にヘルパー関数を提供します。この拡張機能が、RDS for PostgreSQL DB インスタンス上で見つからない場合は、次のように `aws_lambda` を使用してインストールされています。
```
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
`aws_lambda` 拡張機能は、 DB インスタンスにインストールされています。この段階で、Lambda 関数を呼び出すための、使いやすい構造を作成することが可能です。
## ステップ 4: RDS for PostgreSQL DB インスタンスで Lambda のヘルパー関数を使用する (オプション)
`aws_commons` 拡張機能のヘルパー関数を使用すると、PostgreSQL からより簡単に呼び出すことができるエンティティを準備することができます。これを行うには、Lambda 関数に関する以下の情報が必要です。
+ **[Function name]** (関数名) – Lambda 関数の名前、Amazon リソースネーム (ARN)、バージョンまたはエイリアス。[ステップ 2: インスタンスおよび Lambda のために IAM を設定する](#PostgreSQL-Lambda-access) で作成された IAM ポリシーは ARN を必要とするため、関数の ARN を使用することをお勧めします。
+ **[AWS Region]** (リージョン) – (オプション) Lambda 関数が RDS for PostgreSQL DB インスタンスと同じリージョンに存在しない場合の、Lambda 関数が置かれている AWS リージョン。
Lambda 関数名の情報を保持するには、[aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn) 関数を使用します。このヘルパー関数は、呼び出し関数に必要な詳細を含む `aws_commons._lambda_function_arn_1` 複合構造を作成します。以下に、この複合構造を設定するための 3 つの代替手段を説明します。
```
SELECT aws_commons.create_lambda_function_arn(
'my-function',
'aws-region'
) AS aws_lambda_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'111122223333:function:my-function',
'aws-region'
) AS lambda_partial_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'arn:aws:lambda:aws-region:111122223333:function:my-function'
) AS lambda_arn_1 \gset
```
これらの値はいずれも、[aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) 関数の呼び出し時に使用されます。例については「[ステップ 5: RDS for PostgreSQL DB インスタンスから Lambda 関数を呼びだす](#PostgreSQL-Lambda-invoke)」を参照してください。
## ステップ 5: RDS for PostgreSQL DB インスタンスから Lambda 関数を呼びだす
`aws_lambda.invoke` 関数は、`invocation_type` に応じて同期または非同期的で動作します。以下のように、このパラメーターには 2 つの選択肢、`RequestResponse` (デフォルト) と `Event` があります。
+ **`RequestResponse`** – この呼び出しタイプは*同期*です。これは、呼び出しタイプを指定せずに呼び出しが行われた場合のデフォルトの動作です。レスポンスペイロードには、`aws_lambda.invoke` 関数の結果が含まれます。処理を続行する前に Lambda 関数から結果を受け取る必要があるワークフローの場合は、この呼び出しタイプを使用します。
+ **`Event`** – この呼び出しタイプは*非同期*です。この場合の応答には、結果を含むペイロードは含まれません。この呼び出しタイプは、処理を続行するために Lambda 関数の結果を必要としないワークフローで使用します。
セットアップの簡単なテストとして、`psql` を使用して DB インスタンスに接続し、コマンドラインからサンプル関数を起動します。今、次のスクリーンショットに示すシンプルな Python 関数のような基本的関数の 1 つが、Lambda サービスに設定されているとします。
![\[AWS Lambda の AWS CLI 内に表示された Lambda 関数の例\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/lambda_simple_function.png)
**サンプル関数を呼び出すには**
1. `psql` または pgAdmin を使用して、 DB インスタンスに接続します。
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. ARN を使用して関数を呼びだします。
```
SELECT * from aws_lambda.invoke(aws_commons.create_lambda_function_arn('arn:aws:lambda:aws-region:444455556666:function:simple', 'us-west-1'), '{"body": "Hello from Postgres!"}'::json );
```
この応答は次のようになります。
```
status_code | payload | executed_version | log_result
-------------+-------------------------------------------------------+------------------+------------
200 | {"statusCode": 200, "body": "\"Hello from Lambda!\""} | $LATEST |
(1 row)
```
呼び出しが成功しなかった場合は、「[Lambda 関数のエラーメッセージ](PostgreSQL-Lambda-errors.md)」を参照してください。
## ステップ 6: Lambda 関数を呼び出すその他のユーザー許可を付与する
手順のこの時点で、`rds_superuser` であるユーザーだけが Lambda 関数を呼び出すことができます。作成した関数の呼び出しを他のユーザーに許可するには、許可を付与する必要があります。
**Lambda 関数を呼び出すアクセス許可を付与するには**
1. `psql` または pgAdmin を使用して、 DB インスタンスに接続します。
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. 次の SQL コマンドを実行します。
```
postgres=> GRANT USAGE ON SCHEMA aws_lambda TO db_username;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA aws_lambda TO db_username;
```
# 例: RDS for PostgreSQL DB インスタンスから Lambda 関数を呼びだす
以下に、[aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) 関数の呼び出し例をいくつか示します。ほとんどの例では、関数の詳細を簡単に渡せるように、[ステップ 4: RDS for PostgreSQL DB インスタンスで Lambda のヘルパー関数を使用する (オプション)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) で作成した複合構造 `aws_lambda_arn_1` を使用しています。非同期呼び出しの例については、「[例: Lambda 関数の (Event による) 非同期呼び出し](#PostgreSQL-Lambda-Event)」を参照してください。ここに示されたその他の例はすべて、同期呼び出しを使用します。
Lambda 呼び出しタイプの詳細については、「*AWS Lambdaデベロッパーガイド*」の「[Lambda 関数を呼び出す](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html)」を参照してください。`aws_lambda_arn_1`の詳細については、「[aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn)」を参照してください。
**Topics**
+ [
## 例: Lambda 関数の (RequestResponse による) 同期呼び出し
](#PostgreSQL-Lambda-RequestResponse)
+ [
## 例: Lambda 関数の (Event による) 非同期呼び出し
](#PostgreSQL-Lambda-Event)
+ [
## 例: 関数レスポンスからの Lambda 実行ログのキャプチャリング
](#PostgreSQL-Lambda-log-response)
+ [
## 例: Lambda 関数にクライアントコンテキストを含める
](#PostgreSQL-Lambda-client-context)
+ [
## 例: Lambda 関数の特定のバージョンの呼び出し
](#PostgreSQL-Lambda-function-version)
## 例: Lambda 関数の (RequestResponse による) 同期呼び出し
以下に、Lambda 関数の同期呼び出しの例を 2 つ示します。これらの `aws_lambda.invoke` 関数呼び出しの結果は同じです。
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
```
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse');
```
パラメータの説明は次のとおりです。
+ `:'aws_lambda_arn_1'` – このパラメータは、ヘルパー関数 `aws_commons.create_lambda_function_arn` を使用して、[ステップ 4: RDS for PostgreSQL DB インスタンスで Lambda のヘルパー関数を使用する (オプション)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) で作成される複合構造を識別します。この構造は、次のように `aws_lambda.invoke` 呼び出しの中で、インラインで作成することもできます。
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function', 'aws-region'),
'{"body": "Hello from Postgres!"}'::json
);
```
+ `'{"body": "Hello from PostgreSQL!"}'::json` - Lambda関数に渡す JSON ペイロード。
+ `'RequestResponse'`-Lambda 呼び出しタイプ。
## 例: Lambda 関数の (Event による) 非同期呼び出し
以下は、Lambda 関数の非同期呼び出しの例です。`Event` 呼び出しタイプは、指定された入力ペイロードを使用して Lambda 関数の呼び出しをスケジュールし、すぐに返します。Lambda 関数の結果に依存しない特定のワークフローでは、`Event` 呼び出しタイプを使用します。
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'Event');
```
## 例: 関数レスポンスからの Lambda 実行ログのキャプチャリング
関数レスポンスに実行ログの最後の 4 KB を含めるには、`log_type` パラメーターを使用しながら `aws_lambda.invoke` 関数を呼び出します。デフォルトでは、このパラメータには `None` が設定されています。レスポンス内の Lambda 実行ログの結果をキャプチャする場合は、以下のように `Tail` を指定します。
```
SELECT *, select convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
[aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) 関数の `log_type` パラメータを `Tail` に設定して、実行ログをレスポンスに含めます。この `log_type` パラメータのデフォルト値は `None` です。
返された `log_result` は、`base64` エンコードされた文字列です。このコンテンツは、`decode` と `convert_from` PostgreSQL 関数の組み合わせを使用してデコードできます。
`log_type` の詳細については、「[aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke)」を参照してください。
## 例: Lambda 関数にクライアントコンテキストを含める
`aws_lambda.invoke` 関数では、次に示すとおり `context` パラメータを使用して、ペイロードとは別の情報を渡すことができます。
```
SELECT *, convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
クライアントコンテキストを含めるときは、[aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) 関数の `context` パラメータに JSON オブジェクトを使用します。
`context` パラメータの詳細については、「[aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke)」でリファレンスを参照してください。
## 例: Lambda 関数の特定のバージョンの呼び出し
`aws_lambda.invoke` 呼び出しに `qualifier` パラメータを含めることで、Lambda 関数の特定のバージョンを指定することが可能です。以下は、`'custom_version'` をバージョンのエイリアスに使用してこれを行う場合の例です。
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'None', NULL, 'custom_version');
```
代わりに、Lambda 関数名の詳細により、次のように関数の修飾子を指定することもできます。
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function:custom_version', 'us-west-2'),
'{"body": "Hello from Postgres!"}'::json);
```
`qualifier` および他のパラメータの詳細については、「[aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke)」でリファレンスを参照してください。
# Lambda 関数のエラーメッセージ
次のリストには、エラーメッセージに関する情報と、考えられる原因と解決策が表示されます。
+ **VPC 設定の問題**
VPC の設定の問題により、接続しようとすると次のエラーメッセージが表示されることがあります。
```
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'Unable to connect to endpoint'.
CONTEXT: SQL function "invoke" statement 1
```
このエラーの一般的な原因は、VPC セキュリティグループが不適切に設定されていることです。VPC セキュリティグループのポート 443 で TCP のアウトバウンドルールが開いており、VPC が Lambda VPC に接続できるようになっていることを確認します。
プライベートの DB インスタンスを使用している場合は、VPC のプライベート DNS 設定を確認します。`rds.custom_dns_resolution` パラメータには 1 が設定されており、AWS PrivateLink は [ステップ 1: RDS for PostgreSQL DB インスタンスで、AWS Lambda へのアウトバウンド接続を設定する。](PostgreSQL-Lambda.md#PostgreSQL-Lambda-network) での概説どおりにセットアップされていることを確認します。詳細については、「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns)」を参照してください。
+ **Lambda 関数を呼び出すために必要な許可がない**
次のいずれかのエラーメッセージが表示された場合、関数を呼び出すユーザー (ロール) に適切な許可がありません。
```
ERROR: permission denied for schema aws_lambda
```
```
ERROR: permission denied for function invoke
```
Lambda 関数を呼び出すには、ユーザー (ロール) に特定の許可を付与する必要があります。詳しくは、「[ステップ 6: Lambda 関数を呼び出すその他のユーザー許可を付与する](PostgreSQL-Lambda.md#PostgreSQL-Lambda-grant-users-permissions)」を参照してください。
+ **Lambda 関数でのエラーの不適切な処理**
リクエストの処理中に Lambda 関数が例外をスローした場合、`aws_lambda.invoke` は、次のように PostgreSQL エラーで失敗します。
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
ERROR: lambda invocation failed
DETAIL: "arn:aws:lambda:us-west-2:555555555555:function:my-function" returned error "Unhandled", details: "".
```
Lambda 関数または PostgreSQL アプリケーションの中でエラーに対処します。
# AWS Lambda 関数とパラメータのリファレンス
以下は、RDS for PostgreSQL で Lambda を呼び出すために使用する関数とパラメータのリファレンスです。
**Topics**
+ [
## aws\$1lambda.invoke
](#aws_lambda.invoke)
+ [
## aws\$1commons.create\$1lambda\$1function\$1arn
](#aws_commons.create_lambda_function_arn)
+ [
## aws\$1lambda パラメータ
](#aws_lambda.parameters)
## aws\$1lambda.invoke
の RDS for PostgreSQL DB インスタンスの Lambda 関数を実行します。
Lambda関数の呼び出しの詳細については、*AWS Lambda デベロッパーガイド*の「[呼び出し](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)」も参照してください。
**[Syntax]** (構文)
------
#### [ JSON ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSON,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSON,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
------
#### [ JSONB ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSONB,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSONB,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT
)
```
------入力パラメータ
**function\$1name**
Lambda 関数の識別名。値には、関数名、ARN、または部分的な ARN を指定できます。可能な形式のリストについては、*AWS Lambda デベロッパーガイド*の「[Lambda関数名の形式](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestParameters)」を参照してください。
*payload*
Lambda 関数の入力。形式には、JSON または JSONB を使用できます。詳細については、PostgreSQL ドキュメントの「[JSON タイプ](https://www.postgresql.org/docs/current/datatype-json.html)」を参照してください。
*リージョン*
(オプション) 関数の Lambda リージョン。デフォルトでは、RDS は AWS の完全な ARN から `function_name` リージョンを解決するか、 RDS for PostgreSQL DB インスタンスのリージョンを使用します。このリージョン値が `function_name` ARN で指定されたものと競合する場合、エラーが発生します。
*invocation\$1type*
Lambda 関数の呼び出しタイプ。 値は大文字と小文字が区別されます。以下に示しているのは、可能な値です。
+ `RequestResponse`-デフォルト。Lambda 関数の呼び出しタイプは同期で、結果にレスポンスペイロードを返します。ワークフローが Lambda 関数の結果をすぐに受け取ることに依存しているときは、`RequestResponse` 呼び出しのタイプを使用します。
+ `Event`- Lambda 関数の呼び出しタイプは非同期で、返されたペイロードなしにすぐに返されます。ワークフローを先に進める前に Lambda 関数の結果を知る必要がないときは、`Event` の呼び出しタイプを使用します。
+ `DryRun`- この呼び出しタイプは、Lambda 関数を実行せずに、アクセスをテストします。
*log\$1type*
`log_result`出力パラメータで返される Lambda ログのタイプ。 値は大文字と小文字が区別されます。以下に示しているのは、可能な値です。
+ Tail - 返された `log_result` 出力パラメータには、実行ログの最後の 4 KB が含まれます。
+ None - Lambda のないログ情報は返されません。
*context*
JSON または JSONB形式のクライアントコンテキスト。使用されるフィールドには `custom` と `env` が含まれます 。
*修飾子*
呼び出される Lambda 関数のバージョンを識別する修飾子。この値が `function_name` ARN で指定されたものと競合する場合、エラーが発生します。出力パラメータ
*status\$1code*
HTTP ステータスレスポンスコード。詳細については、*AWS Lambda デベロッパーガイド*の「[Lambda 応答要素の呼び出し](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseElements)」を参照してください。
*payload*
実行された Lambda 関数から返された情報。形式は JSON または JSONB です。
*executedversion*
実行された Lambda 関数のバージョン。
*result*
Lambda 関数が呼び出されたとき `log_type` 値が `Tail` である場合に返される実行ログ情報。結果には、Base64 でエンコードされた実行ログの最後の 4 KB が含まれます。
## aws\$1commons.create\$1lambda\$1function\$1arn
Lambda 関数名情報を保持するように、`aws_commons._lambda_function_arn_1` 構造を作成します。`aws_commons.create_lambda_function_arn` 関数の結果は、aws\$1lambda.invoke `function_name` 関数の [aws\$1lambda.invoke](#aws_lambda.invoke) パラメータで使用します。
**[Syntax]** (構文)
```
aws_commons.create_lambda_function_arn(
function_name TEXT,
region TEXT DEFAULT NULL
)
RETURNS aws_commons._lambda_function_arn_1
```入力パラメータ
*function\$1name*
Lambda 関数名を含む必須のテキスト文字列。値には、関数名、部分的な ARN、または完全な ARN を指定します。
*リージョン*
Lambda 関数がある AWS リージョンを含む、オプションのテキスト文字列。 リージョン名と関連する値のリストについては、「」を参照してください。[リージョン、アベイラビリティーゾーン、および Local Zones](Concepts.RegionsAndAvailabilityZones.md)
## aws\$1lambda パラメータ
この表には、`aws_lambda` 関数に関連するパラメータが記載されています。
| パラメータ | 説明 |
| --- | --- |
| `aws_lambda.connect_timeout_ms` | これは動的パラメータであり、AWS Lambda への接続中の最大待機時間を設定します。デフォルト値は `1000` です。このパラメータに指定できる値は、1～900000 です。 |
| `aws_lambda.request_timeout_ms` | これは動的パラメータであり、AWS Lambda からのレスポンスの最大待機時間を設定します。デフォルト値は `3000` です。このパラメータに指定できる値は、1～900000 です。 |
| `aws_lambda.endpoint_override` | AWS Lambda への接続に使用できるエンドポイントを指定します。空の文字列は、リージョンのデフォルトの AWS Lambda エンドポイントを選択します。この静的パラメータの変更を有効にするには、データベースを再起動する必要があります。 |
# Amazon RDS for PostgreSQL の一般的な DBA タスク
Amazon RDS for PostgreSQL DB インスタンスを管理するときに、データベース管理者 (DBA) は、さまざまなタスクを実行します。すでに PostgreSQL に精通している DBA の場合は、ハードウェア上で PostgreSQL を実行することと RDS for PostgreSQL との重要な違いのいくつかに注意する必要があります。例えば、マネージドサービスであるため、Amazon RDS では DB インスタンスへのシェルアクセスができません。つまり、`pg_hba.conf` および他の設定ファイルに直接アクセスすることはできません。RDS for PostgreSQL の場合、オンプレミスインスタンスの PostgreSQL 設定ファイルに通常加えられる変更は、RDS for PostgreSQL DB インスタンスに関連付けられたカスタム DB パラメータグループに対して行われます。詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
また、オンプレミスの PostgreSQL インスタンスと同じ方法では、ログファイルにアクセスできません。ログ記録の詳細については、「[ RDS for PostgreSQL データベースログファイル](USER_LogAccess.Concepts.PostgreSQL.md)」を参照してください。
別の例としては、PostgreSQL `superuser` アカウントにアクセスできなくなります。RDS for PostgreSQL では、`rds_superuser` ロールが最も高い権限を持つロールであり、設定時に `postgres` に付与されます。オンプレミスで PostgreSQL を使い慣れている場合でも、RDS for PostgreSQL を初めて使用する場合でも、`rds_superuser` ロールについて、およびロール、ユーザー、グループ、アクセス権限の操作方法を理解することをお勧めします。詳細については、「[PostgreSQL のロールとアクセス権限について](Appendix.PostgreSQL.CommonDBATasks.Roles.md)」を参照してください。
RDS for PostgreSQL の一般的な DBA タスクの一部を次に示します。
**Topics**
+ [
# RDS for PostgreSQL でサポートされる照合。
](PostgreSQL-Collations.md)
+ [
# PostgreSQL のロールとアクセス権限について
](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [
# PostgreSQL でのデッド接続の処理
](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [
# Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [
# Amazon RDS for PostgreSQL での高いオブジェクト数の管理
](PostgreSQL.HighObjectCount.md)
+ [
# Amazon RDS for PostgreSQL での TOAST OID 競合の管理
](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [
## RDS for PostgreSQL でサポートされているログ記録メカニズムの使用
](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [
# PostgreSQL による一時ファイルの管理
](PostgreSQL.ManagingTempFiles.md)
+ [
## pgBadger を使用した PostgreSQL でのログ分析
](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [
## PostgreSQL をモニタリングするために PGSnapper を使用する
](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [
# RDS for PostgreSQL でのカスタムキャストの管理
](PostgreSQL.CustomCasts.md)
+ [
# RDS for PostgreSQL での並列クエリのベストプラクティス
](PostgreSQL.ParallelQueries.md)
+ [
# RDS for PostgreSQL DB インスタンスでのパラメータの使用
](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# RDS for PostgreSQL でサポートされる照合。
照合は、データベースに保存されている文字列をソートして比較する方法を決定する一連のルールです。照合は、コンピュータシステムにおいて基本的な役割を果たし、オペレーティングシステムの一部として組み込まれています。照合は、言語に新しい文字が追加されたり、順序規則が変更されたりすると、時間の経過とともに変化します。
照合ライブラリは、照合の特定のルールとアルゴリズムを定義します。PostgreSQL で使用される最も一般的な照合ライブラリは GNU C (glibc) と Unicode 用の国際化コンポーネント (ICU) です。デフォルトでは、RDS for PostgreSQL は、マルチバイト文字シーケンスの Unicode 文字ソート順序を含む glibc 照合を使用します。
新しい RDS for PostgreSQL の DB インスタンスを作成すると、オペレーティングシステムで使用可能な照合がチェックされます。`CREATE DATABASE` コマンド `LC_COLLATE` および `LC_CTYPE` の PostgreSQL パラメーターは、照合順序を指定するために使用され、そのデータベースのデフォルトの照合となります。または、`CREATE DATABASE` で `LOCALE` パラメータを使用して、これらのパラメータを設定することもできます。これにより、データベース内の文字列のデフォルトの照合と、文字を文字、数字、または記号として分類する規則が決まります。列、インデックス、またはクエリで使用する照合を選択することもできます。
RDS for PostgreSQL は、照合をサポートするためにオペレーティングシステムの glibc ライブラリに依存しています。RDS for PostgreSQL インスタンスは、オペレーティングシステムの最新バージョンで定期的に更新されます。これらのアップデートには glibc ライブラリの新しいバージョンが含まれることがあります。ごくまれに、新しいバージョンの glibc で一部の文字のソート順序や照合順序が変更されるため、データのソート方法が変わったり、無効なインデックスエントリが生成されることがあります。更新中に照合のソート順序の問題が見つかった場合は、インデックスの再構築が必要になることがあります。
glibc の更新による影響を減らすために、RDS for PostgreSQL に独立したデフォルトの照合ライブラリが含まれるようになりました。この照合ライブラリは、RDS for PostgreSQL 14.6、13.9、12.13、11.18、10.23、およびそれ以降のマイナーバージョンリリースで利用できます。glibc 2.26-59.amzn2 と互換性があり、誤ったクエリ結果を防ぐためにソート順序が安定しています。
# PostgreSQL のロールとアクセス権限について
AWS マネジメントコンソール を使用して RDS for PostgreSQL DB インスタンスを作成すると、管理者アカウントが同時に作成されます。次のスクリーンショットに示すように、デフォルトでは `postgres` という名前になります。
![\[「データベースを作成」ページの認証情報のデフォルトのログイン ID は postgres です。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
デフォルト設定 (`postgres`) を受け入れるのではなく、別の名前を選択することもできます。この場合、選択する名前はアルファベットで始まり、1 文字以上 16 文字以下の英数字である必要があります。このガイドでは、わかりやすくするために、このメインユーザーアカウントをデフォルトの値 (`postgres`) で表記しています。
AWS マネジメントコンソール ではなく、`create-db-instance` AWS CLI を使用する場合は、コマンドの `master-username` パラメータと一緒に渡すことで名前を作成します。詳細については、 を参照してください。[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)
AWS マネジメントコンソール、AWS CLI、または Amazon RDS API のいずれを使用する場合でも、またデフォルトの `postgres` 名を使用するか、別の名前を選択するかにかかわらず、この最初のデータベースユーザーアカウントは `rds_superuser` グループのメンバーであり、`rds_superuser` 権限を持つことになります。
**Topics**
+ [
# rds\$1superuser ロールを理解する
](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [
# PostgreSQL データベースへのユーザーアクセスのコントロール
](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [
# ユーザーパスワード管理の委任と制御
](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [
# PostgreSQL のパスワード暗号化に SCRAM を使用する
](PostgreSQL_Password_Encryption_configuration.md)
# rds\$1superuser ロールを理解する
PostgreSQL では、*ロール*はデータベース内のさまざまなオブジェクトに対して、ユーザー、グループ、またはグループやユーザーに与えられた特定のアクセス権限を定義することができます。`CREATE USER` と `CREATE GROUP` に対する PostgreSQL コマンドは、データベースユーザーを区別するために、より一般的な、特定のプロパティを持つ `CREATE ROLE` に置き換えられました。データベースユーザーは、LOGIN 権限を持つロールと考えることができます。
**注記**
`CREATE USER` および `CREATE GROUP` コマンドは引き続き使用できます。詳細については、PostgreSQL のドキュメントの「[データベースロール](https://www.postgresql.org/docs/current/user-manag.html)」セクションを参照してください。
`postgres` ユーザーは、 RDS for PostgreSQL DB インスタンス で最も権限があるデータベースユーザーです。ユーザーには、次の `CREATE ROLE` ステートメントで定義される特性があります。
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
特に指定がない限り、プロパティ `NOSUPERUSER`、`NOREPLICATION`、`INHERIT`、および `VALID UNTIL 'infinity'` が CREATE ROLE のデフォルトオプションです。
デフォルトでは、`postgres` には `rds_superuser` ロールに付与された権限と、ロールとデータベースを作成するアクセス許可があります。`rds_superuser` ロールでは、`postgres` ユーザーによる次の操作を許可します。
+ Amazon RDS で使用できる拡張機能の追加 詳細については、「[Amazon RDS for PostgreSQL でサポートされている PostgreSQL の機能を使用する](PostgreSQL.Concepts.General.FeatureSupport.md)
+ ユーザーのロールを作成し、ユーザーに権限を付与します。詳細については、PostgreSQL のドキュメントの「[CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html)」および「[GRANT](https://www.postgresql.org/docs/14/sql-grant.html)」セクションを参照してください。
+ データベースの作成 詳細については、PostgreSQL のドキュメントの「[CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html)」を参照してください。
+ これらの権限を持たないユーザーロールに対する `rds_superuser` 権限を付与し、必要に応じてそれらの権限を取り消します。このロールは、スーパーユーザータスクを実行するユーザーにのみ付与することをお勧めします。つまり、データベース管理者 (DBA) またはシステム管理者にこのロールを付与できます。
+ `rds_superuser` ロールを持たないデータベースユーザーに `rds_replication` ロールを付与 (または取り消し) します。
+ `rds_superuser` ロールを持たないデータベースユーザーに `rds_password` ロールを付与 (または取り消し) します。
+ `pg_stat_activity` ビューを使用して、すべてのデータベース接続に関するステータス情報を取得します。必要に応じて、`rds_superuser` で `pg_terminate_backend` または `pg_cancel_backend` を使用して接続を停止できます。
`CREATE ROLE postgres...` ステートメントで、`postgres` ユーザーロールは PostgreSQL の `superuser` アクセス許可を特に禁止することがわかります。RDS for PostgreSQL はマネージドサービスのため、ホスト OS へのアクセスや、PostgreSQL `superuser` アカウントを使用した接続はできません。スタンドアロンの PostgreSQL で `superuser` のアクセスが必要な作業の多くは、Amazon RDS で自動的に管理されます。
権限の付与に関する詳細については、PostgreSQL のドキュメントの「[GRANT](http://www.postgresql.org/docs/current/sql-grant.html)」を参照してください。
`rds_superuser` ロールは、におけるいくつかの*事前定義済み*ロールの 1 つです。RDS for PostgreSQL DB インスタンス。
**注記**
PostgreSQL 13 以前のリリースでは、*定義済み*ロールは*デフォルト*ロールと呼ばれていました。
次のリストに、新しい のために自動的に作成される他の定義済みロールの一部を示します。RDS for PostgreSQL DB インスタンス。定義済みロールとその権限は変更できません。これらの定義済みロールに対して削除、名前の変更、変更を行うことはできません。それらの操作を試みると、エラーが発生します。
+ **rds\$1password** - データベースユーザーのパスワードを変更し、パスワード制約を設定できるロールです。`rds_superuser` ロールにはデフォルトでこのロールが付与され、データベースユーザーにロールを付与できます。詳細については、「[PostgreSQL データベースへのユーザーアクセスのコントロールPostgreSQL へのユーザーアクセスのコントロール](Appendix.PostgreSQL.CommonDBATasks.Access.md)」を参照してください。
+ 14 より前のバージョンの RDS for PostgreSQL の場合、`rds_password` ロールはパスワードを変更し、データベースユーザーと `rds_superuser` ロールを持つユーザーのパスワード制約を設定できます。RDS for PostgreSQL 14 以降のバージョンでは、`rds_password` ロールがユーザーのパスワードを変更し、パスワード制約を設定できるのは、データベースユーザーに対してのみです。`rds_superuser` ロールを持つユーザーのみが、`rds_superuser` ロールを持つ他のユーザーに対して上記のアクションを実行できます。
+ **rdsadmin** - `superuser` 権限を持つ管理者がスタンドアロンの PostgreSQL データベースで行う管理タスクの多くを処理するために作成されるロールです。このロールは、RDS for PostgreSQL によって多くの管理タスクのために内部的に使用されます。
+ **rdstopmgr** - マルチ AZ 配置をサポートするために Amazon RDS によって内部的に使用されるロールです。
+ **rds\$1reserved** – データベース接続を予約するために Amazon RDS によって内部的に使用されるロール。
# ロールとその権限の表示
PostgreSQL バージョン別に異なるコマンドを使用して、RDS for PostgreSQL DB インスタンスで事前定義されたロールとその権限を表示できます。事前定義されたロールをすべて表示するには、RDS for PostgreSQL DB インスタンスに接続し、`psql` を使用して以下のコマンドを実行します。
**`psql` バージョン 15 以前の場合**
RDS for PostgreSQL DB インスタンスに接続し、psql で `\du` コマンドを使用します。
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**`psql` バージョン 16 以降の場合**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
バージョンに関係なくロールのメンバーシップを確認するには、次の SQL クエリを使用できます。
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
出力では、`rds_superuser` がデータベースユーザーロールではない (ログインできない) が、他の多くのロールの特権を持っていることがわかります。また、そのデータベースユーザー `postgres` は `rds_superuser` ロールのメンバーであることも確認できます。前述のように、`postgres` が Amazon RDS コンソールの **[Create database]** (データベースを作成) ページのデフォルト値です。別の名前を選択した場合、代わりにその名前がロールのリストに表示されます。
# PostgreSQL データベースへのユーザーアクセスのコントロール
PostgreSQL の新しいデータベースは、常にデータベースの `public` スキーマに、すべてのデータベースユーザーとロールがオブジェクトを作成できるようなデフォルトの権限セットで作成されます。これらの権限により、例えば、データベースユーザーがデータベースに接続し、接続しながら一時テーブルを作成することができます。
RDS for PostgreSQL DB インスタンスに作成するデータベースインスタンスへのユーザーアクセスをよりよく制御するために、これらのデフォルトの `public` 権限を取り消すことを推奨します。その後、次の手順で示すように、データベースのユーザーに特定の権限をより詳細に付与します。
**新しいデータベースインスタンスのロールと権限を設定するには**
全員がデータベースへの読み取り/書き込みアクセスを必要とする複数の研究者が使用するために、新しく作成された RDS for PostgreSQL DB インスタンス上にデータベースをセットアップしているとします。
1. `psql` (または pgAdmin) を使用して、 RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
プロンプトが表示されたら、パスワードを入力します。`psql` クライアントが接続し、プロンプトとしてデフォルトの管理用接続データベースである `postgres=>` を表示します。
1. データベースユーザーが `public` スキーマでオブジェクトを作成できないようにするには、次の操作を行います。
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. 次に、新しいデータベースインスタンスを作成します。
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. この新しいデータベースの `PUBLIC` スキーマからすべての権限を取り消します。
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. データベースユーザーのロールを作成します。
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. このロールを持つデータベースユーザーに、データベースに接続する機能を付与します。
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. `lab_tech` ロールを持つすべてのユーザーに、このデータベースのすべての権限を付与します。
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. 次のように、データベースユーザーを作成します。
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. これら 2 人のユーザーに lab\$1tech ロールに関連付けられた権限を付与します。
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
この時点で、`lab_user1` と `lab_user2` は `lab_db` データベースに接続できます。この例は、複数のデータベースインスタンスの作成、異なるスキーマの作成、制限されたアクセス許可の付与などを含む、エンタープライズで使用するためのベストプラクティスに従ったものではありません。詳細な情報と追加のシナリオについては、「[PostgreSQL ユーザーとロールの管理](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/)」を参照してください。
PostgreSQL データベースでの権限の詳細については、PostgreSQL のドキュメントの [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) コマンドを参照してください。
# ユーザーパスワード管理の委任と制御
DBA は、ユーザーパスワードの管理を委任する場合があります。または、データベースユーザーがパスワードを変更したり、パスワードの有効期間などのパスワード制約を再設定したりしないようにする場合もあります。選択したデータベースユーザーのみがパスワード設定を変更できるようにするには、制限されたパスワード管理の機能をオンにします。この機能をアクティブにすると、`rds_password` ロールを付与されたデータベースユーザーのみがパスワードを管理できます。
**注記**
制限されたパスワード管理を使用するには、RDS for PostgreSQL DB インスタンス PostgreSQL 10.6 以上を実行している必要があります。
次に示すように、デフォルトではこの機能は `off` になっています。
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
この機能をオンにするには、カスタムパラメータグループを使用して、`rds.restrict_password_commands` の設定を 1 に変更します。設定を有効にするには、 RDS for PostgreSQL DB インスタンスを必ず再起動してください。
この機能をアクティブにすると、次の SQL コマンドには `rds_password` 権限が必要になります。
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
ロールの名前の変更 (`ALTER ROLE myrole RENAME TO newname`) は、パスワードが MD5 ハッシュアルゴリズムを使用する場合にも制限されます。
この機能が有効な場合、`rds_password` ロールのアクセス許可なしでこれらの SQL コマンドの実行を試みると、次のエラーが発生します。
```
ERROR: must be a member of rds_password to alter passwords
```
`rds_password` は、パスワード管理専用の少数のロールにのみ付与することをお勧めします。`rds_superuser` 権限を持たないデータベースユーザーに `rds_password` 権限を付与する場合は、`CREATEROLE` 属性も付与する必要があります。
パスワード要件 (クライアント側の有効期限や必要な複雑さなど) を確認してください。パスワード関連の変更に独自のクライアント側ユーティリティを使用する場合、そのユーティリティは `rds_password` のメンバーであり、`CREATE ROLE` 権限を持つ必要があります。
# PostgreSQL のパスワード暗号化に SCRAM を使用する
*SCRAM (Salted Challenge Response Authentication Mechanism)* は、パスワードを暗号化するための PostgreSQL のデフォルトのメッセージダイジェスト (MD5) アルゴリズムの代替手段です。SCRAM 認証メカニズムは MD5 よりも安全であると見なされます。これら 2 つの異なるパスワードを保護する方法の詳細については、PostgreSQL のドキュメントの「[パスワード認証](https://www.postgresql.org/docs/14/auth-password.html)」を参照してください。
に対しては、パスワード暗号化方式として MD5 ではなく SCRAM を使用することをお勧めします。RDS for PostgreSQL DB インスタンス。これは、パスワード認証と暗号化のために scram-sha-256 アルゴリズムを使用する暗号化チャレンジレスポンスのメカニズムです。
SCRAM をサポートするために、クライアントアプリケーションのライブラリを更新する必要があります。例えば、42.2.0 より前の JDBC バージョンで SCRAM はサポートされていません。詳細については、PostgreSQL JDBC ドライバーのドキュメントの「[PostgreSQL JDBC ドライバー](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/)」を参照してください。その他の PostgreSQL ドライバーおよび SCRAM サポートの一覧については、PostgreSQL のドキュメントの「[ドライバーの一覧](https://wiki.postgresql.org/wiki/List_of_drivers)」を参照してください。
RDS for PostgreSQL 13.1 以降のバージョンは scram-sha-256 をサポートします。これらのバージョンでは、次の手順で説明するように、DB インスタンスに SCRAM を要求するように設定することもできます。
## SCRAM を要求するために RDS for PostgreSQL DB インスタンスを設定する
では、scram-sha-256 アルゴリズムを使用するパスワードのみを受け入れるために、に RDS for PostgreSQL DB インスタンスを要求できます。
**重要**
PostgreSQL データベースを使用する既存の RDS プロキシでは、`SCRAM` のみを使用するようにデータベース認証を変更すると、プロキシは最大 60 秒間使用できなくなります。この問題を回避するには、以下のいずれかの方法で対応します。
データベースが `SCRAM` と `MD5` 認証の両方を許可していることを確認します。
`SCRAM` 認証のみを使用するには、新しいプロキシを作成し、アプリケーショントラフィックを新しいプロキシに移行してから、以前にデータベースに関連付けられていたプロキシを削除します。
システムに変更を加える前に、次の完全なプロセスを理解していることを確認してください。
+ すべてのデータベースユーザーのすべてのロールとパスワードの暗号化に関する情報を取得します。
+ パスワードの暗号化を制御するパラメータを指定するために、 RDS for PostgreSQL DB インスタンスのパラメータ設定を再確認してください。
+ RDS for PostgreSQL DB インスタンスでデフォルトのパラメータグループを使用する場合は、カスタムの DB パラメータグループを作成して、それを RDS for PostgreSQL DB インスタンスに適用し、必要なときにパラメータを変更できるようにする必要があります。 RDS for PostgreSQL DB インスタンスがカスタムパラメータグループを使用している場合、必要に応じて、プロセスの後で必要なパラメータを変更できます。
+ `password_encryption` パラメータを `scram-sha-256` に変更します。
+ パスワードを更新する必要があることをすべてのデータベースユーザーに通知します。`postgres` アカウントに同じ操作を行います。新しいパスワードは暗号化され、scram-sha-256 アルゴリズムを使用して保存されます。
+ 暗号化の種類を使用して、すべてのパスワードが暗号化されていることを確認します。
+ すべてのパスワードで scram-sha-256 が使用されている場合、`rds.accepted_password_auth_method` パラメータを `md5+scram` から `scram-sha-256` に変更できます。
**警告**
`rds.accepted_password_auth_method` を scram-sha-256 のみに変更した後、`md5` で暗号化されたパスワードを持つすべてのユーザー (ロール) は接続できなくなります。
### RDS for PostgreSQL DB インスタンスに SCRAM を要求する準備
お使いの 、RDS for PostgreSQL DB インスタンスに変更を加える前に、既存のデータベースユーザーアカウントをすべて確認します。また、パスワードに使用されている暗号化の種類を確認してください。確認するためには、`rds_tools` 拡張機能を使用します。`rds_tools` をサポートする PostgreSQL バージョンを確認するには、「[Extension versions for Amazon RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html)」を参照してください。
**データベースユーザー (ロール) とパスワードの暗号化方法のリストを取得するには**
1. 次のように、`psql` を使用して を RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. `rds_tools` 拡張機能をインストールします。
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. ロールと暗号化のリストを取得します。
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
以下のような出力結果が表示されます。
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### カスタム DB パラメータグループの作成
**注記**
RDS for PostgreSQL DB インスタンスで既にカスタムパラメータグループを使用している場合、新しいパラメータグループを作成する必要はありません。
Amazon RDS のパラメータグループの概要については、「[RDS for PostgreSQL DB インスタンスでのパラメータの使用](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)」を参照してください。
パスワードに使用されるパスワード暗号化タイプは、1 つのパラメータ `password_encryption` で設定します。 RDS for PostgreSQL DB インスタンスで許可される暗号化は、別のパラメータ `rds.accepted_password_auth_method` で設定されます。これらのいずれかをデフォルト値から変更するには、カスタム DB パラメータグループを作成して、 インスタンスに適用する必要があります。
また、AWS マネジメントコンソール または RDS API を使用して、カスタムの DB パラメータグループを作成することもできます。詳細については、「」を参照してください。
これで、カスタムパラメータグループを DB インスタンスに関連付けることができます。
**カスタム DB パラメータグループを作成するには**
1. `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` CLI コマンドを使用して、カスタムの DB パラメータグループを作成します。この例では `postgres13` をこのカスタムパラメータグループのソースとして使用します。
Linux、macOS、Unix の場合:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Windows の場合:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` CLI コマンドを使用して、このカスタムパラメータグループを RDS for PostgreSQL DB クラスターに適用します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Windows の場合:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
PostgreSQL DB インスタンスとカスタム DB クラスターパラメータグループと再同期するには、プライマリインスタンスとクラスターの他のすべてのインスタンスを再起動する必要があります。ユーザーへの影響を最小限に抑えるため、定期的なメンテナンス期間中に実施するように計画してください。
### SCRAM を使用するためのパスワード暗号化の設定
RDS for PostgreSQL DB インスタンスで使用されるパスワード暗号化メカニズムは、`password_encryption` パラメータの DB パラメータグループに設定されています。指定できる値は、未設定、`md5` または `scram-sha-256` です。デフォルト値は、次のように RDS for PostgreSQL のバージョンによって異なります。
+ RDS for PostgreSQL 14 以上 – デフォルトは `scram-sha-256`
+ RDS for PostgreSQL 13 – デフォルトは `md5`
RDS for PostgreSQL DB インスタンスにアタッチされているカスタム DB パラメータグループでは、パスワード暗号化パラメータの値を変更できます。
![\[次では、RDS コンソールには、RDS for PostgreSQL の password_encryption パラメータのデフォルト値が表示されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**パスワード暗号化の設定を scram-sha-256 に変更するには**
+ 次のように、パスワード暗号化の値を scram-sha-256 に設定します。パラメータが動的であるため、変更をすぐに適用できます。そのため、変更を有効にするために再起動は不要です。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Windows の場合:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### ユーザーロールのパスワードを SCRAM に移行する
以下に説明するように、ユーザーロールのパスワードを SCRAM に移行できます。
**データベースユーザー (ロール) のパスワードを MD5 から SCRAM に移行するには**
1. 次のように、管理者ユーザーとしてログインします (デフォルトのユーザー名、`postgres`)。
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. 次のコマンドを使って、RDS for PostgreSQL DB インスタンスの `password_encryption` パラメータの設定を確認します。
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. このパラメータの値を scram-sha-256 に変更します。詳細については、「[SCRAM を使用するためのパスワード暗号化の設定](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption)」を参照してください。
1. 値をもう一度チェックして、次のように `scram-sha-256` に設定されていることを確認します。
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. パスワードの変更をすべてのデータベースユーザーに通知します。アカウント `postgres` (`rds_superuser` 権限を持つデータベースユーザー) のパスワードも必ず変更してください。
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. のすべてのデータベースに対してこの処理を繰り返します。RDS for PostgreSQL DB インスタンス。
### SCRAM を要求するようにパラメータを変更する
これがプロセスの最後のステップです。次の手順で変更した後、パスワードに引き続き `md5` 暗号化を使用するユーザーアカウント (ロール) は にログインできません。RDS for PostgreSQL DB インスタンス。
`rds.accepted_password_auth_method` は、ログインプロセス中に RDS for PostgreSQL DB インスタンスがユーザーパスワードに対して受け入れる暗号化方式を指定します。デフォルト値は `md5+scram` です。つまり、どちらの方法も受け入れられます。次の画像では、このパラメータのデフォルト設定が表示されています。
![\[rds.accepted_password_auth_method パラメータに対してデフォルト値と許可された値が表示されている RDS コンソール。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
このパラメータに指定できる値は、`md5+scram` または `scram` のみです。このパラメータの値を `scram` に変更すると、これが要件となります。
**パスワードの SCRAM 認証を要求するようにパラメータ値を変更するには**
1. RDS for PostgreSQL DB インスタンスの上のすべてのデータベースに対するすべてのデータベースユーザーパスワードが、パスワード暗号化に `scram-sha-256` を使用していることを確認します。そのためには、`rds_tools` にロール (ユーザー) と暗号化タイプについて、次のようにクエリします。
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. のすべての DB インスタンスでクエリを繰り返します。RDS for PostgreSQL DB インスタンス。
すべてのパスワードで scram-sha-256 が使用されている場合は続行できます。
1. 次のように、受け入れたパスワード認証の値を scram-sha-256 に設定します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Windows の場合:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# PostgreSQL でのデッド接続の処理
デッド接続は、クライアントアプリケーションが終了または異常終了したにもかかわらず、データベースセッションがサーバー上でアクティブのままである場合に発生します。この状況は通常、データベース接続を適切に閉じたり、進行中のリクエストをキャンセルしたりせずに、クライアントプロセスがクラッシュまたは予期せず終了した場合に発生します。
PostgreSQL は、サーバープロセスがアイドル状態のとき、またはクライアントにデータを送信しようとしたときに、デッド接続を効率的に識別してクリーンアップします。ただし、アイドル状態のセッション、クライアント入力を待っているセッション、またはクエリがアクティブに実行されているセッションでは、検出は困難です。これらのシナリオを処理するために、PostgreSQL は `tcp_keepalives_*`、`tcp_user_timeout`、および `client_connection_check_interval` パラメータを提供します。
**Topics**
+ [
## TCP キープアライブを理解する
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [
## RDS for PostgreSQL の主要な TCP キープアライブパラメータ
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [
## TCP キープアライブ設定のユースケース
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [
## ベストプラクティス
](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## TCP キープアライブを理解する
TCP キープアライブは、接続の整合性の維持と検証に役立つプロトコルレベルのメカニズムです。各 TCP 接続は、キープアライブ動作を管理するカーネルレベルの設定を維持します。キープアライブタイマーの有効期限が切れると、システムは以下を実行します。
+ データがなく、ACK フラグが設定されているプローブパケットを送信します。
+ TCP/IP 仕様に従ってリモートエンドポイントからのレスポンスを待ちます。
+ 応答の有無に基づいて接続状態を管理します。
## RDS for PostgreSQL の主要な TCP キープアライブパラメータ
| パラメータ | 説明 | デフォルト値 |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Specifies number of seconds of inactivity before sending keepalive message. | 300 |
| tcp\$1keepalives\$1interval | Specifies number of seconds between retransmissions of unacknowledged keepalive messages. | 30 |
| tcp\$1keepalives\$1count | Maximum lost keepalive messages before declaring connection dead | 2 |
| tcp\$1user\$1timeout | Specifies how long (in Milliseconds) unacknowledged data can remain before forcibly closing the connection. | 0 |
| client\$1connection\$1check\$1interval | Sets the interval (in Milliseconds) for checking client connection status during long-running queries. This ensures quicker detection of closed connections. | 0 |
## TCP キープアライブ設定のユースケース
### アイドルセッションを存続させる
アイドル状態が原因でファイアウォールまたはルーターによってアイドル状態の接続が終了されないようにするには
+ キープアライブパケットを定期的に送信するように `tcp_keepalives_idle` を設定します。
### デッド接続の検出
デッド接続を迅速に検出するには
+ `tcp_keepalives_idle`、`tcp_keepalives_interval`、および `tcp_keepalives_count` を調整します。例えば、Aurora PostgreSQL のデフォルトでは、デッド接続を検出するのに約 1 分 (2 プローブ × 30 秒) かかります。これらの値を小さくすると、検出を速めることができます。
+ `tcp_user_timeout` を使用して、確認の最大待機時間を指定します。
TCP キープアライブ設定は、カーネルがデッド接続を検出するのに役立ちますが、PostgreSQL はソケットが使用されるまで動作しない場合があります。セッションが長いクエリを実行している場合、デッド接続はクエリの完了後にのみ検出される可能性があります。PostgreSQL 14 以降のバージョンでは、`client_connection_check_interval` はクエリの実行中にソケットを定期的にポーリングすることで、デッド接続の検出を迅速化できます。
## ベストプラクティス
+ **妥当なキープアライブ間隔を設定する:** `tcp_user_timeout`、`tcp_keepalives_idle`、`tcp_keepalives_count`、および `tcp_keepalives_interval` を調整して、検出速度とリソースの使用のバランスを取ります。
+ **環境に合わせて最適化する:** 設定をネットワーク動作、ファイアウォールポリシー、およびセッションのニーズに合わせます。
+ **PostgreSQL の機能を活用する:** PostgreSQL 14 以降のバージョンで `client_connection_check_interval` を使用して、効率的な接続チェックを行います。
# Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用
autovacuum 機能を使用して、PostgreSQL DB インスタンスの状態を維持することを強くお勧めします。autovacuum は、VACUUM コマンドと ANALYZE コマンドのスタートを自動化します。自動バキュームが、多数のタプルが挿入、更新、または削除されたテーブルを確認します。確認後、自動バキュームは PostgreSQL データベースから古いデータやタプルを削除することで、ストレージを再利用します。
デフォルトの PostgreSQL DB パラメータグループのいずれかを使用して作成した RDS for PostgreSQL DB インスタンスでは、デフォルトで自動バキュームがオンになっています。autovacuum 機能に関連するその他の設定パラメータもデフォルトで設定されます。これらのデフォルト値は汎用的であるため、特定のワークロードに対して、autovacuum 機能に関連付けられているパラメータの一部をチューニングすることには利点があります。
次に、autovacuum の詳細と、RDS for PostgreSQL DB インスタンスでそのパラメータの一部をチューニングする方法について説明します。概要については、「[PostgreSQL を使用するためのベストプラクティス](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL)」を参照してください。
**Topics**
+ [
## autovacuum のメモリを割り当てる
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [
## トランザクション ID の循環の可能性を減らす
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [
# データベース内のテーブルにバキューム処理が必要かどうかの判別
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [
# 現在 autovacuum の対象となっているテーブルの判別
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [
# Autovacuum が現在実行されているかどうかと実行されている時間の判別
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [
# 手動バキュームフリーズの実行
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [
# autovacuum の実行中にテーブルのインデックスを再作成する
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [
# 大きなインデックスを使った autovacuum の管理
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [
# autovacuum に影響を与えるその他のパラメータ
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [
# テーブルレベルの autovacuum パラメータを設定する
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [
# 自動バキュームおよびバキュームアクティビティのログ記録
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [
# 無効なデータベースでの自動バキュームの動作を理解する
](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [
# RDS for PostgreSQL で積極的なバキュームのブロック要因を特定して解決する
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## autovacuum のメモリを割り当てる
autovacuum のパフォーマンスに影響を与える最も重要なパラメータの 1 つは、[https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM) パラメータです。RDS for PostgreSQL バージョン 14 以前では、`autovacuum_work_mem` パラメータは -1 に設定されており、`maintenance_work_mem` の設定が代わりに使用されていることを示します。他のすべてのバージョンでは、`autovacuum_work_mem` は GREATEST(\$1DBInstanceClassMemory/32768\$1, 65536) によって決定されます。
手動バキュームオペレーションは常に `maintenance_work_mem` 設定を使用し、デフォルト設定は GREATEST(\$1DBInstanceClassMemory/63963136\$11024\$1, 65536) です。また、より的を絞った手動 `VACUUM` オペレーションを実現するために、`SET` のコマンドを使用してセッションレベルで調整することもできます。
`autovacuum_work_mem` は、インデックスをバキュームするためのデッドタプル (`pg_stat_all_tables.n_dead_tup`) の識別子を保持するため、autovacuum のメモリを決定します。
計算を実行して `autovacuum_work_mem` パラメータの値を決定するときは、次の点に注意してください。
+ パラメータの設定値が低すぎると、バキューム処理が完了するまでにテーブルを複数回スキャンすることが必要になる場合があります。このような複数のスキャンは、パフォーマンスに悪影響を及ぼすことがあります。より大きなインスタンスでは、`maintenance_work_mem` または `autovacuum_work_mem` を少なくとも 1 GB に設定することで、デッドタプル数が多いテーブルをバキュームするためのパフォーマンスが向上します。ただし、PostgreSQL バージョン 16 以前では、バキュームのメモリ使用量は 1 GB に制限されています。これは、1 回のパスで約 1 億 7,900 万個のデッドタプルを処理するのに十分な量です。テーブルのデッドタプルがこれよりも多い場合、バキュームはテーブルのインデックスを複数回通過させる必要があり、所要時間が大幅に増加します。PostgreSQL バージョン 17 以降、1 GB の制限はなく、自動バキュームは基数ツリーを使用して 1 億 7,900 万を超えるタプルを処理できます。
タプル識別子のサイズは 6 バイトです。テーブルのインデックスのバキュームに必要なメモリを推定するには、`pg_stat_all_tables.n_dead_tup` をクエリしてデッドタプル数を求め、この数に 6 を掛けて、1 回のパスでインデックスをバキュームするのに必要なメモリを決定します。以下のクエリを使用できます。
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ `autovacuum_work_mem` パラメータは、`autovacuum_max_workers` パラメータと連動して機能します。`autovacuum_max_workers` 間の各ワーカーは、割り当てたメモリを使用できます。小さいテーブルが多数ある場合、`autovacuum_max_workers` の割り当てを増やして `autovacuum_work_mem` の割り当てを減らします。大きなテーブル (100 GB 以上) がある場合は、メモリの割り当てを増やしてワーカープロセス数を減らします。最も大きいテーブルを正常に処理するには、十分なメモリを割り当てる必要があります。したがって、ワーカープロセスとメモリの組み合わせが、割り当てるメモリの合計と等しくなることを確認してください。
## トランザクション ID の循環の可能性を減らす
autovacuum に関連するパラメータグループの設定は、トランザクション ID の循環を防ぐほどは排除率が高くない場合があります。この問題に対処するために、RDS for PostgreSQL には autovacuum パラメータ値を自動的に適応させるメカニズムが用意されています。*適応型 autovacuum* は、RDS for PostgreSQL の機能です。[トランザクション ID の循環](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)に関する詳しい説明については、PostgreSQL ドキュメントを参照してください。
適応型 autovacuum は、動的パラメータ `rds.adaptive_autovacuum` が ON に設定されている RDS for PostgreSQL インスタンスでは、デフォルトでオンになります。この設定をオンにしておくことを強くお勧めします。ただし、autovacuum パラメータのアダプティブチューニングをオフにする場合は、`rds.adaptive_autovacuum` パラメータを 0 または OFF に設定します。
トランザクション ID の循環は、Amazon RDS で autovacuum パラメータをチューニングした後でも発生する場合があります。トランザクション ID の循環に対して Amazon CloudWatch アラームを実装することをお勧めします。詳細については、AWS データベースブログの記事「[Implement an early warning system for transaction ID wraparound in RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/)」(RDS for PostgreSQL でトランザクション ID の循環に早期警告システムを実装する) を参照してください。
自動バキュームパラメータのアダプティブチューニングをオンにすると、CloudWatch メトリクス `MaximumUsedTransactionIDs` が `autovacuum_freeze_max_age` パラメータの値または 500,000,000 のいずれか大きいほうに達したときに、Amazon RDS で自動バキュームパラメータの調整が開始されます。
テーブルでトランザクション ID の循環の傾向が続く場合、Amazon RDS では自動バキュームパラメータの調整が続行されます。続行される調整ごとに、循環を避けるために autovacuum に割り当てられる専用のリソースが増えます。Amazon RDS は、以下の autovacuum 関連のパラメータを更新します。
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
これらのパラメータが RDS で変更されるのは、新しい値で autovacuum による排除率が高くなる場合に限られます。パラメータは、DB インスタンスのメモリで変更されます。パラメータグループの値は変更されません。現在のメモリ内の設定を確認するには、PostgreSQL の [SHOW](https://www.postgresql.org/docs/current/sql-show.html) SQL コマンドを使用します。
これらの自動バキュームパラメータのいずれかが Amazon RDS で変更されると、影響を受ける DB インスタンスでイベントが生成されます。このイベントは、AWS マネジメントコンソール や Amazon RDS API を介して表示できます。CloudWatch メトリクス `MaximumUsedTransactionIDs` がしきい値より低い値に戻ると、Amazon RDS はメモリ内の自動バキューム関連のパラメータをリセットして、パラメータグループで指定されている値に戻します。次に、この変更に対応する別のイベントが生成されます。
# データベース内のテーブルにバキューム処理が必要かどうかの判別
次のクエリを使用して、データベース内のフリーズしていないトランザクションの数を表示できます。データベースの `datfrozenxid` 行の `pg_database` 列は、そのデータベースに表示されている正常なトランザクション ID の下限です。この列は、データベース内のテーブルあたりの `relfrozenxid` 値の最小数です。
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
例えば、前述のクエリの実行結果は以下のようになります。
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
データベースのトランザクション ID 数が 20 億に達すると、トランザクション ID (XID) の循環が発生し、データベースは読み取り専用になります。このクエリを使用してメトリクスを生成し、1 日に数回実行できます。デフォルトでは、autovacuum は保持するトランザクション数が 200,000,000 以下になるように設定されます ()。[https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
サンプルモニタリング戦略は次のようになります。
+ `autovacuum_freeze_max_age` の値を 2 億トランザクションに設定します。
+ テーブルのフリーズしていないトランザクション数が 5 億に達すると、重要度が低いアラームがトリガーされます。これは無効な値ではありませんが、autovacuum が遅れていることを示している場合があります。
+ テーブルのトランザクション数が 10 億に達した場合は、対処を要するアラームとして扱う必要があります。一般的に、パフォーマンス上の理由から、トランザクション数は `autovacuum_freeze_max_age` に近い値にしてください。以下の推奨事項を使用して調査することをお勧めします。
+ テーブルのバキューム処理されていないトランザクション数が 15 億に達すると、重要度が高いアラームがトリガーされます。データベースでトランザクション ID をどれだけ速く使用するかによりますが、このアラームは、システムに autovacuum を実行する時間がないことを示している場合があります。この場合は、この問題を早急に解決することをお勧めします。
テーブルのサイズがこれらのしきい値を頻繁に超える場合は、自動バキュームパラメータをさらに変更します。デフォルトでは、手動で VACUUM (コストベースの遅延が無効) を使用するほうが、デフォルトの autovacuum を使用するより排除率が高くなりますが、システム全体に与える負担が増えます。
次の構成を推奨します。
+ この場合、最も古いトランザクションの経過時間を認識できるように、モニタリングメカニズムをオンにしてください。
トランザクション ID の循還について警告するプロセスを作成する方法については、AWS のデータベースブログの記事「[Amazon RDS for PostgreSQL でトランザクション ID の循環に早期警告システムを実装する](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/)」を参照してください。
+ 処理の多いテーブルでは、autovacuum の使用に加えて、メンテナンスウィンドウ中に手動でバキュームフリーズを定期的に実行してください。手動バキュームフリーズの実行については、「[手動バキュームフリーズの実行](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)」を参照してください。
# 現在 autovacuum の対象となっているテーブルの判別
多くの場合、1 つ以上のテーブルにバキューム処理が必要です。`relfrozenxid` の値が `autovacuum_freeze_max_age` のトランザクション数を超えているテーブルは、常に autovacuum の処理対象となります。それ以外の場合、前回の VACUUM 以降「古い」とされたタプルの数が「バキュームしきい値」を超えると、テーブルがバキューム処理されます。
[autovacuum しきい値](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM)は、次のように定義されます。
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
ここで、`vacuum base threshold` は `autovacuum_vacuum_threshold`、`vacuum scale factor` は `autovacuum_vacuum_scale_factor`、`number of tuples` は `pg_class.reltuples` です。
データベースに接続しているときに、次のクエリを実行し、自動バキュームがバキューム処理の対象と見なしているテーブルのリストを表示します。
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Autovacuum が現在実行されているかどうかと実行されている時間の判別
テーブルを手動でバキューム処理する必要がある場合、必ず自動バキュームが現在実行されているかどうか判別してください。実行されている場合、さらに効率的に実行されるようにパラメータを調整するか、自動バキュームを一時的にオフに切り替えて VACUUM を手動で実行できるようにする必要がある場合があります。
次のクエリを使用して、autovacuum が実行中か、どのくらいの時間実行中か、また別のセッションの待機中かを判別します。
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
クエリが実行されると、次のような出力が表示されます。
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
いくつかの問題が原因で autovacuum セッションの実行が長期間 (複数日) に渡る場合があります。最もよくある問題は、[https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) パラメータ値で設定されたテーブルのサイズまたは更新速度が小さすぎることです。
次の計算式を使用して、`maintenance_work_mem` パラメータ値を設定することをお勧めします。
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
実行時間が短い autovacuum セッションは、以下の問題を示している可能性もあります。
+ ワークロード用の `autovacuum_max_workers` が十分ではないことを示している場合があります。この場合は、ワーカーの数を指定する必要があります。
+ インデックスの破損を示している場合があります (自動バキュームがクラッシュし、同じリレーションで再起動されますが進行はありません)。この場合は、手動 `vacuum freeze verbose table` を実行して正確な原因を確認します。
# 手動バキュームフリーズの実行
バキュームプロセスが既に実行されているテーブルで、手動バキュームを実行できます。これは、トランザクション数が 20 億に近づいている (または、モニタリングしているしきい値を上回った) テーブルに気付いた場合に役立ちます。
次の手順はガイドラインであり、プロセスにはいくつかのバリエーションがあります。例えば、テスト時に、[https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) パラメータの設定値が小さすぎて、テーブルに早急な対処が必要であることに気づいたとします。ただし、今はインスタンスをバウンスしたくない場合があります。前のセクションのクエリを使用することで、問題のあるテーブルを判別し、長時間実行されている autovacuum セッションを確認できます。`maintenance_work_mem` パラメータ設定の変更が必要であることがわかっていても、すぐに対処して問題のテーブルにバキューム処理を実行する必要があります。このような場合、次の手順で対応します。
**バキュームフリーズを手動で実行するには**
1. バキュームを実行するテーブルを含むデータベースへのセッションを 2 つ開きます。2 番目のセッションで、接続が中断された場合にセッションを維持する「screen」または他のユーティリティを使用します。
1. セッション 1 で、テーブルで実行されている自動バキュームセッションのプロセス ID (PID) を取得します。
次のクエリを実行し、autovacuum セッションの PID を取得します。
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. セッション 2 で、このオペレーションに必要なメモリの量を計算します。この例では、このオペレーションに最大 2GB のメモリを使用できると決めたため、現在のセッションの [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) を 2GB に設定します。
```
SET maintenance_work_mem='2 GB';
SET
```
1. セッション 2 で、テーブルに対して `vacuum freeze verbose` コマンドを発行します。現在のところ PostgreSQL には進行状況レポートがないため、verbose 設定はアクティビティを確認するのに役立ちます。
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. セッション 1 で、自動バキュームがバキュームセッションをブロックしていた場合、`pg_stat_activity` は、バキュームセッションを待機中であること (`T`) を示します。この場合は、次のように自動バキュームプロセスを終了します。
```
SELECT pg_terminate_backend('the_pid');
```
**注記**
Amazon RDS の一部の下位バージョンでは、前述のコマンドを使用して自動バキュームプロセスを終了できず、次のエラーで失敗します: `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`。
この時点で、セッションがスタートされます。このテーブルは作業リストの一番上にあると思われるため、自動バキュームは即座に再開します。
1. セッション 2 で `vacuum freeze verbose` コマンドを開始し、セッション 1 で自動バキュームプロセスを終了します。
# autovacuum の実行中にテーブルのインデックスを再作成する
インデックスが破損した場合、autovacuum はテーブルの処理を続けますが失敗します。この状況で手動バキュームを試みると、次のようなエラーメッセージが表示されます。
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
インデックスが破損しているときに、自動バキュームをテーブルで実行しようとすると、既に実行中の自動バキュームセッションと競合します。「[REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html)」コマンドを発行する場合は、テーブルに対する排他ロックを取り除きます。書き込みオペレーションがブロックされ、この特定のインデックスを使用する読み込みオペレーションもブロックされます。
**autovacuum がテーブルに対して実行されているときにテーブルのインデックスを再作成するには**
1. バキュームを実行するテーブルを含むデータベースへのセッションを 2 つ開きます。2 番目のセッションで、接続が中断された場合にセッションを維持する「screen」または他のユーティリティを使用します。
1. セッション 1 で、テーブルを実行している autovacuum セッションの PID を取得します。
次のクエリを実行し、autovacuum セッションの PID を取得します。
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. セッション 2 で、reindex コマンドを発行します。
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. セッション 1 で、自動バキュームがプロセスをブロックしていた場合、`pg_stat_activity` で、バキュームセッションの [waiting] (待機) が「T」であることを確認できます。この場合、自動バキュームプロセスを終了します。
```
SELECT pg_terminate_backend('the_pid');
```
この時点で、セッションがスタートされます。このテーブルは作業リストの一番上にあると思われるため、autovacuum が即座に再開される点に注意することが重要です。
1. セッション 2 で コマンドを開始し、セッション 1 で自動バキュームプロセスを終了します。
# 大きなインデックスを使った autovacuum の管理
操作の一環として、*autovacuum* はテーブル上で実行している間にいくつかの[バキュームフェーズ](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES)を実行します。テーブルをクリーンアップする前に、まずすべてのインデックスがバキューム処理されます。複数の大きなインデックスを削除する場合、このフェーズではかなりの時間とリソースを消費します。したがって、ベストプラクティスとして、テーブル上のインデックスの数を制御し、未使用のインデックスを削除してください。
このプロセスでは、まずインデックス全体のサイズを確認します。次に、次の例に示すように、削除できるインデックスがあるかどうかを確認します。
**テーブルとそのインデックスのサイズを確認するには**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
この例では、インデックスのサイズはテーブルよりも大きくなっています。この違いにより、インデックスが肥大化したり使用されなかったりするため、パフォーマンスの問題が発生し、自動バキュームや挿入オペレーションに影響する可能性があります。
**未使用のインデックスを確認するには**
[https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW) ビューを使用すると、`idx_scan` 列でインデックスがどのくらいの頻度で使用されているかを確認できます。次の例では、未使用のインデックスに `0` の `idx_scan` 値があります
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**注記**
これらの統計情報は、統計がリセットされた時点から増加します。例えば、あるビジネス四半期末にのみ使用される、または特定のレポートにのみ使用されるインデックスがあるとします。統計がリセットされてから、このインデックスが使用されていない可能性があります。詳細については、「[統計関数](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS)」を参照してください。一意性を保証するために使用されるインデックスはスキャンされないため、未使用のインデックスとして識別しないでください。未使用のインデックスを特定するには、アプリケーションとそのクエリに関する深い知識が必要です。
データベースの統計が最後にリセットされた日時を確認するには、[ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW]( https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW) を使用してください。
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## テーブルをできるだけ早くバキューム処理する
**RDS for PostgreSQL 12 以上**
大きなテーブルにインデックスが多すぎる場合、DB インスタンスがトランザクション ID ラップアラウンド (XID) に近づいている可能性があります。これは XID カウンターが 0 にラップアラウンドするタイミングです。チェックを外したままにすると、この状況では、データが失われる可能性があります。ただし、インデックスをクリーンアップせずにテーブルをすばやくバキューム処理できます。RDS for PostgreSQL 12 以上では、[https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html) 句で VACUUM を使用することができます。
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
自動バキュームセッションが既に実行されている場合、手動 VACUUM を開始するにはセッションを終了する必要があります。手動バキュームフリーズの実行については、「[手動バキュームフリーズの実行](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)」を参照してください。
**注記**
インデックスのクリーンアップを定期的にスキップすると、インデックスが肥大化し、スキャンのパフォーマンスが低下します。インデックスはデッド行を保持し、テーブルはデッドラインポインタを保持します。その結果、`pg_stat_all_tables.n_dead_tup` は autovacuum またはインデックスクリーンアップを含む手動 VACUUM が実行されるまで増加します。ベストプラクティスとして、この手順は、トランザクション ID の循環を防ぐためにのみ使用してください。
**RDS for PostgreSQL 11 以降**
ただし、RDS for PostgreSQL 11 以前のバージョンでは、バキューム処理をより速く完了させる唯一の方法は、テーブルのインデックス数を減らすことです。インデックスを削除すると、クエリプランに影響する可能性があります。未使用のインデックスを最初に削除し、XID の循環が間近になったらインデックスを削除することをお勧めします。バキューム処理が完了したら、これらのインデックスを再作成できます。
# autovacuum に影響を与えるその他のパラメータ
次のクエリは、autovacuum とその動作に直接影響を与えるパラメータのいくつかについて値を表示します。[autovacuum パラメータ](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html)の詳細については、PostgreSQL のドキュメントを参照してください。
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
これらはすべて autovacuum に影響を与えますが、最も重要なものは以下のとおりです。
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# テーブルレベルの autovacuum パラメータを設定する
自動バキューム関連の[ストレージパラメータ](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS)をテーブルレベルで設定できます。これは、データベース全体の動作を変更するより適切である場合があります。大きなテーブルでは、極端な設定にする必要が生じる場合がありますが、autovacuum がすべてのテーブルに対してそのように動作するわけではありません。
次のクエリは、現在テーブルレベルのオプションが設定されているテーブルを表示します。
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
これが役立つ可能性がある例として、残りのテーブルよりかなり大きいテーブルがあります。1 個の 300 GB のテーブルと、他の 30 個の 1 GB 未満のテーブルがあるとします。この場合、システム全体の動作を変更しないで、大きなテーブルのいくつかの特定のパラメータを設定できます。
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
これを行うと、このテーブルでコストベースの自動バキューム遅延がなくなりますが、システムでのリソース使用量が多くなります。通常、自動バキュームは `autovacuum_cost_limit` に達するたびに `autovacuum_vacuum_cost_delay` で一時停止します。詳細については、「PostgreSQL ドキュメント」の「[cost-based vacuuming](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST)」(コストベースのバキューム処理) を参照してください。
# 自動バキュームおよびバキュームアクティビティのログ記録
自動バキュームアクティビティに関する情報は、`rds.force_autovacuum_logging_level`パラメータで指定したレベルに基づいて `postgresql.log` に送信されます。このパラメータで指定できる値、およびその値がデフォルトで設定されている PostgreSQL バージョンは次のとおりです。
+ `disabled` (PostgreSQL 10、PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12、PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 以降)
+ `error`、ログ、`fatal`、`panic`
`rds.force_autovacuum_logging_level` では `log_autovacuum_min_duration` パラメータが使用されます。`log_autovacuum_min_duration` パラメータの値はしきい値 (ミリ秒単位) です。このしきい値を超過すると、自動バキュームアクションがログに記録されます。`-1` に設定するとログに何も記録されませんが、0 に設定するとすべてのアクションが記録されます。`rds.force_autovacuum_logging_level` と同様に、`log_autovacuum_min_duration` のデフォルト値はバージョンによって次のように異なります。
+ `10000 ms` – PostgreSQL 14、PostgreSQL 13、PostgreSQL 12、および PostgreSQL 11
+ `(empty)` – PostgreSQL 10 と PostgreSQL 9.6 の場合、デフォルト値はありません
`rds.force_autovacuum_logging_level` を `WARNING` に設定することをお勧めします。`log_autovacuum_min_duration` についても 1,000～5,000 の値に設定することをお勧めします。5,000 に設定すると、5,000 ミリ秒を超える長さのアクティビティがログに記録されます。-1 以外の設定では、ロックの競合または同時に削除されたリレーションが原因で自動バキュームアクションがスキップされた場合にも、メッセージがログに記録されます。詳細については、「PostgreSQL のドキュメント」の「[Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html)」(自動バキューム処理) を参照してください。
問題のトラブルシューティングを行うために、`rds.force_autovacuum_logging_level` パラメータを `debug1` から `debug5` までのデバッグレベルの 1 つに変更し、最も詳しい情報を取得します。デバッグ設定は、短期間かつトラブルシューティングの目的でのみ使用することをお勧めします。詳細については、「PostgreSQL のドキュメント」の「[When to log](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN)」(ログ記録のタイミング) を参照してください。
**注記**
PostgreSQL では、`rds_superuser` アカウントが `pg_stat_activity` 内の autovacuum セッションを表示できます。例えば、コマンドの実行をブロックしている autovacuum セッション、あるいは手動で発行される vacuum コマンドよりも実行スピードが遅い autovacuum セッションを特定して終了することもできます。
# 無効なデータベースでの自動バキュームの動作を理解する
新しい値 `-2` が `pg_database` カタログの `datconnlimit` 列に導入され、DROP DATABASE 操作の途中で中断されたデータベースが無効であることが示されます。
この新しい値は、次の RDS for PostgreSQL バージョンで使用できます。
+ 15.4 以降のすべてのバージョン
+ 14.9 以降のバージョン
+ 13.12 以降のバージョン
+ 12.16 以降のバージョン
+ 11.21 以降のバージョン
無効なデータベースは、有効なデータベースに対する自動バキュームのフリーズ機能には影響しません。自動バキュームは無効なデータベースを無視します。そのため、通常のバキューム操作は、PostgreSQL 環境内のすべての有効なデータベースに対して正常かつ効率的に機能し続けます。
**Topics**
+ [
## トランザクション ID のモニタリング
](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [
## モニタリングクエリの調整
](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [
## 無効なデータベースの問題の解決
](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## トランザクション ID のモニタリング
`age(datfrozenxid)` 関数は、通常、トランザクション ID のラップアラウンドを防ぐため、データベースのトランザクション ID (XID) の経過時間をモニタリングするために使用されます。
無効なデータベースは自動バキュームから除外されるため、そのトランザクション ID (XID) カウンターは最大値 `2 billion` に達すると、`- 2 billion` にラップアラウンドして、このサイクルを無限に続けることができます。トランザクション ID のラップアラウンドをモニタリングする一般的なクエリは次のようになります。
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
ただし、`datconnlimit` に -2 値を導入した場合、無効なデータベースによってこのクエリの結果が歪む可能性があります。これらのデータベースは有効ではなく、定期的なメンテナンスチェックの一部に含めるべきではないため、誤検出が発生し、`age(datfrozenxid)` が実際よりも大きいという誤解を招く可能性があります。
## モニタリングクエリの調整
正確なモニタリングを行うには、モニタリングクエリを調整して無効なデータベースを除外する必要があります。次の推奨クエリに従ってください。
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
このクエリにより、有効なデータベースのみが `age(datfrozenxid)` 計算で考慮され、PostgreSQL 環境全体のトランザクション ID の経過時間が正確に反映されます。
## 無効なデータベースの問題の解決
無効なデータベースに接続しようとすると、次のようなエラーメッセージが表示されることがあります。
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
さらに、`log_min_messages` パラメータが `DEBUG2` 以上に設定されている場合、自動バキュームプロセスが無効なデータベースをスキップしていることを示す次のログエントリが表示されることがあります。
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
この問題を解決するには、接続の試行中に提供される `HINT` に従ってください。RDS マスターアカウントまたは `rds_superuser` ロールを持つデータベースアカウントを使用して有効なデータベースに接続し、無効なデータベースを削除します。
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# RDS for PostgreSQL で積極的なバキュームのブロック要因を特定して解決する
PostgreSQL でデータベースの正常な状態を維持するためにはバキューム処理が不可欠です。バキューム処理によって、ストレージの再利用が可能になり、[トランザクション ID の循環](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)に関する問題を回避できます。しかし、バキューム処理が目的どおりに動作しなくなることもあります。これにより、パフォーマンスの低下やストレージの肥大化が生じ、トランザクション ID の循環によって DB インスタンスの可用性にも影響する場合があります。したがって、データベースのパフォーマンスと可用性を最適化するには、これらの問題を特定して解決することが不可欠です。「[Understanding autovacuum in Amazon RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)」で自動バキュームの詳細について確認してください。
`postgres_get_av_diag()` 関数は、積極的なバキュームの進行を妨げたり遅らせたりしている問題を特定するのに役立ちます。推奨事項が提示され、問題が特定可能な場合はそれを解決するためのコマンドが、問題を特定できない場合は詳細な診断のためのガイダンスが得られます。積極的なバキュームのブロック要因は、経過時間が RDS の[適応型自動バキューム](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)のしきい値である 5 億トランザクション ID を超えた場合に報告されます。
**トランザクション ID の経過時間とは**
トランザクション ID の `age()` 関数は、データベース (`pg_database.datfrozenxid`) またはテーブル (`pg_class.relfrozenxid`) の最も古いフリーズしていないトランザクション ID 以降に発生したトランザクションの数を計算します。この値は、前回の積極的なバキューム操作以降のデータベースアクティビティを示し、今後の VACUUM プロセスのワークロードについての見通しを示します。
**積極的なバキュームとは**
積極的な VACUUM 操作では、通常の VACUUM で省略されるページも含め、テーブル内のすべてのページが包括的にスキャンされます。この徹底的なスキャンは、最大経過時間に近づいているトランザクション ID を「フリーズ」することを目指しており、[トランザクション ID の循環](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)と呼ばれる状況を効果的に防止します。
`postgres_get_av_diag()` で報告されるブロック要因は、5 億トランザクション以上古いものとなります。
**Topics**
+ [
# RDS for PostgreSQL に自動バキュームのモニタリングツールと診断ツールをインストールする
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [
# RDS for PostgreSQL の postgres\$1get\$1av\$1diag() の関数
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [
# RDS for PostgreSQL での識別可能なバキュームブロック要因の解決
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [
# RDS for PostgreSQL での識別不能なバキュームブロック要因の解決
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [
# RDS for PostgreSQL でバキュームのパフォーマンスに関する問題を解決する
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [
# RDS for PostgreSQL の NOTICE メッセージの説明
](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# RDS for PostgreSQL に自動バキュームのモニタリングツールと診断ツールをインストールする
`postgres_get_av_diag()` 関数は現在、次の RDS for PostgreSQL バージョンで使用できます。
+ 17.2 以降の 17 バージョン
+ 16.7 以降の 16 バージョン
+ 15.11 以降の 15 バージョン
+ 14.16 以降の 14 バージョン
+ 13.19 以降の 13 バージョン
`postgres_get_av_diag()` を使用するには、`rds_tools` 拡張機能を作成します。
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
拡張機能がインストールされていることを確認します。
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
関数が作成されていることを確認します。
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# RDS for PostgreSQL の postgres\$1get\$1av\$1diag() の関数
`postgres_get_av_diag()` 関数は、RDS for PostgreSQL データベースで妨害または遅延が生じている自動バキュームプロセスに関する診断情報を取得します。正確な結果を得るには、最も古いトランザクション ID を持つデータベースでクエリを実行する必要があります。最も古いトランザクション ID を持つデータベースを使用する方法の詳細については、「[トランザクション ID の経過時間が最も古いデータベースに接続していない](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)」を参照してください。
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
`postgres_get_av_diag()` 関数は次の情報を含むテーブルを返します。
**blocker**
バキュームをブロックしているデータベースアクティビティのカテゴリを指定します。
+ [アクティブなステートメント](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [トランザクションでのアイドル状態](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [準備済みトランザクション](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [論理レプリケーションスロット](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [物理レプリケーションスロットを使用するリードレプリカ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [ストリーミングレプリケーションを使用するリードレプリカ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [一時テーブル](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**database**
該当しサポートされている場合にデータベースの名前を指定します。これは、アクティビティが進行中で、自動バキュームをブロックしている、またはこれからブロックするデータベースです。これは、接続してアクションを実行する必要があるデータベースです。
**blocker\$1identifier**
自動バキュームをブロックしている、またはこれからブロックするアクティビティの識別子を指定します。識別子は、プロセス ID に SQL ステートメント、準備済みトランザクション、リードレプリカの IP アドレス、および論理または物理レプリケーションスロットの名前を加えたものとなります。
**wait\$1event**
ブロックしているセッションの[待機イベント](PostgreSQL.Tuning.md)を指定し、次のブロック要因に適用されます。
+ アクティブなステートメント
+ トランザクションでのアイドル状態
**autovacum\$1lagging\$1by**
バックログ作業で自動バキュームが停滞しているトランザクションの数をカテゴリごとに指定します。
**suggestion**
ブロック要因を解決するための推奨事項を指定します。これらの手順には、アクティビティが存在するデータベースの名前 (該当する場合)、セッションのプロセス ID (PID)(該当する場合)、および実行するアクションが含まれます。
**suggested\$1action**
ブロック要因を解決するために実行する必要があるアクションを提案します。
# RDS for PostgreSQL での識別可能なバキュームブロック要因の解決
自動バキュームは積極的なバキュームを実行し、トランザクション ID の経過時間が RDS インスタンスの `autovacuum_freeze_max_age` パラメータで指定されたしきい値に達しないようにします。この経過時間は、Amazon CloudWatch メトリクス `MaximumUsedTransactionIDs` を使用して追跡できます。
Amazon RDS インスタンスの `autovacuum_freeze_max_age` の設定 (デフォルトは 2 億トランザクション ID) を確認するには、次のクエリを使用します。
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
`postgres_get_av_diag()` では、経過時間が Amazon RDS の[適応型自動バキューム](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)のしきい値である 5 億トランザクション ID を超えた場合にのみ、積極的なバキュームのブロック要因をチェックすることに注意してください。`postgres_get_av_diag()` で検出されるブロック要因は、5 億トランザクション以上古いものとなります。
`postgres_get_av_diag()` 関数は、次のタイプのブロック要因を識別します。
**Topics**
+ [
## アクティブなステートメント
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [
## トランザクションでのアイドル状態
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [
## 準備済みトランザクション
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [
## 論理レプリケーションスロット
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [
## リードレプリカ
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [
## 一時テーブル
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## アクティブなステートメント
PostgreSQL において、アクティブなステートメントとは、データベースによって現在実行されている SQL ステートメントです。これには、クエリ、トランザクション、または進行中のすべてのオペレーションが含まれます。`pg_stat_activity` を使ってモニタリングする場合、状態列には、対応する PID を持つプロセスがアクティブであることが示されます。
`postgres_get_av_diag()` 関数がアクティブなステートメントであるステートメントを識別すると、次のような出力を表示します。
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**推奨されるアクション**
`suggestion` 列のガイダンスに従って、ユーザーはアクティブなステートメントが存在するデータベースに接続できます。`suggested_action` 列で指定されているように、セッションを終了するオプションを慎重に検討することが推奨されます。終了しても安全な場合は、`pg_terminate_backend()` 関数を使用してセッションを終了できます。このアクションは、管理者 (RDS マスターアカウントなど) または必要な `pg_terminate_backend()` 権限を持つユーザーが実行できます。
**警告**
終了したセッションは、行われた変更を元に戻します (`ROLLBACK`)。要件に応じて、ステートメントを再度実行できます。ただし、自動バキュームプロセスが積極的なバキューム操作を完了した後にのみ実行することをお勧めします。
## トランザクションでのアイドル状態
トランザクションステートメントのアイドル状態とは、明示的なトランザクションを開き (`BEGIN` ステートメントの発行など)、何らかの作業を実行したセッションで、クライアントがさらに作業を渡すか、`COMMIT`、`ROLLBACK`、`END` (暗黙的な `COMMIT` になります) を発行してトランザクションの終了を通知するのを待っているセッションを指します。
`postgres_get_av_diag()` 関数が `idle in transaction` ステートメントをブロック要因として識別すると、次のような出力を表示します。
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**推奨されるアクション**
`suggestion` 列に示されているように、トランザクションセッションでのアイドル状態が存在するデータベースに接続し、`pg_terminate_backend()` 関数を使用してセッションを終了できます。ユーザーは、管理者 (RDS マスターアカウント) ユーザーでも、 `pg_terminate_backend()` 権限を持つユーザーでもかまいません。
**警告**
終了したセッションは、行われた変更を元に戻します (`ROLLBACK`)。要件に応じて、ステートメントを再度実行できます。ただし、自動バキュームプロセスが積極的なバキューム操作を完了した後にのみ実行することをお勧めします。
## 準備済みトランザクション
PostgreSQL では、[準備済みトランザクション](https://www.postgresql.org/docs/current/sql-prepare-transaction.html)と呼ばれる 2 相コミット戦略の一部であるトランザクションを使用できます。これらは、`max_prepared_transactions` パラメータをゼロ以外の値に設定することで有効になります。準備済みトランザクションは、データベースのクラッシュ、再起動、またはクライアントの切断後も、トランザクションが持続し、引き続き使用できるように設計されています。通常のトランザクションと同様に、トランザクション ID が割り当てられ、自動バキュームに影響を与える場合があります。準備状態のままにすると、自動バキュームはフリーズを実行できず、トランザクション ID の循環につながる可能性があります。
トランザクションマネージャによって解決されることなく無期限に準備状態となったトランザクションは、孤立した準備済みトランザクションになります。これを修正する唯一の方法は、`COMMIT PREPARED` コマンドまたは `ROLLBACK PREPARED` コマンドを使用してトランザクションをコミットするかロールバックすることです。
**注記**
準備済みトランザクションで作成されたバックアップには、復元後もそのトランザクションが含まれることに注意してください。このようなトランザクションを見つけて閉じる方法については、以下の情報を参照してください。
`postgres_get_av_diag()` 関数が準備済みトランザクションをブロック要因として識別すると、次の出力を表示します。
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**推奨されるアクション**
suggestion 列で説明されているように、準備済みトランザクションがあるデータベースに接続します。`suggested_action` 列に基づいて、`COMMIT` と `ROLLBACK` のどちらを実行するかを慎重に検討し、適切なアクションを選択します。
準備済みトランザクション全般をモニタリングするために、PostgreSQL には `pg_prepared_xacts` というカタログビューが用意されています。次のクエリを使用して、準備済みトランザクションを検索できます。
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## 論理レプリケーションスロット
レプリケーションスロットの目的は、ターゲットサーバーにレプリケートされるまで、未使用の変更を保持することです。詳細については、PostgreSQL の「[Logical replication](https://www.postgresql.org/docs/current/logical-replication.html)」を参照してください。
論理レプリケーションスロットには 2 つのタイプがあります。
**非アクティブな論理レプリケーションスロット**
レプリケーションが終了すると、未使用のトランザクションログは削除されず、レプリケーションスロットは非アクティブになります。非アクティブな論理レプリケーションスロットは、現在、サブスクライバーによって使用されていませんが、サーバーには残るため、WAL ファイルが保持され、古いトランザクションログが削除されなくなります。システムは LSN 情報が上書きされないよう保持する必要があるため、ディスク使用量が増加し、具体的には、自動バキュームで内部カタログテーブルをクリーンアップできなくなる可能性があります。放置するとカタログの肥大化とパフォーマンスの低下を招き、循環バキュームのリスクが増大して、トランザクションのダウンタイムが発生する可能性があります。
**アクティブだが遅い論理レプリケーションスロット**
論理レプリケーションのパフォーマンスの低下により、カタログのデッドタプルの削除が遅れることがあります。このレプリケーションの遅延により、`catalog_xmin` の更新が遅れ、カタログの肥大化や循環バキュームが発生する可能性があります。
`postgres_get_av_diag()` 関数が論理レプリケーションスロットをブロック要因として検出すると、次のような出力を表示します。
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**推奨されるアクション**
この問題を解決するには、レプリケーション設定で、適用プロセスを終了している可能性のあるターゲットスキーマまたはデータの問題を確認します。最も一般的な理由を次に示します。
+ 列の欠落
+ 互換性のないデータ型
+ データの不一致
+ データの欠落
問題がインフラストラクチャの問題に関連している場合
+ ネットワークの問題 - [互換性のないネットワーク状態にある Amazon RDS DB の問題を解決するにはどうすればよいですか?](https://repost.aws/knowledge-center/rds-incompatible-network)
+ データベースまたは DB インスタンスが、次の理由により使用できない
+ レプリカインスタンスのストレージが不足している - 「[Amazon RDS DB インスタンスのストレージが不足したときに発生する問題を解決する方法を教えてください](https://repost.aws/knowledge-center/rds-out-of-storage)」を参照して、ストレージの追加について確認してください。
+ 互換性のないパラメータ - 「[互換性のないパラメータステータスのままになっている Amazon RDS DB インスタンスを修正するにはどうすればよいですか?](https://repost.aws/knowledge-center/rds-incompatible-parameters)」を参照して、問題を解決する方法の詳細を確認してください。
インスタンスが AWS ネットワーク外または AWS EC2 上にある場合は、可用性またはインフラストラクチャ関連の問題の解決方法について管理者に問い合わせてください。
**非アクティブなスロットの削除**
**警告**
注意: レプリケーションスロットを削除する前に、レプリケーションが進行中ではないこと、レプリケーションスロットが非アクティブで回復不可能な状態であることを慎重に確認してください。スロットを途中で削除すると、レプリケーションが中断されたり、データが失われたりする可能性があります。
レプリケーションスロットが不要になったことを確認したら、削除して自動バキュームを続行できるようにします。条件 `active = 'f'` を指定することで、非アクティブなスロットのみが削除されます。
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## リードレプリカ
[Amazon RDS リードレプリカ](USER_PostgreSQL.Replication.ReadReplicas.md)で `hot_standby_feedback` 設定が有効になっている場合、リードレプリカで実行されているクエリで引き続き必要になる可能性のあるデッド行は、プライマリデータベースの自動バキュームで削除されません。これは、レプリケーションスロットを使用して管理されているかどうかにかかわらず、すべてのタイプの物理リードレプリカに影響します。スタンバイレプリカで実行されているクエリでは、[クエリの競合](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT)やキャンセルを防ぐために、これらの行をプライマリで利用できる状態に保つ必要があるため、こうした動作が必要になります。
**物理レプリケーションスロットを使用するリードレプリカ**
物理レプリケーションスロットを使用するリードレプリカでは、RDS for PostgreSQL でのレプリケーションの信頼性と安定性が大幅に強化されます。これらのスロットにより、プライマリデータベースはレプリカが処理するまで重要なログ先行書き込みファイルを保持し、ネットワークの中断中もデータ整合性を維持できます。
RDS for PostgreSQL バージョン 14 以降、すべてのレプリカでレプリケーションスロットが使用されます。以前のバージョンでは、クロスリージョンレプリカのみでレプリケーションスロットが使用されていました。
`postgres_get_av_diag()` 関数が物理レプリケーションスロットを使用するリードレプリカをブロック要因として検出すると、次のような出力を表示します。
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**ストリーミングレプリケーションを使用するリードレプリカ**
Amazon RDS では、バージョン 13 までの古いバージョンで、物理レプリケーションスロットを使用せずにリードレプリカを設定できます。このアプローチでは、プライマリが WAL ファイルをより積極的にリサイクルできるようにすることでオーバーヘッドを軽減します。これは、ディスク容量が制限された環境においてメリットがあり、ときどき発生するレプリケーションの遅延も許容できます。ただし、スロットを使用しない場合、WAL ファイルが欠落しないように、スタンバイは同期したままにする必要があります。Amazon RDS は、レプリカが遅れをとった場合にアーカイブされた WAL ファイルを使用して遅れを解消しますが、このプロセスには慎重なモニタリングが必要となり、時間がかかることがあります。
`postgres_get_av_diag()` 関数がストリーミングリードレプリカをブロック要因として検出すると、次のような出力を表示します。
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**推奨されるアクション**
`suggested_action` 列で推奨されているように、以下のオプションを慎重に検討して自動バキュームのブロックを解除します。
+ **クエリを終了する** – suggestion 列のガイダンスに従って、suggested\$1action 列で指定されているようにリードレプリカに接続できます。セッションを終了するオプションは慎重に検討することをお勧めします。終了しても安全であると判断した場合は、`pg_terminate_backend()` 関数を使用してセッションを終了できます。このアクションは、管理者 (RDS マスターアカウントなど) または必要な pg\$1terminate\$1backend() 権限を持つユーザーが実行できます。
リードレプリカで次の SQL コマンドを実行すると、プライマリのバキュームによる古い行のクリーンアップを妨げているクエリを終了できます。`backend_xmin` の値は、関数の出力で報告されます。
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **ホットスタンバイフィードバックを無効にする** – `hot_standby_feedback` パラメータがバキュームの大幅な遅延の原因となっている場合は、これを無効にすることを検討します。
`hot_standby_feedback` パラメータを使用すると、リードレプリカはクエリアクティビティについてプライマリに通知し、プライマリがスタンバイで使用されているテーブルや行をバキューム処理できないようにします。これによりスタンバイでのクエリの安定性が確保されますが、プライマリでのバキューム処理が大幅に遅延する可能性があります。この機能を無効にすると、プライマリはスタンバイが追いつくのを待たずにバキューム処理を進めることができます。ただし、プライマリによってバキューム処理された行にアクセスしようとすると、スタンバイでクエリのキャンセルや失敗が発生する可能性があります。
+ **不要になったリードレプリカを削除する** – リードレプリカが不要になった場合は、削除できます。これにより、関連するレプリケーションオーバーヘッドが解消され、プライマリがレプリカによって妨げられることなくトランザクションログをリサイクルできるようになります。
## 一時テーブル
`TEMPORARY` キーワードを使用して作成された[一時テーブル](https://www.postgresql.org/docs/current/sql-createtable.html)は、pg\$1temp\$1xxx などの一時スキーマにあり、それらを作成したセッションのみがアクセスできます。一時テーブルは、セッションが終了すると削除されます。ただし、このようなテーブルは PostgreSQL の自動バキュームプロセスには表示されず、テーブルを作成したセッションによって手動でバキューム処理する必要があります。別のセッションから一時テーブルのバキューム処理を試みても効果はありません。
異常な状況下では、テーブルを所有するアクティブなセッションがない状態で一時テーブルが存在します。致命的なクラッシュ、ネットワークの問題、または同様のイベントが原因でテーブルを所有するセッションが予期せず終了した場合、一時テーブルはクリーンアップされず、「孤立した」テーブルとして残される可能性があります。PostgreSQL 自動バキュームプロセスで孤立した一時テーブルが検出されると、次のメッセージがログに記録されます。
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
`postgres_get_av_diag()` 関数が一時テーブルをブロック要因として識別すると、次のような出力を表示します。この関数で一時テーブルに関連する出力を正しく表示するには、それらのテーブルが存在するのと同じデータベース内で関数を実行する必要があります。
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**推奨されるアクション**
出力の `suggestion` 列に示されている手順に従って、自動バキュームの実行を妨げている一時テーブルを特定して削除します。次のコマンドを使用して、`postgres_get_av_diag()` で報告された一時テーブルを削除します。`postgres_get_av_diag()` 関数で提示された出力に基づいてテーブル名を置き換えます。
```
DROP TABLE my_temp_schema.my_temp_table;
```
次のクエリを使用して、一時テーブルを識別できます。
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# RDS for PostgreSQL での識別不能なバキュームブロック要因の解決
このセクションでは、バキューム処理の進行を妨げる可能性のあるその他の理由について説明します。以下の問題は、現在、`postgres_get_av_diag()` 関数によって直接識別できません。
**Topics**
+ [
## 無効なページ
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [
## インデックスの不整合
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [
## トランザクションレートが極めて高い
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## 無効なページ
無効なページエラーは、PostgreSQL がページへのアクセス中にページのチェックサムの不一致を検出した場合に発生します。コンテンツが読み取れないため、自動バキュームでタプルがフリーズされません。これにより、クリーンアッププロセスが実質的に停止します。次のエラーが PostgreSQL の ログに書き込まれます。
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**オブジェクトタイプを判断する**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
エラーメッセージのパス `base/16403/186752608` は、次の情報を提供しています。
+ 「base」は PostgreSQL データディレクトリのディレクトリ名です。
+ 「16403」はデータベース OID であり、`pg_database` システムカタログで検索できます。
+ 「186752608」は `relfilenode` であり、`pg_class` システムカタログでスキーマとオブジェクト名を検索するために使用できます。
影響を受けるデータベースで次のクエリの出力をチェックすることで、オブジェクトタイプを判断できます。次のクエリは、oid: 186752608 のオブジェクト情報を取得します。OID を、発生したエラーに関連する OID に置き換えます。
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
詳細については、PostgreSQL のドキュメント「[https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html)」で、`pg_class` の `relkind` 列で示されるサポート対象のすべてのオブジェクトタイプを参照してください。
**ガイダンス**
この問題の最も効果的な解決策は、特定の Amazon RDS インスタンスの設定と、整合性のないページの影響を受けるデータの種類によって異なります。
**オブジェクトタイプがインデックスの場合**
インデックスを再構築することをお勧めします。
+ **`CONCURRENTLY` オプションの使用** – PostgreSQL バージョン 12 より前のバージョンでは、インデックスを再構築するには、排他的テーブルロックによってテーブルへのアクセスを制限する必要がありました。PostgreSQL バージョン 12 以降のバージョンでは、`CONCURRENTLY` オプションにより行レベルのロックが可能になり、テーブルの可用性が大幅に向上しています。コマンドは以下のとおりです。
```
REINDEX INDEX ix_name CONCURRENTLY;
```
`CONCURRENTLY` はそれほど破壊的ではありませんが、ビジー状態のテーブルでは時間がかかる場合があります。可能であれば、トラフィックが少ない時間帯にインデックスを構築することを検討してください。
詳細については、PostgreSQL ドキュメントの「[REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html)」を参照してください。
+ **`INDEX_CLEANUP FALSE` オプションの使用** – インデックスが大きく、完了までにかなりの時間がかかると予想される場合は、インデックスを除外しながら手動 `VACUUM FREEZE` を実行して自動バキュームのブロックを解除できます。この機能は PostgreSQL バージョン 12 以降で使用できます。
インデックスを無視すると、整合性のないインデックスのバキュームプロセスを省略して、循環の問題を軽減できます。ただし、無効なページの根本的な問題は解決されません。無効なページの問題に完全に対処し、これを解決するには、インデックスを再構築する必要があります。
**オブジェクトタイプがマテリアライズドビューの場合**
マテリアライズドビューで無効なページエラーが発生した場合は、影響を受けるデータベースにログインし、更新して無効なページを解決します。
マテリアライズドビューを更新します。
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
更新に失敗した場合は、再作成を試みます。
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
マテリアライズドビューを更新または再作成すると、基盤となるテーブルデータに影響を与えずにマテリアライズドビューが復元されます。
**他のすべてのオブジェクトタイプの場合**
他のすべてのオブジェクトタイプについては、AWS サポートに問い合わせてください。
## インデックスの不整合
論理的に整合性のないインデックスによって、自動バキュームの進行が妨げられる場合があります。次のエラーまたは同様のエラーは、インデックスのバキュームフェーズ中、または SQL ステートメントによってインデックスがアクセスされるときにログに記録されます。
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**ガイダンス**
手動 `VACUUM FREEZE` で `INDEX_CLEANUP` を使用してインデックスを再構築するか、インデックスを省略します。インデックスを再構築する方法の詳細については、「[オブジェクトタイプがインデックスの場合](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)」を参照してください。
+ **CONCURRENTLY オプションの使用** – PostgreSQL バージョン 12 より前のバージョンでは、インデックスを再構築するには、排他的テーブルロックによってテーブルへのアクセスを制限する必要がありました。PostgreSQL バージョン 12 以降のバージョンでは、CONCURRENTLY オプションにより行レベルのロックが可能になり、テーブルの可用性が大幅に向上しています。コマンドは以下のとおりです。
```
REINDEX INDEX ix_name CONCURRENTLY;
```
CONCURRENTLY はそれほど破壊的ではありませんが、ビジー状態のテーブルでは時間がかかる場合があります。可能であれば、トラフィックが少ない時間帯にインデックスを構築することを検討してください。詳細については、*PostgreSQL* ドキュメントの「[REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html)」を参照してください。
+ **INDEX\$1CLEANUP FALSE オプションの使用** – インデックスが大きく、完了までにかなりの時間がかかると予想される場合は、インデックスを除外しながら手動 VACUUM FREEZE を実行して自動バキュームのブロックを解除できます。この機能は PostgreSQL バージョン 12 以降で使用できます。
インデックスを無視すると、整合性のないインデックスのバキュームプロセスを省略して、循環の問題を軽減できます。ただし、無効なページの根本的な問題は解決されません。無効なページの問題に完全に対処し、これを解決するには、インデックスを再構築する必要があります。
## トランザクションレートが極めて高い
PostgreSQL では、トランザクションレートが高いと自動バキュームのパフォーマンスに大きな影響を与え、デッドタプルのクリーンアップが遅くなり、トランザクション ID の循環のリスクが高まります。トランザクションレートは、2 つの期間 (通常は 1 秒ごと) の `max(age(datfrozenxid))` の差を測定することでモニタリングできます。さらに、RDS Performance Insights の次のカウンターメトリクスを使用して、トランザクションの合計数であるトランザクションレート (xact\$1commit と xact\$1rollback の合計) を測定できます。
| Counter | タイプ | 単位 | メトリクス |
| --- | --- | --- | --- |
| xact\$1commit | トランザクション | 1 秒あたりのコミット数 | db.Transactions.xact\$1commit |
| xact\$1rollback | トランザクション | 1 秒あたりのロールバック数 | db.Transactions.xact\$1rollback |
急激な増加は、トランザクション負荷が高いことを示しており、自動バキュームが過負荷になり、肥大化、ロック競合、および潜在的なパフォーマンスの問題が発生する可能性があります。これにより、以下のような点で自動バキュームプロセスに悪影響が及ぶ可能性があります。
+ **テーブルアクティビティ:** バキューム処理されている特定のテーブルで大量のトランザクションが発生し、遅延が発生する可能性があります。
+ **システムリソース:** システム全体が過負荷になっている可能性があるため、自動バキュームが効率的に機能するために必要なリソースにアクセスすることが困難になります。
自動バキュームをより効果的に動作させ、遅延なくタスクに対処するために、次の戦略を検討してください。
1. 可能であれば、トランザクションレートを下げます。可能な場合は、類似したトランザクションをバッチ処理またはグループ化することを検討してください。
1. オフピークの時間帯は、毎晩、毎週、または隔週の手動 `VACUUM FREEZE` オペレーションで頻繁に更新されるテーブルをターゲットにします。
1. インスタンスクラスをスケールアップして、大量のトランザクションと自動バキュームを処理するためにより多くのシステムリソースを割り当てることを検討してください。
# RDS for PostgreSQL でバキュームのパフォーマンスに関する問題を解決する
このセクションでは、バキュームのパフォーマンスの低下を招く要因と、それらの問題に対処する方法について説明します。
**Topics**
+ [
## 大規模なインデックスのバキューム処理
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [
## バキューム処理対象のテーブルまたはデータベースが多すぎる
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [
## (循環を防ぐための) 積極的なバキューム処理が実行されている
](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## 大規模なインデックスのバキューム処理
VACUUM は、初期化、ヒープスキャン、インデックスとヒープバキューム、インデックスクリーンアップ、ヒープ切り捨て、最終クリーンアップのシーケンシャルフェーズで動作します。ヒープスキャン中、プロセスはページを除外し、デフラグしてフリーズします。ヒープスキャンが完了すると、VACUUM はインデックスをクリーンアップし、空のページがオペレーティングシステムに返されて、空き領域マップのバキューム処理や統計の更新などの最終的なクリーンアップタスクを実行します。
`maintenance_work_mem` (または `autovacuum_work_mem`) がインデックスの処理に不十分な場合は、インデックスのバキューム処理に複数のパスが必要になることがあります。PostgreSQL 16 以前では、デッドタプル ID を保存するために 1 GB のメモリ制限があり、大きなインデックスでは、多くの場合複数のパスが必要となっていました。PostgreSQL 17 では、単一の割り当て配列を使用する代わりにメモリを動的に割り当てる `TidStore` が導入されています。これにより、1 GB の制約がなくなり、メモリをより効率的に使用でき、インデックスごとに複数のインデックススキャンを行う必要が軽減されます。
使用可能なメモリがインデックス処理全体を一度に処理できない場合、大きなインデックスには PostgreSQL 17 で複数のパスが必要になることがあります。通常、大きなインデックスには、複数のパスを必要とするデッドタプルが多く含まれます。
**低速バキュームオペレーションの検出**
`postgres_get_av_diag()` 関数は、メモリ不足が原因でバキューム操作の実行が遅いタイミングを検出できます。この関数の詳細については、「[RDS for PostgreSQL に自動バキュームのモニタリングツールと診断ツールをインストールする](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)」を参照してください。
この `postgres_get_av_diag()` 関数は、使用可能なメモリが 1 回のパスでインデックスのバキューム処理を完了するのに十分でない場合、次の通知を発行します。
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**注記**
`postgres_get_av_diag()` 関数では、`pg_stat_all_tables.n_dead_tup` を使用してインデックスのバキューム処理に必要なメモリ量を推定します。
`postgres_get_av_diag()` 関数が、`autovacuum_work_mem` が不十分なために複数のインデックススキャンを必要とするスローバキュームオペレーションを特定すると、次のメッセージが生成されます。
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**ガイダンス**
手動 `VACUUM FREEZE` を使用して次の回避策を適用し、テーブルのフリーズにかかる時間を短縮できます。
**バキューム処理のためのメモリを増やす**
`postgres_get_av_diag()` 関数で提案されているように、インスタンスレベルで潜在的なメモリの制約に対応するために、`autovacuum_work_mem` パラメータを増やすことをお勧めします。`autovacuum_work_mem` は動的パラメータですが、新しいメモリ設定を有効にするには、自動バキュームデーモンがワーカーを再起動する必要があることに注意してください。これを行うには、以下の手順を使用します。
1. 新しい設定が指定されていることを確認します。
1. 自動バキュームを現在実行しているプロセスを終了します。
このアプローチにより、調整されたメモリ割り当てが新しい自動バキューム操作に適用されます。
より迅速な結果を得るには、セッション内で `maintenance_work_mem` 設定を増やし、手動で `VACUUM FREEZE` 操作を実行することを検討してください。
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Amazon RDS を使用していて、`maintenance_work_mem` または `autovacuum_work_mem` のより高い値をサポートするために追加のメモリが必要であると判断した場合は、より多くのメモリを持つインスタンスクラスにアップグレードすることを検討してください。これにより、手動バキューム操作と自動バキューム操作の両方を強化するために必要なリソースが提供され、バキューム処理とデータベースの全体的なパフォーマンスが向上します。
**INDEX\$1CLEANUP を無効にする**
PostgreSQL バージョン 12 以降の手動 `VACUUM` ではインデックスのクリーンアップフェーズを省略できますが、PostgreSQL バージョン 14 以降の緊急自動バキュームでは、[https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE) パラメータに基づいてこのフェーズが自動的に行われます。
**警告**
インデックスのクリーンアップを省略すると、インデックスが肥大化し、クエリのパフォーマンスに悪影響を及ぼす可能性があります。これを軽減するには、メンテナンスウィンドウで、影響を受けるインデックスに対してインデックスの再作成またはバキューム処理を行うことを検討してください。
大きなインデックスの処理に関するその他のガイダンスについては、「[大きなインデックスを使った autovacuum の管理](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)」のドキュメントを参照してください。
**インデックスの並列バキューム処理**
PostgreSQL 13 以降では、手動 `VACUUM` を使用して、各インデックスに 1 つのバキュームワーカープロセスを割り当て、デフォルトで複数のインデックスのバキューム処理とクリーンアップを並列して行うことができます。ただし、バキューム操作が並列実行の対象となるかどうかを PostgreSQL が判断するには、特定の基準を満たす必要があります。
+ 少なくとも 2 つのインデックスが必要です。
+ `max_parallel_maintenance_workers` パラメータを 2 以上に設定する必要があります。
+ インデックスサイズが `min_parallel_index_scan_size` の制限 (デフォルトは 512KB) を超えている必要があります。
Amazon RDS インスタンスで使用可能な vCPU の数とテーブルのインデックスの数に基づいて `max_parallel_maintenance_workers` 設定を調整し、バキューム処理のターンアラウンド時間を最適化できます。
詳細については、「[Parallel vacuuming in Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/)」を参照してください。
## バキューム処理対象のテーブルまたはデータベースが多すぎる
PostgreSQL の「[The Autovacuum Daemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM')」ドキュメントで説明されているように、自動バキュームデーモンは複数のプロセスで動作します。このプロセスには、システム内の各データベースの自動バキュームワーカープロセスを開始する、永続的な自動バキュームランチャーが含まれます。ランチャーは、データベースあたり約 `autovacuum_naptime` 秒ごとにこれらのワーカーを開始するようにスケジュールします。
N 個のデータベースでは、新しいワーカーはおおよそ [`autovacuum_naptime`/N 秒] ごとに開始されます。ただし、同時ワーカーの合計数は `autovacuum_max_workers` 設定によって制限されます。バキューム処理を必要とするデータベースまたはテーブルの数がこの制限を超えると、ワーカーが利用可能になり次第すぐに次のデータベースまたはテーブルが処理されます。
多数の大きなテーブルやデータベースで同時にバキューム処理が必要な場合、使用可能なすべての自動バキュームワーカーが長時間占有され、他のテーブルやデータベースのメンテナンスに遅延が生じる可能性があります。トランザクションレートが高い環境では、このボトルネックがすぐに増大し、Amazon RDS インスタンス内で循環バキュームの問題が発生する可能性があります。
`postgres_get_av_diag()` が多数のテーブルまたはデータベースを検出すると、次の推奨事項が提示されます。
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**ガイダンス**
**autovacuum\$1max\$1workers を増やす**
バキューム処理を迅速化するために、`autovacuum_max_workers` パラメータを調整して同時実行の自動バキュームワーカーを増やすことをお勧めします。パフォーマンスのボトルネックが続く場合は、Amazon RDS インスタンスをより多くの vCPU を持つクラスにスケールアップすることを検討してください。これにより、並列処理機能をさらに向上させることができます。
## (循環を防ぐための) 積極的なバキューム処理が実行されている
PostgreSQL のデータベースの経過時間 (MaximumUsedTransactionIDs) は、(循環を防ぐための) 積極的なバキューム処理が正常に完了した場合にのみ減少します。このバキューム処理が終了するまで、トランザクションレートに応じて経過時間は増加し続けます。
`postgres_get_av_diag()` 関数が積極的なバキュームを検出すると、次の `NOTICE` を生成します。ただし、この出力は、バキュームが少なくとも 2 分間アクティブになった後にのみトリガーされます。
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
積極的なバキュームの詳細については、「[When an aggressive vacuum is already running](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)」を参照してください。
次のクエリを使用して、積極的なバキュームが進行中かどうかを確認できます。
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
出力の query 列をチェックすることで、(循環を防ぐための) 積極的なバキュームであるかどうかを判断できます。「to prevent wraparound」という語句は、それが積極的なバキュームであることを示しています。
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
例えば、トランザクション経過時間が 10 億の時点でブロック要因があり、同じトランザクション経過時間での循環を防ぐために積極的なバキューム処理を必要とするテーブルがあるとします。さらに、トランザクション経過時間が 7 億 5,000 万の時点で別のブロック要因もあります。トランザクション経過時間 10 億でのブロック要因をクリアしても、トランザクション経過時間はすぐに 7 億 5,000 万には低下しません。積極的なバキューム処理を必要とするテーブル、または経過時間が 7 億 5,000 万を超えるトランザクションが完了するまで、高いままとなります。この間、PostgreSQL クラスターのトランザクション経過時間は増加し続けます。バキューム処理が完了すると、トランザクションの経過時間は 7 億 5,000 万に低下しますが、さらにバキューム処理が完了するまで再び増加し始めます。このサイクルは、最終的にトランザクション経過時間が `autovacuum_freeze_max_age` で指定された Amazon RDS インスタンスの設定レベルに低下するまで、これらの条件が存続する限り続きます。
# RDS for PostgreSQL の NOTICE メッセージの説明
`postgres_get_av_diag()` 関数は、次の NOTICE メッセージを提供します。
**経過時間がまだモニタリングしきい値に達していない場合**
ブロック要因を識別するための `postgres_get_av_diag()` のモニタリングしきい値は、デフォルトで 5 億トランザクションです。`postgres_get_av_diag()` で次の NOTICE が生成された場合は、トランザクション経過時間がまだこのしきい値に達していないことを示します。
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**トランザクション ID の経過時間が最も古いデータベースに接続していない**
`postgres_get_av_diag()` 関数は、トランザクション ID の経過時間が最も古いデータベースに接続したときに、最も正確な出力を提供します。`postgres_get_av_diag()` によって報告されたトランザクション ID の経過時間が最も古いデータベースが、「my\$1database」とは異なる場合があります。正しいデータベースに接続していない場合、次の NOTICE が生成されます。
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
トランザクション経過時間が最も古いデータベースに接続することは、次の理由で重要です。
+ **一時テーブルのブロック要因の識別:** 一時テーブルのメタデータは各データベースに固有のため、通常、一時テーブルは作成されたデータベースにあります。ただし、一時テーブルが上位のブロック要因となり、最も古いトランザクションを持つデータベースに存在する状況では、誤解が生じる可能性があります。適切なデータベースに接続することで、一時テーブルのブロック要因を正確に識別できます。
+ **遅いバキュームの診断:** インデックスメタデータとテーブル数の情報はデータベース固有であり、バキュームが遅い問題の診断に必要です。
**トランザクションの経過時間が最も古いデータベースが、rdsadmin または template0 データベースにある**
場合によっては、`rdsadmin` または `template0` データベースが、トランザクション ID の経過時間が最も古いデータベースとして識別される場合があります。このような場合、`postgres_get_av_diag()` で次の NOTICE が発行されます。
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
リストされたブロック要因がこれら 2 つのデータベースのいずれからも発生していないことを確認します。ブロック要因が `rdsadmin` または `template0` のいずれかに存在すると報告された場合は、サポートに問い合わせてください。ユーザーはこれらのデータベースにはアクセスできず、サポートが必要です。
`rdsadmin` と `template0` データベースのいずれかに上位のブロック要因が含まれている可能性はほとんどありません。
**積極的なバキュームがすでに実行されている場合**
`postgres_get_av_diag()` 関数は、積極的なバキューム処理が実行されているときに報告を行うように設計されていますが、この出力はバキュームが少なくとも 1 分間アクティブになった後にのみトリガーされます。この意図的な遅延によって、誤検出の可能性が低くなります。待機することで、有効で重要なバキュームのみが報告され、バキュームアクティビティのより正確で信頼性の高いモニタリングが可能になります。
`postgres_get_av_diag()` 関数は、進行中の 1 つ以上の積極的なバキュームを検出すると、次の NOTICE を生成します。
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
NOTICE に示されているように、バキュームのパフォーマンスを引き続きモニタリングします。積極的なバキュームの詳細については、「[(循環を防ぐための) 積極的なバキューム処理が実行されている](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)」を参照してください。
**自動バキュームがオフの場合**
データベースインスタンスで自動バキュームが無効になっている場合、`postgres_get_av_diag()` 関数は次の NOTICE を生成します。
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
自動バキュームは、RDS for PostgreSQL DB インスタンスの重要な機能であり、スムーズなデータベース操作を実現します。古い行バージョンを自動的に削除し、ストレージ領域を再利用して、テーブルの肥大化を防止することで、テーブルとインデックスの効率が維持され、パフォーマンスが最適化されます。さらに、Amazon RDS インスタンスのトランザクションを停止する可能性のある、トランザクション ID の循環も防止します。自動バキュームを無効にすると、データベースのパフォーマンスと安定性が長期的に低下する可能性があるため、常に有効にしておくことをお勧めします。詳細については、「[Understanding autovacuum in RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/)」を参照してください。
自動バキュームをオフにしても、積極的なバキュームは停止しません。積極的なバキュームは、テーブルが `autovacuum_freeze_max_age` しきい値に達すると実行されます。
**残っているトランザクションの数が非常に少ない**
`postgres_get_av_diag()` 関数は、循環バキュームが差し迫った場合に次の NOTICE を生成します。この NOTICE は、Amazon RDS インスタンスが新しいトランザクションを拒否するまであと 1 億トランザクションに差し迫った場合に発行されます。
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
データベースのダウンタイムを回避するために、直ちにアクションが必要です。バキューム操作を注意深くモニタリングし、トランザクションの失敗を防ぐために、影響を受けるデータベースで `VACUUM FREEZE` を手動で開始することを検討する必要があります。
# Amazon RDS for PostgreSQL での高いオブジェクト数の管理
PostgreSQL の制限は理論上のものですが、データベース内のオブジェクト数が非常に多いと、さまざまなオペレーションにおいてパフォーマンスに顕著な影響が及びます。このドキュメントでは、合計数が多い場合にさまざまな影響を及ぼす可能性のある、いくつかの一般的なオブジェクトタイプについて説明します。
次の表は、オブジェクトタイプとその潜在的な影響の概要を示しています。
**オブジェクトタイプと潜在的な影響**
| オブジェクトのタイプ | autovacuum | 論理レプリケーション | メジャーバージョンアップグレード | pg\$1dump / pg\$1restore | 全般的なパフォーマンス | インスタンスの再起動 |
| --- | --- | --- | --- | --- | --- | --- |
| [リレーション](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [一時テーブル](#PostgreSQL.HighObjectCount.TempTables)。 | x | | | | x | |
| [ログに記録されないテーブル](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [パーティション](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [一時ファイル](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [シーケンス](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [ラージオブジェクト](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## リレーション
PostgreSQL データベース内のテーブル数に特定のハード制限はありません。理論上の制限は非常に高いですが、データベース設計時に留意する必要がある実用的な制限が他にもあります。
**影響: autovacuum が遅れる**
autovacuum は、作業量と比較してワーカーが不足しているため、トランザクション ID の増加やテーブルの肥大化に対応しきれない可能性があります。
**推奨されるアクション:** autovacuum をチューニングして、特定の数のテーブルと特定のワークロードに適切に対応させるには、いくつかの要素を考慮する必要があります。適切な autovacuum 設定を決定する方法については、「[PostgreSQL autovacuum を使用するためのベストプラクティス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)」を参照してください。[postgres\$1get\$1av\$1diag ユーティリティ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html)を使用して、トランザクション ID の増加に関する問題をモニタリングします。
**影響: メジャーバージョンのアップグレード/pg\$1dump と復元**
Amazon RDS は、pg\$1upgrade の実行中に「--link」オプションを使用して、データファイルのコピーを作成する必要がないようにしますが、スキーマメタデータは新しいバージョンのデータベースに復元する必要があります。並列 pg\$1restore を使用しても、リレーションの数が多いとダウンタイムが増加します。
**影響: 一般的なパフォーマンスの低下**
カタログサイズによる一般的なパフォーマンスの低下。各テーブルとそれに関連する列は、`pg_attribute`、`pg_class`、および通常のデータベースオペレーションで頻繁に使用される `pg_depend` テーブルに追加されます。特定の待機イベントは表示されませんが、共有バッファの効率に影響します。
**推奨されるアクション:** これらの特定のテーブルに対してテーブルの肥大化を定期的にチェックし、必要に応じてこれらの特定のテーブルに `VACUUM FULL` を実行します。カタログテーブルの `VACUUM FULL` では `ACCESS EXCLUSIVE` ロックが必要です。これは、オペレーションが完了するまで他のクエリがそれらにアクセスできないことを意味します。
**影響: ファイル記述子の枯渇**
エラー: 「ファイル記述子不足: システムで開いているファイルが多すぎます。ファイルを解放して再試行してください」。PostgreSQL のパラメータ `max_files_per_process` は、各プロセスが開くことができるファイルの数を決定します。多数のテーブルを結合する接続の数が多い場合、この制限に達する可能性があります。
**推奨されるアクション:**
+ パラメータ `max_files_per_process` の値を下げると、このエラーを軽減できる可能性があります。各プロセスとサブプロセス (並列クエリなど) は、この数のファイルを開くことができ、クエリが複数のテーブルを結合している場合は、この制限を超える可能性があります。
+ 接続の総数を減らし、[Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) などの接続プーラー、または PgBouncer などの他のソリューションを使用します。詳細については、[PGBouncer](https://www.pgbouncer.org/) のウェブサイトを参照してください。
**影響: Inode の枯渇**
エラー: 「デバイスに空き容量がありません」。ストレージの空き領域が大量にある場合にこれが観察された場合は、inode が不足していることが原因です。[Amazon RDS 拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)は、使用中の inode とホストで使用できる最大数を可視化します。
**概算しきい値:** [数百万](#PostgreSQL.HighObjectCount.Note)
## 一時テーブル
一時テーブルの使用は、テストデータまたは中間結果に役立ち、多くのデータベースエンジンで見られる一般的なパターンです。PostgreSQL での大量使用の影響を理解して、いくつかの落とし穴を回避する必要があります。一時テーブルの作成と削除ごとに、システムカタログテーブルに行が追加され、肥大化すると、一般的なパフォーマンスの問題が発生します。
**影響: autovacuum が遅れる**
一時テーブルは autovacuum によってバキューム処理されませんが、存在中はトランザクション ID を保持し、削除しないと循環が発生する可能性があります。
**推奨されるアクション:** 一時テーブルは、それらを作成したセッション期間中存続するか、手動で削除できます。ベストプラクティスとして、一時テーブルを使用する際に長時間実行されるトランザクションを避けることで、これらのテーブルが使用済みトランザクション ID の最大値の増加に寄与するのを防ぐことができます。
**影響: 一般的なパフォーマンスの低下**
カタログサイズによる一般的なパフォーマンスの低下。セッションが継続的に一時テーブルを作成および削除すると、通常のデータベースオペレーションで頻繁に使用される `pg_attribute`、`pg_class`、`pg_depend` テーブルにテーブルが追加されます。特定の待機イベントは表示されませんが、共有バッファの効率に影響します。
**推奨されるアクション:**
+ これらの特定のテーブルに対してテーブルの肥大化を定期的にチェックし、必要に応じてこれらの特定のテーブルに `VACUUM FULL` を実行します。カタログテーブルの `VACUUM FULL` では `ACCESS EXCLUSIVE` ロックが必要です。これは、オペレーションが完了するまで他のクエリがそれらにアクセスできないことを意味します。
+ 一時テーブルが頻繁に使用される場合は、メジャーバージョンアップグレードの前に、ダウンタイムを短縮するために、これらの特定のカタログテーブルの `VACUUM FULL` を強くお勧めします。
**一般的なベストプラクティス:**
+ 共通テーブル式を使用して中間結果を生成することで、一時テーブルの使用を減らします。これらは、必要なクエリを複雑にすることがありますが、上記の影響を排除できます。
+ `TRUNCATE` コマンドを使用して一時テーブルを再利用し、ドロップ/作成ステップを実行する代わりに内容をクリアします。これにより、一時テーブルによるトランザクション ID の増加の問題も排除されます。
**概算しきい値:** [数万](#PostgreSQL.HighObjectCount.Note)
## ログに記録されないテーブル
ログに記録されないテーブルは、WAL 情報を生成しないため、パフォーマンスを向上させることができます。これらはデータベースのクラッシュ回復中に切り捨てられるため、耐久性がなく、慎重に使用する必要があります。これは PostgreSQL ではコストの高いオペレーションであり、ログに記録されていない各テーブルは順次切り捨てられます。このオペレーションはログに記録されないテーブルの数が少ない場合は高速ですが、数千のテーブルの数になると、起動中に顕著な遅延が発生し始める可能性があります。
**影響: 論理レプリケーション**
論理レプリケーションでは WAL を利用して変更をキャプチャおよび転送するため、ログに記録されないテーブルは通常、[ブルー/グリーンデプロイ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)を含む論理レプリケーションに含まれません。
**影響: 復旧中のダウンタイムが長引く**
フェイルオーバーによるマルチ AZ 再起動、Amazon RDS ポイントインタイムリカバリ、Amazon RDS メジャーバージョンアップグレードなどのデータベースのクラッシュ回復を含むデータベース状態においては、ログに記録されないテーブルを切り捨てるシリアル化されたオペレーションが発生します。これにより、予想よりもはるかに高いダウンタイムが発生する可能性があります。
**推奨されるアクション:**
+ ログに記録されないテーブルの使用は、データベースのクラッシュ回復オペレーション中に失われても許容できるデータのみに限定するようにしてください。
+ シリアル切り捨ての現在の動作により、データベースの起動にかなりの時間がかかる可能性があるため、ログに記録されないテーブルの使用は最小限に抑えてください。
**一般的なベストプラクティス:**
+ ログに記録されないテーブルはクラッシュ時に安全性が確保されません。クラッシュ回復を伴うポイントインタイムリカバリの開始は、各テーブルを切り捨てるシリアルプロセスであるため、PostgreSQL ではかなりの時間がかかります。
**概算しきい値:** [数千](#PostgreSQL.HighObjectCount.Note)
## パーティション
パーティション分割により、クエリのパフォーマンスが向上し、データの論理的な整理が可能になります。理想的なシナリオでは、パーティション分割は、クエリの計画と実行時にパーティションプルーニングを使用できるように構成されます。パーティションが多すぎると、クエリのパフォーマンスとデータベースのメンテナンスに悪影響を及ぼす可能性があります。クエリの計画と実行のパフォーマンスは、不十分な設計によって悪影響を受ける可能性があるため、テーブルを分割する方法の選択は慎重に行う必要があります。パーティション分割の詳細については、[PostgreSQL のドキュメント](https://www.postgresql.org/docs/current/ddl-partitioning.html)を参照してください。
**影響: 一般的なパフォーマンスの低下**
場合によっては、計画時間のオーバーヘッドが増加し、クエリの実行計画がより複雑になり、チューニングの機会を特定することが難しくなる場合があります。18 より前の PostgreSQL バージョンでは、ワークロードの高いパーティションが多いと、`LWLock:LockManager` 待機につながる可能性があります。
**推奨されるアクション:** データの整理を完了させると同時に、クエリの実行パフォーマンスも向上させるために必要な最小限のパーティション数を決定します。
**影響: メンテナンスの複雑さ**
パーティションの数が非常に多いと、事前作成や削除などのメンテナンスの問題が発生します。autovacuum はパーティションを通常のリレーションとして扱い、定期的なクリーンアップを実行する必要があるため、タスクを完了するのに十分なワーカーが必要です。
**推奨されるアクション:**
+ 新しいパーティションが必要になったとき (月単位のパーティションなど) や古いパーティションがロールオフされたときにワークロードがブロックされないように、パーティションを事前に作成してください。
+ すべてのパーティションの通常のクリーンアップメンテナンスを実行するのに十分な autovacuum ワーカーがあることを確認します。
**概算しきい値:** [数百](#PostgreSQL.HighObjectCount.Note)
## 一時ファイル
上記の一時テーブルとは異なり、一時ファイルは、複雑なクエリが複数のソート操作またはハッシュ操作を同時に実行する可能性がある場合に PostgreSQL によって作成されます。各オペレーションは、インスタンスメモリを使用して `work_mem` パラメータで指定された値までの結果を保存します。インスタンスメモリが不足すると、結果を保存する一時ファイルが作成されます。一時ファイルの詳細については、「[一時ファイルの管理](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html)」を参照してください。ワークロードがこれらのファイルを大量に生成する場合、いくつかの影響が生じる可能性があります。
**影響: ファイル記述子の枯渇**
エラー: 「ファイル記述子不足: システムで開いているファイルが多すぎます。ファイルを解放して再試行してください」。PostgreSQL のパラメータ `max_files_per_process` は、各プロセスが開くことができるファイルの数を決定します。多数のテーブルを結合する接続の数が多い場合、この制限に達する可能性があります。
**推奨されるアクション:**
+ パラメータ `max_files_per_process` の値を下げると、このエラーを軽減できる可能性があります。各プロセスとサブプロセス (並列クエリなど) は、この数のファイルを開くことができ、クエリが複数のテーブルを結合している場合は、この制限を超える可能性があります。
+ 接続の総数を減らし、[Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) などの接続プーラーや PgBouncer などの他のソリューションを使用します。詳細については、[PGBouncer](https://www.pgbouncer.org/) のウェブサイトを参照してください。
**影響: Inode の枯渇**
エラー: 「デバイスに空き容量がありません」。ストレージの空き領域が大量にある場合にこれが観察された場合は、inode が不足していることが原因です。[Amazon RDS 拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)は、使用中の inode とホストで使用できる最大数を可視化します。
**一般的なベストプラクティス:**
+ [Performance Insights](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) を使用して一時ファイルの使用状況をモニタリングします。
+ 大量の一時ファイルを生成しているクエリを調整して、一時ファイルの合計数を減らすことができるかどうかを確認します。
**概算しきい値:** [数千](#PostgreSQL.HighObjectCount.Note)
## シーケンス
シーケンスは、PostgreSQL の列の自動増分に使用される基盤となるオブジェクトであり、データの一意性とキーを提供します。これらは、論理レプリケーションを 1 つ例外として、通常のオペレーション中に特に影響を与えることなく、個々のテーブルで使用できます。
PostgreSQL では、論理レプリケーションは現在、シーケンスの現在の値をサブスクライバーにレプリケートしません。詳細については、[PostgreSQL のドキュメントの制約事項ページ](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)を参照してください。
**影響: スイッチオーバー時間の延長**
任意のタイプの設定変更またはアップグレードに、[Amazon RDS ブルー/グリーンデプロイ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)を使用する予定がある場合は、多数のシーケンスがスイッチオーバーに与える影響を理解することが重要です。スイッチオーバーの最後のフェーズの 1 つとして、シーケンスの現在の値を同期させる処理が行われますが、その数が数千に及ぶ場合、スイッチオーバー全体の所要時間が長くなります。
**推奨されるアクション:** データベースワークロードがテーブルごとのシーケンスアプローチではなく共有 UUID の使用を許可する場合、スイッチオーバー中に同期ステップを削減できます。
**概算しきい値:** [数千](#PostgreSQL.HighObjectCount.Note)
## ラージオブジェクト
ラージオブジェクトは pg\$1largeobject という名前の単一のシステムテーブルに保存されます。各ラージオブジェクトには、システムテーブル pg\$1largeobject\$1metadata にもエントリがあります。これらのオブジェクトは、標準リレーションとは大幅に異なる方法で作成、変更、クリーンアップされます。ラージオブジェクトは autovacuum では処理されないため、vacuumlo と呼ばれる別のプロセスで定期的にクリーンアップする必要があります。ラージオブジェクトの管理の例については、「lo モジュールを使用したラージオブジェクトの管理」を参照してください。
**影響: 論理レプリケーション**
現在、PostgreSQL では論理レプリケーション時にラージオブジェクトはレプリケートされません。詳細については、[PostgreSQL のドキュメントの制約事項ページ](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)を参照してください。[ブルー/グリーン](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)設定では、ブルー環境内のラージオブジェクトはグリーン環境にレプリケートされません。
**影響: メジャーバージョンアップグレード**
数百万のラージオブジェクトがあり、アップグレード中にインスタンスがそれらを処理できない場合、アップグレードはメモリ不足になり、失敗する可能性があります。PostgreSQL メジャーバージョンのアップグレードプロセスは、大きく分けて 2 つのフェーズで構成されます。pg\$1dump によるスキーマダンプと、pg\$1restore による復元です。データベースに数百万のラージオブジェクトがある場合は、アップグレード中に pg\$1dump と pg\$1restore を処理するために十分なメモリがインスタンスにあることを確認し、より大きなインスタンスタイプにスケールする必要があります。
**一般的なベストプラクティス:**
+ vacuumlo ユーティリティを定期的に使用して、孤立したラージオブジェクトを削除します。
+ ラージオブジェクトをデータベースに保存する場合は、BYTEA データ型を使用することを検討してください。
**概算しきい値:** [数百万](#PostgreSQL.HighObjectCount.Note)
## 概算しきい値
このトピックで説明されている概算しきい値は、特定のリソースがスケールできる範囲を推定するためにのみ使用されます。これらは、説明されている影響が発生する可能性が高くなる一般的な範囲を示していますが、実際の動作は、特定のワークロード、インスタンスサイズ、および設定によって異なります。これらの予測を超える可能性はあるものの、記載されている影響を避けるためには、適切な管理とメンテナンスを遵守する必要があります。
# Amazon RDS for PostgreSQL での TOAST OID 競合の管理
TOAST (オーバーサイズ属性ストレージ技術) は、一般的な 8KB のデータベースブロックサイズを超える大きなデータ値を処理するように設計された PostgreSQL 機能です。PostgreSQL では、物理的な行が複数のブロックにまたがることは許可されません。ブロックサイズは、行サイズの上限として機能します。TOAST は、大きなフィールド値を小さなチャンクに分割することで、この制限を克服します。メインテーブルにリンクされた専用の TOAST テーブルに個別に保存されます。詳細については、「[PostgreSQL TOAST storage mechanism and implementation documentation](https://www.postgresql.org/docs/current/storage-toast.html)」を参照してください。
**Topics**
+ [
## TOAST オペレーションについて
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [
## パフォーマンスの課題を特定する
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [
## 推奨事項
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [
## モニタリング
](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## TOAST オペレーションについて
TOAST は圧縮を実行し、大きなフィールド値を行外に保存します。TOAST は、TOAST テーブルに保存されているオーバーサイズのデータの各チャンクに一意の OID (オブジェクト識別子) を割り当てます。メインテーブルは TOAST 値 ID とリレーション ID をページに保存し、TOAST テーブルの対応する行を参照します。これにより、PostgreSQL はこれらの TOAST チャンクを効率的に見つけて管理できます。ただし、TOAST テーブルが大きくなると、システムは使用可能な OID を使い果たすリスクがあり、OID の枯渇によりパフォーマンスが低下し、ダウンタイムが発生する可能性があります。
### TOAST のオブジェクト識別子
オブジェクト識別子 (OID) は、PostgreSQL がテーブル、インデックス、関数などのデータベースオブジェクトを参照するために使用するシステム全体の一意の識別子です。これらの識別子は PostgreSQL の内部オペレーションで重要な役割を果たし、データベースがオブジェクトを効率的に見つけて管理できるようにします。
トーストの対象となるデータセットを持つテーブルの場合、PostgreSQL は OID を割り当てて、関連付けられた TOAST テーブルに保存されているオーバーサイズデータの各チャンクを一意に識別します。システムは各チャンクを `chunk_id` に関連付けます。これにより、PostgreSQL はこれらのチャンクを TOAST テーブル内で効率的に整理して見つけることができます。
## パフォーマンスの課題を特定する
PostgreSQL の OID 管理は、グローバル 32 ビットカウンターに依存しているため、40 億の一意の値を生成した後は最初に戻ります。データベースクラスターがこのカウンターを共有する間、OID 割り当てには TOAST オペレーション中の 2 つのステップが含まれます。
+ **割り当てのグローバルカウンター** – グローバルカウンターは、クラスター全体に新しい OID を割り当てます。
+ **競合のローカル検索** – TOAST テーブルは、新しい OID がその特定のテーブルで既に使用されている既存の OID と競合しないようにします。
パフォーマンスの低下は、次の場合に発生する可能性があります。
+ TOAST テーブルはフラグメント化または密な OID 使用率が高く、OID の割り当てが遅れます。
+ データチャーンが高い環境や TOAST を多用する幅の広いテーブルがある環境では、システムは OID を頻繁に割り当てて再利用します。
詳細については、「[PostgreSQL TOAST table size limits and OID allocation documentation](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit)」を参照してください。
グローバルカウンターは OID を生成し、40 億個の値ごとに最初に戻るため、システムは時折、既に使用されている値を再生成します。PostgreSQL はそれを検出し、次の OID で再試行します。TOAST テーブル内で、使用済み OID 値が非常に長く連続し、ギャップがない場合、INSERT が遅くなる可能性があります。これらの課題は、OID スペースがいっぱいになるとより顕著になり、挿入と更新が遅くなります。
### 問題の特定
+ 単純な `INSERT` ステートメントは、一貫性のないランダムな方法で、通常よりも大幅に時間がかかります。
+ 遅延は、TOAST オペレーションを含む `INSERT` および `UPDATE` ステートメントに対してのみ発生します。
+ システムが TOAST テーブルで使用可能な OID を見つけられない場合、次のログエントリが PostgreSQL ログに表示されます。
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ Performance Insights は、`LWLock:buffer_io` および `LWLock:OidGenLock` 待機イベントに関連付けられた平均アクティブセッション (AAS) の数が多いことを示します。
次の SQL クエリを実行して、長時間実行される INSERT トランザクションを待機イベントで識別できます。
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
待機時間が長い INSERT オペレーションを表示するクエリ結果の例。
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### 問題の分離
+ **小さな挿入をテストする** – `toast_tuple_target` しきい値より小さいレコードを挿入します。TOAST ストレージの前に圧縮が適用されることに注意してください。これがパフォーマンスの問題なく動作する場合、問題は TOAST オペレーションに関連しています。
+ **新しいテーブルをテストする** – 同じ構造で新しいテーブルを作成し、`toast_tuple_target` より大きいレコードを挿入します。問題なく動作する場合、問題は元のテーブルの OID 割り当てに限定されます。
## 推奨事項
以下のアプローチは、TOAST OID 競合の問題を解決するのに役立ちます。
+ **データのクリーンアップとアーカイブ** – 廃止されたデータや不要なデータを確認して削除し、将来の使用のために OID を解放するか、データをアーカイブします。次の制限事項を考慮してください。
+ 将来のクリーンアップが常に可能とは限らないため、スケーラビリティが制限されます。
+ 長時間実行される VACUUM オペレーションで、生成されたデッドタプルを削除できます。
+ **新しいテーブルに書き込む** – 将来の挿入用に新しいテーブルを作成し、`UNION ALL` ビューを使用してクエリの古いデータと新しいデータを結合します。このビューは、古いテーブルと新しいテーブルの両方から組み合わされたデータを表示し、クエリが単一のテーブルとしてそれらにアクセスできるようにします。次の制限事項を考慮してください。
+ 古いテーブルを更新すると、OID が枯渇する可能性があります。
+ **パーティションまたはシャード** – テーブルまたはシャードデータをパーティション化して、スケーラビリティとパフォーマンスを向上させます。次の制限事項を考慮してください。
+ クエリロジックとメンテナンスの複雑さが増し、パーティション化されたデータを正しく処理するためにアプリケーションの変更が必要になる可能性があります。
## モニタリング
### システムテーブルの使用
PostgreSQL のシステムテーブルを使用して、OID 使用量の増加をモニタリングできます。
**警告**
TOAST テーブルの OID の数によっては、完了までに時間がかかる場合があります。影響を最小限に抑えるために、営業時間外にモニタリングをスケジュールすることをお勧めします。
次の匿名ブロックは、各 TOAST テーブルで使用される個別の OID の数をカウントし、親テーブル情報を表示します。
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
TOAST テーブル別に OID 使用状況統計を表示する出力例。
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
次の匿名ブロックは、空でない TOAST テーブルごとに割り当てられた最大 OID を取得します。
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
TOAST テーブルの最大チャンク ID を表示する出力例。
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Performance Insights の使用
待機イベント `LWLock:buffer_io` と `LWLock:OidGenLock` は、新しいオブジェクト識別子 (OID) の割り当てを必要とするオペレーション中に Performance Insights に表示されます。これらのイベントの高平均アクティブセッション (AAS) は、通常、OID の割り当てとリソース管理中に競合を示します。これは、データチャーンが高い環境、大規模なデータが頻繁に使用される、またはオブジェクトが頻繁に作成される環境で特に一般的です。
#### LWLock:buffer\$1io
`LWLock:buffer_io` は、PostgreSQL セッションが共有バッファの I/O オペレーションの完了を待機しているときに発生する待機イベントです。これは通常、データベースがディスクからメモリにデータを読み取り、変更されたページをメモリからディスクに書き込むときに発生します。`BufferIO` 待機イベントは、I/O オペレーションの進行中に複数のプロセスが同じバッファにアクセスまたは変更されないようにすることで、一貫性を確保します。この待機イベントの発生率が高い場合は、データベースワークロードのディスクのボトルネックまたは過剰な I/O アクティビティを示している可能性があります。
TOAST オペレーション中。
+ PostgreSQL は大きなオブジェクト OID を割り当て、TOAST テーブルのインデックスをスキャンしてその一意性を確保します。
+ 大きな TOAST インデックスでは、OID の一意性を検証するために複数のページにアクセスする必要がある場合があります。これにより、特にバッファプールが必要なすべてのページをキャッシュできない場合に、ディスク I/O が増加します。
インデックスのサイズは、これらのオペレーション中にアクセスする必要があるバッファページの数に直接影響します。インデックスが肥大化していない場合でも、特に高同時実行または高チャーン環境では、膨大なサイズによってバッファ I/O が増加する可能性があります。詳細については、「[LWLock:BufferIO 待機イベントのトラブルシューティングガイド](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html)」を参照してください。
#### Lwlock:OidGenLock
`OidGenLock` は、PostgreSQL セッションが新しいオブジェクト識別子 (OID) の割り当てを待機しているときに発生する待機イベントです。このロックにより、OID が順番に安全に生成され、一度に 1 つのプロセスのみが OID を生成できます。
TOAST オペレーション中。
+ **TOAST テーブルのチャンクの OID 割り当て** – PostgreSQL は、大きなデータレコードを管理するときに、TOAST テーブルのチャンクに OID を割り当てます。システムカタログの競合を防ぐために、各 OID は一意である必要があります。
+ **高い同時実行性** – OID ジェネレーターへのアクセスはシーケンシャルであるため、複数のセッションが同時に OID を必要とするオブジェクトを作成している場合、`OidGenLock` の競合が発生する可能性があります。これにより、OID 割り当てが完了するまでセッションが待機する可能性が高まります。
+ **システムカタログアクセスの依存関係** – OID を割り当てるには、`pg_class` や `pg_type` などの共有システムカタログテーブルを更新する必要があります。これらのテーブルで大量のアクティビティが発生した場合 (DDL オペレーションが頻繁に発生するため)、`OidGenLock` のロック競合が増加する可能性があります。
+ **高い OID 割り当ての需要** – 大量のデータレコードを持つ TOAST 負荷の高いワークロードには、一定の OID 割り当てが必要で、競合が増大します。
OID の競合を増やすその他の要因。
+ **頻繁なオブジェクトの作成** – 一時テーブルなどのオブジェクトを頻繁に作成および削除するワークロードは、グローバル OID カウンターでの競合を増幅します。
+ **グローバルカウンターロック** – グローバル OID カウンターは一意性を確保するために連続してアクセスされ、同時実行性の高い環境で単一の競合ポイントを作成します。
## RDS for PostgreSQL でサポートされているログ記録メカニズムの使用
いくつかのパラメータ、エクステンション、その他の設定可能な項目を設定して、PostgreSQL DB インスタンスで発生するアクティビティのログを作成できます。これには以下が含まれます。
+ `log_statement` パラメータは PostgreSQL データベースのユーザー操作のログを作成するのに使用できます。RDS for PostgreSQL のログ記録とログのモニタリング方法の詳細については、「[ RDS for PostgreSQL データベースログファイル](USER_LogAccess.Concepts.PostgreSQL.md)」を参照してください。
+ `rds.force_admin_logging_level` パラメータにより、DB インスタンス上のデータベースでの Amazon RDS 内部ユーザー (rdsadmin) によるアクションをログに記録されます。出力が PostgreSQL エラーログに書き込まれます。指定可能な値は、`disabled`、`debug5`、`debug4`、`debug3`、`debug2`、`debug1`、`info`、`notice`、`warning`、`error`、log、`fatal`、および `panic` です。デフォルト値は `disabled` です。
+ `rds.force_autovacuum_logging_level` パラメータを設定して、PostgreSQL エラーログにさまざまな自動バキュームオペレーションをキャプチャすることができます。詳細については、「[自動バキュームおよびバキュームアクティビティのログ記録](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)」を参照してください。
+ PostgreSQL Audit (pgAudit) 拡張は、セッションレベルまたはオブジェクトレベルでアクティビティをキャプチャするようにインストールおよび設定できます。詳細については、「[pgAudit を使用してデータベースのアクティビティを記録する](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)」を参照してください。
+ `log_fdw` 拡張を使用すると、SQL を使用してデータベースエンジンのログにアクセスすることができます。詳細については、「[SQL を使用した DB ログのアクセスのための log\$1fdw 拡張機能の使用](CHAP_PostgreSQL.Extensions.log_fdw.md)」を参照してください。
+ `pg_stat_statements` ライブラリは、PostgreSQL バージョン 10 以降の RDS で、`shared_preload_libraries` パラメータのデフォルトとして指定されています。実行中のクエリを分析するために使用できるのはこのライブラリです。DB パラメータグループで `pg_stat_statements` が設定されていることを確認してください。このライブラリが提供する情報を使用した RDS for PostgreSQL DB インスタンスのモニタリングの詳細については、「[RDS PostgreSQL での SQL 統計](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md)」を参照してください。
+ `log_hostname` パラメータは、各クライアント接続のホスト名をログに取り込みます。PostgreSQL バージョン 12 以降のバージョンの RDS では、このパラメータはデフォルトで `off` に設定されています。オンにする場合は、必ずセッション接続時間をモニタリングしてください。オンにすると、サービスはドメインネームシステム (DNS) 逆ルックアップリクエストを使用して接続しているクライアントのホスト名を取得し、PostgreSQL ログに追加します。これはセッション接続中に顕著な影響を及ぼします。このパラメータはトラブルシューティングの目的のみでオンにすることをお勧めします。
一般に、ログ記録のポイントは、DBA がモニタリング、パフォーマンスのチューニング、およびトラブルシューティングを実行できるようにすることです。ログの多くは、Amazon CloudWatch または Performance Insights に自動的にアップロードされます。ここでは、DB インスタンスの完全なメトリクスを提供するためにソートおよびグループ化されています。Amazon RDS のモニタリングとメトリクスの詳細については、「[Amazon RDS インスタンスでのメトリクスのモニタリング](CHAP_Monitoring.md)」を参照してください。
# PostgreSQL による一時ファイルの管理
PostgreSQL では、複雑なクエリが、インスタンスメモリを使用して [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) パラメータで指定された値までの結果を保存する、複数のソート操作またはハッシュ操作を同時に実行する場合があります。インスタンスメモリが不足すると、結果を保存する一時ファイルが作成されます。これらは、クエリの実行を完了するためにディスクに書き込まれます。その後、これらのファイルは、クエリが完了すると自動的に削除されます。RDS for PostgreSQL では、これらのファイルはデータボリュームの Amazon EBS に保存されます。詳細については、「[Amazon RDS DB インスタンスのストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」を参照してください。CloudWatch で提供される `FreeStorageSpace` メトリクスを常にモニタリングして、DB インスタンスのストレージに十分な空き容量があることを確認できます。詳細については、「[https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm)」を参照してください。
複数のクエリが同時に実行され、一時ファイルの使用量が増えるワークロードには、Amazon RDS Optimized Read インスタンスを使用することをお勧めします。これらのインスタンスがローカルの不揮発性メモリエクスプレス (NVMe) ベースのソリッドステートドライブ (SSD) ブロックレベルストレージを使用することで、一時ファイルを配置します。詳細については、「[Amazon RDS Optimized Reads による RDS for PostgreSQL のクエリパフォーマンスの向上](USER_PostgreSQL.optimizedreads.md)」を参照してください。
以下のパラメータと関数を使用して、インスタンスの一時ファイルを管理することができます。
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** — このパラメータは、temp\$1files のサイズ (KB 単位) を超えるクエリをすべてキャンセルします。この制限により、クエリが延々と実行され、一時ファイルでディスクスペースが消費されるのを防ぐことができます。`log_temp_files` パラメータの結果を使用して値を推定できます。ベストプラクティスとして、ワークロードの動作を調べ、推定値に従って制限を設定してください。次の例は、クエリが制限を超えた場合にキャンセルされる様子を示しています。
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** — このパラメータは、セッションの一時ファイルが削除されたときに postgresql.log にメッセージを送信します。このパラメータは、クエリが正常に完了した後にログを生成します。そのため、アクティブで長時間実行されるクエリのトラブルシューティングには役立たない可能性があります。
次の例は、クエリが正常に完了すると、エントリが postgresql.log ファイルに記録され、一時ファイルがクリーンアップされることを示しています。
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** — この関数は RDS for PostgreSQL 13 以降で使用でき、現在の一時ファイルの使用状況を可視化できます。完了したクエリは、関数の結果には表示されません。次の例では、この関数の結果を表示できます。
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
ファイル名には、一時ファイルを生成したセッションの処理 ID (PID) が含まれます。次の例のような、より高度なクエリでは、各 PID の一時ファイルの合計が実行されます。
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** — pg\$1stat\$1statements パラメータを有効にすると、呼び出しごとの一時ファイルの平均使用量を表示できます。次の例に示すように、クエリの query\$1id を特定し、それを使用して一時ファイルの使用状況を調べることができます。
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** — Performance Insights ダッシュボードで、**temp\$1bytes** と **temp\$1files** のメトリクスをオンにすると、一時ファイルの使用状況を確認できます。次に、これら両方のメトリクスの平均と、それらがクエリワークロードにどのように対応しているかを確認できます。Performance Insights 内のビューには、一時ファイルを生成しているクエリが具体的に表示されません。ただし、Performance Insights と `pg_ls_tmpdir` に示されるクエリを組み合わせると、クエリワークロードの変化をトラブルシューティング、分析、判断できます。
Performance Insights を使用してメトリクスとクエリを分析する方法については、「[Performance Insights ダッシュボードを使用してメトリクスを分析する](USER_PerfInsights.UsingDashboard.md)」を参照してください。
Performance Insights で一時ファイルの使用状況を表示する例については、「[Performance Insights を使用した一時ファイルの使用状況の確認](PostgreSQL.ManagingTempFiles.Example.md)」を参照してください。
# Performance Insights を使用した一時ファイルの使用状況の確認
Performance Insights で、**temp\$1bytes** と **temp\$1files** のメトリクスをオンにすると、一時ファイルの使用状況を確認できます。Performance Insights のビューには、一時ファイルを生成する特定のクエリは表示されませんが、Performance Insights を `pg_ls_tmpdir` に示されているクエリと組み合わせると、クエリワークロードの変更をトラブルシューティング、分析、判断できます。
1. Performance Insights ダッシュボードで、**[メトリクスを管理]** を選択します。
1. 次の画像に示すように、**[データベースメトリクス]** を選択して、**[temp\$1bytes]** と **[temp\$1files]** を選択します。
![\[メトリクスがグラフに表示されます。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. **[トップ SQL]** タブで、**[設定]** アイコンを選択します。
1. **[設定]** ウィンドウで、**[トップ SQL]** タブに以下の統計が表示されるようにして、**[続行]** を選択します。
+ Temp writes/sec
+ Temp reads/sec
+ Tmp blk write/call
+ Tmp blk read/call
1. 次の例に示すように、`pg_ls_tmpdir` で示したクエリと組み合わせると、この一時ファイルが抜き出されます。
![\[一時ファイルの使用状況を表示するクエリ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
`IO:BufFileRead` と `IO:BufFileWrite` イベントは、ワークロードの上位クエリが一時ファイルを頻繁に作成するときに発生します。Performance Insights を使用することで、「データベース負荷」と「上位 SQL」セクションの「平均アクティブセッション (AAS)」を参照して、`IO:BufFileRead` と `IO:BufFileWrite` を待機中の上位クエリの特定が可能になります。
![\[グラフの IO:BufFileRead および IO:BufFileWrite。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Performance Insights を使用して上位クエリを分析して、待機イベント別にロードする方法については、「[[トップ SQL] タブの概要](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL)」を参照してください テンポラリファイルの使用量と関連する待機イベントの増加の原因となるクエリを特定し、調整する必要があります。これらの待機イベントと修復方法の詳細については、「[IO:BufFileRead および IO:BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html)」「」を参照してください。
**注記**
[https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) パラメータは、ソート操作がメモリ不足になり、結果が一時ファイルに書き込まれるタイミングを制御します。このパラメータの設定をデフォルト値より高く変更しないことをお勧めします。変更すると、すべてのデータベースセッションでより多くのメモリを消費することになります。また、複雑な結合とソートを実行する単一セッションでは、それぞれの処理がメモリを消費する並列処理を実行できます。
ベストプラクティスとして、複数の結合とソートを含む大規模なレポートがある場合は、`SET work_mem` コマンドを使用してこのパラメータをセッションレベルで設定します。そうすれば、変更は現在のセッションにのみ適用され、値がグローバルに変更されることはありません。
## pgBadger を使用した PostgreSQL でのログ分析
[pgBadger](http://dalibo.github.io/pgbadger/) などのログ分析ツールを使用して、PostgreSQL のログを分析できます。pgBadger のドキュメントでは %l パターン (セッションやプロセスに関するログの行) をプレフィックスに含める必要があると説明されています。ただし、最新の RDS `log_line_prefix` をパラメータとして pgBadger に渡すことでも、レポートが作成されます。
例えば、次のコマンドでは、pgBadger を使用して、2014-02-04 の日付の Amazon RDS for PostgreSQL のログファイルを適切にフォーマットします。
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## PostgreSQL をモニタリングするために PGSnapper を使用する
PGSnapper を使用すると、Amazon RDS for PostgreSQL のパフォーマンス関連の統計やメトリクスを定期的に収集することができます。詳細については、「[PGSnapper を使用して Amazon RDS for PostgreSQL のパフォーマンスをモニタリングする](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/)」を参照してください。
# RDS for PostgreSQL でのカスタムキャストの管理
PostgreSQL での**型キャスト**は、あるデータ型から別のデータ型に値を変換するプロセスです。PostgreSQL には多くの一般的な変換用の組み込みキャストがありますが、カスタムキャストを作成して、特定の型変換の動作を定義することもできます。
キャストは、あるデータ型から別のデータ型への変換を実行する方法を指定します。例えば、テキスト `'123'` を整数 `123` に変換したり、数値 `45.67` をテキスト `'45.67'` に変換したりします。
PostgreSQL のキャストの概念と構文に関する包括的な情報については、「[PostgreSQL CREATE CAST のドキュメント](https://www.postgresql.org/docs/current/sql-createcast.html)」を参照してください。
RDS for PostgreSQL バージョン 13.23、14.20、15.15、16.11、17.7、および 18.1 以降では、rds\$1casts 拡張機能を使用して組み込みタイプの追加のキャストをインストールできるだけでなく、カスタムタイプの独自のキャストを作成することもできます。
**Topics**
+ [
## rds\$1casts 拡張機能のインストールと使用
](#PostgreSQL.CustomCasts.Installing)
+ [
## サポートされているキャスト
](#PostgreSQL.CustomCasts.Supported)
+ [
## キャストの作成または削除
](#PostgreSQL.CustomCasts.Creating)
+ [
## 適切なコンテキスト戦略を使用してカスタムキャストを作成する
](#PostgreSQL.CustomCasts.BestPractices)
## rds\$1casts 拡張機能のインストールと使用
`rds_casts` 拡張機能を作成するには、`rds_superuser` として RDS for PostgreSQL DB インスタンスに接続し、次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## サポートされているキャスト
カスタムキャストを使用する各データベースに拡張機能を作成します。拡張機能を作成した後、次のコマンドを使用して使用可能なすべてのキャストを表示します。
```
SELECT * FROM rds_casts.list_supported_casts();
```
この関数は、使用可能なキャストの組み合わせ (ソースタイプ、ターゲットタイプ、強制コンテキスト、キャスト関数) を一覧表示します。例えば、`text` から `numeric` への `implicit` キャストを作成する場合です。次のクエリを使用して、キャストを作成できるかどうかを確認できます。
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
rds\$1casts 拡張機能は、キャストごとに 2 種類の変換関数を提供します。
+ *\$1inout 関数* - PostgreSQL の標準 I/O 変換メカニズムを使用し、INOUT メソッドで作成されたキャストと同じように動作します。
+ *\$1custom 関数* - 変換エラーを避けるために空の文字列を NULL 値に変換するなど、エッジケースを処理する拡張変換ロジックを提供します。
`inout` 関数は PostgreSQL のネイティブキャスト動作をレプリケートしますが、`custom` 関数は、空の文字列を整数に変換するなど、標準の INOUT キャストが対応できないシナリオを処理することでこの機能を拡張します。
## キャストの作成または削除
次の 2 つの方法を使用して、サポートされているキャストを作成および削除できます。
### キャストの作成
**方法 1: ネイティブの CREATE CAST コマンドを使用する**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**方法 2: rds\$1casts.create\$1cast 関数を使用する**
```
SELECT rds_casts.create_cast(10);
```
`create_cast` 関数は、`list_supported_casts()` 出力から ID を取得します。この方法はよりシンプルで、正しい関数とコンテキストの組み合わせを使用していることが確認されます。この ID は、異なる postgres バージョン間で同じままであることが保証されています。
キャストが正常に作成されたことを確認するには、pg\$1cast システムカタログをクエリします。
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
`castcontext` 列には、EXPLICIT の場合は `e`、ASSIGNMENT の場合は `a`、IMPLICIT の場合は `i` が表示されます。
### キャストの削除
**方法 1: DROP CAST コマンドを使用する**
```
DROP CAST IF EXISTS (text AS numeric);
```
**方法 2: rds\$1casts.drop\$1cast 関数を使用する**
```
SELECT rds_casts.drop_cast(10);
```
`drop_cast` 関数は、キャストの作成時と同じ ID を使用します。この方法では、対応する ID で作成されたキャストを正確に削除できます。
## 適切なコンテキスト戦略を使用してカスタムキャストを作成する
整数型に対して複数のキャストを作成する場合、すべてのキャストが IMPLICIT として作成されると、演算子のあいまいさのエラーが発生する可能性があります。次の例は、テキストから異なる整数幅に 2 つの暗黙的なキャストを作成することで、この問題を示しています。
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
このエラーは、PostgreSQL が整数列とテキスト値を比較するときに使用する暗黙的なキャストを特定できないために発生します。int4 と int8 の両方の暗黙的なキャストが有効な候補であるため、あいまいさが生じます。
この演算子のあいまいさを回避するには、小さい整数幅には ASSIGNMENT コンテキストを使用し、大きい整数幅には IMPLICIT コンテキストを使用します。
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
この戦略では、int8 キャストのみが暗黙的であるため、PostgreSQL はどのキャストを使用するかを明確に判断できます。
# RDS for PostgreSQL での並列クエリのベストプラクティス
並列クエリ実行は、PostgreSQL の機能であり、単一の SQL クエリをより小さなタスクに分割し、複数のバックグラウンドワーカープロセスによって同時に処理することを可能にします。PostgreSQL は、クエリ全体を単一のバックエンドプロセスで実行する代わりに、スキャン、結合、集約、ソートなどのクエリの一部を複数の CPU コアに分散させることができます。*リーダープロセス*は、この実行を調整し、*並列ワーカー*から結果を収集します。
ただし、ほとんどの本稼働ワークロード、特に高同時実行 OLTP システムでは、自動並列クエリ実行を無効にすることをお勧めします。並列処理は、分析またはレポートワークロードの大規模なデータセットに対するクエリを高速化できますが、負荷の高い本番環境では、多くの場合、メリットを上回る重大なリスクをもたらします。
並列実行では、大きなオーバーヘッドも発生します。各並列ワーカーは完全な PostgreSQL バックエンドプロセスであり、プロセスのフォーク (メモリ構造のコピーとプロセス状態の初期化) と認証 (`max_connections` 制限の接続スロットの消費) が必要です。各ワーカーは、ソートやハッシュ操作のための `work_mem` を含め、独自のメモリも消費します。クエリごとに複数のワーカーがある場合、メモリ使用量は急速に増加します (例: 4 つのワーカー × 64MB `work_mem` = クエリあたり 256MB)。その結果、並列クエリは単一プロセスクエリよりもかなり多くのシステムリソースを消費する可能性があります。正しくチューニングされていない場合は、CPU 飽和 (複数のワーカーが使用可能な処理能力を圧倒する)、コンテキスト切り替えの増加 (オペレーティングシステムが多数のワーカープロセスを頻繁に切り替えるため、オーバーヘッドが増加しスループットが低下する)、または接続の枯渇 (各並列ワーカーが接続スロットを消費するため、4 つのワーカーを含む単一のクエリでは、リーダー 1 つとワーカー 4 つの合計 5 つの接続が使用され、高い同時実行性のもとでは接続プールがすぐに枯渇し、新しいクライアント接続が妨げられ、アプリケーション障害が発生する) につながる可能性があります。これらの問題は、複数のクエリが同時に並列実行を試みる可能性がある同時実行性の高いワークロードでは特に深刻です。
PostgreSQL は、コスト見積もりに基づいて並列処理を使用するかどうかを決定します。場合によっては、プランナーは、実際には理想的でない場合でも、より安価に見える場合、並列プランに自動的に切り替えることがあります。これは、インデックス統計が古くなった場合や、肥大化してシーケンシャルスキャンがインデックス検索よりも魅力的に見える場合に発生する可能性があります。この動作により、自動並列プランによってクエリのパフォーマンスやシステムの安定性にリグレッションを引き起こすことがあります。
RDS for PostgreSQL で並列クエリを最大限に活用するには、ワークロードに基づいて並列クエリをテストおよびチューニングし、システムへの影響をモニタリングし、自動並列プラン選択を無効にして、クエリレベルで制御することが重要です。
## 設定パラメータ
PostgreSQL は、複数のパラメータを使用して並列クエリの動作と可用性を制御します。これらを理解して調整することは、予測可能なパフォーマンスを達成するために不可欠です。
| パラメータ | 説明 | デフォルト |
| --- | --- | --- |
| max\$1parallel\$1workers | 同時に実行できるバックグラウンドワーカープロセスの最大数 | GREATEST(\$1DBInstanceVCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | クエリプランノードあたりのワーカーの最大数 (例: Gather あたり) | 2 |
| parallel\$1setup\$1cost | 並列クエリインフラストラクチャを開始するためのプランナーコストの追加 | 1,000 |
| parallel\$1tuple\$1cost | 並列モードで処理されたタプルあたりのコスト (プランナーの決定に影響する) | 0.1 |
| force\$1parallel\$1mode | プランナーに並列プランのテストを強制する (off、on、regress) | off |
### 主な考慮事項
+ `max_parallel_workers` は、並列ワーカーの合計プールを制御します。設定が低すぎると、一部のクエリが直列実行にフォールバックする可能性があります。
+ `max_parallel_workers_per_gather` は、単一のクエリで使用できるワーカーの数に影響します。値を大きくすると、同時実行数は増加しますが、リソースの使用量も増加します。
+ `parallel_setup_cost` と `parallel_tuple_cost` は、プランナーのコストモデルに影響を与えます。これらの値を下げると、並列プランを選択する可能性が高くなります。
+ `force_parallel_mode` はテストに便利ですが、必要でない限り本番環境では使用しないでください。
**注記**
`max_parallel_workers` パラメータのデフォルト値は、式 `GREATEST($DBInstanceVCPU/2, 8)` を使用してインスタンスサイズに基づいて動的に計算されます。つまり、DB インスタンスをより多くの vCPU でより大きなコンピューティングサイズにスケールすると、使用可能な並列ワーカーの最大数が自動的に増加します。その結果、以前に連続して実行されたクエリや、並列処理が制限されたクエリでは、スケールアップ操作後に突然、より多くの並列ワーカーが使用され、接続使用量、CPU 使用率、メモリ消費量が予期せず増加する可能性があります。コンピューティングスケーリングイベントの後に並列クエリの動作をモニタリングし、予測可能なリソース使用量を維持するために必要に応じて `max_parallel_workers_per_gather` を調整することが重要です。
## 並列クエリの使用状況を特定する
クエリは、データの分布または統計に基づいて並列プランに切り替わる場合があります。例えば、次のようになります。
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
このクエリは、最近のデータにインデックスを使用しますが、履歴データに対しては並列シーケンシャルスキャンに切り替える可能性があります。
`auto_explain` モジュールをロードすることでクエリ実行計画を記録できます。詳細については、AWS ナレッジセンターの「[クエリ実行計画のログ記録](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#)」をご覧ください。
[CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) を使用すると、並列クエリに関連する待機イベントをモニタリングできます。並列クエリに関連する待機イベントの詳細については、「[IPC:parallel 待機イベント](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html)」を参照してください。
PostgreSQL バージョン 18 以降では、[https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW) と [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html) の新しい列を使用して、並列ワーカーのアクティビティをモニタリングできます。
+ `parallel_workers_to_launch`: 起動が予定されている並列ワーカーの数
+ `parallel_workers_launched`: 実際に起動された並列ワーカーの数
これらのメトリクスは、計画された並列処理と実際の並列処理との間の差異を特定するのに役立ち、リソースの制約や設定の問題を示している可能性があります。次のクエリを使用して、並列実行をモニタリングします。
データベースレベルの並列ワーカーメトリクスの場合。
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
クエリレベルの並列ワーカーメトリクスの場合
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## 並列処理を制御する方法
クエリの並列処理を制御するにはいくつかの方法があり、それぞれがさまざまなシナリオと要件に合わせて設計されています。
自動並列処理をグローバルに無効にするには、[パラメータグループを変更して](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html)、次のように設定します。
```
max_parallel_workers_per_gather = 0;
```
永続的なユーザー固有の設定の場合、ALTER ROLE コマンドを使用すると、特定のユーザーの今後のすべてのセッションに適用されるパラメータを設定できます。
例えば、次のようになります。
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;` は、このユーザーがデータベースに接続するたびに、セッションが必要に応じてこの並列ワーカー設定を使用するようにします。
セッションレベルの制御は、現在のデータベースセッションの期間中にパラメータを変更する SET コマンドを使用して実現できます。これは、他のユーザーや今後のセッションに影響を与えることなく、設定を一時的に調整する必要がある場合に特に便利です。設定すると、これらのパラメータは明示的にリセットされるまで、またはセッションが終了するまで有効です。コマンドは簡単です。
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
さらに詳細な制御を行うには、SET LOCAL を使用すると、単一のトランザクションのパラメータを変更できます。これは、トランザクション内の特定のクエリセットの設定を調整する必要がある場合に最適です。その後、設定は自動的に以前の値に戻ります。このアプローチは、同じセッション内の他のオペレーションへの意図しない影響を防ぐのに役立ちます。
## 並列クエリ動作の診断
`EXPLAIN (ANALYZE, VERBOSE)` を使用して、クエリが並列実行を使用したかどうかを確認します。
+ `Gather`、`Gather Merge`、`Parallel Seq Scan` などのノードを探します。
+ 並列処理ありの場合と並列処理なしの場合の計画を比較します。
比較のために並列処理を一時的に無効にするには。
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# RDS for PostgreSQL DB インスタンスでのパラメータの使用
場合によっては、カスタムパラメータグループを指定せずに RDS for PostgreSQL DB インスタンスを作成することがあります。その場合、DB インスタンスは、選択したバージョンの PostgreSQL のデフォルトのパラメータグループを使用して作成されます。例えば、PostgreSQL 13.3 を使用して PostgreSQL DB インスタンス用の RDS を作成するとします。この場合、DB インスタンスは PostgreSQL 13 リリースのパラメータグループの値 `default.postgres13` を使用して作成されます。
独自のカスタム DB パラメータグループを作成することもできます。RDS for PostgreSQL DB インスタンスの設定をデフォルト値から変更する場合は、これを実行する必要があります。この方法の詳細は、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
RDS for PostgreSQL DB インスタンスの設定は、いくつかの異なる方法で追跡できます。AWS マネジメントコンソール、AWS CLI、または Amazon RDS API を使用できます。次のように、インスタンスの PostgreSQL `pg_settings` テーブルから値をクエリすることもできます。
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
このクエリから返される値の詳細については、PostgreSQL ドキュメントの「[https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html)」を参照してください。
RDS for PostgreSQL DB インスタンスで `max_connections` と `shared_buffers` の設定を変更するときは、特に注意してください。例えば、`max_connections` または `shared_buffers` の設定を変更し、実際のワークロードに対して高すぎる値を使用するとします。この場合、RDS for PostgreSQL DB インスタンスは起動しません。この場合、`postgres.log` に次のようなエラーが表示されます。
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
ただし、デフォルトの RDS for PostgreSQL DB パラメータグループに含まれる設定の値は変更できません。パラメータの設定を変更するには、まずカスタム DB パラメータグループを作成します。次に、そのカスタムグループの設定を変更し、カスタムパラメータグループを RDS for PostgreSQL DB インスタンスに適用します。詳細については[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)を参照してください。
RDS for PostgreSQL には、2 種類のパラメータがあります。
+ **静的パラメータ** – 静的パラメータでは、変更後に RDS for PostgreSQL DB インスタンスを再起動して、新しい値を有効にする必要があります。
+ **動的パラメータ** – 動的パラメータでは、設定を変更した後に再起動する必要はありません。
**注記**
RDS for PostgreSQL DB インスタンスで独自のカスタム DB パラメータグループを使用している場合は、実行中の DB インスタンスの動的パラメータの値を変更できます。これを行うには、AWS マネジメントコンソール、AWS CLI、または Amazon RDS API を使用します。
権限がある場合は、`ALTER DATABASE`、`ALTER ROLE`、および `SET` コマンドを使用して、パラメータ値を変更することもできます。
## RDS for PostgreSQL DB インスタンスのパラメータのリスト
RDS for PostgreSQL DB インスタンスで使用可能なパラメータの一部 (すべてではありません) を次の表に示します。使用可能なすべてのパラメータを表示するには、[describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html)AWS CLI コマンドを使用します。例えば、RDS for PostgreSQL バージョン 13 のデフォルトパラメータグループで使用可能なすべてのパラメータのリストを取得するには、以下を実行します。
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
コンソールを使用することもできます。Amazon RDS メニューから **[Parameter groups]** (パラメータグループ) を選択し、AWS リージョン で利用できるパラメータグループの中からパラメータグループを選択します。
| パラメータ名 | Apply\$1Type | 説明 |
| --- | --- | --- |
| `application_name` | 動的 | 統計情報とログで報告されるアプリケーション名を設定します。 |
| `archive_command` | 動的 | WAL ファイルをアーカイブするために呼び出されるシェルコマンドを設定します。 |
| `array_nulls` | 動的 | 配列での NULL 要素の入力を有効にします。 |
| `authentication_timeout` | 動的 | クライアント認証の実行で許可する最大時間を設定します。 |
| `autovacuum` | 動的 | autovacuum サブプロセスを起動します。 |
| `autovacuum_analyze_scale_factor` | 動的 | 分析する前のタプルの挿入、更新、削除の数 (reltuples の割合として指定)。 |
| `autovacuum_analyze_threshold` | 動的 | 分析する前のタプルの挿入、更新、削除の最小数。 |
| `autovacuum_freeze_max_age` | 静的 | トランザクション ID の循環を防ぐためにテーブルに対して autovacuum を実行する期間。 |
| `autovacuum_naptime` | 動的 | autovacuum の実行の間で休止状態になっている時間。 |
| `autovacuum_max_workers` | 静的 | 同時に実行される autovacuum ワーカープロセスの最大数を設定します。 |
| `autovacuum_vacuum_cost_delay` | 動的 | autovacuum でのバキューム処理のコスト遅延の値 (ミリ秒単位)。 |
| `autovacuum_vacuum_cost_limit` | 動的 | autovacuum でバキューム処理を停止する制限値となるバキューム処理のコスト |
| `autovacuum_vacuum_scale_factor` | 動的 | バキューム処理する前のタプルの更新または削除の数 (reltuples の割合として指定)。 |
| `autovacuum_vacuum_threshold` | 動的 | バキューム処理する前のタプルの更新また削除の最小数。 |
| `backslash_quote` | 動的 | 文字列リテラルでバックスラッシュ (\$1) を許可するかどうかを指定します。 |
| `bgwriter_delay` | 動的 | ラウンド間でのバックグラウンドライターの休止時間。 |
| `bgwriter_lru_maxpages` | 動的 | ラウンドあたりのフラッシュするバックグラウンドライター LRU ページの最大数。 |
| `bgwriter_lru_multiplier` | 動的 | ラウンドあたりの解放される平均バッファ使用量の倍数。 |
| `bytea_output` | 動的 | バイトの出力形式を設定します。 |
| `check_function_bodies` | 動的 | CREATE FUNCTION の実行中に関数の本文をチェックします。 |
| `checkpoint_completion_target` | 動的 | チェックポイント中にダーティバッファのフラッシュにかかった時間 (チェックポイント間隔の割合として指定)。 |
| `checkpoint_segments` | 動的 | 自動 WAL (ログ先行書き込み) チェックポイント間のログセグメントの最大間隔を設定します。 |
| `checkpoint_timeout` | 動的 | 自動 WAL チェックポイント間の最大時間を設定します。 |
| `checkpoint_warning` | 動的 | チェックポイントセグメントがこの値よりも頻繁に満杯になる場合に警告を出します。 |
| `client_connection_check_interval` | 動的 | クエリ実行中の切断を確認する時間間隔を設定します。 |
| `client_encoding` | 動的 | クライアントの文字セットエンコードを設定します。 |
| `client_min_messages` | 動的 | クライアントへ送信されるメッセージレベルを設定します。 |
| `commit_delay` | 動的 | トランザクションのコミットからディスクへの WAL のフラッシュまでの遅延間隔をマイクロ秒単位で設定します。 |
| `commit_siblings` | 動的 | commit\$1delay を実行する前に同時に開いている必要があるトランザクションの最小数を設定します。 |
| `constraint_exclusion` | 動的 | クエリを最適化するために、プランナーが制約を使用できるようにします。 |
| `cpu_index_tuple_cost` | 動的 | インデックススキャンの実行中に各インデックスエントリを処理する際にかかるコストに対するプランナーの見積もりを設定します。 |
| `cpu_operator_cost` | 動的 | 演算子の呼び出しや関数呼び出しのそれぞれを処理する際にかかるコストに対するプランナーの見積もりを設定します。 |
| `cpu_tuple_cost` | 動的 | 各タプル (行) の処理にかかるコストに対するプランナーの見積もりを設定します。 |
| `cursor_tuple_fraction` | 動的 | 取得されるカーソル行の割合に対するプランナーの見積もりを設定します。 |
| `datestyle` | 動的 | 日付と時刻の値の表示形式を設定します。 |
| `deadlock_timeout` | 動的 | デッドロックをチェックするまでロックを待機する時間を設定します。 |
| `debug_pretty_print` | 動的 | 分析ツリーや計画ツリーの表示をインデントして見やすくします。 |
| `debug_print_parse` | 動的 | 各クエリの分析ツリーをログに記録します。 |
| `debug_print_plan` | 動的 | 各クエリの実行計画をログに記録します。 |
| `debug_print_rewritten` | 動的 | 各クエリの書き直された分析ツリーをログに記録します。 |
| `default_statistics_target` | 動的 | デフォルトの統計情報の対象を設定します。 |
| `default_tablespace` | 動的 | テーブルとインデックスを作成するためのデフォルトのテーブルスペースを設定します。 |
| `default_transaction_deferrable` | 動的 | 新しいトランザクションのデフォルトの遅延ステータスを設定します。 |
| `default_transaction_isolation` | 動的 | 新しい各トランザクションのトランザクション分離レベルを設定します。 |
| `default_transaction_read_only` | 動的 | 新しいトランザクションのデフォルトの読み取り専用ステータスを設定します。 |
| `default_with_oids` | 動的 | デフォルトでオブジェクト ID (OID) を使用して新しいテーブルを作成します。 |
| `effective_cache_size` | 動的 | ディスクキャッシュのサイズに関するプランナーの予測を設定します。 |
| `effective_io_concurrency` | 動的 | ディスクサブシステムで効率的に処理できる同時リクエストの数。 |
| `enable_bitmapscan` | 動的 | プランナーがビットマップスキャン計画を使用できるようにします。 |
| `enable_hashagg` | 動的 | プランナーがハッシュされた集計計画を使用できるようにします。 |
| `enable_hashjoin` | 動的 | プランナーがハッシュ結合計画を使用できるようにします。 |
| `enable_indexscan` | 動的 | プランナーがインデックススキャン計画を使用できるようにします。 |
| `enable_material` | 動的 | プランナーがマテリアル化を使用できるようにします。 |
| `enable_mergejoin` | 動的 | プランナーがマージ結合計画を使用できるようにします。 |
| `enable_nestloop` | 動的 | プランナーがネステッドループ結合計画を使用できるようにします。 |
| `enable_seqscan` | 動的 | プランナーがシーケンシャルスキャン計画を使用できるようにします。 |
| `enable_sort` | 動的 | プランナーが明示的なソートステップを使用できるようにします。 |
| `enable_tidscan` | 動的 | プランナーが TID スキャン計画を使用できるようにします。 |
| `escape_string_warning` | 動的 | 通常の文字列リテラルにバックスラッシュ (\$1) が含まれている場合に警告を出します。 |
| `extra_float_digits` | 動的 | 浮動小数点値の表示桁数を設定します。 |
| `from_collapse_limit` | 動的 | FROM リストのサイズを設定します。この値を超えるとサブクエリが折りたたまれなくなります。 |
| `fsync` | 動的 | ディスクへの更新の同期を強制的に行います。 |
| `full_page_writes` | 動的 | チェックポイントの後でページに初期の変更を加えた時点で、WAL にすべてのページを書き込みます。 |
| `geqo` | 動的 | 遺伝的クエリ最適化を有効にします。 |
| `geqo_effort` | 動的 | GEQO: 他の GEQO パラメータのデフォルト値を設定するために使用されます。 |
| `geqo_generations` | 動的 | GEQO: アルゴリズムの反復の数。 |
| `geqo_pool_size` | 動的 | GEQO: 母集団内の個体の数。 |
| `geqo_seed` | 動的 | GEQO: 無作為のパスを選択するための初期値。 |
| `geqo_selection_bias` | 動的 | GEQO: 母集団内の選択圧。 |
| `geqo_threshold` | 動的 | FROM 項目のしきい値を設定します。この値を超えると GEQO が使用されます。 |
| `gin_fuzzy_search_limit` | 動的 | GIN による完全一致検索で許可される結果の最大数を設定します。 |
| `hot_standby_feedback` | 動的 | ホットスタンバイがフィードバックメッセージをプライマリあるいはアップストリーミングスタンバイに送信するかを決定します。 |
| `intervalstyle` | 動的 | 間隔値の表示形式を設定します。 |
| `join_collapse_limit` | 動的 | FROM リストのサイズを設定します。この値を超えると JOIN 構造が平坦化されなくなります。 |
| `lc_messages` | 動的 | メッセージを表示する言語を設定します。 |
| `lc_monetary` | 動的 | 金額の書式のロケールを設定します。 |
| `lc_numeric` | 動的 | 数値の書式のロケールを設定します。 |
| `lc_time` | 動的 | 日付と時刻の書式のロケールを設定します。 |
| `log_autovacuum_min_duration` | 動的 | autovacuum に関する最小実行時間を設定します。この値を超えると autovacuum アクションがログに記録されます。 |
| `log_checkpoints` | 動的 | 各チェックポイントをログに記録します。 |
| `log_connections` | 動的 | 成功した各接続をログに記録します。 |
| `log_disconnections` | 動的 | セッションの終了をログに記録します (セッションの有効期間も含まれます)。 |
| `log_duration` | 動的 | 完了した各 SQL ステートメントの期間をログに記録します。 |
| `log_error_verbosity` | 動的 | ログに記録されるメッセージの詳細を設定します。 |
| `log_executor_stats` | 動的 | 実行プログラムのパフォーマンスの統計情報をサーバーログに書き込みます。 |
| `log_filename` | 動的 | ログファイルのファイル名のパターンを設定します。 |
| `log_file_mode` | 動的 | ログファイルのファイルアクセス許可を設定します。デフォルト値は 0644 です。 |
| `log_hostname` | 動的 | 接続ログにホスト名を記録します。PostgreSQL 12 以降のバージョンでは、このパラメータはデフォルトで「off」になっています。オンにすると、接続は DNS 逆引き参照を使用してホスト名を取得し、接続ログに取り込まれます。このパラメータをオンにする場合は、接続の確立にかかる時間への影響をモニタリングする必要があります。 |
| `log_line_prefix ` | 動的 | 各ログ行の先頭に付ける情報を制御します。 |
| `log_lock_waits` | 動的 | 長期間にわたるロックの待機をログに記録します。 |
| `log_min_duration_statement` | 動的 | 最小実行時間を設定します。この値を超えるとステートメントがログに記録されます。 |
| `log_min_error_statement` | 動的 | 設定したレベル以上のエラーが発生したすべてのステートメントをログに記録します。 |
| `log_min_messages` | 動的 | ログに記録するメッセージレベルを設定します。 |
| `log_parser_stats` | 動的 | 分析のパフォーマンスの統計情報をサーバーログに書き込みます。 |
| `log_planner_stats` | 動的 | プランナーのパフォーマンスの統計情報をサーバーログに書き込みます。 |
| `log_rotation_age` | 動的 | N 分が経過するとログファイルのローテーションが自動的に発生します。 |
| `log_rotation_size` | 動的 | N キロバイトを超えるとログファイルのローテーションが自動的に発生します。 |
| `log_statement` | 動的 | ログに記録するステートメントのタイプを設定します。 |
| `log_statement_stats` | 動的 | 累積処理のパフォーマンスの統計情報をサーバーログに書き込みます。 |
| `log_temp_files` | 動的 | 指定したサイズ (キロバイト) を超えるテンポラリファイルの使用をログに記録します。 |
| `log_timezone` | 動的 | ログメッセージで使用するタイムゾーンを設定します。 |
| `log_truncate_on_rotation` | 動的 | ログローテーション中に同じ名前の既存のログファイルを切り捨てます。 |
| `logging_collector` | 静的 | サブプロセスを開始して、stderr 出力や csvlogs をログファイルにキャプチャします。 |
| `maintenance_work_mem` | 動的 | メンテナンスオペレーションに使用するメモリの最大量を設定します。 |
| `max_connections` | 静的 | 同時接続の最大数を設定します。 |
| `max_files_per_process` | 静的 | 各サーバープロセスで同時に開くことができるファイルの最大数を設定します。 |
| `max_locks_per_transaction` | 静的 | トランザクションあたりのロックの最大数を設定します。 |
| `max_pred_locks_per_transaction` | 静的 | トランザクションあたりの述語ロックの最大数を設定します。 |
| `max_prepared_transactions` | 静的 | 同時に準備できるトランザクションの最大数を設定します。 |
| `max_stack_depth` | 動的 | スタックの深度の最大値をキロバイト単位で指定します。 |
| `max_standby_archive_delay` | 動的 | ホットスタンバイサーバーがアーカイブされた WAL データを処理しているときにクエリをキャンセルするまでの最大遅延間隔を設定します。 |
| `max_standby_streaming_delay` | 動的 | ホットスタンバイサーバーがストリーミングされた WAL データを処理しているときにクエリをキャンセルするまでの最大遅延間隔を設定します。 |
| max\$1wal\$1size | 動的 | チェックポイントをトリガーする WAL サイズ (MB) を設定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Amazon RDS for PostgreSQL DB インスタンスで以下のコマンドを使用して現在の値を確認します。 SHOW max_wal_size;
|
| min\$1wal\$1size | 動的 | WAL を縮小する最小サイズを設定します。PostgreSQL バージョン 9.6 以前の場合、min\$1wal\$1size の単位は 16 MB です。PostgreSQL バージョン 10 以降の場合、min\$1wal\$1size の単位は 1 MB です。 |
| `quote_all_identifiers` | 動的 | SQL フラグメントを生成するときに、すべての識別子に引用符 (") を追加します。 |
| `random_page_cost` | 動的 | 非連続的に取得されたディスクページのコストに対するプランナーの見積もりを設定します。クエリプラン管理 (QPM) がオンでない限り、このパラメータには値はありません。QPM がオンの場合、このパラメータ 4 はデフォルト値です。 |
| rds.adaptive\$1autovacuum | 動的 | トランザクション ID のしきい値を超えるたびに、autovacuum パラメータを自動的に微調整します。 |
| rds.force\$1ssl | 動的 | SSL 接続を使用する必要があります。PostgreSQL バージョン 15 の RDS では、デフォルト値は 1 (オン) に設定されています。PostgreSQL のメジャーバージョン 14 以前のその他すべての RDS では、デフォルト値が 0 (オフ) に設定されています。 |
| `rds.local_volume_spill_enabled` | 静的 | ローカルボリュームへの論理スピルファイルの書き込みを有効にします。 |
| `rds.log_retention_period` | 動的 | n 分より古い PostgreSQL ログは Amazon RDS で削除されるようにログ保持期間を設定します。 |
| rds.rds\$1superuser\$1reserved\$1connections | 静的 | rds\$1superusers 用に予約されている接続スロットの数を設定します。このパラメータは、バージョン 15 以前でのみ使用できます。詳細については、PostgreSQL ドキュメントの「[reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS)」を参照してください。 |
| `rds.replica_identity_full` | 動的 | このパラメータを `on` に設定すると、すべてのデータベーステーブルのレプリカ ID 設定が `FULL` に上書きされます。つまり、`REPLICA IDENTITY FULL` 設定に関係なく、すべての列値が先書きログ (WAL) に書き込まれます。 このパラメータをオンにすると、追加の WAL ログ記録のためにデータベースインスタンスの IOPS が増加する可能性があります。 |
| rds.restrict\$1password\$1commands | 静的 | rds\$1password ロールを持つユーザーに対して、だれがパスワードを管理するかを制限します。パスワードの制限を有効にするには、このパラメータを 1 に設定します。デフォルトは 0 です。 |
| `search_path` | 動的 | スキーマによって修飾されていない名前でスキーマを検索する順序を設定します。 |
| `seq_page_cost` | 動的 | 連続的に取得されたディスクページのコストに対するプランナーの見積もりを設定します。 |
| `session_replication_role` | 動的 | トリガーと再書き込みルールに対するセッション動作を設定します。 |
| `shared_buffers` | 静的 | サーバーで使用される共有メモリバッファの数を設定します。 |
| `shared_preload_libraries ` | 静的 | RDS for PostgreSQL DB インスタンスにプリロードする共有ライブラリをリストします。サポートされている値は、auto\$1explain、orafce、pgaudit、pglogical、pg\$1bigm、pg\$1cron、pg\$1hint\$1plan、pg\$1prewarm、pg\$1similarity、pg\$1stat\$1statements、pg\$1transport、plprofiler、および plrust です。 |
| `ssl` | 動的 | SSL 接続を有効にします。 |
| `sql_inheritance` | 動的 | さまざまなコマンドにデフォルトでサブテーブルが取り込まれます。 |
| `ssl_renegotiation_limit` | 動的 | 暗号化キーを再度ネゴシエートする前に送受信されるトラフィックの量を設定します。 |
| `standard_conforming_strings` | 動的 | ... 文字列をリテラルのバックスラッシュとして扱います。 |
| `statement_timeout` | 動的 | すべてのステートメントに許可される最大実行時間を設定します。 |
| `synchronize_seqscans` | 動的 | シーケンシャルスキャンの同期を有効にします。 |
| `synchronous_commit` | 動的 | 現在のトランザクションの同期レベルを設定します。 |
| `tcp_keepalives_count` | 動的 | TCP キープアライブを再送信する最大回数。 |
| `tcp_keepalives_idle` | 動的 | TCP キープアライブを発行する間隔の時間。 |
| `tcp_keepalives_interval` | 動的 | TCP キープアライブを再送信する間隔の時間。 |
| `temp_buffers` | 動的 | 各セッションで使用されるテンポラリバッファの最大数を設定します。 |
| temp\$1file\$1limit | 動的 | テンポラリファイルの最大サイズを KB 単位で設定します。 |
| `temp_tablespaces` | 動的 | テンポラリテーブルとソートファイルで使用するテーブルスペースを設定します。 |
| `timezone` | 動的 | 表示やタイムスタンプの解釈で必要となるタイムゾーンを設定します。 Internet Assigned Numbers Authority (IANA) は年に数回、[https://www.iana.org/time-zones](https://www.iana.org/time-zones) で新しいタイムゾーンを公開します。RDS が PostgreSQL の新しいマイナーメンテナンスリリースをリリースするたびに、リリース時の最新のタイムゾーンデータが付属しています。最新の RDS for PostgreSQL バージョンを使用すると、RDS からの最新のタイムゾーンデータが得られます。DB インスタンスに最新のタイムゾーンデータがあることを確認するには、DB エンジンの上位バージョンにアップグレードすることをお勧めします。PostgreSQL DB インスタンスのタイムゾーン テーブルを手動で変更することはできません。RDS は、実行中の DB インスタンスのタイムゾーンデータを変更またはリセットしません。新しいタイムゾーンデータは、データベースエンジンのバージョンアップグレードを実行する場合にのみインストールされます。 |
| `track_activities` | 動的 | コマンドの実行に関する情報を収集します。 |
| `track_activity_query_size` | 静的 | pg\$1stat\$1activity.current\$1query 用に予約するサイズをバイト単位で設定します。 |
| `track_counts` | 動的 | データベースアクティビティの統計情報を収集します。 |
| `track_functions` | 動的 | データベースアクティビティの関数レベルの統計情報を収集します。 |
| `track_io_timing` | 動的 | データベース I/O アクティビティのタイミングに関する統計情報を収集します。 |
| `transaction_deferrable` | 動的 | 読み取り専用のシリアル化可能なトランザクションを、シリアル化が失敗する可能性がない状況でスタートできるようになるまで延期するかどうかを示します。 |
| `transaction_isolation` | 動的 | 現在のトランザクションの分離レベルを設定します。 |
| `transaction_read_only` | 動的 | 現在のトランザクションの読み取り専用ステータスを設定します。 |
| `transform_null_equals` | 動的 | expr=NULL を expr IS NULL として扱います。 |
| `update_process_title` | 動的 | アクティブな SQL コマンドを表示するようにプロセスのタイトルを更新します。 |
| `vacuum_cost_delay` | 動的 | バキューム処理のコスト遅延の値 (ミリ秒単位)。 |
| `vacuum_cost_limit` | 動的 | バキューム処理を停止する制限値となるバキューム処理のコスト。 |
| `vacuum_cost_page_dirty` | 動的 | バキューム処理によってダーティになったページに対するバキューム処理のコスト。 |
| `vacuum_cost_page_hit` | 動的 | バッファキャッシュ内で検出されたページに対するバキューム処理のコスト。 |
| `vacuum_cost_page_miss` | 動的 | バッファキャッシュ内で検出されなかったページに対するバキューム処理のコスト。 |
| `vacuum_defer_cleanup_age` | 動的 | バキューム処理とホットクリーンアップが延期されるトランザクションの数 (存在する場合)。 |
| `vacuum_freeze_min_age` | 動的 | バキューム処理でテーブルの行をフリーズする最小期間。 |
| `vacuum_freeze_table_age` | 動的 | バキューム処理でテーブル全体をスキャンしタプルをフリーズするための期間。 |
| `wal_buffers` | 静的 | WAL 用の共有メモリ内のディスクページバッファの数を設定します。 |
| `wal_writer_delay` | 動的 | WAL のフラッシュが行われる間の WAL ライターの休止時間。 |
| `work_mem` | 動的 | クエリワークスペースに使用するメモリの最大量を設定します。 |
| `xmlbinary` | 動的 | バイナリ値を XML にエンコードする方法を設定します。 |
| `xmloption` | 動的 | 黙示的な分析とシリアル化オペレーションでの XML データをドキュメントとして見なすか、コンテンツのフラグメントとして見なすかを設定します。 |
Amazon RDS では、すべてのパラメータについて PostgreSQL のデフォルトの単位を使用します。次の表は、PostgreSQL のパラメータ別のデフォルト単位を示しています。
| パラメータ名 | Unit |
| --- | --- |
| `archive_timeout` | s |
| `authentication_timeout` | s |
| `autovacuum_naptime` | s |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | s |
| `checkpoint_warning` | s |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | minutes |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | s |
| `pre_auth_delay` | s |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | s |
| `tcp_keepalives_interval` | s |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | s |
# RDS for PostgreSQL の待機イベントでのチューニング
待機イベントは RDS for PostgreSQL の重要なチューニングツールです。セッションがリソースを待っている理由とその内容がわかれば、ボトルネックを減少できます。このセクションの情報を使用して、考えられる原因と修正措置を見つけることができます。このセクションでは、PostgreSQL の基本的なチューニングの概念についても説明します。
このセクションの待機イベントは RDS for PostgreSQL 固有のものです。
**Topics**
+ [
# RDS for PostgreSQL チューニングの基本概念
](PostgreSQL.Tuning.concepts.md)
+ [
# RDS for PostgreSQL 待機イベント
](PostgreSQL.Tuning.concepts.summary.md)
+ [
# Client:ClientRead
](wait-event.clientread.md)
+ [
# クライアント: ClientWrite
](wait-event.clientwrite.md)
+ [
# CPU
](wait-event.cpu.md)
+ [
# IO:BufFileRead および IO:BufFileWrite
](wait-event.iobuffile.md)
+ [
# IO:DataFileRead
](wait-event.iodatafileread.md)
+ [
# IO:WALWrite
](wait-event.iowalwrite.md)
+ [
# IPC:parallel 待機イベント
](rpg-ipc-parallel.md)
+ [
# IPC:ProcArrayGroupUpdate
](apg-rpg-ipcprocarraygroup.md)
+ [
# Lock:advisory
](wait-event.lockadvisory.md)
+ [
# Lock:extend
](wait-event.lockextend.md)
+ [
# Lock:Relation
](wait-event.lockrelation.md)
+ [
# Lock:transactionid
](wait-event.locktransactionid.md)
+ [
# Lock:tuple
](wait-event.locktuple.md)
+ [
# LWLock:BufferMapping (LWLock:buffer\$1mapping)
](wait-event.lwl-buffer-mapping.md)
+ [
# LWLock:BufferIO (IPC:BufferIO)
](wait-event.lwlockbufferio.md)
+ [
# LWLock:buffer\$1content (BufferContent)
](wait-event.lwlockbuffercontent.md)
+ [
# LWLock:lock\$1manager (LWLock:lockmanager)
](wait-event.lw-lock-manager.md)
+ [
# LWLock:pg\$1stat\$1statements
](apg-rpg-lwlockpgstat.md)
+ [
# LWLock:SubtransSLRU (LWLock:SubtransControlLock)
](wait-event.lwlocksubtransslru.md)
+ [
# Timeout:PgSleep
](wait-event.timeoutpgsleep.md)
+ [
# Timeout:VacuumDelay
](wait-event.timeoutvacuumdelay.md)
# RDS for PostgreSQL チューニングの基本概念
RDS for PostgreSQL データベースをチューニングする前に、待機イベントは何か、なぜそれが発生するのかを確認してください。RDS for PostgreSQL のベーシックメモリとディスクアーキテクチャも確認します。役立つアーキテクチャの図表については、[PostgreSQL](https://en.wikibooks.org/wiki/PostgreSQL/Architecture)ウィキブックを参照してください。
**Topics**
+ [
# RDS for PostgreSQL 待機イベント
](PostgreSQL.Tuning.concepts.waits.md)
+ [
# RDS for PostgreSQL メモリ
](PostgreSQL.Tuning.concepts.memory.md)
+ [
# RDS for PostgreSQL プロセス
](PostgreSQL.Tuning.concepts.processes.md)
# RDS for PostgreSQL 待機イベント
*待機イベント*は、リソースに対して待機しているリソースを示します。例えば、待機イベント `Client:ClientRead` は RDS for PostgreSQL がクライアントからのデータの受信を待っているときに発生します。セッションは通常、次のようなリソースを待ちます。
+ バッファへのシングルスレッドアクセス (例えば、セッションがバッファを変更しようとした場合など)
+ 別のセッションによって現在ロックされている行
+ 読み込まれたデータファイル
+ ログファイルの書き込み
例えば、クエリを満たすために、セッションで完全なテーブルスキャンを実行することがあります。データがまだメモリ上にない場合、セッションはディスク I/O が完了するまで待機します。バッファがメモリに読み込まれるときは、他のセッションが同じバッファにアクセスしているため、セッションは待機しなければならないことがあります。データベースは、事前定義された待機イベントを使用して待機を記録します。これらのイベントはカテゴリに分類されます。
待機イベント自体では、パフォーマンスの問題は表示されません。例えば、要求されたデータがメモリ上にない場合は、ディスクからデータを読み出す必要があります。あるセッションが更新のために行をロックすると、別のセッションはその行を更新できるようにロック解除されるまで待機します。コミットは、ログファイルへの書き込みが完了するまで待機する必要があります。待機は、データベースが正常に機能するために不可欠です。
一方で、待機イベントが発生すると、通常、パフォーマンスの問題を示します。そのような場合、待機イベントデータを使用して、セッションが時間を費やしている場所を特定できます。例えば、通常は数分で実行されるレポートが数時間かかるようになった場合、合計の待機時間に最も寄与している待機イベントを特定できます。上位の待機イベントの原因を特定できる場合は、パフォーマンス向上のための変更を実行できることがあります。例えば、別のセッションによってロックされている行をセッションが待っている場合、ロックセッションを終了させることができます。
# RDS for PostgreSQL メモリ
RDS for PostgreSQL メモリは、共有とローカルに分かれています。
**Topics**
+ [
## RDS for PostgreSQL の共有メモリ
](#PostgreSQL.Tuning.concepts.shared)
+ [
## RDS for PostgreSQL のローカルメモリ
](#PostgreSQL.Tuning.concepts.local)
## RDS for PostgreSQL の共有メモリ
RDS for PostgreSQL では、インスタンスの起動時に共有メモリを割り当てます。共有メモリは複数のサブエリアに分割されています。以下のセクションでは、最も重要なものについて説明します。
**Topics**
+ [
### 共有バッファ
](#PostgreSQL.Tuning.concepts.buffer-pool)
+ [
### ログ先行書き込み (WAL) バッファ
](#PostgreSQL.Tuning.concepts.WAL)
### 共有バッファ
*共有バッファプール*は、アプリケーション接続によって使用されている、または使用されていたすべてのページを保持する RDS for PostgreSQL メモリ領域です。*ページ*は、ディスクブロックのメモリバージョンです。共有バッファプールは、ディスクから読み込まれたデータブロックをキャッシュします。プールは、ディスクからデータを再読み取りする必要性を減らし、データベースの運用効率を向上させます。
すべてのテーブルとインデックスは、固定サイズのページの配列として格納されます。各ブロックには、行に対応する複数のタプルが含まれています。タプルはどのページにも格納できます。
共有バッファプールには有限メモリがあります。新しいリクエストがメモリにないページを必要とし、メモリがもう存在しない場合、RDS for PostgreSQL は使用頻度の低いページを削除してリクエストに対応します。削除ポリシーは、クロックスイープアルゴリズムによって実装されます。
`shared_buffers`パラメータは、サーバーがデータをキャッシュするメモリ量を決定します。デフォルト値は、DB インスタンスで利用可能なメモリに基づいて `{DBInstanceClassMemory/32768}` バイトに設定されます。
### ログ先行書き込み (WAL) バッファ
*ログ先行書き込み (WAL) バッファ*は、RDS for PostgreSQL が後で永続的ストレージに書き込むトランザクションデータを保持します。WAL メカニズムを使用すると、RDS for PostgreSQL は次のことを実行できます。
+ 障害発生後のデータリカバリ
+ ディスクへの頻繁な書き込みを回避し、ディスク I/O を削減
クライアントがデータを変更すると、RDS for PostgreSQL は WAL バッファに変更内容を書き込みます。クライアントが`COMMIT`を発すると、WAL ライタプロセスはトランザクションデータを WAL ファイルに書き込みます。
`wal_level` パラメータは、WAL に書き込む情報量を決定します。`minimal`、`replica`、`logical` などの値を設定できます。
## RDS for PostgreSQL のローカルメモリ
すべてのバックエンドプロセスは、クエリ処理にローカルメモリを割り当てます。
**Topics**
+ [
### ワークメモリ領域
](#PostgreSQL.Tuning.concepts.local.work_mem)
+ [
### メンテナンス作業用メモリ領域
](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem)
+ [
### テンポラリバッファ領域
](#PostgreSQL.Tuning.concepts.temp)
### ワークメモリ領域
*ワークメモリ領域*ソートとハッシュを実行するクエリのテンポラリデータを保持します。例えば、`ORDER BY`文節を持つクエリはソートを実行します。クエリは、ハッシュ結合と集約でハッシュテーブルを使用します。
`work_mem` パラメータは、一時ディスクファイルに書き込む前に、内部のソートオペレーションとハッシュテーブルで使用するメモリ量 (メガバイト単位) を指定します。デフォルト値は 4 MB です。複数のセッションを同時に実行でき、各セッションでメンテナンスオペレーションを並行して行うことができます。このため、使用されるワークメモリの合計は、`work_mem`設定の何倍にもなることがあります。
### メンテナンス作業用メモリ領域
*メンテナンス作業用メモリ領域*は、メンテナンスオペレーション用のデータをキャッシュします。これらの操作には、バキューム処理、インデックス作成、外部キーの追加が含まれます。
`maintenance_work_mem` パラメータは、メンテナンスオペレーションで使用するメモリの最大量 (メガバイト単位) を指定します。デフォルト値は 64 MB です。データベースセッションでは、一度に 1 つのメンテナンスオペレーションしか実行できません。
### テンポラリバッファ領域
*テンポラリバッファ領域*は、データベースセッションごとにテンポラリテーブルをキャッシュします。
各セッションは、指定した制限まで、必要に応じてテンポラリバッファを割り当てます。セッションが終了すると、サーバーはバッファをクリアします。
`temp_buffers` パラメータは、各セッションで使用する一時バッファの最大数 (メガバイト単位) を設定します。デフォルト値は 8 MB です。セッション内でテンポラリテーブルを初期に使用する前に、`temp_buffers`値を変更できます。
# RDS for PostgreSQL プロセス
RDS for PostgreSQL では複数のプロセスを使用します。
**Topics**
+ [
## Postmaster プロセス
](#PostgreSQL.Tuning.concepts.postmaster)
+ [
## バックエンドプロセス
](#PostgreSQL.Tuning.concepts.backend)
+ [
## バックグラウンドプロセス
](#PostgreSQL.Tuning.concepts.vacuum)
## Postmaster プロセス
*Postmaster プロセス*は、RDS for PostgreSQL を起動したときに初期のプロセスがスタートされます。Postmaster プロセスには、主に次のようなロールがあります。
+ バックグラウンドプロセスのフォークとモニタリング
+ クライアントプロセスから認証要求を受信し、データベースが要求を処理する前に認証する
## バックエンドプロセス
Postmaster がクライアント要求を認証する場合、Postmaster は新しいバックエンドプロセスをフォークします。これは postgres プロセスとも呼ばれます。1 つのクライアントプロセスが 1 つのバックエンドプロセスに接続されます。クライアントプロセスとバックエンドプロセスは、Postmaster プロセスの介入なしに直接通信します。
## バックグラウンドプロセス
Postmaster プロセスは、異なるバックエンドタスクを実行するいくつかのプロセスをフォークします。より重要なものとしては、以下のとおりです。
+ WALライター
RDS for PostgreSQL は WAL (ログ先行書き込み) バッファのデータをログファイルに書き込みます。ログ先行書き込みの原理は、データベースがそれらの変更を説明するログレコードをディスクに書き込むまで、データベースがデータファイルに変更を書き込むことができないということです。WAL メカニズムはディスク I/O を削減し、RDS for PostgreSQL が障害後にデータベースを回復するためにログを使用できるようにします。
+ バックグラウンドライター
このプロセスは、メモリバッファからデータファイルにダーティ (変更された) ページを定期的に書き込みます。バックエンドプロセスがメモリ上でページを変更すると、ページがダーティになります。
+ オートバキュームデーモン
最新のデーモンには以下の構成要素があります。
+ オートバキュームランチャー
+ オートバキュームワーカープロセス
オートバキュームをオンにすると、多数の挿入、更新、または削除されたタプルがあるテーブルを確認します。デーモンには、次のようなロールがあります。
+ 更新または削除された行によって占有されているディスク領域をリカバリまたは再利用する
+ プランナーで使用する統計情報を更新する
+ トランザクション ID のラップアラウンドによる古いデータの損失からの保護
オートバキューム機能は、`VACUUM`と`ANALYZE`コマンドの実行を自動化するもので、`VACUUM`にはスタンダードとフルのバリエーションがあります。スタンダードバキュームは、他のデータベースオペレーションと並行して実行されます。 `VACUUM FULL`は、作業中のテーブルを排他的にロックする必要があります。そのため、同じテーブルにアクセスするオペレーションと並行して実行することはできません。`VACUUM`は相当量の I/O トラフィックを作成し、他のアクティブなセッションのパフォーマンスが低下する原因となることがあります。
# RDS for PostgreSQL 待機イベント
次の表では、パフォーマンスの問題を最もよく示す RDS for PostgreSQL の待機イベントと、最も一般的な原因および修正処置をリストアップしています。
| 待機イベント | 定義 |
| --- | --- |
| [Client:ClientRead](wait-event.clientread.md) | このイベントは、RDS for PostgreSQL がクライアントからのデータ受信を待っているときに発生します。 |
| [クライアント: ClientWrite](wait-event.clientwrite.md) | このイベントは、RDS for PostgreSQL がクライアントへのデータ書き込みを待っているときに発生します。 |
| [CPU](wait-event.cpu.md) | この待機イベントは、スレッドが CPU でアクティブであるか CPU の待機中に発生します。 |
| [IO:BufFileRead および IO:BufFileWrite](wait-event.iobuffile.md) | これらのイベントは、RDS for PostgreSQL がテンポラリファイルを作成するときに発生します。 |
| [IO:DataFileRead](wait-event.iodatafileread.md) | このイベントは、バックエンドプロセスが必要なページをストレージから読み込む際に、ページが共有メモリで使用できないために接続が待機したときに発生します。 |
| [IO:WALWrite](wait-event.iowalwrite.md) | このイベントは、RDS for PostgreSQL が WAL ファイルへの先行書き込みログ (WAL) バッファの書き込みを待機しているときに発生します。 |
| [Lock:advisory](wait-event.lockadvisory.md) | このイベントは、PostgreSQL アプリケーションがロックを使用して、複数のセッションにわたるアクティビティを調整するときに発生します。 |
| [Lock:extend](wait-event.lockextend.md) | このイベントは、バックエンドプロセスがリレーション拡張のためにロックするのを待機中に、他のプロセスが同じ目的でそのリレーションをロックしているときに発生します。 |
| [Lock:Relation](wait-event.lockrelation.md) | このイベントは、他のトランザクションによって現在ロックされているテーブルまたはビューに対するロックを取得するためにクエリが待っているときに発生します。 |
| [Lock:transactionid](wait-event.locktransactionid.md) | このイベントは、トランザクションが行レベルロックを待っているときに発生します。 |
| [Lock:tuple](wait-event.locktuple.md) | このイベントは、バックエンドプロセスがタプルのロック取得を待機中の場合に発生します。 |
| [LWLock:BufferMapping (LWLock:buffer\$1mapping)](wait-event.lwl-buffer-mapping.md) | このイベントは、セッションがデータブロックを共有バッファプール内のバッファに関連付けるのを待っているときに発生します。 |
| [LWLock:BufferIO (IPC:BufferIO)](wait-event.lwlockbufferio.md) | このイベントは、RDS for PostgreSQL が、ページへの同時アクセスを試みたときに、他のプロセスが入出力 (I/O) オペレーションを完了するのを待っているときに発生します。 |
| [LWLock:buffer\$1content (BufferContent)](wait-event.lwlockbuffercontent.md) | このイベントは、セッションがデータページのメモリ内への読み取りまたは書き込みのために待機中、そのデータページが他のセッションで書き込むためにロックされているときに発生します。 |
| [LWLock:lock\$1manager (LWLock:lockmanager)](wait-event.lw-lock-manager.md) | このイベントは、RDS for PostgreSQL エンジンが、高速パスロックが不可能な場合に共有ロックのメモリ領域を維持し、ロックの割り当て、チェック、および解放を行うときに発生します。 |
| [LWLock:SubtransSLRU (LWLock:SubtransControlLock)](wait-event.lwlocksubtransslru.md) | このイベントは、プロセスがサブトランザクションのシンプルな最も長い時間使われていない (SLRU) キャッシュへのアクセスを待機しているときに発生します。 |
| [Timeout:PgSleep](wait-event.timeoutpgsleep.md) | このイベントは、サーバープロセスが`pg_sleep`機能を呼び出し、スリープタイムアウトを待っているときに発生します。 |
| [Timeout:VacuumDelay](wait-event.timeoutvacuumdelay.md) | このイベントは、推定コスト制限に達したため、バキュームプロセスがスリープ状態になっていることを示しています。 |
# Client:ClientRead
`Client:ClientRead` イベントは、RDS for PostgreSQL がクライアントからのデータ受信を待っているときに発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.clientread.context.supported)
+ [
## Context
](#wait-event.clientread.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.clientread.causes)
+ [
## アクション
](#wait-event.clientread.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL バージョン 10 以降でサポートされています。
## Context
RDS for PostgreSQL DB インスタンスは、クライアントからのデータ受信を待っています。RDS for PostgreSQL DB インスタンスは、クライアントにさらにデータを送信する前に、クライアントからデータを受信する必要があります。インスタンスがクライアントからデータを受信する前に待機する時間が `Client:ClientRead` イベントとなります。
## 待機時間が増加する原因の可能性
`Client:ClientRead`上位待機中に表示されるイベントの一般的な原因には、次のものがあります。
**ネットワークレイテンシーの増加**
RDS for PostgreSQL DB インスタンスとクライアントの間のネットワークレイテンシーが増加することがあります。ネットワークレイテンシーが高いほど、DB インスタンスがクライアントからデータを受信するために必要な時間が長くなります。
**クライアントへの負荷の増大**
クライアント側で CPU プレッシャーまたはネットワーク飽和が発生している可能性があります。クライアント側の負荷が増加すると、クライアントから RDS for PostgreSQL DB インスタンスへのデータの転送が遅延する可能性があります。
**過剰なネットワークラウンドトリップ**
RDS for PostgreSQL DB インスタンスとクライアントの間のネットワークラウンドトリップが多くなると、クライアントから RDS for PostgreSQL DB インスタンスへのデータの転送が遅延する可能性があります。
**大規模なコピーオペレーション**
コピーオペレーション中、データはクライアントのファイルシステムから RDS for PostgreSQL DB インスタンスに転送されます。DB インスタンスに大量のデータを送信すると、クライアントから DB インスタンスへのデータの転送が遅延する可能性があります。
**アイドル状態のクライアントの接続**
クライアントが RDS for PostgreSQL DB インスタンスに `idle in transaction` 状態で接続している場合、DB インスタンスは、クライアントがより多くのデータを送信するのを待ったり、コマンドを発したりすることがあります。この状態での接続は、`Client:ClientRead`イベントの増加につながることがあります。
**接続プーリングに使用される pgBouncer**
pgBouncer には`pkt_buf`という低レベルネットワーク構成設定があり、デフォルトでは 4,096 に設定されています。ワークロードが 4,096 バイトを超えるクエリパケットを pgBouncer を介して 送信する場合は、`pkt_buf`8,192 に設定することをお勧めします。新しい設定で`Client:ClientRead`イベントの数が減らない場合は、`pkt_buf`を16,384 や 32,768 など、より大きな値に設定にすることをお勧めします。クエリテキストが大きい場合は、大きな設定を使用すると特に効果的です。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [
### クライアントをインスタンスと同じアベイラビリティーゾーンと VPC サブネットに配置します。
](#wait-event.clientread.actions.az-vpc-subnet)
+ [
### クライアントのスケーリング
](#wait-event.clientread.actions.scale-client)
+ [
### 現行世代のインスタンスを使用
](#wait-event.clientread.actions.db-instance-class)
+ [
### ネットワーク帯域幅の増加
](#wait-event.clientread.actions.increase-network-bandwidth)
+ [
### ネットワークパフォーマンスの最大値をモニタリングする
](#wait-event.clientread.actions.monitor-network-performance)
+ [
### 「トランザクションのアイドル」状態のトランザクションをモニタリングする
](#wait-event.clientread.actions.check-idle-in-transaction)
### クライアントをインスタンスと同じアベイラビリティーゾーンと VPC サブネットに配置します。
ネットワークレイテンシーを減らしてネットワークスループットを向上するには、RDS for PostgreSQL DB インスタンスと同じアベイラビリティーゾーンおよび仮想プライベートクラウド (VPC) サブネットにクライアントを配置します。クライアントが、DB インスタンスにできる限り地理的に近い場所に配置されていることを確認してください。
### クライアントのスケーリング
Amazon CloudWatch またはその他のホストメトリクスを使用して、クライアント側が現在 CPU またはネットワーク帯域幅、またはその両方によって制約を受けているかどうかを判断します。クライアント側が制約を受けている場合は、それに応じてクライアントをスケーリングします。
### 現行世代のインスタンスを使用
場合によっては、ジャンボフレームをサポートする DB インスタンスクラスを使用していない可能性があります。Amazon EC2 でアプリケーションを実行している場合は、クライアント側に現行世代のインスタンスを使用することを検討してください。また、クライアントのOSで最大送信単位 (MTU) を設定します。この技術では、ネットワークラウンドトリップの数を減らし、ネットワークスループットを向上させることができます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[ジャンボフレーム (9001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances)」を参照してください。
DB インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。Amazon EC2 インスタンスタイプと同等の DB インスタンスクラスを決定するには、`db.`Amazon EC2 インスタンスタイプの前に配置します。例えば、`r5.8xlarge`Amazon EC2 インスタンスは`db.r5.8xlarge`DB インスタンスクラスと同等です。
### ネットワーク帯域幅の増加
`NetworkReceiveThroughput` および `NetworkTransmitThroughput` の Amazon CloudWatch メトリクスを使用して、DB インスタンス上の着信および発信ネットワークトラフィックをモニタリングします。これらのメトリックは、ネットワーク帯域幅がワークロードに十分であるかどうかを判断するのに役立ちます。
ネットワーク帯域幅が十分でない場合は、増加してください。AWSクライアントまたは DB インスタンスがネットワーク帯域幅の制限に達している場合、帯域幅を増やす唯一の方法は、DB インスタンスのサイズを増加することことです。詳細については、「[DB インスタンスクラスタイプ](Concepts.DBInstanceClass.Types.md)」を参照してください。
CloudWatch のメトリクスの詳細については、「[Amazon RDS の Amazon CloudWatch メトリクス](rds-metrics.md)」を参照してください。
### ネットワークパフォーマンスの最大値をモニタリングする
Amazon EC2 クライアントを使用している場合、Amazon EC2 は、集約されたインバウンドとアウトバウンドのネットワーク帯域幅を含む、ネットワークパフォーマンスメトリックの最大値を提供します。また、パケットが期待どおりに返されることを確認する接続追跡、ドメインネームシステム (DNS) などのサービスへのリンクローカルサービスアクセスも提供します。これらの最大値をモニタリングするには、現在の拡張ネットワークドライバーを使用し、クライアントのネットワークパフォーマンスをモニタリングします。
詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスのネットワークパフォーマンスのモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html)」および「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスのネットワークパフォーマンスのモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/monitoring-network-performance-ena.html)」を参照してください。
### 「トランザクションのアイドル」状態のトランザクションをモニタリングする
`idle in transaction`接続の数が増えているかどうかをチェックします。これを行うには、`pg_stat_activity`テーブルの`state`列をモニタリングします。次のようなクエリを実行することで、接続出典を特定できる場合があります。
```
select client_addr, state, count(1) from pg_stat_activity
where state like 'idle in transaction%'
group by 1,2
order by 3 desc
```
# クライアント: ClientWrite
`Client:ClientWrite` イベントは、RDS for PostgreSQL がクライアントへのデータ書き込みを待っているときに発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.clientwrite.context.supported)
+ [
## Context
](#wait-event.clientwrite.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.clientwrite.causes)
+ [
## アクション
](#wait-event.clientwrite.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL バージョン 10 以降でサポートされています。
## Context
クライアントプロセスは、クラスターがさらにデータを送信する前に、RDS for PostgreSQL DB クラスターから受信したすべてのデータを読み込む必要があります。クライアントにより多くのデータを送信する前にクラスターが待機する時間は、`Client:ClientWrite`イベントになります。
RDS for PostgreSQL DB インスタンスとクライアント間のネットワークスループットが低下すると、このイベントが発生することがあります。クライアントの CPU プレッシャーとネットワークの飽和により、このイベントが発生することがあります。*CPU プレッシャー*とは、CPU が完全に使用されており、CPU 時間を待っているタスクがあることです。*ネットワーク飽和度*とは、データベースとクライアント間のネットワークが、処理できるデータ以上のデータを伝送しているときです。
## 待機時間が増加する原因の可能性
`Client:ClientWrite`上位待機中に表示されるイベントの一般的な原因には、次のものがあります。
**ネットワークレイテンシーの増加**
RDS for PostgreSQL DB インスタンスとクライアントの間のネットワークレイテンシーが増加することがあります。ネットワークレイテンシーが高いほど、クライアントからデータを受信するために必要な時間が長くなります。
**クライアント側への負荷の増加**
クライアント側で CPU プレッシャーまたはネットワーク飽和が発生している可能性があります。クライアントの負荷が増加すると、RDS for PostgreSQL DB インスタンスからのデータの受信が遅延します。
**クライアントに送信される大量のデータ**
RDS for PostgreSQL DB インスタンスがクライアントに大量のデータを送信している可能性があります。クライアントは、クラスターのデータ送信と同じ速度ではデータを受信できない場合があります。大きなテーブルのコピーなどのアクティビティは、`Client:ClientWrite`イベントの増加につながることがあります。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [
### クライアントをクラスターと同じアベイラビリティーゾーンと VPC サブネットに配置します。
](#wait-event.clientwrite.actions.az-vpc-subnet)
+ [
### 現行世代のインスタンスを使用
](#wait-event.clientwrite.actions.db-instance-class)
+ [
### クライアントに送信するデータ量を減らします。
](#wait-event.clientwrite.actions.reduce-data)
+ [
### クライアントのスケーリング
](#wait-event.clientwrite.actions.scale-client)
### クライアントをクラスターと同じアベイラビリティーゾーンと VPC サブネットに配置します。
ネットワークレイテンシーを減らしてネットワークスループットを向上するには、RDS for PostgreSQL DB インスタンスと同じアベイラビリティーゾーンおよび仮想プライベートクラウド (VPC) サブネットにクライアントを配置します。
### 現行世代のインスタンスを使用
場合によっては、ジャンボフレームをサポートする DB インスタンスクラスを使用していない可能性があります。Amazon EC2 でアプリケーションを実行している場合は、クライアント側に現行世代のインスタンスを使用することを検討してください。また、クライアントのOSで最大送信単位 (MTU) を設定します。この技術では、ネットワークラウンドトリップの数を減らし、ネットワークスループットを向上させることができます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[ジャンボフレーム (9001 MTU)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances)」を参照してください。
DB インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。Amazon EC2 インスタンスタイプと同等の DB インスタンスクラスを決定するには、`db.`Amazon EC2 インスタンスタイプの前に配置します。例えば、`r5.8xlarge`Amazon EC2 インスタンスは`db.r5.8xlarge`DB インスタンスクラスと同等です。
### クライアントに送信するデータ量を減らします。
可能であれば、RDS for PostgreSQL DB インスタンスがクライアントに送信するデータ量を減らすようにアプリケーションを調整します。このような調整を行うと、クライアントの CPU やネットワークの競合を軽減します。
### クライアントのスケーリング
Amazon CloudWatch またはその他のホストメトリクスを使用して、クライアント側が現在 CPU またはネットワーク帯域幅、またはその両方によって制約を受けているかどうかを判断します。クライアント側が制約を受けている場合は、それに応じてクライアントをスケーリングします。
# CPU
この待機イベントは、スレッドが CPU でアクティブであるか CPU の待機中に発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.cpu.context.supported)
+ [
## Context
](#wait-event.cpu.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.cpu.causes)
+ [
## アクション
](#wait-event.cpu.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、すべての RDS for PostgreSQL のすべてのバージョンに関連しています。
## Context
*中央処理装置 (CPU)*は、命令を実行するコンピュータのコンポーネントです。例えば、CPU 命令は演算処理を実行し、メモリ上でデータを交換します。クエリがデータベースエンジンを介して実行する命令の数が増えると、クエリの実行にかかる時間が長くなります。*CPU スケジューリング*は、CPU にプロセス時間を与えています。スケジューリングは、OS のカーネルによってオーケストレーションされます。
**Topics**
+ [
### この待機の発生時期を確認する方法
](#wait-event.cpu.when-it-occurs)
+ [
### DbLoadCPU メトリクス
](#wait-event.cpu.context.dbloadcpu)
+ [
### os.cpuUtilization メトリック
](#wait-event.cpu.context.osmetrics)
+ [
### CPU スケジューリングの原因の可能性
](#wait-event.cpu.context.scheduling)
### この待機の発生時期を確認する方法
この`CPU`待機イベントは、バックエンドプロセスが CPU でアクティブであるか、CPU を待っていることを示します。クエリに次の情報が表示されると、発生していることがわかります。
+ 「`pg_stat_activity.state`」 列には値`active`があります。
+ `pg_stat_activity`の`wait_event_type`および`wait_event`の列は、両方とも`null`です。
CPU を使用中または待機中のバックエンドプロセスを確認するには、次のクエリを実行します。
```
SELECT *
FROM pg_stat_activity
WHERE state = 'active'
AND wait_event_type IS NULL
AND wait_event IS NULL;
```
### DbLoadCPU メトリクス
CPU の Performance Insights のメトリクスは `DBLoadCPU` です。`DBLoadCPU`の値は、Amazon CloudWatch メトリクスの値とは異なる場合があります`CPUUtilization`。後者のメトリクスは、データベースインスタンスのハイパーバイザーから収集されます。
### os.cpuUtilization メトリック
Performance Insights OS のメトリクスは、CPU 使用率に関する詳細情報を提供します。例えば、次のメトリクスを表示できます。
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Performance Insights は、データベースエンジンによる CPU 使用率を`os.cpuUtilization.nice.avg`のように報告します。
### CPU スケジューリングの原因の可能性
オペレーティングシステム (OS) カーネルは、CPU のスケジューリングを処理します。CPU が*アクティブ*な場合、プロセスがスケジューリングされるのを待機する必要がある場合があります。計算の実行中は、CPU はアクティブです。また、実行されていないアイドルスレッド、つまりメモリ I/O の待機中もアクティブになります。このタイプの I/O は、一般的なデータベースワークロードの大部分を占めています。
以下の条件が満たされると、プロセスは CPU でスケジュールされるのを待機する可能性があります。
+ CloudWatch`CPUUtilization`メトリクスは 100% に近いです。
+ 平均ロードは vCPUs の数よりも大きく、ロードが重いことを示しています。このメトリクスは、`loadAverageMinute`Performance Insights の OS メトリクスセクションで見ることができます。
## 待機時間が増加する原因の可能性
CPU 待機イベントが通常よりも頻繁に発生する場合は、パフォーマンスの問題を示している可能性があり、典型的な原因は次のとおりです。
**Topics**
+ [
### 突然のスパイクの原因の可能性
](#wait-event.cpu.causes.spikes)
+ [
### 長期の高周波の原因の可能性
](#wait-event.cpu.causes.long-term)
+ [
### コーナーケース
](#wait-event.cpu.causes.corner-cases)
### 突然のスパイクの原因の可能性
突然のスパイクの原因として最も可能性の高いものは次のとおりです。
+ アプリケーションがデータベースへの同時接続を開きすぎています。このシナリオは「接続ストーム」と呼ばれます。
+ アプリケーションのワークロードは、次のいずれかの方法で変更されました。
+ 新しいクエリ
+ データセットのサイズの増加
+ インデックスのメンテナンスまたは作成
+ 新しい関数
+ 新しいオペレーター
+ パラレルクエリ実行の増加
+ クエリ実行プランが変更されました。場合によっては、変更によってバッファが増加することがあります。例えば、以前はインデックスを使用していたクエリが、現在はシーケンシャルスキャンを使用します。この場合、同じ目標を達成するには、クエリがより多くの CPU を必要とします。
### 長期の高周波の原因の可能性
長期間にわたって再発するイベントの原因として最も可能性の高いもの:
+ CPU で同時に実行されているバックエンドプロセスが多すぎます。これらのプロセスは、パラレルワーカーにすることができます。
+ クエリのパフォーマンスは、大量のバッファを必要とするため最適ではありません。
### コーナーケース
考えられる原因のいずれも実際の原因ではない場合は、以下のような状況が発生することがあります。
+ CPU がプロセスを入れ替えています。
+ *huge pages* 機能が無効になっていると、CPU がページテーブルエントリを管理している可能性があります。このメモリ管理機能は、micro、small、medium 以外のすべての DB インスタンスクラスで、デフォルトでオンになっています。詳細については、「[RDS for PostgreSQL の ヒュージページ](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md)」を参照してください。
## アクション
`CPU` 待機イベントがデータベースアクティビティを占領している場合でも、必ずしもパフォーマンスの問題を示すわけではありません。パフォーマンスが低下した場合にのみ、このイベントに応答します。
**Topics**
+ [
### データベースが CPU の増加原因かどうかを調べる
](#wait-event.cpu.actions.db-CPU)
+ [
### 接続数が増加したかどうかを判断する
](#wait-event.cpu.actions.connections)
+ [
### ワークロードの変更に対応
](#wait-event.cpu.actions.workload)
### データベースが CPU の増加原因かどうかを調べる
`os.cpuUtilization.nice.avg`Performance Insights のメトリクスを検証します。この値が CPU 使用率よりはるかに小さい場合、データベース以外のプロセスが CPU の主な原因となっています。
### 接続数が増加したかどうかを判断する
`DatabaseConnections`Amazon CloudWatch のメトリクスを検証します。アクションは、CPU の待機イベントが増加した期間中の数値の増減によって異なります。
#### 接続数が増加した
接続数が増えた場合は、CPU を消費しているバックエンドプロセスの数と vCPUs の数を比較します。以下のシナリオが考えられます。
+ CPU を消費するバックエンドプロセスの数が、vCPUs の数より少なくなっています。
この場合、接続数は問題ではありません。ただし、それでも CPU 使用率を下げようとすることがあります。
+ CPU を消費するバックエンドプロセスの数が vCPUs の数を超えています。
このような場合は、以下のオプションを検討します。
+ データベースに接続されているバックエンドプロセスの数を減らします。例えば、RDS Proxy などの接続プーリングソリューションを実装します。詳細については[Amazon RDS Proxy ](rds-proxy.md)を参照してください。
+ インスタンスサイズをアップグレードして vCPUs の数を増やします。
+ 一部の読み取り専用ワークロードをリーダーノードにリダイレクトします (該当する場合)。
#### 接続は増加しなかった
`blks_hit`Performance Insights のメトリクスを検証します。`blks_hit`と CPU 使用率の増加の相関関係を探してください。以下のシナリオが考えられます。
+ CPU 使用率と`blks_hit`が相関しています。
この場合、CPU 使用率にリンクされている上位 SQL ステートメントを検索し、プランの変更を検討します。以下のいずれかの対策を使用できます。
+ 計画をマニュアルで説明し、予想される実行プランと比較します。
+ 秒単位のブロックヒット数とローカルブロックヒット数の増加を確認します。Performance Insights ダッシュボードの**上位 SQL**セクションで、**Preferences (設定) **を選択します。
+ CPU 使用率と`blks_hit`には相関関係がありません。
このような場合は、次のいずれかに該当するかどうかを判断します。
+ アプリケーションは、データベースとの接続と切断を高速で行っています。
`log_connections`および`log_disconnections`をオンにして、PostgreSQL のログを分析します。`pgbadger`ログアナライザの使用を検討します。詳細については、「[https://github.com/darold/pgbadger](https://github.com/darold/pgbadger)」を参照してください。
+ OS はオーバーロード状態です。
この場合、Performance Insights は、バックエンドプロセスが通常よりも長い時間 CPU を消費していることを示しています。Performance Insights の`os.cpuUtilization`メトリクスサイトまたは`CPUUtilization`CloudWatch のメトリクスでエビデンスを探します。OS がオーバーロード状態になっている場合は、拡張モニタリングのメトリックを参照してさらに診断します。具体的には、プロセスリストと各プロセスが消費する CPU の割合を確認します。
+ 上位 SQL ステートメントが消費する CPU が多すぎます。
CPU 使用率とリンクするステートメントを検証し、CPU の使用率を減らせるかどうかを確認します。`EXPLAIN`コマンドを実行し、最も影響が大きいプランノードにフォーカスします。PostgreSQL の実行計画ビジュアライザーの使用を検討してください。このツールを試すには、[http://explain.dalibo.com/](http://explain.dalibo.com/)を参照してください。
### ワークロードの変更に対応
ワークロードが変更された場合は、次のタイプの変更を探します。
新しいクエリ
新しいクエリが想定されているかどうかを確認します。その場合は、その実行計画と秒単位の実行数が想定されていることを確認してください。
データセットのサイズの増加
パーティショニングが未実装の場合は、それが役立つかどうかを判断します。この戦略では、クエリで取得する必要があるページ数を減らすことができます。
インデックスのメンテナンスまたは作成
メンテナンスのスケジュールが想定されているかどうかを確認します。ベストプラクティスは、ピークアクティビティ以外のメンテナンスアクティビティをスケジュールすることです。
新しい関数
これらの機能がテスト中に想定したとおりに動作するかどうかを確認します。具体的には、秒単位の実行数が想定されているかどうかを確認します。
新しいオペレーター
テスト中に想定どおりに動作するかどうかを確認します。
パラレルクエリの実行の増加
以下のいずれかの状況が発生するかどうかを確認します。
+ 関連する関係やインデックスのサイズが突然大きくなり、`min_parallel_table_scan_size`または`min_parallel_index_scan_size`は大きく異なるようになりました。
+ 「`parallel_setup_cost`または`parallel_tuple_cost`」に最近変更が加えられました。
+ 「`max_parallel_workers`または`max_parallel_workers_per_gather`」に最近変更が加えられました。
# IO:BufFileRead および IO:BufFileWrite
`IO:BufFileRead` と `IO:BufFileWrite` イベントは、RDS for PostgreSQL がテンポラリファイルを作成するときに発生します。作業メモリパラメータが現在の定義より多くのメモリを必要とするオペレーションは、テンポラリデータを永続的ストレージに書き込みます。この操作は「*spilling to disk (ディスクへの流出)*」と呼ばれることがあります。一時ファイルとその使用方法の詳細については、「[PostgreSQL による一時ファイルの管理](PostgreSQL.ManagingTempFiles.md)」を参照してください。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.iobuffile.context.supported)
+ [
## Context
](#wait-event.iobuffile.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.iobuffile.causes)
+ [
## アクション
](#wait-event.iobuffile.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
`IO:BufFileRead`そして`IO:BufFileWrite`は、作業メモリ領域とメンテナンス作業用メモリ領域に関連します。これらのローカルメモリ領域の詳細については、PostgreSQL ドキュメントの「[リソース消費](https://www.postgresql.org/docs/current/runtime-config-resource.html)」を参照してください。
デフォルト値は `work_mem` 4 MB です。一つのセッションがパラレルにオペレーションを実行する場合、パラレル処理を行う各ワーカーは 4 MB のメモリを使用します。このため、`work_mem`を慎重に設定してください。値を大きくしすぎると、多くのセッションを実行しているデータベースがメモリを過剰に消費することがあります。値を低く設定しすぎると、RDS for PostgreSQL はローカルストレージに一時ファイルを作成します。これらのテンポラリファイルのためのディスク I/O により、パフォーマンスが低下する可能性があります。
次のようなイベントが発生する場合、データベースがテンポラリファイルを生成している可能性があります。
1. 可用性の急激な低下
1. 空き領域の高速リカバリ
また、「チェーンソー」のパターンが表示されるかもしれません。このパターンは、データベースが小さなファイルを常に作成していることを示す可能性があります。
## 待機時間が増加する原因の可能性
一般に、これらの待機イベントは、`work_mem`または`maintenance_work_mem`パラメータが割り当てられるよりも多くのメモリを消費するオペレーションによって発生します。補うために、オペレーションはテンポラリファイルに書き込みます。`IO:BufFileRead`そして`IO:BufFileWrite`イベントの一般的な原因には、次のようなものがあります。
**作業用メモリ領域に存在するメモリより多くのメモリを必要とするクエリ**
次の特性を持つクエリは、作業メモリ領域を使用します。
+ ハッシュ結合
+ `ORDER BY` 句
+ `GROUP BY` 句
+ `DISTINCT`
+ ウィンドウ関数
+ `CREATE TABLE AS SELECT`
+ REFRESH MATERIALIZED VIEW
**メンテナンス作業メモリ領域に存在するメモリより多くのメモリを必要とするステートメント**
次のステートメントは、メンテナンス作業メモリ領域を使用します。
+ `CREATE INDEX`
+ `CLUSTER`
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [
### 問題の特定
](#wait-event.iobuffile.actions.problem)
+ [
### ジョイントクエリを検証する
](#wait-event.iobuffile.actions.joins)
+ [
### ORDER BY クエリと GROUP BY クエリを検証する
](#wait-event.iobuffile.actions.order-by)
+ [
### DISTINCT オペレーションの使用を避ける
](#wait-event.iobuffile.actions.distinct)
+ [
### GROUP BY 関数の代わりにウィンドウ関数の使用を検討してください。
](#wait-event.iobuffile.actions.window)
+ [
### マテリアライズドビューと CTAS ステートメントの調査
](#wait-event.iobuffile.actions.mv-refresh)
+ [
### インデックスの再構築時に pg\$1repack を使用する
](#wait-event.iobuffile.actions.pg_repack)
+ [
### テーブルをクラスター化するときに maintenance\$1work\$1mem を増やす
](#wait-event.iobuffile.actions.cluster)
+ [
### IO:BufFileRead および IO:BufFileWrite を防ぐためにメモリを調整します
](#wait-event.iobuffile.actions.tuning-memory)
### 問題の特定
一時ファイルの使用状況は、Performance Insights で直接表示できます。詳細については、「[Performance Insights を使用した一時ファイルの使用状況の確認](PostgreSQL.ManagingTempFiles.Example.md)」を参照してください。Performance Insights を無効にすると、`IO:BufFileRead` および `IO:BufFileWrite` オペレーションが増加することがあります。
問題の原因を特定するには、指定したしきい値 KB を超える一時ファイルを生成するすべてのクエリをログに記録するように `log_temp_files` パラメータを設定できます。デフォルトでは、`log_temp_files` は `-1` に設定され、このロギング機能は無効になります。このパラメータを `0` に設定した場合は、RDS for PostgreSQL はすべての一時ファイルをログに記録します。値を `1024` に設定した場合、RDS for PostgreSQL は 1 MB を超える一時ファイルを生成するすべてのクエリをログに記録します。`log_temp_files`についての詳細は、PostgreSQL ドキュメントの[Error reporting and logging](https://www.postgresql.org/docs/current/runtime-config-logging.html) を参照してください。
### ジョイントクエリを検証する
クエリでは、結合が使用されている可能性があります。例えば、次のクエリは 4 つのテーブルをジョイントします。
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = order.customer_id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
テンポラリファイル使用量が急増する原因は、クエリ自体の問題の可能性があります。例えば、壊れた節はジョイントを適切にフィルタリングしない可能性があります。次の例では 2 番目の内部ジョイントを考えてみましょう。
```
SELECT *
FROM "order"
INNER JOIN order_item
ON (order.id = order_item.order_id)
INNER JOIN customer
ON (customer.id = customer.id)
INNER JOIN customer_address
ON (customer_address.customer_id = customer.id AND
order.customer_address_id = customer_address.id)
WHERE customer.id = 1234567890;
```
前のクエリが誤って`customer.id`を`customer.id`にジョイントし、すべての顧客とすべての注文の間にデカルト積を生成します。このタイプの偶発的なジョイントは、大きなテンポラリファイルを生成します。テーブルのサイズによっては、デカルトクエリでストレージがいっぱいになることもあります。以下の条件を満たす場合は、アプリケーションにデカルトジョインが生成される場合があります。
+ ストレージの可用性が大きく急激に低下し、その後、高速リカバリが起こります。
+ インデックスは作成されていません。
+ `CREATE TABLE FROM SELECT`ステートメントは発行されていません。
+ マテリアライズドビューはリフレッシュされません。
テーブルが適切なキーを使用してジョイントされているかどうかを確認するには、クエリおよびオブジェクト関係マッピングディレクティブを調べます。アプリケーションの特定のクエリは常に呼び出されるわけではなく、一部のクエリは動的に生成されることに注意してください。
### ORDER BY クエリと GROUP BY クエリを検証する
場合によっては、`ORDER BY`節を使用するとテンポラリファイルが過剰になる可能性があります。以下のガイドラインを検討します。
+ 順序付けが必要な場合のみ、`ORDER BY`に列を含めてください。このガイドラインは、数千行を返し、`ORDER BY`節で多数の列を指定するクエリでは特に重要です。
+ `ORDER BY`節が同じ昇順または降順の列にマッチする場合、高速化するためにインデックスの作成を検討します。パーシャルインデックスのほうが小さいため好ましいです。小さいインデックスは、より迅速に読み込まれ、トラバースされます。
+ NULL 値を受け入れることができる列のインデックスを作成する場合は、NULL 値をインデックスの最後に格納するか、先頭に格納するかを検討します。
可能であれば、結果セットをフィルタリングして、順序付けが必要な行の数を減らします。`WITH`節ステートメントまたはサブクエリを使用する場合、内部クエリが結果セットを生成し、外部クエリに渡すことに注意してください。クエリが行をより多くフィルタリングすると、クエリが行う必要がある順序付けは減ります。
+ 完全な結果セットを取得する必要がない場合は、`LIMIT`節を使用します。例えば、上位 5 行だけが必要な場合、`LIMIT`節を使用したクエリは結果を生成し続けることはありません。このように、クエリに必要なメモリとテンポラリファイルが減ります。
`GROUP BY` 句を使用するクエリは、テンポラリファイルを要求することもできます。`GROUP BY` クエリは、次のような関数を使用して値を要約します。
+ `COUNT`
+ `AVG`
+ `MIN`
+ `MAX`
+ `SUM`
+ `STDDEV`
`GROUP BY`クエリをチューニングするには、`ORDER BY`クエリの推奨事項に従ってください。
### DISTINCT オペレーションの使用を避ける
可能であれば、`DISTINCT`オペレーションを使用して重複した行を削除することは避けてください。クエリが返す行が不要かつ重複していればいるほど、V`DISTINCT`オペレーションのコストは高くなります。可能であれば、異なるテーブルに対して同じフィルターを使用している場合でも、`WHERE`節でフィルターを追加してください。クエリをフィルタリングして正しく結合すると、パフォーマンスが向上し、リソースの使用量が削減されます。また、誤ったレポートや結果を防ぐことができます。
`DISTINCT`を同じテーブルの複数の行に使用する必要がある場合、複合インデックスの作成を検討してください。インデックスに複数の列をグループ化すると、個別の行を評価する時間を短縮できます。また、RDS for PostgreSQL バージョン 10 以降を使用している場合は、`CREATE STATISTICS` コマンドを使用して複数の列間で統計を関連付けられます。
### GROUP BY 関数の代わりにウィンドウ関数の使用を検討してください。
`GROUP BY`を使用すると、結果セットを変更し、集計結果を取得できます。ウィンドウ関数を使用すると、結果セットを変更せずにデータを集計できます。ウィンドウ関数は、`OVER`句を使用して、クエリによって定義されたセット間で計算を実行し、ある行を別の行に関連付けます。ウィンドウ関数に含まれるすべての`GROUP BY`関数は使用できますが、次のような関数も使用可能です。
+ `RANK`
+ `ARRAY_AGG`
+ `ROW_NUMBER`
+ `LAG`
+ `LEAD`
ウィンドウ関数によって生成されるテンポラリファイルの数を最小限に抑えるには、2 つの異なる集計が必要な場合は同じ結果セットの重複を削除してください。次のクエリについて考えます。
```
SELECT sum(salary) OVER (PARTITION BY dept ORDER BY salary DESC) as sum_salary
, avg(salary) OVER (PARTITION BY dept ORDER BY salary ASC) as avg_salary
FROM empsalary;
```
`WINDOW`節のクエリは、次のように書き換えることができます。
```
SELECT sum(salary) OVER w as sum_salary
, avg(salary) OVER w as_avg_salary
FROM empsalary
WINDOW w AS (PARTITION BY dept ORDER BY salary DESC);
```
デフォルトでは、RDS for PostgreSQL 実行プランナーは類似したノードを統合し、オペレーションが重複しないようにします。ただし、ウィンドウブロックに明示的な宣言を使用すると、クエリをより簡単に維持できます。また、重複を防止するとパフォーマンスの向上につながることがあります。
### マテリアライズドビューと CTAS ステートメントの調査
マテリアライズドビューがリフレッシュされると、クエリが実行されます。このクエリには、`GROUP BY`、`ORDER BY`、`DISTINCT`のような操作を含めることができます。リフレッシュ中に、大量のテンポラリファイルや待機イベント`IO:BufFileWrite`および`IO:BufFileRead`が発生することがあります。同様に、`SELECT`に基づいてテーブルを作成すると、`CREATE TABLE`ステートメントはクエリを実行します。必要なテンポラリファイルを減らすには、クエリを最適化します。
### インデックスの再構築時に pg\$1repack を使用する
インデックスを作成すると、エンジンは結果セットを順序付けます。テーブルのサイズが大きくなり、インデックスで指定された列の値が多様化していくと、テンポラリファイルはより多くの領域を必要とします。ほとんどの場合、メンテナンス作業のメモリ領域を変更しなければ、大きなテーブルのテンポラリファイルの作成を防ぐことはできません。`maintenance_work_mem` の詳細については、PostgreSQL のドキュメントの「[https://www.postgresql.org/docs/current/runtime-config-resource.html](https://www.postgresql.org/docs/current/runtime-config-resource.html)」を参照してください。
大きなインデックスを再作成するときに考えられる回避策としては、pg\$1repack 拡張機能を使用することが挙げられます。詳細については、「pg\$1repack のドキュメント」で「[最小限のロックで PostgreSQL データベース内のテーブルを再編成する](https://reorg.github.io/pg_repack/)」を参照してください。RDS for PostgreSQL DB インスタンスに対する拡張機能の設定については、「[pg\$1repack 拡張機能を使用して、テーブルやインデックスの膨張を抑制する](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md)」を参照してください。
### テーブルをクラスター化するときに maintenance\$1work\$1mem を増やす
`CLUSTER`コマンドは、*index\$1name*で指定した既存のインデックスに基づいて、*table\$1name*で指定したテーブルをクラスター化します。RDS for PostgreSQL は、指定されたインデックスの順序に一致するようにテーブルを物理的に再作成します。
磁気ストレージが普及していたころは、ストレージのスループットが限られていたため、クラスター化が一般的でした。今では、SSD ベースのストレージが一般的となり、クラスター化はあまり一般的ではなくなっています。ただし、テーブルをクラスター化すると、テーブルのサイズ、インデックス、クエリなどによってパフォーマンスが多少向上することがあります。
`CLUSTER`コマンドを実行して、待機イベント`IO:BufFileWrite`、`IO:BufFileRead`をモニタリングし、`maintenance_work_mem`をチューニングします。メモリサイズをかなり大きくしてください。高い値は、エンジンがクラスター化オペレーションのためにより多くのメモリを使用できることを意味します。
### IO:BufFileRead および IO:BufFileWrite を防ぐためにメモリを調整します
状況によっては、メモリのチューニングが必要です。以下のような適切なパラメータを使用して、消費領域にわたってメモリのバランスを取ることが目的です。
+ `work_mem` 値。
+ `shared_buffers` を割り引いた後の残りのメモリ
+ `max_connections`で制限されるオープンおよび使用中の最大接続数
これらのメモリのチューニングの詳細については、PostgreSQL ドキュメントの「[リソース消費](https://www.postgresql.org/docs/current/runtime-config-resource.html)」を参照してください。
#### 作業メモリ領域のサイズを拡大する
状況によっては、セッションで使用されるメモリを増やすことが唯一の選択肢となることもあります。クエリが正しく記述され、ジョイントに正しいキーを使用している場合は、`work_mem`値の増加を検討してください。
クエリが生成するテンポラリファイルの数を調べるには、`log_temp_files` を `0` に設定します。`work_mem` 値をログで識別される最大値まで上げると、クエリでテンポラリファイルが生成されるのを防ぎます。ただし、`work_mem`は各接続またはパラレルワーカーにプランノードあたりの最大値を設定します。データベースに 5,000 の接続があり、それぞれが 256 MiB のメモリを使用する場合、エンジンは 1.2 TiB の RAM を必要とします。そのため、インスタンスのメモリが不足する可能性があります。
#### 共有バッファプールに十分なメモリを予約する
データベースでは、作業用メモリ領域だけでなく、共有バッファプールなどのメモリ領域が使用されます。`work_mem`を増加する前に、これらの追加メモリ領域の要件を考慮してください。
例えば、RDS for PostgreSQL インスタンスクラスが db.r5.2xlarge であると仮定します。このクラスには 64 GiB のメモリがあります。デフォルトでは、メモリの 25% が共有バッファプール用に予約されています。共有メモリ領域に割り当てられた量を引くと、16,384 MB が残ります。OS やエンジンもメモリを必要とするため、残りのメモリを作業メモリ領域にのみ割り当てないでください。
`work_mem`に割り当て可能なメモリはインスタンスクラスによって異なります。より大きなインスタンスクラスを使用すると、より多くのメモリが使用できます。ただし、前の例では 16 GiB 以上は使用できません。そうでなければ、メモリ不足に陥ったときにインスタンスが使用できなくなります。インスタンスを利用できない状態から回復するには、RDS for PostgreSQL オートメーションサービスが自動的に再起動します。
#### 接続の数を管理する
データベースインスタンスでの同時接続が 5,000 とします。各接続では、`work_mem`のうち少なくとも 4 MiB を使用します。接続に必要なメモリ消費量が多いと、パフォーマンスが低下する可能性があります。これに対して、次のオプションがあります。
+ より大きなインスタンスクラスにアップグレードします。
+ 接続プロキシまたはプーラーを使用することで、データベースの同時接続の数を減らします。
プロキシの場合は、アプリケーションに基づいて Amazon RDS プロキシ、pgBouncer、または接続プーラーを検討してください。この解決策は CPU ロードを軽減します。また、すべての接続が作業メモリ領域を必要とする場合のリスクも軽減します。データベース接続数が少ない場合は、`work_mem`の値を増やすことができます。このように、`IO:BufFileRead`そして`IO:BufFileWrite`待機イベントの発生を減らします。また、作業メモリ領域で待っているクエリが大幅に高速化します。
# IO:DataFileRead
`IO:DataFileRead`イベントは、バックエンドプロセスが必要なページを読み込む際に、ページが共有メモリで使用できないため接続が待機したときに発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.iodatafileread.context.supported)
+ [
## Context
](#wait-event.iodatafileread.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.iodatafileread.causes)
+ [
## アクション
](#wait-event.iodatafileread.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
すべてのクエリおよびデータ操作 (DML) オペレーションは、バッファプール内のページにアクセスします。読み取りを誘発できるステートメントには、`SELECT`、`UPDATE`、`DELETE`があります。例えば、`UPDATE`は、テーブルまたはインデックスからページを読み取ることができます。要求または更新中のページが共有バッファプールにない場合、この読み取りは`IO:DataFileRead`イベントにつながることがあります。
共有バッファプールは有限のため、いっぱいになる可能性があります。この場合、メモリ上にないページをリクエストすると、データベースは強制的にディスクからブロックを読み取ることになります。`IO:DataFileRead`イベントが頻繁に発生する場合は、共有バッファプールが小さすぎるとワークロードに対応できない可能性があります。この問題は、バッファプールに収まらない多数の行読み取る`SELECT`クエリでは深刻です。バッファプールの詳細については、PostgreSQL ドキュメントの「[リソース消費](https://www.postgresql.org/docs/current/runtime-config-resource.html)」を参照してください。
## 待機時間が増加する原因の可能性
`IO:DataFileRead`イベントの一般的な原因は以下のとおりです。
**接続スパイク**
複数の接続で同じ数の IO:DataFileRead 待機イベントが発生することがあります。この場合、スパイク (突然大きく増加) が `IO:DataFileRead` イベントで発生する可能性があります。
**シーケンシャルスキャンを実行する SELECT および DML ステートメント**
アプリケーションが新しいオペレーションを実行している可能性があります。または、新しい実行計画のために既存の操作がオペレーションされる可能性があります。このような場合は、`seq_scan`値より大きいテーブル (特に大きなテーブル) を探します。`pg_stat_user_tables`クエリでそれらを探してください。より多くの読み取りオペレーションを生成しているクエリを追跡するには、エクステンション`pg_stat_statements`を使用します。
**大規模なデータセットの CTAS および CREATE INDEX**
*CTAS*は`CREATE TABLE AS SELECT`ステートメントです。大規模なデータセットを出典として使用して CTAS を実行する場合、または大きなテーブルにインデックスを作成する場合は、`IO:DataFileRead`イベントが発生する可能性があります。インデックスを作成するとき、データベースはシーケンシャルスキャンを使用してオブジェクト全体を読み取る必要があります。CTAS は、ページがメモリ上にないときに`IO:DataFile`リードを生成します。
**複数のバキュームワーカーが同時に実行されている**
バキュームワーカーは、マニュアルまたは自動でトリガーできます。積極的なバキューム戦略の採用をお勧めします。ただし、テーブルに多数の更新または削除された行がある場合、`IO:DataFileRead`待機が増加します。スペース確保後、`IO:DataFileRead`に費やすバキューム時間が減少します。
**大量データの取り込み**
アプリケーションで大量のデータを取り込むと、`ANALYZE`オペレーションが頻繁に発生する可能性があります。`ANALYZE`プロセスは、オートバキュームランチャーによって、あるいはマニュアルでトリガーすることができます。
`ANALYZE`オペレーションは、テーブルのサブセットを読み取ります。30 に`default_statistics_target`値を掛けたものがスキャンを要するページ数です。詳細については、[PostgreSQL ドキュメント](https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET)をご参照ください。`default_statistics_target`パラメータは 1～10,000 の範囲の値を指定でき、デフォルトは 100 です。
**リソースの枯渇**
インスタンスのネットワーク帯域幅や CPU が消費されると、`IO:DataFileRead`イベントはより頻繁に発生する可能性があります。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [
### 待機を生成するクエリの述語フィルターをチェックする
](#wait-event.iodatafileread.actions.filters)
+ [
### メンテナンス作業の影響を最小化する
](#wait-event.iodatafileread.actions.maintenance)
+ [
### 多数の接続に対応する
](#wait-event.iodatafileread.actions.connections)
### 待機を生成するクエリの述語フィルターをチェックする
`IO:DataFileRead`待機イベントを生成する特定のクエリを特定するとします。これらは、次の方法を使用して識別できることがあります。
+ Performance Insights
+ エクステンション`pg_stat_statements`で提供されるようなカタログビュー
+ カタログビュー`pg_stat_all_tables`で、定期的な物理読み取り回数の増加を示す場合
+ `pg_statio_all_tables`ビューで、`_read`カウンターの増加が示されている場合
これらのクエリの述語 (`WHERE` 節) でどのフィルターが使用されるかを決定することをお勧めします。次のガイドラインに従ってください:
+ `EXPLAIN` コマンドを実行します。出力では、使用されているスキャンのタイプを特定します。シーケンシャルスキャンは必ずしも問題を示すわけではありません。シーケンシャルスキャンを使用するクエリは、フィルターを使用するクエリと比較して、自然により多くの`IO:DataFileRead`イベントを生成します。
`WHERE`節に記載された列がインデックスされているかどうかを確認します。されていない場合、この列のインデックスの作成を検討してください。この方法では、シーケンシャルスキャンを回避し、`IO:DataFileRead`イベントの発生を減らすことができます。制限付きフィルターがあってもシーケンシャルスキャンが実行される場合は、適切なインデックスが使用されているかどうかを評価します。
+ クエリが非常に大きなテーブルにアクセスしているかどうかを確認します。場合によっては、テーブルをパーティション化するとクエリで必要なパーティションのみを読み取ることができ、パフォーマンスが向上することがあります。
+ ジョイント操作からカーディナリティ (行の合計数) を検証します。フィルターに渡す`WHERE`節の値がどれほど制限的であるかに注意してください。可能であれば、クエリをチューニングして、計画の各ステップで渡される行数を減らします。
### メンテナンス作業の影響を最小化する
`VACUUM`や`ANALYZE`のようなメンテナンスオペレーションは重要です。これらのメンテナンス作業に関連する`IO:DataFileRead`待機イベントを見つけても、それらをオフにしないことをお勧めします。次のようなアプローチにより、これらの操作の影響を最小限に抑えることができます。
+ オフピーク時にメンテナンス操作をマニュアルで実行します。この方法では、データベースが自動操作のしきい値に達するのを防ぎます。
+ 非常に大きなテーブルの場合は、テーブルのパーティション化を検討してください。この方法により、メンテナンスオペレーションのオーバーヘッドが削減されます。データベースは、メンテナンスが必要なパーティションにのみアクセスします。
+ 大量のデータを取り込む場合は、自動分析機能を無効にすることを検討してください。
オートバキューム機能は、次の数式が真の場合、テーブルに対して自動的にトリガーされます。
```
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
```
ビュー`pg_stat_user_tables`とカタログ`pg_class`には複数の行があります。1 行は、テーブル内の 1 つの行に対応できます。この公式は、`reltuples`が特定のテーブル用だと仮定しています。パラメータ `autovacuum_vacuum_scale_factor` (デフォルトは 0.20) と `autovacuum_vacuum_threshold` (デフォルトでは 50 タプル) は通常、インスタンス全体に対してグローバルに設定されます。ただし、特定のテーブルに対して異なる値を設定できます。
**Topics**
+ [
#### 不要な領域を消費しているテーブルを探す
](#wait-event.iodatafileread.actions.maintenance.tables)
+ [
#### 不要な領域を消費しているインデックスを探す
](#wait-event.iodatafileread.actions.maintenance.indexes)
+ [
#### オートバキュームの対象となるテーブルを見つける
](#wait-event.iodatafileread.actions.maintenance.autovacuumed)
#### 不要な領域を消費しているテーブルを探す
不必要に領域を消費しているテーブルを探すには、PostgreSQL `pgstattuple` 拡張機能の関数を使用できます。この拡張機能 (モジュール) は、すべての RDS for PostgreSQL DB インスタンスにデフォルトで使用でき、次のコマンドを使用してインスタンス化できます。
```
CREATE EXTENSION pgstattuple;
```
この拡張機能の詳細については、PostgreSQL ドキュメントの「[pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html)」を参照してください。
アプリケーション内のテーブルとインデックスの肥大化をチェックできます。詳細については、「[テーブルとインデックスの肥大化の診断](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html)」を参照してください。
#### 不要な領域を消費しているインデックスを探す
肥大化したインデックスを探し、読み取り権限のあるテーブルで不必要に消費されている領域の大きさを推定するには、次のクエリを実行します。
```
-- WARNING: rows with is_na = 't' are known to have bad statistics ("name" type is not supported).
-- This query is compatible with PostgreSQL 8.2 and later.
SELECT current_database(), nspname AS schemaname, tblname, idxname, bs*(relpages)::bigint AS real_size,
bs*(relpages-est_pages)::bigint AS extra_size,
100 * (relpages-est_pages)::float / relpages AS extra_ratio,
fillfactor, bs*(relpages-est_pages_ff) AS bloat_size,
100 * (relpages-est_pages_ff)::float / relpages AS bloat_ratio,
is_na
-- , 100-(sub.pst).avg_leaf_density, est_pages, index_tuple_hdr_bm,
-- maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, sub.reltuples, sub.relpages
-- (DEBUG INFO)
FROM (
SELECT coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)/(4+nulldatahdrwidth)::float)), 0
-- ItemIdData size + computed avg size of a tuple (nulldatahdrwidth)
) AS est_pages,
coalesce(1 +
ceil(reltuples/floor((bs-pageopqdata-pagehdr)*fillfactor/(100*(4+nulldatahdrwidth)::float))), 0
) AS est_pages_ff,
bs, nspname, table_oid, tblname, idxname, relpages, fillfactor, is_na
-- , stattuple.pgstatindex(quote_ident(nspname)||'.'||quote_ident(idxname)) AS pst,
-- index_tuple_hdr_bm, maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples
-- (DEBUG INFO)
FROM (
SELECT maxalign, bs, nspname, tblname, idxname, reltuples, relpages, relam, table_oid, fillfactor,
( index_tuple_hdr_bm +
maxalign - CASE -- Add padding to the index tuple header to align on MAXALIGN
WHEN index_tuple_hdr_bm%maxalign = 0 THEN maxalign
ELSE index_tuple_hdr_bm%maxalign
END
+ nulldatawidth + maxalign - CASE -- Add padding to the data to align on MAXALIGN
WHEN nulldatawidth = 0 THEN 0
WHEN nulldatawidth::integer%maxalign = 0 THEN maxalign
ELSE nulldatawidth::integer%maxalign
END
)::numeric AS nulldatahdrwidth, pagehdr, pageopqdata, is_na
-- , index_tuple_hdr_bm, nulldatawidth -- (DEBUG INFO)
FROM (
SELECT
i.nspname, i.tblname, i.idxname, i.reltuples, i.relpages, i.relam, a.attrelid AS table_oid,
current_setting('block_size')::numeric AS bs, fillfactor,
CASE -- MAXALIGN: 4 on 32bits, 8 on 64bits (and mingw32 ?)
WHEN version() ~ 'mingw32' OR version() ~ '64-bit|x86_64|ppc64|ia64|amd64' THEN 8
ELSE 4
END AS maxalign,
/* per page header, fixed size: 20 for 7.X, 24 for others */
24 AS pagehdr,
/* per page btree opaque data */
16 AS pageopqdata,
/* per tuple header: add IndexAttributeBitMapData if some cols are null-able */
CASE WHEN max(coalesce(s.null_frac,0)) = 0
THEN 2 -- IndexTupleData size
ELSE 2 + (( 32 + 8 - 1 ) / 8)
-- IndexTupleData size + IndexAttributeBitMapData size ( max num filed per index + 8 - 1 /8)
END AS index_tuple_hdr_bm,
/* data len: we remove null values save space using it fractionnal part from stats */
sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024)) AS nulldatawidth,
max( CASE WHEN a.atttypid = 'pg_catalog.name'::regtype THEN 1 ELSE 0 END ) > 0 AS is_na
FROM pg_attribute AS a
JOIN (
SELECT nspname, tbl.relname AS tblname, idx.relname AS idxname,
idx.reltuples, idx.relpages, idx.relam,
indrelid, indexrelid, indkey::smallint[] AS attnum,
coalesce(substring(
array_to_string(idx.reloptions, ' ')
from 'fillfactor=([0-9]+)')::smallint, 90) AS fillfactor
FROM pg_index
JOIN pg_class idx ON idx.oid=pg_index.indexrelid
JOIN pg_class tbl ON tbl.oid=pg_index.indrelid
JOIN pg_namespace ON pg_namespace.oid = idx.relnamespace
WHERE pg_index.indisvalid AND tbl.relkind = 'r' AND idx.relpages > 0
) AS i ON a.attrelid = i.indexrelid
JOIN pg_stats AS s ON s.schemaname = i.nspname
AND ((s.tablename = i.tblname AND s.attname = pg_catalog.pg_get_indexdef(a.attrelid, a.attnum, TRUE))
-- stats from tbl
OR (s.tablename = i.idxname AND s.attname = a.attname))
-- stats from functional cols
JOIN pg_type AS t ON a.atttypid = t.oid
WHERE a.attnum > 0
GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9
) AS s1
) AS s2
JOIN pg_am am ON s2.relam = am.oid WHERE am.amname = 'btree'
) AS sub
-- WHERE NOT is_na
ORDER BY 2,3,4;
```
#### オートバキュームの対象となるテーブルを見つける
自動バキュームの対象となるテーブルを見つけるには、次のクエリを実行します。
```
--This query shows tables that need vacuuming and are eligible candidates.
--The following query lists all tables that are due to be processed by autovacuum.
-- During normal operation, this query should return very little.
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold
FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold')
, vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor
FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor')
, fma AS (SELECT setting AS autovacuum_freeze_max_age
FROM pg_settings WHERE name = 'autovacuum_freeze_max_age')
, sto AS (SELECT opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value
FROM (SELECT oid opt_oid, unnest(reloptions) setting FROM pg_class) opt)
SELECT
'"'||ns.nspname||'"."'||c.relname||'"' as relation
, pg_size_pretty(pg_table_size(c.oid)) as table_size
, age(relfrozenxid) as xid_age
, coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age
, (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
as autovacuum_vacuum_tuples
, n_dead_tup as dead_tuples
FROM pg_class c
JOIN pg_namespace ns ON ns.oid = c.relnamespace
JOIN pg_stat_all_tables stat ON stat.relid = c.oid
JOIN vbt on (1=1)
JOIN vsf ON (1=1)
JOIN fma on (1=1)
LEFT JOIN sto cvbt ON cvbt.param = 'autovacuum_vacuum_threshold' AND c.oid = cvbt.opt_oid
LEFT JOIN sto cvsf ON cvsf.param = 'autovacuum_vacuum_scale_factor' AND c.oid = cvsf.opt_oid
LEFT JOIN sto cfma ON cfma.param = 'autovacuum_freeze_max_age' AND c.oid = cfma.opt_oid
WHERE c.relkind = 'r'
AND nspname <> 'pg_catalog'
AND (
age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
or
coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup
-- or 1 = 1
)
ORDER BY age(relfrozenxid) DESC;
```
### 多数の接続に対応する
Amazon CloudWatch をモニタリングすると、`DatabaseConnections`メトリックスパイクが見つかることがあります。この増加は、データベースへの接続数が増加していることを示します。次のようなアプローチを推奨します。
+ アプリケーションが各インスタンスで開くことができる接続の数を制限します。アプリケーションが組み込み接続プール機能を備えている場合は、適切な数の接続を設定します。インスタンス内の vCPUs が効果的にパラレル化できる数値を基準にします。
アプリケーションで接続プール機能を使用しない場合は、Amazon RDS プロキシまたは代替の使用を検討してください。このアプローチにより、アプリケーションはロードバランサーとの複数の接続を開くことができます。その後、バランサーは、データベースとの制限された数の接続を開くことができます。パラレルで実行される接続が少なくなると、DB インスタンスのカーネル内のコンテキスト切り替えが減少します。クエリの進行が速くなり、待機イベントが減少するはずです。詳細については、「[Amazon RDS Proxy ](rds-proxy.md)」を参照してください。
+ 可能であれば、RDS for PostgreSQL のリードレプリカを活用してください。アプリケーションが読み取り専用のオペレーションを実行するときは、これらのリクエストを読み取り専用レプリカに送信します。この方法でプライマリ (ライター) ノードの I/O 負荷を軽減します。
+ DB インスタンスのスケールアップを検討します。大容量のインスタンスクラスはより多くのメモリを提供するため、RDS for PostgreSQL ではページを保持するためのより大きな共有バッファプールを提供します。サイズが大きければ、DB インスタンスが接続処理する vCPUs も多くなります。特に、`IO:DataFileRead`待機イベントを発生させているオペレーションが書き込みの場合、vCPU の増設は有効です。
# IO:WALWrite
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.iowalwrite.context.supported)
+ [
## Context
](#wait-event.iowalwrite.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.iowalwrite.causes)
+ [
## アクション
](#wait-event.iowalwrite.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL 10 以降のすべてのバージョンでサポートされています。
## Context
先行書き込みログデータを生成しているデータベース内のアクティビティは、最初に WAL バッファをいっぱいにし、次に非同期でディスクに書き込みます。待機イベント `IO:WALWrite` は、トランザクションの COMMIT 呼び出しを解放できるように、WAL データのディスクへの書き込みが完了するまで SQL セッションの待機中に生成されます。
## 待機時間が増加する原因の可能性
この待機イベントが頻繁に発生する場合は、ワークロードが実行する更新の種類とその頻度を確認する必要があります。特に、次のタイプのアクティビティを確認します。
**高負荷の DML アクティビティ**
データベーステーブルのデータは、すぐに変更されるわけではありません。あるテーブルへの挿入は、別のクライアントからの同じテーブルへの挿入または更新を待つ必要がある場合があります。データ操作言語 (DML) のステートメントによってデータ値 (INSERT、UPDATE、DELETE、COMMIT、ROLLBACK TRANSACTION) を変更したことで競合が発生し、先行書き込みログファイルがバッファのフラッシュを待つ可能性があります。この状況は、以下の Amazon RDS Performance Insights メトリクスにも表れており、高負荷の DML アクティビティを示しています。
+ `tup_inserted`
+ `tup_updated`
+ `tup_deleted`
+ `xact_rollback`
+ `xact_commit`
これらのメトリクスの詳細については、「[Amazon RDS for PostgreSQL の Performance Insights カウンター](USER_PerfInsights_Counters.md#USER_PerfInsights_Counters.PostgreSQL)」を参照してください。
**チェックポイントアクティビティの頻度**
チェックポイントが頻繁に発生すると、WAL ファイルの数が増えます。RDS for PostgreSQL では、ページ全体の書き込みは常に「オン」になっています。ページ全体への書き込みは、データ損失の防止に役立ちます。ただし、チェックポイントが頻繁に行われると、システム全体のパフォーマンスの問題が発生することがあります。これは、特に 高負荷の DML アクティビティのシステムに当てはまります。場合によっては、`postgresql.log` に「チェックポイントが頻繁に発生しています」というエラーメッセージが表示されることがあります。
チェックポイントをチューニングする際には、異常なシャットダウンが発生した場合に予想される復旧時間と、パフォーマンスとのバランスを慎重に取ることをお勧めします。
## アクション
この待機イベントの数を削減するには、次のアクションをお勧めします。
**Topics**
+ [
### コミットの回数を減らす
](#wait-event.iowalwrite.actions.problem)
+ [
### チェックポイントのモニタリング
](#wait-event.iowalwrite.actions.monitor)
+ [
### IO のスケールアップ
](#wait-event.iowalwrite.actions.scale-io)
+ [
### 専用ログボリューム (DLV)
](#wait-event.iowalwrite.actions.dlv)
### コミットの回数を減らす
コミット数を減らすには、ステートメントをトランザクションブロックにまとめることができます。Amazon RDS Performance Insights を使用して、実行されているクエリの種類を確認してください。また、大規模なメンテナンスオペレーションをオフピークの時間帯に移動することもできます。例えば、インデックスを作成したり、稼働時間外に `pg_repack` オペレーションを使用したりします。
### チェックポイントのモニタリング
RDS for PostgreSQL DB インスタンスがチェックポイント用に WAL ファイルに書き込む頻度をモニタリングできるパラメータが 2 つあります。
+ `log_checkpoints` – このパラメータはデフォルトで「オン」になっています。これにより、チェックポイントごとにメッセージが PostgreSQL ログに送信されます。これらのログメッセージには、書き込まれたバッファの数、書き込みにかかった時間、特定のチェックポイントで追加、削除、またはリサイクルされた WAL ファイルの数が含まれます。
このパラメータについての詳細は、PostgreSQL ドキュメントの「[エラー報告とログ記録](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-CHECKPOINTS)」を参照してください。
+ `checkpoint_warning` – このパラメータは、チェックポイント頻度のしきい値 (秒単位) を設定します。この値を超えると、警告が表示されます。デフォルトでは、このパラメータは RDS for PostgreSQL では設定されていません。このパラメータの値を設定すると、RDS for PostgreSQL DB インスタンスのデータベース変更が WAL ファイルのサイズが処理できない速度で書き込まれたときに警告を受け取ることができます。例えば、このパラメータを 30 に設定したとします。RDS for PostgreSQL インスタンスが 30 秒に 1 回以上の頻度で変更を書き込む必要がある場合、「チェックポイントが頻繁に発生しています」という警告が PostgreSQL ログに送信されます。これは、`max_wal_size` 値を増やす必要があることを示している可能性があります。
詳細については、PostgreSQL ドキュメントの「[ログ先行書き込み](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS)」を参照してください。
### IO のスケールアップ
このタイプの入出力 (IO) 待機イベントは、1 秒あたりの入出力オペレーション (IOPS) をスケーリングして IO を高速化することで修正できます。CPU をスケーリングするよりも IO をスケーリングする方が望ましいです。CPU をスケーリングすると、処理量が増えることで IO ボトルネックがさらに悪化するため、IO の競合がさらに増える可能性があります。一般的に、スケーリングを実行する前にワークロードのチューニングを検討することをお勧めします。
### 専用ログボリューム (DLV)
Amazon RDS コンソール、AWS CLI、または Amazon RDS API を使用して、プロビジョンド IOPS (PIOPS) ストレージを使用する DB インスタンスの専用ログボリューム (DLV) を使用できます。DLV は、PostgreSQL データベーストランザクションログを、データベーステーブルを含むボリュームとは別のストレージボリュームに移動します。詳細については、「[専用ログボリューム (DLV)](CHAP_Storage.md#CHAP_Storage.dlv)」を参照してください。
# IPC:parallel 待機イベント
以下の `IPC:parallel wait events` は、セッションが並列クエリ実行オペレーションに関連するプロセス間通信を待機していることを示します。
+ `IPC:BgWorkerStartup` - プロセスは、並列ワーカープロセスが起動シーケンスを完了するのを待機しています。これは、並列クエリ実行のためにワーカーを初期化するときに発生します。
+ `IPC:BgWorkerShutdown` - プロセスは、並列ワーカープロセスがシャットダウンシーケンスを完了するのを待機しています。これは、並列クエリ実行のクリーンアップフェーズ中に発生します。
+ `IPC:ExecuteGather` - プロセスは、クエリの実行中に並列ワーカープロセスからデータを受信するのを待機しています。これは、リーダープロセスがワーカーから結果を収集する必要がある場合に発生します。
+ `IPC:ParallelFinish` - プロセスは、並列ワーカーが実行を終了して最終結果を報告するのを待機しています。これは、並列クエリ実行の完了フェーズ中に発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#rpg-ipc-parallel-context-supported)
+ [
## Context
](#rpg-ipc-parallel-context)
+ [
## 待機時間が増加する原因の可能性
](#rpg-ipc-parallel-causes)
+ [
## アクション
](#rpg-ipc-parallel-actions)
## サポート対象エンジンバージョン
この待機イベント情報は、Aurora PostgreSQL のすべてのバージョンでサポートされています。
## Context
PostgreSQL での並列クエリの実行では、複数のプロセスが連携して単一のクエリを処理します。クエリが並列化に適していると判断されると、リーダープロセスは `max_parallel_workers_per_gather` パラメータ設定に基づいて 1 つ以上の並列ワーカープロセスと連携します。リーダープロセスはワーカー間に作業を分割し、各ワーカーは担当するデータ部分を個別に処理します。結果はリーダープロセスに収集されます。
**注記**
各並列ワーカーは、フルユーザーセッションと同様のリソース要件を持つ個別のプロセスとして動作します。並列クエリで 4 つのワーカーが連携する場合、リーダープロセスと各ワーカープロセスの両方が独自のリソース割り当てを維持するため、非並列クエリと比較してリソース (CPU、メモリ、I/O 帯域幅) を最大 5 倍消費する可能性があります。例えば、`work_mem` のような設定は各ワーカーに個別に適用されるため、すべてのプロセスにわたって合計メモリ使用量が乗算される可能性があります。
並列クエリアーキテクチャは、以下の 3 つの主要コンポーネントで構成されます。
+ リーダープロセス: 並列オペレーションを開始して、ワークロードを分割し、ワーカープロセスと連携するメインプロセス。
+ ワーカープロセス: クエリの一部を並行して実行するバックグラウンドプロセス。
+ ギャザー/ギャザーマージ: 複数のワーカープロセスの結果をリーダーに戻してまとめるオペレーション。
並列実行中、プロセスはプロセス間通信 (IPC) メカニズムを介して相互に通信する必要があります。これらの IPC 待機イベントは、以下のさまざまなフェーズで発生します。
+ ワーカーの起動: 並列ワーカーを初期化するとき
+ データ交換: ワーカーがデータを処理し、結果をリーダーに送信するとき
+ ワーカーのシャットダウン: 並列実行が完了し、ワーカーを終了するとき
+ 同期ポイント: プロセス間で連携する必要があるとき、または他のプロセスがタスクを完了するまで待機する必要があるとき
これらの待機イベントを理解することは、特に複数の並列クエリが同時に実行中となる可能性が高い同時実行環境において、並列クエリの実行に関連するパフォーマンスの問題を診断するために重要です。
## 待機時間が増加する原因の可能性
並列関連の IPC 待機イベントの増加には、いくつかの要因が関係します。
**並列クエリに伴う高い同時実行性**
多数の並列クエリを同時に実行すると、リソースの競合が発生し、IPC オペレーションの待機時間が長くなる可能性があります。これは、トランザクション量が多いシステムや分析ワークロードで特によく見られます。
**最適ではない並列クエリプラン**
クエリプランナーで非効率的な並列プランを選択すると、ワーカー間での不要な並列化や作業分散の低下につながる可能性があります。その結果、特に `IPC:ExecuteGather` イベントと `IPC:ParallelFinish` イベントで、IPC 待機時間が長くなることがあります。こうしたプランニングの問題は、多くの場合、古い統計情報やテーブル/インデックスの肥大化が原因です。
**並列ワーカーの頻繁な起動とシャットダウン**
有効期間の短いクエリによる並列ワーカーの頻繁な開始と終了は、`IPC:BgWorkerStartup` イベントと `IPC:BgWorkerShutdown` イベントの増加につながる可能性があります。これは、多くの小さな並列化可能なクエリを含む OLTP ワークロードでよく見られます。
**リソースの制約**
CPU、メモリ、または I/O 容量が制限されると、並列実行でボトルネックが発生し、すべての IPC イベントで待機時間が長くなる可能性があります。例えば、CPU が飽和していると、ワーカープロセスが作業の一部を起動または処理するのに時間がかかることがあります。
**複雑なクエリ構造**
複数レベルの並列処理 (並列結合の後に並列集約が続くなど) を含むクエリは、特に `IPC:ExecuteGather` イベントの場合、IPC パターンが複雑化し、待機時間が長くなる可能性があります。
**大きな結果セット**
結果セットが大きいクエリでは、リーダープロセスがワーカープロセスからの結果の収集と処理により多くの時間を費やすため、`IPC:ExecuteGather` の待機時間が長くなる可能性があります。
これらの要因を理解することは、Aurora PostgreSQL での並列クエリ実行に関連するパフォーマンスの問題の診断と対処に役立ちます。
## アクション
並列クエリに関連する待機が生じた場合は、通常、バックエンドプロセスが並列ワーカープロセスを連携中または待機中であることを意味します。これらの待機は、並列プランの実行中によく発生します。これらの待機の影響を調査して軽減するには、並列ワーカーの使用状況をモニタリングし、パラメータ設定を見直して、クエリの実行とリソース割り当てを調整します。
**Topics**
+ [
### 非効率的な並列処理のクエリプランを分析する
](#rpg-ipc-parallel-analyze-plans)
+ [
### 並列クエリの使用状況をモニタリングする
](#rpg-ipc-parallel-monitor)
+ [
### 並列クエリ設定を確認して調整する
](#rpg-ipc-parallel-adjust-settings)
+ [
### リソース割り当てを最適化する
](#rpg-ipc-parallel-optimize-resources)
+ [
### 接続管理を調査する
](#rpg-ipc-parallel-connection-management)
+ [
### メンテナンスオペレーションを確認して最適化する
](#rpg-ipc-parallel-maintenance)
### 非効率的な並列処理のクエリプランを分析する
並列クエリを実行すると、システムの不安定性、CPU 使用率の急上昇、予測不可能なクエリパフォーマンスの変動が発生しがちです。並列処理によって特定のワークロードが実際に改善されるかどうかを徹底的に分析することが重要です。EXPLAIN ANALYZE を使用して、並列クエリ実行プランを確認してください。
プランの効率を比較するには、セッションレベルで並列処理を一時的に無効にします。
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
```
並列処理を再度有効にして比較します。
```
RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE ;
```
並列処理を無効にすると、より良い結果またはより一貫した結果が得られる場合は、SET コマンドを使用してセッションレベルで特定のクエリに対して並列処理を無効にすることを検討してください。より広範な効果を得るには、DB パラメータグループの関連するパラメータを調整して、インスタンスレベルで並列処理を無効にすることもできます。詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 並列クエリの使用状況をモニタリングする
以下のクエリを使用して、並列クエリのアクティビティと容量を可視化します。
アクティブな並列ワーカープロセスを確認します。
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
このクエリは、アクティブな並列ワーカープロセスの数を示します。値が高い場合は、`max\$1parallel\$1workers` の設定値が高い可能性があるため、値を下げることを検討できます。
同時並列クエリを確認します。
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
このクエリは、並列クエリを起動した個別のリーダープロセスの数を返します。ここで数値が高い場合は、複数のセッションで並列クエリを同時に実行中であることを示しているため、CPU とメモリの需要が増加する可能性があります。
### 並列クエリ設定を確認して調整する
以下のパラメータがワークロードに適合していることを確認します。
+ `max_parallel_workers`: すべてのセッションにわたる並列ワーカーの合計数。
+ `max_parallel_workers_per_gather`: クエリあたりの最大ワーカー数。
OLAP ワークロードの場合、これらの値を増やすと、パフォーマンスが向上する可能性があります。OLTP ワークロードの場合は、一般的に値を低く設定することが推奨されます。
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### リソース割り当てを最適化する
CPU 使用率をモニタリングし、値が一貫して高い場合や、アプリケーションが並列クエリのメリットを得られる場合は、vCPU の数を調整することを検討してください。並列オペレーションに十分なメモリが使用可能であることを確認します。
+ Performance Insights メトリクスを使用して、システムが CPU の処理能力に制約されているかどうかを判断します。
+ 各並列ワーカーは独自の `work_mem` を使用します。合計メモリ使用量がインスタンスの制限内であることを確認します。
並列クエリは、非並列クエリよりもかなり多くのリソースを消費する可能性があります。各ワーカープロセスは完全に独立したプロセスであり、別のユーザーセッションを追加するのとほぼ同じ影響をシステムにもたらすためです。この設定の値を選択したり、リソース使用率を制御する他の設定 (`work_mem` など) を構成したりする場合は、この点を考慮に入れる必要があります。詳細については、[PostgreSQL ドキュメント](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM)をご参照ください。`work_mem` などのリソース制限は各ワーカーに個別に適用されるため、すべてのプロセスにわたる合計使用率は、単一のプロセスにおける通常の使用率よりも大幅に高くなる可能性があります。
ワークロードを高度に並列化する場合は、vCPU を増やすか、メモリパラメータを調整することを検討してください。
### 接続管理を調査する
接続が不足している場合は、アプリケーション接続プーリング戦略を見直します。接続プーリングをまだ使用していない場合は、アプリケーションレベルで実装することを検討してください。
### メンテナンスオペレーションを確認して最適化する
インデックスの作成やその他のメンテナンスタスクを調整して、リソースの競合を防ぎます。これらのオペレーションは、オフピーク時間帯にスケジュールすることを検討してください。ユーザークエリの負荷が高い間は、負荷の高いメンテナンス (並列インデックスのビルドなど) をスケジュールしないでください。これらのオペレーションは並列ワーカーを消費し、通常のクエリのパフォーマンスに影響を与える可能性があります。
# IPC:ProcArrayGroupUpdate
`IPC:ProcArrayGroupUpdate` イベントは、セッションが、グループリーダーによるオペレーション終了時のトランザクションステータスの更新を待機しているときに発生します。PostgreSQL は通常、IPC タイプの待機イベントを並列クエリオペレーションに関連付けますが、この特定の待機イベントは並列クエリに固有ではありません。
**Topics**
+ [
## サポート対象エンジンバージョン
](#apg-rpg-ipcprocarraygroup.supported)
+ [
## Context
](#apg-rpg-ipcprocarraygroup.context)
+ [
## 待機時間が増加する原因の可能性
](#apg-rpg-ipcprocarraygroup.causes)
+ [
## アクション
](#apg-rpg-ipcprocarraygroup.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
**プロセス配列の理解** – プロセス (proc) 配列は PostgreSQL の共有メモリ構造です。トランザクションの詳細など、実行中のすべてのプロセスに関する情報を保持します。トランザクションの完了時 (`COMMIT` または `ROLLBACK`) に、ProcArray を更新して変更を反映し、配列から transactionID をクリアする必要があります。トランザクションを完了しようとするセッションは、ProcArray で排他的ロックを取得する必要があります。これにより、他のプロセスが共有ロックまたは排他的ロックを取得できなくなります。
**グループ更新メカニズム** – COMMIT または ROLLBACK の実行中に、バックエンドプロセスが排他的モードで ProcArrayLock を取得できない場合、ProcArrayGroupMember という特別なフィールドを更新します。これにより、終了する予定のセッションのリストにトランザクションが追加されます。このバックエンドプロセスはスリープし、スリープ時間は ProcArrayGroupUpdate 待機イベントとして計測されます。procArrayGroupMember を使用した ProcArray の最初のプロセスはリーダープロセスと呼ばれ、ProcArrayLock を排他的モードで取得します。次に、グループ transactionID のクリアを待機しているプロセスのリストをクリアします。これが完了すると、リーダーは ProcArrayLock をリリースし、このリストのすべてのプロセスを起動して、トランザクションが完了したことを通知します。
## 待機時間が増加する原因の可能性
実行中のプロセスが多いほど、リーダーが排他的モードで procArrayLock を保持する時間が長くなります。したがって、グループ更新シナリオでより多くの書き込みトランザクションが発生すると、`ProcArrayGroupUpdate` 待機イベントを待っているプロセスが蓄積される可能性があります。Database Insights のトップ SQL ビューでは、COMMIT がこの待機イベントの大部分を持つステートメントであることがわかります。これは予想される動作ですが、実行する特定の書き込み SQL をより詳細に調査して、実行する適切なアクションを決定する必要があります。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。Amazon RDS Performance Insights を使用するか、PostgreSQL システムビュー `pg_stat_activity` をクエリして、`IPC:ProcArrayGroupUpdate` イベントを特定します。
**Topics**
+ [
### トランザクションコミットおよびロールバックオペレーションのモニタリング
](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [
### 同時実行数の削減
](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [
### 接続プーリングを実装する
](#apg-rpg-ipcprocarraygroup.actions.pooling)
+ [
### 高速ストレージの使用
](#apg-rpg-ipcprocarraygroup.actions.storage)
### トランザクションコミットおよびロールバックオペレーションのモニタリング
**コミットとロールバックのモニタリング** – コミットとロールバックの数が増えると、ProcArray への負荷が増大する可能性があります。例えば、重複するキー違反の増加が原因で SQL ステートメントが失敗し始めた場合、ロールバックが増加し、ProcArray の競合とテーブルの肥大化が増加する可能性があります。
Amazon RDS Database Insights は PostgreSQL メトリクス `xact_commit` と `xact_rollback` を提供し、1 秒あたりのコミット数とロールバック数を報告します。
### 同時実行数の削減
**トランザクションのバッチ処理** – 可能であれば、コミット/ロールバック操作を減らすために、単一のトランザクションでバッチ操作を行います。
**同時実行数の制限** – ProcArray でのロック競合を軽減するために、同時にアクティブなトランザクションの数を減らします。ある程度のテストが必要になりますが、同時接続の合計数を減らすと、競合を減らし、スループットを維持できます。
### 接続プーリングを実装する
**接続プーリングソリューション** – 接続プーリングを使用してデータベース接続を効率的に管理し、バックエンドの合計数を減らし、ProcArray のワークロードを削減します。ある程度のテストが必要になりますが、同時接続の合計数を減らすと、競合を減らし、スループットを維持できます。
**接続ストームの軽減** – 同様に、頻繁に接続を作成および終了するパターンにより、ProcArray にさらなる負荷がかかります。このパターンを減らすことで、全体的な競合が軽減されます。
### 高速ストレージの使用
**専用ログボリューム** – `IPC:ProcArrayGroupUpdate` 待機イベントに高い `IO:WALWrite` 待機イベントが伴う場合、専用ログボリュームを設定すると、WAL への書き込みのボトルネックを減らすことができます。これにより、コミットのパフォーマンスが向上します。
詳細については、「[専用ログボリューム](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.dlv.html)」を参照してください。
# Lock:advisory
`Lock:advisory`イベントは、PostgreSQL アプリケーションがロックを使用して複数のセッション全体のアクティビティを調整するときに発生します。
**Topics**
+ [
## 関連するエンジンのバージョン
](#wait-event.lockadvisory.context.supported)
+ [
## Context
](#wait-event.lockadvisory.context)
+ [
## 原因
](#wait-event.lockadvisory.causes)
+ [
## アクション
](#wait-event.lockadvisory.actions)
## 関連するエンジンのバージョン
この待機イベント情報は、RDS for PostgreSQL バージョン 9.6 以降に関連します。
## Context
PostgreSQL アドバイザリロックは、ユーザーのアプリケーションコードによって明示的にロックおよびロック解除を実行するアプリケーションレベルの協調的ロックです。アプリケーションは PostgreSQL アドバイザリロックを使用して、複数のセッションにまたがるアクティビティを調整できます。通常のオブジェクトレベルまたは行レベルのロックとは異なり、アプリケーションはロックのライフタイムを完全に制御できます。詳細については、PostgreSQL ドキュメントの [Advisory Locks (アドバイザリロック)](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) を参照してください。
アドバイザリロックは、トランザクションが終了する前に解放されるか、トランザクション間のセッションで保持されます。これは、`CREATE INDEX`ステートメントによって取得されたテーブルへのアクセス排他ロックなど、暗黙のうちにシステムで強制されるロックには当てはまりません。
アドバイザリロックの取得 (ロック) およびリリース (ロック解除) に使用される関数の説明については、「PostgreSQL のドキュメント」の[アドバイザリロックの関数](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS)を参照してください。
アドバイザリロックは、通常の PostgreSQL ロックシステムの上に実装され、`pg_locks`システムビューで表示できます。
## 原因
このロックタイプは、明示的に使用するアプリケーションによって排他的に制御されます。クエリの一部として各行に対して取得されるアドバイザリロックは、ロックの急増や、長期的な蓄積を引き起こすことがあります。
これらの効果は、クエリが返すよりも多くの行でロックを取得する方法でクエリが実行されると発生します。アプリケーションは最終的にすべてのロックを解放する必要がありますが、返されない行でロックが取得された場合、アプリケーションはすべてのロックを見つけることができません。
PostgreSQL のドキュメントの「[アドバイザリロック](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS)」からの例を紹介します。
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
この例では、`LIMIT`節がクエリの出力を停止できるのは、内部で行が選択され、その ID 値がロックされた後のみです。これは、データ量の増加により、プランナーが開発中にテストされなかった別の実行プランを選択した場合に突然発生することがあります。この場合の構築アップは、アプリケーションがロックされた各ID値に明示的に`pg_advisory_unlock`を呼び出すことによって発生します。ただし、この場合、返されなかった行において取得されたロックのセットを見つけることはできません。ロックはセッションレベルで取得されるため、トランザクションの終了時に自動的に解放されません。
ブロックされたロック試行のスパイクは、意図しない競合が原因の可能性があります。このような競合では、アプリケーションの無関係な部分が、誤って同じロック ID スペースを共有します。
## アクション
アドバイザリロックのアプリケーション使用状況を確認し、アプリケーションフロー内のいつどこで各タイプのアドバイザリロックが取得および解放されるのか、詳しく説明します。
セッションが取得したロックが多すぎるか、長時間実行しているセッションがロックを早期に解放しないために、ロックの蓄積が遅くなっているかどうかを調べます。`pg_terminate_backend(pid)`を使用してセッションを終了すると、セッションレベルロックの遅い蓄積を修正できます。
アドバイザリロックを待機中のクライアントが`pg_stat_activity`、`wait_event_type=Lock`、`wait_event=advisory`に表示されます。同じ`pid`の`pg_locks`システムビューへのクエリを実行し、`locktype=advisory`と`granted=f`を検索することで、特定のロック値を取得できます。
`pg_locks`に対して`granted=t`を持つ同じアドバイザリロックへのクエリを実行することで、ブロックしているセッションを特定することができます。
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
すべてのアドバイザリロック API 関数には、1 つの`bigint`引数または2つの`integer`引数の 2 組の引数があります。
+ `bigint` の引数が 1 つの API 関数では、上位 32 ビットが `pg_locks.classid`、下位 32 ビットが `pg_locks.objid` となります。
+ `integer`が2つある API 関数の場合、第 1 引数は`pg_locks.classid`、第 2 引数は`pg_locks.objid`となります。
`pg_locks.objsubid`値はどの API フォームが使用されたかを示し、`1`は 1 つの`bigint`引数、`2`は 2 つの`integer`引数を意味します。
# Lock:extend
`Lock:extend`イベントは、バックエンドプロセスがリレーションを拡張するためにロックするのを待っているときに、別のプロセスが同じ目的でそのリレーションをロックしていると発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.lockextend.context.supported)
+ [
## Context
](#wait-event.lockextend.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.lockextend.causes)
+ [
## アクション
](#wait-event.lockextend.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
イベント`Lock:extend`は、バックエンドプロセスがリレーションの拡張する間、他のバックエンドプロセスがそのリレーションを拡張するのを待っている間にロックを保持することを示しています。リレーションを拡張できるのは一度に 1 つのプロセスだけなので、システムは`Lock:extend`待機イベントを発生させます。`INSERT`、`COPY`、`UPDATE`のオペレーションでこのイベントを生成することができます。
## 待機時間が増加する原因の可能性
`Lock:extend`イベントが通常より頻繁に発生する場合は、パフォーマンスの問題を示していることがあります。典型的な原因は次のとおりです。
**同じテーブルへの同時挿入または更新の急増 **
同じテーブルに挿入または更新するクエリの同時セッションが増加する可能性があります。
**ネットワーク帯域幅の不足**
DB インスタンスのネットワーク帯域幅が、現在のワークロードのストレージ通信ニーズに対して不十分な可能性があります。これは、`Lock:extend`イベントの増加を引き起こすストレージレイテンシーの原因となることがあります。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [
### 同じリレーションへの同時挿入と更新を減らす
](#wait-event.lockextend.actions.action1)
+ [
### ネットワーク帯域幅の増加
](#wait-event.lockextend.actions.increase-network-bandwidth)
### 同じリレーションへの同時挿入と更新を減らす
まず、`tup_inserted`、`tup_updated`メトリクスの増加と、それに伴うこの待機イベントの増加があるかどうか判断します。その場合は、挿入および更新オペレーションで競合性が高いリレーションをチェックします。これを判断するには、`n_tup_ins`および`n_tup_upd`フィールドでの値の`pg_stat_all_tables`ビューへのクエリを実行します。`pg_stat_all_tables`ビューの詳細については、PostgreSQL ドキュメントの「[pg\$1stat\$1statements](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW)」を参照してください。
ブロックおよびブロックされたクエリの詳細については、`pg_stat_activity`次の例のとおりにクエリを実行します。
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
`Lock:extend`イベントの増加に寄与するリレーションを特定したら、次の方法を使用して競合を減らします。
+ パーティション化によって同じテーブルの競合を減らせるかどうかを調べます。挿入または更新されたタプルを異なるパーティショニングすると、競合を減らすことができます。パーティショニングについては、「[pg\$1partman エクステンションによる PostgreSQL パーティションの管理](PostgreSQL_Partitions.md)」を参照してください。
+ 待機イベントが主に更新アクティビティによるものである場合は、リレーションのフィルファクタ値を減らすことを検討してください。これにより、更新時に新しいブロックのリクエストを減らすことができます。フィルファクタとは、テーブルページをパッキングするための最大容量を決定する、テーブルの格納パラメータです。これは、ページの総容量に対するパーセンテージで表されます。フィルファクタパラメータの詳細については、PostgreSQL ドキュメントの「[CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html)」を参照してください。
**重要**
この値を変更すると、ワークロードによってはパフォーマンスに悪影響を及ぼす可能性があるため、フィルファクタを変更する場合は、システムのテストを強くお勧めします。
### ネットワーク帯域幅の増加
書き込みレイテンシーが増加しているかどうかを確認するには、`WriteLatency`CloudWatch でメトリクスをチェックします。増加している場合は、Amazon CloudWatch の `WriteThroughput`、`ReadThroughput` メトリクスを使用し、DB インスタンスのストレージに関するトラフィックをモニタリングしてください。これらのメトリックは、ネットワーク帯域幅がワークロードのストレージアクティビティに十分かどうかを判断するのに役立ちます。
ネットワーク帯域幅が不足している場合は、増加してください。DB インスタンスがネットワーク帯域幅の制限に達している場合、帯域幅を増やす唯一の方法は DB インスタンスのサイズを大きくすることです。
CloudWatch のメトリクスの詳細については、「[Amazon RDS の Amazon CloudWatch インスタンスレベルのメトリクス](rds-metrics.md#rds-cw-metrics-instance)」を参照してください。DB インスタンスクラスごとの DB エンジンサポートについては、「[Amazon RDS の Amazon CloudWatch インスタンスレベルのメトリクス](rds-metrics.md#rds-cw-metrics-instance)」を参照してください。
# Lock:Relation
`Lock:Relation`イベントは、別のトランザクションによって現在ロックされているテーブルまたはビュー (リレーション) のロックを取得するためにクエリが待っているときに発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.lockrelation.context.supported)
+ [
## Context
](#wait-event.lockrelation.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.lockrelation.causes)
+ [
## アクション
](#wait-event.lockrelation.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
ほとんどの PostgreSQL コマンドは、テーブル内のデータへの同時アクセスを制御するために、暗黙のうちにロックを使用します。また、これらのロックは、アプリケーションコード内で`LOCK`コマンドによって明示的に使用することもできます。多くのロックモードは互いに互換性がないため、同じオブジェクトにアクセスしようとしているときにトランザクションをブロックすることがあります。このイベントが発生すると、RDS for PostgreSQL は `Lock:Relation` イベントを生成します。一般的な例をいくつか以下に示します。
+ `ACCESS EXCLUSIVE`のような排他的なロックは、すべての同時アクセスをブロックできます。`DROP TABLE`、`TRUNCATE`、`VACUUM FULL`、`CLUSTER`などのデータ定義言語 (DDL) オペレーションは、暗黙のうちに`ACCESS EXCLUSIVE`ロックを取得します。`ACCESS EXCLUSIVE` は、明示的にモードを指定しない `LOCK TABLE` ステートメントのデフォルトのロックモードでもあります。
+ テーブル上で`CREATE INDEX (without CONCURRENT)`を使用すると、`ROW EXCLUSIVE`ロックを取得するデータ操作言語 (DML) ステートメント`UPDATE`、`DELETE`、`INSERT`と競合します。
テーブルレベルのロックと競合するロックモードの詳細については、PostgreSQL ドキュメントの「[明示的なロック](https://www.postgresql.org/docs/13/explicit-locking.html)」を参照してください。
ブロックされたクエリとトランザクションは、通常、次のいずれかの方法でブロックを解除します。
+ クエリのブロック: アプリケーションがクエリをキャンセルするか、ユーザーがプロセスを終了できます。また、セッションのステートメントタイムアウトやデッドロック検出メカニズムによって、エンジンがクエリを強制終了させることもできます。
+ トランザクションのブロック: トランザクションが `ROLLBACK` または `COMMIT` を実行すると、トランザクションはブロックを停止します。ロールバックは、クライアントまたはネットワークの問題によってセッションが切断されたり、終了したときにも自動的に行われます。セッションは、データベースエンジンがシャットダウンされたり、システムがメモリ不足になったりしたときに終了できます。
## 待機時間が増加する原因の可能性
`Lock:Relation` イベントが通常よりも頻繁に発生する場合、パフォーマンスの問題を示している可能性があります。代表的な原因としては、以下が挙げられます。
**テーブルロックの競合による同時セッションの増加**
競合するロックモードで同じテーブルをロックするクエリによる同時セッションの数が増加する可能性があります。
**メンテナンスオペレーション**
`VACUUM`や`ANALYZE`のようなヘルスメンテナンスオペレーションは、競合するロックの数を大幅に増加させる可能性があります。`VACUUM FULL`は`ACCESS EXCLUSIVE`のロックを、`ANALYSE`は`SHARE UPDATE EXCLUSIVE`のロックを取得します。どちらのタイプのロックも、`Lock:Relation`待機イベントを引き起こすことがあります。また、マテリアライズドビューのリフレッシュなどのアプリケーションデータのメンテナンスオペレーションも、ブロックされたクエリとトランザクションを増加することもあります。
**リーダーインスタンスをロックする**
ライターとリーダーが保持しているリレーションロックの間に矛盾がある可能性があります。現在は、`ACCESS EXCLUSIVE` リレーションロックのみが、リーダーインスタンスにレプリケートされます。ただし、`ACCESS EXCLUSIVE` リレーションロックは、リーダーが保持する `ACCESS SHARE` リレーションロックと競合します。これにより、リーダーのロックリレーション待機イベントが増加する可能性があります。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [
### SQL ステートメントのブロックによる影響を軽減
](#wait-event.lockrelation.actions.reduce-blocks)
+ [
### メンテナンスオペレーションの影響を最小限に抑える
](#wait-event.lockrelation.actions.maintenance)
### SQL ステートメントのブロックによる影響を軽減
SQL ステートメントのブロックによる影響を軽減するには、可能なところではアプリケーションコードを修正します。ブロックを減らすための 2 つの一般的な方法は以下のとおりです。
+ `NOWAIT` オプションを使用する: `SELECT` や `LOCK` ステートメントなど、一部の SQL コマンドはこのオプションをサポートしています。`NOWAIT`指示文は、ロックをすぐに取得できない場合、ロックへのクエリをキャンセルします。この方法は、ブロックされたセッションが、その後ろにあるブロックされたセッションが積み重なるのを防ぐのに役立ちます。
例えば、トランザクション A がトランザクション B に保持されているロックを待っているとします。ここで、B がトランザクション C によってロックされているテーブルのロックをリクエストすると、トランザクション C が完了するまでトランザクション A がブロックされる可能性があります。ただし、トランザクション B が C のロックを要求するときに`NOWAIT`を使用する場合、トランザクションBは迅速に失敗し、トランザクション A が無期限に待機する必要がないことを保証できます。
+ `SET lock_timeout` を使用する: `lock_timeout` 値を設定して、SQL ステートメントがリレーションでロックを取得するのを待機する時間を制限します。指定されたタイムアウト時間内にロックが取得されなかった場合、ロックを要求したトランザクションはキャンセルされます。この値はセッションレベルで設定します。
### メンテナンスオペレーションの影響を最小限に抑える
`VACUUM`や`ANALYZE`のようなメンテナンスオペレーションは重要です。これらのメンテナンス作業に関連する`Lock:Relation`待機イベントを見つけても、それらをオフにしないことをお勧めします。次のようなアプローチにより、これらの操作の影響を最小限に抑えることができます。
+ オフピーク時にメンテナンス操作をマニュアルで実行します。
+ オートバキュームタスクによる`Lock:Relation`待機をへらすには、必要なオートバキュームチューニングを実行します。オートバキュームのチューニングについては、*Amazon RDS ユーザーガイド*の「[Amazon RDS での PostgreSQL オートバキュームの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)」を参照してください。
# Lock:transactionid
`Lock:transactionid`イベントは、トランザクションが行レベルのロックを待っているときに発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.locktransactionid.context.supported)
+ [
## Context
](#wait-event.locktransactionid.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.locktransactionid.causes)
+ [
## アクション
](#wait-event.locktransactionid.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
イベント`Lock:transactionid`は、トランザクションが、同時に実行されているトランザクションにすでに付与された行レベルのロックを取得しようとすると発生します。を示すセッションは、`Lock:transactionid`待機イベントがこのロックのためにブロックされていることを示します。`COMMIT`または`ROLLBACK`ステートメントでブロックされているトランザクションの完了後、ブロックされたトランザクションを続行できます。
RDS for PostgreSQL のマルチバージョン同時実行制御セマンティクスは、リーダーがライターを、ライターがリーダーをブロックしないことを保証します。行レベルの競合が発生するには、ブロックおよびブロックされたトランザクションで、次のタイプの競合するステートメントを発行する必要があります。
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
ステートメント`SELECT … FOR KEY SHARE`は特殊なケースです。データベースは、レファレンスの整合性のパフォーマンスを最適化するために、`FOR KEY SHARE`節を使用します。行に対する行レベルロックは、行を参照している他のテーブルの`INSERT`、`UPDATE`、`DELETE`コマンドをブロックできます。
## 待機時間が増加する原因の可能性
このイベントが通常よりも頻繁に発生する場合、通常は`UPDATE`、`SELECT … FOR UPDATE`、または`SELECT … FOR KEY SHARE`ステートメントが以下の条件と組み合わさることが原因です。
**Topics**
+ [
### 同時実行数が多い
](#wait-event.locktransactionid.concurrency)
+ [
### トランザクションでのアイドル状態
](#wait-event.locktransactionid.idle)
+ [
### トランザクションの実行時間が長い
](#wait-event.locktransactionid.long-running)
### 同時実行数が多い
RDS for PostgreSQL は、きめ細かい行レベルのロックセマンティクスを使用できます。以下の条件が満たされると、行レベルの同時実行が発生する可能性が高くなります。
+ 同時性の高いワークロードは、同じ行で同時実行します。
+ 同時実行数が増加します。
### トランザクションでのアイドル状態
時々、`pg_stat_activity.state`列には`idle in transaction`値が表示されます。この値は、トランザクションをスタートしていても、まだ`COMMIT`または`ROLLBACK`を発行していないセッションに表示されます。`pg_stat_activity.state`値が`active`ではない場合、`pg_stat_activity`に表示されるクエリは、実行を終了した最新のクエリになります。ブロックされているセッションは、開いているトランザクションがロックを保持しているため、クエリを積極的に処理しません。
アイドル状態のトランザクションが行レベルロックを取得した場合は、他のセッションがそのロックを取得するのを妨害する可能性があります。この状態は、待機イベント`Lock:transactionid`の頻発につながります。問題を診断するには、`pg_stat_activity`そして`pg_locks`からの出力を検証します。
### トランザクションの実行時間が長い
実行時間が長いトランザクションは、長時間ロックされます。これらの長時間のロックは、他のトランザクションの実行をブロックすることがあります。
## アクション
行ロックは`UPDATE`、`SELECT … FOR UPDATE`、または`SELECT … FOR KEY SHARE`ステートメント間の競合です。解決策を試す前に、これらのステートメントが同じ行で実行されているかどうかを調べます。この情報をもとに、次のセクションで説明する戦略を選択してください。
**Topics**
+ [
### 同時実行数の多さに対応
](#wait-event.locktransactionid.actions.problem)
+ [
### アイドル状態のトランザクションに対応する
](#wait-event.locktransactionid.actions.find-blocker)
+ [
### 長時間実行されるトランザクションへの対応
](#wait-event.locktransactionid.actions.concurrency)
### 同時実行数の多さに対応
同時実行数が問題になる場合は、以下から 1 つの方法を試行します。
+ アプリケーションの同時実行数を減らします。例えば、アクティブなセッションの数を減らします。
+ 接続プールを実装します。RDS プロキシを使用して接続をプールする方法については、「[Amazon RDS Proxy ](rds-proxy.md)」を参照してください。
+ アプリケーションまたはデータモデルを設計し、`UPDATE`および`SELECT … FOR UPDATE`ステートメントの競合を避けてください。また、`SELECT … FOR KEY SHARE`ステートメントにアクセスされる外部キーの数を減らすこともできます。
### アイドル状態のトランザクションに対応する
`pg_stat_activity.state`が`idle in transaction`を示している場合は、以下の方法を使用します。
+ 可能な限り、オートコミットをオンにします。この方法では、`COMMIT`または`ROLLBACK`を待っている間に、トランザクションが他のトランザクションをブロックすることを防ぎます。
+ `COMMIT`、`ROLLBACK`、または`END`が不足しているコードパスを検索します。
+ アプリケーションの例外処理ロジックに、常に有効な`end of transaction`へのパスが設定されていることを確認してください。
+ `COMMIT`または`ROLLBACK`でトランザクションを完了した後、アプリケーションがクエリの結果を処理することを確認します。
### 長時間実行されるトランザクションへの対応
長時間実行されるトランザクションが`Lock:transactionid`の発生を頻繁に引き起こす場合、以下の方法を試します。
+ 長時間実行されるトランザクションが行をロックしないようにします。
+ 可能であれば、オートコミットを実装してクエリの長さを制限します。
# Lock:tuple
`Lock:tuple` イベントは、バックエンドプロセスがタプルのロックを取得するのを待っているときに発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.locktuple.context.supported)
+ [
## Context
](#wait-event.locktuple.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.locktuple.causes)
+ [
## アクション
](#wait-event.locktuple.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
イベント`Lock:tuple`は、バックエンドがタプルのロック取得を待っている間、別のバックエンドが同じタプルで競合するロックを保持していることを示します。次の表では、セッションが`Lock:tuple`イベントを生成するシナリオを示します。
| 時間 | セッション 1 | セッション 2 | セッション 3 |
| --- | --- | --- | --- |
| t1 | トランザクションをスタートします。 | | |
| t2 | 行 1 を更新します。 | | |
| t3 | | 行 1 を更新します。セッションは、タプルの排他ロックを取得してから、セッション1がコミットまたはロールバックによってロックを解放するのを待機します。 | |
| t4 | | | 行 1 を更新します。セッションは、セッション 2 がタプルの排他ロックを解放するのを待機します。 |
または、ベンチマークツール`pgbench`を使用してこの待機イベントをシミュレートすることができます。多数の同時セッションを構成して、カスタムSQLファイルでテーブル内の同じ行を更新します。
競合するロックモードの詳細については、「PostgreSQL のドキュメント」の「[明示的なロック](https://www.postgresql.org/docs/current/explicit-locking.html)」を参照してください。`pgbench`の詳細については、「PostgreSQL のドキュメント」の「[pgbench](https://www.postgresql.org/docs/current/pgbench.html)」を参照してください。
## 待機時間が増加する原因の可能性
このイベントが通常よりも頻繁に表示される場合、パフォーマンスの問題を示している可能性があり、典型的な原因は次のとおりです。
+ `UPDATE`または`DELETE`ステートメントの実行により、同じタプルへの競合するロックを取得しようとしている同時セッションが多数あります。
+ 同時実行数の多いセッションでは、`FOR UPDATE`または`FOR NO KEY UPDATE`ロックモードを使用して`SELECT`ステートメントを実行します。
+ さまざまな要因により、アプリケーションまたは接続プールが同じオペレーションを実行するため、より多くのセッションを開きます。新しいセッションが同じ行を変更しようとすると、DB ロードのスパイクが発生して`Lock:tuple`が表示されることがあります。
詳細については、「PostgreSQL のドキュメント」の「[行レベルのロック](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS)」を参照してください。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [
### アプリケーションロジックを調査する
](#wait-event.locktuple.actions.problem)
+ [
### ブロッカーセッションを見つける
](#wait-event.locktuple.actions.find-blocker)
+ [
### 同時実行数が多いときにそれを減らす
](#wait-event.locktuple.actions.concurrency)
+ [
### ボトルネックのトラブルシューティング
](#wait-event.locktuple.actions.bottlenecks)
### アプリケーションロジックを調査する
ブロッカーセッションが長い間`idle in transaction`ステートメントにあったかどうかを確認します。その場合は、短期的な解決策としてブロッカーセッションの終了を検討してください。`pg_terminate_backend` 関数を使用することもできます。この関数の詳細については、「PostgreSQL のドキュメント」の「[サーバーシグナリング関数](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL)」を参照してください。
長期的な解決策としては、以下を実行してください。
+ アプリケーションロジックを調整します。
+ `idle_in_transaction_session_timeout` パラメータを使用します。このパラメータは、指定された時間より長くアイドル状態であったオープントランザクションを持つセッションを終了させます。詳細については、PostgreSQL ドキュメントの 「[Client Connection Defaults (クライアント接続のデフォルト)](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT)」 を参照してください。
+ 可能な限りオートコミットを使用します。詳細については、PostgreSQL ドキュメントの 「[Client authentication (クライアント認証)](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html)」 を参照してください。
### ブロッカーセッションを見つける
`Lock:tuple`の待機イベントが発生している間に、どのロックが互いに依存しているかを探して、ブロッカーとブロックされたセッションを特定します。詳細については、PostgreSQL wiki にの「[依存関係情報のロック](https://wiki.postgresql.org/wiki/Lock_dependency_information)」を参照してください。
次の例では、`tuple`でフィルタリングして`wait_time`で順序付けし、すべてのセッションへのクエリを実行しています。
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
### 同時実行数が多いときにそれを減らす
`Lock:tuple`イベントは、特にワークロードの多い時間帯に、コンスタントに発生する可能性があります。このような状況では、非常にビジーな行への同時実行数を減らすことを検討してください。多くの場合、キューまたはブールロジックを制御する行の数行だけで、これらの行は非常にビジーになります。
ビジネス要件、アプリケーションロジック、およびワークロードタイプに応じて、さまざまなアプローチを使用することで、競合を減らすことができます。例えば、次のオペレーションを実行できます。
+ テーブルとデータロジックを再設計し、競合を減らします。
+ アプリケーションロジックを変更して、行レベルで高い競合を減らします。
+ 行レベルのロックを活用してクエリを再設計します。
+ `NOWAIT`節はリトライオペレーションで使用します。
+ 楽観的かつハイブリッドロックロジックの同時実行制御の使用を検討します。
+ データベースの隔離レベルの変更を検討してください。
### ボトルネックのトラブルシューティング
`Lock:tuple`は、CPU の枯渇や Amazon EBS 帯域幅の最大使用率などのボトルネックを発生させることがあります。ボトルネックを減らすには、次のアプローチを検討します。
+ インスタンスクラスタイプをスケールアップします。
+ リソースを大量に消費するクエリを最適化します。
+ アプリケーションロジックを変更します。
+ ほとんどアクセスされないデータをアーカイブします。
# LWLock:BufferMapping (LWLock:buffer\$1mapping)
このイベントは、セッションがデータブロックを共有バッファプール内のバッファに関連付けるのを待っているときに発生します。
**注記**
RDS for PostgreSQL のバージョン 13 以降では、このイベントの名前は `LWLock:BufferMapping` になります。RDS for PostgreSQL のバージョン 12 以前では、このイベントの名前は `LWLock:buffer_mapping` になります。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.lwl-buffer-mapping.context.supported)
+ [
## Context
](#wait-event.lwl-buffer-mapping.context)
+ [
## 原因
](#wait-event.lwl-buffer-mapping.causes)
+ [
## アクション
](#wait-event.lwl-buffer-mapping.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL バージョン 9.6 以降に関連します。
## Context
*共有バッファプール*は、プロセスで使用されている、または使用されていたすべてのページを保持する PostgreSQL のメモリ領域です。プロセスがページを必要とするとき、そのページを共有バッファプールに読み取ります。`shared_buffers`パラメータは、共有バッファサイズを設定し、テーブルとインデックスページを格納するためのメモリ領域を予約します。このパラメータを変更する場合は、必ずデータベースを再起動してください。
`LWLock:buffer_mapping`待機イベントは、以下の場合に発生します。
+ プロセスは、バッファテーブルでページを検索し、共有バッファマッピングロックを取得します。
+ プロセスは、ページをバッファプールにロードし、排他的バッファマッピングロックを取得します。
+ プロセスは、プールからページを削除し、排他バッファマッピングロックを取得します。
## 原因
このイベントが通常よりも頻繁に発生する場合、パフォーマンスの問題を示していることがあり、データベースは共有バッファプールにページインとアウトページングを行っています。代表的な原因としては、以下が挙げられます。
+ 大きなクエリ
+ 肥大化したインデックスとテーブル
+ フルテーブルスキャン
+ ワーキングセットより小さい共有プールサイズ
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。
**Topics**
+ [
### バッファ関連のメトリクスをモニタリングする
](#wait-event.lwl-buffer-mapping.actions.monitor-metrics)
+ [
### インデックス作成戦略を評価する
](#wait-event.lwl-buffer-mapping.actions.indexes)
+ [
### 迅速に確保しなければならないバッファの数を減らす
](#wait-event.lwl-buffer-mapping.actions.buffers)
### バッファ関連のメトリクスをモニタリングする
`LWLock:buffer_mapping`がスパイクを待機したら、バッファヒット率を調べます。これらのメトリクスを使用すると、バッファキャッシュで何が起こっているかをより深く理解できます。次のメトリックを検証します。
`blks_hit`
この Performance Insights カウンターメトリクスは、共有バッファプールから取得されたブロックの数を示します。`LWLock:buffer_mapping`の待機イベントが表示された後、`blks_hit`のスパイクを観察することがあります。
`blks_read`
この Performance Insights カウンターメトリクスは、共有バッファプールへの読み取りのため、 I/O を必要とするブロックの数を示します。`LWLock:buffer_mapping`待機イベントまでに`blks_read`のスパイクが観察されることがあります。
### インデックス作成戦略を評価する
インデックス作成戦略がパフォーマンスが低下させていないことを確認するには、次を確認してください。
インデックスの肥大化
インデックスとテーブルの肥大化によって、不要なページが共有バッファに読み込まれないようにします。テーブルに未使用の行がある場合は、データをアーカイブし、テーブルから行を削除することを検討してください。その後、サイズ変更されたテーブルのインデックスを再構築できます。
頻繁に使用するクエリのインデックス
最適なインデックスがあるかどうかを判断するには、Performance Insights で DB エンジンのメトリクスをモニタリングします。`tup_returned`メトリクスは、読み込まれた行数を示します。`tup_fetched`メトリクスは、クライアントに返される行数を示します。`tup_returned`が`tup_fetched`を大幅に超える場合、データが適切にインデックスされていない可能性があります。また、テーブルの統計が最新ではない可能性があります。
### 迅速に確保しなければならないバッファの数を減らす
`LWLock:buffer_mapping`待機イベントを減らすには、迅速に割り当てる必要があるバッファの数を減らしてください。1 つの戦略として、より小規模なバッチオペレーションを実行します。テーブルをパーティション化することで、より小さなバッチを実現できることがあります。
# LWLock:BufferIO (IPC:BufferIO)
`LWLock:BufferIO` イベントは、RDS for PostgreSQL が同時にページにアクセスしようとしているときに、他のプロセスが入出力 (I/O) オペレーションの完了を待っているときに発生します。その目的は、同じページを共有バッファに読み込むことです。
**Topics**
+ [
## 関連するエンジンのバージョン
](#wait-event.lwlockbufferio.context.supported)
+ [
## Context
](#wait-event.lwlockbufferio.context)
+ [
## 原因
](#wait-event.lwlockbufferio.causes)
+ [
## アクション
](#wait-event.lwlockbufferio.actions)
## 関連するエンジンのバージョン
この待機イベント情報は、すべての RDS for PostgreSQL のバージョンに関連しています。RDS for PostgreSQL 12 以前のバージョンでは、この待機イベントは lwlock:buffer\$1io という名前でしたが、RDS for PostgreSQL 13 バージョンでは lwlock:bufferio という名前です。RDS for PostgreSQL 14 バージョンから、BufferIO 待機イベントは `LWLock` から `IPC` 待機イベントタイプ (IPC:BufferIO) に移動されました。
## Context
各共有バッファは、ブロック (またはページ) が共有バッファプールの外部で取得される必要があるたびに、`LWLock:BufferIO`待機イベントに関連付けられた I/O ロックを持ちます。
このロックは、すべての同じブロックへのアクセスを必要とする複数のセッションを処理するために使用されます。このブロックは、`shared_buffers`パラメータで定義された共有バッファプールの外部から読み取る必要があります。
共有バッファプール内でページが読み込まれると、`LWLock:BufferIO`ロックが解除されます。
**注記**
`LWLock:BufferIO`待機イベントは[IO:DataFileRead](wait-event.iodatafileread.md)待機イベントに先行します。`IO:DataFileRead`待機イベントは、データがストレージから読み込まれている間に発生します。
ライトウェイトロックの詳細については、「[ロックの概要](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20)」を参照してください。
## 原因
`LWLock:BufferIO`上位待機中に表示されるイベントの一般的な原因には、次のものがあります。
+ 複数のバックエンドまたは接続が I/O オペレーションを保留している同じページにアクセスしようとしている
+ 共有バッファプール (`shared_buffers`パラメータで定義) のサイズと、現在のワークロードが必要とするバッファ数の比率
+ 共有バッファプールのサイズが、他の操作によって削除されるページ数とのバランスが悪い
+ エンジンが共有バッファプールに必要以上のページを読み込む必要がある大規模なインデックスまたは肥大化したインデックス
+ DB エンジンが強制的に必要以上に多くのページをテーブルから読み取るインデックスの欠落
+ チェックポイント発生が頻繁すぎたり、変更されたページをフラッシュする必要が多すぎる
+ 同じページで操作を実行しようとするデータベース接続が突然スパイクする
## アクション
待機イベントの原因に応じたさまざまなアクションを実行することをお勧めします。
+ `BufferCacheHitRatio`の急減と`LWLock:BufferIO`待機イベントの相関関係のため、Amazon CloudWatch メトリクスを観察します。この効果は、共有バッファの設定が小さいことを意味することがあります。増やすか、DB インスタンスクラスをスケールアップする必要がある場合があります。ワークロードをより多くのリーダーノードに分割できます。
+ `LWLock:BufferIO`が`BufferCacheHitRatio`のメトリックと一致する場合は、ワークロードのピーク時間に基づいて`max_wal_size`と`checkpoint_timeout`をチューニングしてください。次に、原因となっているクエリを特定します。
+ 未使用のインデックスがあるかどうかを確認し、それらを削除します。
+ パーティション化されたテーブルを使用します (パーティション化されたインデックスもあります)。これにより、インデックスの並べ替えを低く抑え、その影響を軽減することができます。
+ 不必要に列のインデックスを作成しないようにします。
+ 接続プールを使用して、突然のデータベース接続スパイクを防ぎます。
+ ベストプラクティスとして、データベースへの最大接続数を制限します。
# LWLock:buffer\$1content (BufferContent)
この`LWLock:buffer_content`待機イベントは、セッションがデータページをメモリに読み取るまたは書き込むために待機中、他のセッションがそのページを書き込み用にロックしている場合に発生します。RDS for PostgreSQL 13 以降では、この待機イベントは `BufferContent` と呼ばれます。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.lwlockbuffercontent.context.supported)
+ [
## Context
](#wait-event.lwlockbuffercontent.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.lwlockbuffercontent.causes)
+ [
## アクション
](#wait-event.lwlockbuffercontent.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
データの読み取りや操作のために、PostgreSQL は共有メモリバッファを介してデータにアクセスします。バッファから読み取るために、プロセスは共有モードでバッファコンテンツに対する軽量ロック (LwLock) を取得します。バッファに書き込むには、排他モードでそのロックを取得します。共有ロックを使用すると、他のプロセスがそのコンテンツの共有ロックを同時に取得できます。排他ロックは、他のプロセスによるいかなるタイプのロック取得も防ぎます。
`LWLock:buffer_content`(`BufferContent`) イベントは、複数のプロセスが特定のバッファの内容をロックしようとしていることを示します。
## 待機時間が増加する原因の可能性
`LWLock:buffer_content` (`BufferContent`) イベントが通常より頻繁に発生し、パフォーマンスの問題を示している可能性がある場合、代表的な原因として以下が挙げられます。
**同一データに対する同時更新の増加**
同じバッファコンテンツを更新するクエリによる同時実行セッションの数が増加する可能性があります。この競合は、インデックスの多いテーブルではより顕著になることがあります。
**ワークロードデータがメモリ内に存在しない**
アクティブなワークロードが処理しているデータがメモリ上にない場合、これらの待機イベントが増加する可能性があります。この効果は、ロックを保持しているプロセスが、ディスク I/O 操作の実行中にロックを長く維持できるためです。
**外部キー制約の過度の使用**
外部キー制約により、プロセスがバッファコンテンツロックを保持する時間を増やすことがあります。この効果は、読み取り操作では、そのキーが更新されている間、参照キーに対する共有バッファコンテンツのロックが必要になるためです。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。`LWLock:buffer_content`(`BufferContent`)イベントは、Amazon RDS Performance Insights を使用するか、ビュー`pg_stat_activity`のクエリで特定することができます。
**Topics**
+ [
### インメモリ効率の向上
](#wait-event.lwlockbuffercontent.actions.in-memory)
+ [
### 外部キー制約の使用を減らす
](#wait-event.lwlockbuffercontent.actions.foreignkey)
+ [
### 未使用インデックスの削除
](#wait-event.lwlockbuffercontent.actions.indexes)
+ [
### シーケンスを使用する場合は、キャッシュサイズを増やしてください
](#wait-event.lwlockbuffercontent.actions.sequences)
### インメモリ効率の向上
アクティブなワークロードデータがメモリ内に存在する可能性を高めるには、テーブルをパーティション化するか、インスタンスクラスをスケールアップします。DB インスタンスクラスの詳細については、「[ DB インスタンスクラス](Concepts.DBInstanceClass.md)」を参照してください。
### 外部キー制約の使用を減らす
外部キー制約の使用で、`LWLock:buffer_content`(`BufferContent`)待機イベントが多発しているワークロードを調査します。不要な外部キーの制約を削除します。
### 未使用インデックスの削除
`LWLock:buffer_content` (`BufferContent`) 待機イベントが多いワークロードで、未使用のインデックスを特定して削除します。
### シーケンスを使用する場合は、キャッシュサイズを増やしてください
テーブルがシーケンスを使用している場合は、キャッシュサイズを増やして、シーケンスページとインデックスページの競合をなくします。各シーケンスは共有メモリ内の 1 ページです。定義済みのキャッシュは接続ごとです。多くの同時セッションによってシーケンス値を取得している場合、これではワークロードを処理するのに不十分な場合があります。
# LWLock:lock\$1manager (LWLock:lockmanager)
このイベントは、RDS for PostgreSQL エンジンが、高速パスロックが不可能な場合に共有ロックのメモリ領域を維持し、ロックの割り当て、チェック、および解放を行うときに発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.lw-lock-manager.context.supported)
+ [
## Context
](#wait-event.lw-lock-manager.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.lw-lock-manager.causes)
+ [
## アクション
](#wait-event.lw-lock-manager.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL バージョン 9.6 以降に関連します。RDS for PostgreSQL のバージョン 13 より前のリリースでは、この待機イベントの名前は `LWLock:lock_manager` になります。RDS for PostgreSQL のバージョン 13 以降のリリースでは、この待機イベントの名前は `LWLock:lockmanager` になります。
## Context
SQL ステートメントを発行すると、RDS for PostgreSQL は同時オペレーション中にデータベースの構造、データ、および整合性を保護するためにロックを記録します。エンジンは、高速パスロックまたは高速ではないパスロックを使用して、この目標を達成できます。高速ではないパスロックは、高速パスロックよりも高価で、オーバーヘッドも多く発生します。
### 高速パスロック
バックエンドプロセスでは、頻繁にロックされロック解除されるがめったに競合しないロックのオーバーヘッドを減らすために、高速パスロックを使用できます。データベースでは、以下の基準を満たすロックにこのメカニズムを使用します。
+ DEFAULT ロック方式を使用します。
+ これらは、共有関係ではなく、データベースリレーションに対するロックを表します。
+ これらは競合する可能性が低い弱いロックです。
+ エンジンは、競合するロックが存在する可能性がないことをすばやく確認できます。
エンジンは、以下のいずれかの条件が true の場合、高速パスロックを使用できません。
+ ロックが上記の条件を満たしていません。
+ バックエンドプロセスに使用できるスロットはこれ以上ありません。
高速パスロック用にクエリを調整するには、次のクエリを使用できます。
```
SELECT count(*), pid, mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 4,3,2
ORDER BY pid, mode;
count | pid | mode | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock | t
```
次のクエリでは、データベース全体の合計のみを表示します。
```
SELECT count(*), mode, fastpath
FROM pg_locks
WHERE fastpath IS NOT NULL
GROUP BY 3,2
ORDER BY mode,1;
count | mode | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock | t
(3 rows)
```
高速パスロックの詳細については、「PostgreSQL ロックマネージャ README」 の[fast path](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76)および「PostgreSQL ドキュメント」の[pg-locks](https://www.postgresql.org/docs/9.3/view-pg-locks.html#AEN98195)を参照してください。
### ロックマネージャのスケーリング問題の例
この例では、`purchases`という名前のテーブルが 5 年分のデータを日ごとにパーティション化して保存しています。各パーティションには 2 つのインデックスがあります。次の一連のイベントが発生します。
1. 何日分ものデータをクエリすると、データベースは多くのパーティションを読み取る必要があります。
1. データベースは、各パーティションに対してロックエントリを作成します。パーティションインデックスがオプティマイザアクセスパスの一部である場合、データベースはそれらのロックエントリも作成します。
1. 同じバックエンドプロセスでリクエストされたロックエントリの数が`FP_LOCK_SLOTS_PER_BACKEND`の値である16より大きい場合、ロックマネージャは非高速パスロック方式を使用します。
最新のアプリケーションには何百ものセッションがあることがあります。同時セッションが適切なパーティションプルーニングを行わずに親を照会している場合、データベースは数百または数千の非高速パスロックを作成することがあります。通常、この同時実行が vCPUs の数よりも多いと、`LWLock:lock_manager`待機イベントが表示されます。
**注記**
`LWLock:lock_manager`待機イベントは、データベーススキーマのパーティションまたはインデックスの数とは関係ありません。代わりに、データベースが制御する必要がある非高速パスロックの数と関係しています。
## 待機時間が増加する原因の可能性
`LWLock:lock_manager`待機イベントが通常より頻繁に発生する場合は、おそらくパフォーマンスの問題を示しており、突然のスパイクが発生する原因として最も可能性が高いものは次のとおりです。
+ 同時アクティブセッションは、高速パスロックを使用しないクエリを実行しています。また、これらのセッション数が最大 vCPU を超えています。
+ 多数の同時アクティブセッションが、大きくパーティション化されたテーブルにアクセスしています。各パーティションには複数のインデックスがあります。
+ データベースで接続ストームが発生しています。デフォルトでは、一部のアプリケーションと接続プールソフトウェアは、データベースが遅い場合により多くの接続を作成します。これは問題を悪化させます。接続ストームが発生しないように接続プールソフトウェアをチューニングします。
+ 多数のセッションが、パーティションをプルーニングせずに親テーブルをクエリします。
+ データ定義言語 (DDL)、データ操作言語 (DML)、またはメンテナンスコマンドは、頻繁にアクセスまたは変更されるビジーリレーションあるいはタプルのいずれかを排他的にロックします。
## アクション
`CPU`待機イベントが発生する場合、必ずしもパフォーマンスの問題を示しているとは限りません。パフォーマンスが低下し、この待機イベントが DB ロードを支配している場合にのみ、このイベントに応答します。
**Topics**
+ [
### パーティションプルーニングを使用する
](#wait-event.lw-lock-manager.actions.pruning)
+ [
### 不要なインデックスを削除する
](#wait-event.lw-lock-manager.actions.indexes)
+ [
### 高速パスロック用にクエリをチューニングする
](#wait-event.lw-lock-manager.actions.tuning)
+ [
### 他の待機イベントに合わせてチューニングする
](#wait-event.lw-lock-manager.actions.other-waits)
+ [
### ハードウェアのボトルネックを減らす
](#wait-event.lw-lock-manager.actions.hw-bottlenecks)
+ [
### 接続プーラーを使用する
](#wait-event.lw-lock-manager.actions.pooler)
+ [
### RDS for PostgreSQL バージョンのアップグレード
](#wait-event.lw-lock-manager.actions.pg-version)
### パーティションプルーニングを使用する
*パーティションプルーニング*とは、宣言によってパーティション分割されたテーブルに対するクエリ最適化戦略のことで、不要なパーティションをテーブルスキャンから除外し、パフォーマンスを向上させます。パーティションプルーニングは、デフォルトで有効になっています。オフになっている場合は、次のようにオンにします。
```
SET enable_partition_pruning = on;
```
クエリの`WHERE`節にパーティショニングに使用される列が含まれる場合は、パーティションのプルーニングを利用できます。詳細については、PostgreSQL のドキュメントの「[パーティションプルーニング](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING)」を参照してください。を参照してください。
### 不要なインデックスを削除する
データベースには、未使用またはほとんど使用されないインデックスが含まれている可能性があります。その場合は、それらの削除を検討します。次のいずれかを実行します。
+ 不要なインデックスを見つける方法については、PostgreSQL wikiの「[未使用のインデックス](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes)」を参照してください。
+ PG コレクタを実行します。この SQL スクリプトは、データベース情報を収集し、統合 HTML レポートに表示します。「未使用のインデックス」セクションをチェックします。詳細については、AWSLabs GitHub リポジトリの「[PG コレクター](https://github.com/awslabs/pg-collector)」を参照してください。
### 高速パスロック用にクエリをチューニングする
クエリで高速パスロックが使用されているかどうかを調べるには、`pg_locks`テーブルの`fastpath`列にクエリを実行します。クエリで高速パスロックを使用していない場合は、クエリあたりのリレーション数を 16 未満に減らしてください。
### 他の待機イベントに合わせてチューニングする
`LWLock:lock_manager`が上位待機のリストの第1位または 2 番目である場合、次の待機イベントもリストに表示されるかどうかを確認します。
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
上記のイベントがリスト内で上位に表示される場合は、まずこれらの待機イベントのチューニングを検討してください。これらのイベントは、`LWLock:lock_manager`のドライバーになり得ます。
### ハードウェアのボトルネックを減らす
CPU の枯渇や Amazon EBS 帯域幅の最大使用率など、ハードウェアのボトルネックが発生する可能性があります。このような場合は、ハードウェアのボトルネックを減らすことを検討してください。以下のアクションの場合を検討します。
+ インスタンスクラスをスケールアップします。
+ 大量の CPU とメモリを消費するクエリを最適化します。
+ アプリケーションロジックを変更します。
+ データをアーカイブします。
CPU、メモリ、および EBS ネットワーク帯域幅の詳細については、[Amazon RDS インスタンスタイプ](https://aws.amazon.com/rds/instance-types/)を参照してください。
### 接続プーラーを使用する
アクティブな接続の総数が最大 vCPU を超えると、インスタンスタイプがサポートできるより多くの OS プロセスが CPU を必要とします。このような場合は、接続プールの使用またはチューニングを検討してください。インスタンスタイプの vCPUs の詳細については、「[Amazon RDS インスタンスタイプ](https://aws.amazon.com/rds/instance-types/)」を参照してください。
接続プールの詳細については、次のリソースを参照してください。
+ [Amazon RDS Proxy ](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ *PostgreSQL ドキュメント*の[接続プールとデータソース](https://www.postgresql.org/docs/7.4/jdbc-datasource.html)
### RDS for PostgreSQL バージョンのアップグレード
現在使用している RDS for PostgreSQL のバージョンが 12 より前のものであれば、バージョン 12 以降にアップグレードします。PostgreSQL バージョン 12 以降では、パーティションメカニズムが改良されています。バージョン12の詳細については、[PostgreSQL 12.0 リリースノート]( https://www.postgresql.org/docs/release/12.0/)を参照してください。RDS for PostgreSQL のアップグレードの詳細については、「[RDS for PostgreSQL DB エンジンのアップグレード](USER_UpgradeDBInstance.PostgreSQL.md)」を参照してください。
# LWLock:pg\$1stat\$1statements
LWLock:pg\$1stat\$1statements 待機イベントは、`pg_stat_statements` 拡張機能が SQL ステートメントを追跡するハッシュテーブルで排他的ロックを取得したときに発生します。これは以下のようなシナリオで発生します。
+ 追跡されるステートメントの数が設定された `pg_stat_statements.max` パラメータ値に達し、さらに多くのエントリを格納する必要がある場合、拡張機能は呼び出し数をソートし、最も実行されていないステートメントの 5% を削除し、ハッシュに残りのエントリを再入力します。
+ `pg_stat_statements` がディスク上の `pgss_query_texts.stat` ファイルに `garbage collection` 操作を実行し、ファイルを書き換えた場合。
**Topics**
+ [
## サポート対象エンジンバージョン
](#apg-rpg-lwlockpgstat.supported)
+ [
## Context
](#apg-rpg-lwlockpgstat.context)
+ [
## 待機時間が増加する原因の可能性
](#apg-rpg-lwlockpgstat.causes)
+ [
## アクション
](#apg-rpg-lwlockpgstat.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
**pg\$1stat\$1statements 拡張機能を理解する** – pg\$1stat\$1statements 拡張機能は、ハッシュテーブル内の SQL ステートメントの実行統計を追跡します。拡張機能は、`pg_stat_statements.max` パラメータで定義された制限まで SQL ステートメントを追跡します。このパラメータは、pg\$1stat\$1statements ビューの最大行数に対応する、追跡できるステートメントの最大数を決定します。
**ステートメント統計の永続性** – 拡張機能は、以下によってインスタンスのすべての再起動でステートメント統計を保持します。
+ pg\$1stat\$1statements.stat という名前のファイルにデータを書き込む
+ pg\$1stat\$1statements.save パラメータを使用して永続性の動作を制御する
pg\$1stat\$1statements.save の設定と動作。
+ on (デフォルト): 統計はシャットダウン時に保存され、サーバー起動時に再ロードされる
+ off: 統計はシャットダウン時に保存されず、サーバー起動時に再ロードされない
**クエリテキストストレージ** – 拡張機能は、追跡されたクエリのテキストを `pgss_query_texts.stat` という名前のファイルに保存します。このファイルは、ガベージコレクションが発生する前に、追跡されるすべての SQL ステートメントの平均サイズの 2 倍に増加する可能性があります。拡張機能では、クリーンアップオペレーションと `pgss_query_texts.stat` ファイルの書き換え中にハッシュテーブルに排他的ロックが必要です。
**ステートメントの割り当て解除プロセス** – 追跡されたステートメントの数が `pg_stat_statements.max` の制限に達し、新しいステートメントを追跡する必要がある場合、拡張機能は以下の処理を行います。
+ ハッシュテーブルで排他的ロック (LWLock:pg\$1stat\$1statements) を取得します。
+ 既存のデータをローカルメモリにロードします。
+ 呼び出しの数に基づいてクイックソートを実行します。
+ 最小呼び出しステートメント (下位 5%) を削除します。
+ ハッシュテーブルに残りのエントリを再入力します。
**ステートメントの割り当て解除のモニタリング** – PostgreSQL 14 以降では、pg\$1stat\$1statements\$1info ビューを使用してステートメントの割り当て解除をモニタリングできます。このビューには、新しいステートメントのスペースを確保するためにステートメントが割り当て解除された回数を示す dealloc 列が含まれています。
ステートメントの割り当て解除が頻繁に発生すると、ディスク上の `pgss_query_texts.stat` ファイルのガベージコレクションの頻度が高くなります。
## 待機時間が増加する原因の可能性
`LWLock:pg_stat_statements` の待機時間が長くなる一般的な原因は次のとおりです。
+ アプリケーションで使用される一意のクエリの数の増加。
+ `pg_stat_statements.max` パラメータ値が、使用されている一意のクエリの数と比較して小さい。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。`LWLock:pg_stat_statements` イベントは、Amazon RDS Performance Insights を使用するか、ビュー `pg_stat_activity` のクエリで特定することができます。
次の `pg_stat_statements` パラメータを調整して追跡動作を制御し、LWLock:pg\$1stat\$1statements の待機イベントを減らします。
**Topics**
+ [
### pg\$1stat\$1statements.track パラメータを無効にする
](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [
### pg\$1stat\$1statements.max パラメータを増やす
](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [
### pg\$1stat\$1statements.track\$1utility パラメータを無効にする
](#apg-rpg-lwlockpgstat.actions.disableutility)
### pg\$1stat\$1statements.track パラメータを無効にする
LWLock:pg\$1stat\$1statements 待機イベントがデータベースのパフォーマンスに悪影響を及ぼし、`pg_stat_statements` ビューをさらに分析して根本原因を特定する前に迅速な対応が必要な場合は、`pg_stat_statements.track` パラメータを `none` に設定することで無効にできます。これにより、ステートメント統計の収集が無効になります。
### pg\$1stat\$1statements.max パラメータを増やす
ディスク上の `pgss_query_texts.stat` ファイルの割り当て解除を減らし、ガベージコレクションを最小限に抑えるため、`pg_stat_statements.max` パラメータの値を増やします。デフォルト値は `5,000` です。
**注記**
`pg_stat_statements.max` パラメータは即時反映されません。これらのパラメータの変更を適用するには、DB インスタンスを再起動する必要があります。
### pg\$1stat\$1statements.track\$1utility パラメータを無効にする
pg\$1stat\$1statements ビューを分析して、`pg_stat_statements` によって追跡されるリソースを最も多く消費しているユーティリティコマンドを特定できます。
`pg_stat_statements.track_utility` パラメータは、SELECT、INSERT、UPDATE、DELETE、MERGE を除くすべてのコマンドを含むユーティリティコマンドをモジュールが追跡するかどうかを制御します。デフォルトでは、このパラメータは `on` に設定されます。
例えば、アプリケーションが本質的に一意である多くのセーブポイントクエリを使用する場合、ステートメントの割り当て解除が増加する可能性があります。これに対処するには、`pg_stat_statements.track_utility` パラメータを無効にして `pg_stat_statements` がセーブポイントクエリを追跡しないようにします。
**注記**
`pg_stat_statements.track_utility` パラメータは変更後、即時反映されます。データベースインスタンスを再起動することなく、その値を変更できます。
**Example pg\$1stat\$1statements での一意のセーブポイントクエリの例**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 では、ユーティリティコマンドの追跡にいくつかの機能強化が導入されています。
+ セーブポイント名が定数として表示されるようになりました。
+ 2 フェーズコミットコマンドのグローバルトランザクション ID (GID) が定数として表示されるようになりました。
+ DEALLOCATE ステートメントの名前は定数として表示されます。
+ CALL パラメータが定数として表示されるようになりました。
# LWLock:SubtransSLRU (LWLock:SubtransControlLock)
`LWLock:SubtransSLRU` および `LWLock:SubtransBuffer` 待機イベントは、セッションがサブトランザクション情報の単純最小使用時間 (SLRU) キャッシュへのアクセスを待っていることを示します。これは、トランザクションの可視性と親子関係を決定するときに発生します。
+ `LWLock:SubtransSLRU`: プロセスは、サブトランザクションのシンプルな最も長い時間使われていない (SLRU) キャッシュへのアクセスを待っています。バージョン 13 より前の RDS for PostgreSQL では、この待機イベントは `SubtransControlLock` と呼ばれます。
+ `LWLock:SubtransBuffer`: プロセスは、サブトランザクションのシンプルな最も長い時間使われていない (SLRU) バッファの I/O を待っています。バージョン 13 より前の RDS for PostgreSQL では、この待機イベントは `subtrans` と呼ばれます。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.lwlocksubtransslru.supported)
+ [
## Context
](#wait-event.lwlocksubtransslru.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.lwlocksubtransslru.causes)
+ [
## アクション
](#wait-event.lwlocksubtransslru.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
**サブトランザクションを理解する** – サブトランザクションは、PostgreSQL のトランザクション内のトランザクションです。ネストされたトランザクションとも呼ばれます。
サブトランザクションは通常、次の場合に作成されます。
+ `SAVEPOINT` コマンド
+ 例外ブロック (`BEGIN/EXCEPTION/END`)
サブトランザクションを使用すると、トランザクション全体に影響を与えることなく、トランザクションの一部をロールバックできます。これにより、トランザクション管理をきめ細かく制御できます。
**実装の詳細** – PostgreSQL は、メイントランザクション内のネストされた構造としてサブトランザクションを実装します。各サブトランザクションは独自のトランザクション ID を取得します。
実装の主な側面。
+ トランザクション ID は `pg_xact` で追跡されます。
+ 親子関係は `PGDATA` の `pg_subtrans` サブディレクトリに保存されます。
+ 各データベースセッションは、最大 `64` のアクティブなサブトランザクションを維持できます
+ この制限を超えると、サブトランザクションオーバーフローが発生します。サブトランザクション情報を取得するために、最も長い時間使われていない (SLRU) キャッシュにアクセスする必要があります
## 待機時間が増加する原因の可能性
サブトランザクション SLRU 競合の一般的な原因は次のとおりです。
+ **SAVEPOINT および EXCEPTION 処理の過剰な使用** – `EXCEPTION` ハンドラーを使用した PL/pgSQL プロシージャは、例外が発生するかどうかにかかわらず、暗黙的なセーブポイントを自動的に作成します。各 `SAVEPOINT` は新しいサブトランザクションを開始します。1 つのトランザクションが 64 を超えるサブトランザクションを蓄積すると、サブトランザクション SLRU オーバーフローがトリガーされます。
+ **ドライバーと ORM の設定** – `SAVEPOINT` の使用は、アプリケーションコードで明示的で行うことも、ドライバー設定を通じて暗黙的に行うこともできます。一般的に使用される ORM ツールやアプリケーションフレームワークの多くは、ネストされたトランザクションをネイティブにサポートしています。以下は一般的な例です。
+ JDBC ドライバーパラメータ `autosave` を `always` または `conservative` に設定すると、各クエリの前にセーブポイントが生成されます。
+ Spring Framework トランザクション定義を `propagation_nested` に設定した場合。
+ `requires_new: true` が設定されている場合の Rails。
+ `session.begin_nested` を使用する場合の SQLAlchemy。
+ ネストされた `atomic()` ブロックを使用する場合の Django。
+ `Savepoint` を使用する場合の GORM。
+ ロールバックレベル設定がステートメントレベルのロールバックに設定されている場合の psqlODBC (例: `PROTOCOL=7.4-2`)。
+ **長時間実行されるトランザクションとサブトランザクションを伴う高同時ワークロード** – 同時ワークロードが高く、長時間実行されるトランザクションとサブトランザクション中にサブトランザクション SLRU オーバーフローが発生すると、PostgreSQL の競合が増加します。これは、`LWLock:SubtransBuffer` および `LWLock:SubtransSLRU` ロックの昇格された待機イベントとして現れます。
## アクション
待機イベントの原因に応じたさまざまなアクションをお勧めします。一部のアクションは即時の打開策を提供しますが、他のアクションは調査と長期的な修正を必要とします。
**Topics**
+ [
### サブトランザクション使用状況のモニタリング
](#wait-event.lwlocksubtransslru.actions.monitor)
+ [
### メモリパラメータを設定する
](#wait-event.lwlocksubtransslru.actions.memory)
+ [
### 長時間のアクション
](#wait-event.lwlocksubtransslru.actions.longterm)
### サブトランザクション使用状況のモニタリング
PostgreSQL バージョン 16.1 以降では、次のクエリを使用して、バックエンドごとのサブトランザクション数とオーバーフローステータスをモニタリングします。このクエリは、バックエンド統計をアクティビティ情報と結合して、サブトランザクションを使用しているプロセスを示します。
```
SELECT a.pid, usename, query, state, wait_event_type,
wait_event, subxact_count, subxact_overflowed
FROM (SELECT id, pg_stat_get_backend_pid(id) pid, subxact_count, subxact_overflowed
FROM pg_stat_get_backend_idset() id
JOIN LATERAL pg_stat_get_backend_subxact(id) AS s ON true
) a
JOIN pg_stat_activity b ON a.pid = b.pid;
```
PostgreSQL バージョン 13.3 以降では、サブトランザクションキャッシュプレッシャーについて `pg_stat_slru` ビューをモニタリングします。次の SQL クエリは、Subtrans コンポーネントの SLRU キャッシュ統計を取得します。
```
SELECT * FROM pg_stat_slru WHERE name = 'Subtrans';
```
`blks_read` 値が一貫して増加すると、キャッシュされていないサブトランザクションのディスクアクセスが頻繁になり、SLRU キャッシュプレッシャーの可能性が示されます。
### メモリパラメータを設定する
PostgreSQL 17.1 以降では、`subtransaction_buffers` パラメータを使用してサブトランザクション SLRU キャッシュサイズを設定できます。次の設定例は、サブトランザクションバッファパラメータを設定する方法を示しています。
```
subtransaction_buffers = 128
```
このパラメータは、サブトランザクションコンテンツのキャッシュに使用される共有メモリの量を指定します (`pg_subtrans`)。単位なしで指定した場合、値は `BLCKSZ` バイトのブロックを表し、通常はそれぞれ 8KB です。例えば、値を 128 に設定すると、サブトランザクションキャッシュに 1MB (128 \$1 8kB) のメモリが割り当てられます。
**注記**
このパラメータをクラスターレベルで設定することで、すべてのインスタンスの整合性を維持できます。特定のワークロード要件とインスタンスクラスに適した値をテストして調整します。パラメータの変更を有効にするには、ライターインスタンスを再起動する必要があります。
### 長時間のアクション
+ **アプリケーションコードと設定の確認** – アプリケーションコードとデータベースドライバーの設定で、明示的および暗黙的な `SAVEPOINT` 使用状況とサブトランザクションの一般的な使用状況の両方を確認します。64 を超えるサブトランザクションを生成する可能性のあるトランザクションを特定します。
+ **セーブポイント使用量の削減** – トランザクションでのセーブポイントの使用を最小限に抑えます。
+ EXCEPTION ブロックを使用して PL/pgSQL の手順と関数を確認します。EXCEPTION ブロックは暗黙的なセーブポイントを自動的に作成し、サブトランザクションのオーバーフローにつながる可能性があります。各 EXCEPTION 句は、実行中に例外が実際に発生したかどうかに関係なく、サブトランザクションを作成します。
**Example**
例 1: 問題のある EXCEPTION ブロックの使用
次のコード例は、複数のサブトランザクションを作成する問題のある EXCEPTION ブロックの使用を示しています。
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
BEGIN
-- This creates a subtransaction for each iteration
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW());
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
EXCEPTION
WHEN unique_violation THEN
-- Handle duplicate audit entries
UPDATE user_audit
SET timestamp = NOW()
WHERE user_id = user_record.id AND action = 'processed';
END;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
次の改善されたコード例では、例外処理の代わりに UPSERT を使用することで、サブトランザクションの使用を削減しています。
```
CREATE OR REPLACE FUNCTION process_user_data()
RETURNS void AS $$
DECLARE
user_record RECORD;
BEGIN
FOR user_record IN SELECT * FROM users LOOP
-- Use UPSERT to avoid exception handling
INSERT INTO user_audit (user_id, action, timestamp)
VALUES (user_record.id, 'processed', NOW())
ON CONFLICT (user_id, action)
DO UPDATE SET timestamp = NOW();
UPDATE users
SET last_processed = NOW()
WHERE id = user_record.id;
END LOOP;
END;
$$ LANGUAGE plpgsql;
```
**Example**
例 2: STRICT 例外ハンドラー
次のコード例は、NO\$1DATA\$1FOUND を使用した EXCEPTION 処理の問題を示しています。
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
BEGIN
-- STRICT causes an exception if no rows or multiple rows found
SELECT email INTO STRICT user_email
FROM users
WHERE id = p_user_id;
RETURN user_email;
EXCEPTION
WHEN NO_DATA_FOUND THEN
RETURN 'Email not found';
END;
END;
$$ LANGUAGE plpgsql;
```
次の改善されたコード例では、例外処理の代わりに IF NOT FOUND を使用してサブトランザクションを回避します。
```
CREATE OR REPLACE FUNCTION get_user_email(p_user_id INTEGER)
RETURNS TEXT AS $$
DECLARE
user_email TEXT;
BEGIN
SELECT email INTO user_email
FROM users
WHERE id = p_user_id;
IF NOT FOUND THEN
RETURN 'Email not found';
ELSE
RETURN user_email;
END IF;
END;
$$ LANGUAGE plpgsql;
```
+ JDBC ドライバー – `autosave` パラメータを `always` または `conservative` に設定すると、各クエリの前にセーブポイントが生成されます。`never` 設定がアプリケーションに受け入れられるかどうかを評価します。
+ PostgreSQL ODBC ドライバー (psqlODBC) — ロールバックレベル設定 (ステートメントレベルのロールバック用) は、ステートメントのロールバック機能を有効にするための暗黙的なセーブポイントを作成します。トランザクションレベルのロールバックがアプリケーションで許容されるかどうかを評価します。
+ ORM トランザクション設定を確認する
+ セーブポイントを必要としない代替エラー処理戦略を検討する
+ **トランザクション設計の最適化** – 過剰なネストを回避し、サブトランザクションオーバーフロー条件の可能性を減らすために、トランザクションを再構築します。
+ **長時間実行されるトランザクションの削減** – 長時間実行されるトランザクションでは、サブトランザクション情報を長く保持することで、サブトランザクションの問題が悪化する可能性があります。Performance Insights メトリクスをモニタリングし、アイドル状態のトランザクションを自動的に終了するように `idle_in_transaction_session_timeout` パラメータを設定します。
+ Performance Insights メトリクスのモニタリング – `idle_in_transaction_count` (トランザクション状態でアイドル状態のセッション数) や `idle_in_transaction_max_time` (アイドル状態にある最長時間のトランザクションの継続時間) などのメトリクスを追跡して、長時間実行されるトランザクションを検出します。
+ `idle_in_transaction_session_timeout` の設定 – 指定した期間後にアイドル状態のトランザクションを自動的に終了するように、パラメータグループにこのパラメータを設定します。
+ プロアクティブモニタリング – `LWLock:SubtransBuffer` および `LWLock:SubtransSLRU` 待機イベントの発生頻度をモニタリングし、サブトランザクション関連の競合が重大になる前に検出します。
# Timeout:PgSleep
`Timeout:PgSleep`イベントは、サーバプロセスが`pg_sleep`関数を呼び出し、スリープタイムアウトの期限切れを待っているときに発生します。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.timeoutpgsleep.context.supported)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.timeoutpgsleep.causes)
+ [
## アクション
](#wait-event.timeoutpgsleep.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## 待機時間が増加する原因の可能性
この待機イベントは、アプリケーション、ストアド関数、またはユーザーが次のいずれかの関数を呼び出す SQL ステートメントを発行したときに発生します。
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
前述の関数は、指定された秒数が経過するまで実行を遅らせます。例えば、`SELECT pg_sleep(1)` は 1 秒間一時停止します。詳細については、PostgreSQL のドキュメントの「[実行の遅延](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY)」を参照してください。
## アクション
`pg_sleep`関数を実行していたステートメントを特定します。関数の使用が適切かどうかを判断します。
# Timeout:VacuumDelay
`Timeout:VacuumDelay` イベントは、バキューム I/O のコスト制限を超え、バキュームプロセスがスリープ状態になったことを示します。バキュームオペレーションは、それぞれのコスト遅延パラメータで指定された期間停止し、その後動作を再開します。手動バキュームコマンドの場合、遅延は `vacuum_cost_delay` パラメータで指定されます。自動バキュームデーモンの場合、遅延は `autovacuum_vacuum_cost_delay parameter.` で指定されます。
**Topics**
+ [
## サポート対象エンジンバージョン
](#wait-event.timeoutvacuumdelay.context.supported)
+ [
## Context
](#wait-event.timeoutvacuumdelay.context)
+ [
## 待機時間が増加する原因の可能性
](#wait-event.timeoutvacuumdelay.causes)
+ [
## アクション
](#wait-event.timeoutvacuumdelay.actions)
## サポート対象エンジンバージョン
この待機イベント情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
## Context
PostgreSQL には、自動バキュームデーモンと手動バキュームコマンドがあります。自動バキュームプロセスは、RDS for PostgreSQL DB インスタンスでデフォルトで「オン」になっています。手動バキュームコマンドは、dead タプルのテーブルの削除や、新しい統計の生成など、必要に応じて使用されます。
バキューム処理中は、PostgreSQL では内部カウンターを使用して、システムがさまざまな I/O オペレーションを実行する際の推定コストを追跡します。カウンターがコスト制限パラメータで指定された値に達すると、そのオペレーションを実行するプロセスは、コスト遅延パラメータで指定された短時間の間スリープ状態になります。その後、カウンターをリセットしてオペレーションを続行します。
バキュームプロセスには、リソース消費量を調整するために使用できるパラメータがあります。自動バキュームコマンドと手動バキュームコマンドには、コスト制限値を設定するための独自のパラメータがあります。コスト遅延、つまり制限に達したときにバキュームをスリープ状態にする時間を指定する独自のパラメータもあります。このように、コスト遅延パラメータは、リソース消費のスロットリングメカニズムとして機能します。以下の一覧で、これらのパラメータの説明を参照できます。
**自動バキュームデーモンのスロットリングに影響するパラメータ**
+ `[autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)` – 自動バキュームオペレーションで使用するコスト制限値を指定します。このパラメータの設定を増やすと、バキュームプロセスが使用するリソースが増え、`Timeout:VacuumDelay` 待機イベントが減ります。
+ `[autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)` – 自動バキュームオペレーションで使用するコスト遅延値を指定します。デフォルト値は 2 ミリ秒です。遅延パラメータを 0 に設定すると、スロットリングメカニズムがオフになり、`Timeout:VacuumDelay` 待機イベントは表示されなくなります。
詳細については、「PostgreSQL のドキュメント」の「[Automatic Vacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)」(自動バキューム処理) を参照してください。
**手動バキュームプロセスのスロットリングに影響するパラメータ**
+ `vacuum_cost_limit` – バキューム処理をスリープ状態にするしきい値。デフォルトの制限値は 200 です。この数値は、さまざまなリソースが必要とする追加の I/O の累積コスト見積もりを表します。この値を増やすと、`Timeout:VacuumDelay` 待機イベントの数が減ります。
+ `vacuum_cost_delay` – バキュームのコスト制限に達したときに、バキュームプロセスがスリープになる時間。デフォルト設定は 0 で、この機能はオフになります。この機能を有効にするミリ秒数を整数値で指定できますが、デフォルト設定のままにしておくことをお勧めします。
`vacuum_cost_delay` パラメータの詳細については、PostgreSQL ドキュメントの「[リソース消費](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST)」を参照してください。
RDS for PostgreSQL で自動バキュームを設定し、使用する方法の詳細については、「[Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)」を参照してください。
## 待機時間が増加する原因の可能性
`Timeout:VacuumDelay` は、バキュームのスリープ時間を制御するコスト制限パラメータ設定 (`vacuum_cost_limit`、`autovacuum_vacuum_cost_limit`) と、コスト遅延パラメータ (`vacuum_cost_delay`、`autovacuum_vacuum_cost_delay`) のバランスの影響を受けます。コスト制限のパラメータ値を上げると、バキュームがスリープ状態になる前に利用できるリソースが増えます。その結果、`Timeout:VacuumDelay` 待機イベントが少なくなります。いずれかの遅延パラメータを増やすと、これまでよりも頻繁に、長期間 `Timeout:VacuumDelay` 待機イベントが発生します。
`autovacuum_max_workers` パラメータ設定により、`Timeout:VacuumDelay` の数を増やすこともできます。自動バキュームワーカープロセスを追加するごとに内部カウンターメカニズムに影響を与えるため、単一の自動バキュームワーカープロセスを使用する場合よりも早く上限に達する場合があります。コスト制限に早く達するとコスト遅延がより頻繁に発生し、結果的に `Timeout:VacuumDelay` 待機イベントが増えます。詳細については、PostgreSQL ドキュメントの「[autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)」を参照してください。
バキュームが大きなオブジェクトの処理を完了するまでに時間がかかることがあるため、500 GB 以上の大きなオブジェクトでもこの待機イベントが発生します。
## アクション
想定どおりにバキュームオペレーションが完了すれば、修復は不要です。つまり、この待機イベントは、必ずしも問題を示すわけではありません。これは、処理を完了する必要のある他のプロセスにリソースを割り当てることができるように、バキュームが遅延パラメータで指定された時間だけスリープ状態になっていることを示しています。
バキュームオペレーションをより早く完了させる場合は、遅延パラメータを下げることができます。これにより、バキュームのスリープ時間が短縮されます。
# Amazon DevOps Guru のプロアクティブインサイトによる RDS for PostgreSQL のチューニング
DevOps Guru のプロアクティブインサイトは、問題の原因となる可能性がある RDS for PostgreSQL DB インスタンスの条件を検出して、問題が発生する前に通知します。プロアクティブインサイトは、トランザクション接続で長時間アイドル状態になっている場合にアラートを送信できます。トランザクション接続で長時間アイドル状態になっている場合のトラブルシューティングの詳細については、「[データベースがトランザクション接続で長時間アイドル状態になっている](#proactive-insights.idle-txn)」を参照してください。
DevOps Guru では、次のことができます。
+ データベース構成を一般的な推奨設定と照合することで、データベースに関する多くの一般的な問題を防ぎます。
+ 未チェックのままにしておくと、後で大きな問題につながる可能性があるフリート内の重大な問題について警告します。
+ 新しく発見された問題について警告します。
すべてのプロアクティブインサイトには、問題の原因の分析と是正措置の推奨事項が含まれています。
Amazon DevOps Guru for Amazon RDS の詳細については、「[Amazon DevOps Guru for Amazon RDS でパフォーマンスの異常を分析する](devops-guru-for-rds.md)」を参照してください。
## データベースがトランザクション接続で長時間アイドル状態になっている
データベースへの接続が 1800 秒以上 `idle in transaction` 状態です。
**Topics**
+ [
### サポート対象エンジンバージョン
](#proactive-insights.idle-txn.context.supported)
+ [
### Context
](#proactive-insights.idle-txn.context)
+ [
### この問題の考えられる原因
](#proactive-insights.idle-txn.causes)
+ [
### アクション
](#proactive-insights.idle-txn.actions)
+ [
### 関連するメトリクス
](#proactive-insights.idle-txn.metrics)
### サポート対象エンジンバージョン
このインサイト情報は、RDS for PostgreSQL のすべてのバージョンでサポートされています。
### Context
`idle in transaction` 状態のトランザクションがロックを保持していて、他のクエリをブロックしている可能性があります。また、`VACUUM` (自動バキュームを含む) がデッド行をクリーンアップするのを妨げて、インデックスやテーブルが肥大化したり、トランザクション ID がラップアラウンドしたりします。
### この問題の考えられる原因
インタラクティブセッションで BEGIN または START TRANSACTION を使用して開始されたトランザクションが、COMMIT、ROLLBACK、または END コマンドを使用しても終了していません。これにより、トランザクションは `idle in transaction` 状態に移行します。
### アクション
`pg_stat_activity` クエリを実行すると、アイドル状態のトランザクションを見つけることができます。
SQL クライアントで、次のクエリを実行して、`idle in transaction` 状態にあるすべての接続を一覧表示し、継続時間順に並べ替えます。
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
インサイトの原因に応じて、異なるアクションをお勧めします。
**Topics**
+ [
#### 接続を終了する
](#proactive-insights.idle-txn.actions.end-txn)
+ [
#### 接続を作成する
](#proactive-insights.idle-txn.actions.end-connection)
+ [
#### idle\$1in\$1session\$1timeout パラメータを設定する
](#proactive-insights.idle-txn.actions.parameter)
+ [
#### AUTOCOMMIT のステータスを確認する
](#proactive-insights.idle-txn.actions.autocommit)
+ [
#### アプリケーションコード内のトランザクションロジックを確認する
](#proactive-insights.idle-txn.actions.app-logic)
#### 接続を終了する
インタラクティブセッションで BEGIN または START TRANSACTION を使用してトランザクションを開始すると、トランザクションは `idle in transaction` 状態に移行します。COMMIT、ROLLBACK、END コマンドを実行してトランザクションを終了するか、接続を完全に切断してトランザクションをロールバックするまで、この状態のままになります。
#### 接続を作成する
次のクエリを使用して、アイドル状態のトランザクションがある接続を終了します。
```
SELECT pg_terminate_backend(pid);
```
pid は接続のプロセス ID です。
#### idle\$1in\$1session\$1timeout パラメータを設定する
パラメータグループの `idle_in_transaction_session_timeout` パラメータを設定します。このパラメータを設定する利点は、手動操作を行わなくても、長時間アイドル状態になっているトランザクションを終了できることです。このパラメータの詳細については、「[PostgreSQL documentation](https://www.postgresql.org/docs/current/runtime-config-client.html)」(PostgreSQL ドキュメント) を参照してください。
接続が終了し、指定した時間を超えてトランザクションが idle\$1in\$1transaction 状態にあると、PostgreSQL ログファイルに次のメッセージが報告されます。
```
FATAL: terminating connection due to idle in transaction timeout
```
#### AUTOCOMMIT のステータスを確認する
AUTOCOMMIT は、デフォルトで有効になっています。ただし、クライアントで誤ってオフにした場合は、必ずオンに戻してください。
+ psql クライアントで次のコマンドを実行します。
```
postgres=> \set AUTOCOMMIT on
```
+ pgadmin で、下矢印から AUTOCOMMIT オプションを選択してオンにします。
![\[pgadmin で、AUTOCOMMIT を選択して、オンにします。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/apg-insight-pgadmin-autocommit.png)
#### アプリケーションコード内のトランザクションロジックを確認する
アプリケーションロジックを調べ手、問題がない確認します。以下のアクションの場合を検討します。
+ アプリケーションで JDBC auto commit が true に設定されているかどうかを確認します。また、コード内で明示的な `COMMIT` コマンドを使用することも検討してください。
+ エラー処理ロジックをチェックして、エラー後にトランザクションがクローズされるかどうかを確認します。
+ トランザクションが開いているときに、アプリケーションがクエリによって返された行の処理に時間がかかるかどうかを確認します。その場合は、行を処理する前にトランザクションを閉じるようにアプリケーションをコーディングすることを検討してください。
+ トランザクションに長時間実行される操作が多数含まれていないか確認します。その場合は、1 つのトランザクションを複数のトランザクションに分割します。
### 関連するメトリクス
以下の PI メトリクスがこのインサイトに関連しています。
+ idle\$1in\$1transaction\$1count - `idle in transaction` 状態にあるセッション数。
+ idle\$1in\$1transaction\$1max\$1time - `idle in transaction` 状態で最も長く実行されているトランザクションの継続時間。
# Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用する
PostgreSQL は、さまざまな拡張機能やモジュールをインストールすることで、機能を拡張することができます。例えば、空間データを操作するには、PostGIS 拡張機能をインストールして使用します。詳細については、「[PostGIS 拡張機能を使用した空間データの管理](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)」を参照してください。別の例として、非常に大きなテーブルへのデータ入力を改善する場合は、`pg_partman` 拡張機能を使用したデータのパーティション化を検討できます。詳細については[pg\$1partman エクステンションによる PostgreSQL パーティションの管理](PostgreSQL_Partitions.md)を参照してください。
**注記**
RDS for PostgreSQL は、DB インスタンスに追加できる `pg_tle` 拡張機能を通じて、Trusted Language Extensions for PostgreSQL をサポートしています。この拡張を使用することで、開発者は安全な環境で独自の PostgreSQL 拡張を作成できるため、セットアップと設定の要件が簡素化されます。`pg_tle` 拡張機能をサポートする RDS for PostgreSQL のバージョンと詳細については、「[Trusted Language Extensions for PostgreSQL を使用した操作](PostgreSQL_trusted_language_extension.md)」を参照してください。
場合によっては、拡張機能をインストールする代わりに、Aurora PostgreSQL DB クラスターのカスタム DB クラスターパラメータグループの `shared_preload_libraries` リストに特定のモジュールを追加することもできます。通常、デフォルトの DB クラスターパラメータグループでは、`pg_stat_statements` のみが読み込まれますが、リストに追加できるモジュールは他にもいくつかあります。例えば、[PostgreSQL pg\$1cron エクステンションによるメンテナンスのスケジューリング](PostgreSQL_pg_cron.md) で説明されているように、`pg_cron` モジュールを追加することでスケジュール機能を追加できます。別の例として、`auto_explain` モジュールをロードすることでクエリ実行計画を記録できます。詳細については、AWS ナレッジセンターの「[クエリ実行計画のログ記録](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#)」をご覧ください。
RDS for PostgreSQL のバージョンによっては、拡張機能をインストールする際に、以下のような `rds_superuser` の権限が必要になる場合があります。
+ RDS for PostgreSQL バージョン 12 以前のバージョンでは、拡張機能をインストールする際に `rds_superuser` の権限が必要となります。
+ RDS for PostgreSQL バージョン 13 以降のバージョンでは、特定のデータベースインスタンスに対する作成権限を持つユーザー (ロール) は、*信頼できる拡張機能*をインストールして使用することができます。信頼できる拡張機能のリストについては、「[PostgreSQL 信頼できるエクステンション](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.Extensions.Trusted)」を参照してください。
また、RDS for PostgreSQL DBインスタンスにインストール可能な拡張機能は、`rds.allowed_extensions` パラメータにリストアップして、正確に指定することができます。詳細については、「[PostgreSQL エクステンションのインストールを制限する](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction)」を参照してください。
`rds_superuser` ロールの詳細については、「[PostgreSQL のロールとアクセス権限について](Appendix.PostgreSQL.CommonDBATasks.Roles.md)」を参照してください。
**Topics**
+ [
# orafce 拡張機能の関数の使用
](Appendix.PostgreSQL.CommonDBATasks.orafce.md)
+ [
# PostgreSQL での Amazon RDS 委任拡張機能サポートの使用
](RDS_delegated_ext.md)
+ [
# pg\$1partman エクステンションによる PostgreSQL パーティションの管理
](PostgreSQL_Partitions.md)
+ [
# pgAudit を使用してデータベースのアクティビティを記録する
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [
# PostgreSQL pg\$1cron エクステンションによるメンテナンスのスケジューリング
](PostgreSQL_pg_cron.md)
+ [
# pglogical を使用してインスタンス間でデータを同期する
](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [
# pgactive を使用したアクティブ/アクティブレプリケーションのサポート
](Appendix.PostgreSQL.CommonDBATasks.pgactive.md)
+ [
# pg\$1repack 拡張機能を使用して、テーブルやインデックスの膨張を抑制する
](Appendix.PostgreSQL.CommonDBATasks.pg_repack.md)
+ [
# PLV8 拡張機能のアップグレードおよび使用
](PostgreSQL.Concepts.General.UpgradingPLv8.md)
+ [
# PL/Rust を使って Rust 言語で PostgreSQL 関数を記述する
](PostgreSQL.Concepts.General.Using.PL_Rust.md)
+ [
# PostGIS 拡張機能を使用した空間データの管理
](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
# orafce 拡張機能の関数の使用
orafce 拡張機能は、Oracle データベースから関数とパッケージのサブセットをエミュレートする関数と演算子を提供します。Oracle 拡張機能を使用すると、Oracle アプリケーションを PostgreSQL に簡単に移植できます。この拡張機能は、RDS for PostgreSQL バージョン 9.6.6 以降でサポートされています。orafce についての詳細は、GitHub で「[orafce](https://github.com/orafce/orafce)」を参照してください。
**注記**
RDS for PostgreSQL では、orafce 拡張機能の一部である `utl_file` パッケージがサポートされていません。これは、`utl_file` スキーマ関数が、基になるモストへのスーパーユーザーアクセスに必要なオペレーティングシステムテキストファイルで読み書き操作を実行するためです。マネージド型サービスの RDS for PostgreSQL では、ホストアクセスが許可されません。
**orafce エクステンションを使用するには**
1. DB インスタンスの作成で使用したプライマリユーザー名を使用して DB インスタンスに接続します。
同じ DB インスタンスにある別のデータベースで orafce をオンにする場合は、`/c dbname` psql コマンドを使用します。このコマンドを使用すると、接続を開始した後にプライマリデータベースから変更できます。
1. `CREATE EXTENSION` ステートメントを使用して、orafce 拡張機能をオンにします。
```
CREATE EXTENSION orafce;
```
1. `ALTER SCHEMA` ステートメントを使用して、oracle スキーマの所有権を rds\$1superuser ロールに転送します。
```
ALTER SCHEMA oracle OWNER TO rds_superuser;
```
oracle スキーマの所有者のリストを表示する場合は、`\dn` psql コマンドを使用します。
# PostgreSQL での Amazon RDS 委任拡張機能サポートの使用
PostgreSQL に対して Amazon RDS 委任拡張機能のサポートを使用すると、拡張機能管理を `rds_superuser` である必要のないユーザーに委任できます。この委任拡張機能のサポートにより、`rds_extension` という新しいロールが作成され、他の拡張機能を管理するには、これをユーザーに割り当てる必要があります。このロールは、拡張機能を作成、更新、削除できます。
RDS DB インスタンスにインストール可能な拡張機能は、`rds.allowed_extensions` パラメータにそれらをリストアップして指定することができます。詳細については、「[Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用する](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html)」を参照してください。
`rds.allowed_delegated_extensions` パラメータを使用して、`rds_extension` ロールでユーザーが管理できる拡張機能のリストを制限できます。
委任拡張機能のサポートは、次のバージョンで利用できます。
+ すべての上位バージョン
+ 16.4 以降の 16 バージョン
+ 15.8 以降の 15 バージョン
+ 14.13 以降の 14 バージョン
+ 13.16 以降の 13 バージョン
+ 12.20 以降の 12 バージョン
**Topics**
+ [
## ユーザーに対する委任拡張機能のサポートの有効化
](#RDSPostgreSQL.delegated_ext_mgmt)
+ [
## PostgreSQL での RDS 委任拡張機能サポートで使用される設定
](#RDSPostgreSQL.delegated_ext_config)
+ [
## 委任拡張機能のサポートの無効化
](#RDSPostgreSQL.delegated_ext_disable)
+ [
## Amazon RDS 委任拡張機能サポートの使用のメリット
](#RDSPostgreSQL.delegated_ext_benefits)
+ [
## PostgreSQL での Amazon RDS 委任拡張機能サポートの制限
](#RDSPostgreSQL.delegated_ext_limit)
+ [
## 特定の拡張機能に必要なアクセス許可
](#RDSPostgreSQL.delegated_ext_perm)
+ [
## セキュリティに関する考慮事項
](#RDSPostgreSQL.delegated_ext_sec)
+ [
## DROP EXTENSION CASCADE を無効化
](#RDSPostgreSQL.delegated_ext_drop)
+ [
## 委任拡張機能サポートを使用して追加できる拡張機能の例
](#RDSPostgreSQL.delegated_ext_support)
## ユーザーに対する委任拡張機能のサポートの有効化
ユーザーに対して委任拡張機能のサポートを有効にするには、以下を実行する必要があります。
1. **ユーザーに `rds_extension` ロールを付与する** – `rds_superuser` としてデータベースに接続し、次のコマンドを実行します。
```
Postgres => grant rds_extension to user_name;
```
1. **委任されたユーザーが管理できる拡張機能のリストを設定する** – `rds.allowed_delegated_extensions` では、DB クラスターパラメータで `rds.allowed_extensions` を使用して、使用可能な拡張機能のサブセットを指定できます。これは、次のいずれかのレベルで実行できます。
+ クラスターまたはインスタンスパラメータグループで、AWS マネジメントコンソール または API を使用します。詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
+ データベースレベルで次のコマンドを使用します。
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ ユーザーレベルで次のコマンドを使用します。
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**注記**
`rds.allowed_delegated_extensions` 動的パラメータを変更した後にデータベースを再起動する必要はありません。
1. **拡張機能の作成プロセス中に作成されたオブジェクトへのアクセスを委任されたユーザーに許可する** – 特定の拡張機能では、`rds_extension` ロールを持つユーザーがオブジェクトにアクセスする前に、追加のアクセス許可を付与する必要があるオブジェクトが作成されます。`rds_superuser` は、それらのオブジェクトへのアクセス権を委任されたユーザーに付与する必要があります。オプションの 1 つは、イベントトリガーを使用して、委任されたユーザーにアクセス許可を自動的に付与することです。
**イベントトリガーの例**
`rds_extension` を持つ委任ユーザーに、拡張機能の作成によって作成されたオブジェクトに対するアクセス許可の設定を必要とする拡張機能の使用を許可する場合は、次のイベントトリガーの例をカスタマイズし、委任されたユーザーに完全な機能へのアクセスを許可する拡張機能のみを追加できます。このイベントトリガーは template1 (デフォルトのテンプレート) で作成できるため、template1 から作成されたすべてのデータベースにそのイベントトリガーがあります。委任されたユーザーが拡張機能をインストールすると、このトリガーは拡張機能によって作成されたオブジェクトの所有権を自動的に付与します。
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## PostgreSQL での RDS 委任拡張機能サポートで使用される設定
| 設定名 | 説明 | デフォルト値 | 注意事項 | アクセス許可を変更または付与できるユーザー |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | このパラメータは、rds\$1extension ロールがデータベースで管理できる拡張機能を制限します。rds.allowed\$1extensions のサブセットである必要があります。 | 空の文字列 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/RDS_delegated_ext.html) このパラメータの設定の詳細については、「[ユーザーに対する委任拡張機能のサポートの有効化](#RDSPostgreSQL.delegated_ext_mgmt)」を参照してください。 | rds\$1superuser |
| `rds.allowed_extensions` | このパラメータにより、カスタマーは RDS DB インスタンスにインストールできる拡張機能を制限できます。詳細については、「[PostgreSQL 拡張機能のインストールの制限](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction)」を参照してください。 | "\$1" | デフォルトでは、このパラメータは「\$1」に設定されています。つまり、RDS for PostgreSQL および Aurora PostgreSQL でサポートされているすべての拡張機能は、必要な権限を持つユーザーが作成できます。 空の場合、RDS DB インスタンスに拡張機能をインストールできないことを意味します。 | 管理者 |
| `rds-delegated_extension_allow_drop_cascade` | このパラメータは、`rds_extension` を持つユーザーがカスケードオプションを使用して拡張機能を削除する機能を制御します。 | 化 | デフォルトで、`rds-delegated_extension_allow_drop_cascade` は `off` に設定されています。つまり、`rds_extension` を持つユーザーは、カスケードオプションを使用して拡張機能を削除することはできません。 その機能を許可するには、`rds.delegated_extension_allow_drop_cascade` パラメータを `on` に設定する必要があります。 | rds\$1superuser |
## 委任拡張機能のサポートの無効化
**部分的にオフにする**
委任されたユーザーは、新しい拡張機能を作成することはできませんが、既存の拡張機能を更新することはできます。
+ DB クラスターパラメータグループでデフォルト値に `rds.allowed_delegated_extensions` をリセットします。
+ データベースレベルで次のコマンドを使用します。
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ ユーザーレベルで次のコマンドを使用します。
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**すべてオフにする**
ユーザーから `rds_extension` ロールを取り消すと、ユーザーは標準のアクセス許可に戻ります。ユーザーは拡張機能を作成、更新、削除できなくなります。
```
postgres => revoke rds_extension from user_name;
```
## Amazon RDS 委任拡張機能サポートの使用のメリット
PostgreSQL に対して Amazon RDS 委任拡張機能のサポートを使用すると、拡張機能管理を `rds_superuser` ロールを持たないユーザーに対してセキュアに委任できます。この機能には次の利点があります。
+ 選択したユーザーに拡張機能管理を簡単に委任できます。
+ これには `rds_superuser` ロールは不要です。
+ 同じ DB クラスター内の異なるデータベースに対して、異なる拡張機能セットをサポートする機能を提供します。
## PostgreSQL での Amazon RDS 委任拡張機能サポートの制限
+ 拡張機能の作成プロセス中に作成されたオブジェクトは、拡張機能が正しく機能するために追加の権限が必要になる場合があります。
+ 一部の拡張機能は、デフォルトで `log_fdw`、`pg_cron`、`pg_tle`、`pgactive`、`pglogical`、`postgis_raster`、`postgis_tiger_geocoder`、`postgis_topology` などの委任された拡張機能ユーザーが管理することはできません。
## 特定の拡張機能に必要なアクセス許可
次の拡張機能を作成、使用、または更新するには、委任されたユーザーに次の関数、テーブル、スキーマに対する必要な権限が必要です。
| 所有権またはアクセス許可が必要な拡張機能 | 関数 | テーブル | スキーマ | テキスト検索ディクショナリ | Comment |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | なし | us\$1gaz、us\$1lex、us\$1lex、I.us\$1rules | なし | なし | なし |
| amcheck | bt\$1index\$1check、bt\$1index\$1parent\$1check | なし | なし | なし | なし |
| dict\$1int | なし | なし | なし | intdict | なし |
| pg\$1partman | なし | custom\$1time\$1partitions、part\$1config、part\$1config\$1sub | なし | なし | なし |
| pg\$1stat\$1statements | なし | なし | なし | なし | なし |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | なし | なし | なし |
| postgis\$1raster | なし | なし | なし | なし | なし |
| postgis\$1topology | なし | トポロジ、レイヤー | トポロジ | なし | 委任されたユーザーはデータベース所有者であること |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | なし | なし | なし | なし |
| rds\$1tools | role\$1password\$1encryption\$1type | なし | なし | なし | なし |
| postgis\$1tiger\$1geocoder | なし | geocode\$1settings\$1default, geocode\$1settings | tiger | なし | なし |
| pg\$1freespacemap | pg\$1freespace | なし | なし | なし | なし |
| pg\$1visibility | pg\$1visibility | なし | なし | なし | なし |
## セキュリティに関する考慮事項
`rds_extension` ロールを持つユーザーは、接続権限を持つすべてのデータベースの拡張機能を管理できることに注意してください。委任されたユーザーが 1 つのデータベースの拡張機能を管理する場合は、各データベースのパブリックからすべての権限を取り消し、その特定のデータベースの接続権限を委任されたユーザーに明示的に付与することをお勧めします。
ユーザーが複数のデータベースから情報にアクセスできる拡張機能がいくつかあります。これらの拡張機能を `rds.allowed_delegated_extensions` に追加する前に、`rds_extension` を付与するユーザーにクロスデータベース機能があることを確認してください。例えば、`postgres_fdw` と `dblink` は、同じインスタンスまたはリモートインスタンス上のデータベース間でクエリを実行する機能を提供します。`log_fdw` は postgres エンジンのログファイルを読み取ります。これらは、インスタンス内のすべてのデータベース用であり、複数のデータベースからのスロークエリやエラーメッセージが含まれている可能性があります。`pg_cron` は、DB インスタンスでスケジュールされたバックグラウンドジョブの実行を有効にし、別のデータベースで実行するようにジョブを設定できます。
## DROP EXTENSION CASCADE を無効化
`rds_extension` ロールを持つユーザーがカスケードオプションを使用して拡張機能を削除する機能は、`rds.delegated_extension_allow_drop_cascade` パラメータによって制御されます。デフォルトで、`rds-delegated_extension_allow_drop_cascade` は `off` に設定されています。つまり、`rds_extension` ロールを持つユーザーは、以下のクエリに示すように、カスケードオプションを使用して拡張機能を削除することはできません。
```
DROP EXTENSION CASCADE;
```
これにより、拡張機能に依存するオブジェクト、およびそれらのオブジェクトに依存するすべてのオブジェクトが自動的に削除されます。カスケードオプションを使用しようとすると、エラーが発生します。
その機能を許可するには、`rds.delegated_extension_allow_drop_cascade` パラメータを `on` に設定する必要があります。
`rds.delegated_extension_allow_drop_cascade` 動的パラメータを変更しても、データベースを再起動する必要はありません。これは、次のいずれかのレベルで実行できます。
+ クラスターまたはインスタンスパラメータグループで、AWS マネジメントコンソール または API を使用します。
+ データベースレベルで次のコマンドを使用する。
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ ユーザーレベルで次のコマンドを使用する。
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## 委任拡張機能サポートを使用して追加できる拡張機能の例
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# pg\$1partman エクステンションによる PostgreSQL パーティションの管理
PostgreSQL テーブルパーティションは、データ入力とレポートにおける高性能な処理のためのフレームワークを提供します。大量のデータを非常に速く入力する必要があるデータベースには、パーティションを使用します。またパーティションは、大きなテーブルでより高速のクエリを提供します。パーティションは、必要とする I/O リソースが少ないため、データベースインスタンスに影響を与えずにデータを維持するのに役立ちます。
パーティションを使用すると、データをカスタムサイズのチャンクに分割して処理することができます。例えば、時間単位、日単位、週単位、月単位、四半期単位、年単位、カスタム、またはこれらの組み合わせなどの範囲のパーティションの時系列データを選択できます。時系列データの例では、テーブルを時間単位でパーティション化した場合、各パーティションには 1 時間のデータが含まれます。時系列テーブルを日単位でパーティション化した場合、パーティションには 1 日分のデータが保持されます。パーティションキーは、パーティションのサイズを制御します。
パーティション化されたテーブルで `INSERT` SQL コマンドまたは `UPDATE` SQL コマンドを使用すると、データベースエンジンはデータを適切なパーティションにルーティングします。データを格納する PostgreSQL テーブルパーティションは、メインテーブルの子テーブルです。
データベースクエリの読み取り中、PostgreSQL オプティマイザはクエリの `WHERE` 句を調べ、可能な場合、関連するパーティションだけにデータベーススキャンを行うよう指示します。
バージョン 10 以降、PostgreSQL は宣言的なパーティショニングを使用してテーブルパーティションを実装します。これは、ネイティブ PostgreSQL パーティションとも言います。PostgreSQL バージョン 10 より前は、トリガーを使用してパーティションを実装していました。
PostgreSQL テーブルパーティションは、次の機能を提供します。
+ 新しいパーティションの作成がいつでも可能。
+ 可変のパーティション範囲。
+ データ定義言語 (DDL) ステートメントを使用して、取り外し可能かつ再接続可能なパーティション。
例えば、デタッチ可能なパーティションは、メインパーティションから履歴データを削除し、履歴データを分析用に保持する場合に便利です。
+ 新しいパーティションは、親のデータベーステーブルの以下のプロパティを継承します。
+ インデックス
+ プライマリキー (パーティションキー列を含める必要があります)
+ 外部キー
+ 検査制約
+ 参照
+ フルテーブルまたは各特定のパーティションのインデックスの作成。
個々のパーティションのスキーマを変更することはできません。ただし、パーティションに伝播される親テーブル (新しい列の追加など) は変更できます。
**Topics**
+ [
## PostgreSQL pg\$1partman エクステンションの概要
](#PostgreSQL_Partitions.pg_partman)
+ [
## pg\$1partman エクステンションの有効化
](#PostgreSQL_Partitions.enable)
+ [
## create\$1parent 関数を使用したパーティションの設定
](#PostgreSQL_Partitions.create_parent)
+ [
## run\$1maintenance\$1proc 関数を使用したパーティションのメンテナンス設定
](#PostgreSQL_Partitions.run_maintenance_proc)
## PostgreSQL pg\$1partman エクステンションの概要
PostgreSQL `pg_partman` エクステンションを使用すると、テーブルパーティションの作成とメンテナンスを自動化できます。一般的な情報については、`pg_partman` ドキュメントの「[PG Partition Manager](https://github.com/pgpartman/pg_partman)」を参照してください。
**注記**
`pg_partman` エクステンションは、RDS for PostgreSQL のバージョン 12.5 以降でサポートされています。
各パーティションを手動で作成する代わりに、次の設定で `pg_partman` を設定します。
+ パーティション化するテーブル
+ パーティションタイプ
+ パーティションキー
+ パーティションの粒度
+ パーティションの事前作成および管理オプション
PostgreSQL のパーティション化されたテーブルの作成後、`create_parent` 関数を呼び出して、そのテーブルを `pg_partman` に登録します。これにより、関数に渡すパラメータに基づいて、必要なパーティションを作成します。
`pg_partman` エクステンションには、設定したスケジュールに基づいて呼び出しを行うことでパーティションを自動的に管理できる `run_maintenance_proc` 関数も用意されています。必要に応じて適切なパーティションが作成されるようにするには、この関数を定期的に (時間単位など) 実行するようにスケジュールします。また、パーティションが自動的に削除されるようにすることもできます。
## pg\$1partman エクステンションの有効化
パーティションを管理する同じ PostgreSQL DB インスタンス内に複数のデータベースがある場合は、データベースごとに `pg_partman` エクステンションを有効にします。特定のデータベースで `pg_partman` エクステンションを有効にするには、パーティションメンテナンススキーマを作成した上で、次のように `pg_partman` エクステンションを作成します。
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**注記**
`pg_partman` エクステンションを作成するには、`rds_superuser` 権限が必要です。
次のようなエラーが表示された場合は、アカウントに `rds_superuser` 権限を付与するか、スーパーユーザーアカウントを使用します。
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
`rds_superuser` 権限を付与するには、スーパーユーザーアカウントを使用して接続し、以下のコマンドを実行します。
```
GRANT rds_superuser TO user-or-role;
```
pg\$1partman エクステンションの使用方法を示す例では、次のサンプルのデータベーステーブルとパーティションを使用します。このデータベースでは、タイムスタンプに基づいてパーティション化されたテーブルを使用します。スキーマ `data_mart` には、`events` という列を持つ `created_at` という名前のテーブルが含まれています。この `events` テーブルには、次の設定が含まれています。
+ プライマリキー `event_id` および `created_at`。パーティションのガイドに使用される列を含める必要があります。
+ `ck_valid_operation` テーブル列に値を適用するための検査制約 `operation`。
+ 2 つの外部キー。1 つ (`fk_orga_membership)`) は外部テーブル `organization` で、もう 1 つ (`fk_parent_event_id`) は自己参照外部キーです。
+ 2 つのインデックス。1 つ (`idx_org_id`) は外部キー用で、もう 1 つ (`idx_event_type`) はイベントタイプ用です。
次の DDL ステートメントは、各パーティションに自動的に含まれるこれらのオブジェクトを作成します。
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## create\$1parent 関数を使用したパーティションの設定
`pg_partman` エクステンションを有効にした後、`create_parent` 関数を使用して、パーティションメンテナンススキーマ内でパーティションの設定を行います。以下の例では、`events` で作成される [pg\$1partman エクステンションの有効化run\$1maintenance\$1proc 関数を使用したパーティションのメンテナンス設定](#PostgreSQL_Partitions.enable) テーブルの例を使用します。`create_parent` 関数を次のように呼び出します。
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
パラメータは次のとおりです。
+ `p_parent_table` - 親パーティションテーブル。このテーブルは既に存在しており、スキーマを含めて完全修飾である必要があります。
+ `p_control` - パーティションのベースとなる列。データタイプは、整数または時間ベースである必要があります。
+ `p_type` - タイプは `'range'` または `'list'` です。
+ `p_interval` - 各パーティションの時間間隔または整数の範囲。値の例は、`1 day`、`1 hour` などです。
+ `p_premake` - 新しい挿入をサポートするために事前に作成するパーティションの数。
`create_parent` 関数の詳細については、`pg_partman` ドキュメントの「[Creation Functions (関数の作成)](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions)」を参照してください。
## run\$1maintenance\$1proc 関数を使用したパーティションのメンテナンス設定
パーティションのメンテナンスオペレーションを実行して、自動的に新しいパーティションの作成、パーティションのデタッチ、または古いパーティションの削除ができます。パーティションのメンテナンスは、内部のスケジューラをスタートする `pg_partman` および `pg_cron` エクステンション の `run_maintenance_proc` 関数により異なります。`pg_cron` スケジューラは、データベースで定義された SQL ステートメント、関数、および手順を自動的に実行します。
次の例では、`events` で作成した [pg\$1partman エクステンションの有効化run\$1maintenance\$1proc 関数を使用したパーティションのメンテナンス設定](#PostgreSQL_Partitions.enable) テーブルの例を使用して、パーティションのメンテナンスオペレーションを自動的に実行するように設定します。前提条件にあるように、DB インスタンスのパラメータグループで、`shared_preload_libraries` パラメータに `pg_cron` を追加します。
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
その後、前の例についてのステップバイステップの説明を確認できます。
1. DB インスタンスに関連付けられているパラメータグループを変更して、`pg_cron` を `shared_preload_libraries` パラメータ値に追加します。この変更を有効にするには、DB インスタンスの再起動が必要です。詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
1. `CREATE EXTENSION pg_cron;` のアクセス許可を持つアカウントを使用して、コマンド `rds_superuser` を実行します。これにより、`pg_cron` エクステンションが有効になります。詳細については、「[PostgreSQL pg\$1cron エクステンションによるメンテナンスのスケジューリング](PostgreSQL_pg_cron.md)」を参照してください。
1. `UPDATE partman.part_config` コマンドを実行して、`data_mart.events` テーブルの `pg_partman` 設定を調整します。
1. `SET` . . .コマンドを実行して、以下の句を使用しながら、`data_mart.events` テーブルを設定します。
1. `infinite_time_partitions = true,` - 制限なしで新しいパーティションを自動的に作成できるようにテーブルを設定します。
1. `retention = '3 months',` - テーブルの最大保持期間を 3 か月に設定します。
1. `retention_keep_table=true ` - 保存期間の期限が過ぎてもテーブルが自動的に削除されないように、テーブルを構成します。代わりに、保持期間より古いパーティションは、親テーブルからのみデタッチされます。
1. `SELECT cron.schedule` . . .コマンドを実行して、`pg_cron` 関数を呼び出します。この呼び出は、`pg_partman` メンテナンスプロシージャの `partman.run_maintenance_proc` が、スケジューラにより実行される頻度を定義します。この例では、プロシージャは 1 時間ごとに実行されます。
`run_maintenance_proc` 関数の詳細については、`pg_partman` ドキュメントの「[Maintenance Functions (メンテナンス機能)](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions)」を参照してください。
# pgAudit を使用してデータベースのアクティビティを記録する
金融機関、政府機関、および多くの業界では、*規制要件を満たすために監査ログ*を保存する必要があります。 RDS for PostgreSQL DB インスタンスで PostgreSQL 監査拡張機能 (pgAudit) を使用することで、監査人が通常必要とする詳細なレコードや規制要件を満たすための詳細なレコードをキャプチャできます。例えば、pgAudit 拡張機能を設定して、特定のデータベースやテーブルに加えられた変更を追跡したり、変更を加えたユーザーやその他の多くの詳細を記録したりできます。
pgAudit 拡張機能は、ログメッセージをより詳細に拡張することにより、ネイティブの PostgreSQL ログ記録インフラストラクチャの機能に基づいて構築されています。つまり、監査ログは、他のログメッセージを表示するのと同じ方法を使用します。PostgreSQL ログ記録の詳細については、「[ RDS for PostgreSQL データベースログファイル](USER_LogAccess.Concepts.PostgreSQL.md)」を参照してください。
pgAudit 拡張機能は、クリアテキストパスワードなどの機密データをログから編集します。 RDS for PostgreSQL DB インスタンスが、[ RDS for PostgreSQL DB インスタンスのクエリログ記録をオンにする](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md) で説明されているようにデータ操作言語 (DML) ステートメントをログに記録するように設定されている場合は、PostgreSQL Audit 拡張機能を使用することでクリアテキストパスワードの問題を回避できます。
データベースインスタンスの監査は、きわめて詳細に構成できます。すべてのデータベースとすべてのユーザーを監査できます。また、特定のデータベース、ユーザー、その他のオブジェクトのみを監査することもできます。特定のユーザーやデータベースを監査対象から明示的に除外することもできます。詳細については、「[監査ログからのユーザーまたはデータベースの除外](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)」を参照してください。
キャプチャできる詳細の量を考慮すると、pgAudit を使用する場合はストレージ消費量を監視することをお勧めします。
pgAudit 拡張モジュールは、使用可能なすべての RDS for PostgreSQL バージョン。利用可能な RDS for PostgreSQL バージョンでサポートされている pgAudit バージョンのリストについては、*Amazon RDS for PostgreSQL リリースノート*の「[Amazon RDS for PostgreSQL の拡張バージョン](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html)」を参照してください。
**Topics**
+ [
# pgAudit 拡張機能のセットアップ
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [
# データベースオブジェクトの監査
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [
# 監査ログからのユーザーまたはデータベースの除外
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [
# pgAudit 拡張機能のリファレンス
](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# pgAudit 拡張機能のセットアップ
RDS for PostgreSQL DB インスタンス に pgAudit 拡張機能を設定するには、まず RDS for PostgreSQL DB インスタンスのカスタム DB パラメータグループの共有ライブラリに pgAudit を追加します。カスタム DB パラメータグループの作成については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。次に、pgAudit 拡張機能をインストールします。最後に、監査するデータベースとオブジェクトを指定します。このセクションの手順で、方法を示します。AWS マネジメントコンソール または AWS CLI を使用できます。
これらすべてのタスクを実行するには、`rds_superuser` ロールとして権限が必要です。
以下の手順では、 RDS for PostgreSQL DB インスタンスがカスタム DB パラメータグループに関連付けられていることを前提としています。
## コンソール
**pgAudit 拡張機能をセットアップするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. ナビゲーションペインで、 RDS for PostgreSQL DB インスタンスを選択します。
1. の **[Configuration]** (設定) タブを開きます。RDS for PostgreSQL DB インスタンス。インスタンスの詳細の中から、**パラメータグループ**のリンクを見つけてください。
1. リンクを選択して、に関連するカスタムパラメータを開きます。RDS for PostgreSQL DB インスタンス。
1. **パラメータ**検索フィールドに、`shared_pre` を入力して `shared_preload_libraries` パラメータを検索します。
1. プロパティ値にアクセスするには、**[Edit parameters]** (パラメータの編集) を選択します。
1. **[Values]** (値) フィールドのリストに `pgaudit` を追加します。値のリスト内の項目を区切るにはカンマを使用します。
![\[pgAudit が追加された shared_preload_libaries パラメータの画像。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. RDS for PostgreSQL DB instance を再起動して、`shared_preload_libraries` パラメータの変更を有効にします。
1. インスタンスが使用可能になったら、pgAudit が初期化されていることを確認します。`psql` を使用して RDS for PostgreSQL DB インスタンスに接続し、次のコマンドを実行します。
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. pgAudit を初期化すると、拡張機能を作成できるようになりました。`pgaudit` 拡張機能はデータ定義言語 (DDL) ステートメントを監査するためのイベントトリガーをインストールするため、ライブラリを初期化した後に拡張機能を作成する必要があります。
```
CREATE EXTENSION pgaudit;
```
1. `psql` セッションを終了します。
```
labdb=> \q
```
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. リストで `pgaudit.log` パラメータを検索し、ユースケースに応じた値に設定します。例えば、次の画像に示すように `pgaudit.log` パラメータを `write` に設定すると、ログへの挿入、更新、削除、およびその他のタイプの変更がキャプチャされます。
![\[設定を含む pgaudit.log パラメータの画像。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/rpg_set_pgaudit-log-level.png)
`pgaudit.log` パラメータには、次のいずれかの値を選択することもできます。
+ none – これはデフォルトです。データベースの変更は記録されません。
+ すべて — すべてをログに記録します (読み取り、書き込み、関数、ロール、DDL、その他)。
+ ddl – `ROLE` クラスに含まれていない、すべてのデータ定義言語 (DDL) ステートメントのログ記録。
+ function – 関数呼び出し、および `DO` ブロックのログ記録。
+ misc – `DISCARD`、`FETCH`、`CHECKPOINT`、`VACUUM`、`SET` など、さまざまなコマンドのログ記録。
+ read – `SELECT` および `COPY` のログ記録 (ソースがリレーション (テーブルなどの) またはクエリの場合)。
+ role – `GRANT`、`REVOKE`、`CREATE ROLE`、`ALTER ROLE`、`DROP ROLE` など、ロールと権限に関連するステートメントのログ記録。
+ write – `INSERT`、`UPDATE`、`DELETE`、`TRUNCATE`、および `COPY` のログ記録 (送信先がリレーション (テーブル) の場合)。
1. [**Save changes**] (変更の保存) をクリックします。
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. データベースリストから、 RDS for PostgreSQL DB インスタンスを選択します。
## AWS CLI
**pgAudit をセットアップするには**
AWS CLI を使用して pgAudit を設定するには、次の手順に示すように、[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) オペレーションを呼び出してカスタムパラメータグループの監査ログパラメータを変更します。
1. 次の AWS CLI コマンドを使用して`shared_preload_libraries`パラメータに `pgaudit` を追加します。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. 次の AWS CLI コマンドを使用して RDS for PostgreSQL DB インスタンスを再起動し、pgaudit ライブラリを初期化します。
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. インスタンスが使用可能になると、`pgaudit` が初期化されていることを確認できます。`psql` を使用して RDS for PostgreSQL DB インスタンスに接続し、次のコマンドを実行します。
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
pgAudit を初期化すると、拡張機能を作成できるようになりました。
```
CREATE EXTENSION pgaudit;
```
1. AWS CLI を使用できるように `psql` セッションを終了します。
```
labdb=> \q
```
1. 次の AWS CLI コマンドを使用して、セッション監査ログによって記録するステートメントのクラスを指定します。この例では、`pgaudit.log` パラメータを `write` に設定し、ログへの挿入、更新、削除をキャプチャします。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
`pgaudit.log` パラメータには、次のいずれかの値を選択することもできます。
+ none – これはデフォルトです。データベースの変更は記録されません。
+ すべて — すべてをログに記録します (読み取り、書き込み、関数、ロール、DDL、その他)。
+ ddl – `ROLE` クラスに含まれていない、すべてのデータ定義言語 (DDL) ステートメントのログ記録。
+ function – 関数呼び出し、および `DO` ブロックのログ記録。
+ misc – `DISCARD`、`FETCH`、`CHECKPOINT`、`VACUUM`、`SET` など、さまざまなコマンドのログ記録。
+ read – `SELECT` および `COPY` のログ記録 (ソースがリレーション (テーブルなどの) またはクエリの場合)。
+ role – `GRANT`、`REVOKE`、`CREATE ROLE`、`ALTER ROLE`、`DROP ROLE` など、ロールと権限に関連するステートメントのログ記録。
+ write – `INSERT`、`UPDATE`、`DELETE`、`TRUNCATE`、および `COPY` のログ記録 (送信先がリレーション (テーブル) の場合)。
次の AWS CLI コマンドを使用して、 RDS for PostgreSQL DB インスタンスを再起動します。
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# データベースオブジェクトの監査
RDS for PostgreSQL DB インスタンスに pgAudit をセットアップし、要件に合わせて設定すると、より詳細な情報が PostgreSQL ログに取得されます。例えば、デフォルトの PostgreSQL ログ設定はデータベーステーブルに変更が加えられた日付と時刻を識別しますが、pgAudit 拡張機能では、拡張機能のパラメータの設定方法に応じて、スキーマ、変更を行ったユーザー、その他の詳細をログエントリに含めることができます。監査を設定して、次の方法で変更を追跡できます。
+ セッションごとに、ユーザー別。セッションレベルでは、完全修飾コマンドテキストをキャプチャできます。
+ オブジェクトごとに、ユーザー別、データベース別。
オブジェクト監査機能は、システムで `rds_pgaudit` ロールを作成し、そのロールをカスタムパラメータグループの `pgaudit.role` パラメータに追加したときに有効になります。デフォルトでは、`pgaudit.role` パラメータは設定されておらず、許容される値は `rds_pgaudit` だけです。以下の手順は、`pgaudit` が初期化され、[pgAudit 拡張機能のセットアップ](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md) の手順に従って `pgaudit` 拡張機能を作成したことを前提としています。
![\[pgAudit をセットアップした後の PostgreSQL ログファイルの画像。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/pgaudit-log-example.png)
この例に示すように、「LOG: AUDIT: SESSION」行には、テーブルとそのスキーマなどの詳細情報が表示されます。
**オブジェクト監査をセットアップするには**
1. `psql` を使用して RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. 次のコマンドを使用して、`rds_pgaudit` というデータベースロールを作成します。
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. `psql` セッションを終了します。
```
labdb=> \q
```
次のステップでは、AWS CLI を使用してカスタムパラメータグループの監査ログパラメータを変更します。
1. 次の AWS CLI コマンドを使用して、`pgaudit.role` パラメータを `rds_pgaudit` に設定します。デフォルトでは、このパラメータは空で、`rds_pgaudit` は、唯一の許容値です。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. 次の AWS CLI コマンドを使用して RDS for PostgreSQL DB インスタンスを再起動し、パラメータの変更を有効にします。
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. 次のコマンドを実行して、`pgaudit.role` が `rds_pgaudit` に設定されたことを確認します。
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
pgAudit ログ記録をテストするには、監査するサンプルコマンドをいくつか実行します。例えば、次のコマンドを実行します。
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
データベースログには、次のようなエントリが含まれます。
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
ログの表示方法については、「[Amazon RDS ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。
pgAudit 拡張機能の詳細については、GitHub で「[pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md)」を参照してください。
# 監査ログからのユーザーまたはデータベースの除外
[ RDS for PostgreSQL データベースログファイル](USER_LogAccess.Concepts.PostgreSQL.md) で説明したように、PostgreSQL ログはストレージ容量を使用します。pgAudit 拡張機能を使用すると、追跡する変更に応じて、ログに収集されるデータの量が、程度の差はありますが、増加します。内のすべてのユーザーまたはデータベースを監査する必要はないかもしれません。RDS for PostgreSQL DB インスタンス。
ストレージへの影響を最小限に抑え、監査記録を不必要にキャプチャしないようにするには、ユーザーとデータベースを監査対象から除外できます。特定のセッション内のロギングを変更することもできます。次の例は、その方法を示しています。
**注記**
セッションレベルのパラメータ設定は、 RDS for PostgreSQL DB インスタンスのカスタム DB パラメータグループの設定よりも優先されます。データベースユーザーに監査ログ設定の設定をバイパスさせたくない場合は、必ず権限を変更してください。
RDS for PostgreSQL DB インスタンスが、すべてのユーザーとデータベースについて同じレベルのアクティビティを監査するように設定されているとします。次に、`myuser` ユーザーを監査しないことにします。次の SQL コマンドを使用して、`myuser` の監査機能を無効にできます。
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
次に、次のクエリを使用して `pgaudit.log` の `user_specific_settings` 列をチェックし、パラメータが `NONE` に設定されていることを確認できます。
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
次のような出力が表示されます。
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
次のコマンドを使用すると、データベースとのセッションの最中に、指定したユーザーのログをオフにできます。
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
次のクエリを使用して、特定のユーザーとデータベースの組み合わせの pgaudit.log の設定列を確認します。
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
以下のような出力が表示されます。
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
`myuser` の監査を無効化した後に、`mydatabase` の変更を追跡しないことにしました。次のコマンドを使用して、その特定のデータベースの監査を無効化します。
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
次に、以下のクエリで database\$1specific\$1settings 列を確認し、pgaudit.log が NONE に設定されていることを確認します。
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
次のような出力が表示されます。
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
myuser の設定をデフォルト設定に戻すには、次のコマンドを使用します。
```
ALTER USER myuser RESET pgaudit.log;
```
設定をデータベースのデフォルト設定に戻すには、次のコマンドを使用します。
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
ユーザーとデータベースをデフォルト設定にリセットするには、次のコマンドを使用します。
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
また、`pgaudit.log` パラメータに `pgaudit.log` を他の許容値のいずれかに設定することで、特定のイベントをログに記録することもできます 詳細については、「[`pgaudit.log` パラメータの許容設定のリスト](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings)」を参照してください。
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# pgAudit 拡張機能のリファレンス
このセクションにリストされている 1 つまたは複数のパラメータを変更することで、監査ログに必要な詳細レベルを指定できます。
## pgAudit 動作の制御
監査ログは、次のテーブルに示す 1 つ以上のパラメータを変更することで制御できます。
| パラメータ | 説明 |
| --- | --- |
| `pgaudit.log` | セッション監査ログ記録によってログに記録されるステートメントのクラスを指定します。許容値には、ddl、関数、その他、読み取り、ロール、書き込み、なし、すべてが含まれます。(詳しくは、「[`pgaudit.log` パラメータの許容設定のリスト](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings)」を参照してください)。 |
| `pgaudit.log_catalog` | オンにすると (1 に設定)、ステートメント内のすべてのリレーションが pg\$1catalog 内にある場合に、ステートメントを監査証跡に追加します。 |
| `pgaudit.log_level` | ログエントリに使用されるログレベルを指定します。指定できる値は debug5、debug4、debug3、debug2、debug1、info、notice、warning、log です。 |
| `pgaudit.log_parameter` | オン (1 に設定) すると、ステートメントとともに渡されたパラメータが監査ログに記録されます。 |
| `pgaudit.log_relation` | オンにすると (1 に設定)、セッションの監査ログで、SELECT ステートメントまたは DML ステートメントで参照されるリレーション (TABLE、VIEW など) ごとに個別のログエントリが作成されます。 |
| `pgaudit.log_statement_once` | ログ記録に、ステートメントテキストとパラメータを、ステートメントとサブステートメントの組み合わせの最初のログエントリとともに含めるか、すべてのエントリとともに含めるかを指定します。 |
| `pgaudit.role` | オブジェクト監査ログ記録に使用するマスターロールを指定します。唯一許容されるエントリは `rds_pgaudit` です。 |
## `pgaudit.log` パラメータの許容設定のリスト
| 値 | 説明 |
| --- | --- |
| なし | これがデフォルトです。データベースの変更は記録されません。 |
| すべて | すべてをログに記録します (読み取り、書き込み、関数、ロール、DDL、その他)。 |
| ddl | `ROLE` クラスに含まれていない、すべてのデータ定義言語 (DDL) ステートメントのログ記録。 |
| 関数 | 関数呼び出し、および `DO` ブロックのログ記録。 |
| misc | `DISCARD`、`FETCH`、`CHECKPOINT`、`VACUUM`、`SET` など、さまざまなコマンドのログ記録。 |
| 読む | `SELECT` および `COPY` のログ記録 (ソースがリレーション (テーブルなどの) またはクエリの場合)。 |
| ロール | `GRANT`、`REVOKE`、`CREATE ROLE`、`ALTER ROLE`、`DROP ROLE` など、ロールと権限に関連するステートメントのログ記録。 |
| 書き込み | `INSERT`、`UPDATE`、`DELETE`、`TRUNCATE`、および `COPY` のログ記録 (送信先がリレーションの場合)。 |
セッション監査で複数のイベントタイプをログ記録するには、カンマ区切りリストを使用します。すべてのイベントタイプをログ記録するには、`pgaudit.log` を `ALL` に設定します。DB インスタンスを再起動して、変更を適用します。
オブジェクト監査では、監査のログ記録を絞り込み、特定のリレーションを操作できます。例えば、1 つまたは複数のテーブルで、`READ` オペレーションのログ記録を監査するよう指定できます。
# PostgreSQL pg\$1cron エクステンションによるメンテナンスのスケジューリング
PostgreSQL `pg_cron` エクステンションを使用すると、PostgreSQL データベース内でメンテナンスコマンドのスケジュールを組むことができます。拡張機能の詳細については、pg\$1cron ドキュメントの 「[What is pg\$1cron?](https://github.com/citusdata/pg_cron)」 を参照してください。
`pg_cron` エクステンションは PostgreSQL の RDS エンジンのバージョン 12.5 以降でサポートされています。
`pg_cron` の使用の詳細については、「[RDS for PostgreSQL または Aurora PostgreSQL 互換エディションのデータベースで pg\$1cron を使用してジョブをスケジュールする](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/)」を参照してください
**注記**
`pg_cron` 拡張機能バージョンは、pg\$1available\$1extensions ビューに 1.6 などの 2 桁のバージョンとして表示されます。1.6.4 や 1.6.5 などの 3 桁のバージョンが表示される場合がありますが、一部のコンテキストでは、拡張機能のアップグレードを実行するときに 2 桁のバージョンを指定する必要があります。
**Topics**
+ [
## pg\$1cron 拡張機能のセットアップ
](#PostgreSQL_pg_cron.enable)
+ [
## データベースユーザーに pg\$1cron を使用する権限を付与する
](#PostgreSQL_pg_cron.permissions)
+ [
## pg\$1cron ジョブのスケジューリング
](#PostgreSQL_pg_cron.examples)
+ [
## pg\$1cron 拡張機能のリファレンス
](#PostgreSQL_pg_cron.reference)
## pg\$1cron 拡張機能のセットアップ
次のように `pg_cron` 拡張機能をセットアップします。
1. `shared_preload_libraries` パラメータ値に `pg_cron` を追加して、PostgreSQL DB インスタンスに関連付けられているカスタムパラメータグループを変更します。
+ RDS for PostgreSQL DB インスタンスが `rds.allowed_extensions` パラメータを使用して、インストール可能な拡張機能を明示的に一覧表示するには、リストに `pg_cron` 拡張機能を追加する必要があります。RDS for PostgreSQL の特定のバージョンのみが、`rds.allowed_extensions` パラメータに対応しています。デフォルトでは使用可能なすべての拡張機能が許可されます。詳しくは、「[PostgreSQL エクステンションのインストールを制限する](PostgreSQL.Concepts.General.FeatureSupport.Extensions.md#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction)」を参照してください。
静的パラメータグループの変更を反映するために PostgreSQL DB インスタンスを再起動します。パラメータグループを使用する方法の詳細については、[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md) を参照してください。
1. PostgreSQL DB インスタンスが再起動したら、`rds_superuser` の許可を持つアカウントを使用して以下のコマンドを実行します。例えば、RDS for PostgreSQL DB インスタンスの作成時にデフォルト設定を使用した場合は、ユーザー `postgres` として接続し拡張機能を作成します。
```
CREATE EXTENSION pg_cron;
```
`pg_cron` スケジューラは、`postgres` という名前のデフォルトの PostgreSQL データベースに設定されます。`pg_cron` オブジェクトはこの `postgres` データベースに作成され、すべてのスケジューリングアクションがこのデータベースで実行されます。
1. デフォルト設定を使用することも、ジョブをスケジュールして、PostgreSQL DB インスタンス内の他のデータベースで実行させることもできます。PostgreSQL DB インスタンス内の他のデータベースでジョブをスケジュールするには、[デフォルトのデータベース以外のデータベースでの cron ジョブのスケジューリング](#PostgreSQL_pg_cron.otherDB) の例を参照してください。
## データベースユーザーに pg\$1cron を使用する権限を付与する
`pg_cron` 拡張機能をインストールするには、`rds_superuser` 権限が必要です。ただし、`pg_cron` の使用権限は (`rds_superuser` グループ/ロールのメンバーによって) 他のデータベースユーザーに付与して、各ユーザーが自分のジョブをスケジュールできるようにすることができます。本番環境での運用が改善される場合にのみ、`cron` スキーマへのアクセス許可を付与することをお勧めします。
`cron` スキーマでデータベースユーザー権限を付与するには、以下のコマンドを実行します。
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
これにより、アクセス権限のあるオブジェクトの cron ジョブをスケジュールするための `cron` スキーマへの *db-user* アクセス許可が付与されます。データベースユーザーに権限がない場合、以下に示すように、エラーメッセージを `postgresql.log` ファイルに投稿した後にジョブは失敗します。
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
つまり、`cron` スキーマへの権限を付与されているデータベースユーザーに、スケジュールを設定する予定のオブジェクト (テーブル、スキーマなど) に対する権限も付与されていることを確認します。
この cron ジョブの詳細と、その成功または失敗も `cron.job_run_details` テーブルにキャプチャされます。詳細については、「[ジョブのスケジュール設定とステータス取得用のテーブル](#PostgreSQL_pg_cron.tables)」を参照してください。
## pg\$1cron ジョブのスケジューリング
次のセクションでは、`pg_cron` ジョブを使用してさまざまな管理タスクをスケジュールする方法について説明します。
**注記**
`pg_cron` ジョブの作成時は、`max_worker_processes` 設定が `cron.max_running_jobs` の数より大きいことを確認します。バックグラウンドのワーカープロセスを使い切ると、`pg_cron` ジョブは失敗します。`pg_cron` ジョブのデフォルト数は `5` です。詳しくは、「[pg\$1cron 拡張機能の管理用パラメータ](#PostgreSQL_pg_cron.parameters)」を参照してください。
**Topics**
+ [
### テーブルのバキューム処理
](#PostgreSQL_pg_cron.vacuum)
+ [
### pg\$1cron の履歴テーブルの除去
](#PostgreSQL_pg_cron.job_run_details)
+ [
### エラーのログを postgresql.log ファイルにのみ記録する
](#PostgreSQL_pg_cron.log_run)
+ [
### デフォルトのデータベース以外のデータベースでの cron ジョブのスケジューリング
](#PostgreSQL_pg_cron.otherDB)
### テーブルのバキューム処理
Autovacuum は、ほとんどの場合、バキュームのメンテナンスを実行します。ただし、特定のテーブルのバキューム処理を、選択した特定の時点にスケジュールしたい、というケースも考えられます。
「[Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)」も参照してください。
以下は、`cron.schedule` 関数を使用して、毎日 22:00 (GMT) に特定のテーブルで `VACUUM FREEZE` を使用するようにジョブをセットアップする例です。
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
上記の例を実行した後、次のように `cron.job_run_details` テーブル内の履歴を確認できます。
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
失敗したジョブを確認するための `cron.job_run_details` テーブルのクエリは、次のとおりです。
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
詳細については、「[ジョブのスケジュール設定とステータス取得用のテーブル](#PostgreSQL_pg_cron.tables)」を参照してください。
### pg\$1cron の履歴テーブルの除去
`cron.job_run_details` テーブルには、時間の経過とともに非常に大きくなる可能性がある cron ジョブの履歴が含まれています。そのため、このテーブルをクリアにするジョブをスケジュールすることをお勧めします。例えば、トラブルシューティングの目的では、1 週間分のエントリを保持するだけで十分です。
次の例では、[cron.schedule](#PostgreSQL_pg_cron.schedule) 関数を使用して、`cron.job_run_details` テーブルをクリアにするよう、毎日午前 0 時に実行されるジョブをスケジュールします。このジョブは過去 7 日間しか残せません。`rds_superuser` アカウントを使用して、以下のようなジョブをスケジュールできます。
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
(詳しくは、「[ジョブのスケジュール設定とステータス取得用のテーブル](#PostgreSQL_pg_cron.tables)」を参照してください。)
### エラーのログを postgresql.log ファイルにのみ記録する
`cron.job_run_details` テーブルへの書き込みをしないようにするには、PostgreSQL DB インスタンスに関連付けられているパラメータグループを変更し、`cron.log_run` パラメータをオフに設定します。`pg_cron` 拡張機能によって対象のテーブルには書き込まなくなり、エラーは `postgresql.log` ファイルのみに記録されるようになります。詳細については、「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
`cron.log_run` パラメータの値を確認するには、次のコマンドを使用します。
```
postgres=> SHOW cron.log_run;
```
詳細については、「[pg\$1cron 拡張機能の管理用パラメータ](#PostgreSQL_pg_cron.parameters)」を参照してください。
### デフォルトのデータベース以外のデータベースでの cron ジョブのスケジューリング
`pg_cron` のメタデータはすべて、`postgres` という名前の PostgreSQL のデフォルトのデータベースに保持されます。メンテナンスの cron ジョブの実行にはバックグラウンドワーカーが使用されるため、PostgreSQL DB インスタンス内の任意のデータベースでジョブのスケジューリングが可能です。
**注記**
`rds_superuser` ロールまたは `rds_superuser` 権限を持つユーザーのみが、データベース内のすべての cron ジョブを一覧表示できます。他のユーザーは、自分のジョブのみを `cron.job` テーブルに表示できます。
1. cron データベースで、[cron.schedule](#PostgreSQL_pg_cron.schedule) を使用して通常どおりにジョブをスケジュールします。
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. 作成したジョブのデータベース列を、`rds_superuser` ロールを持つユーザーとして更新し、そのジョブを PostgreSQL DB インスタンス内の別のデータベースで実行できるようにします。
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. `cron.job` テーブルのクエリを実行して確認します。
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**注記**
状況によっては、別のデータベースで実行する cron ジョブを追加することがあります。このような場合、ジョブは、正しいデータベース列を更新する前に、デフォルトのデータベース (`postgres`) で実行しようとする可能性があります。ユーザー名に権限がある場合、デフォルトのデータベースでジョブが正常に実行されます。
## pg\$1cron 拡張機能のリファレンス
`pg_cron` エクステンションでは、次のパラメータ、関数、およびテーブルを使用できます。詳細については、pg\$1cron ドキュメントの [What is pg\$1cron?](https://github.com/citusdata/pg_cron) を参照してください。
**Topics**
+ [
### pg\$1cron 拡張機能の管理用パラメータ
](#PostgreSQL_pg_cron.parameters)
+ [
### 関数リファレンス: cron.schedule
](#PostgreSQL_pg_cron.schedule)
+ [
### 関数リファレンス: cron.unschedule
](#PostgreSQL_pg_cron.unschedule)
+ [
### ジョブのスケジュール設定とステータス取得用のテーブル
](#PostgreSQL_pg_cron.tables)
### pg\$1cron 拡張機能の管理用パラメータ
`pg_cron` エクステンションの動作を制御するパラメータの一覧を次に示します。
| Parameter | 説明 |
| --- | --- |
| cron.database\$1name | `pg_cron` メタデータが保持されるデータベース。 |
| cron.host | PostgresSQL に接続するためのホスト名。この値は変更できません。 |
| cron.log\$1run | `job_run_details` テーブルで実行されるすべてのジョブをログに記録します。有効な値は `on` または `off` です。詳細については、「[ジョブのスケジュール設定とステータス取得用のテーブル](#PostgreSQL_pg_cron.tables)」を参照してください。 |
| cron.log\$1statement | 実行する前に、すべての cron ステートメントを記録します。有効な値は `on` または `off` です。 |
| cron.max\$1running\$1jobs | 同時に実行できるジョブの最大数。 |
| cron.use\$1background\$1workers | クライアントセッションの代わりにバックグラウンドワーカーを使用します。この値は変更できません。 |
次の SQL コマンドを使用して、これらのパラメータとその値を表示します。
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### 関数リファレンス: cron.schedule
この関数は、cron ジョブをスケジュールします。このジョブは、デフォルトの `postgres` データベースで初期にスケジュールされます。この関数は、ジョブ識別子を表す `bigint` の値を返します。PostgreSQL DB インスタンス内の他のデータベースで実行するようにジョブをスケジュールするには、[デフォルトのデータベース以外のデータベースでの cron ジョブのスケジューリング](#PostgreSQL_pg_cron.otherDB) の例を参照してください。
この関数には、2 つの構文形式があります。
**構文**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**パラメータ**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**例**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### 関数リファレンス: cron.unschedule
この関数は、cron ジョブを削除します。`job_name` または `job_id` を指定できます。ポリシーにより、ユーザーがジョブのスケジュールを削除する所有者であることが確認されます。この関数は、成功または失敗を示すブール値を返します。
関数の構文形式は以下のとおりです。
**構文**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**パラメータ**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)
**例**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### ジョブのスケジュール設定とステータス取得用のテーブル
以下のテーブルは、cron ジョブのスケジューリングのためと、そのジョブがどのように完了したかを記録するために使用されます。
| 表 | 説明 |
| --- | --- |
| cron.job | スケジュールされた各ジョブに関するメタデータが含まれます。このテーブルとのほとんどのやり取りは、`cron.schedule` 関数および `cron.unschedule` 関数を使用して行う必要があります。 更新または挿入の権限をこのテーブルに直接与えないようにお勧めします。そうすることで、ユーザーは `username` 列を更新し、`rds-superuser` として実行できるようになります。 |
| cron.job\$1run\$1details | ここには、過去にスケジュールされ実行されたジョブに関する履歴の情報が含まれます。これは、実行されたジョブのステータス、返されたメッセージ、およびスタートと終了の時間を調査する場合に便利です。 このテーブルが無期限に増えないようにするには、定期的に削除してください。例については、「[pg\$1cron の履歴テーブルの除去](#PostgreSQL_pg_cron.job_run_details)」を参照してください。 |
# pglogical を使用してインスタンス間でデータを同期する
現在利用可能なすべての RDS for PostgreSQL バージョンは、`pglogical` 拡張機能をサポートしています。pglogical 拡張は、バージョン 10 で PostgreSQL により導入された機能的に類似した論理レプリケーション機能よりも前のものです。詳細については、「[Amazon RDS for PostgreSQL の論理レプリケーションの実行](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md)」を参照してください。
`pglogical` 拡張が、2 つ以上の 間の論理レプリケーションをサポートします。RDS for PostgreSQL DB インスタンス。また、異なる PostgreSQL バージョン間のレプリケーション、および RDS for PostgreSQL DB と Aurora PostgreSQL DB クラスターで実行されているデータベース間のレプリケーションもサポートしています。`pglogical` 拡張は、公開/サブスクライブモデルを使用して、テーブルやその他のオブジェクト (シーケンスなど) への変更をパブリッシャーからサブスクライバーに複製します。パブリッシャーノードからサブスクライバーノードに変更が確実に同期されるようにするには、レプリケーションスロットを使用し、次のように定義されます。
+ *パブリッシャーノード*は、他のノードにレプリケートされるデータのソースである RDS for PostgreSQL DB インスタンスです。パブリッシャーノードは、パブリケーションセットでレプリケートするテーブルを定義します。
+ *サブスクライバーノード*は、公開者から WAL の更新を受け取る RDS for PostgreSQL DB インスタンスです。サブスクライバーは、パブリッシャーに接続してデコードされた WAL データを取得するためのサブスクリプションを作成します。サブスクライバーがサブスクリプションを作成すると、パブリッシャーノードに複製スロットが作成されます。
`pglogical` 拡張の設定についての情報は、以下を参照してください。
**Topics**
+ [
## pglogical 拡張の要件と制限
](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [
# pglogical 拡張のセットアップ
](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [
# RDS for PostgreSQL DB インスタンスに論理レプリケーションを設定する
](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [
# メジャーアップグレード後の論理レプリケーションの再確立
](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [
# RDS for PostgreSQL 用ロジカルレプリケーションスロットの管理
](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [
# pglogical 拡張のパラメータリファレンス
](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## pglogical 拡張の要件と制限
RDS for PostgreSQL の現在利用可能なすべてのリリースが `pglogical` 拡張機能をサポートしています。
パブリッシャーノードとサブスクライバーノードの両方を論理レプリケーション用に設定する必要があります。
サブスクライバーからパブリッシャーにレプリケートするテーブルは、同じ名前と同じスキーマである必要があります。これらのテーブルにも同じ列が含まれている必要があり、列は同じデータ型を使用する必要があります。パブリッシャーテーブルとサブスクライバーテーブルの両方に同じプライマリキーが必要です。一意の制約事項としては PRIMARY KEY のみを使用することをお勧めします。
サブスクライバーノードのテーブルには、CHECK 制約と NOT NULL 制約について、パブリッシャーノードのテーブルよりも許可度が高い制約を設定できます。
`pglogical` 拡張は、PostgreSQL (バージョン 10 以降) に組み込まれている論理レプリケーション機能ではサポートされていない双方向レプリケーションなどの機能を提供します。詳細については、「[PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/)」(pglogical を使用した PostgreSQL の双方向レプリケーション) を参照してください。
# pglogical 拡張のセットアップ
RDS for PostgreSQL DB インスタンスに `pglogical` 拡張機能を設定するには、RDS for PostgreSQL DB インスタンスのカスタム DB パラメータグループの共有ライブラリに `pglogical` を追加します。また、論理デコードをオンにするには、`rds.logical_replication` パラメータの値を `1` に設定する必要があります。最後に、データベースに拡張を作成します。これらのタスクには、AWS マネジメントコンソール または AWS CLI を使用できます。
これらのタスクを実行するには、`rds_superuser` ロールとしてアクセス許可が必要です。
以下のステップでは、 RDS for PostgreSQL DB インスタンスがカスタム DB パラメータグループに関連付けられていることを前提としています。カスタム DB パラメータグループの作成については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
## コンソール
**pglogical 拡張をセットアップするには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、 RDS for PostgreSQL DB インスタンスを選択します。
1. の **[Configuration]** (設定) タブを開きます。RDS for PostgreSQL DB インスタンス。インスタンスの詳細の中から、**パラメータグループ**のリンクを見つけてください。
1. リンクを選択して、に関連するカスタムパラメータを開きます。RDS for PostgreSQL DB インスタンス。
1. **パラメータ**検索フィールドに、`shared_pre` を入力して `shared_preload_libraries` パラメータを検索します。
1. プロパティ値にアクセスするには、**[Edit parameters]** (パラメータの編集) を選択します。
1. **[Values]** (値) フィールドのリストに `pglogical` を追加します。値のリスト内の項目を区切るにはカンマを使用します。
![\[pglogical が追加された shared_preload_libraries パラメータの画像。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. `rds.logical_replication` パラメータを見つけて `1` に設定し、論理レプリケーションをオンにします。
1. RDS for PostgreSQL DB インスタンス を再起動して、変更を有効にします。
1. インスタンスが使用可能になったら、`psql` (または pgAdmin) を使用して RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. pglogical が初期化されていることを確認するには、次のコマンドを実行します。
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. 次のように、論理デコードを有効にする設定を確認します。
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. 次のように拡張を作成します。
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. **[Save changes]** (変更の保存) をクリックします。
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. データベースリストから RDS for PostgreSQL DB インスタンス を選択して選択し、アクションメニューから **[Reboot]** (再起動) を選択します。
## AWS CLI
**pglogical 拡張のセットアップするには**
AWS CLI を使用して pglogical を設定するには、次の手順に示すように、[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) オペレーションを呼び出してカスタムパラメータグループの特定のパラメータを変更します。
1. 次の AWS CLI コマンドを使用して`shared_preload_libraries`パラメータに `pglogical` を追加します。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. 次の AWS CLI コマンドを使用して `rds.logical_replication` を `1` に設定し、の論理デコード機能をオンにします。RDS for PostgreSQL DB インスタンス。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. 次の AWS CLI コマンドを使用して RDS for PostgreSQL DB インスタンスを再起動し、pglogical ライブラリを初期化します。
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. インスタンスが使用可能になったら、`psql` を使用して RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. 次のように拡張を作成します。
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. 次の AWS CLI コマンドを使用して、 RDS for PostgreSQL DB インスタンスを再起動します。
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
# RDS for PostgreSQL DB インスタンスに論理レプリケーションを設定する
以下の手順では、2 つの RDS for PostgreSQL DB インスタンス間で論理レプリケーションを開始する方法を示しています。これらのステップでは、ソース (パブリッシャー) とターゲット (サブスクライバー) の両方に、[pglogical 拡張のセットアップ](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md) で説明されているように `pglogical` 拡張が設定されていることを前提としています。
**注記**
サブスクライバーノードの `node_name` は、`rds` で開始することができません。
**パブリッシャーノードを作成し、複製するテーブルを定義するには**
これらのステップは、別のノードに複製する 1 つ以上のテーブルがあるデータベースが RDS for PostgreSQL インスタンスにあることを前提としています。サブスクライバー上のパブリッシャーからテーブル構造を再作成する必要があるため、まず必要に応じてテーブル構造を取得します。そのためには、`psql` メタコマンド `\d tablename` を使用してサブスクライバーインスタンスに同じテーブルを作成します。次の手順では、デモンストレーションを目的として、パブリッシャー (ソース) でサンプルテーブルを作成します。
1. `psql` を使用して、サブスクライバーのソースとして使用したいテーブルがあるインスタンスに接続します。
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
複製する既存のテーブルがない場合は、次のようにサンプルテーブルを作成できます。
1. 次の SQL ステートメントを使用してサンプルテーブルを作成します。
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. 次の SQL ステートメントを使用して、生成されたデータをテーブルに入力します。
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. 次の SQL ステートメントを使用して、テーブルにデータが存在することを確認します。
```
SELECT count(*) FROM docs_lab_table;
```
1. 次のように、この RDS for PostgreSQL DB インスタンスをパブリッシャーノードとして指定します。
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. 複製するテーブルをデフォルトのレプリケーションセットに追加します。レプリケーションセットの詳細については、pglogical ドキュメントの「[Replication sets](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets)」(レプリケーションセット) を参照してください。
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
パブリッシャーノードの設定が完了しました。これで、パブリッシャーから更新を受け取るようにサブスクライバーノードを設定できます。
**サブスクライバーノードを設定し、更新を受信するサブスクリプションを作成するには**
これらのステップは、RDS for PostgreSQL DB インスタンスが `pglogical` 拡張機能を使用してセットアップされていることを前提としています。詳細については、「[pglogical 拡張のセットアップ](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)」を参照してください。
1. `psql` を使用して、パブリッシャーから更新を受け取るインスタンスに接続します。
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. サブスクライバーの RDS for PostgreSQL DB インスタンスで、パブリッシャーに存在するのと同じテーブルを作成します。この例では、テーブルは `docs_lab_table` です。次に示すようにテーブルを作成できます。
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. このテーブルが空であることを確認します。
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. 次のように、この RDS for PostgreSQL DB インスタンスをサブスクライバーノードとして指定します。
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. サブスクリプションを作成します。
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
このステップを完了すると、パブリッシャーのテーブルのデータが、サブスクライバーのテーブルに作成されます。このことを確認するには、次の SQL クエリを使用します。
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
これ以降、パブリッシャーのテーブルに加えられた変更は、サブスクライバーのテーブルにレプリケートされます。
# メジャーアップグレード後の論理レプリケーションの再確立
論理レプリケーションのパブリッシャーノードとして設定されている RDS for PostgreSQL DB インスタンスのメジャーバージョンアップグレードを実行する前に、アクティブではないものを含め、すべてのレプリケーションスロットを削除する必要があります。パブリッシャーノードからデータベーストランザクションを一時的に迂回させ、レプリケーションスロットを削除し、RDS for PostgreSQL DB インスタンスをアップグレードしてから、レプリケーションを再確立して再開することをお勧めします。
レプリケーションスロットはパブリッシャーノードでのみホストされます。論理レプリケーションシナリオの RDS for PostgreSQL サブスクライバーノードには削除するスロットはありませんが、パブリッシャーへのサブスクリプションを持つサブスクライバーノードとして指定されている間は、メジャーバージョンにアップグレードできません。RDS for PostgreSQL サブスクライバーノードをアップグレードする前に、サブスクリプションとノードを削除してください。詳細については、「[ RDS for PostgreSQL 用ロジカルレプリケーションスロットの管理](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)」を参照してください。
## 論理レプリケーションが中断されたことの確認
次のように、パブリッシャーノードまたはサブスクライバーノードのいずれかにクエリを実行することで、レプリケーションプロセスが中断されたことを確認できます。
**パブリッシャーノードを確認するには**
+ `psql` を使用してパブリッシャーノードに接続して、`pg_replication_slots` 関数をクエリします。active 列の値に注目します。通常は `t` (true) が返されます。これは、レプリケーションがアクティブであることを示します。クエリが`f` (false) を返す場合は、サブスクライバーへのレプリケーションが停止したことを示します。
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**サブスクライバーノードを確認するには**
サブスクライバーノードでは、3 つの異なる方法でレプリケーションのステータスを確認できます。
+ サブスクライバーノードの PostgreSQL ログを調べて、失敗のメッセージを見つけます。ログでは、次に示すように、終了コード 1 を含むメッセージで失敗が識別されます。
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ `pg_replication_origin` 関数をクエリします。次のように、`psql` を使用してサブスクライバーノード上のデータベースに接続し、`pg_replication_origin` 関数をクエリします。
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
結果セットが空の場合は、レプリケーションが中断されたことを意味します。通常、次のような出力が表示されます。
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ 次の例に示すように、`pglogical.show_subscription_status` 関数をクエリします。
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
この出力は、レプリケーションが中断されたことを示しています。そのステータスは `down` です。通常、出力にはステータスが `replicating` として表示されます。
論理レプリケーションプロセスが中断された場合は、次のステップに従ってレプリケーションを再確立できます。
**パブリッシャーノードとサブスクライバーノード間の論理レプリケーションを再確立するには**
レプリケーションを再確立するには、以下のステップで説明するように、まずサブスクライバーをパブリッシャーノードから切断し、次にサブスクリプションを再確立します。
1. 次のように `psql` を使用してサブスクライバーノードに接続します。
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. `pglogical.alter_subscription_disable` 関数を使用してサブスクリプションを非アクティブ化します。
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. 以下のように、`pg_replication_origin` をクエリして、パブリッシャーノードの識別子を取得します。
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. 前のステップからの応答を `pg_replication_origin_create` コマンドに使用して、サブスクリプションが再確立されたときに使用できる識別子を割り当てます。
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. 次の例のように、ステータスを `true` にして名前を渡し、サブスクリプションを有効にします。
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
ノードのステータスを確認します。ステータスはこの例のように `replicating` として表示されているはずです。
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
パブリッシャーノード上のサブスクライバーのレプリケーションスロットのステータスを確認します。スロットの `active` 列は `t` (true) を返し、レプリケーションが再確立されたことを示します。
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# RDS for PostgreSQL 用ロジカルレプリケーションスロットの管理
論理レプリケーションシナリオでパブリッシャーノードとして機能している RDS for PostgreSQL DB インスタンスでメジャーバージョンアップグレードを実行する前に、インスタンスのレプリケーションスロットを削除する必要があります。メジャーバージョンアップグレードの事前確認プロセスにより、スロットが削除されるまでアップグレードを続行できないことが通知されます。
RDS for PostgreSQL DB インスタンスからスロットを削除するには、まずサブスクリプションを削除してからスロットを削除します。
`pglogical` 拡張を使用して作成されたレプリケーションスロットを特定するには、各データベースにログインしてノードの名前を取得します。サブスクライバーノードにクエリを実行すると、次の例に示すように、パブリッシャーノードとサブスクライバーノードの両方が出力されます。
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
次のクエリで、サブスクリプションの詳細を取得できます。
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
これで、次のようにサブスクリプションを削除できます。
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
サブスクリプションを削除すると、ノードを削除できます。
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
次のように、ノードが存在しないことを確認できます。
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# pglogical 拡張のパラメータリファレンス
表には、`pglogical` 拡張に関連するパラメータがあります。`pglogical.conflict_log_level` や `pglogical.conflict_resolution` などのパラメータは、更新の競合を処理するために使用されます。パブリッシャーから変更をサブスクライブしているテーブルにローカルで変更を加えると、競合が発生する可能性があります。これ以外にも、競合は、双方向のレプリケーションや、複数のサブスクライバーが同じパブリッシャーからレプリケートする場合など、さまざまなシナリオで発生する可能性があります。詳細については、「[PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/)」(pglogical を使用した PostgreSQL の双方向レプリケーション) を参照してください。
| パラメータ | 説明 |
| --- | --- |
| pglogical.batch\$1inserts | 可能であれば、バッチ挿入。デフォルトでは設定されていません。オンにする場合は「1」に、オフにする場合は「0」に変更します。 |
| pglogical.conflict\$1log\$1level | 解決された競合のログ記録に使用するログレベルを設定します。サポートされている文字列値は、debug5、debug4、debug3、debug2、debug1、info、notice、warning、error、log、fatal、panic です。 |
| pglogical.conflict\$1resolution | 競合が解決可能な場合に競合を解決するために使用するメソッドを設定します。サポートされている文字列値は、error、apply\$1remote、keep\$1local、last\$1update\$1wins、first\$1update\$1wins です。 |
| pglogical.extra\$1connection\$1options | すべてのピアノード接続に追加する接続オプション。 |
| pglogical.synchronous\$1commit | pglogical 固有の同期コミット値 |
| pglogical.use\$1spi | 低レベル API の代わりに SPI (サーバープログラミングインターフェイス) を使用して変更を適用します。オンにする場合は「1」に、オフにする場合は「0」に設定します。SPI の詳細については、PostgreSQL ドキュメントの「[サーバープログラミングインターフェイス](https://www.postgresql.org/docs/current/spi.html)」を参照してください。 |
# pgactive を使用したアクティブ/アクティブレプリケーションのサポート
`pgactive` 拡張は、アクティブ/アクティブレプリケーションを使用して、複数の RDS for PostgreSQL データベースに対する書き込み操作をサポートおよび調整します。Amazon RDS for PostgreSQL は、次のバージョンの `pgactive` 拡張機能をサポートしています。
+ RDS for PostgreSQL バージョン 17.0 以降のバージョン
+ RDS for PostgreSQL 16.1 またはそれ以降の 16 バージョン
+ RDS for PostgreSQL 15.4-R2 以降のバージョン 15
+ RDS for PostgreSQL 14.10 以降のバージョン 14
+ RDS for PostgreSQL 13.13 以降のバージョン 13
+ RDS for PostgreSQL 12.17 以降のバージョン 12
+ RDS for PostgreSQL 11.22
**注記**
レプリケーション設定に複数のデータベースに対する書き込み操作があると、競合が発生する可能性があります。詳細については、[アクティブ/アクティブレプリケーションの競合の処理](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)を参照してください。
**Topics**
+ [
## pgactive 拡張の制限事項
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.requirements-limitations)
+ [
# pgactive 拡張機能の初期化
](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)
+ [
# RDS for PostgreSQL DB インスタンスのアクティブ/アクティブレプリケーションの設定
](Appendix.PostgreSQL.CommonDBATasks.pgactive.setup-replication.md)
+ [
# pgactive メンバー間のレプリケーションラグの測定
](Appendix.PostgreSQL.CommonDBATasks.pgactive.replicationlag.md)
+ [
# pgactive 拡張機能のパラメータ設定
](Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.md)
+ [
# アクティブ/アクティブ競合について
](Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.replication.md)
+ [
# pgactive スキーマについて
](Appendix.PostgreSQL.CommonDBATasks.pgactive.schema.md)
+ [
# pgactive 関数リファレンス
](pgactive-functions-reference.md)
+ [
# アクティブ/アクティブレプリケーションの競合の処理
](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-conflicts.md)
+ [
# アクティブ/アクティブレプリケーションでのシーケンスの処理
](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)
## pgactive 拡張の制限事項
+ すべてのテーブルには主キーが必要です。主キーがないと、更新や削除は許可されません。主キー列の値は更新しないでください。
+ シーケンスにはギャップがある場合があり、順序に従わないこともあります。シーケンスはレプリケートされません。詳細については、「[アクティブ/アクティブレプリケーションでのシーケンスの処理](Appendix.PostgreSQL.CommonDBATasks.pgactive.handle-sequences.md)」を参照してください。
+ DDL とラージオブジェクトはレプリケートされません。
+ セカンダリの一意のインデックスはデータの相違を引き起こす可能性があります。
+ 照合順序はグループ内のすべてのノードで同一である必要があります。
+ ノード間の負荷分散はアンチパターンです。
+ トランザクションが大きいと、レプリケーションの遅延が発生する可能性があります。
# pgactive 拡張機能の初期化
RDS for PostgreSQL DB インスタンスの `pgactive` 拡張機能を初期化するには、`rds.enable_pgactive` パラメータの値を `1` に設定し、データベースに拡張を作成します。これを行うと、`rds.logical_replication` パラメータと `track_commit_timestamp` パラメータが自動的に有効になり、`wal_level` の値が `logical` に設定されます。
これらのタスクを実行するには、`rds_superuser` ロールとしてアクセス許可が必要です。
AWS マネジメントコンソール または AWS CLI を使用して、必要な RDS for PostgreSQL DB インスタンスを作成できます。以下のステップでは、RDS for PostgreSQL DB インスタンスがカスタム DB パラメータグループに関連付けられていることを前提としています。カスタム DB パラメータグループの作成については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
## コンソール
**pgactive 拡張機能を初期化するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、RDS for PostgreSQL DB インスタンスを選択します。
1. RDS for PostgreSQL DB インスタンスの **[設定]** タブを開きます。インスタンスの詳細で、**[DB インスタンスパラメータグループ]** リンクを見つけます。
1. リンクを選択して、RDS for PostgreSQL DB インスタンスに関連付けられたカスタムパラメータを開きます。
1. `rds.enable_pgactive` パラメータを見つけて `1` に設定し、`pgactive` 機能を初期化します。
1. **[Save changes]** (変更の保存) をクリックします。
1. Amazon RDS コンソールのナビゲーションペインで、**[データベース]** を選択します。
1. RDS for PostgreSQL DB インスタンスを選択し、**[アクション]** メニューから **[再起動]** を選択します。
1. DB インスタンスの再起動を確定して、変更を有効にします。
1. DB インスタンスが使用可能になったら、`psql` または他の任意の PostgreSQL インスタンスを使用して RDS for PostgreSQL DB インスタンスに接続します。
次の例では、RDS for PostgreSQL DB インスタンスに *postgres* という名前のデフォルトデータベースがあることを前提としています。
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. pgactive が初期化されていることを確認するには、次のコマンドを実行します。
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
`pgactive` が `shared_preload_libraries` にある場合、前述のコマンドは以下を返します。
```
?column?
----------
t
```
## AWS CLI
**pgactive 拡張機能を初期化するには**
AWS CLI を使用して `pgactive` を設定するには、次の手順に示すように、[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) オペレーションを呼び出してカスタムパラメータグループ内の特定のパラメータを変更します。
1. AWS CLI コマンドを使用して `rds.enable_pgactive` を `1` に設定し、RDS for PostgreSQL DB インスタンスの `pgactive` 機能を初期化します。
```
postgres=>aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.enable_pgactive,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. 次の AWS CLI コマンドを使用して RDS for PostgreSQL DB インスタンスを再起動し、`pgactive` ライブラリを初期化します。
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. インスタンスが使用可能になったら、`psql` を使用して RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=mydb.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=master user --password=PASSWORD --dbname=postgres
```
1. pgactive が初期化されていることを確認するには、次のコマンドを実行します。
```
postgres=>SELECT setting ~ 'pgactive'
FROM pg_catalog.pg_settings
WHERE name = 'shared_preload_libraries';
```
`pgactive` が `shared_preload_libraries` にある場合、前述のコマンドは以下を返します。
```
?column?
----------
t
```
# RDS for PostgreSQL DB インスタンスのアクティブ/アクティブレプリケーションの設定
以下の手順は、`pgactive` が利用可能な場合に 2 つの RDS for PostgreSQL DB インスタンス間でアクティブ/アクティブレプリケーションを開始する方法を示しています。マルチリージョンの高可用性の例を実行するには、2 つの異なるリージョンに Amazon RDS for PostgreSQL インスタンスをデプロイし、VPC ピアリングを設定する必要があります。詳細については、「[VPC ピアリング接続](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)」を参照してください。
**注記**
複数のリージョン間でトラフィックを送信すると、追加コストが発生する可能性があります。
次の手順では、RDS for PostgreSQL DB インスタンスが `pgactive` 拡張を使用して有効化されていることを前提としています。詳細については、「[pgactive 拡張機能の初期化](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)」を参照してください。
**`pgactive` 拡張を使用して最初の RDS for PostgreSQL DB インスタンスを設定するには**
次の例は、`pgactive` グループの作成方法と、RDS for PostgreSQL DB インスタンスで `pgactive` 拡張を作成するために必要なその他の手順を示しています。
1. `psql` または別のクライアントツールを使用して、最初の RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=firstinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. 次のコマンドを使用して RDS for PostgreSQL インスタンスにデータベースを作成します。
```
postgres=> CREATE DATABASE app;
```
1. 次のコマンドを使用して、接続先を新しいデータベースに切り替えます。
```
\c app
```
1. 次の SQL ステートメントを使用して、サンプルのテーブルを作成および設定します。
1. 次の SQL ステートメントを使用してサンプルテーブルを作成します。
```
app=> CREATE SCHEMA inventory;
CREATE TABLE inventory.products (
id int PRIMARY KEY, product_name text NOT NULL,
created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP);
```
1. 次の SQL ステートメントを使用して、サンプルデータをテーブルに入力します。
```
app=> INSERT INTO inventory.products (id, product_name)
VALUES (1, 'soap'), (2, 'shampoo'), (3, 'conditioner');
```
1. 次の SQL ステートメントを使用して、テーブルにデータが存在することを確認します。
```
app=>SELECT count(*) FROM inventory.products;
count
-------
3
```
1. 既存のデータベースで `pgactive` 拡張を作成します。
```
app=> CREATE EXTENSION pgactive;
```
1. pgactive グループを安全に作成して初期化するには、以下のコマンドを使用します。
```
app=>
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
これで、レプリケーショングループを初期化し、この最初のインスタンスを追加できます。
```
SELECT pgactive.pgactive_create_group(
node_name := 'endpoint1-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
代替手段として、以下のコマンドを使用して pgactive グループを作成および初期化します。ただし、安全性は低くなります。
```
app=> SELECT pgactive.pgactive_create_group(
node_name := 'node1-app',
node_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node1-app は、`pgactive` グループ内のノードを一意に識別するために割り当てる名前です。
**注記**
パブリックにアクセス可能な DB インスタンスで、このステップを正常に実行するには、`rds.custom_dns_resolution` パラメータを `1` に設定して有効にする必要があります。
1. DB インスタンスの準備が整っているかどうかを確認するには、次のコマンドを使用します。
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
コマンドが正常に完了した場合は、次の出力が表示されます。
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
**2 番目の RDS for PostgreSQL インスタンスを設定して `pgactive` グループに参加させるには**
次の例は、RDS for PostgreSQL DB インスタンスを `pgactive` グループに参加させる方法と、DB インスタンスに `pgactive` 拡張を作成するために必要なその他のステップを示しています。
次の手順では、RDS for PostgreSQL DB インスタンスが `pgactive` 拡張を使用して設定されていることを前提としています。詳細については、「[pgactive 拡張機能の初期化](Appendix.PostgreSQL.CommonDBATasks.pgactive.basic-setup.md)」を参照してください。
1. `psql` を使用して、パブリッシャーから更新を受け取るインスタンスに接続します。
```
psql --host=secondinstance.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password=PASSWORD --dbname=postgres
```
1. 次のコマンドを使用して、2 番目の RDS for PostgreSQL DB インスタンスにデータベースを作成します。
```
postgres=> CREATE DATABASE app;
```
1. 次のコマンドを使用して、接続先を新しいデータベースに切り替えます。
```
\c app
```
1. 既存のデータベースに `pgactive` 拡張を作成します。
```
app=> CREATE EXTENSION pgactive;
```
1. 次に示すように、以下のコマンドを使用して、より安全な方法で RDS for PostgreSQL の 2 番目の DB インスタンスを `pgactive` グループに参加させます。
```
-- connection info for endpoint1
CREATE SERVER pgactive_server_endpoint1
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint1
OPTIONS (user 'postgres', password '');
-- connection info for endpoint2
CREATE SERVER pgactive_server_endpoint2
FOREIGN DATA WRAPPER pgactive_fdw
OPTIONS (host '', dbname 'app');
CREATE USER MAPPING FOR postgres
SERVER pgactive_server_endpoint2
OPTIONS (user 'postgres', password '');
```
```
SELECT pgactive.pgactive_join_group(
node_name := 'endpoint2-app',
node_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint2',
join_using_dsn := 'user_mapping=postgres pgactive_foreign_server=pgactive_server_endpoint1'
);
```
代替手段として、以下のコマンドを使用して RDS for PostgreSQL の 2 番目の DB インスタンスを `pgactive` グループに参加させます。ただし、安全性は低くなります。
```
app=> SELECT pgactive.pgactive_join_group(
node_name := 'node2-app',
node_dsn := 'dbname=app host=secondinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD',
join_using_dsn := 'dbname=app host=firstinstance.111122223333.aws-region.rds.amazonaws.com user=postgres password=PASSWORD');
```
node2-app は、`pgactive` グループ内のノードを一意に識別するために割り当てる名前です。
1. DB インスタンスの準備が整っているかどうかを確認するには、次のコマンドを使用します。
```
app=> SELECT pgactive.pgactive_wait_for_node_ready();
```
コマンドが正常に完了すると、次の出力が表示されます。
```
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
最初の RDS for PostgreSQL データベースが比較的大きい場合は、`pgactive.pgactive_wait_for_node_ready()` から復元操作の進行状況レポートを出力されることを確認できます。出力は次の例のようになります:
```
NOTICE: restoring database 'app', 6% of 7483 MB complete
NOTICE: restoring database 'app', 42% of 7483 MB complete
NOTICE: restoring database 'app', 77% of 7483 MB complete
NOTICE: restoring database 'app', 98% of 7483 MB complete
NOTICE: successfully restored database 'app' from node node1-app in 00:04:12.274956
pgactive_wait_for_node_ready
------------------------------
(1 row)
```
この時点から、`pgactive` は 2 つの DB インスタンス間でデータを同期します。
1. 次のコマンドを使用して、2 番目の DB インスタンスのデータベースにデータがあるかどうかを確認できます。
```
app=> SELECT count(*) FROM inventory.products;
```
データが正常に同期されると、次の出力が表示されます。
```
count
-------
3
```
1. 次のコマンドを実行して新しい値を挿入します。
```
app=> INSERT INTO inventory.products (id, product_name) VALUES (4, 'lotion');
```
1. 最初の DB インスタンスのデータベースに接続し、次のクエリを実行します。
```
app=> SELECT count(*) FROM inventory.products;
```
アクティブ/アクティブレプリケーションが初期化されると、出力は次のようになります。
```
count
-------
4
```
**`pgactive` グループから DB インスタンスをデタッチして削除するには**
`pgactive` グループから DB インスタンスをデタッチして削除するには、次の手順に従います。
1. 次のコマンドを使用して、最初のインスタンスから 2 番目の DB インスタンスをデタッチできます。
```
app=> SELECT * FROM pgactive.pgactive_detach_nodes(ARRAY[‘node2-app']);
```
1. 次のコマンドを使用して、2 番目の DB インスタンスから `pgactive` 拡張を削除します。
```
app=> SELECT * FROM pgactive.pgactive_remove();
```
拡張を強制的に削除するには
```
app=> SELECT * FROM pgactive.pgactive_remove(true);
```
1. 次のコマンドを使用して拡張をドロップします。
```
app=> DROP EXTENSION pgactive;
```
# pgactive メンバー間のレプリケーションラグの測定
次のクエリを使用して、`pgactive` メンバー間のレプリケーションラグを表示できます。全体像を把握するには、すべての `pgactive` ノードでこのクエリを実行します。
```
app=> SELECT * FROM pgactive.pgactive_get_replication_lag_info();
│-[ RECORD 1 ]--------+---------------------------------------------
│node_name | node2-app
│node_sysid | 7481018224801653637
│application_name | pgactive:7481018224801653637:send
│slot_name | pgactive_16385_7481018224801653637_0_16385__
│active | t
│active_pid | 783486
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/2108150
│confirmed_flush_lsn | 0/2154690
│sent_lsn | 0/2154690
│write_lsn | 0/2154690
│flush_lsn | 0/2154690
│replay_lsn | 0/2154690
│-[ RECORD 2 ]--------+---------------------------------------------
│node_name | node1-app
│node_sysid | 7481018033434600853
│application_name | pgactive:7481018033434600853:send
│slot_name | pgactive_16385_7481018033434600853_0_16385__
│active | t
│active_pid | 783488
│pending_wal_decoding | 0
│pending_wal_to_apply | 0
│restart_lsn | 0/20F5AD0
│confirmed_flush_lsn | 0/214EF68
│sent_lsn | 0/214EF68
│write_lsn | 0/214EF68
│flush_lsn | 0/214EF68
│replay_lsn | 0/214EF68
```
少なくとも次の診断をモニタリングします。
アクティブ
アクティブが false の場合にアラートを設定します。これは、スロットが現在使用されていない (サブスクライバーインスタンスがパブリッシャーから切断された) ことを示します。
Pending\$1wal\$1decoding
PostgreSQL の論理レプリケーションでは、WAL ファイルはバイナリ形式で保存されます。パブリッシャーは、これらの WAL の変更をデコードし、論理的な変更 (挿入、更新、削除オペレーションなど) に変換する必要があります。
pending\$1wal\$1decoding メトリクスは、パブリッシャー側でデコードを待っている WAL ファイルの数を示します。
この数は、次の要因により増加する可能性があります。
+ サブスクライバーが接続されていない場合、アクティブステータスは false になり、pending\$1wal\$1decoding は増加する
+ スロットはアクティブだが、パブリッシャーは WAL の変更の量に対応できない
pending\$1wal\$1to\$1apply
pending\$1wal\$1apply メトリクスは、サブスクライバー側で適用を待っている WAL ファイルの数を示します。
いくつかの要因により、サブスクライバーが変更を適用できなくなり、ディスクがいっぱいになるシナリオが発生する可能性があります。
+ スキーマの違い - サンプルという名前のテーブルの WAL ストリームに変更があっても、そのテーブルがサブスクライバー側に存在しない場合など
+ プライマリキー列の値が更新された場合
+ セカンダリの一意のインデックスはデータの相違を引き起こす可能性がある
# pgactive 拡張機能のパラメータ設定
次のクエリを使用すると、`pgactive` 拡張に関連するすべてのパラメータを表示できます。
```
app=> SELECT * FROM pg_settings WHERE name LIKE 'pgactive.%';
```
`pgactive` 拡張機能は、さまざまなパラメータを使用して設定できます。これらのパラメータは、AWS マネジメントコンソール または CLI AWS インターフェイスから設定できます。
## 主な pgactive 拡張機能パラメータ
次の表は、`pgactive` 拡張機能の主なパラメータのリファレンスです。
| パラメータ | 単位 | デフォルト | 説明 |
| --- | --- | --- | --- |
| pgactive.conflict\$1logging\$1include\$1tuples | `boolean` | – | `pgactive` 拡張機能の完全なタプル情報をログに記録します。 変更を有効にするには、サーバーの再起動が必要です。 |
| pgactive.log\$1conflicts\$1to\$1table | `boolean` | – | `pgactive` 拡張機能が検出された競合を `pgactive.pgactive_conflict_history` テーブルにログ記録するかどうかを決定します。詳細については、「競合のログ記録」を参照してください。 変更を有効にするには、サーバーの再起動が必要です。 |
| pgactive.log\$1conflicts\$1to\$1logfile | `boolean` | – | `pgactive` 拡張機能が検出された競合を PostgreSQL ログファイルに記録するかどうかを決定します。詳細については、「競合のログ記録」を参照してください。 変更を有効にするには、サーバーの再起動が必要です。 |
| pgactive.synchronous\$1commit | `boolean` | 化 | pgactive 適用ワーカーのコミット動作を決定します。無効 (オフ) にすると、適用ワーカーは非同期コミットを実行します。これにより、適用オペレーション中の PostgreSQL のスループットが向上しますが、アップストリームへのリプレイ確認が遅延します。`off` に設定しても常に安全であり、トランザクションの損失やスキップは発生しません。この設定は、ダウンストリームノードでのディスクフラッシュのタイミングと、確認がアップストリームに送信されるタイミングにのみ影響します。システムは、チェックポイントや定期的な作業などの関連しないオペレーションを通じてコミットがディスクにフラッシュされるまで、リプレイフラッシュ確認の送信を遅らせます。ただし、アップストリームノードの `synchronous_standby_names` にダウンストリームがリストされている場合、`off` に設定すると、アップストリームノードでの同期コミットがクライアントに成功を報告するまでの時間が長くなります。この場合、パラメータは `on` に設定してください。 このパラメータが `on` に設定されていても、`synchronous_standby_names` にノードがリストされている場合は、アクティブ/アクティブ設定ではレプリケーションの競合が発生する可能性があります。これは、システムにはノード間ロックとグローバルスナップショット管理がないため、異なるノード上の同時トランザクションが同じタプルを変更できるためです。さらに、トランザクションはアップストリームノードでコミットした後にのみレプリケーションを開始します。同期コミットを有効にしても、pgactive 拡張機能が常時一貫性のあるシステムになるわけではありません。 |
| pgactive.temp\$1dump\$1directory | `string` | – | 初期設定時のデータベースクローン作成オペレーションに必要な一時ストレージパスを定義します。このディレクトリは postgres ユーザーによって書き込み可能で、完全なデータベースダンプを格納するのに十分なストレージ容量を持っている必要があります。システムは、論理コピーオペレーションによるデータベースの初期セットアップ中にのみ、この場所を使用します。このパラメータは、`pgactive_init_copy command` では使用されません。 |
| pgactive.max\$1ddl\$1lock\$1delay | `milliseconds` | `-1` | 同時書き込みトランザクションを強制的に中止するまでの DDL ロックの最大待機時間を指定します。デフォルト値は `-1` で、`max_standby_streaming_delay` で設定された値が使用されます。このパラメータには時間単位を指定できます。例えば、10 秒の場合は 10s と設定できます。この待機期間中、システムは進行中の書き込みトランザクションがコミットまたはロールバックされるのを待つ間に DDL ロックの取得を試みます。詳細については、「DDL ロック」を参照してください。 |
| pgactive.ddl\$1lock\$1timeout | `milliseconds` | `-1` | DDL ロック試行がロックの取得を待機する時間を指定します。デフォルト値は `-1` で、lock\$1timeout で指定された値を使用します。このパラメータは、10 秒の場合は 10s などの時間単位で設定できます。このタイマーは、DDL ロックを取得するための待機期間のみを制御します。システムがロックを取得し、DDL オペレーションを開始すると、タイマーは停止します。このパラメータは、DDL ロックを保持できる合計期間や全体的な DDL オペレーション時間を制限するものではありません。オペレーションの合計期間を制御するには、代わりに `statement_timeout` を使用します。詳細については、「DDL ロック」を参照してください。 |
| pgactive.debug\$1trace\$1ddl\$1locks\$1level | `boolean` | – | `pgactive` 拡張機能の DDL ロックオペレーションのデフォルトのデバッグログレベルを上書きします。この設定を行うと、DDL ロック関連のメッセージがデフォルトレベルではなく LOG デバッグレベルで出力されます。このパラメータを使用して、サーバー全体で詳細な `DEBUG1` または `DEBUG2` ログレベルを有効にせずに、DDL ロックアクティビティをモニタリングできます。 詳細度の高い順序で使用可能なログレベル。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) モニタリングオプションの詳細については、「グローバル DDL ロックのモニタリング」を参照してください。 この設定の変更は、設定を再読み込みすると有効になります。サーバーを再起動する必要はありません。 |
## 追加の pgactive 拡張機能パラメータ
次の表は、`pgactive` 拡張機能で利用可能な、あまり使用されない内部設定オプションを示しています。
| パラメータ | 単位 | デフォルト | 説明 |
| --- | --- | --- | --- |
| pgactive.debug\$1apply\$1delay | `integer` | – | `pgactive.pgactive_connections` エントリに明示的に適用遅延が指定されていない設定済み接続の適用遅延 (ミリ秒単位) を設定します。この遅延はノード作成時または参加時に設定され、pgactive はコミットされてから指定されたミリ秒数が経過するまで、ピアノードでトランザクションをリプレイしません。 主に、テスト環境で高レイテンシーのネットワークをシミュレートして、競合を簡単に作成するために使用します。例えば、ノード A とノード B に 500 ミリ秒の遅延が設定されている場合、ノード A に値を挿入した後、ノード B で競合する挿入を実行するために少なくとも 500 ミリ秒の猶予があります。 適用ワーカーを有効にするには、サーバーの再ロードまたは再起動が必要です。 |
| pgactive.connectability\$1check\$1duration | `integer` | – | データベースワーカーが接続の確立に失敗した場合に、接続を確立しようとする時間 (秒単位) を指定します。ワーカーは、成功するかこのタイムアウト値に達するまで、1 秒ごとに接続を試行します。この設定は、ワーカーが接続を確立する準備ができる前にデータベースエンジンが起動する場合に便利です。 |
| pgactive.skip\$1ddl\$1replication | `boolean` | `on` | `pgactive` が有効になっている Amazon RDS で DDL の変更をレプリケートまたは処理する方法を制御します。`on` に設定すると、ノードは非 pgcctive ノードと同様に DDL 変更を処理します。このパラメータを使用する場合、以下の要件が適用されます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) このパラメータは、スーパーユーザー権限を使用してグローバル、ローカル (セッションレベル) の 2 つの方法で変更できます。 このパラメータを誤って変更すると、レプリケーションのセットアップが中断される可能性があります。 |
| pgactive.do\$1not\$1replicate | `boolean` | – | このパラメータは内部使用のみを目的としています。トランザクションでこのパラメータを設定すると、変更は DB クラスター内の他のノードにレプリケートされません。 このパラメータを誤って変更すると、レプリケーションのセットアップが中断される可能性があります。 |
| pgactive.discard\$1mismatched\$1row\$1attributes | `boolean` | – | このパラメータは専門家による使用のみを目的としています。このパラメータは、特定のレプリケーションの問題をトラブルシューティングする場合にのみ使用することをお勧めします。このパラメータは、次の場合に使用します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) この設定により、以下のエラーメッセージがオーバーライドされ、データの不一致が発生してもレプリケーションは続行されます。「`cannot right-pad mismatched attributes; attno %u is missing in local table and remote row has non-null, non-dropped value for this attribute`」 このパラメータを誤って変更すると、レプリケーションのセットアップが中断される可能性があります。 |
| pgactive.debug\$1trace\$1replay | `boolean` | – | `on` に設定すると、ダウンストリームの適用ワーカーが処理するリモートアクションごとにログメッセージが出力されます。ログには以下が含まれます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) ログには、キューに登録された DDL コマンドとテーブルの DROP も記録されます。para> デフォルトでは、ログには行フィールドの内容は含まれません。ログに行の値を含めるには、次のフラグを有効にして再コンパイルする必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) このログ記録設定を有効にすると、パフォーマンスに影響する可能性があります。トラブルシューティングに必要な場合にのみ有効にすることをお勧めします。この設定の変更は、設定を再読み込みすると有効になります。サーバーを再起動する必要はありません。 |
| pgactive.extra\$1apply\$1connection\$1options | | – | pgactive ノードとのすべてのピアノード接続の接続パラメータを設定できます。これらのパラメータは、keepalives や SSL モードなどの設定を制御します。デフォルトでは、pgactive は次の接続パラメータを使用します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) デフォルトのパラメータを上書きするには、以下の同様のコマンドを使用します。 pgactive.extra\$1apply\$1connection\$1options = 'keepalives=0' 個々のノード接続文字列は、これらの設定と pgactive の組み込み接続オプションの両方よりも優先されます。接続文字列形式の詳細については、「[libpq connection strings](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING)」を参照してください。 デフォルトの keepalives 設定は有効のままにすることをお勧めします。信頼性の低いネットワーク経由で大規模なトランザクションが完了する際に問題が発生する場合にのみ、keepalives を無効にしてください。 デフォルトのkeepalives 設定は有効のままにすることをお勧めします。信頼性の低いネットワーク経由で大規模なトランザクションが完了する際に問題が発生する場合にのみ、keepalives を無効にしてください。この設定の変更は、設定を再読み込みすると有効になります。サーバーを再起動する必要はありません。 |
| pgactive.init\$1node\$1parallel\$1jobs (int) | | – | `pgactive.pgactive_join_group` 関数を使用して、論理ノードの結合時に `pg_dump` と `pg_restore` が使用できる並列ジョブの数を指定します。 この設定の変更は、設定を再読み込みすると有効になります。サーバーを再起動する必要はありません。 |
| pgactive.max\$1nodes | `int` | 4 | pgactive 拡張グループで許可されるノードの最大数を指定します。デフォルト値は 4 ノードです。このパラメータの値を設定するときは、次の点を考慮する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgactive.parameters.html) このパラメータは、設定ファイルで設定する方法と、`ALTER SYSTEM SET` コマンドを使用する方法の 2 つの方法で設定できます。 このパラメータのデフォルト値は `4` です。つまり、`pgactive` 拡張グループには、いつでも最大 4 ノードまでしか参加できません。 この変更は、サーバーを再起動した後に有効になります。 |
| pgactive.permit\$1node\$1identifier\$1getter\$1function\$1creation | `boolean` | – | このパラメータは、内部使用のみを目的としています。有効にすると、`pgactive` 拡張機能により、pgactive ノード識別子 getter 関数の作成が可能になります。 |
# アクティブ/アクティブ競合について
pgactive をアクティブ/アクティブモードで使用する場合、複数のノードから同じテーブルに書き込むと、データの競合が発生する可能性があります。一部のクラスタリングシステムでは、同時アクセスを防ぐために分散ロックを使用していますが、pgactive は地理的に分散されたアプリケーションに適した楽観的なアプローチを採用しています。
一部のデータベースクラスタリングシステムは、分散ロックを使用して同時データアクセスを防止します。このアプローチはサーバーが近接している場合に機能しますが、優れたパフォーマンスのためには非常に低いレイテンシーが必要となるため、地理的に分散したアプリケーションはサポートしていません。pgactive 拡張機能は、分散ロック (悲観的アプローチ) を使用する代わりに、楽観的アプローチを使用します。つまり、次のことを意味します。
+ 可能な場合には競合を回避できます。
+ 特定のタイプの競合の発生を許可します。
+ 競合が発生した場合に競合を解決します。
このアプローチにより、分散アプリケーションを構築する際の柔軟性が向上します。
## 競合の発生方法
ノード間の競合は、関連するすべてのトランザクションが同じノードで同時に発生した場合には発生しない一連のイベントから発生します。ノード間の変更はトランザクションのコミット後にのみ行われるため、各トランザクションはコミットされたノードで個別に有効ですが、その間に他の作業を行った別のノードで実行された場合は有効になりません。pgactive 適用は基本的に他のノードでトランザクションを再実行するため、適用されているトランザクションと受信側ノードでコミットされたトランザクションの間に競合がある場合、再実行オペレーションが失敗する可能性があります。
すべてのトランザクションが単一のノードで実行されている場合にほとんどの競合が発生しないのは、PostgreSQL にそれを防ぐためのトランザクション間通信メカニズムがあるからです。これには、以下が含まれます。
+ UNIQUE インデックス
+ SEQUENCE
+ 行とリレーションのロック
+ SERIALIZABLE 依存関係の追跡
これらのメカニズムはすべて、望ましくない同時実行の問題を防ぐためにトランザクション間で通信する方法です。
pgactive は、分散トランザクションマネージャーやロックマネージャーを使用しないため、低レイテンシーを実現し、ネットワークパーティションを適切に処理します。ただし、これは、異なるノード上のトランザクションが相互に完全に分離して実行されることを意味します。通常、分離はデータベースの一貫性を向上させますが、この場合は、競合を防ぐために分離を減らす必要があります。
## 競合のタイプ
発生する可能性のある競合には、以下が含まれます。
**Topics**
+ [
### PRIMARY KEY または UNIQUE の競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict1)
+ [
### INSERT/INSERT の競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict2)
+ [
### 複数の UNIQUE 制約に違反する INSERT
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict3)
+ [
### UPDATE/UPDATE の競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict4)
+ [
### PRIMARY KEY の UPDATE 競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)
+ [
### 複数の UNIQUE 制約に違反するUPDATE
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict6)
+ [
### UPDATE/DELETE の競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)
+ [
### INSERT/UPDATE の競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict8)
+ [
### DELETE/DELETE の競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict9)
+ [
### 外部キー制約の競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict10)
+ [
### 排他制約の競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict11)
+ [
### グローバルデータの競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict12)
+ [
### ロックの競合とデッドロックの中止
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict13)
+ [
### 相違による競合
](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)
### PRIMARY KEY または UNIQUE の競合
行の競合は、複数のオペレーションが単一のノードで同じ行キーを変更しようとしたときに発生します。これらの競合は、最も一般的なタイプのデータ競合です。
pgactive は検出された競合を、最終更新を優先する処理またはカスタム競合ハンドラーで解決します。
行の競合には以下が含まれます。
+ INSERT と INSERT
+ INSERT と UPDATE
+ UPDATE と DELETE
+ INSERT と DELETE
+ DELETE と DELETE
+ INSERT と DELETE
### INSERT/INSERT の競合
この最も一般的な競合は、2 つの異なるノードの INSERT が同じ PRIMARY KEY 値 (または PRIMARY KEY が存在しない場合は同じ UNIQUE 制約値) を持つタプルを作成するときに発生します。
pgactivelink は、発信元ホストのタイムスタンプを使用して最新のタプルを保持することで、INSERT の競合を解決します。このデフォルトの動作は、カスタム競合ハンドラーで上書きできます。このプロセスでは特別な管理者アクションは必要ありませんが、pgactivelink はノード全体で 1 つの INSERT オペレーションを破棄することに注意してください。カスタムハンドラーが実装しない限り、自動データマージは発生しません。
pgactivelink は、単一の制約違反に関連する競合のみを解決できます。INSERT が複数の UNIQUE 制約に違反している場合は、追加の競合解決戦略を実装する必要があります。
### 複数の UNIQUE 制約に違反する INSERT
INSERT/INSERT 競合は、PRIMARY KEY を含む複数の UNIQUE 制約に違反する可能性があります。pgactivelink は、単一の UNIQUE 制約を含む競合のみを処理できます。競合が複数の UNIQUE 制約に違反すると、適用ワーカーは失敗し、次のエラーを返します。
`multiple unique constraints violated by remotely INSERTed tuple.`
古いバージョンでは、この状況では代わりに「一意性の相違による競合」エラーが発生しました。
これらの競合を解決するには、手動でアクションを実行する必要があります。競合するローカルタプルを DELETE するか、UPDATE して新しいリモートタプルとの競合を削除します。複数の競合するタプルに対処する必要がある場合があることに注意してください。現在、pgactivelink には、複数の一意の制約に違反するタプルを無視、破棄、またはマージする組み込み機能はありません。
**注記**
詳細については、「複数の UNIQUE 制約に違反する UPDATE」を参照してください。
### UPDATE/UPDATE の競合
この競合は、2 つのノードが PRIMARY KEY を変更せずに同じタプルを同時に変更した場合に発生します。pgactivelink は、定義されている場合には、最終更新を優先するロジックまたはカスタム競合ハンドラーを使用してこれらの競合を解決します。PRIMARY KEY は、タプルマッチングと競合の解決に不可欠です。PRIMARY KEY のないテーブルの場合、pgactivelink は次のエラーで UPDATE オペレーションを拒否します。
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
### PRIMARY KEY の UPDATE 競合
pgactive は、PRIMARY KEY 更新を処理する際に制限があります。PRIMARY KEY で UPDATE オペレーションを実行することはできますが、pgactive はこれらのオペレーションに最終更新を優先するロジックを使用して競合を自動的に解決することはできません。PRIMARY KEY の更新が既存の値と競合しないようにする必要があります。PRIMARY KEY の更新中に競合が発生した場合、相違による競合が発生し、手動による介入が必要になります。これらの状況の処理の詳細については、「[相違による競合](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)」を参照してください。
### 複数の UNIQUE 制約に違反するUPDATE
pgactivelink は、受信する UPDATE が複数の UNIQUE 制約または PRIMARY KEY 値に違反している場合、最終更新を優先する競合解決を適用できません。この動作は、複数の制約違反がある INSERT オペレーションに似ています。このような状況では、手動による介入を必要とする相違による競合が発生します。詳細については、「[相違による競合](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict14)」を参照してください。
### UPDATE/DELETE の競合
この競合は、あるノードが行を UPDATE し、別のノードが同時にその行を DELETE した場合に発生します。この場合、再実行時に UPDATE/DELETE 競合が発生します。解決策は、カスタム競合ハンドラーが特に指定しない限り、DELETE の後に送信される UPDATE をすべて破棄することです。
pgactivelink は、タプルを照合して競合を解決するために PRIMARY KEY を必要とします。PRIMARY KEY のないテーブルの場合、次のエラーで DELETE オペレーションが拒否されます。
`Cannot run UPDATE or DELETE on table (tablename) because it does not have a primary key.`
**注記**
pgactivelink は、UPDATE/DELETE と INSERT/UPDATE の競合を区別できません。どちらの場合も、UPDATE は存在しない行に影響します。非同期レプリケーションおよびノード間に再実行順序がないことにより、pgactivelink は UPDATE が新しい行 (INSERT をまだ受信していない) に対するものか、削除された行に対するものかを判断できません。どちらのシナリオでも、pgactivelink は UPDATE を破棄します。
### INSERT/UPDATE の競合
この競合は、マルチノード環境で発生する可能性があります。これは、あるノードが行を INSERT し、2 番目のノードが行を UPDATE し、3 番目のノードが元の INSERT の前に UPDATE を受信したときに発生します。デフォルトでは、カスタム競合トリガーで特に指定されていない限り、pgactivelink は UPDATE を破棄することで、これらの競合を解決します。この解決方法により、ノード間でデータの不整合が発生する可能性があることに注意してください。同様のシナリオとその処理の詳細については、「[UPDATE/DELETE の競合](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict7)」を参照してください。
### DELETE/DELETE の競合
この競合は、2 つの異なるノードが同じタプルを同時に削除した場合に発生します。pgactivelink は、両方の DELETE オペレーションの結果が同じであるため、これらの競合を無害と見なします。このシナリオでは、pgactivelink はデータ整合性に影響を与えることなく、一方の DELETE オペレーションを安全に無視します。
### 外部キー制約の競合
FOREIGN KEY の制約により、既存のローカルデータにリモートトランザクションを適用するときに競合が発生する可能性があります。これらの競合は通常、トランザクションが発信元ノードの論理順序とは異なる順序で適用された場合に発生します。
デフォルトでは、pgactive は session\$1replication\$1role を `replica` として変更を適用し、レプリケーション中に外部キーチェックをバイパスします。アクティブ/アクティブ設定では、これが外部キー違反につながる可能性があります。ほとんどの違反は一時的なものであり、レプリケーションが追いつくと解決されます。ただし、pgactive はクロスノードの行ロックをサポートしていないため、外部キーのダングリングが発生する可能性があります。
この動作は、分断耐性のある非同期アクティブ/アクティブシステムに固有のものです。例えば、ノード A が新しい子行を挿入すると同時に、ノード B がその親行を削除する場合があります。システムは、ノード間でのこのタイプの同時変更を防ぐことはできません。
外部キーの競合を最小限に抑えるには、以下のことをお勧めします。
+ 外部キー関係を密接に関連するエンティティに制限します。
+ 可能な場合は、単一のノードから関連エンティティを変更します。
+ ほとんど変更を必要としないエンティティを選択します。
+ 変更に対してアプリケーションレベルの同時実行制御を実装します。
### 排他制約の競合
pgactivelink は排他制約をサポートしておらず、作成を制限します。
**注記**
既存のスタンドアロンデータベースを pgactivelink データベースに変換する場合は、すべての排他制約を手動で削除します。
分散非同期システムでは、制約に違反する行のセットが存在しないことは保証できません。これは、異なるノード上のすべてのトランザクションが完全に分離されているためです。排他制約は、排他制約違反のためにどのノードからも別のノードに再実行できなくなる、再実行デッドロックにつながる可能性があります。
pgactivelink に排他制約の作成を強制した場合、またはスタンドアロンデータベースを pgactivelink に変換するときに既存の排他制約を削除しない場合、レプリケーションが中断する可能性があります。レプリケーションの進行状況を回復するには、受信リモートタプルと競合するローカルタプルを削除または変更し、リモートトランザクションを適用できるようにします。
### グローバルデータの競合
pgactivelink を使用する場合、ノード間でロールなどの PostgreSQL システム全体のグローバルデータが異なると、競合が発生する可能性があります。これらの競合により、オペレーション (主に DDL) が 1 つのノードで成功してコミットされるものの、他のノードには適用されない可能性があります。
ユーザーが 1 つのノードに存在するものの、別のノードには存在しない場合、レプリケーションの問題が発生する可能性があります。
+ Node1 には `fred` という名前のユーザーがいますが、このユーザーは Node2 には存在しません。
+ `fred` が Node1 にテーブルを作成すると、テーブルは `fred` を所有者としてレプリケートされます。
+ この DDL コマンドを Node2 に適用すると、ユーザー `fred` が存在しないため、失敗します。
+ この失敗により、Node2 の PostgreSQL ログに ERROR が生成され、`pgactive.pgactive_stats.nr_rollbacks` カウンターが増分されます。
**解決策:** Node2 でユーザー `fred` を作成します。ユーザーが同じアクセス許可を持つ必要はありませんが、両方のノードに存在する必要があります。
1 つのノードにテーブルが存在するものの、別のノードには存在しない場合、データ変更オペレーションは失敗します。
+ Node1 には、Node2 に存在しない `foo` という名前のテーブルがあります。
+ Node1 の `foo` テーブルに対する DML オペレーションは、Node2 にレプリケートされると失敗します。
**解決策:** 同じ構造で Node2 にテーブル `foo` を作成します。
**注記**
pgactivelink は現在、CREATE USER コマンドまたは DDL オペレーションをレプリケートしません。DDL レプリケーションは将来のリリースが予定されています。
### ロックの競合とデッドロックの中止
pgactive 適用プロセスは通常のユーザーセッションのように動作するため、標準的な行とテーブルのロックルールに従います。そのため、pgactivelink 適用プロセスは、ユーザートランザクションまたは他の適用プロセスによって保持されているロックを待機する可能性があります。
以下のタイプのロックは適用プロセスに影響を与える可能性があります。
+ ユーザーセッションによる明示的なテーブルレベルのロック (LOCK TABLE...)
+ ユーザーセッションによる明示的な行レベルのロック (SELECT ... FOR UPDATE/FOR SHARE)
+ 外部キーからのロック
+ ローカルアクティビティまたは他のサーバーからの行の UPDATE、INSERT、または DELETE による暗黙的なロック
デッドロックは、次の間で発生する可能性があります。
+ pgactivelink 適用プロセスとユーザートランザクション
+ 2 つの適用プロセス
デッドロックが発生すると、PostgreSQL のデッドロック検出機能は問題のトランザクションのうち 1 つを終了します。pgactivelink 適用ワーカーのプロセスが終了すると、自動的に再試行され、通常は成功します。
**注記**
これらの問題は一時的なものであり、通常は管理者の介入は必要ありません。適用プロセスがアイドル状態のユーザーセッションのロックによって長期間ブロックされている場合は、ユーザーセッションを終了してレプリケーションを再開できます。この状況は、ユーザーが別のユーザーセッションに影響を与える長期間にわたるロックを保持する場合に似ています。
ロック関連の再生遅延を特定するには、PostgreSQL で `log_lock_waits` 機能を有効にします。
### 相違による競合
ノード間で同一であるはずのデータが予期せず異なる場合、相違による競合が発生します。これらの競合は発生すべきではないものの、現在の実装ではすべてを確実に防止できるわけではありません。
**注記**
行の PRIMARY KEY を変更すると、すべてのノードが変更を処理する前に別のノードが同じ行のキーを変更した場合、相違による競合が発生する可能性があります。プライマリキーの変更を避けるか、変更を指定された 1 つのノードに制限してください。詳細については、「[PRIMARY KEY の UPDATE 競合](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflict5)」を参照してください。
行データが関係した相違による競合には通常、管理者の介入が必要です。これらの競合を解決するには、`pgactive.pgactive_do_not_replicate` を使用してレプリケーションを一時的に無効にし、一方のノードのデータをもう一方のノードに合わせて手動で調整する必要があります。これらの競合は、pgactive を記載通りに使用し、安全でないとマークされた設定や関数を回避すれば、発生しません。
管理者は、これらの競合を手動で解決する必要があります。競合タイプによっては、`pgactive.pgactive_do_not_replicate` などの高度なオプションを使用する必要があります。不適切に使用すると状況が悪化する可能性があるため、これらのオプションは慎重に使用してください。競合にはさまざまな可能性が考えられるため、普遍的な解決の手順を提供することはできません。
異なるノード間で同一であるはずのデータが予期せず異なる場合、相違による競合が発生します。これらの競合は発生すべきではないものの、現在の実装ではこのような競合をすべて確実に防止できるわけではありません。
## 競合の回避または許容
ほとんどの場合、適切なアプリケーション設計を使用することで、競合を回避したり、アプリケーションが競合を許容するようにしたりできます。
競合は、複数のノードで同時操作が行われた場合にのみ発生します。競合を回避するには、以下を行います。
+ 1 つのノードにのみ書き込む
+ 各ノードの独立したデータベースサブセットに書き込む (各ノードに個別のスキーマを割り当てるなど)
INSERT と INSERT の競合の場合は、グローバルシーケンスを使用して競合を完全に防止します。
競合が許容できないユースケースの場合は、アプリケーションレベルで分散ロックを実装することを検討してください。多くの場合、最善の方法は、すべての競合を防ぐのではなく、pgactive の競合解決メカニズムと連携するようにアプリケーションを設計することです。詳細については、「[競合のタイプ](#Appendix.PostgreSQL.CommonDBATasks.pgactive.actact.conflicttypes)」を参照してください。
## 競合のログ記録
pgactivelink は、競合インシデントを `pgactive.pgactive_conflict_history` テーブルに記録し、アクティブ/アクティブ競合の診断と処理に役立つようにします。このテーブルへの競合ログは、`pgactive.log_conflicts_to_table` を true に設定した場合にのみ記録されます。pgactive 拡張機能は、log\$1min\$1messages が `LOG` または `lower` に設定されている場合に、`pgactive.log_conflicts_to_table` 設定に関係なく、競合を PostgreSQL ログファイルにも記録します。
競合履歴テーブルは、以下の目的で使用します。
+ アプリケーションに競合が起きる頻度を測定する
+ 競合が発生する場所を特定する
+ アプリケーションを改善し、競合率を低減する
+ 競合の解決策により望ましい結果が得られないケースを検出する
+ ユーザー定義の競合トリガーまたはアプリケーション設計の変更が必要な場所を特定する
行が競合した場合、オプションで行の値をログに記録できます。これは `pgactive.log_conflicts_to_table` 設定によって制御されます。以下の点に注意してください。
+ これはデータベース全体のグローバルオプションです。
+ 行値のログ記録をテーブル別に制御することはできません。
+ フィールド番号、配列要素、またはフィールド長に制限はありません。
+ 競合を引き起こす可能性のある数メガバイトの行を使用する場合は、この機能を有効にすることはお勧めできません。
競合履歴テーブルには、データベース内のすべてのテーブルのデータ (それぞれ異なるスキーマを持つ可能性がある) が含まれているため、ログに記録された行値は JSON フィールドとして保存されます。JSON は、SQL から直接呼び出す場合と同様に、`row_to_json` を使用して作成されます。PostgreSQL では `json_to_row` 関数が提供されていないため、ログに記録された JSON から複合型のタプルを再構築するには、テーブル固有のコード (PL/pgSQL、PL/Python、PL/Perl など) が必要です。
**注記**
ユーザー定義の競合のサポートは、今後の拡張機能として計画されています。
# pgactive スキーマについて
pgactive スキーマは、RDS for PostgreSQL のアクティブ/アクティブレプリケーションを管理します。このスキーマには、レプリケーション設定とステータス情報を保存するテーブルが含まれています。
**注記**
pgactive スキーマは進化しており、変更される可能性があります。これらのテーブルのデータを直接変更しないでください。
pgactive スキーマのキーテーブルには以下のものが含まれます。
+ `pgactive_nodes` − アクティブ/アクティブレプリケーショングループ内のノードに関する情報を保存します。
+ `pgactive_connections` − 各ノードの接続の詳細を保存します。
## pgactive\$1nodes
pgactive\$1nodes は、アクティブ/アクティブレプリケーショングループに参加しているノードに関する情報を保存します。
| 列 | タイプ | 照合 | Nullable | デフォルト |
| --- | --- | --- | --- | --- |
| node\$1sysid | text | – | NOT NULL | – |
| node\$1timeline | oid | – | NOT NULL | – |
| node\$1dboid | oid | – | NOT NULL | – |
| node\$1status | char | – | NOT NULL | – |
| node\$1name | text | – | NOT NULL | – |
| node\$1dsn | text | – | NOT NULL | – |
| node\$1init\$1from\$1dsn | text | – | NOT NULL | – |
| node\$1read\$1only | ブール値 | – | – | false |
| node\$1seq\$1id | smallint | – | NOT NULL | – |
**node\$1sysid**
ノードの一意の ID。`pgactive_create_group` または `pgactive_join_group` 中に生成されます。
**node\$1status**
ノードの準備状況:
+ **b** - セットアップの開始
+ **i** - 初期化
+ **c** - キャッチアップ
+ **o** - アウトバウンドスロットの作成
+ **r** - 準備完了
+ **k** - 強制終了
この列は、ノードが接続されているか切断されているかを示しません。
**node\$1name**
ユーザーが指定した一意のノード名。
**node\$1dsn**
接続文字列またはユーザーマッピング名
**node\$1init\$1from\$1dsn**
このノードが作成された DSN。
## pgactive\$1connection
pgactive\$1connections は、各ノードの接続の詳細を保存します。
| 列 | タイプ | 照合 | Nullable | デフォルト |
| --- | --- | --- | --- | --- |
| conn\$1sysid | text | なし | NOT NULL | なし |
| conn\$1timeline | oid | なし | NOT NULL | なし |
| conn\$1dboid | oid | なし | NOT NULL | なし |
| conn\$1dsn | text | なし | NOT NULL | なし |
| conn\$1apply\$1delay | integer | なし | なし | なし |
| conn\$1replication\$1sets | text | なし | なし | なし |
conn\$1sysid
このエントリが参照するノードのノード識別子。
conn\$1dsn
pgactive.pgactive\$1nodes `node_dsn` と同じです。
conn\$1apply\$1delay
設定されている場合、リモートノードから各トランザクションを適用するまで待機するミリ秒数。主にデバッグ用。null の場合、グローバルデフォルトが適用されます。
## レプリケーションセットの使用
レプリケーションセットは、レプリケーションオペレーションに含めるテーブルと除外するテーブルを決定します。デフォルトでは、次の関数を使用して指定しない限り、すべてのテーブルがレプリケートされます。
+ `pgactive_exclude_table_replication_set()` - 指定されたテーブルをレプリケーションから除外する
+ `pgactive_include_table_replication_set()` - 指定されたテーブルをレプリケーションに含める
**注記**
レプリケーションセットを設定する前に、次の点を考慮してください。
テーブルの包含または除外は、`pgactive_create_group()` の実行後、`pgactive_join_group()` を実行するより前にのみ設定できます。
`pgactive_exclude_table_replication_set()` を使用した後、`pgactive_include_table_replication_set()` を使用することはできません。
`pgactive_exclude_table_replication_set()` を使用した後、`pgactive_include_table_replication_set()` を使用することはできません。
システムは、初期設定に基づいて新しく作成されたテーブルを異なる方法で処理します。
+ テーブルを除外した場合: `pgactive_join_group()` 以降に作成された新しいテーブルは、自動的にレプリケーションに含まれます。
+ テーブルを含めた場合: `pgactive_join_group()` 以降に作成された新しいテーブルは、自動的にレプリケーションから除外されます。
特定のテーブルのレプリケーションセット設定を表示するには、`pgactive.pgactive_get_table_replication_sets()` 関数を使用します。
# pgactive 関数リファレンス
以下に、pgactive 関数のリストとそのパラメータ、戻り値、実用的な使用上の注意事項を示します。
## get\$1last\$1applied\$1xact\$1info
指定されたノードに最後に適用されたトランザクション情報を取得します。
**引数**
+ sysid (テキスト) - タイムライン OID
+ dboid (OID)
**戻り型**
以下を記録します。
+ last\$1applied\$1xact\$1id (OID)
+ last\$1applied\$1xact\$1committs (タイムゾーン付きのタイムスタンプ)
+ last\$1applied\$1xact\$1at (タイムゾーン付きのタイムスタンプ)
**使用に関する注意事項**
この関数を使用して、指定されたノードに最後に適用されたトランザクション情報を取得します。
## pgactive\$1apply\$1pause
レプリケーション適用プロセスを一時停止します。
**引数**
なし
**戻り型**
boolean
**使用に関する注意事項**
この関数を呼び出して、レプリケーション適用プロセスを一時停止します。
## pgactive\$1apply\$1resume
レプリケーション適用プロセスを再開します。
**引数**
なし
**戻り型**
void
**使用に関する注意事項**
この関数を呼び出して、レプリケーション適用プロセスを再開します。
## pgactive\$1is\$1apply\$1paused
レプリケーション適用が現在一時停止されているかどうかを確認します。
**引数**
なし
**戻り型**
boolean
**使用に関する注意事項**
この関数を使用して、レプリケーション適用が現在一時停止されているかどうかを確認します。
## pgactive\$1create\$1group
スタンドアロンデータベースを初期ノードに変換して pgactive グループを作成します。
**引数**
+ node\$1name (テキスト)
+ node\$1dsn (テキスト)
+ apply\$1delay integer DEFAULT NULL::integer - replication\$1sets text[] DEFAULT ARRAY[‘default’::text]
**戻り型**
void
**使用に関する注意事項**
スタンドアロンデータベースを初期ノードに変換して pgactive グループを作成します。この関数は、ノードを pgactive ノードに変換する前に、サニティチェックを実行します。この関数を使用する前に、PostgreSQL クラスターに pgactive バックグラウンドワーカーをサポートするのに十分な `max_worker_processes` が使用可能であることを確認してください。
## pgactive\$1detach\$1nodes
pgactive グループから指定されたノードを削除します。
**引数**
+ p\$1nodes (text[])
**戻り型**
void
**使用に関する注意事項**
この関数を使用して、pgactive グループから指定されたノードを削除します。
## pgactive\$1exclude\$1table\$1replication\$1set
レプリケーションから特定のテーブルを除外します。
**引数**
+ p\$1relation (regclass)
**戻り型**
void
**使用に関する注意事項**
この関数を使用して、レプリケーションから特定のテーブルを除外します。
## pgactive\$1get\$1replication\$1lag\$1info
ノードの詳細、WAL ステータス、LSN 値など、詳細なレプリケーションラグ情報を取得します。
**引数**
なし
**戻り型**
SETOF record - node\$1name text - node\$1sysid text - application\$1name text - slot\$1name text - active boolean - active\$1pid integer - pending\$1wal\$1decoding bigint - Approximate size of WAL in bytes to be decoded on the sender node - pending\$1wal\$1to\$1apply bigint - Approximate size of WAL in bytes to be applied on receiving node - restart\$1lsn pg\$1lsn - confirmed\$1flush\$1lsn pg\$1lsn - sent\$1lsn pg\$1lsn - write\$1lsn pg\$1lsn - flush\$1lsn pg\$1lsn - replay\$1lsn pg\$1lsn
**使用に関する注意事項**
この関数を呼び出して、ノードの詳細、WAL ステータス、LSN 値などのレプリケーションラグ情報を取得します。
## pgactive\$1get\$1stats
pgactive レプリケーションの統計を取得します。
**引数**
なし
**戻り型**
SETOF record - rep\$1node\$1id oid - rilocalid oid - riremoteid text - nr\$1commit bigint - nr\$1rollback bigint - nr\$1insert bigint - nr\$1insert\$1conflict bigint - nr\$1update bigint - nr\$1update\$1conflict bigint - nr\$1delete bigint - nr\$1delete\$1conflict bigint - nr\$1disconnect bigint
**使用に関する注意事項**
この関数を使用して、pgactive レプリケーションの統計を取得します。
## pgactive\$1get\$1table\$1replication\$1sets
特定のリレーションのレプリケーションセット設定を取得します。
**引数**
+ リレーション (regclass)
**戻り型**
SETOF レコード
**使用に関する注意事項**
この関数を呼び出して、特定のリレーションのレプリケーションセット設定を取得します。
## pgactive\$1include\$1table\$1replication\$1set
レプリケーションに特定のテーブルを含めます。
**引数**
+ p\$1relation (regclass)
**戻り型**
void
**使用に関する注意事項**
この関数を使用して、レプリケーションに特定のテーブルを含めます。
## pgactive\$1join\$1group
既存の pgactive グループにノードを追加します。
**引数**
+ node\$1name (テキスト)
+ node\$1dsn (テキスト)
+ join\$1using\$1dsn (テキスト)
+ apply\$1delay (整数、オプション)
+ replication\$1sets (text[]、デフォルト: ['default'])
+ bypass\$1collation\$1check (ブール値、デフォルト: false)
+ bypass\$1node\$1identifier\$1creation (ブール値、デフォルト: false)
+ bypass\$1user\$1tables\$1check (ブール値、デフォルト: false)
**戻り型**
void
**使用に関する注意事項**
この関数を呼び出して、既存の pgactive グループにノードを追加します。PostgreSQL クラスターに pgactive バックグラウンドワーカー用の十分な max\$1worker\$1processes があることを確認します。
## pgactive\$1remove
ローカルノードからすべての pgactive コンポーネントを削除します。
**引数**
+ force (ブール値、デフォルト: false)
**戻り型**
void
**使用に関する注意事項**
この関数を呼び出して、ローカルノードからすべての pgactive コンポーネントを削除します。
## pgactive\$1snowflake\$1id\$1nextval
ノード固有の一意のシーケンス値を生成します。
**引数**
+ regclass
**戻り型**
bigint
**使用に関する注意事項**
この関数を使用して、ノード固有の一意のシーケンス値を生成します。
## pgactive\$1update\$1node\$1conninfo
pgactive ノードの接続情報を更新します。
**引数**
+ node\$1name\$1to\$1update (テキスト)
+ node\$1dsn\$1to\$1update (テキスト)
**戻り型**
void
**使用に関する注意事項**
この関数を使用して、pgactive ノードの接続情報を更新します。
## pgactive\$1wait\$1for\$1node\$1ready
グループの作成または参加オペレーションの進行状況をモニタリングします。
**引数**
+ タイムアウト (整数、デフォルト: 0)
+ progress\$1interval (整数、デフォルト: 60)
**戻り型**
void
**使用に関する注意事項**
この関数を呼び出して、グループの作成または参加オペレーションの進行状況をモニタリングします。
# アクティブ/アクティブレプリケーションの競合の処理
`pgactive` 拡張は、クラスターごとではなく、データベースごとに機能します。`pgactive` を使用する各 DB インスタンスは、独立したインスタンスであり、あらゆるソースからのデータ変更を受け入れることができます。変更が DB インスタンスに送信されると、PostgreSQL は変更をローカルにコミットし、`pgactive` を使用して他の DB インスタンスに非同期に変更をレプリケートします。2 つの PostgreSQL DB インスタンスが同じレコードをほぼ同時に更新すると、競合が発生する可能性があります。
`pgactive` 拡張は、競合の検出と自動解決のためのメカニズムを提供します。両方の DB インスタンスでトランザクションがコミットされた時点のタイムスタンプを追跡し、最新のタイムスタンプで変更を自動的に適用します。また、`pgactive` 拡張は、`pgactive.pgactive_conflict_history` テーブルで競合が発生した場合もログに記録します。
`pgactive.pgactive_conflict_history` は継続的に増大します。パージポリシーを定義するとよいでしょう。これを行うには、一部のレコードを定期的に削除するか、この関係のパーティションスキームを定義します (その後で対象のパーティションをデタッチ、ドロップ、切り捨てることができます)。パージポリシーを定期的に実装するには、 `pg_cron` 拡張機能を使用するというオプションがあります。`pg_cron` 履歴テーブルの例については、「[PostgreSQL pg\$1cron 拡張機能を使用したメンテナンスのスケジュール](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html)」の次の情報を参照してください。
# アクティブ/アクティブレプリケーションでのシーケンスの処理
`pgactive` 拡張を使用した RDS for PostgreSQL DB インスタンスは、2 つの異なるシーケンスメカニズムを使用して固有の値を生成します。
**グローバルシーケンス**
グローバルシーケンスを使用するには、`CREATE SEQUENCE` ステートメントを使用してローカルシーケンスを作成します。`usingnextval(seqname)` の代わりに `pgactive.pgactive_snowflake_id_nextval(seqname)` を使用すると、シーケンスの次の固有な値を取得できます。
次の例では、グローバルシーケンスを作成します。
```
app=> CREATE TABLE gstest (
id bigint primary key,
parrot text
);
```
```
app=>CREATE SEQUENCE gstest_id_seq OWNED BY gstest.id;
```
```
app=> ALTER TABLE gstest \
ALTER COLUMN id SET DEFAULT \
pgactive.pgactive_snowflake_id_nextval('gstest_id_seq');
```
**分割シーケンス**
分割ステップまたは分割シーケンスでは、通常の PostgreSQL シーケンスをノードごとに使用します。各シーケンスは同じ量ずつインクリメントされ、異なるオフセットから始まります。例えば、ステップ 100 の場合、ノード 1 は 101、201、301 などとしてシーケンスを生成し、ノード 2 は 102、202、302 などとしてシーケンスを生成します。このスキームは、ノードが長時間通信できない場合でも適切に機能しますが、設計者はスキーマを確立するときに最大ノード数を指定する必要があり、ノードごとの設定が必要になります。間違えると、シーケンスが重複しやすくなります。
次に示すように、ノードで目的のシーケンスを作成することで、このアプローチを `pgactive` で比較的簡単に設定できます。
```
CREATE TABLE some_table (generated_value bigint primary key);
```
```
app=> CREATE SEQUENCE some_seq INCREMENT 100 OWNED BY some_table.generated_value;
```
```
app=> ALTER TABLE some_table ALTER COLUMN generated_value SET DEFAULT nextval('some_seq');
```
次に、各ノードで `setval` を呼び出して、次のように異なるオフセットの開始値を指定します。
```
app=>
-- On node 1
SELECT setval('some_seq', 1);
-- On node 2
SELECT setval('some_seq', 2);
```
# pg\$1repack 拡張機能を使用して、テーブルやインデックスの膨張を抑制する
`pg_repack` 拡張機能を使用して、`VACUUM FULL` の代わりとしてテーブルやインデックスの肥大化を取り除くことができます。このエクステンションは、RDS for PostgreSQL のバージョン 9.6.3 以降でサポートされています。`pg_repack` 拡張機能の詳細については、[GitHub プロジェクトのドキュメント](https://reorg.github.io/pg_repack/)をご覧ください。
`VACUUM FULL` とは異なり、`pg_repack` 拡張機能では、次の場合にテーブルの再構築オペレーション中に短期間だけ排他的ロック (AccessExclusiveLock) が必要です。
+ ログテーブルの初回作成 – 次の例に示すように、データの初回コピー中に発生した変更を記録するログテーブルが作成されます。
```
postgres=>\dt+ repack.log_*
List of relations
-[ RECORD 1 ]-+----------
Schema | repack
Name | log_16490
Type | table
Owner | postgres
Persistence | permanent
Access method | heap
Size | 65 MB
Description |
```
+ 最終スワップアンドドロップフェーズ。
再構築オペレーションの残りの部分で必要なのは、元のテーブルから新しいテーブルに行をコピーするための `ACCESS SHARE` ロックのみです。これにより、INSERT、UPDATE、DELETE オペレーションを通常どおりに進めることができます。
## 推奨事項
次の推奨事項は、`pg_repack` 拡張機能を使用してテーブルとインデックスの肥大化を取り除く場合に適用されます。
+ 業務時間外または他のデータベースアクティビティのパフォーマンスへの影響を最小限に抑えるために、メンテナンスウィンドウで再パックを実行します。
+ 再構築アクティビティ中にブロッキングセッションを注意深くモニタリングし、`pg_repack` をブロックする可能性のあるアクティビティが元のテーブルにないことを確認します。特に、元のテーブルで排他的ロックが必要なときは、最後のスワップアンドドロップフェーズ中にアクティビティがないことを確認します。詳細については、「[クエリをブロックしているものの特定](https://repost.aws/knowledge-center/rds-aurora-postgresql-query-blocked)」を参照してください。
ブロッキングセッションが表示された場合は、慎重に検討した後、次のコマンドを使用してセッションを終了できます。これは、`pg_repack` の継続によって再構築を完了するのに役立ちます。
```
SELECT pg_terminate_backend(pid);
```
+ トランザクション率が非常に高いシステムで `pg_repack's` ログテーブルから蓄積された変更を適用すると、適用プロセスが変更の速度に対して遅れる可能性があります。このような場合、`pg_repack` は適用プロセスを完了できません。詳細については、「[再パック中の新しいテーブルのモニタリング](#Appendix.PostgreSQL.CommonDBATasks.pg_repack.Monitoring)」を参照してください。インデックスが著しく肥大化している場合、代替の解決策は、インデックスのみの再パックを実行することです。これにより、VACUUM のインデックスクリーンアップサイクルをより速く完了させることもできます。
PostgreSQL バージョン 12 の手動 VACUUM を使用してインデックスのクリーンアップフェーズをスキップできます。また、PostgreSQL バージョン 14 の緊急自動バキューム中は自動的にスキップされます。これにより、VACUUM はインデックスの肥大化を取り除くことなくより迅速に完了します。これは、循環 VACUUM の防止などの緊急時にのみ使用されます。詳細については、Amazon Aurora ユーザーガイドの「[インデックスの肥大化の回避](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html#AuroraPostgreSQL.diag-table-ind-bloat.AvoidinginIndexes)」を参照してください。
## 前提条件
+ テーブルには、PRIMARY KEY 制約または null 以外の UNIQUE 制約が必要です。
+ 拡張機能のバージョンは、クライアントとサーバーの両方で同じである必要があります。
+ RDS インスタンスに、肥大化がないテーブルの合計サイズ以上の `FreeStorageSpace` があることを確認します。例として、TOAST とインデックスを含むテーブルの合計サイズが 2TB で、テーブルの肥大化の合計が 1TB であるとします。必須の `FreeStorageSpace` は、次の計算によって返される値よりも大きくなければなりません。
`2TB (Table size)` - `1TB (Table bloat)` = `1TB`
次のクエリを使用してテーブルの合計サイズを確認し、`pgstattuple` を使用して肥大化を導き出すことができます。詳細については、Amazon Aurora ユーザーガイドの「[テーブルとインデックスの肥大化の診断](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.diag-table-ind-bloat.html)」を参照してください。
```
SELECT pg_size_pretty(pg_total_relation_size('table_name')) AS total_table_size;
```
このスペースは、アクティビティの完了後に再利用されます。
+ RDS インスタンスに再パックオペレーションを処理するのに十分なコンピューティング容量と IO 容量があることを確認します。パフォーマンスのバランスを最適化するために、インスタンスクラスをスケールアップすることを検討してください。
**`pg_repack` 拡張機能を使用するには**
1. 次のコマンドを実行して、RDS for PostgreSQL DB インスタンスに `pg_repack` エクステンションをインストールします。
```
CREATE EXTENSION pg_repack;
```
1. 次のコマンドを実行して、`pg_repack` によって作成されたテンポラリログテーブルへの書き込みアクセス権を付与します。
```
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
```
1. `pg_repack` クライアントユーティリティを使用してデータベースに接続します。`rds_superuser` 権限を持つアカウントを使用します。例として、`rds_test` ロールに `rds_superuser` 権限があるとします。次の構文は、`postgres` データベース内のすべてのテーブルインデックスを含む完全なテーブルに対して `pg_repack` を実行します。
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test -k postgres
```
**注記**
-k オプションを使用して接続する必要があります。-a オプションはサポートされていません。
`pg_repack` クライアントからのレスポンスにより、再パッケージされる DB インスタンスのテーブルに関する情報が提供されます。
```
INFO: repacking table "pgbench_tellers"
INFO: repacking table "pgbench_accounts"
INFO: repacking table "pgbench_branches"
```
1. 次の構文は、`postgres` データベース内のインデックスを含む単一のテーブル `orders` を再パックします。
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders -k postgres
```
次の構文では、`postgres` データベース内の `orders` テーブルのインデックスのみを再パックします。
```
pg_repack -h db-instance-name.111122223333.aws-region.rds.amazonaws.com -U rds_test --table orders --only-indexes -k postgres
```
## 再パック中の新しいテーブルのモニタリング
+ データベースのサイズは、再パックのスワップアンドドロップフェーズまで、テーブルの合計サイズから肥大化を引いた数だけ増加します。データベースサイズの増加率をモニタリングし、再パックの速度を計算して、最初のデータ転送の完了にかかる時間を概算で見積もることができます。
例えば、テーブルの合計サイズを 2TB、データベースのサイズを 4TB、テーブルの合計肥大化を 1TB とします。再パックオペレーションの最後に計算によって返されるデータベースの合計サイズ値は次のとおりです。
`2TB (Table size)` \$1 `4 TB (Database size)` - `1TB (Table bloat)` = `5TB`
再パックオペレーションの速度を概算で見積もるには、2 つの時点の間の増加率をバイト単位でサンプリングします。増加率が 1GB の場合、最初のテーブル構築オペレーションが完了するまでに 1000 分または 16.6 時間かかることがあります。最初のテーブル構築に加えて、`pg_repack` は蓄積された変更を適用する必要があります。所要時間は、進行中の変更と蓄積された変更の適用速度によって異なります。
**注記**
`pgstattuple` 拡張機能を使用して、テーブルの肥大化を計算できます。詳細については、「[pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html)」を参照してください。
+ 再パックスキーマの下の `pg_repack's` ログテーブルの行数は、最初のロード後に新しいテーブルに適用される保留中の変更の量を表します。
`pg_stat_all_tables` の `pg_repack's` ログテーブルをチェックして、新しいテーブルに適用される変更をモニタリングできます。`pg_stat_all_tables.n_live_tup` は、新しいテーブルに適用される保留中のレコードの数を示します。詳細については、「[pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW)」を参照してください。
```
postgres=>SELECT relname,n_live_tup FROM pg_stat_all_tables WHERE schemaname = 'repack' AND relname ILIKE '%log%';
-[ RECORD 1 ]---------
relname | log_16490
n_live_tup | 2000000
```
+ `pg_stat_statements` 拡張機能を使用して、再パックオペレーションの各ステップにかかる時間を調べることができます。これは、本番環境で同じ再パックオペレーションを適用する準備に役立ちます。出力をさらに拡張するように `LIMIT` 句を調整できます。
```
postgres=>SELECT
SUBSTR(query, 1, 100) query,
round((round(total_exec_time::numeric, 6) / 1000 / 60),4) total_exec_time_in_minutes
FROM
pg_stat_statements
WHERE
query ILIKE '%repack%'
ORDER BY
total_exec_time DESC LIMIT 5;
query | total_exec_time_in_minutes
-----------------------------------------------------------------------+----------------------------
CREATE UNIQUE INDEX index_16493 ON repack.table_16490 USING btree (a) | 6.8627
INSERT INTO repack.table_16490 SELECT a FROM ONLY public.t1 | 6.4150
SELECT repack.repack_apply($1, $2, $3, $4, $5, $6) | 0.5395
SELECT repack.repack_drop($1, $2) | 0.0004
SELECT repack.repack_swap($1) | 0.0004
(5 rows)
```
再パックは完全にアウトオブプレースオペレーションであるため、元のテーブルは影響を受けず、元のテーブルの復元を必要とする予期しない課題は予想されません。再パックが予期せず失敗した場合は、エラーの原因を調べて解決する必要があります。
問題が解決したら、テーブルが存在するデータベースに `pg_repack` 拡張機能を削除して再作成し、`pg_repack` ステップを再試行してください。さらに、コンピューティングリソースの可用性とテーブルの同時アクセシビリティは、再パックオペレーションをタイムリーに完了させる上で重要な役割を果たします。
# PLV8 拡張機能のアップグレードおよび使用
PLV8 は、信頼できる JavaScript 言語の PostgreSQL 用エクステンションです。ストアドプロシージャ、トリガー、SQL から呼び出し可能なその他のプロシージャルコードに使用できます。この言語のエクステンションは、PostgreSQL のすべての最新リリースでサポートされています。
[PLV8](https://plv8.github.io/) を使用しており、PostgreSQL を新しい PLV8 バージョンにアップグレードする場合は、新しいエクステンションをすぐに利用できるようになります。次のステップを実行して、カタログメタデータを PLV8 の新しいバージョンと同期させます。これらの手順はオプションですが、メタデータ不一致の警告を回避するために実行することを強くお勧めします。
アップグレードプロセスでは、既存の PLV8 機能がすべて削除されます。そのため、アップグレードする前に、RDS for PostgreSQL DB インスタンスのスナップショットを作成しておくことをお勧めします。詳細については、「[Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成](USER_CreateSnapshot.md)」を参照してください。
**重要**
PostgreSQL バージョン 18 以降の Amazon RDS for PostgreSQL では、`plcoffee` および `plls` の PostgreSQL 拡張機能が廃止されます。エンジンバージョンがアップグレードされる場合に備えて、今後はアプリケーションで CoffeeScript や LiveScript を使用しないことをお勧めします。
**カタログメタデータを新しいバージョンの PLV8 と同期させるには**
1. 更新する必要があることを確認します。そのためには、インスタンスに接続されている間に以下のコマンドを実行します。
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
インストールされているバージョンとしてデフォルトのバージョンより低いバージョンが表示された場合は、この手順を実行して、エクステンションを更新する必要があります。例えば、以下の結果セットは更新の必要があることを表します。
```
name | default_version | installed_version | comment
--------+-----------------+-------------------+--------------------------------------------------
plls | 2.1.0 | 1.5.3 | PL/LiveScript (v8) trusted procedural language
plcoffee| 2.1.0 | 1.5.3 | PL/CoffeeScript (v8) trusted procedural language
plv8 | 2.1.0 | 1.5.3 | PL/JavaScript (v8) trusted procedural language
(3 rows)
```
1. RDS for PostgreSQL DB インスタンスのスナップショットを作成していない場合は、作成してください。次のステップは、スナップショットの作成中も続行できます。
1. DB インスタンスの PLV8 関数の数を取得し、アップグレード後にすべて揃っていることを確認できるようにします。例えば次の SQL クエリ では、plv8、plcoffee、plls で記述されている関数の数が返ります。
```
SELECT proname, nspname, lanname
FROM pg_proc p, pg_language l, pg_namespace n
WHERE p.prolang = l.oid
AND n.oid = p.pronamespace
AND lanname IN ('plv8','plcoffee','plls');
```
1. pg\$1dump を使用して、スキーマのみのダンプファイルを作成します。例えば、クライアントマシンの `/tmp` ディレクトリに、ファイルを作成します。
```
./pg_dump -Fc --schema-only -U master postgres >/tmp/test.dmp
```
この例では、以下のオプションを使用します。
+ `-Fc` – カスタム形式
+ -- スキーマのみ – スキーマの作成に必要なコマンド (ここでは関数) のみをダンプする
+ `-U` – RDS マスターユーザー名
+ `database` – DB インスタンスのデータベース名
pg\$1dump の詳細については、「PostgreSQL ドキュメント」の「[pg\$1dump](https://www.postgresql.org/docs/current/static/app-pgdump.html )」を参照してください。
1. ダンプファイルに存在する "CREATE FUNCTION" DDL ステートメントを抽出します。次の例では `grep` コマンドを実行して、関数を作成する DDL ステートメントを抽出し、ファイルに保存します。この ddl は後続のステップで関数を再作成するために使用します。
```
./pg_restore -l /tmp/test.dmp | grep FUNCTION > /tmp/function_list
```
pg\$1restore の詳細については、「PostgreSQL ドキュメント」の「[pg\$1restore](https://www.postgresql.org/docs/current/static/app-pgrestore.html)」を参照してください。
1. 関数およびエクステンションを削除します。次の例では、PLV8 ベースのオブジェクトを削除します。CASCADE オプションでは、すべての依存が削除されます。
```
DROP EXTENSION plv8 CASCADE;
```
plcoffee または plls に基づくオブジェクトが PostgreSQL インスタンスに含まれている場合は、それらのエクステンションに対してこのステップを繰り返します。
1. エクステンションを作成します。次の例では、plv8、plcoffee、plls のエクステンションが作成されます。
```
CREATE EXTENSION plv8;
CREATE EXTENSION plcoffee;
CREATE EXTENSION plls;
```
1. ダンプファイルおよび "ドライバ" ファイルを使用して関数を作成します。
次の例では、前に抽出した関数が再作成されます。
```
./pg_restore -U master -d postgres -Fc -L /tmp/function_list /tmp/test.dmp
```
1. 次のクエリを使用して、すべての関数が再作成されたことを確認します。
```
SELECT * FROM pg_available_extensions WHERE name IN ('plv8','plls','plcoffee');
```
PLV8 バージョン 2 では、次の行が結果セットに追加されます。
```
proname | nspname | lanname
---------------+------------+----------
plv8_version | pg_catalog | plv8
```
# PL/Rust を使って Rust 言語で PostgreSQL 関数を記述する
PL/Rust は、PostgreSQL のための信頼できる Rust 言語エクステンションです。ストアドプロシージャ、関数、SQL から呼び出し可能なその他のプロシージャルコードに使用できます。PL/Rust 言語拡張は次のバージョンで利用可能です。
+ RDS for PostgreSQL 17.1 またはそれ以降の 17 バージョン
+ RDS for PostgreSQL 16.1 またはそれ以降の 16 バージョン
+ RDS for PostgreSQL 15.2-R2 またはそれ以降の 15 バージョン
+ RDS for PostgreSQL 14.9 またはそれ以降の 14 バージョン
+ RDS for PostgreSQL 13.12 またはそれ以降の 13 バージョン
詳細については、GitHub の「[PL/Rust](https://github.com/tcdi/plrust#readme)」を参照してください。
**Topics**
+ [
## PL/Rust の設定
](#PL_Rust-setting-up)
+ [
## PL/Rust を使った関数の作成
](#PL_Rust-create-function)
+ [
## PL/Rust の入ったクレートを使用する
](#PL_Rust-crates)
+ [
## PL/Rust の制限事項
](#PL_Rust-limitations)
## PL/Rust の設定
DB インスタンスに plrust 拡張機能をインストールするには、DBインスタンスに関連付けられた DB パラメータグループの `shared_preload_libraries` パラメータに plrust を追加します。plrust 拡張機能をインストールすると、関数を作成できます。
`shared_preload_libraries` パラメータを変更するには、DB インスタンスをカスタムパラメータグループに関連付ける必要があります。カスタム DB パラメータグループの作成については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
plust 拡張機能は、AWS マネジメントコンソール または AWS CLI を使用してインストールできます。
以下のステップでは、DB インスタンスがカスタム DB パラメータグループに関連付けられていることを前提としています。
### コンソール
**plust 拡張機能を `shared_preload_libraries` パラメータにインストールする**
`rds_superuser` グループ (ロール) のメンバーであるアカウントを使用して、次のステップを完了します。
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**データベース** を選択します。
1. DB インスタンスの名前を選択して、その詳細を表示します。
1. DB インスタンスの **[設定]** タブを開き、DB インスタンスパラメータグループのリンクを探します。
1. リンクを選択して、DB クラスターに関連付けられたカスタムパラメータを開きます。
1. **[パラメータ]** 検索フィールドに、`shared_pre` を入力して **`shared_preload_libraries`** パラメータを検索します。
1. プロパティ値にアクセスするには、**[Edit parameters]** (パラメータの編集) を選択します。
1. **[値]** フィールドのリストに plrust を追加します。値のリスト内の項目を区切るにはカンマを使用します。
1. DB インスタンスを再起動して、`shared_preload_libraries` パラメータの変更を有効にします。最初の再起動が完了するまでにさらに時間がかかる場合があります。
1. インスタンスが使用可能になったら、plrust が初期化されていることを確認します。`psql` を使用して DB インスタンスに接続し、次のコマンドを実行します。
```
SHOW shared_preload_libraries;
```
出力は以下のようになります。
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
### AWS CLI
**shared\$1preload\$1libraries パラメータに pltrust 拡張機能をインストールする**
`rds_superuser` グループ (ロール) のメンバーであるアカウントを使用して、次のステップを完了します。
1. `shared_preload_libraries` パラメータに plrust を追加するには、[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI コマンドを使用します。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=plrust,ApplyMethod=pending-reboot" \
--region aws-region
```
1. [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) AWS CLI コマンドを使用して DB インスタンスを再起動し、plrust ライブラリを初期化します。最初の再起動が完了するまでにさらに時間がかかる場合があります。
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. インスタンスが使用可能になったら、plrust が初期化されていることを確認できます。`psql` を使用して DB インスタンスに接続し、次のコマンドを実行します。
```
SHOW shared_preload_libraries;
```
出力は以下のようになります。
```
shared_preload_libraries
--------------------------
rdsutils,plrust
(1 row)
```
## PL/Rust を使った関数の作成
PL/Rust は関数を動的ライブラリとしてコンパイルし、ロードして実行します。
次の Rust 関数は、配列から複数を除外します。
```
postgres=> CREATE LANGUAGE plrust;
CREATE EXTENSION
```
```
CREATE OR REPLACE FUNCTION filter_multiples(a BIGINT[], multiple BIGINT) RETURNS BIGINT[]
IMMUTABLE STRICT
LANGUAGE PLRUST AS
$$
Ok(Some(a.into_iter().filter(|x| x.unwrap() % multiple != 0).collect()))
$$;
WITH gen_values AS (
SELECT ARRAY(SELECT * FROM generate_series(1,100)) as arr)
SELECT filter_multiples(arr, 3)
from gen_values;
```
## PL/Rust の入ったクレートを使用する
RDS for PostgreSQL バージョン 16.3-R2 以降、15.7-R2 以降の 15 バージョン、14.12-R2 以降の 14 バージョン、および 13.15-R2 以降の 13 バージョンでは、PL/Rust は追加のクレートをサポートしています。
+ `url`
+ `regex`
+ `serde`
+ `serde_json`
RDS for PostgreSQL バージョン 15.5-R2 以降、14.10-R2 以降の 14 バージョン、および 13.13-R2 以降の 13 バージョンでは、PL/Rust は 2 つの追加のクレートをサポートしています。
+ `croaring-rs`
+ `num-bigint`
Amazon RDS for PostgreSQL バージョン 15.4、14.9、13.12 以降、PL/Rust は、次のクレートをサポートします。
+ `aes`
+ `ctr`
+ `rand`
これらのクレートではデフォルト機能のみがサポートされています。新しい RDS for PostgreSQL バージョンには、更新されたバージョンのクレートが含まれているため、古いバージョンのクレートはサポートされなくなる可能性があります。
メジャーバージョンアップグレードを行う際のベストプラクティスに従って、お使いの PL/Rust 関数が新しいメジャーバージョンと互換性があるかどうかをテストしてください。詳細については、「Amazon RDS ユーザーガイド」のブログ「[Amazon RDS を PostgreSQL のメジャーバージョンとマイナーバージョンにアップグレードするためのベストプラクティス](https://aws.amazon.com/blogs/database/best-practices-for-upgrading-amazon-rds-to-major-and-minor-versions-of-postgresql/)」と「[Amazon RDS の PostgreSQL DB エンジンのアップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html)」を参照してください。
PL/Rust 関数を作成する際の依存関係の使用例については、「[依存関係を使う](https://tcdi.github.io/plrust/use-plrust.html#use-dependencies)」を参照してください。
## PL/Rust の制限事項
デフォルトでは、データベースユーザーは PL/Rust を使用できません。PL/Rust へのアクセスを提供するには、rds\$1superuser 権限を持つユーザーとして接続し、次のコマンドを実行します。
```
postgres=> GRANT USAGE ON LANGUAGE PLRUST TO user;
```
# PostGIS 拡張機能を使用した空間データの管理
PostGIS は PostgreSQL の拡張機能であり、空間情報の保存と管理に使用します。PostGIS の詳細については、「[Postgis.net](https://postgis.net/)」を参照してください。
バージョン 10.5 以降の PostgreSQL では、PostGIS がマップボックスのベクトルタイルデータを操作するために使用する libprotobuf 1.3.0 ライブラリがサポートされています。
PostGIS 拡張機能のセットアップには、`rds_superuser` 権限が必要です。PostGIS 拡張機能と空間データを管理するためのユーザー (ロール) を作成することをお勧めします。PostGIS 拡張機能とその関連コンポーネントは PostgreSQL に数千もの関数を追加します。ユースケースに適している場合は、PostGIS エクステンションを独自のスキーマで作成することを検討してください。次の例は、拡張機能を独自のデータベースにインストールする方法を示していますが、これは必須ではありません。
**Topics**
+ [
## ステップ 1: PostGIS 拡張機能を管理するユーザー (ロール) を作成する
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [
## ステップ 2: PostGIS エクステンションを読み込む
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [
## ステップ 3: 拡張機能スキーマの所有権を移管する
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [
## ステップ 4: PostGIS テーブルの所有権を移管する
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [
## ステップ 5: エクステンションをテストする
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [
## ステップ 6: PostGIS 拡張機能を更新する
](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [PostGIS 拡張バージョン](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [PostGIS 2 から PostGIS 3 へのアップグレード](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## ステップ 1: PostGIS 拡張機能を管理するユーザー (ロール) を作成する
まず、`rds_superuser` 権限があるユーザーとして RDS for PostgreSQL DB インスタンスに接続します。インスタンスの設定時にデフォルトの名前を保持している場合は、次のように `postgres` として接続します。
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
PostGIS 拡張機能を管理する別のロール (ユーザー) を作成します。
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
このロールに `rds_superuser` 権限を付与して、ロールが拡張機能をインストールできるようにします。
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
PostGIS アーティファクトに使用するデータベースを作成します。この手順は省略可能です。または、ユーザーデータベースに PostGIS 拡張機能用のスキーマを作成することもできますが、これも必須ではありません。
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
`gis_admin` に `lab_gis` データベース上のすべての特権を付与します。
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
セッションを終了し、RDS for PostgreSQL DB インスタンスに `gis_admin` として再接続します。
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
次の手順の説明に従って、拡張機能のセットアップを続けます。
## ステップ 2: PostGIS エクステンションを読み込む
PostGIS 拡張機能には複数の関連する拡張機能があり、それらが連携することで地理空間機能を提供しています。ユースケースによっては、このステップで作成した拡張機能の一部が必要ない場合があります。
`CREATE EXTENSION` ステートメントを使用して PostGIS エクステンションをロードします。
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
次の例に示されている SQL クエリを実行すると、拡張子とその所有者がリストアップされ、結果を確認することができます。
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## ステップ 3: 拡張機能スキーマの所有権を移管する
ALTER SCHEMA ステートメント使用して、`gis_admin` ロールにスキーマの所有権を移転します。
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
次の SQL クエリを実行して、所有権の変更を確認できます。または、psql コマンドラインの `\dn` メタコマンドを使用します。
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## ステップ 4: PostGIS テーブルの所有権を移管する
**注記**
PostGIS 関数の所有権を変更しないでください。PostGIS の適切な運用と今後のアップグレードでは、これらの関数が元の所有権を保持する必要があります。PostGIS アクセス許可の詳細については、「[PostgreSQL Security](https://postgis.net/workshops/postgis-intro/security.html)」を参照してください。
次の関数を使用して、`gis_admin` ロールに PostGIS テーブルの所有権を移管します。psql プロンプトから次のステートメントを実行して関数を作成します。
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
続いて、次のクエリを実行して `exec` 関数を実行すると、ステートメントが実行されてアクセス許可が変更されます。
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## ステップ 5: エクステンションをテストする
スキーマ名の指定を不要とするには、次のコマンドを使用して検索パスに `tiger` スキーマを追加します。
```
SET search_path=public,tiger;
SET
```
次の SELECT ステートメントを使用して、`tiger` スキーマをテストします。
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
この拡張機能の詳細については、PostGIS ドキュメントの「[Tiger Geocoder](https://postgis.net/docs/Extras.html#Tiger_Geocoder)」を参照してください。
次の `topology` ステートメントを使用して `SELECT` スキーマへのアクセスをテストします。これにより、`createtopology` 関数を呼び出して、指定された空間参照識別子 (26986) とデフォルトの許容誤差 (0.5) を持つ新しいトポロジーオブジェクト (my\$1new\$1topo) を登録します。詳細については、PostGIS ドキュメントの「[CreateTopology](https://postgis.net/docs/CreateTopology.html)」を参照してください。
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## ステップ 6: PostGIS 拡張機能を更新する
PostgreSQL の新しいリリースでは、それぞれのリリースと互換性のある 1 つまたは複数のバージョンの PostGIS 拡張機能をサポートしています。PostgreSQL エンジンを新しいバージョンにアップグレードしても、PostGIS 拡張機能は自動的にアップグレードされません。PostgreSQL エンジンをアップグレードする前に、通常 PostGIS を現在の PostgreSQL バージョンで使用可能な最新バージョンにアップグレードします。詳細については、「[PostGIS 拡張バージョン](#CHAP_PostgreSQL.Extensions.PostGIS)」を参照してください。
PostgreSQL エンジンのアップグレード後、PostGIS 拡張機能を再度アップグレードして、新しくアップグレードした PostgreSQL エンジンバージョンでサポートされているバージョンにアップグレードします。PostgreSQL のアップグレードの詳細については、「 [RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)」を参照してください。
RDS for PostgreSQL DB インスタンスでは、利用可能な PostGIS 拡張機能のバージョンアップを常時確認できます。そうするには、以下のコマンドを実行します。この関数は、PostGIS 2.5.0 以降のバージョンで使用できます。
```
SELECT postGIS_extensions_upgrade();
```
アプリケーションが最新で PostGIS バージョンがサポートされていない場合でも、次のように、メジャーバージョンで使用できる古いバージョンの PostGIS をインストールできます。
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
古いバージョンから特定の PostGIS バージョンにアップグレードする場合は、次のコマンドも使用できます。
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
アップグレード前のバージョンによっては、この関数をもう一度実行する必要があります。初期に関数を実行した結果によって、追加のアップグレード関数が必要かどうかが決まります。例えば、PostGIS 2 から PostGIS 3 にアップグレードする場合がこれに該当します。(詳しくは、「[PostGIS 2 から PostGIS 3 へのアップグレード](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)」を参照してください。)
PostgreSQL エンジンのメジャーアップグレードの準備のためにこの拡張機能をアップグレードした場合は、他の準備作業を継続できます。詳細については、「[RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Process.md)」を参照してください。
## PostGIS 拡張バージョン
に記載されている PostGIS など、すべての拡張機能バージョンをインストールすることをお勧めします。「[Amazon RDS for PostgreSQL リリースノート](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html)」の *Amazon RDS for PostgreSQL の拡張バージョン*。リリースで利用可能なバージョンのリストを取得するには、次のコマンドを使用します。
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
バージョン情報は、*Amazon RDS for PostgreSQL リリースノート*の次のセクションで確認できます。
+ [Amazon RDS でサポートされる PostgreSQL バージョン 16 の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-16x)
+ [Amazon RDS でサポートされる PostgreSQL バージョン 15 の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-15x)
+ [Amazon RDS でサポートされる PostgreSQL バージョン 14 の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-14x)
+ [Amazon RDS でサポートされる PostgreSQL バージョン 13 の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-13x)
+ [Amazon RDS でサポートされる PostgreSQL バージョン 12 の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-12x)
+ [Amazon RDS でサポートされる PostgreSQL バージョン 11 の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-11x)
+ [Amazon RDS でサポートされる PostgreSQL バージョン 10 の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-101x)
+ [Amazon RDS でサポートされる PostgreSQL バージョン 9.6.x の拡張機能](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html#postgresql-extensions-96x)
## PostGIS 2 から PostGIS 3 へのアップグレード
バージョン 3.0 以降、PostGIS ラスター機能は別の `postgis_raster` という拡張機能になりました。この拡張機能には、独自のインストールとアップグレードパスがあります。これにより、ラスター画像処理に必要な多くの関数、データ型などのアーティファクトがコア `postgis` 拡張機能から削除されます。つまり、ユースケースにラスター処理が必要ない場合は、`postgis_raster` 拡張機能をインストールする必要はありません。
次のアップグレード例では、最初のアップグレードコマンドは、ラスター機能を `postgis_raster` 拡張機能に展開します。次に、`postgis_raster` を新しいバージョンにアップグレードするには 2 つ目のアップグレードコマンドが必要です。
**PostGIS 2 から PostGIS 3 にアップグレードするには**
1. お使いの の PostgreSQL バージョンで利用可能な PostGIS のデフォルトバージョンを確認します。RDS for PostgreSQL DB インスタンス。確認するために、以下のクエリを実行します。
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. 、RDS for PostgreSQL DB インスタンスの各データベースにインストールされている PostGIS のバージョンを確認します。つまり、各ユーザーデータベースを次のようにクエリします。
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
このようにデフォルトバージョン (PostGIS 3.1.4) とインストールされているバージョン (PostGIS 2.3.7) が一致しない場合は、PostGIS 拡張機能をアップグレードする必要があることになります。
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. 次のクエリを実行して、ラスター機能が独自のパッケージに組み込まれていることを確認します。
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
出力を確認すれば、バージョンの間にまだ差があることがわかります。PostGIS 関数はバージョン 3 (postgis-3) で、ラスター関数 (rtpostgis) はバージョン 2 (rtpostgis-2.3) です。アップグレードを完了するには、次のようにアップグレードコマンドを再度実行します。
```
postgres=> SELECT postgis_extensions_upgrade();
```
警告メッセージは無視しても問題ありません。次のクエリを再度実行して、アップグレードが完了していることを確認します。PostGIS と関連するすべての拡張機能に対してアップグレードが必要と表示されていなければ、アップグレードは完了です。
```
SELECT postgis_full_version();
```
1. 次のクエリを使用して、完了したアップグレードプロセスと個別にパッケージ化された拡張機能を確認し、それぞれのバージョンが一致していることを確認します。
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
出力には、PostGIS 2 拡張機能が PostGIS 3 にアップグレードされ、`postgis` と現在は分離された `postgis_raster` 拡張機能の両方がバージョン 3.1.5 であることが表示されます。
このアップグレード完了後にラスター機能を使用する予定がない場合は、次のように拡張機能を削除できます。
```
DROP EXTENSION postgis_raster;
```
# Amazon RDS for PostgreSQL でサポートされている外部データラッパーを使用する
外部データラッパー (FDW) は、外部データへのアクセスを提供する特定のタイプの拡張機能です。例えば、`oracle_fdw` 拡張機能を使用すると、 RDS for PostgreSQL DB クラスターが Oracle データベースと連動できるようになります。別の例では、PostgreSQL ネイティブの `postgres_fdw` 拡張機能を使用すると、RDS for PostgreSQL DB インスタンスの外部に置かれた PostgreSQL DB インスタンスに保存されているデータにアクセスできます。
以下で、PostgreSQL でサポートされている、いくつかの 外部データラッパーについての情報を確認できます。
**Topics**
+ [
# SQL を使用した DB ログのアクセスのための log\$1fdw 拡張機能の使用
](CHAP_PostgreSQL.Extensions.log_fdw.md)
+ [
# 外部データへのアクセスのための postgres\$1fdw 拡張機能の使用
](postgresql-commondbatasks-fdw.md)
+ [
# mysql\$1fdw 拡張機能による MySQL データベースの操作
](postgresql-mysql-fdw.md)
+ [
# oracle\$1fdw 拡張機能による Oracle データベースの操作
](postgresql-oracle-fdw.md)
+ [
# tds\$1fdw 拡張機能による SQL Server データベースの操作
](postgresql-tds-fdw.md)
# SQL を使用した DB ログのアクセスのための log\$1fdw 拡張機能の使用
RDS for PostgreSQL DB インスタンスは、SQL インターフェイスを通じてデータベースエンジンのログにアクセスする際に使用できる、`log_fdw` 拡張機能をサポートしています。`log_fdw` エクステンションは、データベースログ用の外部テーブルの作成を容易にする 2 つの関数を提供します。
+ `list_postgres_log_files` - データベースログディレクトリのファイルとファイルサイズ (バイト単位) を一覧表示します。
+ `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)` - 現在のデータベースで指定されたファイルの外部テーブルを構築します。
`log_fdw` によって作成されたすべての関数は、`rds_superuser` によって所有されます。`rds_superuser` ロールのメンバーは、これらの関数へのアクセス権限を他のデータベースユーザーに付与することができます。
デフォルトでは、ログファイルは、`log_destination` パラメータで指定されたように、Amazon RDS によって `stderr` (標準エラー) 形式で生成されます。このパラメータには、`stderr` と `csvlog` (カンマ区切り値、CSV) の 2 つのオプションしかありません。パラメータに `csvlog` オプションを追加すると、Amazon RDS は `stderr` と `csvlog` 両方のログを生成します。これは DB クラスターのストレージ容量に影響を与える可能性があるため、ログ処理に影響を与える他のパラメータに注意する必要があります。詳細については、「[ログの送信先の設定 (`stderr`、`csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format)」を参照してください。
`csvlog` ログを生成すること 1 つの利点は、`log_fdw` 拡張機能により、データが複数の列にきちんと分割された外部テーブルを構築できることです。これを行うには、インスタンスをカスタム DB パラメータグループに関連付けて、`log_destination` の設定を変更できるようにする必要があります。これを行う方法については、「[RDS for PostgreSQL DB インスタンスでのパラメータの使用](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)」を参照してください。
次の例では、`log_destination` パラメータに `cvslog` が含まれることを前提としています。
**log\$1fdw 拡張を使用するには**
1. `log_fdw` 拡張機能をインストールします。
```
postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION
```
1. 外部データラッパーとしてログサーバーを作成します。
```
postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER
```
1. ログファイルのリストからすべてを選択します。
```
postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;
```
レスポンスの例を次に示します。
```
file_name | file_size_bytes
------------------------------+-----------------
postgresql.log.2023-08-09-22.csv | 1111
postgresql.log.2023-08-09-23.csv | 1172
postgresql.log.2023-08-10-00.csv | 1744
postgresql.log.2023-08-10-01.csv | 1102
(4 rows)
```
1. 選択したファイルの、1 つの 'log\$1entry' 列でテーブルを作成します。
```
postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
'log_server', 'postgresql.log.2023-08-09-22.csv');
```
レスポンスでは、テーブルが存在しているということ以外の詳細を返しません。
```
-----------------------------------
(1 row)
```
1. ログファイルのサンプルを選択します。次のコードは、ログの時間とエラーメッセージの説明を取得します。
```
postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;
```
レスポンスの例を次に示します。
```
log_time | message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)
```
# 外部データへのアクセスのための postgres\$1fdw 拡張機能の使用
[postgres\$1fdw](https://www.postgresql.org/docs/current/static/postgres-fdw.html) 拡張を使用してリモートデータベースサーバーにあるテーブルのデータにアクセスできます。PostgreSQL DB インスタンスからリモート接続を設定すると、リードレプリカにもアクセスできます。
**postgres\$1fdw を使用してリモートデータベースサーバーにアクセスするには**
1. postgres\$1fdw 拡張をインストールします。
```
CREATE EXTENSION postgres_fdw;
```
1. CREATE SERVER を使用して外部データサーバーを作成します。
```
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
```
1. リモートサーバーで使用するロールを識別するためのユーザーマッピングを作成します。
**重要**
パスワードを編集してログに表示されないようにするには、セッションレベルで `log_statement=none` を設定します。パラメータレベルで設定しても、パスワードは編集されません。
```
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'foreign_user', password 'password');
```
1. リモートサーバーのテーブルにマッピングするテーブルを作成します。
```
CREATE FOREIGN TABLE foreign_table (
id integer NOT NULL,
data text)
SERVER foreign_server
OPTIONS (schema_name 'some_schema', table_name 'some_table');
```
# mysql\$1fdw 拡張機能による MySQL データベースの操作
RDS for PostgreSQL DB インスタンスから MySQL 互換データベースにアクセスするには、`mysql_fdw` 拡張機能をインストールしそれを使用します。この外部データラッパーを使用すると、RDS for MySQL、Aurora MySQL、MariaDB、その他の MySQL 互換データベースを操作できます。RDS for PostgreSQL DB インスタンスから MySQL データベースへの接続は、クライアントとサーバーの設定に応じて、ベストエフォートベースで暗号化されます。ただし、必要に応じて暗号化を強制できます。詳細については、「[拡張機能で転送中の暗号化を使用する](#postgresql-mysql-fdw.encryption-in-transit)」を参照してください。
`mysql_fdw` 拡張機能は、Amazon RDS for PostgreSQL バージョン 14.2、13.6 以降のリリースでサポートされています。MySQL 互換データベースインスタンス上のテーブルに対する RDS for PostgreSQL DB での選択、挿入、更新、および削除をサポートします。
**Topics**
+ [
## mysql\$1fdw 拡張機能を使用するように RDS for PostgreSQL DB をセットアップする
](#postgresql-mysql-fdw.setting-up)
+ [
## 例: RDS for PostgreSQL から RDS for MySQL データベースを操作する
](#postgresql-mysql-fdw.using-mysql_fdw)
+ [
## 拡張機能で転送中の暗号化を使用する
](#postgresql-mysql-fdw.encryption-in-transit)
## mysql\$1fdw 拡張機能を使用するように RDS for PostgreSQL DB をセットアップする
RDS for PostgreSQL DB インスタンスでの `mysql_fdw` 拡張機能のセットアップには、DB インスタンスでの拡張機能のロードと、MySQL DB インスタンスへの接続ポイントの作成が関係しています。このタスクでは、MySQL DB インスタンスに関する次の詳細が必要です。
+ ホスト名またはエンドポイント。RDS for MySQL DB インスタンスの場合、コンソールを使用してエンドポイントを見つけることができます。[接続とセキュリティ] タブを選択し、[エンドポイントとポート] セクションを確認します。
+ ポート番号。MySQL のデフォルトポート番号は 3306 です。
+ データベースの名前 DB 識別子。
また、MySQL ポート 3306 のセキュリティグループまたはアクセスコントロールリスト (ACL) へのアクセスを提供する必要があります。RDS for PostgreSQL DB インスタンスと RDS for MySQL DB インスタンスの両方がポート 3306 にアクセスする必要があります。アクセスが正しく設定されていない場合、MySQL 互換テーブルに接続しようとすると、次のようなエラーメッセージが表示されます。
```
ERROR: failed to connect to MySQL: Can't connect to MySQL server on 'hostname.aws-region.rds.amazonaws.com:3306' (110)
```
次の手順では、ユーザーが (`rds_superuser` アカウントとして) 外部サーバーを作成します。次に、外部サーバーへのアクセスを特定のユーザーに付与します。その後、これらのユーザーは、MySQL DB インスタンスを操作するための適切な MySQL ユーザーアカウントへの独自のマッピングを作成します。
**mysql\$1fdw を使用して MySQL データベースサーバーにアクセスするには**
1. `rds_superuser` ロールがあるアカウントを使用して PostgreSQL DB インスタンスを接続します。 RDS for PostgreSQL DB インスタンスの作成時にデフォルトを受け入れた場合、ユーザー名は `postgres` であり、`psql` コマンドラインツールを使用して次のように接続できます。
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres –-password
```
1. 次のように `mysql_fdw` 拡張機能をインストールします。
```
postgres=> CREATE EXTENSION mysql_fdw;
CREATE EXTENSION
```
拡張機能が RDS for PostgreSQL DB インスタンスにインストールされたら、MySQL データベースへの接続を提供する外部サーバーをセットアップします。
**外部サーバーを作成するには**
RDS for PostgreSQL DB インスタンス でこれらのタスクを実行します。このステップは、`rds_superuser`特権 (`postgres` など) があるユーザーとして接続していることを前提としています。
1. RDS for PostgreSQL DB インスタンスで外部サーバーを作成します。
```
postgres=> CREATE SERVER mysql-db FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'db-name.111122223333.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. 適切なユーザーに外部サーバーへのアクセスを付与します。これらは、管理者以外のユーザー、つまり、`rds_superuser` ロールのないユーザーである必要があります。
```
postgres=> GRANT USAGE ON FOREIGN SERVER mysql-db to user1;
GRANT
```
PostgreSQL ユーザーは、外部サーバーを介して MySQL データベースへの独自の接続を作成し、管理します。
## 例: RDS for PostgreSQL から RDS for MySQL データベースを操作する
RDS for PostgreSQL DB インスタンスにシンプルなテーブルがあると仮定します。RDS for PostgreSQL ユーザーが、そのテーブルで (`SELECT`)、`INSERT`、`UPDATE`、`DELETE` の項目をクエリしたいと思っています。`mysql_fdw` 拡張機能は、前の手順で詳述されているように、RDS for PostgreSQL DB インスタンスで作成された、と仮定します。`rds_superuser` 権限のあるユーザーとして RDS for PostgreSQL DB インスタンスに接続した後、次の手順に進むことができます。
1. RDS for PostgreSQL DB インスタンスで外部サーバーを作成します。
```
test=> CREATE SERVER mysqldb FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'your-DB.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. `rds_superuser` の許可を持たないユーザーに、(例えば `user1` として) 使用を許可します。
```
test=> GRANT USAGE ON FOREIGN SERVER mysqldb TO user1;
GRANT
```
1. *user1* として接続し、MySQL ユーザーへのマッピングを作成します。
```
test=> CREATE USER MAPPING FOR user1 SERVER mysqldb OPTIONS (username 'myuser', password 'mypassword');
CREATE USER MAPPING
```
1. MySQL テーブルにリンクされた外部テーブルを作成します。
```
test=> CREATE FOREIGN TABLE mytab (a int, b text) SERVER mysqldb OPTIONS (dbname 'test', table_name '');
CREATE FOREIGN TABLE
```
1. 外部テーブルに対して単純なクエリを実行します。
```
test=> SELECT * FROM mytab;
a | b
---+-------
1 | apple
(1 row)
```
1. MySQL テーブルでのデータの追加、変更、削除を行うことができます。例:
```
test=> INSERT INTO mytab values (2, 'mango');
INSERT 0 1
```
`SELECT` クエリをもう一度実行して、結果を確認します。
```
test=> SELECT * FROM mytab ORDER BY 1;
a | b
---+-------
1 | apple
2 | mango
(2 rows)
```
## 拡張機能で転送中の暗号化を使用する
RDS for PostgreSQL から MySQL への接続は、デフォルトで転送中の暗号化 (TLS/SSL) を使用します。ただし、クライアントとサーバーの設定が異なる場合、接続は暗号化されていない状態に戻ります。RDS for MySQL ユーザアカウントの `REQUIRE SSL` オプションを指定して、すべての発信接続に対して暗号化を適用できます。この同じアプローチは MariaDB および Aurora MySQL ユーザーアカウントでも機能します。
`REQUIRE SSL` に構成された MySQL ユーザーアカウントの場合、安全な接続を確立できないと接続の試行は失敗します。
既存の MySQL データベースユーザーアカウントの暗号化を強制するには、`ALTER USER` コマンドを使用できます。次の表に示すとおり、構文は MySQL のバージョンによって異なります。詳細については、*MySQL リファレンスマニュアル*の [ALTER USER](https://dev.mysql.com/doc/refman/8.0/en/alter-user.html) を参照してください。
| MySQL 5.7、MySQL 8.0 | MySQL 5.6 |
| --- | --- |
| `ALTER USER 'user'@'%' REQUIRE SSL;` | `GRANT USAGE ON *.* to 'user'@'%' REQUIRE SSL;` |
`mysql_fdw` 拡張機能の詳細については、[mysql\$1fdw](https://github.com/EnterpriseDB/mysql_fdw) ドキュメントをご覧ください。
# oracle\$1fdw 拡張機能による Oracle データベースの操作
RDS for PostgreSQL DB インスタンス から Oracle データベースにアクセスするには、`oracle_fdw` 拡張機能をインストールして、使用します。この拡張機能は、Oracle データベース用の外部データラッパーです。この拡張機能の詳細については、[oracle\$1fdw](https://github.com/laurenz/oracle_fdw) のドキュメントを参照してください。
`oracle_fdw` 拡張機能は、RDS for PostgreSQL のバージョン 12.7、13.3 以上のバージョンでサポートされています。
**Topics**
+ [
## oracle\$1fdw 拡張機能の有効化
](#postgresql-oracle-fdw.enabling)
+ [
## 例: Amazon RDS for Oracle Database にリンクされた外部サーバーの使用
](#postgresql-oracle-fdw.example)
+ [
## 転送時の暗号化の使用
](#postgresql-oracle-fdw.encryption)
+ [
## pg\$1user\$1mappings のビューおよび許可を理解する
](#postgresql-oracle-fdw.permissions)
## oracle\$1fdw 拡張機能の有効化
oracle\$1fdw 拡張機能を使用するには、以下の手順を実行します。
**oracle\$1fdw 拡張機能を有効化するには**
+ `rds_superuser` のアクセス許可を持つアカウントを使用して、次のコマンドを実行します。
```
CREATE EXTENSION oracle_fdw;
```
## 例: Amazon RDS for Oracle Database にリンクされた外部サーバーの使用
以下は、Amazon RDS for Oracle のデータベースにリンクされた外部サーバーの使用例です。
**RDS for Oracle データベースにリンクされた外部サーバーを作成するには**
1. RDS for Oracle DB インスタンスの以下の点を書き留めます。
+ エンドポイント
+ ポート
+ データベース名
1. 外部サーバーを作成します。
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. `rds_superuser` の権限を持たないユーザーに、(例えば `user1` として) 使用を許可します。
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. `user1` として接続し、Oracle ユーザーへのマッピングを作成します。
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Oracle テーブルにリンクされた外部テーブルを作成します。
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. 外部テーブルに対しクエリを実行します。
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
クエリで次のエラーが報告された場合は、セキュリティグループとアクセスコントロールリストをチェックして、両方のインスタンス間で通信が可能なことを確認します。
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## 転送時の暗号化の使用
PostgreSQL から Oracle への転送時における暗号化は、クライアントとサーバーの設定パラメータの組み合わせに基づき構成されます。Oracle 21c の使用例については、Oracle ドキュメントの「[About the Values for Negotiating Encryption and Integrity](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5)」を参照してください。Amazon RDS で oracle\$1fdw 用に使用されるクライアントは、`ACCEPTED` に設定されています。つまり、暗号化は Oracle データベースサーバーの設定に依存しており、暗号化には Oracle Security Library (libnnz) が使用されます。
データベースが RDS for Oracle 上にある場合の暗号化の設定については、「[Oracle ネイティブネットワーク暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html)」を参照してください。
## pg\$1user\$1mappings のビューおよび許可を理解する
PostgreSQL カタログ `pg_user_mapping` は、RDS for PostgreSQL ユーザーからのマッピングを外部データ (リモート) サーバー上のユーザーに保存します。カタログへのアクセスは制限されていますが、`pg_user_mappings` ビューをクリックすると、マッピングが表示されます。以下に、Oracle データベースの例で許可がどのように適用されるかを示す例がありますが、この情報は一般的に外部データラッパーに適用されます。
次の出力では、ロールとアクセス許可が、3 つの異なるサンプルユーザーにマップされていることが示されています。ここで、ユーザー `rdssu1` と `rdssu2` は `rds_superuser` ロールのメンバーであり、`user1` はメンバーではありません。この例では、`psql` メタコマンド `\du` を使用して、既存のロールを一覧表示します。
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
すべてのユーザー (`rds_superuser` 権限を持っているユーザーを含む) は、`pg_user_mappings` テーブルで独自のユーザーマッピング (`umoptions`) を表示することが許可されています。次の例に示すように、`rdssu1` がすべてのユーザーマッピングを取得しようとすると、`rdssu1``rds_superuser` 権限があっても、次のエラーが発生します。
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
次に例をいくつか示します。
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
`information_schema._pg_user_mappings` と `pg_catalog.pg_user_mappings` の間に実装上の違いがあるため、手動で作成された `rds_superuser` が `pg_catalog.pg_user_mappings` 内のパスワードを表示する場合には、追加のアクセス許可が必要となります。
`rds_superuser` が `information_schema._pg_user_mappings` 内のパスワードを表示する際には、追加のアクセス許可は必要ありません。
`rds_superuser` ロールを持たないユーザーの場合、以下の条件の下でのみ、`pg_user_mappings` 内のパスワードを表示できます。
+ 現在のユーザーはマップされているユーザーであり、サーバーの所有者であるか、そのサーバーに対する `USAGE` 権限を保持しています。
+ 現在のユーザーはサーバーの所有者であり、マッピングは `PUBLIC` となっています。
# tds\$1fdw 拡張機能による SQL Server データベースの操作
PostgreSQL `tds_fdw` 拡張機能を使用して、Sybase や Microsoft SQL Server データベースなど、表形式データストリーム (TDS) プロトコルをサポートするデータベースにアクセスできます。この外部データラッパーを使用すると、RDS for PostgreSQL DB インスタンス を、Amazon RDS for Microsoft SQL Server を含む、TDS プロトコルを使用するデータベースに接続できます。詳細については、GitHub にある [tds-fdw/tds\$1fdw](https://github.com/tds-fdw/tds_fdw) に関するドキュメントを参照してください。
`tds_fdw` 拡張機能は、Amazon RDS for PostgreSQL のバージョン 14.2、13.6、およびそれ以降のリリースでサポートされています。
## tds\$1fdw 拡張機能を使用するように Aurora PostgreSQL DB をセットアップする
次の手順では、`tds_fdw` をセットアップして、RDS for PostgreSQL DB インスタンスと使用する例を示します。`tds_fdw` を使用して SQL Server データベースに接続する前に、インスタンスの次の詳細を取得する必要があります。
+ ホスト名またはエンドポイント。RDS for SQL Server DB インスタンスの場合、コンソールを使用してエンドポイントを見つけることができます。[Connectivity & security] (接続とセキュリティ) タブを選択し、[Endpoint and port] (エンドポイントとポート) セクションを確認します。
+ ポート番号。Microsoft SQL Server のデフォルトポート番号は 1433 です。
+ データベースの名前 DB 識別子。
また、SQL Server ポート、1433 のセキュリティグループまたはアクセスコントロールリスト (ACL) でのアクセスを提供する必要があります。RDS for PostgreSQL DB インスタンスと RDS for SQL Server DB インスタンスの両方が、ポート 1433 にアクセスする必要があります。アクセスが正しく設定されていない場合、Microsoft SQL Server をクエリしようとすると、次のエラーメッセージが表示されます。
```
ERROR: DB-Library error: DB #: 20009, DB Msg: Unable to connect:
Adaptive Server is unavailable or does not exist (mssql2019.aws-region.rds.amazonaws.com), OS #: 0, OS Msg: Success, Level: 9
```
**tds\$1fdw を使用して SQL Server データベースに接続するには**
1. `rds_superuser` ロールがあるアカウントを使用して、PostgreSQL DB インスタンスに接続します。
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=test –-password
```
1. `tds_fdw` 拡張機能をインストールします。
```
test=> CREATE EXTENSION tds_fdw;
CREATE EXTENSION
```
RDS for PostgreSQL DB インスタンスに拡張機能をインストールした後、外部サーバーをセットアップします。
**外部サーバーを作成するには**
`rds_superuser` 権限があるアカウントを使用する RDS for PostgreSQL DB インスタンスで次のタスクを実行します。
1. RDS for PostgreSQL DB インスタンスで外部サーバーを作成します。
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing');
CREATE SERVER
```
SQLServer 側で非 ASCII データにアクセスするには、RDS for PostgreSQL DB インスタンスの character\$1set オプションを使用してサーバーリンクを作成します。
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing', character_set 'UTF-8');
CREATE SERVER
```
1. `rds_superuser` ロール権限を持たないユーザーに、(例えば `user1` として) 許可を付与します。
```
test=> GRANT USAGE ON FOREIGN SERVER sqlserverdb TO user1;
```
1. user1 として接続し、SQL Server ユーザーへのマッピングを作成します。
```
test=> CREATE USER MAPPING FOR user1 SERVER sqlserverdb OPTIONS (username 'sqlserveruser', password 'password');
CREATE USER MAPPING
```
1. SQL Server テーブルにリンクされた外部テーブルを作成します。
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER sqlserverdb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. 外部テーブルに対しクエリを実行します。
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
### 接続に転送中の暗号化を使用する
RDS for PostgreSQL から SQL Server への接続には、SQL Server のデータベース設定に応じて、転送中の暗号化 (TLS/SSL) を使用します。SQL Server が暗号化用に設定されていない場合、SQL Server データベースへの要求を行う RDS for PostgreSQL クライアントは、暗号化されていない状態に戻ります。
`rds.force_ssl` パラメータを設定して、RDS for SQL Server DB インスタンスへの接続に暗号化を強制できます。この方法については、「[DB インスタンスへの接続に SSL を使用させる](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html#SQLServer.Concepts.General.SSL.Forcing)」を参照してください。RDS for SQL Server での SSL/TLS 設定の詳細については、「[Microsoft SQL Server DB インスタンスでの SSL の使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html)」を参照してください。
# Trusted Language Extensions for PostgreSQL を使用した操作
Trusted Language Extensions for PostgreSQL は PostgreSQL 拡張機能を構築するためのオープンソース開発キットです。これにより、高性能の PostgreSQL 拡張機能を構築し、それらを RDS for PostgreSQL DB インスタンス。PostgreSQL の Trusted Language Extensions (TLE) を使用することで、PostgreSQL の機能を拡張する文書化されたアプローチに従った PostgreSQL 拡張機能を作成できます。詳細については、PostgreSQL ドキュメントの「[エクステンションへの関連オブジェクトのパッケージ化](https://www.postgresql.org/docs/current/extend-extensions.html)」を参照してください。
TLE の主な利点の 1 つは、PostgreSQL インスタンスの基盤となるファイルシステムへのアクセスを提供しない環境で使用できることです。以前は、新しい拡張機能をインストールするにはファイルシステムへのアクセスが必要でした。TLE ではこの制約がありません。で実行されているものを含め、あらゆる PostgreSQL データベース用の新しい拡張機能を作成するための開発環境を提供します。RDS for PostgreSQL DB インスタンス
TLE は、TLE を使用して作成する拡張機能の危険なリソースへのアクセスを防ぐように設計されています。そのランタイム環境では、拡張機能の不具合による影響は 1 つのデータベース接続に限定されます。また、TLE では、データベース管理者が拡張機能をインストールできるユーザーをきめ細かく制御でき、拡張機能を実行するためのアクセス許可モデルも用意されています。
TLE は、以下の RDS for PostgreSQL バージョンでサポートされています。
+ バージョン 18.1 以降のバージョン 18
+ バージョン 17.1 以降のバージョン 17
+ バージョン 16.1 以降のバージョン 16
+ バージョン 15.2 以降のバージョン 15
+ バージョン 14.5 以降のバージョン 14
+ バージョン 13.12 以降のバージョン 13
Trusted Language Extensions の開発環境とランタイムは、`pg_tle` PostgreSQL 拡張機能のバージョン 1.0.1 としてパッケージ化されています。JavaScript、Perl、PL/pgSQL、および SQL での拡張機能の作成をサポートしています。他の PostgreSQL 拡張機能をインストールするのと同じ方法で、 RDS for PostgreSQL DB インスタンスに `pg_tle` 拡張機能をインストールします。`pg_tle` をセットアップすると、開発者はこれを使用して *TLE 拡張機能*と呼ばれる新しい PostgreSQL 拡張機能を作成できます。
次のトピックでは、Trusted Language Extensions をセットアップする方法と、独自の TLE 拡張機能の作成を開始する方法について説明します。
**Topics**
+ [
# 用語
](PostgreSQL_trusted_language_extension-terminology.md)
+ [
# Trusted Language Extensions for PostgreSQL を使用するための要件
](PostgreSQL_trusted_language_extension-requirements.md)
+ [
# RDS for PostgreSQL DB インスタンスに Trusted Language Extensions を設定する
](PostgreSQL_trusted_language_extension-setting-up.md)
+ [
# Trusted Language Extensions for PostgreSQL の概要
](PostgreSQL_trusted_language_extension.overview.md)
+ [
# RDS for PostgreSQL の TLE 拡張機能の作成
](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md)
+ [
# TLE 拡張機能をデータベースから削除する
](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md)
+ [
# Trusted Language Extensions for PostgreSQL のアンインストール
](PostgreSQL_trusted_language_extension-uninstalling-pg_tle-devkit.md)
+ [
# TLE 拡張機能で PostgreSQL フックを使用する
](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)
+ [
# TLE でのカスタムデータ型の使用
](PostgreSQL_trusted_language_extension-custom-data-type.md)
+ [
# Trusted Language Extensions for PostgreSQL の関数リファレンス
](PostgreSQL_trusted_language_extension-functions-reference.md)
+ [
# Trusted Language Extensions for PostgreSQL のフックリファレンス
](PostgreSQL_trusted_language_extension-hooks-reference.md)
# 用語
Trusted Language Extensions の理解を深めるために、このトピックで使用されている用語については、次の用語集を参照してください。
**Trusted Language Extensions for PostgreSQL**
*Trusted Language Extensions for PostgreSQL* は、`pg_tle` 拡張機能としてパッケージされているオープンソース開発キットの正式名称です。これは、どの PostgreSQL システムでも使用できます。詳細については、GitHub の「[aws/pg\$1tle](https://github.com/aws/pg_tle)」を参照してください。
**Trusted Language Extensions**
*Trusted Language Extensions* は、Trusted Language Extensions for PostgreSQL の省略名です。このドキュメントでは、この短縮名とその略称 (TLE) も使用されています。
**信頼できる言語**
*信頼できる言語*とは、特定のセキュリティ属性を持つプログラミング言語またはスクリプト言語です。例えば、信頼できる言語は通常、ファイルシステムへのアクセスを制限し、指定されたネットワークプロパティの使用を制限します。TLE 開発キットは、信頼できる言語をサポートするように設計されています。PostgreSQL は、信頼できる、または信頼できない拡張機能を作成するために使用される複数の異なる言語をサポートしています。例については、PostgreSQL ドキュメントの「[信頼できる PL/Perl と信頼できない PL/Perl](https://www.postgresql.org/docs/current/plperl-trusted.html)」を参照してください。Trusted Language Extensions を使用して拡張機能を作成すると、その拡張機能は本質的に信頼できる言語メカニズムを使用します。
**TLE 拡張機能**
*TLE 拡張機能*は、Trusted Language Extensions (TLE) 開発キットを使用して作成された PostgreSQL 拡張機能です。
# Trusted Language Extensions for PostgreSQL を使用するための要件
TLE 開発キットをセットアップして使用するための要件は次のとおりです。
+ ** RDS for PostgreSQL バージョン** – Trusted Language Extensions は、 RDS for PostgreSQL バージョン 13.12 以降の 13 バージョン、14.5 以降の 14 バージョン、15.2 以降のバージョンでのみサポートされています。
+ RDS for PostgreSQL インスタンスをアップグレードする必要がある場合は、「」「[RDS for PostgreSQL DB エンジンのアップグレード](USER_UpgradeDBInstance.PostgreSQL.md)」を参照してください。
+ PostgreSQL を実行している Amazon RDS DB インスタンスをまだ持っていない場合は作成できます。詳細については、「」を参照してください。RDS for PostgreSQL DB インスタンスについては、「[PostgreSQL DB インスタンスを作成して接続する](CHAP_GettingStarted.CreatingConnecting.PostgreSQL.md)」を参照してください。
+ **`rds_superuser` 権限が必要です** - `pg_tle` 拡張機能をセットアップおよび設定するには、データベースユーザーロールに `rds_superuser` ロールのアクセス許可が必要です。デフォルトでは、このロールは を作成する `postgres` ユーザーに付与されます。RDS for PostgreSQL DB インスタンス。
+ **カスタム DB パラメータグループが必要です** – RDS for PostgreSQL DB インスタンス には、カスタム DB パラメータグループを設定する必要があります。
+ RDS for PostgreSQL DB インスタンスがカスタム DB パラメータグループで構成されていない場合は、カスタム DB パラメータグループを作成して に関連付ける必要があります。RDS for PostgreSQL DB インスタンス。ステップの簡単な概要については、「[カスタム DB パラメータグループの作成と適用](#PostgreSQL_trusted_language_extension-requirements-create-custom-params)」を参照してください。
+ RDS for PostgreSQL DB インスタンスが、カスタム DB パラメータグループを使用して既に設定されている場合は、Trusted Language Extensions をセットアップできます。詳細については、「[ RDS for PostgreSQL DB インスタンスに Trusted Language Extensions を設定する](PostgreSQL_trusted_language_extension-setting-up.md)」を参照してください。
## カスタム DB パラメータグループの作成と適用
以下のステップを使用してカスタム DB パラメータグループを作成し、それを使用するように RDS for PostgreSQL DB インスタンスを設定します。
### コンソール
**カスタム DB パラメータグループを作成して、 RDS for PostgreSQL DB インスタンスで使用するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS メニューから [Parameter groups] (パラメータグループ) を選択します。
1. **[パラメータグループの作成]** を選択します。
1. **[Parameter group details]** (パラメータグループの詳細) ページで、次の情報を入力します。
+ **[Parameter group family]** (パラメータグループファミリー) で、[postgres14.] を選択します
+ **[Type]** (タイプ) で、[DB Parameter Group] (DB パラメータグループ) を選択します。
+ **[Group name]** (グループ名) には、パラメータグループに操作の内容に合ったわかりやすい名前を付けます。
+ **[Description]** (説明) には、チームの他のメンバーが簡単に見つけられるように、わかりやすい説明を入力します。
1. **[作成]** を選択します。カスタム DB パラメータグループは AWS リージョン で作成されます。次のステップに従って、 RDS for PostgreSQL DB インスタンスを使用するように変更できるようになりました。
1. Amazon RDS メニューから **[Databases]** (データベース) を選択します。
1. 一覧から TLE で使用する RDS for PostgreSQL DB インスタンスを選択し、**[Modify]** (変更) を選択します。
1. DB インスタンス設定の変更ページで、追加設定セクションで **[データベースオプション]** (データベースオプション) を選択し、セレクターからカスタム DB パラメータグループを選択します。
1. **[Continue]** (続行) を選択して、変更を保存します。
1. **[Apply immediately]** (すぐに適用) を選択すると、引き続き RDS for PostgreSQL DB インスタンスを TLE を使用するようにセットアップできます。
Trusted Language Extensions のシステム設定を継続するには、「[ RDS for PostgreSQL DB インスタンスに Trusted Language Extensions を設定する](PostgreSQL_trusted_language_extension-setting-up.md)」を参照してください。
DB パラメータグループについては、「[Amazon RDS DB インスタンスの DB パラメータグループ](USER_WorkingWithDBInstanceParamGroups.md)」を参照してください。
### AWS CLI
AWS CLI をデフォルト AWS リージョン に設定することで、CLI コマンドを使用するときに `--region` 引数を指定しなくても済みます。詳細については、*AWS Command Line Interface ユーザーガイド*の「[設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。
**カスタム DB パラメータグループを作成して、 RDS for PostgreSQL DB インスタンスで使用するには**
1. [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI コマンドを使用して、AWS リージョン の postgres14 をベースにしたカスタム DB パラメータグループを作成してください。
Linux、macOS、Unix の場合:
```
aws rds create-db-parameter-group \
--region aws-region \
--db-parameter-group-name custom-params-for-pg-tle \
--db-parameter-group-family postgres14 \
--description "My custom DB parameter group for Trusted Language Extensions"
```
Windows の場合:
```
aws rds create-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name custom-params-for-pg-tle ^
--db-parameter-group-family postgres14 ^
--description "My custom DB parameter group for Trusted Language Extensions"
```
AWS リージョン でカスタム DB パラメータグループを使用できるため、 RDS for PostgreSQL DB インスタンスのライターインスタンスを変更してそれを使用できます。
1. [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI コマンドを使用して、カスタム DB パラメータグループを RDS for PostgreSQL DB インスタンス。このコマンドは、アクティブなインスタンスを直ちに再起動します。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--region aws-region \
--db-instance-identifier your-instance-name \
--db-parameter-group-name custom-params-for-pg-tle \
--apply-immediately
```
Windows の場合:
```
aws rds modify-db-instance ^
--region aws-region ^
--db-instance-identifier your-instance-name ^
--db-parameter-group-name custom-params-for-pg-tle ^
--apply-immediately
```
Trusted Language Extensions のシステム設定を継続するには、「[ RDS for PostgreSQL DB インスタンスに Trusted Language Extensions を設定する](PostgreSQL_trusted_language_extension-setting-up.md)」を参照してください。
詳細については、「[Amazon RDS のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
# RDS for PostgreSQL DB インスタンスに Trusted Language Extensions を設定する
以下のステップでは、 RDS for PostgreSQL DB インスタンスがカスタム DB パラメータグループに関連付けられていることを前提としています。これらの手順には、AWS マネジメントコンソール または AWS CLI を使用できます。
RDS for PostgreSQL DB インスタンスで信頼できる Trusted Language Extensions をセットアップする場合、そのデータベースに対するアクセス許可を持つデータベースユーザーが使用できるように、特定のデータベースにインストールします。
## コンソール
**Trusted Language Extensions をセットアップするには**
`rds_superuser` グループ (ロール) のメンバーであるアカウントを使用して、次のステップを実行します。
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. ナビゲーションペインで、 RDS for PostgreSQL DB インスタンスを選択します。
1. の **[Configuration]** (設定) タブを開きます。RDS for PostgreSQL DB インスタンス。インスタンスの詳細の中から、**パラメータグループ**のリンクを見つけてください。
1. リンクを選択して、に関連するカスタムパラメータを開きます。RDS for PostgreSQL DB インスタンス。
1. **パラメータ**検索フィールドに、`shared_pre` を入力して `shared_preload_libraries` パラメータを検索します。
1. プロパティ値にアクセスするには、**[Edit parameters]** (パラメータの編集) を選択します。
1. **[Values]** (値) フィールドのリストに `pg_tle` を追加します。値のリスト内の項目を区切るにはカンマを使用します。
![\[pg_tle が追加された shared_preload_libraries パラメータの画像。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/apg_rpg_shared_preload_pg_tle.png)
1. RDS for PostgreSQL DB instance を再起動して、`shared_preload_libraries` パラメータの変更を有効にします。
1. インスタンスが使用可能になったら、`pg_tle` が初期化されていることを確認します。`psql` を使用して RDS for PostgreSQL DB インスタンスに接続し、次のコマンドを実行します。
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
1. `pg_tle` 拡張子を初期化すると、拡張機能を作成できるようになりました。
```
CREATE EXTENSION pg_tle;
```
以下の `psql` メタコマンドを使用して、拡張機能がインストールされていることを確認できます。
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
```
1. RDS for PostgreSQL DB インスタンスのセットアップ時に作成したプライマリユーザー名に `pgtle_admin` ロールを付与します。デフォルトを受け入れた場合は、`postgres` です。
```
labdb=> GRANT pgtle_admin TO postgres;
GRANT ROLE
```
次の例に示すように、`psql` メタコマンドを使用して、付与されたことを確認できます。出力には `pgtle_admin` と `postgres` ロールのみが表示されます。詳細については、「[rds\$1superuser ロールを理解する](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)」を参照してください。
```
labdb=> \du
List of roles
Role name | Attributes | Member of
-----------------+---------------------------------+-----------------------------------
pgtle_admin | Cannot login | {}
postgres | Create role, Create DB +| {rds_superuser,pgtle_admin}
| Password valid until infinity |...
```
1. `\q` メタコマンドを使用して `psql` セッションを終了します。
```
\q
```
TLE 拡張機能の作成を開始するには、「[例: SQL を使用した信頼できる言語拡張関数の作成](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example)」を参照してください。
## AWS CLI
AWS CLI をデフォルト AWS リージョン に設定することで、CLI コマンドを使用するときに `--region` 引数を指定しなくても済みます。詳細については、*AWS Command Line Interface ユーザーガイド*の「[設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。
**Trusted Language Extensions をセットアップするには**
1. `shared_preload_libraries` パラメータに `pg_tle` を追加するには、[modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI コマンドを使用します。
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pg_tle,ApplyMethod=pending-reboot" \
--region aws-region
```
1. [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) AWS CLI コマンドを使用して、を再起動し、`pg_tle` ライブラリを初期化します。
```
aws rds reboot-db-instance \
--db-instance-identifier your-instance \
--region aws-region
```
1. インスタンスが使用可能になると、`pg_tle` が初期化されていることを確認できます。`psql` を使用して RDS for PostgreSQL DB インスタンスに接続し、次のコマンドを実行します。
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
`pg_tle` を初期化すると、拡張機能を作成できるようになりました。
```
CREATE EXTENSION pg_tle;
```
1. RDS for PostgreSQL DB インスタンスのセットアップ時に作成したプライマリユーザー名に `pgtle_admin` ロールを付与します。デフォルトを受け入れた場合は、`postgres` です。
```
GRANT pgtle_admin TO postgres;
GRANT ROLE
```
1. 以下のように `psql` セッションを終了します。
```
labdb=> \q
```
TLE 拡張機能の作成を開始するには、「[例: SQL を使用した信頼できる言語拡張関数の作成](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example)」を参照してください。
# Trusted Language Extensions for PostgreSQL の概要
Trusted Language Extensions for PostgreSQL は PostgreSQL 拡張機能で、他の PostgreSQL 拡張機能をセットアップするのと同じ方法で RDS for PostgreSQL DB インスタンスにインストールします。pgAdmin クライアントツールのサンプルデータベースの次の画像では、`pg_tle` 拡張機能を構成するコンポーネントの一部を確認できます。
![\[TLE 開発キットを占めるコンポーネントの一部を示す画像\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/apg-pg_tle-installed-view-in-pgAdmin.png)
以下の詳細を表示できます。
1. Trusted Language Extensions (TLE) for PostgreSQL 開発キットは `pg_tle` 拡張機能としてパッケージ化されています。そのため、`pg_tle` がインストールされているデータベースで使用可能な拡張機能にそれが追加されます。
1. TLE には独自のスキーマ、`pgtle` があります。このスキーマには、作成した拡張機能をインストールおよび管理するためのヘルパー関数 (3) が含まれています。
1. TLE には、拡張機能のインストール、登録、管理のためのヘルパー関数が十数種類用意されています。これらの関数の詳細については、「[Trusted Language Extensions for PostgreSQL の関数リファレンス](PostgreSQL_trusted_language_extension-functions-reference.md)」を参照してください。
`pg_tle` 拡張機能のその他のコンポーネントには、以下のものが含まれています。
+ **`pgtle_admin` ロール** – `pgtle_admin` ロールは、`pg_tle` 拡張機能のインストール時に作成されます。この役職には特権があり、そのように扱われる必要があります。データベースユーザーに `pgtle_admin` ロールを付与する場合は、*最小特権の原則*に従うことを強くお勧めします。つまり、`postgres` のような新しい TLE 拡張機能の作成、インストール、管理が許可されているデータベースユーザーにのみ `pgtle_admin` ロールを付与します。
+ **`pgtle.feature_info` テーブル** – `pgtle.feature_info` テーブルは保護されたテーブルで、TLE、フック、およびそれらが使用するカスタムストアドプロシージャと関数に関する情報が含まれています。`pgtle_admin`権限がある場合は、以下の Trusted Language Extensions の関数を使用して、テーブル内の情報を追加および更新します。
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
# RDS for PostgreSQL の TLE 拡張機能の作成
TLE を使用して作成した拡張機能は、`pg_tle` 拡張機能がインストールされている任意の RDS for PostgreSQL DB インスタンスにインストールできます。`pg_tle` 拡張機能のスコープは、インストールされている PostgreSQL データベースに限定されます。TLE を使用して作成した拡張機能は、同じデータベースを対象としています。
さまざまな `pgtle` 関数を使用して、TLE 拡張機能を構成するコードをインストールします。以下の Trusted Language Extensions 関数には `pgtle_admin` すべてロールが必要です。
+ [pgtle.install\$1extension](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path)
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(name)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension(name, version)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
## 例: SQL を使用した信頼できる言語拡張関数の作成
次の例は、さまざまな式を使用して距離を計算するためのいくつかの SQL 関数を含む `pg_distance` という名前の TLE 拡張機能を作成する方法を示しています。リストには、マンハッタン距離を計算する関数とユークリッド距離を計算する関数があります。これらの式の違いの詳細については、Wikipedia の「[Taxicab geometry](https://en.wikipedia.org/wiki/Taxicab_geometry)」と「[Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry)」を参照してください。
[ RDS for PostgreSQL DB インスタンスに Trusted Language Extensions を設定する](PostgreSQL_trusted_language_extension-setting-up.md) で説明されているように `pg_tle` 拡張機能をセットアップしていれば、この例を独自の RDS for PostgreSQL DB インスタンスで使用できます。
**注記**
この手順を実行するには、`pgtle_admin` ロールの権限が必要です。
**サンプルの TLE 拡張機能を作成するには**
以下の手順では、`labdb` という名前のサンプルデータベースを使用します。このデータベースは `postgres` プライマリユーザーが所有しています。`postgres` ロールには、`pgtle_admin` ロールのアクセス許可もあります。
1. `psql` を使用して、に接続します。RDS for PostgreSQL DB インスタンス。
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. 次のコードをコピーして `psql` セッションコンソールに貼り付けて、`pg_distance` という名前の TLE 拡張機能を作成します。
```
SELECT pgtle.install_extension
(
'pg_distance',
'0.1',
'Distance functions for two points',
$_pg_tle_$
CREATE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL;
CREATE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL;
CREATE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL;
$_pg_tle_$
);
```
次のような出力が表示されます。
```
install_extension
---------------
t
(1 row)
```
これで、`pg_distance` 拡張機能を構成するアーティファクトがデータベースにインストールされました。これらのアーティファクトには、コントロールファイルと拡張機能のコードが含まれます。これらは、`CREATE EXTENSION` コマンドを使用して拡張機能を作成するために必要となる項目です。つまり、データベースユーザーがその関数を利用できるようにするには、やはり拡張機能を作成する必要があります。
1. 拡張機能を作成するには、他の拡張機能と同じように `CREATE EXTENSION` コマンドを使用します。他の拡張機能と同様に、データベースユーザーにはデータベース内の `CREATE` アクセス許可が必要です。
```
CREATE EXTENSION pg_distance;
```
1. `pg_distance` TLE 拡張機能をテストするには、これを使用して 4 点間の[マンハッタン距離](https://en.wikipedia.org/wiki/Taxicab_geometry)を計算できます。
```
labdb=> SELECT manhattan_dist(1, 1, 5, 5);
8
```
同じ点群間の[ユークリッド距離](https://en.wikipedia.org/wiki/Euclidean_geometry)を計算するには、以下を使用できます。
```
labdb=> SELECT euclidean_dist(1, 1, 5, 5);
5.656854249492381
```
`pg_distance` 拡張機能は関数をデータベースに読み込み、データベースに対するアクセス許可を持つすべてのユーザーがその関数を利用できるようにします。
## TLE 拡張機能の変更
この TLE 拡張機能にパッケージされている関数のクエリパフォーマンスを向上させるには、次の 2 つの PostgreSQL 属性を仕様に追加してください。
+ `IMMUTABLE` – `IMMUTABLE` 属性により、クエリオプティマイザが最適化を使用してクエリの応答時間を改善できるようになります。詳細については、PostgreSQL ドキュメントの「[関数のボラティリティカテゴリ](https://www.postgresql.org/docs/current/xfunc-volatility.html)」を参照してください。
+ `PARALLEL SAFE` – `PARALLEL SAFE`属性は、PostgreSQL が関数をパラレルモードで実行できるようにするもう 1 つの属性です。詳細については、PostgreSQL のドキュメントの「[機能の作成](https://www.postgresql.org/docs/current/sql-createfunction.html)」を参照してください。
次の例では、`pgtle.install_update_path` 関数を使用してこれらの属性を各関数に追加し、`pg_distance` TLE 拡張機能のバージョン `0.2` を作成する方法を確認できます。この関数の詳細については、「[pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path)」を参照してください。このタスクを実行するには、`pgtle_admin` ロールが必要です。
**既存の TLE 拡張機能を更新してデフォルトバージョンを指定するには**
1. `psql` または pgAdmin などの別のクライアントツールを使用して、 RDS for PostgreSQL DB インスタンスのライターインスタンスに接続します。
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. 次のコードをコピーして `psql` セッションコンソールに貼り付けることで、既存の TLE 拡張機能を変更します。
```
SELECT pgtle.install_update_path
(
'pg_distance',
'0.1',
'0.2',
$_pg_tle_$
CREATE OR REPLACE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
$_pg_tle_$
);
```
次のようなレスポンスが表示されます。
```
install_update_path
---------------------
t
(1 row)
```
このバージョンの拡張機能をデフォルトバージョンにすると、データベースユーザーがデータベースで拡張機能を作成または更新するときにバージョンを指定する必要がなくなります。
1. TLE 拡張機能の修正バージョン (バージョン 0.2) がデフォルトバージョンになるように指定するには、次の例に示す `pgtle.set_default_version` 関数を使用します。
```
SELECT pgtle.set_default_version('pg_distance', '0.2');
```
この関数の詳細については、「[pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version)」を参照してください。
1. コードを配置したら、次に示すように、`ALTER EXTENSION ... UPDATE` コマンドを使用して、インストールされている TLE 拡張機能を通常の方法で更新できます。
```
ALTER EXTENSION pg_distance UPDATE;
```
# TLE 拡張機能をデータベースから削除する
TLE 拡張機能は、他の PostgreSQL 拡張機能の場合と同じように `DROP EXTENSION` コマンドを使用して削除できます。拡張機能を削除しても、拡張機能を構成するインストールファイルは削除されないため、ユーザーは拡張機能を再作成できます。拡張機能とそのインストールファイルを削除するには、次の 2 段階のプロセスを実行します。
**TLE 拡張機能とそのインストールファイルを削除するには**
1. `psql` または別のクライアントツールを使用して RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. PostgreSQL 拡張機能と同様に、この拡張機能を削除してください。
```
DROP EXTENSION your-TLE-extension
```
例えば、[例: SQL を使用した信頼できる言語拡張関数の作成](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example) で詳細を説明しているように `pg_distance` という拡張機能を作成する場合は、次のように拡張機能を削除できます。
```
DROP EXTENSION pg_distance;
```
次のように、拡張機能が削除されたことを確認する出力が表示されます。
```
DROP EXTENSION
```
この時点で、拡張機能はデータベースでアクティブではなくなります。ただし、インストールファイルとコントロールファイルはデータベースにまだ残っているため、データベースユーザーは必要に応じて拡張機能を再作成できます。
+ 拡張ファイルをそのまま残して、データベースユーザーが TLE 拡張機能を作成できるようにする場合は、ここで終了してください。
+ 拡張機能を占めるすべてのファイルを削除する場合は、次のステップに進みます。
1. 拡張機能のインストールファイルをすべて削除するには、`pgtle.uninstall_extension` 関数を使用してください。この関数は、拡張機能のコードとコントロールファイルをすべて削除します。
```
SELECT pgtle.uninstall_extension('your-tle-extension-name');
```
例えば、すべての `pg_distance` インストールファイルを削除するには、次のコマンドを使用します。
```
SELECT pgtle.uninstall_extension('pg_distance');
uninstall_extension
---------------------
t
(1 row)
```
# Trusted Language Extensions for PostgreSQL のアンインストール
TLE を使用して独自の TLE 拡張機能を作成する必要がなくなった場合は、`pg_tle` 拡張機能を削除してすべてのアーティファクトを削除できます。このアクションには、データベース内のすべての TLE 拡張機能の削除と `pgtle` スキーマの削除が含まれます。
**`pg_tle` 拡張機能とそのスキーマをデータベースから削除するには**
1. `psql` または別のクライアントツールを使用して RDS for PostgreSQL DB インスタンスに接続します。
```
psql --host=.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. `pg_tle` 拡張機能をデータベースから削除します。データベースに独自の TLE 拡張機能がまだデータベースで実行されている場合は、それらの拡張機能も削除する必要があります。そのためには、次に示すように、`CASCADE` キーワードを使用します。
```
DROP EXTENSION pg_tle CASCADE;
```
`pg_tle` 拡張機能がデータベースでまだ有効になっていない場合は、`CASCADE` キーワードを使用する必要はありません。
1. `pgtle` スキーマを削除します。このアクションにより、データベースからすべての管理関数が削除されます。
```
DROP SCHEMA pgtle CASCADE;
```
このコマンドは、プロセスが完了すると、以下を返します。
```
DROP SCHEMA
```
`pg_tle` 拡張機能、そのスキーマ、関数、およびすべてのアーティファクトが削除されます。TLE を使用して新しい拡張機能を作成するには、セットアッププロセスをもう一度実行してください。詳細については、「[ RDS for PostgreSQL DB インスタンスに Trusted Language Extensions を設定する](PostgreSQL_trusted_language_extension-setting-up.md)」を参照してください。
# TLE 拡張機能で PostgreSQL フックを使用する
フックは PostgreSQL で利用できるコールバックメカニズムで、開発者は通常のデータベースオペレーション中にカスタム関数やその他のルーチンを呼び出すことができます。TLE 開発キットは PostgreSQL フックをサポートしているため、実行時にカスタム関数を PostgreSQL の動作と統合できます。例えば、フックを使用して認証プロセスを独自のカスタムコードに関連付けたり、特定のニーズに合わせてクエリの計画と実行プロセスを変更したりできます。
TLE 拡張機能にはフックを使用できます。フックの適用範囲がグローバルな場合、すべてのデータベースに適用されます。そのため、TLE 拡張機能がグローバルフックを使用している場合は、ユーザーがアクセスできるすべてのデータベースに TLE 拡張機能を作成する必要があります。
`pg_tle` 拡張機能を使用して独自の Trusted Language Extensions を構築する場合、SQL API の利用可能なフックを使用して拡張機能の関数を構築できます。すべてのフックを `pg_tle` に登録する必要があります。一部のフックでは、さまざまな設定パラメータを設定する必要がある場合もあります。例えば、`passcode` チェックフックをオン、オフ、または必須に設定できます。使用可能な `pg_tle` フックの特定の要件の詳細については、「[Trusted Language Extensions for PostgreSQL のフックリファレンス](PostgreSQL_trusted_language_extension-hooks-reference.md)」を参照してください。
## 例: PostgreSQL フックを使用する拡張機能の作成
このセクションで説明する例では、PostgreSQL フックを使用して特定の SQL のオペレーション中に入力されたパスワードをチェックし、データベースユーザーが自分のパスワードを `password_check.bad_passwords` テーブルに含まれるパスワードに設定できないようにします。この表には、一般的によく使用されているものの、簡単に破られてしまうパスワードの選択肢の上位 10 件が掲載されています。
この例を 、RDS for PostgreSQL DB インスタンスに設定するには、Trusted Language Extensions が既にインストールされている必要があります。詳細については、「[ RDS for PostgreSQL DB インスタンスに Trusted Language Extensions を設定する](PostgreSQL_trusted_language_extension-setting-up.md)」を参照してください。
**パスワードチェックフックの例を設定するには**
1. `psql` を使用して、に接続します。RDS for PostgreSQL DB インスタンス。
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. [パスワードチェックフックコードリスト](#PostgreSQL_trusted_language_extension-example-hook_code_listing) のコードをコピーし、データベースに貼り付けます。
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
拡張機能がデータベースに読み込まれると、次のような出力が表示されます。
```
install_extension
-------------------
t
(1 row)
```
1. データベースに接続したままで、拡張機能を作成できるようになりました。
```
CREATE EXTENSION my_password_check_rules;
```
1. 次の `psql` メタコマンドを使用して、拡張機能がデータベースに作成されたことを確認できます。
```
\dx
List of installed extensions
Name | Version | Schema | Description
-------------------------+---------+------------+-------------------------------------------------------------
my_password_check_rules | 1.0 | public | Prevent use of any of the top-ten most common bad passwords
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
1. 別のターミナルセッションを開いて、AWS CLI を操作します。パスワードチェックフックを有効にするには、カスタム DB パラメータグループを変更する必要があります。そのためには、以下の例に示すように [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) CLI コマンドを使用します。
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
パラメータが正常に有効になると、次のような出力が表示されます。
```
(
"DBParameterGroupName": "docs-lab-parameters-for-tle"
}
```
パラメータグループ設定の変更が適用されるまでには数分かかる場合があります。ただし、このパラメータは動的であるため、設定を有効にするために を再起動する必要はありません。
1. `psql` セッションを開き、データベースに問い合わせて password\$1check フックが有効になっていることを確認します。
```
labdb=> SHOW pgtle.enable_password_check;
pgtle.enable_password_check
-----------------------------
on
(1 row)
```
パスワードチェックフックがアクティブになりました。次の例に示すように、新しいロールを作成し、不適切なパスワードを使用してテストできます。
```
CREATE ROLE test_role PASSWORD 'password';
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 21 at RAISE
SQL statement "SELECT password_check.passcheck_hook(
$1::pg_catalog.text,
$2::pg_catalog.text,
$3::pgtle.password_types,
$4::pg_catalog.timestamptz,
$5::pg_catalog.bool)"
```
出力は、読みやすい形式にしてあります。
次の例では、`pgsql` インタラクティブメタコマンドの `\password` 動作が password\$1check フックの影響を受けることを示しています。
```
postgres=> SET password_encryption TO 'md5';
SET
postgres=> \password
Enter new password for user "postgres":*****
Enter it again:*****
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 12 at RAISE
SQL statement "SELECT password_check.passcheck_hook($1::pg_catalog.text, $2::pg_catalog.text, $3::pgtle.password_types, $4::pg_catalog.timestamptz, $5::pg_catalog.bool)"
```
この TLE 拡張機能モジュールを削除して、必要に応じてソースファイルをアンインストールできます。詳細については、「[TLE 拡張機能をデータベースから削除するTLE 拡張機能をデータベースから削除する](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md)」を参照してください。
### パスワードチェックフックコードリスト
ここに示すサンプルコードは、`my_password_check_rules` TLE 拡張機能の仕様を定義しています。このコードをコピーしてデータベースに貼り付けると、`my_password_check_rules` 拡張機能のコードがデータベースにロードされ、`password_check` フックが拡張機能で使用できるように登録されます。
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
# TLE でのカスタムデータ型の使用
PostgreSQLは、データベース内の複雑なデータ構造を効率的に処理するための新しい基本型（スカラー型とも呼ばれます）を登録するコマンドをサポートしています。ベースタイプを使用すると、データを内部に保存する方法や、データを外部のテキスト表現に変換したり、外部のテキスト表現から変換したりする方法をカスタマイズできます。これらのカスタムデータ型は、数値やテキストなどの組み込み型では十分な検索セマンティクスを提供できない機能ドメインをサポートするために PostgreSQL を拡張する場合に役立ちます。
RDS for PostgreSQL では、信頼できる言語拡張機能でカスタムデータ型を作成し、これらの新しいデータ型の SQL 操作とインデックス操作をサポートする関数を定義できます。カスタムデータ型は、以下のバージョンで利用できます。
+ RDS for PostgreSQL 15.4 またはそれ以降の 15 バージョン
+ RDS for PostgreSQL 14.9 またはそれ以降の 14 バージョン
+ RDS for PostgreSQL 13.12 またはそれ以降の 13 バージョン
詳細については、「[信頼言語ベースタイプ](https://github.com/aws/pg_tle/blob/main/docs/09_datatypes.md)」を参照してください。
# Trusted Language Extensions for PostgreSQL の関数リファレンス
Trusted Language Extensions for PostgreSQL で利用できる関数については、以下のリファレンスドキュメントを参照してください。これらの関数を使用して、*TLE 拡張機能*、つまり Trusted Language Extensions 開発キットを使用して開発した PostgreSQL 拡張機能のインストール、登録、更新、管理を行います。
**Topics**
+ [
## pgtle.available\$1extensions
](#pgtle.available_extensions)
+ [
## pgtle.available\$1extension\$1versions
](#pgtle.available_extension_versions)
+ [
## pgtle.extension\$1update\$1paths
](#pgtle.extension_update_paths)
+ [
## pgtle.install\$1extension
](#pgtle.install_extension)
+ [
## pgtle.install\$1update\$1path
](#pgtle.install_update_path)
+ [
## pgtle.register\$1feature
](#pgtle.register_feature)
+ [
## pgtle.register\$1feature\$1if\$1not\$1exists
](#pgtle.register_feature_if_not_exists)
+ [
## pgtle.set\$1default\$1version
](#pgtle.set_default_version)
+ [
## pgtle.uninstall\$1extension(name)
](#pgtle.uninstall_extension-name)
+ [
## pgtle.uninstall\$1extension(name, version)
](#pgtle.uninstall_extension-name-version)
+ [
## pgtle.uninstall\$1extension\$1if\$1exists
](#pgtle.uninstall_extension_if_exists)
+ [
## pgtle.uninstall\$1update\$1path
](#pgtle.uninstall_update_path)
+ [
## pgtle.uninstall\$1update\$1path\$1if\$1exists
](#pgtle.uninstall_update_path_if_exists)
+ [
## pgtle.unregister\$1feature
](#pgtle.unregister_feature)
+ [
## pgtle.unregister\$1feature\$1if\$1exists
](#pgtle.unregister_feature_if_exists)
## pgtle.available\$1extensions
`pgtle.available_extensions` 関数は、集合を返す関数です。データベース内の使用可能なすべての TLE 拡張機能を返します。返される各行には、1 つの TLE 拡張機能に関する情報が含まれています。
### 関数プロトタイプ
```
pgtle.available_extensions()
```
### ロール
なし。
### 引数
なし。
### 出力
+ `name` – TLE 拡張機能の名前。
+ `default_version` – バージョンを指定せずに `CREATE EXTENSION` が呼び出されたときに使用する TLE 拡張機能のバージョン。
+ `description` – TLE 拡張機能に関するさらに詳細な説明。
### 使用例
```
SELECT * FROM pgtle.available_extensions();
```
## pgtle.available\$1extension\$1versions
`available_extension_versions` 関数は、集合を返す関数です。使用可能なすべての TLE 拡張機能とそのバージョンの一覧を返します。各行には、特定のロールが必要かどうかなど、特定の TLE 拡張機能のバージョンに関する情報が含まれています。
### 関数プロトタイプ
```
pgtle.available_extension_versions()
```
### ロール
なし。
### 引数
なし。
### 出力
+ `name` – TLE 拡張機能の名前。
+ `version` – TLE 拡張機能のバージョン。
+ `superuser` – この値は、TLE 拡張機能では常に `false` です。TLE 拡張機能の作成または更新に必要なアクセス許可は、特定のデータベースに他のオブジェクトを作成する場合と同じです。
+ `trusted` – この値は、TLE 拡張機能では常に `false` です。
+ `relocatable` – この値は、TLE 拡張機能では常に `false` です。
+ `schema` – TLE 拡張機能がインストールされているスキーマの名前を指定します。
+ `requires` – この TLE 拡張機能に必要な他の拡張機能の名前を含む配列。
+ `description` – TLE 拡張機能の詳細な説明。
出力値の詳細については、PostgreSQL ドキュメントの [[Extension > Extension Files] (拡張機能 > 拡張機能ファイル) にある「関連オブジェクトのパッケージ化」](https://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11)を参照してください。
### 使用例
```
SELECT * FROM pgtle.available_extension_versions();
```
## pgtle.extension\$1update\$1paths
`extension_update_paths` 関数は、集合を返す関数です。TLE 拡張機能で使用可能なすべての更新パスのリストを返します。各行には、その TLE 拡張機能で使用可能なアップグレードまたはダウングレードが含まれています。
### 関数プロトタイプ
```
pgtle.extension_update_paths(name)
```
### ロール
なし。
### 引数
`name` – アップグレードパスを取得する TLE 拡張機能の名前。
### 出力
+ `source` – 更新のソースバージョン。
+ `target` – 更新のターゲットバージョン。
+ `path` – TLE 拡張機能を `source` バージョンから `target` にアップグレードするために使用されるアップグレードパス (例えば `0.1--0.2`)。
### 使用例
```
SELECT * FROM pgtle.extension_update_paths('your-TLE');
```
## pgtle.install\$1extension
この `install_extension` 関数を使用すると、TLE 拡張機能を構成するアーティファクトをデータベースにインストールし、その後、`CREATE EXTENSION` コマンドを使用して作成できます。
### 関数プロトタイプ
```
pgtle.install_extension(name text, version text, description text, ext text, requires text[] DEFAULT NULL::text[])
```
### ロール
なし。
### 引数
+ `name` – TLE 拡張機能の名前。この値は `CREATE EXTENSION` を呼び出すときに使用されます。
+ `version` – TLE 拡張機能のバージョン。
+ `description` – TLE 拡張機能に関する詳細な説明。この説明は、`pgtle.available_extensions()` の `comment` フィールドに表示されます。
+ `ext` – TLE 拡張機能の内容。この値には、関数などのオブジェクトが含まれます。
+ `requires` – この TLE 拡張機能の依存関係を指定するオプションパラメータ。`pg_tle` 拡張機能は、依存関係として自動的に追加されます。
これらの引数の多くは、PostgreSQL インスタンスのファイルシステムに PostgreSQL 拡張機能をインストールするための拡張制御ファイルに含まれている引数と同じです。詳細については、PostgreSQL ドキュメントの「[拡張機能への関連オブジェクトのパッケージ化](https://www.postgresql.org/docs/current/extend-extensions.html)」にある「[拡張ファイル](http://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11)」を参照してください。
### 出力
この関数は、正常時には `OK` を、エラー時には `NULL` を返します。
+ `OK` – TLE 拡張機能がデータベースに正常にインストールされました。
+ `NULL` – TLE 拡張機能がデータベースに正常にインストールされませんでした。
### 使用例
```
SELECT pgtle.install_extension(
'pg_tle_test',
'0.1',
'My first pg_tle extension',
$_pgtle_$
CREATE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 42;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.install\$1update\$1path
この `install_update_path` 関数は、TLE 拡張機能の 2 つの異なるバージョン間の更新パスを提供します。この機能によって、TLE 拡張機能のユーザーは `ALTER EXTENSION ... UPDATE` 構文を使用してバージョンを更新できます。
### 関数プロトタイプ
```
pgtle.install_update_path(name text, fromvers text, tovers text, ext text)
```
### ロール
`pgtle_admin`
### 引数
+ `name` – TLE 拡張機能の名前。この値は `CREATE EXTENSION` を呼び出すときに使用されます。
+ `fromvers` – アップグレードの TLE 拡張機能のソースバージョン。
+ `tovers` – アップグレードする TLE 拡張機能のデスティネーションバージョン。
+ `ext` – 更新の内容。この値には、関数などのオブジェクトが含まれます。
### 出力
なし。
### 使用例
```
SELECT pgtle.install_update_path('pg_tle_test', '0.1', '0.2',
$_pgtle_$
CREATE OR REPLACE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 21;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.register\$1feature
この `register_feature` 関数は、指定された内部 PostgreSQL 機能を `pgtle.feature_info` テーブルに追加します。PostgreSQL フックは、内部 PostgreSQL 機能の一例です。Trusted Language Extensions 開発キットは、PostgreSQL フックの使用をサポートしています。現在、この関数は次の機能をサポートしています。
+ `passcheck` – PostgreSQL のパスワードチェック動作をカスタマイズするプロシージャまたは関数にパスワードチェックフックを登録します。
### 関数プロトタイプ
```
pgtle.register_feature(proc regproc, feature pg_tle_feature)
```
### ロール
`pgtle_admin`
### 引数
+ `proc` – その機能に使用するストアドプロシージャまた関数の名前。
+ `feature` – 関数に登録する `pg_tle` 機能 (`passcheck` など) の名前。
### 出力
なし。
### 使用例
```
SELECT pgtle.register_feature('pw_hook', 'passcheck');
```
## pgtle.register\$1feature\$1if\$1not\$1exists
この `pgtle.register_feature_if_not_exists` 関数は、指定した PostgreSQL 機能を `pgtle.feature_info` テーブルに追加し、その機能を使用する TLE 拡張機能またはその他のプロシージャまたは関数を識別します。フックと Trusted Language Extensions の詳細については、「[TLE 拡張機能で PostgreSQL フックを使用する](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)」を参照してください。
### 関数プロトタイプ
```
pgtle.register_feature_if_not_exists(proc regproc, feature pg_tle_feature)
```
### ロール
`pgtle_admin`
### 引数
+ `proc` – TLE 拡張機能として使用するロジック (コード) を含むストアドプロシージャまたは関数の名前。例えば、`pw_hook` コードです。
+ `feature` – TLE 関数に登録する PostgreSQL 機能の名前。現在、使用できる機能は `passcheck` フックだけです。詳細については、「[パスワードチェックフック (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook)」を参照してください。
### 出力
指定された拡張機能を登録した後、`true` を返します。機能が既に登録されていた場合は `false` を返します。
### 使用例
```
SELECT pgtle.register_feature_if_not_exists('pw_hook', 'passcheck');
```
## pgtle.set\$1default\$1version
`set_default_version` 関数では、TLE 拡張機能に `default_version` を指定できます。この関数を使用してアップグレードパスを定義し、そのバージョンを TLE 拡張機能のデフォルトとして指定できます。データベースユーザーが `CREATE EXTENSION` および `ALTER EXTENSION ... UPDATE` コマンドで TLE 拡張機能を指定すると、そのユーザー用にそのバージョンの TLE 拡張機能がデータベースに作成されます。
この関数は成功すると `true` を返します。`name` 引数で指定された TLE 拡張機能が存在しない場合、関数はエラーを返します。同様に、TLE 拡張機能の `version` が存在しない場合、関数はエラーを返します。
### 関数プロトタイプ
```
pgtle.set_default_version(name text, version text)
```
### ロール
`pgtle_admin`
### 引数
+ `name` – TLE 拡張機能の名前。この値は `CREATE EXTENSION` を呼び出すときに使用されます。
+ `version` – デフォルトに設定する TLE 拡張機能のバージョン。
### 出力
+ `true` — デフォルトバージョンの設定が成功すると、関数は `true` を返します。
+ `ERROR` – 指定された名前またはバージョンの TLE 拡張機能が存在しない場合は、エラーメッセージを返します。
### 使用例
```
SELECT * FROM pgtle.set_default_version('my-extension', '1.1');
```
## pgtle.uninstall\$1extension(name)
`uninstall_extension` 関数は、TLE 拡張機能のすべてのバージョンをデータベースから削除します。この関数により、今後の `CREATE EXTENSION` の呼び出しで TLE 拡張機能がインストールされないようにします。TLE 拡張機能がデータベースに存在しない場合、エラーが発生します。
`uninstall_extension` 関数は、データベースで現在アクティブな TLE 拡張機能を削除しません。現在アクティブな TLE 拡張機能を削除するには、`DROP EXTENSION` を明示的に呼び出して削除する必要があります。
### 関数プロトタイプ
```
pgtle.uninstall_extension(extname text)
```
### ロール
`pgtle_admin`
### 引数
+ `extname` – アンインストールする TLE 拡張機能の名前。この名前は、特定のデータベースで使用する TLE 拡張機能をロードするために `CREATE EXTENSION` で使用される名前と同じです。
### 出力
なし。
### 使用例
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test');
```
## pgtle.uninstall\$1extension(name, version)
`uninstall_extension(name, version)` 関数は、指定されたバージョンの TLE 拡張機能をデータベースから削除します。この関数は、`CREATE EXTENSION` および `ALTER EXTENSION` が TLE 拡張機能を指定されたバージョンにインストールまたは更新するのを防ぎます。この関数は、TLE 拡張機能の指定されたバージョンのすべての更新パスも削除します。この関数は、データベースで現在アクティブになっている TLE 拡張機能をアンインストールしません。TLE 拡張機能を削除するには、明示的に `DROP EXTENSION` を呼び出す必要があります。TLE 拡張機能のすべてのバージョンをアンインストールするには、「[pgtle.uninstall\$1extension(name)](#pgtle.uninstall_extension-name)」を参照してください。
### 関数プロトタイプ
```
pgtle.uninstall_extension(extname text, version text)
```
### ロール
`pgtle_admin`
### 引数
+ `extname` – TLE 拡張機能の名前。この値は `CREATE EXTENSION` を呼び出すときに使用されます。
+ `version` - データベースからアンインストールする TLE 拡張機能のバージョン。
### 出力
なし。
### 使用例
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test', '0.2');
```
## pgtle.uninstall\$1extension\$1if\$1exists
`uninstall_extension_if_exists` 関数は、特定のデータベースから TLE 拡張機能のすべてのバージョンを削除します。TLE 拡張機能が存在しない場合、関数は何も返しません (エラーメッセージは発生しません)。指定された拡張機能がデータベース内で現在アクティブになっている場合、この関数はその拡張機能を削除しません。この関数を使用してアーティファクトをアンインストールする前に、`DROP EXTENSION` を明示的に呼び出して TLE 拡張機能を削除する必要があります。
### 関数プロトタイプ
```
pgtle.uninstall_extension_if_exists(extname text)
```
### ロール
`pgtle_admin`
### 引数
+ `extname` – TLE 拡張機能の名前。この値は `CREATE EXTENSION` を呼び出すときに使用されます。
### 出力
`uninstall_extension_if_exists` 関数は、指定された拡張機能をアンインストールした後に、`true` を返します。指定した拡張機能が存在しない場合、この関数は `false` を返します。
+ `true` – TLE 拡張機能をアンインストールした後に `true` を返します。
+ `false` – TLE 拡張機能がデータベースに存在しない場合に `false` を返します。
### 使用例
```
SELECT * FROM pgtle.uninstall_extension_if_exists('pg_tle_test');
```
## pgtle.uninstall\$1update\$1path
`uninstall_update_path` 関数は TLE 拡張機能から指定された更新パスを削除します。これにより、`ALTER EXTENSION ... UPDATE TO` では、これを更新パスとして使用できなくなります。
TLE 拡張機能が、この更新パス上のいずれかのバージョンで現在使用されている場合、その拡張機能はデータベースに残ります。
指定された更新パスが存在しない場合、この関数はエラーを発生させます。
### 関数プロトタイプ
```
pgtle.uninstall_update_path(extname text, fromvers text, tovers text)
```
### ロール
`pgtle_admin`
### 引数
+ `extname` – TLE 拡張機能の名前。この値は `CREATE EXTENSION` を呼び出すときに使用されます。
+ `fromvers` – 更新パスで使用されている TLE 拡張機能のソースバージョン。
+ `tovers` – 更新パスで使用されている TLE 拡張機能の送信先バージョン。
### 出力
なし。
### 使用例
```
SELECT * FROM pgtle.uninstall_update_path('pg_tle_test', '0.1', '0.2');
```
## pgtle.uninstall\$1update\$1path\$1if\$1exists
`uninstall_update_path_if_exists` 関数は、指定された更新パスを TLE 拡張機能から削除するという点で `uninstall_update_path` に似ています。ただし、更新パスが存在しない場合、この関数はエラーメッセージを表示しません。代わりに、関数は `false` を返します。
### 関数プロトタイプ
```
pgtle.uninstall_update_path_if_exists(extname text, fromvers text, tovers text)
```
### ロール
`pgtle_admin`
### 引数
+ `extname` – TLE 拡張機能の名前。この値は `CREATE EXTENSION` を呼び出すときに使用されます。
+ `fromvers` – 更新パスで使用されている TLE 拡張機能のソースバージョン。
+ `tovers` – 更新パスで使用されている TLE 拡張機能の送信先バージョン。
### 出力
+ `true` – 関数は TLE 拡張機能のパスを正常に更新しました。
+ `false` – この関数は TLE 拡張機能のパスを更新できませんでした。
### 使用例
```
SELECT * FROM pgtle.uninstall_update_path_if_exists('pg_tle_test', '0.1', '0.2');
```
## pgtle.unregister\$1feature
`unregister_feature` 関数は、フックなどの `pg_tle` 機能を使用するために登録された関数を削除する方法を提供します。機能の登録については、「[pgtle.register\$1feature](#pgtle.register_feature)」を参照してください。
### 関数プロトタイプ
```
pgtle.unregister_feature(proc regproc, feature pg_tle_features)
```
### ロール
`pgtle_admin`
### 引数
+ `proc` – `pg_tle` 機能に登録するストアド関数の名前。
+ `feature` – 関数に登録する `pg_tle` 機能の名前。例えば、`passcheck` は、お客様が開発した、信頼できる言語拡張機能で使用するために登録できる機能です。詳細については、「[パスワードチェックフック (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook)」を参照してください。
### 出力
なし。
### 使用例
```
SELECT * FROM pgtle.unregister_feature('pw_hook', 'passcheck');
```
## pgtle.unregister\$1feature\$1if\$1exists
`unregister_feature` 関数は、フックなどの `pg_tle` 機能を使用するために登録された関数を削除する方法を提供します。詳細については、「[TLE 拡張機能で PostgreSQL フックを使用する](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)」を参照してください。機能を正常に登録解除すると `true` を返します。機能が登録されていない場合は `false` を返します。
TLE 拡張機能の `pg_tle` 機能の登録の詳細については、「[pgtle.register\$1feature](#pgtle.register_feature)」を参照してください。
### 関数プロトタイプ
```
pgtle.unregister_feature_if_exists('proc regproc', 'feature pg_tle_features')
```
### ロール
`pgtle_admin`
### 引数
+ `proc` – `pg_tle` 機能を含めるように登録されたストアド関数の名前。
+ `feature` - 信頼できる言語拡張機能に登録された `pg_tle` 機能の名前。
### 出力
次のように `false` または `true` を返します。
+ `true` - 関数は拡張機能から機能を正常に登録解除しました。
+ `false` – 関数は TLE 拡張機能から機能を登録解除できませんでした。
### 使用例
```
SELECT * FROM pgtle.unregister_feature_if_exists('pw_hook', 'passcheck');
```
# Trusted Language Extensions for PostgreSQL のフックリファレンス
Trusted Language Extensions for PostgreSQL は PostgreSQL フックをサポートしています。フックは、PostgreSQL のコア機能を拡張するために開発者が利用できる内部コールバックメカニズムです。フックを使用することで、開発者はさまざまなデータベースオペレーションで使用する独自の関数やプロシージャを実装できるため、PostgreSQL の動作を何らかの方法で変更できます。例えば、`passcheck` フックを使用して、ユーザー (ロール) のパスワードを作成または変更する際に提供されたパスワードを PostgreSQL がどのように処理するかをカスタマイズできます。
TLE 拡張機能で利用できる passcheck フックについては、次のドキュメントを参照してください。クライアント認証フックを含む使用可能なフックの詳細については、「[Trusted Language Extensions hooks](https://github.com/aws/pg_tle/blob/main/docs/04_hooks.md)」を参照してください。
## パスワードチェックフック (passcheck)
`passcheck` フックは、以下の SQL コマンドと `psql` メタコマンドのパスワードチェックプロセス時の PostgreSQL の動作をカスタマイズするために使用されます。
+ `CREATE ROLE username ...PASSWORD` – 詳細については、PostgreSQL のドキュメントの「[CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html)」を参照してください。
+ `ALTER ROLE username...PASSWORD` – 詳細については、PostgreSQL のドキュメントの「[ALTER ROLE](https://www.postgresql.org/docs/current/sql-alterrole.html)」を参照してください。
+ `\password username` – このインタラクティブな `psql` メタコマンドは、`ALTER ROLE ... PASSWORD` 構文を透過的に使用する前にパスワードをハッシュすることで、指定されたユーザーのパスワードを安全に変更します。このメタコマンドは `ALTER ROLE ... PASSWORD` コマンドの安全なラッパーであるため、フックは `psql` メタコマンドの動作に適用されます。
例については、「[パスワードチェックフックコードリスト](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md#PostgreSQL_trusted_language_extension-example-hook_code_listing)」を参照してください。
**Contents**
+ [
### 関数プロトタイプ
](#passcheck_hook-prototype)
+ [
### 引数
](#passcheck_hook-arguments)
+ [
### 設定
](#passcheck_hook-configuration)
+ [
### 使用に関する注意事項
](#passcheck_hook-usage)
### 関数プロトタイプ
```
passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
```
### 引数
`passcheck` フック関数は、次の引数を取ります。
+ `username` – パスワードを設定するロール (ユーザー名) の名前 (テキスト)。
+ `password` – プレーンテキストまたはハッシュ化されたパスワード。入力するパスワードは、`password_type` で指定されたタイプと一致する必要があります。
+ `password_type` – パスワードの `pgtle.password_type` 形式を指定します。この形式は、以下のいずれかのオプションになります。
+ `PASSWORD_TYPE_PLAINTEXT` – プレーンテキストのパスワード。
+ `PASSWORD_TYPE_MD5` – MD5 (メッセージダイジェスト 5) アルゴリズムを使用してハッシュ化されたパスワード。
+ `PASSWORD_TYPE_SCRAM_SHA_256` – SCRAM-SHA-256 アルゴリズムを使用してハッシュ化されたパスワード。
+ `valid_until` – パスワードが無効になる時間を指定します。この引数はオプションです。この引数を使用する場合は、時間を `timestamptz` 値で指定します。
+ `valid_null` – このブール値が `true` に設定されている場合、`valid_until` オプションは `NULL` に設定されます。
### 設定
この `pgtle.enable_password_check` 関数は、パスチェックフックが有効かどうかを制御します。パスチェックフックには 3 種類の設定があります。
+ `off` – `passcheck` パスワードチェックフックをオフにします。これは、デフォルト値です。
+ `on` – `passcode` パスワードチェックフックをオンにして、パスワードとテーブルを照合します。
+ `require` – パスワードチェックフックを定義する必要があります。
### 使用に関する注意事項
`passcheck` フックをオンまたはオフにするには、、RDS for PostgreSQL DB インスタンスのカスタム DB パラメータグループを変更する必要があります。
Linux、macOS、Unix の場合:
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
Windows の場合:
```
aws rds modify-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name your-custom-parameter-group ^
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```