はじめに
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)のアーカイブを保存することができる機能の新規追加によって、そのアーカイブファイルを保存する場所を指定するパラメーターとして追加されています。
パラメータ―は動的に設定可能であり、以下のようなフォーマットで値を指定します。
|
1 |
innodb_redo_log_archive_dirs='【ラベル名】:【保存先ディレクトリ名】[;【ラベル名】:【保存先ディレクトリ名】;...]'; |
また、保存先ディレクトリ名の指定には以下のような制約があります。
自動でディレクトリの生成はおこなわれないため、あらかじめディレクトリを作成しておきます。後述するサブディレクトリも指定する場合は、そのディレクトリも作成します。
|
1 2 |
# mkdir /directory_path1 # chown mysql:mysql /directory_path1 |
作成されていない場合は、以下のエラーが出力されます。
|
1 |
ERROR 3844 (HY000): Redo log archive directory 'directory_path1' does not exist or is not a directory |
セキュリティ上の問題から、ディレクトリに対してその他のユーザーにアクセス権限があると以下のエラーが出力されます。
|
1 |
ERROR 3846 (HY000): Redo log archive directory 'directory_path1' is accessible to all OS users |
回避するには、保存先ディレクトリの権限をたとえば以下のように設定してください。
|
1 2 3 |
# chmod 750 /directory_path1 # ls -ld /directory_path1 drwxr-x--- 2 mysql mysql 6 8月 21 17:18 /directory_path1 |
保存先ディレクトリ名には、既に MySQL で使用しているディレクトリと同じ範囲を含んでいた場合、以下のエラーが出力されます。
|
1 |
ERROR 3845 (HY000): Redo log archive directory 'directory_path1' is in, under, or over server directory 'datadir' - '/path/to/data_directory' |
このとき、たとえば datadir に /var/lib/mysql を指定していた場合、/var/lib/data/directory_path1 だけでなく、 /var/lib や /var を指定してもエラーとなってしまいます。
なお、上記の制約は変数の指定(や MySQL の再起動)時点ではエラーにならず、実際に Redo ログのアーカイブを取得する際に初めてエラーが発生するため、注意する必要があります。
主なユースケース
今までは、オンライン物理バックアップ(MySQL Enterprise Backup など)の取得時に大きな更新処理などが実行された場合、バックアップ中に Redo ログがローテーションしてしまうと、Redo ログファイルが一貫した状態で保存できなくなるため、以下のようなエラーが出力されていました。
|
1 2 3 4 5 6 7 |
190826 17:35:31 RLR1 ERROR: Redo log was overwritten. To solve this problem either: 1) re-run the backup when the database has less load, or 2) re-configure the database with bigger InnoDB log files. 190826 17:35:31 RLR1 INFO: Rethrowing the exception. 190826 17:35:31 RLR1 INFO: Requesting completion of redo log copy. Rapid: 1 (...) |
今回追加された Redo Log Archiving によって、この問題は解消され、バックアップ取得時にエラーが発生してバックアップが取得できなくなるリスクを低減することが可能になります。
手動実行
また、この Redo ログのアーカイブ機能は、以下のコマンドで手動で取得開始および停止することが可能です。
※ただし、取得した Redo ログのアーカイブ単体を何かに利用できるツールは MySQL 8.0.17 リリース時点では存在していないため、基本的に手動で取得する意味はありません。
- 取得開始コマンド
|
1 2 3 4 5 6 |
mysql> SELECT innodb_redo_log_archive_start('【ラベル名】'[, '【サブディレクトリ名】']); +------------------------------------------+ | innodb_redo_log_archive_start('label') | +------------------------------------------+ | 0 | +------------------------------------------+ |
DO 構文でも実行可能です。また、サブディレクトリ名を指定しない場合は、innodb_redo_log_archive_dirs で指定した保存先ディレクトリの配下に出力されます。
なお、上記コマンドを実行するためには INNODB_REDO_LOG_ARCHIVE 権限が必要となります。
- 取得停止コマンド
|
1 2 3 4 5 6 |
mysql> SELECT innodb_redo_log_archive_stop(); +--------------------------------+ | innodb_redo_log_archive_stop() | +--------------------------------+ | 0 | +--------------------------------+ |
上記コマンドを実行することで、Redo ログのアーカイブが保存されます。なお、innodb_redo_log_archive_stop() を実行しないでセッションを閉じてしまった場合、Redo ログのアーカイブは暗黙的に削除されてしまうので注意が必要です。
総括
実際に MySQL Enterprise Backupを使用して Redo ログのアーカイブ取得試験をおこなったところ、一般クエリログにおいて、以下のように Redo ログのアーカイブが実行されている様子が確認できました。
|
1 2 3 4 5 |
2019-08-21T21:18:28.825052Z 15 Query DO innodb_redo_log_archive_start('label1','15664223085978217') (...) 2019-08-21T21:18:40.304693Z 15 Query SHOW ENGINE INNODB STATUS 2019-08-21T21:18:40.310016Z 15 Query DO innodb_redo_log_archive_stop() 2019-08-21T21:18:40.511078Z 16 Query UNLOCK INSTANCE |
なお、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 XtraBackup や MariaDB Enterprise Backup ではまだ使用することができない点には注意してください。
この他にも、MySQL 8.0.17 で様々な機能が一挙に追加されてきているので、これを機に MySQL8.0 の検証を是非進めてみてはいかがでしょうか。
参考
- Changes in MySQL 8.0.17 (2019-07-22, General Availability)
- Chapter 3 What’s New in MySQL Enterprise Backup 8.0?
- 15.6.5 Redo Log
