Jeremy Cole的演讲InnoDB: A journey to the core II似乎表明有128个插槽，每个插槽可以有1024个交易。所以我对日志文件中记录的2 ^ 17次更新进行了硬限制。
我正在寻找一种方法来从ibdata1和ib_logfile [01]文件中的undo和redo日志中转出更新。如果我可以静态地或动态地从配置中确定撤消和重做日志条目的最大数量，那么我可以强制进入系统中的一些更新，这些更新将旋转出我想要从中删除的数据。文件。
如果可以按字面意思采用Jeremy Cole，则131,072更新应该旋出记录中列的原始值。还是比这更复杂？
答案 0 :(得分：4)
答案是，遗憾的是，它确实比＃34更复杂。首先，澄清一些。
＆＃34;重做日志＆＃34;可以通过两个参数进行配置：
innodb_log_file_size - 控制每个创建的日志文件的大小，以字节为单位。innodb_log_files_in_group - 控制要创建的日志文件数，每个innodb_log_file_size个字节。这使得＆＃34;日志空间＆＃34;大约innodb_log_file_size * innodb_log_files_in_group，您可以看到，例如256 MiB * 2，总共大约512 MiB的日志文件。
此重做日志空间在首次启动时完全分配（所有文件都以其完整大小预先创建），并从头到尾依次使用。使用它＆＃34;包裹＆＃34;从最后一个文件的末尾回到第一个文件的开头，就像一个循环缓冲区。每次发生数据库修改时，＆＃34;记录记录＆＃34;描述该修改将写入重做日志。每个日志记录的大小都是可变的。
＆＃34;撤消日志＆＃34;是不是真的可配置，并不是真正的＆＃34; log＆＃34;从根本上说，在传统意义上。撤消日志作为在InnoDB系统表空间（通常名为ibdata1）内部分配的页面存在，并在那里消耗其空间。它没有预先分配或固定大小;它随需求增长。每次在InnoDB中修改记录时，该记录的数据的之前的版本将被复制到某个撤消日志页面中，然后才允许修改原始页面中的记录。
撤消日志页面是一系列撤消日志页面的一部分，它们形成一个撤销段，并使用一个＆＃34;插槽＆＃34;在回滚段中，有1024个插槽。默认情况下，现在有128个回滚段。这是所提到的128 * 1024（或2 ^ 17）个活动交易限制的来源。每个活动事务占用回滚段中的一个插槽，因此默认情况下，活动，并发事务的最大数量为128 * 1024 = ~113,072（但是其中一些插槽被偶尔使用后台任务。
原始问题实际上是关于如何确保在管理员需要时从系统中删除数据。实际上，这既非常简单又非常困难。
从重做日志中删除数据仅需要消耗足够的重做日志空间来完全循环重做日志。这可以通过许多小交易或一些大型交易。可以执行事务，直到当前LSN提前了日志中的字节数（因为LSN是日志字节的模拟，尽管不完全如此）。
从撤消日志中删除数据几乎是不可能的，但很难监控。没有合理的方法来预测哪个撤销段或撤消页面将用于任何给定的交易，没有办法看到当前存在的页面（或它们的内容）并且没有直接的方式来影响他们破坏。重新启动服务器将释放页面以供内部重复使用，但不幸的是，它们将保留其内容。