Aurora Global Databaseのマイナーバージョンアップとメジャーバージョンアップをやってみた

実際に手を動かしてバージョンアップ手順を確認したい

こんにちは、のんピ(@non____97)です。

皆さんはAurora Global Databaseのマイナーバージョンアップとメジャーバージョンアップをやってみたいなと思ったことはありますか? 私はあります。

それぞれ、以下AWS公式ドキュメントやre:Postに方法が紹介されています。

Aurora PostgreSQLの場合はざっくり以下の通りです。

• マイナーバージョンアップ
  1. セカンダリクラスターのマイナーバージョンアップを行う
  2. プライマリクラスターのマイナーバージョンアップを行う
• メジャーバージョンアップ
  1. 目標復旧時点 (RPO) が設定されている場合は、新しいメジャーバージョンにアップグレードする前に rds.global_db_rpo パラメーターをリセットする
  2. マネジメントコンソールもしくはAWS CLIでメジャーバージョンアップグレードを行う
  3. カスタムパラメータグループを使用する場合は、アップグレード後に手動でリージョンクラスターに適用する

恐らくそのまんまなのでしょうが、思わぬ落とし穴がないか実際に試してみます。

なお、互換性の確認や拡張機能のアップデートといった、Aurora Global Databaseに限らないバージョンアップ時に行う一般的な対応は省略します。

そちらの内容は先述のAWS公式ドキュメントAurora PostgreSQL の PostgreSQL DB エンジンのアップグレードをご覧ください。

いきなりまとめ

• マイナーバージョンアップは必ず全てのセカンダリクラスターから行う
  • マイナーバージョン自動アップグレードを有効化する場合はセカンダリクラスターのメンテナンスウィンドウをプライマリクラスターよりも前にするべき
• マイナーバージョンアップが異なるとスイッチオーバーおよびフェイルオーバーはできない
  • データの同期は継続して行われる
• 手動で個別にメジャーバージョンアップをすることはできない
  • デフォルトのパラメーターグループに変更されるため、必要に応じて再起動を行う
• AWS CDKで後から変更を適用することも可能

検証環境

検証環境は以下の通りです。

検証環境はAWS CDKでデプロイしました。使用したコードは以下の通りです。

デプロイすると、以下のようにAurora Global Databaseが作成されていました。

ちなみに、Global Databaseを選択して変更をクリックすると、14.5と15.2、15.3が選択可能でした。

データの同期がされているか確認します。

プライマリクラスターで適当なテーブルを作成します。

# シークレットの取得
$ get_secrets_value=$(aws secretsmanager get-secret-value \
    --secret-id AuroraSecret7ACECA7F-GpcIOvXusUVh \
    --region us-east-1 \
    | jq -r .SecretString)

# 環境変数に埋め込み
$ export PGHOST=$(echo "${get_secrets_value}" | jq -r .host)
$ export PGPORT=$(echo "${get_secrets_value}" | jq -r .port)
$ export PGDATABASE=$(echo "${get_secrets_value}" | jq -r .dbname)
$ export PGUSER=$(echo "${get_secrets_value}" | jq -r .username)
$ export PGPASSWORD=$(echo "${get_secrets_value}" | jq -r .password)

# プライマリクラスターに接続
$ psql
psql (15.0, server 14.5)
SSL connection (protocol: TLSv1.2, cipher: AES256-GCM-SHA384, compression: off)
Type "help" for help.

# 現在のテーブル一覧
testDB=> \dt
Did not find any relations.

# テーブルの作成
testDB=> CREATE TABLE test (
  id integer,
  name varchar(10)
);
CREATE TABLE

# テーブルが作成されたことを確認
testDB-> \dt
        List of relations
 Schema | Name | Type  |  Owner
--------+------+-------+----------
 public | test | table | postgres
(1 row)

セカンダリクラスターでプライマリクラスター上で作成したテーブルを確認します。

# シークレットの取得
$ get_secrets_value=$(aws secretsmanager get-secret-value \
    --secret-id AuroraSecret7ACECA7F-GpcIOvXusUVh \
    --region us-east-1 \
    | jq -r .SecretString)

# 環境変数に埋め込み
$ export PGHOST='db-cluster.cluster-ro-cy14ft6ffvhw.us-east-2.rds.amazonaws.com'
$ export PGPORT=$(echo "${get_secrets_value}" | jq -r .port)
$ export PGDATABASE=$(echo "${get_secrets_value}" | jq -r .dbname)
$ export PGUSER=$(echo "${get_secrets_value}" | jq -r .username)
$ export PGPASSWORD=$(echo "${get_secrets_value}" | jq -r .password)

