MySQL 复制：如何处理“Got Fatal Error 1236”或 MY-013114 错误
内容提要
处理MySQL复制错误时可能会遇到挑战，常见原因包括错误的GTIDs、超过最大允许的数据包大小、缺少二进制日志文件或磁盘空间不足。解决这些问题可能需要插入空事务、增加max_allowed_packet设置等步骤。合适的日志轮转策略和确保足够的磁盘空间可以帮助预防这些错误。
延伸解读
GTID错误：空事务恢复与一致性风险
当源端清除副本所需的二进制日志时，会触发GTID错误。文章指出，若无法找回缺失事务，可在副本上插入具有相同GTID的空事务以恢复复制。但这种方法只是绕过错误，并未实际执行缺失事务，可能导致数据不一致。因此，文章建议事后使用pt-table-checksum等工具检查实例间的一致性，确保数据正确。
max_allowed_packet报错：不一定是参数问题
错误提示建议增加max_allowed_packet，但文章强调这可能具有误导性。即使源端已设置为最大值1GB，错误仍可能出现。此时应检查二进制日志是否真的超过1GB，若未超过，则更可能是日志损坏，例如源端异常重启且sync_binlog未设置为1。此外，还需考虑已知bug（如单行过大或binlog超过4GB）的影响。
日志轮转与磁盘空间：预防复制错误的关键
缺少二进制日志文件通常是因为源端在副本下载前就轮转了日志。文章建议实施合理的日志轮转策略，避免使用过短的保留时间，并考虑使用Percona的binlog_space_limit按空间限制日志。磁盘空间不足也会导致二进制日志损坏，尤其是临时空间（tmpdir或innodb_tmpdir）满时，因此需确保足够的磁盘空间。
Q&A
MySQL复制中常见的错误有哪些？
常见的错误包括错误的GTIDs、数据包大小超限、缺少二进制日志文件和磁盘空间不足。
如何解决MySQL中的GTID错误？
可以通过插入空事务和检查不一致性来解决GTID错误。
为什么会出现“Got Fatal Error 1236”错误？
该错误通常是因为源服务器清除了所需的二进制日志，导致复制失败。
如何避免MySQL复制中的缺少二进制日志文件问题？
实施合适的日志轮转策略可以避免缺少日志文件的问题。
如何处理MySQL复制时的磁盘空间不足问题？
确保有足够的磁盘空间可以防止二进制日志损坏，从而避免复制错误。
如何调整max_allowed_packet设置以解决复制错误？
如果max_allowed_packet设置过小，需要增加该设置以避免复制错误。
