MYSQL 8.030 的两个重要的变化，对MYSQL 预示着什么 MYSQL 变为 OMYSQL 9 吗

本文主要是介绍MYSQL 8.030 的两个重要的变化，对MYSQL 预示着什么 MYSQL 变为 OMYSQL 9 吗，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

据小道消息，MYSQL 将不在8个开头混了，要转变为 9 这个开头了，那么目前最新的8.030 这个版本的MYSQL 在两个部分的变化较大，并且这两个地方的变化预示这什么，MYSQL将往哪个地方继续变化，这是一个需要研究和理解的地方。

我们从下面的地方查看 MYSQL 的被标记最重要的两个变化

1 与doublewrite 有关

2 与redo log 有关

我们先从doublewrite 说起，与POSTGRESQL full page 一样，doublewrite 也是为了数据安全而做的工作，弊病也是一样，性能的影响的问题。之前我们对于 MYSQL 的double write 的选择只有两种

1 关闭他

2 打开他而在 8.030 这个版本中他们改变了这个问题添加了两个参数

1 detect_and_recover

2 detect_only

当然你可以继续选择关闭和打开它，那么8.030添加这两个参数的意义在哪里，功能是什么。实际上从官方的文档中， detect_and_recover 和 on 打开这个设置的意思是一致的。而进步的是detect_only这个设置，如果打开这个设置后，MYSQL 将只对元数据的产生的变化写入double write 而针对其他的数据将不在启用doublewrite.

我们可以根据这样的状态来测试一下，相关的变化。我们需要准备相关参数的变化，

1 我们先测试仅仅针对系统中参数为

innodb_doublewrite = DETECT_ONLY

我们分别对数据库进行三次的压力测试，可以看到相关的时间在 3.6 -3.74 中左右。

修改参数重启机器 innodb_doublewrite = DETECT_AND_RECOVER，在进行测试。

在测试中可以看到，使用DETECT_ONLY的速度和使用DETECT_AND_ RECOVER 的速度是不同的,可以看到DETECT_ONLY 的速度明显是比开启 DETECT_AND_ RECOVER 的速度要快。

第二个位置的改动在 innodb_redo_log_capacity的位置，目前 8.030已经支持了动态的 redo log 的环境变量的支持工作，通过这个参数可以动态的支持redo log 的capacity 来增加和减少总体的redo log 占用的磁盘空间。从MySQL 8.0.30开始，InnoDB在data目录的#innodb_redo目录下维护了32个重做日志文件。之前InnoDB默认在data目录下创建了两个重做日志文件，重做日志文件的数量和大小由变量innodb_log_files_in_group和innodb_log_file_size控制，这两个变量现在已被弃用。

当innodb_redo_log_capacity设置被定义时，innodb_log_files_in_group和innodb_log_file_size设置被忽略;否则，这些设置被用来计算innodb_redo_log_capacity设置(innodb_log_files_in_group * innodb_log_file_size = innodb_redo_log_capacity)。如果这些变量都没有设置，则重做日志容量设置为innodb_redo_log_capacity的默认值，即104857600字节(100MB)。

根据参数设置，最大的位置的设置为 128G，平均分配到32个文件中为4G 一个REDO LOG 的文件。关键的问题是，他可以动态的进行文件大小的变化。

我们可以看到我们的整体的redo log 的文件初始大小，这个参数允许我们可以在线填充redo log 的大小。

在执行命令后，我们可以蛋刀REDO LOG 的文件大小都进行了变化。重做日志也分为现在使用的重做日志和备用重做日志，带有_tmp 的日志为备用的日志。

通过语句直接也可以查看当前正在使用的REDO LOG 的文件

SELECT FILE_NAME, START_LSN, END_LSN FROM performance_schema.innodb_redo_log_files;

SHOW STATUS LIKE 'Innodb_redo_log_capacity_resized'; 通过命令可以查看redo log 的当前调整的尺寸问题。

复制重做日志记录的备份工具有时可能在备份操作进行时无法跟上重做日志生成的速度，导致重做日志记录丢失，因为这些记录被覆盖了。当备份操作期间MySQL服务器活动频繁，且重做日志文件存储介质的运行速度比备份存储介质快时，通常会发生此问题。MySQL 8.0.17中引入的重做日志归档特性，通过将重做日志记录依次写入除重做日志文件之外的归档文件，解决了这个问题。

MySQL 8.0.17中引入的重做日志归档特性，通过将重做日志记录依次写入除重做日志文件之外的归档文件，解决了这个问题。备份工具可以根据需要从存档文件复制重做日志记录，从而避免潜在的数据丢失。

其他的部分还没有来得及看，但大致的意思是 redo log 在 8.017开始了redo log archive 的工作，是不是有似曾相识的味道。小ORACLE 的名字是越来越成熟了，

数据复制直接使用REDO LOG ，并且REDO LOG 可以归档，以后MYSQL 可以改名叫 OMYSQL

下面的英文可以自己看看，并问自己几个问题，为什么REDO LOG 要归档，并参与备份，后续REDO LOG 参与数据复制，还有BINLOG 什么事情。