$ psql
psql (15.0, server 14.5)
SSL connection (protocol: TLSv1.2, cipher: AES256-GCM-SHA384, compression: off)
Type "help" for help.

testDB=> \dt
        List of relations
 Schema | Name | Type  |  Owner
--------+------+-------+----------
 public | test | table | postgres
(1 row)

テーブルが表示されたので、きちんと同期されていそうですね。

マイナーバージョンアップ

プライマリクラスターのマイナーバージョンアップをしてみる

マイナーバージョンアップから試します。

Aurora Global Databaseでは基本的に同じパッチレベルで同じエンジンバージョンでなければフェイルオーバーできません。

Aurora Global Database のアップグレードは、Aurora DB クラスターのアップグレードと同じ手順に従います。ただし、プロセスを開始する前に注意すべき重要な相違点は次のとおりです。

プライマリとセカンダリの DB クラスターを同じバージョンにアップグレードすることをお勧めします。プライマリ DB クラスターとセカンダリ DB クラスターが同じメジャー、マイナー、パッチレベルのエンジンバージョンである場合にのみ、Aurora グローバルデータベースでマネージドクロスリージョンデータベースフェイルオーバーを実行できます。ただし、パッチレベルはマイナーエンジンバージョンによって異なる場合があります。詳細については、「マネージドクロスリージョンフェイルオーバーに対するパッチレベルの互換性」を参照してください。

. . (中略) . .

マネージドクロスリージョンフェイルオーバーに対するパッチレベルの互換性 Aurora グローバルデータベースを次のマイナーエンジンバージョンのいずれかにアップグレードすると、プライマリおよびセカンダリ DB クラスターのパッチレベルが一致しない場合でも、マネージドクロスリージョンデータベースのフェイルオーバーを実行できます。このリストにあるものよりもマイナーエンジンバージョンが低い場合、マネージドクロスリージョンデータベースフェイルオーバーを実行するには、プライマリ DB クラスターとセカンダリ DB クラスターを同じメジャー、マイナー、パッチレベルにアップグレードする必要があります。次の表のバージョン情報および注意事項を必ず確認してください。

注記

手動による計画外のクロスリージョンフェイルオーバーの場合、ターゲットセカンダリ DB クラスターがプライマリ DB クラスターと同じメジャーおよびマイナーエンジンバージョンを実行している場合に限り、フェイルオーバーオペレーションを実行できます。この場合、パッチレベルが一致する必要はありません。

データベースエンジン	マイナーエンジンバージョン	コメント
Aurora MySQL	マイナーバージョンはありません	すべてのマイナーバージョンで、プライマリ DB クラスターとセカンダリ DB クラスターのパッチレベルが一致する場合のみ、マネージドクロスリージョンデータベースフェイルオーバーを実行できます。
Aurora PostgreSQL	バージョン 14.5 以上 のマイナーバージョン バージョン 13.8 以上 のマイナーバージョン バージョン 12.12 以上 のマイナーバージョン バージョン 11.17 以上 のマイナーバージョン	前の列に記載されているマイナーエンジンバージョンでは、あるパッチレベルのプライマリ DB クラスターから、異なるパッチレベルのセカンダリ DB クラスターへのマネージドクロスリージョンデータベースフェイルオーバーを実行できます。 これより古いマイナーバージョンでは、プライマリ DB クラスターとセカンダリ DB クラスターのパッチレベルが一致する場合のみ、マネージドクロスリージョンデータベースフェイルオーバーを実行できます。

Amazon Aurora Global Database のアップグレード - Amazon Aurora

Aurora PostgreSQLの14.5以上や13.8以上など一部バージョンではパッチレベルは異なっていてもフェイルオーバーできます。裏を返せば必ずマイナーバージョンレベルではバージョンが一致している必要があります。

マイナーバージョンが異なる場合にどのような挙動をするのか気になりますね。

また、マイナーバージョンアップを行う場合は「プライマリクラスターよりも前に全てのセカンダリクラスターをアップグレードすること」と紹介されています。

Aurora Global Database をマイナーアップグレードするときは、プライマリクラスターをアップグレードする前に、すべてのセカンダリクラスターをアップグレードします。

Amazon Aurora Global Database のアップグレード - Amazon Aurora

こちらも、プライマリクラスターからアップグレードした場合の挙動が気になります。

実際にプライマリクラスターのマイナーバージョンを14.5から14.6にアップグレードしてみます。

AWS CDKでDBクラスターのバージョンを１4.6に変更します。

