io/redo_log_flush - Amazon Aurora

io/redo_log_flush

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

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

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

  • Aurora MySQL バージョン 3

Context

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

注記

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

待機時間が増加する原因の可能性

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

この待機イベントの動作の例については、「io/aurora_redo_log_flush」を参照してください。

アクション

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

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

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/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/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;