mysql can't init tc log_Can't init tc log问题导致MariaDB（MySQL）启动不了-CSDN博客

本文链接：https://blog.csdn.net/weixin_32737183/article/details/113906160

当遇到MariaDB（MySQL）因`Can't init tc log`无法启动时，通常是由于tc.log文件的问题。解决方法包括删除tc.log文件（Linux：rm /var/lib/mysql/tc.log，Windows：删除data文件夹中的tc.log）然后重启MySQL服务。此错误可能是由于服务器崩溃后支持XA协议的存储引擎数量不一致。确保恢复期间所有之前的XA引擎都存在，以避免事务风险和数据不一致。此外，tc.log的头损坏也可能导致相同问题，同样需要删除并重启MySQL。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

ps：windows下的mariadb版本10.1.9

问题1

mysql启动不了,不能初始化tc日志,导致数据库mariadb启动失败

[Note] Recovering after a crash using tc.log

[ERROR] Can't init tc log

[ERROR] Aborting

解决

FIX:

linux：rm /var/lib/mysql/tc.log

windows：删除mysq下的data文件夹中的tc.log

Then:

重启mysql服务：sudo service mysql start

原因

tc.log is the distributed transaction (XA) log coordinator, which is created by a fresh installation of MariaDB, not in Oracle MySQL.

tc_log是事务协调器日志，用于协调影响多个具有XA功能的存储引擎的事务。如果启用了两个或更多具有XA功能的存储引擎，则事务协调器日志必须可用

在咱们的程序中使用了分布式事务，数据库引擎是InnoDB，使用的是基于内存映射和文件的事务处理协调器日志，其主要目的之一是崩溃修复( crash recovery)

但如果服务器崩溃了，并且你更改了加载的支持XA的存储引擎的数量，也就是出现以下问题：

2018-11-30 23:08:49 140046048638848 [Note] Recovering after a crash using tc.log

2018-11-30 23:08:49 140046048638848 [ERROR] Recovery failed! You must enable exactly 3 storage engines that support two-phase commit protocol

2018-11-30 23:08:49 140046048638848 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}

2018-11-30 23:08:49 140046048638848 [ERROR] Can't init tc log

2018-11-30 23:08:49 140046048638848 [ERROR] Aborting

翻译：

2018-11-30 23:08:49 140046048638848 [注意]使用tc.log崩溃后恢复

2018-11-30 23:08:49 140046048638848 [ERROR]恢复失败！您必须确切启用3个支持两阶段提交协议的存储引擎

2018-11-30 23:08:49 140046048638848 [错误]崩溃恢复失败。纠正问题(例如，出现内存不足错误)并重新启动，或删除tc日志并使用--tc-heuristic-recover = {commit | rollback}启动mysqld

2018-11-30 23:08:49 140046048638848 [错误]无法初始化tc日志

2018-11-30 23:08:49 140046048638848 [ERROR]正在中止

查看mariadb数据库引擎

d70fe6f0ad39

image.png

刚开始启动两个带有SEQUENCE和InnoDB引擎的服务器，服务器意外被干掉，崩溃恢复后没有启动SEQUENCE的服务器导致，崩溃前和恢复后的支持XA引擎数据不一致，导致mariadb检查不通过，数据库启动不了。

注意：缺少哪个支持xa的引擎，无论是缺少还是新出现的引擎都无关紧要，只有数量很重要。例如，可以通过添加TokuDB而不是删除SEQUENCE来复制它；在另一方面，如果你删除序列，并添加TokuDB 一次，服务器启动时都没错，因为引擎的数量是一样的。

mariadb开发维护人员(Sergei Golubchik)给出解释：

This behavior is intentional. The check for the number of engines is supposed to catch user mistakes when one of XA-capable engines is disabled after the crash but before the recovery. Note that

this engine might have prepared but uncommitted transactions

the only entity that knows whether to commit or rollback these transaction is the tc-log

tc-log is destroyed after the recovery

It follows that all XA-capable engines from before the crash must be present during recovery, otherwise you risk "hanging" transactions and inconsistent data.

This is not a bullet-proof check, if one wants to fool it and get inconstent data, he can unload XA-capable engine and replace it with a different XA-capable engine. Or one can simply delete the tc-log file. This check is only designed to prevents user mistakes, not malicious actions.

大致意思说这是一个检查，用于防止用户错误，是故意这么做的，在恢复期间必须存在崩溃之前的所有具有XA功能的引擎，否则您将会有事务和数据不一致的风险。

解决办法就是：卸载支持XA的引擎并将其替换为其他支持XA的引擎。或者可以简单地删除tc-log文件

可能还会遇到同样的类似的其他问题：

基于内存映射和文件的事务协调器日志(tc.log)的标头已损坏

2018-09-19 4:29:31 0 [Note] Recovering after a crash using tc.log

2018-09-19 4:29:31 0 [ERROR] Bad magic header in tc log

2018-09-19 4:29:31 0 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}

2018-09-19 4:29:31 0 [ERROR] Can't init tc log

2018-09-19 4:29:31 0 [ERROR] Aborting

翻译：

2018-09-19 4:29:31 0 [注意]使用tc.log崩溃后恢复

2018-09-19 4:29:31 0 [错误] tc日志中的错误魔术头

2018-09-19 4:29:31 0 [错误]崩溃恢复失败。纠正问题(例如，出现内存不足错误)并重新启动，或删除tc日志并使用--tc-heuristic-recover = {commit | rollback}启动mysqld

2018-09-19 4:29:31 0 [错误]无法初始化tc日志

2018-09-19 4:29:31 0 [错误]中止

问题2

mysql二进制日志文件出错导致mysql服务无法启动

mariadb日志

不能初始化tc日志,导致数据库mariadb启动失败