./lib/constructs/aurora.ts

    const dbCluster = new cdk.aws_rds.DatabaseCluster(this, "Default", {
      engine: cdk.aws_rds.DatabaseClusterEngine.auroraPostgres({
        version: cdk.aws_rds.AuroraPostgresEngineVersion.VER_14_6,
      }),
      writer: cdk.aws_rds.ClusterInstance.serverlessV2("Instance", {
        allowMajorVersionUpgrade: false,
        autoMinorVersionUpgrade: true,
        enablePerformanceInsights: true,
        parameterGroup: dbParameterGroup14,
        performanceInsightRetention:
          cdk.aws_rds.PerformanceInsightRetention.DEFAULT,
        publiclyAccessible: false,
        instanceIdentifier: "db-instance",
        caCertificate: cdk.aws_rds.CaCertificate.RDS_CA_RDS4096_G1,
      }),
      serverlessV2MaxCapacity: 1.0,
      serverlessV2MinCapacity: 0.5,
      backup: {
        retention: cdk.Duration.days(7),
        preferredWindow: "16:00-16:30",
      },
      cloudwatchLogsExports: ["postgresql"],
      cloudwatchLogsRetention: cdk.aws_logs.RetentionDays.ONE_YEAR,
      clusterIdentifier: "db-cluster",
      copyTagsToSnapshot: true,
      defaultDatabaseName: "testDB",
      deletionProtection: false,
      iamAuthentication: false,
      monitoringInterval: cdk.Duration.minutes(1),
      monitoringRole,
      parameterGroup: dbClusterParameterGroup14,
      preferredMaintenanceWindow: "Sat:17:00-Sat:17:30",
      storageEncrypted: true,
      storageEncryptionKey: cdk.aws_kms.Alias.fromAliasName(
        this,
        "DefaultRdsKey",
        "alias/aws/rds"
      ),
      vpc: props.vpc,
      securityGroups: [props.dbClusterSg],
      subnetGroup,
    });

diffを確認します。

$ npx cdk diff AuroraStack
Stack AuroraStack
Resources
[~] AWS::RDS::DBCluster Aurora/Default Aurora2CBAB212
 └─ [~] EngineVersion
     ├─ [-] 14.5
     └─ [+] 14.6

こちらでデプロイすると以下のようなエラーが出力されました。

14:47:57 | UPDATE_FAILED        | AWS::RDS::DBCluster                         | Aurora/Default
Resource handler returned message: "Cannot upgrade DB cluster 'db-cluster' to engine version 14.6 as global replica(s) are running lower version. P
lease upgrade global replicas first before upgrading the primary member. (Service: Rds, Status Code: 400, Request ID: ff42852d-9c68-41aa-ab6d-69c45
e7cebd8)" (RequestToken: 4b360b42-3049-6b2e-a28a-1383e480d941, HandlerErrorCode: InvalidRequest)

Aurora Global Databaseのレプリカ(セカンダリクラスター)は14.6よりも低いバージョンであるため、先にレプリカのアップグレードをしろとのことです。

「セカンダリクラスターからマイナーバージョンアップしなければ不具合が発生する」ではなく、セカンダリクラスターからのアップグレードが必須のようです。

AWSマネジメントコンソールからも試してみます。

プライマリクラスターを選択して変更をクリックし、DB エンジンバージョンで14.6を選択します。

はい、同じエラーが出力されました。

セカンダリクラスターのマイナーバージョンアップ

ということで、セカンダリクラスターのマイナーバージョンアップを行いましょう。

上述と同じようにAWS CDKでversion: cdk.aws_rds.AuroraPostgresEngineVersion.VER_14_6としてあげてデプロイします。

$ npx cdk diff AuroraSecondaryStack
Stack AuroraSecondaryStack
Resources
[~] AWS::RDS::DBCluster Aurora/Default Aurora2CBAB212
 └─ [~] EngineVersion
     ├─ [-] 14.5
     └─ [+] 14.6


✨  Number of stacks with differences: 1

$ npx cdk deploy AuroraSecondaryStack

✨  Synthesis time: 7.58s

AuroraSecondaryStack:  start: Building 2fa1f0da2a231bc9f81703a6a13394cfe4baad06db2023da247e70ccec6ecc5c:<AWSアカウントID>-us-east-2
AuroraSecondaryStack:  success: Built 2fa1f0da2a231bc9f81703a6a13394cfe4baad06db2023da247e70ccec6ecc5c:<AWSアカウントID>-us-east-2
AuroraSecondaryStack:  start: Publishing 2fa1f0da2a231bc9f81703a6a13394cfe4baad06db2023da247e70ccec6ecc5c:<AWSアカウントID>-us-east-2
AuroraSecondaryStack:  success: Published 2fa1f0da2a231bc9f81703a6a13394cfe4baad06db2023da247e70ccec6ecc5c:<AWSアカウントID>-us-east-2
AuroraSecondaryStack: deploying... [1/1]
AuroraSecondaryStack: creating CloudFormation changeset...

 ✅  AuroraSecondaryStack

