MySQL 8.0.32 双写参数和innodb_redo

最新推荐文章于 2024-05-24 09:16:51 发布

qq_26009505

最新推荐文章于 2024-05-24 09:16:51 发布

阅读量1k

点赞数 13

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/qq_26009505/article/details/135410688

版权

本文详细解释了MySQL8.0.32中的关键内建结构，如双写缓冲区的作用与配置，重做日志文件的管理和磁盘使用，以及会话临时表空间的特性。讨论了innodb_doublewrite、innodb_redo_log_capacity等系统变量及其对数据库性能和数据完整性的影响。

摘要由CSDN通过智能技术生成

版本为mysql 8.0.32

数据库内存和磁盘架构

#ib_16384_0.dblwr

#ib_16384_0.dblwr和#ib_16384_2.dblwr 这两个文件有什么区别

从架构图中，不难看出这两个文件是双写buffer文件。

双写缓冲区是一个存储区域，在 InnoDB将页面写入 InnoDB数据文件中的正确位置之前，先将页面写入从缓冲池刷新的位置。 如果在页面写入过程中 存在操作系统、存储子系统或意外的mysqldInnoDB进程退出，则可以在崩溃恢复期间从双写缓冲区中找到该页面的良好副本。

虽然数据被写入两次，但双写缓冲区不需要两倍的 I/O 开销或两倍的 I/O 操作。fsync()通过对操作系统的一次调用 ，将数据以大的顺序块写入双写缓冲区（innodb_flush_method设置为 的 情况除外O_DIRECT_NO_FSYNC）。

MySQL 8.0.20之前，双写缓冲区存储区域位于InnoDB系统表空间中。从MySQL 8.0.20开始，双写缓冲区存储区域位于双写文件中。

为双写缓冲区配置提供以下变量：

innodb_doublewrite

该innodb_doublewrite 变量控制是否启用双写缓冲区。大多数情况下它是默认启用的。要禁用双写缓冲区，请设置 innodb_doublewrite为 OFF。如果您更关心性能而不是数据完整性（例如，执行基准测试时可能会出现这种情况），请考虑禁用双写缓冲区。

从MySQL 8.0.30开始， innodb_doublewrite支持 DETECT_AND_RECOVER和 DETECT_ONLY设置。

设置DETECT_AND_RECOVER与设置相同ON。通过此设置，双写缓冲区将完全启用，数据库页面内容将写入双写缓冲区，在恢复期间访问该缓冲区以修复不完整的页面写入。

通过该DETECT_ONLY设置，只有元数据会写入双写缓冲区。数据库页内容不会写入双写缓冲区，并且恢复不会使用双写缓冲区来修复不完整的页写入。此轻量级设置仅用于检测不完整的页面写入。

MySQL 8.0.30 及以上版本支持 在、和innodb_doublewrite之间动态更改启用双写缓冲区的设置 。MySQL 不支持启用双写缓冲区的设置之间的动态更改，反之亦然。 ONDETECT_AND_RECOVERDETECT_ONLYOFF

如果双写缓冲区位于支持原子写入的 Fusion-io 设备上，则会自动禁用双写缓冲区，并使用 Fusion-io 原子写入来执行数据文件写入。但是，请注意该innodb_doublewrite 设置是全局的。当双写缓冲区被禁用时，所有数据文件（包括那些不驻留在 Fusion-io 硬件上的数据文件）都会被禁用。此功能仅在 Fusion-io 硬件上受支持，并且仅针对 Linux 上的 Fusion-io NVMFS 启用。要充分利用此功能， 建议 innodb_flush_method设置为。O_DIRECT

innodb_doublewrite_dir

该innodb_doublewrite_dir 变量（在 MySQL 8.0.20 中引入）定义创建双写文件的目录InnoDB。如果未指定目录，则会在该innodb_data_home_dir 目录中创建双写文件，如果未指定，则默认为数据目录。

哈希符号“#”会自动作为指定目录名称的前缀，以避免与架构名称发生冲突。但是，如果有“.”、“#”。或“/”前缀在目录名称中显式指定，哈希符号“#”不作为目录名称的前缀。

理想情况下，双写目录应放置在最快的可用存储介质上。

