マルチ AZ DB インスタンスでフェイルオーバー時のログファイルの挙動について

## はじめに
マルチ AZ DB インスタンスでフェイルオーバー発生時にログファイルがどのような挙動を示すのか確認したかったため、調べた内容をこちらに記載しておきます。

## RDS におけるマルチ AZ DB インスタンス
RDS におけるマルチ AZ の構成は、「マルチ AZ DB インスタンス」と「マルチ AZ DB クラスター」の 2 つのパターンが存在します。
![create-multi-az-db-instance2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3480312/8e7395b2-88ce-c62a-b173-12e36851e075.png)
クラスターの方は Aurora 同様にログファイルはインスタンス単位で存在することになると思いますが、「マルチ AZ DB インスタンス」でフェイルオーバーが発生した際に、プライマリーで出力されていたログに追記されるのか、またはログファイルが新たに作成され古いものが見られなくなるのかを確認しました。

## 確認詳細
マルチ AZ DB インスタンスを「general_log」を有効(1)にし、出力先「log_output」を「FILE」にした状態で起動します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3480312/805b2759-99e0-8056-5922-1962b2df54fb.png)
適当なクエリーを実行します。

ログファイルをコンソールからダウンロードして確認してみると、以下のような実行したクエリーについての出力が存在することを確認できました。
```
2023-07-09T00:28:08.687356Z	   12 Query	/* ApplicationName=DBeaver 23.1.1 - SQLEditor <Script-2.sql> */ select * from emp
LIMIT 0, 200
```

次にフェイルオーバー(インスタンスの切り替え)を実施します。※手動で切り替えるのでスイッチオーバーと言った方がよいかもしれないですが。AZ障害の場合はこの切り替えは自動で行われるそうです。マルチ AZ DB インスタンスにおける手動切り替えは、「再起動」のオペレーションから行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3480312/93aaf27f-a8bb-42cc-9c15-371ef5d8f813.png)
イベントには以下のように出力されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3480312/aaca0144-9362-4b13-9f29-d228edd43428.png)
コンソールでも AZ が変わっていることが確認できますね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3480312/556a4d10-4f7f-485f-84a9-309c4e9a5f85.png)
また、ログファイルの一覧も、フェイルオーバー前後の分け隔てなく確認とダウンロードができました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3480312/267201be-cdca-d17e-6ff7-38ef86f0cff1.png)
もちろん、aws cli の describe-db-log-files を使っても同様の情報を確認できます。
```
$ aws rds describe-db-log-files --db-instance-identifier xxxxx-multi-db-instanc-my-8-0-32
{
    "DescribeDBLogFiles": [
        {
            "LogFileName": "error/mysql-error.log",
            "LastWritten": 1688870100498,
            "Size": 0
        },
        {
            "LogFileName": "error/mysql-error-running.log",
            "LastWritten": 1688869198746,
            "Size": 6030
        },
～～中略～～
        {
            "LogFileName": "general/mysql-general.log",
            "LastWritten": 1688870366855,
            "Size": 139573
        },
        {
            "LogFileName": "general/mysql-general.log.2023-07-08.2",
            "LastWritten": 1688781604427,
            "Size": 50087
        },
        {
            "LogFileName": "general/mysql-general.log.2023-07-09.1",
            "LastWritten": 1688864405567,
            "Size": 200914
        },
        {
            "LogFileName": "general/mysql-general.log.2023-07-09.2",
            "LastWritten": 1688868000931,
            "Size": 200963
        },
        {
            "LogFileName": "mysqlUpgrade",
            "LastWritten": 1688780730972,
            "Size": 1013
        }
    ]
}
```
さらにフェイルオーバーのタイミングのログを見てみると、以下のような、再起動時の出力と思われるものが出ていました。
```
2023-07-09T02:10:00.534784Z	    7 Query	flush logs
/rdsdbbin/mysql/bin/mysqld, Version: 8.0.32 (Source distribution). started with:
Tcp port: 3306  Unix socket: /tmp/mysql.sock
```
当然、その後に実行するクエリーも同じログファイルへ出力されるようになることが確認できました。

## マルチ AZ DB インスタンスの仕組みから考えてみると
このログファイルの挙動について、マルチ AZ DB インスタンスの仕組みを改めて考えてみます。以下の記事によると、マルチ AZ DB インスタンスは、EBS のレベルで同期レプリケーションが実現されているようです。ということで、ログファイルも含め、ディスク内容が同じに保たれますので、ログファイルの内容も同じに保たれる(フェイルオーバー後のログにもフェイルオーバー前の内容が含まれている)、ということですね。

https://aws.amazon.com/jp/blogs/news/amazon-rds-under-the-hood-multi-az/

## おわりに
ログファイルは追記されることが確認できました。また、過去に出力されていた古いログファイルも、切り替え後も同じインスタンスIDからダウンロードできることがわかりました。