mysql中主从复制报错如何排查

说白了，排查MySQL主从复制错误其实很简单，但复杂之处在于系统性的检查。
我们先来说说最重要的事情。
登录从库，执行SHOW SLAVESTATUS\G，重点关注Slave_IO_Running和Slave_SQL_Running这两个字段。
我们去年运行的项目有大约 3 000 个级别的数据。
如果这两个字段显示No，基本可以断定是网络或者权限有问题。

一开始我以为是网络问题，后来发现是bug。
还有另一个重要细节，即 Last_Error 和 Last_IO_Error 字段。
它们记录最近的错误详细信息，例如 GTID 不一致或主键冲突。

等一下，还有一件事，它是 Seconds_Behind_Master。
如果该值为NULL，则表示复制被中止；如果继续增加，可能是主库压力大或者从库性能不佳。

分析常见错误类型，例如网络连接问题、用户权限不足、GTID或binlog位置不一致、数据冲突以及DDL/DML不兼容操作等。
这些是常见的错误类型。

检查主从配置的一致性也很重要。
例如，确保主库开启binlog，主从binlog_format建议为ROW，这样可以降低数据不一致的风险。

处理复制中断后的恢复，并根据故障类型选择恢复方法，例如暂时跳过故障、使用GTID修复或重建复制。

最后，建议生产环境优先考虑重构和复制，避免隐藏的数据不一致问题，并建立长效监控机制，防止问题再次出现。
很多人没有注意到这一点，但我认为值得尝试。

mysql主从复制 update_rows失败了

说实话，我对MySQL主从复制中Update_rows的失败感到非常失望。
记得有一次，我半夜看监控，突然发现从库有延迟。
当我检查日志时，正是这个幽灵造成了问题。
当时脑子比较忙，就复制粘贴了网上看到的一个解决方案。
猜猜发生了什么？数据不匹配。

最常见的原因是数据不一致。
显然，从库的这个家伙正在偷偷地更改数据，而主库还不知道。
我曾经面临过一个非常极端的情况。
一位运维小哥觉得查询数据库某张表太慢，就上网优化索引。
结果，数据完全丢失。
主库正常运行binlog，但从库数据崩溃。
我可以请谁来澄清这一点？老实说，这样的事情太隐蔽了，调查起来就像大海捞针一样。

有趣的是表结构不一致的问题。
我以前曾为客户服务过。
他们的主数据库使用ROW格式的binlog。
从库中的某些表有一些附加字段。
导致从库的SQL线程直接被阻塞。
当时技术面出了很多汗。
我一看binlog，哦，全是更新错误。
在这种场景下，直接使用mysqldump导出覆盖肯定不行，因为主库可能还保存着旧数据。

在紧急情况下，STOPSLAVE和跳过计数器确实可以快速解决问题。
当我急于取得进展并忽略错误事件时，我会这样做。
结果第二天又发现主库有更新，但从库还是匹配不到。
我坐在办公桌前，手心出汗。
坦率地说，这类临时解决方案是治标不治本，多用于紧急情况。
当您有时间时，您仍然需要重新同步时间表。

完全重建从数据库是一个坏主意，但有时不得不这样做。
我遇到过一个极端的案例，从库直接被黑，一半数据被篡改。
如果真是这样的话，总不能一一对比记录吧？最终，您可以简单地从主数据库的完整备份中恢复并重置复制。
这个过程令人沮丧，但总比数据不完整要好。

最好的办法是使用mysqlbinlog来查找有问题的SQL。
我有一个朋友非常喜欢使用这个技巧。
他创建了一个脚本，只要日志中报错，就会自动捕获有问题的SQL，然后比较主从数据库的数据差异，直接在从库中进行弥补。
说实话，并不是每个人都知道这项技术。
你需要了解binlog的内部逻辑。
但一旦你掌握了它的窍门，它就会非常有效。

处理这样的问题，关键是要小心。
错误日志中的错误码、时间戳和表名不能被忽略。
我有一个习惯。
当复制出现问题时，我首先查看最新的binlog文件，找到错误的位置，然后回到主库验证这条SQL对应的数据在哪里。
有时你会发现主数据库完全消失了，问题就更大了。

归根结底，还是要通过设计来保证数据的一致性。
然后我就劝很多客户，说主从库之间不要有乱七八糟的手动操作，不管是CDC同步还是全同步+正常增量，不要自己乱来。
就技术而言，有时越简单就越可靠。

MySQL主从复制：Slave_SQL_Running:No

发生异常：致命错误：Foundtablemapeventmappingtableid0 已映射但设置不同。
该错误一般发生在MySQL主从复制过程中，表明当发现表映射事件时，表ID为0的映射已经存在，但设置不同。

解决方案： 1 . 检查配置文件，确保主从复制设置正确。
2 、检查主从服务器时间同步问题。
3 . 尝试重置或重新配置映射表。

您可以先检查一下配置，看看是否有配置错误。

mysql 8.0报错semi-sync master failed on net_flush() before waiting

不，这个“Semi-syncmasterfailedonnet_flush()beforewaitingforreplicareply”错误是错误的。
说实话，我在问答论坛上见过很多次了。
以前使用MySQL 5 .7 时，这个错误相当常见，并且与BUG有关。
比如MariaDB 1 0.0.2 5 的时候，网络卡顿，半同步复制被禁用，主库无法写入，IOThread从库也坏了。
此问题后来在 MariaDB 1 0.0.3 6 和 MySQL 5 .7 中得到修复。
另外，也有人报告MySQL版本5 .7 .1 6 和5 .7 .2 1 出现类似问题，主要与网络不稳定有关。

但是现在我们谈论的是MySQL8 .0。
据我所知，关于net_flush()错误，官方资料并没有说这是一个BUG。
所以在8 .0中，这个错误可能与网络问题有关，这可能与5 .7 中的BUG不同。

为什么这么说？首先，半同步复制依赖于主从库之间的网络通信。
如果网络不稳定，主库在等待从库确认时可能会终止，从而导致错误。
例如，如果主库执行net_flush()将数据刷新到网络缓冲区，但网络不强，从库没有响应，就会报错。

半同步复制机制要求主库等待至少一个从库接收并写入事务后才能向客户端返回成功。
如果从库处理能力不足或者网络延迟太高，主库可能就得等啊等啊等，结果就是超时。

应该做什么？首先应检查网络环境，使用ping、traceroute检查主从库之间的时延和丢包率，确保网络稳定。
如果网络出现抖动，应优化配置或请网络管理员查看。

接下来可以调整半同步参数，比如增加rpl_semi_sync_master_timeout（主库等待从库响应的超时时间）和rpl_semi_sync_master_wait_for_slave_count（从库数量可以减少从库等待主库的数量）。

最后，定期检查MySQL log_error文件，结合慢查询日志和性能监控工具，看看错误发生的时间和系统负载是否有相关性。
这可以帮助您找到问题的根本原因。