✨  Deployment time: 409.09s

Stack ARN:
arn:aws:cloudformation:us-east-2:<AWSアカウントID>:stack/AuroraSecondaryStack/66d5f6f0-5b4a-11ee-84c1-0254663157f3

✨  Total time: 416.67s

数分でデプロイ完了しました。

セカンダリクラスターに接続してバージョンを確認します。

$ psql
psql (15.0, server 14.6)
SSL connection (protocol: TLSv1.2, cipher: AES256-GCM-SHA384, compression: off)
Type "help" for help.

testDB=> SELECT * FROM VERSION();
                                                   version
-------------------------------------------------------------------------------------------------------------
 PostgreSQL 14.6 on aarch64-unknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 7.5.0, 64-bit
(1 row)

14.6になっていますね。

マイナーバージョンが異なる状態でもデータ同期がされているか確認します。

プライマリクラスターでテーブルに適当にレコードを追加します。

testDB=> SELECT * FROM test;
 id | name
----+------
(0 rows)

testDB=> INSERT INTO test VALUES (1, 'value');
INSERT 0 1

testDB=> SELECT * FROM test;
 id | name
----+-------
  1 | value
(1 row)

セカンダリクラスターでテーブルを参照します。

testDB=> SELECT * FROM test;
 id | name
----+-------
  1 | value
(1 row)

レコードが追加されていたので、マイナバージョンが異なる状態でもデータ同期はされているようですね。

マイナーバージョンが異なる状態でスイッチオーバーとフェイルオーバーをしてみる

次にマイナーバージョンが異なる状態でスイッチオーバーやフェイルオーバーができるか確認してみます。

スイッチオーバー = 計画的なフェイルオーバー で、フェイルオーバー = 計画外のフェイルオーバー です。以下アップデートで名称が変更になりました。

スイッチオーバーから試します。

すると、The target DB cluster specified must be on the same engine version as the source DB cluster.とエラーになりました。

フェイルオーバーでも全く同じエラーが出力されました。エンジンバージョンを同じにする必要があるようですね。

イベントを確認すると、「プライマリクラスターとセカンダリクラスターのエンジンバージョンが異なるためフェイルオーバー機能を無効にした」とメッセージがありました。

プライマリクラスターのマイナーバージョンアップ

プライマリクラスターのマイナーバージョンアップを行います。

セカンダリクラスターと同じくAWS CDKを使ってアップグレードしました。

アップグレード中に気づきましたが、Aurora Global Databaseのエンジンバージョンが一時的に14.514.6となっていました。

10分ほど待ち、アップグレードが完了するとエンジンバージョンが14.6となりました。

スイッチオーバー

マイナーバージョンが揃ったので、スイッチオーバーしてみます。

Aurora Global Databaseのステータスが切り替えに変わりました。

しばらくすると、クライアントからDBへの接続が切れました。

そのまま10分弱ほど待つと、セカンダリクラスターとプライマリクラスターが入れ替わりました。

testDB=> SELECT * FROM aurora_global_db_instance_status();
  server_id  |              session_id              | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec
-------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+------------------------
 db-instance | MASTER_SESSION_ID                    | us-east-2  |   143576716 |                  |                |               |                      |
 db-instance | 91c5f409-dd33-4408-a8a9-ffdc98f6e76b | us-east-1  |   143576707 |        143576716 |              0 |         37026 |            143576704 |                 0
(2 rows)

旧セカンダリクラスターのイベントは以下の通りです。

メジャーバージョンアップ

個別にメジャーバージョンアップをしてみる

メジャーバージョンアップもしてみましょう。

AWS公式ドキュメントには個別にメジャーバージョンアップするのではなく、Aurora Global Databaseのクラスター自体をアップグレードして対応すると記載があります。

Amazon Aurora Global Database のメジャーバージョンアップグレードを実行する場合は、それに含まれる個々のクラスターではなく、グローバルデータベースクラスターをアップグレードします。

Amazon Aurora Global Database のアップグレード - Amazon Aurora

また、以下の文章の書きっぷりからメジャーバージョンアップの場合はプライマリクラスターからアップグレードされるようですね。

Aurora グローバルデータベースクラスターの場合、アップグレードプロセスは Aurora グローバルデータベースを構成するすべての DB クラスターを同時にアップグレードします。これは、それぞれが同じ Aurora PostgreSQL バージョンを実行するようにするためです。また、システムテーブル、データファイル形式などの変更が、すべてのセカンダリクラスターに自動的にレプリケートされます。

Aurora PostgreSQL の PostgreSQL DB エンジンのアップグレード - Amazon Aurora

試しに個別にメジャーバージョンアップができるか確認します。

