Re: Replication VS Cluster
On Thu, Sep 2, 2010 at 1:10 PM, Jangita jang...@jangita.com 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: jang...@yahoo.com Skype: jangita | GTalk: jangita.nyag...@gmail.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=vegiv...@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
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=arch...@jab.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 jang...@jangita.com mailto:jang...@jangita.com 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: jang...@yahoo.com Skype: jangita | GTalk: jangita.nyag...@gmail.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.org
Re: Replication VS Cluster
On 02/09/2010 4:35 p, a.sm...@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: jang...@yahoo.com Skype: jangita | GTalk: jangita.nyag...@gmail.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql?unsub=arch...@jab.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=arch...@jab.org
Re: Replication VS Cluster
Quoting Jangita jang...@jangita.com: 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=arch...@jab.org
Re: Replication VS Cluster
On Thu, Sep 2, 2010 at 5:12 PM, Neil Aggarwal n...@jammconsulting.comwrote: 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
Re: Replication VS Cluster
On Thu, Sep 2, 2010 at 5:51 PM, a.sm...@ukgrid.net wrote: Quoting Jangita jang...@jangita.com: 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
