24问：一主多从的半同步复制，到底是哪个slave拖慢了性能问题我们都知道

文章插图
问题我们都知道，半同步复制中，如果 slave 比较慢，会拖慢 master 的提交性能。
那么，在一主多从的半同步架构中，如果 master 的提交性能慢，如何判断是哪个 slave 拖慢了性能？
实验先通过 dbdeployer 快速搭建一主两从半同步集群：
文章插图
下面给 master 施加一些压力：
文章插图
然后我们用 strace ，拖慢 slave2 的运行速度。
文章插图
由于半同步复制的原因，现在 slave2 拖慢了 master 的提交性能。我们开始诊断，
设置半同步插件的日志级别为 16：
文章插图
查看 master 的 error log：
文章插图
大概扫一下 error log ，如图举例，发现大部分半同步阻塞，最后收到的都是 server_id 为 300 的 slave 。
而在我们的环境中， slave2 的 server_id 恰好是 300 。
最后，记得将调整的日志级别调回来：
文章插图
半同步插件并没有提供方便的方法查看各个 slave 谁拖慢了性能，所以我们通过调试日志来查看最后一个返回的 ack 都来自于哪台 slave 。
大家使用此方法时，要注意调试日志的量比较大，不要开启太久以防占用过多磁盘。
【24问：一主多从的半同步复制，到底是哪个slave拖慢了性能】关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
文章插图