io/aurora_redo_log_flush - Amazon Aurora

io/aurora_redo_log_flush

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

サポート対象エンジンバージョン

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

  • Aurora MySQL バージョン 2

Context

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

注記

Aurora MySQL バージョン 3 では、この待機イベントの名前は io/redo_log_flush です。

待ち時間増加の考えられる原因

データの永続化のために、コミットはストレージが安定するよう耐久性の高い書き込みを要求とします。データベースがコミットを多くし過ぎると、書き込み 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 待機イベントの例

    これは、使用される単純な挿入ステートメントが原因です。

    
                        トップ SQL にステートメントを挿入します

    50,000 レコードは挿入されるまで 3.5 分 かかります。

  • 2 番目の例では、挿入は 1,000 バッチで作成されます。つまり、各接続は 10,000 ではなく 10 のコミットを実行します。Performance Insights は、コネクションがほとんどの時間 io/aurora_redo_log_flush 待機イベントで待っていないことを示しています。

    
                        影響の少ない Performance Insights 待機イベントの例

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

アクション

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

問題のあるセッションとクエリを特定する

DB インスタンスにボトルネックが発生している場合、ユーザーの初期のタスクは、その原因となるセッションとクエリを見つけることになります。便利な AWS データベースブログ記事は Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析 を参照してください。

ボトルネックの原因となっているセッションとクエリを特定するには
  1. AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/) を開きます。

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

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

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

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

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

書き込みオペレーションをグループ化する

次の例は 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 つのコミットにグループ化し、ストレージへの永続的な呼び出しを減らします。

オートコミットをオフにする

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

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;

トランザクションの使用

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

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

バッチを使用する

次の例が示すように、バッチで変更することもできます。ただし、大きすぎるバッチを使用すると、特にリードレプリカやポイントインタイムリカバリ (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;