Replication VS Cluster

Hi Guys,
We have a system that has been running along nicely for the past three
months on a pc (4gb 1,8ghz,debian lenny pc). It is a telecom-financal
system; slightly 2 hits per minute but growing exponentally as customers
increase.

We have now bought two servers 12Gb RAM RAID blah blah; and we want to
set the servers up such that one is an exact duplicate of the other; to
guard against hardware failiure (in case for example one motherboard is
fried for some reason). We want to be able to switch from one server to
the next and continue with minimum downtime. Switching will be manual
until I figure out how to do an automatic switch (probably continuously
ping the main server from the hot backup and if the ping fails the hot
backup can change its ip automatically or something!)

Anyway, what method of keeping the two servers in sync would the experts
recommend between replication and setting up a cluster (or something
else)? which will also give me a painless (and later maybe automatic)
changeover? Both servers are connected to the same switch.
--
Jangita | +256 76 91 8383 | Y! & MSN: jangita@yahoo.com
Skype: jangita | GTalk: jangita.nyagudi@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@m.gmane.org

Re: Replication VS Cluster

--0016e64353a0825536048f47b01a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Sep 2, 2010 at 1:10 PM, Jangita wrote:

> Hi Guys,
> We have a system that has been running along nicely for the past three
> months on a pc (4gb 1,8ghz,debian lenny pc). It is a telecom-financal
> system; slightly 2 hits per minute but growing exponentally as customers
> increase.
>

Growth should be linear to the growth of customers, no ? :-)


> We have now bought two servers 12Gb RAM RAID blah blah;


RAID setup is important :-) Datafiles preferably on raid 10.



> and we want to set the servers up such that one is an exact duplicate of
> the other; to guard against hardware failiure (in case for example one
> motherboard is fried for some reason). We want to be able to switch from one
> server to the next and continue with minimum downtime. Switching will be
> manual until I figure out how to do an automatic switch (probably
> continuously ping the main server from the hot backup and if the ping fails
> the hot backup can change its ip automatically or something!)
>

Have a look at Ultramonkey for that.


> Anyway, what method of keeping the two servers in sync would the experts
> recommend between replication and setting up a cluster (or something else)?
> which will also give me a painless (and later maybe automatic) changeover?
> Both servers are connected to the same switch.
>

Standard setup would be replication, yes. If you setup automatic failover,
make sure you prevent automatic failback - that's the best way to mess up
your dataset.

I also hear MMM is pretty good, although I have no personal experience with
it.

Another route you might want to investigate, is Xen (or VMWare, if so
inclined). Build a single virtual host on your hardware, allocate everything
and the kitchen sink to it, and run your MySQL in it. You'll have a slight
performance loss, obviously, but here's the benefit: you can set up the
second server so that it keeps a bit-perfect copy of your primary machine.
The moment your primary machine dies, the second takes over; and since it
has the EXACT same state down to the last bit of ram, you don't even lose a
ping.

Under Xen this feature is called Remus I believe, VMWare calls it Live
Migration or something similar.




> --
> Jangita | +256 76 91 8383 | Y! & MSN: jangita@yahoo.com
> Skype: jangita | GTalk: jangita.nyagudi@gmail.com
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=vegivamp@tuxera.be
>
>


--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--0016e64353a0825536048f47b01a--

Re: Replication VS Cluster

Clustering is a general term, do you know which one you are comparing
with replication? Clustering most typically refers to high
availability clustering or high performance clustering, which wouldnt
necessarily/normally imply any copy of the actual data.

If you want a copy of your data on another server, replication is the
obvious choice. Assuming the realities of replication arent a problem
with respect to your requirements, ie replication is asynchronous...

Andy.




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

Re: Replication VS Cluster

On 02/09/2010 4:32 p, Johan De Meersman wrote:
> On Thu, Sep 2, 2010 at 1:10 PM, Jangita > > wrote:
>

....

> Growth should be linear to the growth of customers, no ? :-)
>

I thought so too; but one customer = 1 customer record, plus all his
transactions, and also weirdly enough (common for us Africans) customers
tend to use the service more as more customers enroll (did that make any
sence?) :):)
....
> RAID setup is important :-) Datafiles preferably on raid 10.

Thanks a bunch on that generous tip!
....
>
> Have a look at Ultramonkey for that.

Thanks again!

