我们最新的 MariaDB Server 版本从 10.6 系列开始引入了一些回归，也影响了 10.7 – 10.9 版本。这篇博文旨在解释这些问题，希望能最大程度地减少影响。我们很可能很快就会发布一个新的 MariaDB 版本来修正这些问题。
表上的 InnoDB 全文索引导致断言错误 (MDEV-29342)
InnoDB 存储引擎中存在一个错误，可能导致全文索引与实际的表数据不同步。这种情况发生在最后一次 InnoDB 同步（异步进行）到服务器关闭之间只插入了一行新数据时。修复索引的唯一方法是重建它。请注意，这个问题在旧版本中也存在，只是它是静默发生的。10.6.9 版本中的不同之处在于断言会实际捕获到该问题，从而停止服务器以防止进一步的数据损坏。更多详情请参见 MDEV-29342。
修复程序已推送到 GitHub。带有全文索引的表很可能受此 bug 影响，升级到 10.6.10 后需要使用 OPTIMIZE TABLE 重建索引。作为一种潜在的临时解决方案，在 10.6.9 中重建全文索引可以防止服务器崩溃（至少直到数据损坏再次发生）。希望此解决方案在您能够升级之前有效。
InnoDB 崩溃恢复错误 (MDEV-29374, MDEV-29383)
通常，InnoDB 表应该对崩溃具有弹性，并且在很大程度上是这样。InnoDB 还有一个校验和机制，以确保数据页中不包含损坏的数据。自 InnoDB 的第一个版本以来，首选方法是如果在遇到校验和错误时总是使服务器崩溃。这实际上是将风险降到最低的编码解决方案：我们检测到有问题，但不知道原因，所以停止一切，让用户决定最佳的处理方式。
不幸的是，这种方法有其缺点，因为它保证了系统停机。即使表中只有一行数据损坏，也无法执行任何请求。这就是 MDEV-13542 发挥作用的地方。我们选择将这项新功能引入到 10.6 及更高版本中，即使它已经是 GA 版本。通常，我们只将代码作为错误修复引入到 GA 版本中。我们将这段代码视为错误修复而不是功能，因为在检测到损坏页面时不总是使服务器崩溃有很多好处。
事后看来，有人可能会争辩说，这最好保留到更新的版本中。但由于开发始于 10.6 版本，并且在开发过程中发现了许多其他错误，因此 10.6 是代码落地的版本。
然而，这项工作引入了以下崩溃恢复错误 MDEV-29374 和 MDEV-29383，这些错误会导致数据损坏。除了防止 MariaDB Server 崩溃（例如通过 Out of Memory killer 脚本终止 mariadbd 进程）之外，用户无法采取任何措施来避免遇到这些 bug。对于 MDEV-29383，请避免在崩溃恢复后使用 maria-backup 执行备份。这两个 bug 都已在源代码树中修复。
有关更改的完整列表，请参阅 MariaDB 10.6.9 的发布说明。
正如这篇博文开篇段落所述，MariaDB Server 很快将发布一个新的点版本。