導讀
MySQL 8.0.17開始支援的redo log歸檔能幹嘛用呢，好吃嗎
今天，MySQL 8.0.17釋出了，看了下release note，發現果真如之前預期的那樣，恢複了redo log歸檔（redo log archiving）功能。之是以說是“恢複”，那是因為在InnoDB非常古老的版本（MySQL 4.0.6之前的版本）才存在，之後就取消了，當時還支援redo log mirror，老一點的MySQL DBA可能都還有印象，不過這兩個功能當時沒什麼卵用，是以取消了。
此次，InnoDB重新開機redo log歸檔功能，按照開發團隊的說法，主要是為了解決備份一緻性的問題。文檔裡是這麼寫的：
Backup utilities that copy redo log records may sometimes fail to keep pace
with redo log generation while a backup operation is in progress, resulting
in lost redo log records due to those records being overwritten. The redo
log archiving feature addresses this issue by sequentially writing redo log
records to an archive file. Backup utilities can copy redo log records from
the archive file as necessary, thereby avoiding the potential loss of data. 簡言之，就是備份速度跟不上redo log生成的速度，結果導緻redo log被覆寫了，然後備份就無法保證一緻性。有了redo log歸檔，就可以在備份啟動時同步啟動redo log歸檔，備份結束時同步停止redo log歸檔，這樣就可以避免這個問題了，備份結束後可以利用這期間生成的redo log進行資料恢複。
想要啟用redo log歸檔功能，隻需設定innodb_redo_log_archive_dirs選項即可，該選項可支援線上動态修改，例如：
[[email protected]]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs/";
指定 /data/mysql8-redologs/ 目錄作為redo log歸檔存放路徑，并且指定label為 "redolog-archiving-for-backup"，也就是這是專用于備份的redo log歸檔存放目錄。
我們還可以指定另一個目錄用于未來基于redo log的實體複制用途（我瞎猜的，可能沒那麼快實作）。
[[email protected]]> SET GLOBAL innodb_redo_log_archive_dirs = "redolog-archiving-for-backup:/data/mysql8-redologs1/;redolog-archiving-for-repl:/data/mysql8-redologs2";
選項innodb_redo_log_archive_dirs可以指定多個目錄作為歸檔redo log存放位置。不過這個選項有幾個限制：
- 該目錄必須事先建立好
- 該目錄其他使用者不可通路，最好設定成 0700 權限模式
- 該目錄不能是datadir、innodb_data_home_dir、innodb_directories、innodb_log_group_home_dir、innodb_temp_tablespaces_dir、innodb_tmpdir、innodb_undo_directory、secure_file_priv這些目錄的父目錄或子目錄。簡言之，歸檔目錄不要和mysqld的運作目錄有任何重合
設定完後，就可以開始進行redo log歸檔了。
第一個參數是我們之前定義過的一個label，第二個參數是該label對應目錄下的子目錄，也就是 "/data/mysql8-redologs/20190722"。我們在相應目錄下就可以看到這樣的redo log歸檔檔案了：
[[email protected]]> DO innodb_redo_log_archive_start("redolog-archiving-for-backup","20190722");
Query OK, 0 rows affected (0.02 sec)
檔案名中常常的那串字元，就是本執行個體的UUID。此時檔案的大小是0位元組。
我們在另一個session發動一個sysbench oltp測試。執行完sysbench測試結束後，我們停止redo log歸檔工作：
[[email protected]]> ls -l /data/mysql8-redologs/20190722
-r--r-----. 1 mysql mysql 0 Jul 22 20:54 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log 我分别記錄了測試前後redo log LSN的變化如下：
# 測試前的LSN
LOG
---
Log sequence number 27938813989
...
# 測試後的LSN
LOG
---
Log sequence number 27945024531 兩次LSN的內插補點是：6210542 位元組。
然後我們檢視redo log歸檔檔案大小是多少：
[[email protected]]> ls -l /data/mysql8-redologs/20190722
-r--r-----. 1 mysql mysql 6213632 Jul 22 21:19 archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log 可以看到檔案大小是 6213632 位元組，和上面的 6210542 位元組隻相差了 3090 位元組，和本次測試産生的redo log日志大小相當。後面我們就可以利用這個redo log做資料恢複之用了（不過，相應的官方工具還沒開發出來，拭目以待吧）。
一般情況下，redo log歸檔對性能的影響比較小（順序寫入），在大量高并發事務的場景下，可能對性能影響會稍大點，不過也不用太擔心，以後有機會我再做個性能對比測試吧。
發車前，月月提醒我，MySQL企業版的備份工具已經提前支援redo歸檔了，希望Percona Xtrabackup也能盡快支援哈。
最後，再多說一句。大家也能注意到，MySQL 8.0版本之後，和ORACLE是越來越像了。有ORACLE這個最成功的商業資料庫大哥在前面，我們完全有理由不用擔心MySQL的未來。
Enjoy MySQL 8.0 :)
延伸閱讀
- MySQL 8.0 Reference Manual，Redo Log Archiving
- 重磅:MySQL8.0.17将新增redo log歸檔特性
- Changes in MySQL 8.0.17 (2019-07-22, General Availability)
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)