EventBridge SchedulerでAuroraの定期的な再起動

スケジュール20230811164940.png

次にターゲットの選択を行います。

「すべての API」を選択し、「RDS」で検索をかけます。

ターゲットの選択1_20230811174213.png

「Amazon RDS」を選択し、次はrebootで検索をかけます。

今回はDBインスタンスの再起動になるので「RebootDBInstance」を選択しました。

(「RebootDBCluster」もありますが、aurora-postgresqlではサポートしていないとの事… )

(「RebootDBCluster」もありますが、aurora-postgresqlではサポートしていないとの事… )

以下のように対象DB名を記載しましょう。

ターゲット選択2_20230811181818.png

スケジュール完了後のアクションではNONE、再試行ポリシーとデッドレターキュー (DLQ)はなしとしています。

スケジュール完了後の20230811173327.png

最後にこのイベントルールを動作させる為にIAMロールが必要となります。

まずはIAMポリシーを作成しましょう。

今回はクラスターの再起動を行うので以下で設定しました。

1{2    "Version": "2012-10-17",3    "Statement": [4        {5            "Sid": "VisualEditor0",6            "Effect": "Allow",7            "Action": "rds:RebootDBInstance",8            "Resource": "*"9        }10    ]11}

次にIAMロールを作成します。

EventBridgeで実行できるように信頼されたエンティティで以下のように設定しておきましょう。

エンティティを設定したら、上で作成したポリシー(RDS再起動する権限のやつ)も付与しておきます。

ロール20230811172138.png
1{2    "Version": "2012-10-17",3    "Statement": [4        {5            "Effect": "Allow",6            "Principal": {7                "Service": "scheduler.amazonaws.com"8            },9            "Action": "sts:AssumeRole"10        }11    ]12}

上記、作成したロールを「アクセス許可」で指定し、設定を最終確認後、スケジュールを作成してください。

アクセス許可20230811201012.png
これで設定は完了です!

実際に動作したかはauroraの「ログとイベント」より確認できます。

■Auroraの再起動について

ちなみに、ライターとリーダーで構成されているAuroraの再起動は以下のように動作します。

・ライターを再起動した場合

ライターとリーダーが再起動される

・リーダーを再起動した場合

再起動されるのは選択したリーダーのみ

参考:

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_RebootCluster.html#aurora-reboot-cluster

ライター DB インスタンスを再起動すると、クラスター内の各リーダー DB インスタンスの再起動も開始されます。

これにより、クラスター全体のパラメータの変更がすべての DB インスタンスに同時に適用されます。

ただし、すべての DB インスタンスの再起動により、クラスターのための短時間の停止が発生します。

リーダー DB インスタンスは、ライター DB インスタンスの再起動が完了して利用可能になるまで利用できません。

■最後に

EventBridge Schedulerは導入が簡単であり、様々な動作をスケジュールできます。

もちろんRDS再起動以外でもターゲットAPIは豊富にありますので、色んな使い方を模索してみたいと思います。

この記事を書いた人

aws-recipe-user