#innodb_redo

从 MySQL 8.0.30 开始， innodb_redo_log_capacity系统变量控制重做日志文件占用的磁盘空间量。您可以在启动时或在运行时使用语句在选项文件中设置此变量 SET GLOBAL；例如，以下语句将重做日志容量设置为8GB：

SET GLOBAL innodb_redo_log_capacity = 8589934592;
在运行时设置时，配置更改会立即发生，但可能需要一些时间才能完全实施新的限制。如果重做日志文件占用的空间小于指定值，则脏页会不太积极地从缓冲池刷新到表空间数据文件，最终会增加重做日志文件占用的磁盘空间。如果重做日志文件占用的空间超过指定值，则会更积极地刷新脏页，最终减少重做日志文件占用的磁盘空间。

该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_log_files_in_group* innodb_log_file_size= innodb_redo_log_capacity)。如果未设置这些变量，则重做日志容量将设置为 innodb_redo_log_capacity默认值，即 104857600 字节 (100MB)。最大重做日志容量为128GB。

#innodb_redo 除非变量指定了不同的目录，否则 重做日志文件驻留在数据目录中的目录中innodb_log_group_home_dir 。如果 innodb_log_group_home_dir已定义，则重做日志文件驻留在 #innodb_redo该目录中的目录中。重做日志文件有两种类型：普通重做日志文件和备用重做日志文件。普通重做日志文件是正在使用的文件。备用重做日志文件是那些等待使用的文件。InnoDB 尝试总共维护 32 个重做日志文件，每个文件的大小等于 1/32 * innodb_redo_log_capacity；但是，修改设置后，文件大小可能会暂时有所不同 innodb_redo_log_capacity。

重做日志文件使用 命名约定，其中是重做日志文件编号。备用重做日志文件由后缀表示 。以下示例显示 目录中的重做日志文件，其中有 21 个活动重做日志文件和 11 个备用重做日志文件，按顺序编号。 
#ib_redoNN_tmp   # 11 个备用重做日志文件
#innodb_redo     # 21 个活动重做日志文件

'#ib_redo582'  '#ib_redo590'  '#ib_redo598'      '#ib_redo606_tmp'
'#ib_redo583'  '#ib_redo591'  '#ib_redo599'      '#ib_redo607_tmp'
'#ib_redo584'  '#ib_redo592'  '#ib_redo600'      '#ib_redo608_tmp'
'#ib_redo585'  '#ib_redo593'  '#ib_redo601'      '#ib_redo609_tmp'
'#ib_redo586'  '#ib_redo594'  '#ib_redo602'      '#ib_redo610_tmp'
'#ib_redo587'  '#ib_redo595'  '#ib_redo603_tmp'  '#ib_redo611_tmp'
'#ib_redo588'  '#ib_redo596'  '#ib_redo604_tmp'  '#ib_redo612_tmp'
'#ib_redo589'  '#ib_redo597'  '#ib_redo605_tmp'  '#ib_redo613_tmp'
每个普通重做日志文件都与特定范围的 LSN 值相关联；例如，以下查询显示 上一示例中列出的活动重做日志文件的 START_LSN和值：END_LSN

