MySQL8.0的一些新特性介绍

本文主要给大家简单讲讲MySQL8.0的一些新特性，相关专业术语大家可以上网查查或者找一些相关书籍补充一下，这里就不涉猎了，我们就直奔主题吧，希望MySQL8.0的一些新特性这篇文章可以给大家带来一些实际帮助。

创新互联是一家专业提供英吉沙企业网站建设,专注与成都网站制作、成都做网站、外贸营销网站建设、HTML5建站、小程序制作等业务。10年已为英吉沙众多企业、政府机构等服务。创新互联专业网站设计公司优惠进行中。

此次，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归档对性能的影响比较小（顺序写入），在大量高并发事务的场景下，可能对性能影响会稍大点，不过也不用太担心，以后有机会我再做个性能对比测试吧。

MySQL8.0的一些新特性就先给大家讲到这里，对于其它相关问题大家想要了解的可以持续关注我们的行业资讯。我们的板块内容每天都会捕捉一些行业新闻及专业知识分享给大家的。