> Standard setup would be replication, yes. If you setup automatic
> failover, make sure you prevent automatic failback - that's the best way
> to mess up your dataset.
>
> I also hear MMM is pretty good, although I have no personal experience
> with it.
>
> Another route you might want to investigate, is Xen (or VMWare, if so
> inclined). Build a single virtual host on your hardware, allocate
> everything and the kitchen sink to it, and run your MySQL in it. You'll
> have a slight performance loss, obviously, but here's the benefit: you
> can set up the second server so that it keeps a bit-perfect copy of your
> primary machine. The moment your primary machine dies, the second takes
> over; and since it has the EXACT same state down to the last bit of ram,
> you don't even lose a ping.
>
> Under Xen this feature is called Remus I believe, VMWare calls it Live
> Migration or something similar.

Thanks!
--
Jangita | +256 76 91 8383 | Y! & MSN: jangita@yahoo.com
Skype: jangita | GTalk: jangita.nyagudi@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@m.gmane.org

Re: Replication VS Cluster

On 02/09/2010 4:35 p, a.smith@ukgrid.net wrote:
> Clustering is a general term, do you know which one you are comparing
> with replication? Clustering most typically refers to high availability
> clustering or high performance clustering, which wouldnt
> necessarily/normally imply any copy of the actual data.
>
> If you want a copy of your data on another server, replication is the
> obvious choice. Assuming the realities of replication arent a problem
> with respect to your requirements, ie replication is asynchronous...
>
> Andy.
>
True.

Simply put: I want a solution that ensures that server 2 has all the
data at server 1 at any point in time; say server 1 suddenly fell into a
pond :) . I wouldnt want to open server 2 and find the last
insert/update/delete missing...

--
Jangita | +256 76 91 8383 | Y! & MSN: jangita@yahoo.com
Skype: jangita | GTalk: jangita.nyagudi@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@m.gmane.org

RE: Replication VS Cluster

> Simply put: I want a solution that ensures that server 2 has all the
> data at server 1 at any point in time

If server 1 and 2 are on the same local network, I would use
a cluster. If they are located on physically separate networks,
I would use master-master replication.

Neil

--
Neil Aggarwal, (281)846-8957
FREE trial: Wordpress VPS with unmetered bandwidth
http://UnmeteredVPS.net/wordpress


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

Re: Replication VS Cluster

Quoting Jangita :

>
> Simply put: I want a solution that ensures that server 2 has all the
> data at server 1 at any point in time; say server 1 suddenly fell
> into a pond :) . I wouldnt want to open server 2 and find the last
> insert/update/delete missing...
>

Ok so that rules out any asynchronous replication (MySQL replication
for example).
So options available would include, HA clustering with a shared fibre
channel RAID array. Or synchronous replication over the network using
something like DRBD or HAST (on FreeBSD), plus any other suggestions
from others... :P




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

Re: Replication VS Cluster

--0016e64f8f4a6ffc03048f48d790
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Sep 2, 2010 at 5:12 PM, Neil Aggarwal wrote:

> If server 1 and 2 are on the same local network, I would use
> a cluster.
>

As in NDB ? I've no personal experience with it - save for a sales talk by
MySQL guys some years back where we decided it was useless to us - but I
understand it has quite a few specific limitations that make it suited for a
rather specific range of applications.



> If they are located on physically separate networks,
> I would use master-master replication.
>

If you're on separate networks, you're gonna have trouble maintaining both
performance and perfect replication, regardless of what you do; not to
mention you'll be in performance hell as soon as you want to switch to the
remote master.

--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--0016e64f8f4a6ffc03048f48d790--

Re: Replication VS Cluster

--001636c93243579c49048f48ded9
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Sep 2, 2010 at 5:51 PM, wrote:

> Quoting Jangita :
>
>
>> Simply put: I want a solution that ensures that server 2 has all the data
>> at server 1 at any point in time; say server 1 suddenly fell into a pond :)
>> . I wouldnt want to open server 2 and find the last insert/update/delete
>> missing...
>>
>>
> Ok so that rules out any asynchronous replication (MySQL replication for
> example).
>


Actually, recent 5.1 servers do have 'semi-synchronous' replication, where
replication is synchronous until the slave happens to timeout, where it
reverts to asynchronous until you fix it. Incidentally, this is default
Oracle behaviour, too, if you're not talking RAC.

--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel

--001636c93243579c49048f48ded9--