Databases for EnterpriseDB の構成変更

Databases for EnterpriseDB は非推奨です。 2025年6月16日現在、新しいインスタンスを展開することはできません。既存のインスタンスは2025年10月15日までサポートされます。その日までにまだ存在しているインスタンスはすべて削除されます。詳細は Databases for EnterpriseDB の廃止を参照してください。

IBM Cloud® Databases for EnterpriseDB は構成可能であるため、PosgreSQL 設定の一部を変更して、Databases for EnterpriseDB のデータベースをユース・ケースに合わせてチューニングすることができます。データベースの構成に永続的な変更を加えるには、Cloud Databases cli-plugin または API を使用して、デプロイメントの構成ファイルに変更を書き込みます。

構成はスキーマで定義されています。変更を加えるには、対象の設定と新しい設定値を含む JSON オブジェクトを API または CLI に渡します。例えば、max_connections を 150 に設定するには、

{"configuration":{"max_connections":150}}

上記を CLI または API に渡します。

CLI での Databases for EnterpriseDB 構成の変更

デプロイメントの現在の構成を確認するには、次のようにします。

ibmcloud cdb deployment-configuration-schema <deployment name or CRN>

Cloud Databases CLI プラグインで構成を変更するには、deployment-configuration コマンドを使用します。

ibmcloud cdb deployment-configuration <deployment name or CRN> [@JSON_FILE | JSON_STRING]

このコマンドは、変更内容を JSON オブジェクトまたはファイルから読み取ります。詳しくは、リファレンス・ページを参照してください。

API での Databases for EnterpriseDB 構成の変更

デプロイメント構成に関するエンドポイントは 2 つあります。構成スキーマを表示するためのエンドポイントと、構成を変更するためのエンドポイントです。構成スキーマを表示するには、GET 要求を /deployments/{id}/configuration/schema に送信します。

構成を変更するには、変更する設定を JSON オブジェクトとして PATCH 要求の本文に指定して /deployments/{id}/configuration に送信します。

詳しくは、API リファレンスを参照してください。

使用可能な構成設定

メモリーの設定

shared_buffers

デフォルト - 32000 (8 KiB バッファーの数、または約 262 MB)
データベースを再始動する - はい
オプション - バッファーの最大数は 1048576 です。
注意事項 - この設定は、8 KiB の共有メモリー・バッファーの数を指定します。例えば、1 GB の shared_buffers スペースは 1048576 KiB であり、(1048576 KiB / 8 KiB) はバッファー 131072 個です。 shared_buffers のメモリー割り振り量は、デプロイメントの RAM の 25% にすることをお勧めします。 shared_buffers にこれより大きい値を設定すると、メモリーの問題が発生し、データベースが異常終了する可能性があります。 shared_buffers に割り振りメモリー量と同じか、それに近いか、それよりも大きい値を設定すると、データベースが起動しなくなります。 shared_buffers の合計スペースの最大量は、PostgreSQL コミュニティーの推奨に基づき、8 GB またはバッファー 1048576 個になっています。これより多い RAM を、(shared_buffers への割り当てをなしとしても) デプロイメントでキャッシュとパフォーマンスのために使用することができます。割り当てられた RAM をすべて使用するようにデータベースを構成しなくても、デプロイメントはすべての RAM を使用できます。

一般設定

max_connections

デフォルト - 115
データベースを再始動する - はい
注意事項 - 最大接続数を増やす前にスケーリングしなければならない場合があります。

max_prepared_transactions

デフォルト - 0
データベースを再始動する - はい
注意事項 - デフォルト値 0 では、PREPARE されたトランザクションの使用が無効になるので、PREPARE されたトランザクションを使用する必要がない限り、デフォルトのままにしておくことをお勧めします。

synchronous_commit

デフォルト- local
データベースを再始動する - いいえ
オプション - local、on、またはoff
注 - synchronous_commitをオフに設定すると、トランザクション・コミット率が増加しますが、クリーンでないシャットダウンが発生した場合は、コミットされたトランザクションが失われます。 synchronous_commitがオンに設定されている場合、トランザクションは、リーダーと少なくとも 1 つのレプリカに書き込まれたときにのみコミットされます。したがって、オンの設定は、少なくとも 3 つのメンバーがまだ存在するフォーメーションでのみ使用できます。この変更を実装する前に、「高可用性」ページをお読みください。

effective_io_concurrency

デフォルト- 12
データベースを再始動する - いいえ
注意事項 - この設定はデフォルトのままにしておくことをお勧めします。 SQL 照会のプロファイルを作成し、非効率的なビットマップ・ヒープ・スキャンが検出された場合にのみ、この設定値を大きくしてください。 IOPS はディスク・サイズと関連しているので、デフォルトまたは小さいサイズのディスクでこの設定値を大きくすることも推奨されません。

deadlock_timeout

