MySQL Cluster Tutorial - cdn.oreillystatic.com
MySQL Cluster Tutorial - cdn.oreillystatic.com
MySQL Cluster Tutorial - cdn.oreillystatic.com
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Geographical Replication<br />
The <strong>MySQL</strong> Server <strong>com</strong>es with Replication built in. It allows you to duplicate your data<br />
from one machine to another for failover or backup purposes.<br />
This section we will show how <strong>MySQL</strong> <strong>Cluster</strong> takes advantage of this feat.<br />
First, lets look at the binary logging of the <strong>MySQL</strong> Server, which is a prerequisite for<br />
replication.<br />
Binary Log Format<br />
Before <strong>MySQL</strong> 5.1, the only available option for binary logging was Statement Based. This<br />
means that each successful SQL statement that changes data gets logged.<br />
Another <strong>MySQL</strong> server, the Slave, will read these statements and apply them.<br />
<strong>MySQL</strong> 5.1 brings 2 new formats in addition to Statement-Based binary logging: Row-<br />
Based and Mixed. The latter is a format where the storage engine will be able to choose<br />
whether it does Statement or Row-Based binary logging. Mixed is also default for <strong>MySQL</strong><br />
<strong>Cluster</strong> installations. (Note that for the ‘normal’ <strong>MySQL</strong> 5.1 server, Statement-Based<br />
logging is the default.)<br />
Row-Based binary logging was needed to allow replication of one cluster to another. The<br />
reason is that there can be multiple SQL and API nodes doing changes simultaneously.<br />
Since API Nodes don’t talk SQL, statements can’t be logged. With Row-Based logging, the<br />
data that changed goes to the binary logs, from all SQL and API Nodes.<br />
Copyright © 2010, Oracle and/or its affiliates. All rights reserved. 73/81
Change language