AWS CDKでバージョンを15.2に指定します。併せてパラメーターグループを15.2のものを指定します。

./lib/constructs/aurora.ts

    // DB Cluster
    const dbCluster = new cdk.aws_rds.DatabaseCluster(this, "Default", {
      engine: cdk.aws_rds.DatabaseClusterEngine.auroraPostgres({
        version: cdk.aws_rds.AuroraPostgresEngineVersion.VER_15_2,
      }),
      writer: cdk.aws_rds.ClusterInstance.serverlessV2("Instance", {
        allowMajorVersionUpgrade: false,
        autoMinorVersionUpgrade: true,
        enablePerformanceInsights: true,
        parameterGroup: dbParameterGroup15,
        performanceInsightRetention:
          cdk.aws_rds.PerformanceInsightRetention.DEFAULT,
        publiclyAccessible: false,
        instanceIdentifier: "db-instance",
        caCertificate: cdk.aws_rds.CaCertificate.RDS_CA_RDS4096_G1,
      }),
      serverlessV2MaxCapacity: 1.0,
      serverlessV2MinCapacity: 0.5,
      backup: {
        retention: cdk.Duration.days(7),
        preferredWindow: "16:00-16:30",
      },
      cloudwatchLogsExports: ["postgresql"],
      cloudwatchLogsRetention: cdk.aws_logs.RetentionDays.ONE_YEAR,
      clusterIdentifier: "db-cluster",
      copyTagsToSnapshot: true,
      defaultDatabaseName: "testDB",
      deletionProtection: false,
      iamAuthentication: false,
      monitoringInterval: cdk.Duration.minutes(1),
      monitoringRole,
      parameterGroup: dbClusterParameterGroup15,
      preferredMaintenanceWindow: "Sat:17:00-Sat:17:30",
      storageEncrypted: true,
      storageEncryptionKey: cdk.aws_kms.Alias.fromAliasName(
        this,
        "DefaultRdsKey",
        "alias/aws/rds"
      ),
      vpc: props.vpc,
      securityGroups: [props.dbClusterSg],
      subnetGroup,
    });

デプロイします。

$ npx cdk diff AuroraStack
Stack AuroraStack
Resources
[-] AWS::RDS::DBClusterParameterGroup Aurora/DbClusterParameterGroup14 AuroraDbClusterParameterGroup145F7E6F5D destroy
[-] AWS::RDS::DBParameterGroup Aurora/DbParameterGroup14 AuroraDbParameterGroup146D0E289A destroy
[~] AWS::RDS::DBCluster Aurora/Default Aurora2CBAB212
 ├─ [~] DBClusterParameterGroupName
 │   └─ [~] .Ref:
 │       ├─ [-] AuroraDbClusterParameterGroup145F7E6F5D
 │       └─ [+] AuroraDbClusterParameterGroup150C75B72F
 └─ [~] EngineVersion
     ├─ [-] 14.6
     └─ [+] 15.2
[~] AWS::RDS::DBInstance Aurora/Default/Instance AuroraInstance6F9B6C0C may be replaced
 └─ [~] DBParameterGroupName (may cause replacement)
     └─ [~] .Ref:
         ├─ [-] AuroraDbParameterGroup146D0E289A
         └─ [+] AuroraDbParameterGroup158895769D


✨  Number of stacks with differences: 1

$ npx cdk deploy AuroraStack

✨  Synthesis time: 7.22s

AuroraStack:  start: Building d7578814d56d40bc3891c2ccd49a83dc7a51513106100ab2681e7ffa072813e8:<AWSアカウントID>-us-east-1
AuroraStack:  success: Built d7578814d56d40bc3891c2ccd49a83dc7a51513106100ab2681e7ffa072813e8:<AWSアカウントID>-us-east-1
AuroraStack:  start: Publishing d7578814d56d40bc3891c2ccd49a83dc7a51513106100ab2681e7ffa072813e8:<AWSアカウントID>-us-east-1
AuroraStack:  success: Published d7578814d56d40bc3891c2ccd49a83dc7a51513106100ab2681e7ffa072813e8:<AWSアカウントID>-us-east-1
AuroraStack: deploying... [1/1]
AuroraStack: creating CloudFormation changeset...
15:58:58 | UPDATE_FAILED        | AWS::RDS::DBCluster                         | Aurora2CBAB212
Resource handler returned message: "Major Version Upgrade isn't supported in a single member of a global cluster. Use ModifyGlobalCluster to upgrad
e all the members. (Service: Rds, Status Code: 400, Request ID: 3015e353-f443-4909-82b0-7d1cbaaa4401)" (RequestToken: 3ed74a1f-db85-9c96-e25c-f3fab
f7c6038, HandlerErrorCode: InvalidRequest)

