スマートスタイル TECH BLOG|データベース&クラウドの最新技術情報を配信

MySQL8.0.17 新機能紹介:Redo ログのアーカイブについて

はじめに

MySQL 8.0.17 が 2019 年 7 月 22 日にリリースし、様々な機能が追加されています。そんな中、今回は新しく追加されたシステム変数である innodb_redo_log_archive_dirs について紹介します。
 

内容

innodb_redo_log_archive_dirs 概要

参考 : 15.13 InnoDB Startup Options and System Variables

Defines labeled directories where redo log archive files can be created. You can define multiple labeled directories in a semicolon-separated list.

MySQL 8.0.17 から、Redo ログ(一般的には ib_logfile0 や ib_logfile1)のアーカイブを保存することができる機能の新規追加によって、そのアーカイブファイルを保存する場所を指定するパラメーターとして追加されています。

パラメータ―は動的に設定可能であり、以下のようなフォーマットで値を指定します。

また、保存先ディレクトリ名の指定には以下のような制約があります。

  • 保存先ディレクトリが存在している必要があります
  • 自動でディレクトリの生成はおこなわれないため、あらかじめディレクトリを作成しておきます。後述するサブディレクトリも指定する場合は、そのディレクトリも作成します。

    作成されていない場合は、以下のエラーが出力されます。

  • 保存先ディレクトリにその他のユーザーへのアクセス権限を付与してはいけません
  • セキュリティ上の問題から、ディレクトリに対してその他のユーザーにアクセス権限があると以下のエラーが出力されます。

    回避するには、保存先ディレクトリの権限をたとえば以下のように設定してください。

  • 他のシステム変数(datadir,secure_file_priv など)で指定しているディレクトリ、あるいはその親ディレクトリやサブディレクトリを指定することはできません
  • 保存先ディレクトリ名には、既に MySQL で使用しているディレクトリと同じ範囲を含んでいた場合、以下のエラーが出力されます。

    このとき、たとえば datadir/var/lib/mysql を指定していた場合、/var/lib/data/directory_path1 だけでなく、 /var/lib/var を指定してもエラーとなってしまいます。

    なお、上記の制約は変数の指定(や MySQL の再起動)時点ではエラーにならず、実際に Redo ログのアーカイブを取得する際に初めてエラーが発生するため、注意する必要があります。
     

    主なユースケース

    今までは、オンライン物理バックアップ(MySQL Enterprise Backup など)の取得時に大きな更新処理などが実行された場合、バックアップ中に Redo ログがローテーションしてしまうと、Redo ログファイルが一貫した状態で保存できなくなるため、以下のようなエラーが出力されていました。

    今回追加された Redo Log Archiving によって、この問題は解消され、バックアップ取得時にエラーが発生してバックアップが取得できなくなるリスクを低減することが可能になります。
     

    手動実行

    また、この Redo ログのアーカイブ機能は、以下のコマンドで手動で取得開始および停止することが可能です。

    ※ただし、取得した Redo ログのアーカイブ単体を何かに利用できるツールは MySQL 8.0.17 リリース時点では存在していないため、基本的に手動で取得する意味はありません。

    • 取得開始コマンド

    DO 構文でも実行可能です。また、サブディレクトリ名を指定しない場合は、innodb_redo_log_archive_dirs で指定した保存先ディレクトリの配下に出力されます。
    なお、上記コマンドを実行するためには INNODB_REDO_LOG_ARCHIVE 権限が必要となります。

    • 取得停止コマンド

    上記コマンドを実行することで、Redo ログのアーカイブが保存されます。なお、innodb_redo_log_archive_stop() を実行しないでセッションを閉じてしまった場合、Redo ログのアーカイブは暗黙的に削除されてしまうので注意が必要です。
     

    総括

    実際に MySQL Enterprise Backupを使用して Redo ログのアーカイブ取得試験をおこなったところ、一般クエリログにおいて、以下のように Redo ログのアーカイブが実行されている様子が確認できました。

    なお、MySQL 5.7 においては ERROR: Redo log was overwritten と表示されてしまったケースで、MySQL8.0.17 で Redo ログのアーカイブを無効(–no-redo-log-archive )にした状態でも、エラーが発生しないことがありました。

    これは、MySQL 8.0 から、 FLUSH TABLE WITH READ LOCK の代わりに LOCK INSTANCE FOR BACKUP が使用されるようになったため、バックアップ取得時のロック時間が短縮した結果 、必要な Redo ログ量も減ったことが理由として考えられます。

    参考: Chapter 3 What’s New in MySQL Enterprise Backup 8.0?

    For MySQL Enterprise Backup 8.0.16 and later:

    i. Near the end of the backup process, instead of locking the whole server instance for a brief period of time, mysqlbackup now applies these locks consecutively:

    ii. A backup lock on the server instance, which blocks DDLs (except those on user-created temporary tables), but not DMLs on InnoDB tables.

    iii. A FLUSH TABLES tbl_name [, tbl_name] … WITH READ LOCK operation on all non-InnoDB tables, for copying the relevant ones among them into the backup. This step is skipped if no user created non-InnoDB tables exist.

     

    まとめ

    Redo ログのアーカイブ機能によって、バックアップ実行中に更新負荷の高い処理が実行されていたり、Redo ログの格納ストレージに比べてバックアップ用のストレージの性能が低い(= Redo ログのローテーションまでにバックアップが終わらない)場合にも、バックアップを取得しやすくなることが期待できます。
    ただし、現時点でこの機能に対応しているのは MySQL Enterprise Backup のみであるため、Percona XtraBackupMariaDB Enterprise Backup ではまだ使用することができない点には注意してください。

    この他にも、MySQL 8.0.17 で様々な機能が一挙に追加されてきているので、これを機に MySQL8.0 の検証を是非進めてみてはいかがでしょうか。

    参考

    MySQL
    Return Top