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的未来。