MySQL Forums
Forum List  »  General

Re: Difference between replication and cluster solutions?
Posted by: Harrison Fisk
Date: October 14, 2004 12:26PM

Hi,

With partitioning, that means the data is divided up into chunks. These chunks are then stored over the computers in question.

Lets say you have 4 machines, and have NoOfReplicas set to 2 (that means 2 machines have copies of the chunks) Each machine would only store half of the data that is added. (2 have the first half, 2 have the second half) That way if one goes down, another still has it. Also by splitting it apart, you can get better parallel processing. However you will still always have a single consistant view of the database.

Replication is generally used for a few cases. First, if you need to have failover. You have just two machines, if one dies, you can failover to another. The slave in this case doesn't do actually anything, just sits idle, while keeping in sync, waiting for the master to fail. Second, is for scalibility for read queries. Since all of the machines have complete copies of the data, you can do SELECTs on any of them.

Clustering is used for a few cases as well. First is super-high HA. If you have the hardware, you can make clusters with lots of nodes, where if multiple fail, everything will still be running OK. Second is for scalibility. Clusters can improve scalibility in one place where replication can't, and that is for write queries, INSERT/UPDATE/etc... The more nodes you add, the more writes you will be able to do. This isn't true at all for replication, since all writes have to happen everywhere.

Hope that gives you some ideas about the differences.

Harrison Fisk, Trainer and Consultant
MySQL AB, www.mysql.com

Options: ReplyQuote


Subject
Written By
Posted
Re: Difference between replication and cluster solutions?
October 14, 2004 12:26PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.