Jeremy Cole 的演讲《InnoDB:核心之旅 II》似乎表明有 128 个插槽,每个插槽可以有 1024 个事务。因此,我将记录在日志文件中的更新硬性限制为 2^17 次。
我正在寻找一种方法来从 ibdata1 和 ib_logfile[01] 文件中的撤消和重做日志轮换更新。如果我可以静态地或从配置动态地确定撤消和重做日志条目的最大数量是多少,那么我可以强制对系统进行大量更新,从而轮换出我试图删除的数据文件。
如果 Jeremy Cole 可以从字面上理解,则 131,072 次更新应该轮换出记录中列的原始值。或者比这更复杂?
不幸的是,答案是,它确实“比这更复杂”。首先,一些澄清。
“重做日志”可通过两个参数进行配置:
innodb_log_file_size— 控制创建的每个日志文件的大小(以字节为单位)。innodb_log_files_in_group— 控制要创建的日志文件的数量(每个innodb_log_file_size字节)。这使得“日志空间”的innodb_log_file_size * innodb_log_files_in_group大小大致相同,您可以看到,例如 256 MiB * 2,总共大约 512 MiB 的日志文件。
此重做日志空间在首次启动时完全分配(所有文件均以其完整大小预先创建),并从开始到结束按顺序使用。它的使用从最后一个文件的末尾“环绕”到第一个文件的开头,就像循环缓冲区一样。每次发生数据库修改时,描述该修改的“日志记录”都会写入重做日志。每个日志记录的大小都是可变的。
“撤消日志”并不是真正可配置的,并且根本不是传统意义上的“日志”。撤消日志作为在 InnoDB 系统表空间(通常名为ibdata1)内分配的页面存在,并消耗其空间。它不是预先分配的或固定大小的;它按需增长。每次在 InnoDB 中修改记录时,在允许修改原始页面中的记录之前,该记录数据的先前版本都会被复制到某个撤消日志页面中。
撤消日志页是撤消日志页链的每个部分,撤消日志页链形成撤消段,并消耗回滚段中的一个“槽”,该“槽”有 1024 个槽。现在默认有 128 个回滚段。这就是所提到的 128 * 1024(或 2^17)活跃交易限制的来源。每个活动事务都会消耗回滚段中的一个槽,因此活动并发事务的最大数量现在默认为 128 * 1024 = ~131,072(但是其中一些槽偶尔会被后台任务消耗)。
最初的问题实际上是关于如何确保在管理员需要时从系统中删除数据。实际上,这既非常容易又非常困难。
从重做日志中删除数据只需要消耗足够的重做日志空间来完全循环重做日志。这可以通过许多小交易或一些大交易来实现。事务可以一直执行,直到当前 LSN 前进了日志中的字节数(因为 LSN 是日志字节的模拟,尽管不完全如此)。
然而,从撤消日志中删除数据几乎是不可能的,而且难以监控。没有合理的方法来预测哪个撤消段或撤消页将用于任何给定的事务,无法查看当前存在哪些页面(或其内容),也没有直接的方法来影响它们的销毁。重新启动服务器将释放页面以供内部重新使用,但不幸的是,会将其内容保留在原处。
| 归档时间: |
|
| 查看次数: |
3020 次 |
| 最近记录: |