Aurora Global Databaseに属するクラスターは個別にメジャーバージョンアップできないと怒られました。

Aurora Global Databaseのグローバルクラスター単位でメジャーバージョンアップ

公式に従ってAurora Global Databaseのグローバルクラスター単位でメジャーバージョンアップをします。

グローバルクラスターを選択して変更をクリックして、エンジンバージョンで15.2を選択します。

DBクラスターパラメーターグループおよびDBパラメーターグループはどちらも設定変更できませんでした。

公式ドキュメントグループを確認すると、メジャーバージョンアップ中はカスタムパラメーターグループは使用できないと記載がありました。

現在、Aurora Global Database のアップグレードには以下の制限があります。

• Aurora グローバルデータベースのメジャーバージョンアップグレードを実行している間、グローバルデータベースクラスターにカスタムパラメータグループを適用できません。グローバルクラスターの各リージョンにカスタムパラメータグループを作成し、アップグレード後に手動でリージョンクラスターに適用します。
• Aurora MySQL に基づく Aurora グローバルデータベースでは、lower_case_table_names パラメータがオンの場合、Aurora MySQL バージョン 2 からバージョン 3 へのインプレースアップグレードを実行できません。使用できる方法の詳細については、「メジャーバージョンのアップグレード」を参照してください。
• Aurora PostgreSQL に基づく Aurora グローバルデータベースでは、目標復旧時点 (RPO) 機能がオンになっている場合、Aurora DB エンジンのメジャーバージョンアップグレードを実行できません。RPO 機能については、「Aurora PostgreSQL- ベースのグローバルデータベースの RPO (目標復旧時点) 管理」を参照してください。
• Aurora MySQL に基づく Aurora グローバルデータベースでは、標準プロセスを使用して、バージョン 3.01 または 3.02 から 3.03 以降へのマイナーバージョンアップグレードを実行できません。使用するプロセスの詳細については、「エンジンのバージョンを変更して Aurora MySQL アップグレードする」を参照してください。

Amazon Aurora Global Database の使用 - Amazon Aurora

ということで仕様です。

設定変更内容を確認してグローバルデータベースの変更をクリックします。このアップグレードは非同期的に即時適用されます。保留中の変更でクラスターの再起動が必要な場合、このアップグレードによって予期しないダウンタイムが発生する可能性があります。次のメンテナンスウィンドウで変更をスケジュールするには、DB クラスターまたは DB インスタンスを個別に変更します。とありますが、メンテナンスウィンドウで適用するオプションは見当たりませんでした。

旧セカンダリクラスター = 現プライマリクラスターからメジャーアップグレードが始まりました。

しばらくするとプライマリクラスターのメジャーバージョンアップが完了し、セカンダリクラスターのメジャーバージョンアップが開始しました。エンジンバージョンを確認すると14.615.2となっていますね。

プライマリクラスターへの接続が切れていたので、再接続するとPostgreSQL 15.2にアップグレードされていることが確認できました。

$ psql
psql (15.0, server 15.2)
SSL connection (protocol: TLSv1.2, cipher: AES128-SHA256, compression: off)
Type "help" for help.

testDB=> SELECT * FROM VERSION();
                                                   version
-------------------------------------------------------------------------------------------------------------
 PostgreSQL 15.2 on aarch64-unknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 9.5.0, 64-bit
(1 row)

testDB=> SELECT * FROM aurora_global_db_instance_status();
  server_id  |    session_id     | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_m
sec
-------------+-------------------+------------+-------------+------------------+----------------+---------------+----------------------+--------------------
----
 db-instance | MASTER_SESSION_ID | us-east-2  |   352637429 |                  |                |               |                      |

(1 row)

メジャーバージョンアップ開始をしてから30分程度で完了しました。

セカンダリクラスターについてもPostgreSQL 15.2にアップグレードされたことが分かります。

testDB-> \dt
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
SSL SYSCALL error: EOF detected
The connection to the server was lost. Attempting reset:
Succeeded.
psql (15.0, server 15.2)
SSL connection (protocol: TLSv1.2, cipher: AES128-SHA256, compression: off)
testDB->
testDB->
testDB-> SELECT * FROM VERSION();
ERROR:  syntax error at or near "psql"
LINE 1: psql
        ^
testDB=>
testDB=> SELECT * FROM VERSION();
                                                   version
-------------------------------------------------------------------------------------------------------------
 PostgreSQL 15.2 on aarch64-unknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 9.5.0, 64-bit
(1 row)

testDB=>
testDB=> SELECT * FROM aurora_global_db_instance_status();
  server_id  |              session_id              | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn |
