Newsletters older than 6 months may have links that are out of date. Please use the Search to check for updated links.
Replication means making a duplicate, or multiple copies, of enterprise data for server load balancing, data warehousing, synchronization of multiple offices and warm back up of servers. Data replication is an increasingly important topic as databases are more and more deployed over clusters of workstations. One of the challenges in database replication is to introduce replication without severely affecting performance. Because of this difficulty, current database products use lazy (asynchronous) replication, which is very efficient but can compromise consistency. As an alternative, eager (synchronous) replication guarantees consistency but most existing algorithms have a prohibitive cost.
Today MySQL offers asynchronous master/slave replication. In an asynchronous replication model, the primary database server does updates down to the stable storage and it is able to commit changes without further communication. After commitment phase, it propagates data changes to other remote database instances. However, some applications require strict consistency between replicas and because the asynchronous method may lead into inconsistent situations, other alternatives should be covered.
During the last 10 years we have seen different proposals for implementing synchronous database replication that is based on two-phase commit (2PC) protocol [GR93]. The 2PC synchronous (eager) replication method, which is based on this algorithm, requires a two-phase commit procedure for writes on a per-action basis. This means that all SQL statements that are going to be replicated are first duplicated on all replicas and then acknowledged by all of them. Synchronous replication ensures strict consistency mechanisms, but due to its high performance impact, it has been considered as an unpractical for the most production environments.
The problems of high overhead inherent to eager replication cause database designers to focus on supporting asynchronous (lazy) master/slave or peer-to-peer replication methods, as these methods deliver better performance.
With Emic Application Cluster (EAC) multi-master architecture, the clients can send their requests to any active server. The server taking care of the new request will act as the master for the requests submitted by the client. The master will process the requests and synchronize changes with the other servers. Unlike 2PC mechanism, EAC does not require per action basis acknowledgments from remote databases, because EAC?s replication engine and communication protocol make sure that all replicated SQL statements are delivered and performed in the same order in all databases. EAC for MySQL's group replication mechanism does not deteriorate performance the way existing synchronous models do, and it still ensures the strict consistency between all replicas.
EAC for MySQL not only provides a fast, reliable synchronous replication, but also offers:
i) dynamic load balancing
ii) fault management with fast failovers
iii) high availability, and
iv) linear scalability with each added server node
For more information about EAC for MySQL, visit
http://www.emicnetworks.com/download/pdf/eac_mysql_whitepaper.pdf.
Or download a free evaluation version at
http://www.emicnetworks.com/download/download_software.html