MySQL启动报错ER_FAILED_TO_INIT_THREAD_ATTR，GTID表压缩初始化失败远程修复方案

根据MySQL官方文档和常见的故障排查实践,这个错误通常不是单一原因造成的，错误信息“ER_FAILED_TO_INIT_THREAD_ATTR”直译是“初始化线程属性失败”，而“GTID表压缩初始化失败”则指向了与GTID（全局事务标识符）相关的表可能存在的损坏或访问问题，这两个错误一起出现，意味着MySQL在启动过程中，尝试为处理GTID相关功能的线程设置属性时失败了，而失败的根本原因很可能是底层依赖的GTID系统表（主要是mysql.gtid_executed表）出了问题，比如表空间损坏、索引损坏，或者服务器在之前关闭时没有正确持久化GTID信息。

在进行任何操作之前,远程修复的核心前提是备份，你必须立即对MySQL的数据目录进行完整的文件系统级备份，可以使用简单的打包命令，比如在Linux上使用tar -czvf mysql_backup_before_repair.tar.gz /var/lib/mysql/（具体路径根据你的安装配置而定），这一步是生命线，万一修复失败，还能恢复到操作前的状态，避免数据丢失。

由于数据库无法正常启动,我们无法使用SQL命令进行操作，所有修复都必须在数据库服务停止的状态下，直接处理数据文件，以下是几种逐步深入的远程修复方案，建议按顺序尝试。

跳过GTID相关初始化（临时应急） 这个方法旨在让数据库先启动起来，以便进行后续更安全的修复，根据MySQL官方文档中关于启动选项的说明，可以通过在MySQL的配置文件（如my.cnf或my.ini）中添加特定参数来实现。

1. 通过SSH远程连接到服务器。
2. 编辑MySQL的配置文件,通常在/etc/my.cnf或/etc/mysql/my.cnf。
3. 在[mysqld]配置段下添加一行：disabled_storage_engines=MyISAM，这个参数的作用是禁止使用MyISAM引擎，因为mysql.gtid_executed表在MySQL 5.7及以上版本中默认使用InnoDB引擎，但有时与GTID相关的内部初始化可能会涉及到其他存储引擎的交互，这个选项可以绕过一些复杂的初始化步骤。
4. 也可以尝试添加skip-slave-start参数，确保即使启动成功，复制线程也不会自动开始，避免在数据不一致的情况下引发更多问题。
5. 保存配置文件后,尝试启动MySQL服务：systemctl start mysql或service mysql start。
6. 如果启动成功,立即登录MySQL，然后尝试执行下一步的修复操作，这只是权宜之计，目的是为了获得一个可以操作数据库的入口。

强制恢复模式（InnoDB引擎恢复） 如果方案一无效，错误很可能与存储GTID信息的InnoDB表空间损坏有关，这时需要利用InnoDB存储引擎的强制恢复能力，根据MySQL官方文档中关于InnoDB故障恢复的部分，可以设置不同的恢复级别。

1. 确保MySQL服务处于停止状态。
2. 再次编辑MySQL配置文件。
3. 在[mysqld]部分添加一行：innodb_force_recovery = X，这里的X是一个从1到6的整数，代表不同的恢复强度，数字越大，尝试的恢复措施越激进，但同时也可能造成数据不一致。必须从最小的数字开始尝试。
   • 建议先从innodb_force_recovery = 1开始，这个级别允许服务器忽略检测到的损坏页而继续运行。
   • 如果级别1无法启动,依次尝试2、3，级别3会在1和2的基础上，不回滚事务。
   • 级别4、5、6更为激进，风险也更大，比如级别4会不应用撤销日志，可能导致数据文件处于原始状态，只有在万不得已时才考虑。
4. 设置好参数后（例如先设为1），保存并尝试启动MySQL服务。
5. 一旦启动成功,应立即将受损的表中的数据导出，重点是导出mysql系统数据库中的表，特别是gtid_executed表，可以使用mysqldump命令：mysqldump -u root -p mysql > mysql_database_dump.sql。
6. 导出完成后,必须停止MySQL服务，然后立刻从配置文件中注释掉或删除innodb_force_recovery这一行，因为在该模式下不允许对数据进行任何修改（如INSERT, UPDATE, DELETE），无法进行彻底修复。
7. 再次正常启动MySQL（如果移除了恢复参数后还能启动的话），并重新导入刚才备份的mysql数据库：mysql -u root -p mysql < mysql_database_dump.sql，如果正常启动失败，则需要进行方案三。

重建系统表（最终手段） 如果强制恢复模式也失败了，或者导入后问题依旧，说明系统表损坏可能非常严重，这时，参考MySQL官方文档中关于系统表重建的方法，可以尝试重建整个mysql系统数据库。

1. 停止MySQL服务。
2. 再次确认你已经有了整个数据目录的备份。
3. 重命名当前的mysql系统数据库文件夹，使其失效，命令类似：mv /var/lib/mysql/mysql /var/lib/mysql/mysql_bak。
4. 运行MySQL的初始化命令来重新生成一个全新的、空的mysql系统数据库，这个命令根据安装方式不同而异，常见的有：mysqld --initialize-insecure（不生成root密码）或mysqld --initialize（会生成临时root密码在日志中）。注意： 这个操作也会生成新的ibdata1等系统表空间文件，可能会影响其他数据库，如果你的服务器上只有系统库有问题，这是一个危险操作，因为它会影响所有数据库。
5. 初始化成功后,再次启动MySQL服务，此时应该可以正常启动，因为新的系统表是完好的。
6. 登录MySQL后,你需要手动重新设置root密码、用户权限等信息，这就是为什么第一步强调要备份整个数据目录，你可以从备份的mysql_bak文件夹中，尝试将一些重要的用户和权限表（如user, db, tables_priv等）的数据导入到新生成的mysql数据库中，这个过程非常繁琐且容易出错。
7. 对于gtid_executed表，它已经被重建为空表，这意味着服务器丢失了GTID的执行历史，如果你的数据库是复制环境中的从库，你需要使用CHANGE MASTER TO语句重新配置复制，并使用MASTER_AUTO_POSITION=1来从主库重新同步数据，如果是单机实例，那么GTID历史将从头开始。

总结与预防 远程修复此类底层错误风险极高，在所有方案中，备份是第一步也是最重要的一步，方案一是尝试绕过问题，方案二是尝试修复损坏的数据页，方案三则是推倒重来，成功的概率和数据的完整性依次降低，预防胜于治疗，确保服务器稳定供电、使用可靠的硬件、定期进行数据库完整性检查，是避免此类问题的根本方法，如果数据极其重要且自身没有把握，在尝试任何操作前，寻求专业数据库管理员（DBA）的帮助是最稳妥的选择。