ps：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数据库引擎
刚开始==启动两个带有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启动失败
mysqld: File '.\mysql-bin.000370' not found (Errcode: 2)
141120 13:23:13 [ERROR] Failed to open log (file '.\mysql-bin.000370', errno 2)
141120 13:23:13 [ERROR] Could not open log file
141120 13:23:13 [ERROR] Can't init tc log
141120 13:23:13 [ERROR] Aborting
说明
查询得知Mysql Data文件夹生成的大量mysql-bin.xxxxx文件是叫做MySQL Binary Log。主要有以下两个作用：
1、数据恢复。
2、在主从server上提高复制的可靠性。
解决
- 进入mysql/data文件夹下手动删除mysql-bin.xxxxx相关的文件
- 进入mysql命令行运行RESET MASTER删除所有日志
rm /var/lib/mysql/mysql-bin.000370
Then:
sudo service mysql start
问题3
数据库起不来，查看数据库err日志
2020-09-17 16:01:21 2216 [ERROR] Binlog has bad magic number; It's not a binary log file that can be used by this version of MySQL
2020-09-17 16:01:21 2216 [ERROR] Can't init tc log
2020-09-17 16:01:21 2216 [ERROR] Aborting
异常断电导致
处理方式
删除mysql.000001文件（注意：删除最近（新）的mysql.****文件）
重启服务
问题4
2020-09-22 17:12:05 2636 [ERROR] InnoDB: Database page corruption on disk or a failed
2020-09-22 17:12:05 2636 [ERROR] InnoDB: Space 0 file .\ibdata1 read of page 229.
2020-09-22 17:12:05 2636 [ERROR] InnoDB: You may have to recover from a backup.
2020-09-22 17:12:05 a4c InnoDB: Page dump in ascii and hex (16384 bytes):
服务器数据库磁盘损坏
2020-09-22 17:12:05 2636[错误]InnoDB:磁盘上的数据库页损坏或失败
2020-09-22 17:12:05 2636[错误]InnoDB:Space 0 file.\ibdata1已阅读第229页。
2020-09-22 17:12:05 2636[错误]InnoDB:您可能需要从备份中恢复。
2020-09-22 17:12:05 a4c InnoDB:页面转储（ascii和十六进制）（16384字节）：
断电导致
处理方式
设置mysql.ini配置文件，设置[mysqld]中添加innodb_force_recovery=1,进行强制奔溃恢复
具体操作
- 关闭所有服务
- 设置[mysqld]中添加innodb_force_recovery=1
- 启动mysql：net start mysql
- 关闭mysql：net stop mysql
- 去掉[mysqld]中添加innodb_force_recovery=1
- 查看是否能重新重启mysql：net start mysql
- 重启所有服务
问题5
2020-07-03 10:20:55 3404 [Note] Found 1 prepared transaction(s) in InnoDB
2020-07-03 10:20:55 3404 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions.
2020-07-03 10:20:55 3404 [ERROR] Aborting
提示信息
找到1个准备好的交易！这意味着mysqld上次没有正确关闭，关键恢复信息（上一个binlog或tc日志文件被手动删除。您必须使用--tc heuristic recover开关启动mysqld，以提交或回滚挂起的事务。
处理办法
- 在my.cnf的[mysqld]下加一项innodb_force_recovery=1
- 管理员命令重新启动mysql：net start mysql --tc-heuristic-recover
- 删除项innodb_force_recovery=1
问题 6
160226 11:00:21 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
处理办法
- 在my.cnf的[mysqld]下加一项innodb_force_recovery=1
- 管理员命令重新启动mysql：net start mysql --tc-heuristic-recover
- 删除项innodb_force_recovery=1
