It kind of depends on your application. If you have an application like most web applications, it is okay to skip a beat and a half when a failover occurs. Usually you can lose a very small number of transactions (the ones that are ongoing when the failure occurs), but your failover happens sub-second or very close to that. For most web applications it is more important that service continues, and it is "acceptable" to lose a few transactions (these will just have to be tried again). Other then that 1. make sure to use a separate machine for the monitor 2. make sure that if you use VM's, you put your masters on different physical machines 3. make sure that ARP traffic can flow freely between your machines. EC2 doesn't support thatfor instance, so you'll either have to stick with MMM 1 or patch MMM 2.
That's the most important part I think :) Walter Heck Engineer @ OpenQuery (http://openquery.com) On Sat, Jul 24, 2010 at 07:59, Kyong Kim <kykim...@gmail.com> wrote: > Are there any known issues or challenges implementing MMM? > We're currently focused on MMM but just kinda wanted to keep our eyes open. > Kyong > > On Thu, Jul 22, 2010 at 11:19 PM, Rob Wultsch <wult...@gmail.com> wrote: >> On Thu, Jul 22, 2010 at 8:42 PM, Kyong Kim <kykim...@gmail.com> wrote: >>> >>> Has anyone used this in production? >>> We're looking at this as part of our sharding/scale strategy and >>> wanted some insight into real world experience. >>> Are there alternatives out there? >>> Kyong >>> >> >> Lots of people are using MMM. >> >> Alternatives include Linux-HA (aka heartbeat) often combined with DRBD and >> MySQL cluster. >> >> For the general case MMM is probably the best option. >> >> >> -- >> Rob Wultsch >> wult...@gmail.com >> > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql?unsub=li...@olindata.com > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
