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

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2 [at] m.gmane.org

--0015175cddda4fa2dd048c080629
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jul 22, 2010 at 8:42 PM, Kyong Kim <kykimdba [at] 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
wultsch [at] gmail.com

--0015175cddda4fa2dd048c080629--

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 <wultsch [at] gmail.com> wrote:
> On Thu, Jul 22, 2010 at 8:42 PM, Kyong Kim <kykimdba [at] 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
> wultsch [at] gmail.com
>

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2 [at] m.gmane.org

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 [at] OpenQuery (http://openquery.com)

On Sat, Jul 24, 2010 at 07:59, Kyong Kim <kykimdba [at] 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 ope=
n.
> Kyong
>
> On Thu, Jul 22, 2010 at 11:19 PM, Rob Wultsch <wultsch [at] gmail.com> wrote:
>> On Thu, Jul 22, 2010 at 8:42 PM, Kyong Kim <kykimdba [at] 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 a=
nd
>> MySQL cluster.
>>
>> For the general case MMM is probably the best option.
>>
>>
>> --
>> Rob Wultsch
>> wultsch [at] gmail.com
>>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: =C2=A0 =C2=A0http://lists.mysql.com/mysql?unsub=3Dlists [at] o=
lindata.com
>
>

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2 [at] m.gmane.o rg