Problems with mmm for mysql

posted in MySQL by shlomi

出于兴趣和研究目的翻译了此文，最近也看了大众点评关于后台使用MMM来做高可用的一些信息(貌似2014年开始转用MHA来做HA)，想评估下下MMM在实际生产环境当中的可用性。

正文：

我最近在部署MMM for MySQL的时候遭遇到了一些问题，这使我决定不把它应用到生产环境上。

就在我开始写下这篇文章的同一天，Baron 发表了What‘s wrong with MMM?.而我也发现MMM存在缺陷所以希望把我遭遇到的问题都呈现出来，在过去的两周中，
我做了两次不同的部署，在3个不同应用场景下遇到了4次故障。

在下面的所有场景中，都部署了一个活动/被动的MySQL双主同步,一个写入VIP，一个读VIP

问题1：(unjustified failover)非常规的failover操作会破坏MySQL复制

(unjustified failover)非常规的failover是很正常的操作，我可以忍受在数月中有几秒钟的宕机情况
但是在这两个不同的应用部署中，才间隔几天，就发生了两次让人闹心的unjustified failover非常规failover：MySQL复制故障

故障是怎么发生的？之前的活动Master,现在变成非活动的，并且日志position回到大概10天之前，我没有把日志保留10天那么多，所以这就是个突然的复制失败

到现在我还不能在MMM中定位原因，但是
1、没有电源故障
2、MySQL实例没有停掉
3、在发生Failover时复制还都是正常的
4、没有人工干预(我自己或别人使用过)

我明白在上面的情况发生时我没有把所有的都监控到，所以我不能责怪说“当电源关闭时Replication没有把主库信息发送到磁盘”。
我认为这非常可疑；但是，发生了两次，在两个不同的环境部署中。。。

这么多疑点，足以证明了!

说实话，这段我看的不是很明白，这个场景很奇怪

问题2：Master Hanging,没有failover
活动的Master宕机，可能是任何一个硬件或者软件原因引起的，它不执行任何任务工作，TCP/IP链接不上
但不仅仅只是链接不上：是停住不动了。如果尝试用ssh来连，链接会hang住：没有被拒绝链接。SSH客户端没有在合理的时间内终止链接。

嗯哼，是时候做故障转移了吧？

显然还是没有。告警的电话响了，邮件也发过来了。然后开始人工介入，这时候MMM 监控怎么说的呢？什么也没说！It‘s frozen。现在我没有去
读源码，我不会PERL!但是在我看来这个监控守护进程只是运行了一个单一的线程，它用这一个线程去连所有的主机，在链接活动Master时hang住了，
所以整个monitor都停了，没办法，我只好kill掉，我可以选择重现配置去忽略掉原活动Master,但是我还是决定让它重新工作，让它继续回复原装我
必须操作两次，我意识到该做Failover了。

为什么失败了？假设我的分析正确，这是一个重要的设计缺陷，绝不应该用一个单一进程去监控多路主机环境

这个问题倒是比较大，但我也不会PERL，不好下结论

问题3：no servers

系统挂了，不能操作数据库，这时候MMM监控会告诉我们什么呢？
两台机器都是HARD_OFFLINE。
嗯哼，两台机器都出于运行状态时，它们互相同步复制。并且都可以连接操作，MySQL是这样的。
但是没有一台机器是通过VIP来关联的
假如两台Agent 都未能意识到到它们的MYSQL服务器处于运行状态或者Monitor线程都没有接收到信息，这两种情况有问题吗？没有
MMM不会移走所有的VIP。那行，假如MMM确信两台都挂掉了，会怎样？MMM要把所有的VIP丢到其中的一台机器上，所以问题来了，
没有机器了，哪里出错了？

需要有机器来安置这些VIPs.

作者模拟出两台server都挂掉，这种情况出现的几率......

上面列出来的这些不意味这我对MMM的作者反感，我很尊敬他，这些不是容易解决的问题，显然也没有100%的解决方案，只是我不会再用MMM了。

Problems with MMM for mysql(译文),布布扣,bubuko.com

Problems with MMM for mysql(译文)

原文：http://www.cnblogs.com/zeromyth/p/3772422.html