mysql 8.0.17發布了，看了下release note，發現果真如之前預期的那樣，恢復了redo log歸檔（redo log archiving）功能。之所以說是“恢復”，那是因為在InnoDB非常古老的版本（MySQL 4.0.6之前的版本）才存在，之后就取消了，當時還支持redo log mirror，老一點的MySQL DBA可能都還有印象，不過這兩個功能當時沒什么卵用，所以取消了。
推案教程：MySQL數據庫入門視頻教程
此次，InnoDB重啟redo log歸檔功能，按照開發團隊的說法，主要是為了解決備份一致性的問題。文檔里是這么寫的：
Backup?utilities?that?copy?redo?log?records?may?sometimes?fail?to?keep?pacewith?redo?log?generation?while?a?backup?operation?is?in?progress,?resultingin?lost?redo?log?records?due?to?those?records?being?overwritten.?The?redolog?archiving?feature?addresses?this?issue?by?sequentially?writing?redo?logrecords?to?an?archive?file.?Backup?utilities?can?copy?redo?log?records?fromthe?archive?file?as?necessary,?thereby?avoiding?the?potential?loss?of?data. 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選項即可，該選項可支持在線動態修改，例如：
[root@yejr.me]>?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的物理復制用途（我瞎猜的，可能沒那么快實現）。
[root@yejr.me]>?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存放位置。不過這個選項有幾個限制：
設置完后，就可以開始進行redo log歸檔了。
第一個參數是我們之前定義過的一個label，第二個參數是該label對應目錄下的子目錄，也就是 “/data/mysql8-redologs/20190722″。我們在相應目錄下就可以看到這樣的redo log歸檔文件了：
[root@yejr.me]>?ls?-l?/data/mysql8-redologs/20190722-r--r-----.?1?mysql?mysql?0?Jul?22?20:54?archive.f0ff5743-97be-11e9-a5d6-0050568bba82.000001.log
文件名中常常的那串字符，就是本實例的UUID。此時文件的大小是0字節。
我們在另一個session發動一個sysbench oltp測試。執行完sysbench測試結束后，我們停止redo log歸檔工作：
[root@yejr.me]>?DO?innodb_redo_log_archive_stop();Query?OK,?0?rows?affected?(0.00?sec)
我分別記錄了測試前后redo log LSN的變化如下：
#?測試前的LSNLOG---Log?sequence?number??????????27938813989...#?測試后的LSNLOG---Log?sequence?number??????????27945024531 --- Log?sequence?number??????????27938813989 ... #?測試后的LSN LOG --- Log?sequence?number??????????27945024531
兩次LSN的差值是：6210542 字節。
然后我們查看redo log歸檔文件大小是多少：
[root@yejr.me]>?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的未來。
