建设网站的必要性,网页设计制作详细流程,如何快速提升网站权重,wordpress主题文件夹在哪MySQL 8.0.17发布了#xff0c;看了下release note#xff0c;发现果真如之前预期的那样#xff0c;恢复了redo log归档(redo log archiving)功能。之所以说是“恢复”#xff0c;那是因为在InnoDB非常古老的版本(MySQL 4.0.6之前的版本)才存在#xff0c;之后就取消了看了下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 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.简言之就是备份速度跟不上redo log生成的速度结果导致redo log被覆盖了然后备份就无法保证一致性。有了redo log归档就可以在备份启动时同步启动redo log归档备份结束时同步停止redo log归档这样就可以避免这个问题了备份结束后可以利用这期间生成的redo log进行数据恢复。想要启用redo log归档功能只需设置innodb_redo_log_archive_dirs选项即可该选项可支持在线动态修改例如[rootyejr.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的物理复制用途(我瞎猜的可能没那么快实现)。[rootyejr.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归档文件了[rootyejr.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归档工作[rootyejr.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...# 测试后的LSNLOG---Log sequence number 27945024531两次LSN的差值是6210542 字节。然后我们查看redo log归档文件大小是多少[rootyejr.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的未来。