デフォルト - 10000
データベースを再始動する - いいえ
オプション - 最小値 100
注意事項 - デッドロックを検査するまで待機するミリ秒数であり、ロック待機がログに記録される間隔でもあります。ログは、ロギングとの統合を行うと利用できるようになります。この数値の設定が小さすぎると、パフォーマンスに悪影響があります。

log_connections

デフォルト- off
データベースを再始動する - いいえ
オプション - on 値または off 値
注意事項 - この値を on に設定すると、ログが非常に冗長になります。また、60 秒ごとにメトリックが抽出されるので、モニタリング・ツールの接続も示されます。これを on に設定する場合は、接続 URI に application_name を設定してログに概要を保持するようにすることをお勧めします。示される IP アドレスは Kubernetes 内部 IP だからです。接続 URI の調整についての詳細は、 PostgreSQL の資料に記載されています。 off に設定した場合は、デフォルト設定と比べて動作の変化はなく、接続はログに記録されません。ログは、ロギングとの統合を行うと利用できるようになります。 on に設定した場合は、次の例のような行がログで示されます。この例では、アプリケーション名は test-app に設定されています。

2021-03-01 10:27:56 UTC [[unknown]] [00000] [708]: [2-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  connection authorized: user=admin database=ibmclouddb application_name=test-app SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, compression=off)

log_disconnections

デフォルト- off
データベースを再始動する - いいえ
オプション - on 値または off 値
注意事項 - この値を on に設定すると、ログが非常に冗長になります。また、60 秒ごとにメトリックが抽出されるので、モニタリング・ツールの切断も示されます。これを on に設定する場合は、接続 URI に application_name を設定してログに概要を保持するようにすることをお勧めします。示される IP アドレスは Kubernetes 内部 IP だからです。接続 URI の調整についての詳細は、 PostgreSQL の資料に記載されています。 off に設定した場合は、デフォルト設定と比べて動作の変化はなく、切断はログに記録されません。ログは、ロギングとの統合を行うと利用できるようになります。 on に設定した場合は、次の例のような行がログで示されます。この例では、アプリケーション名は test-app に設定されています。
```
2021-03-01 10:27:56 UTC [test-app] [00000] [708]: [3-1] user=admin,db=ibmclouddb,client=127.0.0.1 LOG:  disconnection: session time: 0:00:00.793 user=admin database=ibmclouddb host=127.0.0.1 port=50638
```

WAL の設定

archive_timeout

デフォルト- 1800
データベースを再始動する - いいえ
オプション - 最小値 300
注意事項 - 次の WAL ファイルへの切り替えを強制するまで待機する秒数。指定した秒数が経過し、データベース・アクティビティーが発生すると、サーバーは新しいセグメントに切り替えます。データがアーカイブされない状態でいる時間を効果的に制限できます。

log_min_duration_statement

デフォルト- 100
データベースを再始動する - いいえ
オプション - 最小値 100
注意事項 - 指定したミリ秒数より長くかかっているステートメントがログに記録されます。

wal_level、max_replication_slots、および max_wal_senders という 3 つの設定によって、wal2json 論理デコード・プラグインの使用が有効化されます。このプラグインを使用しない場合は、これらの設定をデフォルトのままにしておく必要があります。

wal_level

デフォルト- hot_standby
データベース再始動 - 必要
注意事項 - WAL レベルを制御します。指定できる値は hot_standby または logical です。論理デコードを使用するには、logical に設定します。論理デコードを使用しない場合に logical を使用すると WAL サイズが大きくなります。これには欠点がいくつかあるだけで、利点は一切ありません。 SHOW wal_level; で psql を使用して構成を確認する場合、バージョン 9.6 以降では、値 hot_standby が replica にマップされることに注意してください。

max_replication_slots

デフォルト- 10
データベース再始動 - 必要
注意事項 - 同時に定義できるレプリケーション・スロットの最大数。デフォルトおよび最小のスロット数は 10 です。高可用性 (HA) のためにデプロイメントが内部使用するものとして、20 個のスロットが予約されます。スロットを使用するには、20 を超える値を設定し、コンシューマーごとに 1 つのスロットを用意する必要があります。予期されるコンシューマーごとに、最小数より 1 つ余分にスロットを追加することをお勧めします。 wal2json を使用し、max_replication_slots を大きくしないと、HA および読み取り専用レプリカに影響が生じる可能性があります。 wal2json を使用しない場合は、この設定をデフォルトのままにする必要があります。

max_wal_senders

デフォルト- 12
データベース再始動 - 必要
注意事項 - 同時に実行できる WAL 送信側プロセスの最大数。デフォルトおよび最小数は 12 です。コンシューマーごとに 1 つの wal_sender が必要です。高可用性 (HA) のためにデプロイメントが内部使用するものとして、20 個のスロットが予約されます。 20 より大きい値を設定する必要があります。予期されるコンシューマーごとに、最小数より 1 つ余分に wal_sender を追加することをお勧めします。 wal2json を使用し、max_wal_senders を大きくしないと、HA および読み取り専用レプリカに影響が生じる可能性があります。 wal2json を使用しない場合は、この設定をデフォルトのままにする必要があります。