mysql> SELECT FILE_NAME, START_LSN, END_LSN FROM performance_schema.innodb_redo_log_files;
+----------------------------+--------------+--------------+
| FILE_NAME                  | START_LSN    | END_LSN      |
+----------------------------+--------------+--------------+
| ./#innodb_redo/#ib_redo582 | 117654982144 | 117658256896 |
| ./#innodb_redo/#ib_redo583 | 117658256896 | 117661531648 |
| ./#innodb_redo/#ib_redo584 | 117661531648 | 117664806400 |
| ./#innodb_redo/#ib_redo585 | 117664806400 | 117668081152 |
| ./#innodb_redo/#ib_redo586 | 117668081152 | 117671355904 |
| ./#innodb_redo/#ib_redo587 | 117671355904 | 117674630656 |
| ./#innodb_redo/#ib_redo588 | 117674630656 | 117677905408 |
| ./#innodb_redo/#ib_redo589 | 117677905408 | 117681180160 |
| ./#innodb_redo/#ib_redo590 | 117681180160 | 117684454912 |
| ./#innodb_redo/#ib_redo591 | 117684454912 | 117687729664 |
| ./#innodb_redo/#ib_redo592 | 117687729664 | 117691004416 |
| ./#innodb_redo/#ib_redo593 | 117691004416 | 117694279168 |
| ./#innodb_redo/#ib_redo594 | 117694279168 | 117697553920 |
| ./#innodb_redo/#ib_redo595 | 117697553920 | 117700828672 |
| ./#innodb_redo/#ib_redo596 | 117700828672 | 117704103424 |
| ./#innodb_redo/#ib_redo597 | 117704103424 | 117707378176 |
| ./#innodb_redo/#ib_redo598 | 117707378176 | 117710652928 |
| ./#innodb_redo/#ib_redo599 | 117710652928 | 117713927680 |
| ./#innodb_redo/#ib_redo600 | 117713927680 | 117717202432 |
| ./#innodb_redo/#ib_redo601 | 117717202432 | 117720477184 |
| ./#innodb_redo/#ib_redo602 | 117720477184 | 117723751936 |
+----------------------------+--------------+--------------+
执行检查点时，InnoDB将检查点 LSN 存储在包含该 LSN 的文件的标头中。在恢复期间，将检查所有重做日志文件，并从最新的检查点 LSN 开始恢复。

提供了几个状态变量用于监视重做日志和重做日志容量调整操作；例如，您可以查询 Innodb_redo_log_resize_status 以查看调整大小操作的状态：

mysql> SHOW STATUS LIKE 'Innodb_redo_log_resize_status';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_redo_log_resize_status | OK    |
+-------------------------------+-------+
状态 Innodb_redo_log_capacity_resized 变量显示当前重做日志容量限制：


mysql> SHOW STATUS LIKE 'Innodb_redo_log_capacity_resized';
 +----------------------------------+-----------+
| Variable_name                    | Value     |
+----------------------------------+-----------+
| Innodb_redo_log_capacity_resized | 104857600 |
+----------------------------------+-----------+

#innodb_temp

会话临时表空间

会话临时表空间存储用户创建的临时表和优化器在InnoDB配置为磁盘内部临时表的存储引擎时创建的内部临时表。从 MySQL 8.0.16 开始，磁盘内部临时表使用的存储引擎是InnoDB。（以前，存储引擎是由的值确定的 internal_tmp_disk_storage_engine。）

会话临时表空间是在第一次请求创建磁盘临时表时从临时表空间池中分配给会话的。一个会话最多分配两个表空间，一个用于用户创建的临时表，另一个用于优化器创建的内部临时表。分配给会话的临时表空间用于该会话创建的所有磁盘上临时表。当会话断开连接时，其临时表空间将被截断并释放回池中。服务器启动时会创建一个包含 10 个临时表空间的池。池的大小永远不会缩小，并且表空间会根据需要自动添加到池中。临时表空间池将在正常关闭或中止初始化时删除。会话临时表空间文件在创建时大小为五页，并具有.ibt文件扩展名。

为会话临时表空间保留了 40 万个空间 ID 的范围。由于每次服务器启动时都会重新创建会话临时表空间池，因此当服务器关闭时，会话临时表空间的空间 ID 不会保留，并且可以重复使用。

该innodb_temp_tablespaces_dir 变量定义创建会话临时表空间的位置。默认位置是 #innodb_temp数据目录中的目录。如果无法创建临时表空间池，则启动将被拒绝。

$> cd BASEDIR/data/#innodb_temp
$> ls
temp_10.ibt  temp_2.ibt  temp_4.ibt  temp_6.ibt  temp_8.ibt
temp_1.ibt   temp_3.ibt  temp_5.ibt  temp_7.ibt  temp_9.ibt

在基于语句的复制 (SBR) 模式中，在副本上创建的临时表驻留在单个会话临时表空间中，该临时表空间仅在 MySQL 服务器关闭时才会被截断。

该INNODB_SESSION_TEMP_TABLESPACES 表提供有关会话临时表空间的元数据。

信息架构 INNODB_TEMP_TABLE_INFO表提供有关实例中活动的用户创建的临时表的元数据InnoDB。