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的将来。
以上就是MySQL新特征归档引见的细致内容，更多请关注ki4网别的相干文章！