visibility_lag_in_msec
-------------+--------------------------------------+------------+-------------+------------------+----------------+---------------+----------------------+-
-----------------------
 db-instance | MASTER_SESSION_ID                    | us-east-2  |   353035703 |                  |                |               |                      |

 db-instance | 6cd5d58f-a94d-4db2-92ea-3d939dcdba5d | us-east-1  |   353035691 |        353035700 |              0 |         53658 |            353035691 |
                    37
(2 rows)

プライマリクラスターのイベントは以下の通りで、何回か停止や再起動をしていたことが分かります。

また、イベントに記録されている通り、DBクラスターのアップグレードが走る前にpreupgrade-db-cluster-14-6-to-15-2-2023-09-25-07-05というスナップショットを取得していました。

セカンダリクラスターのイベントは以下の通りです。

Upgrade in progress: Upgrading readers.の時間がプライマリクラスターのイベントで記録されていたUpgrade in progress: Upgrading writer.よりも10分ほど後であることからプライマリクラスターのメジャーバージョンアップをしてからセカンダリクラスターのメジャーバージョンアップが走ることが分かります。

メジャーバージョンアップ後Global Databaseの変更を確認すると、15.2のみ選択できるようになっていました。

AWS CDKでメジャーバージョンアップ後のパラメーターグループを適用

DBインスタンスのパラメーターグループを確認するとDBクラスターパラメーターグループ、DBインスタンスパラメーターグループどちらもデフォルトのものが使用されていました。

AWS CDKでカスタムパラメーターグループを適用できるか試してみます。

./lib/constructs/aurora.ts

    // DB Cluster
    const dbCluster = new cdk.aws_rds.DatabaseCluster(this, "Default", {
      engine: cdk.aws_rds.DatabaseClusterEngine.auroraPostgres({
        version: cdk.aws_rds.AuroraPostgresEngineVersion.VER_15_2,
      }),
      writer: cdk.aws_rds.ClusterInstance.serverlessV2("Instance", {
        allowMajorVersionUpgrade: false,
        autoMinorVersionUpgrade: true,
        enablePerformanceInsights: true,
        parameterGroup: dbParameterGroup15,
        performanceInsightRetention:
          cdk.aws_rds.PerformanceInsightRetention.DEFAULT,
        publiclyAccessible: false,
        instanceIdentifier: "db-instance",
        caCertificate: cdk.aws_rds.CaCertificate.RDS_CA_RDS4096_G1,
      }),
      serverlessV2MaxCapacity: 1.0,
      serverlessV2MinCapacity: 0.5,
      backup: {
        retention: cdk.Duration.days(7),
        preferredWindow: "16:00-16:30",
      },
      cloudwatchLogsExports: ["postgresql"],
      cloudwatchLogsRetention: cdk.aws_logs.RetentionDays.ONE_YEAR,
      clusterIdentifier: "db-cluster",
      copyTagsToSnapshot: true,
      defaultDatabaseName: "testDB",
      deletionProtection: false,
      iamAuthentication: false,
      monitoringInterval: cdk.Duration.minutes(1),
      monitoringRole,
      parameterGroup: dbClusterParameterGroup15,
      preferredMaintenanceWindow: "Sat:17:00-Sat:17:30",
      storageEncrypted: true,
      storageEncryptionKey: cdk.aws_kms.Alias.fromAliasName(
        this,
        "DefaultRdsKey",
        "alias/aws/rds"
      ),
      vpc: props.vpc,
      securityGroups: [props.dbClusterSg],
      subnetGroup,
    });

デプロイします。

$ npx cdk diff AuroraSecondaryStack
Stack AuroraSecondaryStack
Resources
[-] AWS::RDS::DBClusterParameterGroup Aurora/DbClusterParameterGroup14 AuroraDbClusterParameterGroup145F7E6F5D destroy
[-] AWS::RDS::DBParameterGroup Aurora/DbParameterGroup14 AuroraDbParameterGroup146D0E289A destroy
[~] AWS::RDS::DBCluster Aurora/Default Aurora2CBAB212
 ├─ [~] DBClusterParameterGroupName
 │   └─ [~] .Ref:
 │       ├─ [-] AuroraDbClusterParameterGroup145F7E6F5D
 │       └─ [+] AuroraDbClusterParameterGroup150C75B72F
 └─ [~] EngineVersion
     ├─ [-] 14.6
     └─ [+] 15.2
[~] AWS::RDS::DBInstance Aurora/Default/Instance AuroraInstance6F9B6C0C may be replaced
 └─ [~] DBParameterGroupName (may cause replacement)
     └─ [~] .Ref:
         ├─ [-] AuroraDbParameterGroup146D0E289A
         └─ [+] AuroraDbParameterGroup158895769D


✨  Number of stacks with differences: 1

