# io/aurora\_redo\_log\_flush
<a name="ams-waits.io-auredologflush"></a>

`io/aurora_redo_log_flush` イベントは、セッションが永続データを Amazon Aurora ストレージに書き込むときに発生します。

**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.io-auredologflush.context.supported)
+ [Context](#ams-waits.io-auredologflush.context)
+ [待機時間が増加する原因の可能性](#ams-waits.io-auredologflush.causes)
+ [アクション](#ams-waits.io-auredologflush.actions)

## サポート対象エンジンバージョン
<a name="ams-waits.io-auredologflush.context.supported"></a>

この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2

## Context
<a name="ams-waits.io-auredologflush.context"></a>

`io/aurora_redo_log_flush` イベントは Aurora MySQL の書き込み入力/出力 (I/O) オペレーション用です。

**注記**  
Aurora MySQL バージョン 3 では、この待機イベントの名前は [io/redo\_log\_flush](ams-waits.io-redologflush.md) です。

## 待機時間が増加する原因の可能性
<a name="ams-waits.io-auredologflush.causes"></a>

データの永続化のために、コミットはストレージが安定するよう耐久性の高い書き込みを要求とします。データベースがコミットを多くし過ぎると、書き込み I/O オペレーションで待機イベントが発生します、`io/aurora_redo_log_flush` 待機イベント。

次の例では、db.r5.xlarge DB インスタンスクラスを使用して、50,000 レコードが Aurora MySQL DB クラスターに挿入されています。
+ 初期の例では、各セッションは行ごとに 10,000 レコードを挿入しています。デフォルトで、データ操作言語 (DML) コマンドがトランザクション内にない場合、Aurora MySQL は暗黙的なコミットを使用します。オートコミットがオンになっています。これは、各行の挿入に対してコミットがあることを意味します。Performance Insights は、コネクションがほとんどの時間`io/aurora_redo_log_flush` 待機イベントで待っていることを示しています。  
![Performance Insights 待機イベントの例](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)

  これは、使用される単純な挿入ステートメントが原因です。  
![トップ SQL にステートメントを挿入します](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)

  50,000 レコードは挿入されるまで 3.5 分 かかります。
+ 2 番目の例では、挿入は 1,000 バッチで作成されます。つまり、各接続は 10,000 ではなく 10 のコミットを実行します。Performance Insights は、コネクションがほとんどの時間 `io/aurora_redo_log_flush` 待機イベントで待っていないことを示しています。  
![影響の少ない Performance Insights 待機イベントの例](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)

  50,000 レコードが挿入されるまでに 4 秒かかります。

## アクション
<a name="ams-waits.io-auredologflush.actions"></a>

待機イベントの原因に応じて、異なるアクションをお勧めします。

**Topics**
+ [問題のあるセッションとクエリを特定する](#ams-waits.io-auredologflush.actions.identify-queries)
+ [書き込みオペレーションをグループ化する](#ams-waits.io-auredologflush.actions.action0)
+ [オートコミットをオフにする](#ams-waits.io-auredologflush.actions.action1)
+ [トランザクションの使用](#ams-waits.io-auredologflush.action2)
+ [バッチを使用する](#ams-waits.io-auredologflush.action3)

### 問題のあるセッションとクエリを特定する
<a name="ams-waits.io-auredologflush.actions.identify-queries"></a>

DB インスタンスにボトルネックが発生している場合、ユーザーの初期のタスクは、その原因となるセッションとクエリを見つけることになります。便利な AWS データベースブログ記事は [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。

**ボトルネックの原因となっているセッションとクエリを特定するには**

1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。

1. ナビゲーションペインで、[**Performance Insights**] を選択します。

1. DB インスタンスを選択します。

1. **データベース負荷**で、**待機でスライス**を選択します。

1. ページの下部で **トップ SQL** を選択します。

   リストの上部にあるクエリは、データベースで最大の負荷を引き起こしています。

### 書き込みオペレーションをグループ化する
<a name="ams-waits.io-auredologflush.actions.action0"></a>

次の例は `io/aurora_redo_log_flush` 待機イベントをトリガーしています。(オートコミットがオンになっています。)

```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');

UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;

DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```

`io/aurora_redo_log_flush` 待機イベントで待機する時間を減らすため、書き込み操作を論理的に 1 つのコミットにグループ化し、ストレージへの永続的な呼び出しを減らします。

### オートコミットをオフにする
<a name="ams-waits.io-auredologflush.actions.action1"></a>

次の例に示すように、トランザクション内に存在しない大きな変更を加える前に、オートコミットをオフにします。

```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;

SET SESSION AUTOCOMMIT=ON;
```

### トランザクションの使用
<a name="ams-waits.io-auredologflush.action2"></a>

次の例が示すように、トランサクションを使用することができます。

```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');

DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;

-- Other DML statements here
END
```

### バッチを使用する
<a name="ams-waits.io-auredologflush.action3"></a>

次の例が示すように、バッチで変更することもできます。ただし、大きすぎるバッチを使用すると、特にリードレプリカやポイントインタイムリカバリ (PITR) の実行時にパフォーマンスの問題が発生する可能性があります。

```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');

UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;

DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1<xx;
```