MyDumper多线程加载MySQL系统表时的死锁问题分析

问题背景

在使用MyDumper工具进行MySQL数据库备份和恢复时，当尝试以多线程方式加载MySQL系统表(mysql.*)时，会出现死锁问题。具体表现为在执行CREATE TABLE语句时抛出"Deadlock found when trying to get lock; try restarting transaction"错误。

问题重现

用户报告在使用myloader以6个线程加载数据时遇到死锁，特别是当处理mysql.default_roles表时。而当将线程数降为1时，加载过程可以正常完成。

技术分析

这个问题实际上与MySQL 8.0版本引入的内部架构变更有关。自MySQL 8.0起，数据库引擎对系统表的并发创建操作进行了更严格的限制。在早期版本中，可以相对自由地并行创建多个表，但在8.0及更高版本中，这种并行操作可能导致死锁。

死锁发生的根本原因是多个线程同时尝试获取系统表上的元数据锁(MDL)，而MySQL 8.0对这些锁的管理更加严格。当多个线程同时尝试创建不同但相关联的系统表时，就可能出现循环等待锁的情况，最终导致死锁。

解决方案

针对这一问题，MyDumper提供了两个有效的解决方案参数：

1. --serialized-table-creation：强制按顺序创建表，完全避免并发创建
2. --max-threads-for-schema-creation：限制用于模式(包括表)创建的线程数

使用这些参数可以在保持一定并发度的同时避免死锁问题，而不需要将整个加载过程降为单线程。

最佳实践建议

对于MySQL 8.0及以上版本的系统表恢复，建议：

1. 优先使用--max-threads-for-schema-creation参数，设置一个适中的值(如2-4)
2. 如果仍遇到问题，再考虑使用--serialized-table-creation
3. 对于非系统表的恢复，可以保持较高的并发度
4. 监控恢复过程中的资源使用情况，避免过度并发导致性能下降

总结

MySQL 8.0对系统表操作的并发限制是一个有意为之的设计变更，旨在提高系统稳定性。MyDumper通过提供灵活的并发控制参数来适应这一变化。理解这些机制有助于DBA更有效地进行数据库备份恢复操作，在保证数据一致性的同时获得最佳性能。