MySQL新特性归档介绍-百分百源码网

MySQL新特性归档介绍

发布时间：09/01 来源：未知浏览：关键词：

　　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新特性归档介绍的具体内容，更多请关注百分百源码网其它相关文章！

打赏