$ npx cdk deploy AuroraSecondaryStack

✨  Synthesis time: 8.86s

AuroraSecondaryStack: deploying... [1/1]
AuroraSecondaryStack: creating CloudFormation changeset...

 ✅  AuroraSecondaryStack

✨  Deployment time: 99.37s

Stack ARN:
arn:aws:cloudformation:us-east-2:<AWSアカウントID>:stack/AuroraSecondaryStack/66d5f6f0-5b4a-11ee-84c1-0254663157f3

✨  Total time: 108.23s

すんなりデプロイできました。

適用されたか確認すると、どちらのパラメーターグループも適用されていますが、DBクラスターパラメーターグループは同期中ではなく再起動を保留中になっていました。

これはパラメーターグループで設定したパラメーターにStaticが含まれるためです。

• 静的パラメータを変更して DB パラメータグループを保存すると、パラメータの変更は関連付けられている DB インスタンスを手動で再起動した後に有効になります。静的パラメータの場合、コンソールは常に ApplyMethod として pending-reboot を使用します。
• 動的パラメータを変更すると、デフォルトでは、パラメータの変更は直ちに有効になり、再起動は不要です。AWS Management Console を使用して DB インスタンスのパラメータ値を変更するときには、常に動的パラメータ向けの ApplyMethod として immediate を使用します。パラメータの変更を、関連付けられている DB インスタンスが再起動されるまで延期するには、AWS CLI または RDS API を使用します。パラメータを変更する場合は、ApplyMethod を pending-reboot に設定します。

パラメータグループの概要 - Amazon Relational Database Service

デフォルトのパラメーターとの比較は以下の通りです。この内、shared_preload_librariesがStaticです。

再起動前にこちらのパラメーターが適用されていないことを確認します。

$ psql
psql (15.0, server 15.2)
SSL connection (protocol: TLSv1.2, cipher: AES256-GCM-SHA384, compression: off)
Type "help" for help.

testDB=> SHOW shared_preload_libraries;
  shared_preload_libraries
-----------------------------
 rdsutils,pg_stat_statements
(1 row)

shared_preload_librariesで指定したpgauditが存在していませんね。一方ssl_ciphersは指定した通りAES256-GCM-SHA384で接続していることが分かります。

再起動してあげます。

再起動後DBクラスターパラメーターグループの適用状況を確認すると、同期中に変わっていました。

shared_preload_librariesを確認すると、pgauditが設定されていました。

testDB=> SHOW shared_preload_libraries;
SSL SYSCALL error: EOF detected
The connection to the server was lost. Attempting reset: Succeeded.
psql (15.0, server 15.2)
SSL connection (protocol: TLSv1.2, cipher: AES256-GCM-SHA384, compression: off)
testDB=>
testDB=> SHOW shared_preload_libraries;
 shared_preload_libraries
--------------------------
 rdsutils,pgaudit
(1 row)

DBパラメーターグループの設定内容に応じて再起動を行うと良いでしょう。

AWS公式ドキュメントの通り対応すればOK

Aurora Global Databaseのマイナーバージョンアップとメジャーバージョンアップをやってみました。

AWS公式ドキュメントを信じて対応すれば大丈夫そうですね。

実際にメジャーバージョンアップを行う場合は、以下AWS公式ドキュメントに従って慎重に行うことをお勧めします。

メジャーバージョンのアップグレードには、以前のバージョンのデータベースと下位互換性のないデータベースの変更が含まれる可能性があります。新しいバージョンの新機能により、既存のアプリケーションが適切に動作しなくなることがあります。問題を回避するため、Amazon Aurora では、メジャーバージョンアップグレードは自動的に適用されません。むしろ、次の手順を実行して、メジャーバージョンのアップグレードを慎重に計画することをお勧めします。

1. 使用可能なターゲットのリストから必要なメジャーバージョンを、テーブル内のバージョンにリストされているターゲットから選択します。AWS CLI を使うことにより現在のバージョンの AWS リージョン で利用可能なバージョンの正確なリストを入手できます。詳細については、「AWS リージョン で使用可能なバージョンのリストを取得します。」を参照してください。
2. 新しいバージョンのトライアルデプロイで、アプリケーションが正常に動作することを確認します。完全なプロセスの詳細については、「本番稼働用の DB クラスターの新しいメジャーバージョンへのアップグレードをテストする」を参照してください。
3. トライアルデプロイでアプリケーションが正常に動作することを確認したら、クラスターをアップグレードできます。詳細については、「Aurora PostgreSQL エンジンを新しいメジャーバージョンにアップグレードする」を参照してください。

Aurora PostgreSQL の PostgreSQL DB エンジンのアップグレード - Amazon Aurora

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!