ACUを増やしてもmax_connectionsが反映されない原因と確認手順

Aurora Serverless v2で接続数が足りなくなり、最大ACUを引き上げた。パラメータグループのmax_connectionsも新しい値に書き換えた。それでもSHOW max_connections;は以前の値を返し、クライアント側の接続上限も変わらない。コンソール上はパラメータが新しい値で表示されているため、設定ミスを疑って同じ画面を何度も見直す流れに陥りがちです。原因はACUの指定値でもコンソールの表示でもなく、パラメータの反映タイミングにあります。

この記事は「Aurora Serverless v2のmax_connectionsは最大ACUで決まる」の一部を、話題を絞って書き直したものです。接続数を増やす以外の選択肢や、パラメータ変更時のチェックリストと監視項目は、ブログの完全版にまとめています: Aurora Serverless v2のmax_connectionsは最大ACUで決まる

max_connectionsのデフォルト値は何で決まるか

Aurora Serverless v2のmax_connectionsのデフォルト値は、DBインスタンスのメモリ量を表すDBInstanceClassMemoryを使った計算式で決まります。Serverless v2では、このDBInstanceClassMemoryが最大ACU（max capacity）に対応するメモリ量から算出されます。現在のACUは計算に関係しません。

再起動するまで実効値は変わらない

max_connectionsはstaticパラメータです。最大ACUを変更しても、パラメータグループの値を書き換えても、DBインスタンスを再起動するまで実効値は変わりません。変更内容は保留中（pending-reboot）としてキューに積まれるだけです。dynamicパラメータなら再起動なしで反映されますが、max_connectionsは該当しません。

再起動の単位にも注意してください。必要なのはクラスター単位の操作ではなくインスタンス単位の再起動です。ライターだけ再起動してもリーダーの実効値は変わりません。グローバルデータベースで複数リージョンに複数インスタンスがある構成では、各インスタンスを個別に再起動します。

今すぐ確認して対処する3ステップ

障害対応中なら、次の順で進めてください。

まず対象インスタンスのエンドポイントに接続してSHOW max_connections;を実行します。ここで返る値が、今そのpostmasterが持っている上限です。パラメータグループの表示値は判断材料になりません。

次にdescribe-db-instancesでDBParameterGroups[].ParameterApplyStatusを見ます。pending-rebootになっていれば未反映で確定です。

最後にreboot-db-instanceを実行し、起動後にもう一度SHOW max_connections;で新しい値を確認します。複数インスタンスがあるなら、リーダー、フェイルオーバー、旧ライターの順で回すと書き込み停止時間を短くできます。

# 1. 実効値
# psql -h <クラスターエンドポイント> -U <ユーザー名> -d <DB名>
# => SHOW max_connections;

# 2. 保留中かどうか
aws rds describe-db-instances \
  --db-instance-identifier <インスタンス名> \
  --query "DBInstances[].{Id:DBInstanceIdentifier,Status:DBInstanceStatus,PG:DBParameterGroups[0].DBParameterGroupName,Apply:DBParameterGroups[0].ParameterApplyStatus}" \
  --output table

# 3. 再起動
aws rds reboot-db-instance --db-instance-identifier <インスタンス名>

再起動が必要なパラメータかを素早く見分ける

毎回ドキュメントを引くのは非効率です。見分け方を2つ覚えておくと判断が早くなります。

ひとつはAWS側のApplyTypeです。インスタンスパラメータグループならdescribe-db-parameters、クラスターパラメータグループならdescribe-db-cluster-parametersの出力を見ます。ApplyTypeがstaticなら再起動が必要で、dynamicなら不要です。

もうひとつはPostgreSQL側のcontextです。pg_settings.contextがpostmasterのパラメータは共有メモリ構造のサイズ決定に関わるため、プロセス起動時にしか値を確定できません。max_connectionsがまさにその例で、プロセス配列（PGPROC）、スナップショット管理用の領域、軽量ロックや通常ロックのスロット数など、共有メモリの割り当て量をこの値から計算します。ロックテーブルのサイズはmax_locks_per_transaction × (max_connections + max_prepared_transactions)を目安に確保されます。稼働中にmax_connectionsだけ増やすと共有メモリが不足するため、設計上、再起動なしでは変更できない仕組みです。

AWSのstaticとPostgreSQLのcontext = postmasterはおおむね対応します。どちらか一方を確認できれば判断は付きます。

元記事で扱っている内容

• 実効値、パラメータグループ、ACU、pending-rebootを順に見ていく切り分け手順
• 再起動の進め方と、接続数を増やす以外に取れる選択肢
• 現場で見かけるmax_connections関連の誤解を3つ整理した解説
• パラメータ変更時のチェックリストと、再発を防ぐための監視項目
• max_connectionsについてよく寄せられる質問への回答

Aurora Serverless v2のmax_connectionsは最大ACUで決まる