Comments on: Failure scenarios and solutions in master-master replication http://www.xaprb.com/blog/2009/08/30/failure-scenarios-and-solutions-in-master-master-replication/ Stay curious! Thu, 09 Feb 2012 20:41:20 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: The Future of Database Clustering « JZ Talk Blogger http://www.xaprb.com/blog/2009/08/30/failure-scenarios-and-solutions-in-master-master-replication/#comment-17634 The Future of Database Clustering « JZ Talk Blogger Thu, 21 Jan 2010 07:33:04 +0000 http://www.xaprb.com/blog/?p=1263#comment-17634 [...] Future of Database Clustering Baron Schwartz started a good discussion about MMM use cases that quickly veered into an argument about clustering in general. As Florian Haas put it on his [...] [...] Future of Database Clustering Baron Schwartz started a good discussion about MMM use cases that quickly veered into an argument about clustering in general. As Florian Haas put it on his [...]

]]> By: /dev/pawwa » MySQL replication - asynchronous way http://www.xaprb.com/blog/2009/08/30/failure-scenarios-and-solutions-in-master-master-replication/#comment-17067 /dev/pawwa » MySQL replication - asynchronous way Sun, 04 Oct 2009 16:24:54 +0000 http://www.xaprb.com/blog/?p=1263#comment-17067 [...] http://www.xaprb.com/blog/2009/08/30/failure-scenarios-and-solutions-in-master-master-replication/ [...] [...] http://www.xaprb.com/blog/2009/08/30/failure-scenarios-and-solutions-in-master-master-replication/ [...]

]]> By: Istvan Podor http://www.xaprb.com/blog/2009/08/30/failure-scenarios-and-solutions-in-master-master-replication/#comment-16952 Istvan Podor Mon, 07 Sep 2009 10:24:51 +0000 http://www.xaprb.com/blog/?p=1263#comment-16952 @imran I think this isn't the best place to discuss this. Let me invite you to #mmm on freenode and to our mailing list what you can find here: http://groups.google.com/group/mmm-devel @imran

I think this isn’t the best place to discuss this. Let me invite you to #mmm on freenode and to our mailing list what you can find here: http://groups.google.com/group/mmm-devel

]]> By: imran http://www.xaprb.com/blog/2009/08/30/failure-scenarios-and-solutions-in-master-master-replication/#comment-16951 imran Mon, 07 Sep 2009 09:34:48 +0000 http://www.xaprb.com/blog/?p=1263#comment-16951 @Istvan Thanks for the response and for the tips! I'd need to dig the source a little bit but I'm also wondering what the consequence of running two mmm_mon instances would be on 2 separate servers with identical configurations. Would this cause a conflict with respect to the agents/nodes being monitored or can that be considered as a potential workaround to the mmm_mon failing along with the active master? Thanks! @Istvan

Thanks for the response and for the tips! I’d need to dig the source a little bit but I’m also wondering what the consequence of running two mmm_mon instances would be on 2 separate servers with identical configurations. Would this cause a conflict with respect to the agents/nodes being monitored or can that be considered as a potential workaround to the mmm_mon failing along with the active master?

Thanks!

]]> By: Istvan Podor http://www.xaprb.com/blog/2009/08/30/failure-scenarios-and-solutions-in-master-master-replication/#comment-16950 Istvan Podor Mon, 07 Sep 2009 09:01:40 +0000 http://www.xaprb.com/blog/?p=1263#comment-16950 @Imran you can use heartbeat :) But monitor is really not a single-point of failure. yes its stand-alone, but MMM agents will keep the last state if something goes wrong. Regarding to the topic, this is another thing what, lets say, I can afford. If the mmmd_mon failed, and the active master failed, something veery nasty thing must happened. And in that case (based on my experiences) our smallest problem was the mysql master's auto fail-over status :) But, there is another way, what if mmm_mon and the current active master is on the same uplink and something network outages comes in? Now, this is more like a tip, use different network and power supply for each of your mysql master and mmm_mon :) @Imran

you can use heartbeat :)
But monitor is really not a single-point of failure. yes its stand-alone, but MMM agents will keep the last state if something goes wrong. Regarding to the topic, this is another thing what, lets say, I can afford. If the mmmd_mon failed, and the active master failed, something veery nasty thing must happened. And in that case (based on my experiences) our smallest problem was the mysql master’s auto fail-over status :)

But, there is another way, what if mmm_mon and the current active master is on the same uplink and something network outages comes in? Now, this is more like a tip, use different network and power supply for each of your mysql master and mmm_mon :)

]]>