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.
• The management node(s) can continue to act as arbitrators (avoiding a split-brain<br />
scenario). For this reason, it is still important to run those processes on separate hosts<br />
from the data nodes;<br />
• Some reporting information (for example, memory usage) is not yet available in the<br />
<strong>Cluster</strong> Manager and can still be performed using the ndb_mgm tool.<br />
When using <strong>MySQL</strong> <strong>Cluster</strong> Manager, the 'angel' processes are no longer needed (or<br />
created) for the data nodes, as it be<strong>com</strong>es the responsibility of the agents to detect the<br />
failure of the data nodes and recreate them as required. Additionally, the agents extend<br />
this functionality to include the management nodes and <strong>MySQL</strong> Server nodes.<br />
It should be noted that there is no angel process for the agents themselves and so for the<br />
highest levels of availability, the administrator may choose to use a process monitor to<br />
detect the failure of an agent and automatically restart it. When an agent is unavailable,<br />
the <strong>MySQL</strong> <strong>Cluster</strong> database continues to operate in a fault-tolerant manner but<br />
management changes cannot be made until it is restarted. When the agent process is<br />
restarted, it re-establishes <strong>com</strong>munication with the other agents and has access to all<br />
current configuration data, ensuring that the management function is restored.<br />
When using <strong>MySQL</strong> <strong>Cluster</strong> Manager, the 'angel' processes are no longer needed (or<br />
created) for the data nodes, as it be<strong>com</strong>es the responsibility of the agents to detect the<br />
failure of the data nodes and recreate them as required. Additionally, the agents extend<br />
this functionality to include the management nodes and <strong>MySQL</strong> Server nodes.<br />
It should be noted that there is no angel process for the agents themselves and so for the<br />
highest levels of availability, the administrator may choose to use a process monitor to<br />
detect the failure of an agent and automatically restart it. When an agent is unavailable,<br />
the <strong>MySQL</strong> <strong>Cluster</strong> database continues to operate in a fault-tolerant manner but<br />
management changes cannot be made until it is restarted. When the agent process is<br />
restarted, it re-establishes <strong>com</strong>munication with the other agents and has access to all<br />
current configuration data, ensuring that the management function is restored.<br />
<strong>MySQL</strong> <strong>Cluster</strong> Manager Model & Terms<br />
Before looking at how to install, configure and use <strong>MySQL</strong> <strong>Cluster</strong> Manager, it helps to<br />
understand a number of <strong>com</strong>ponents and the relationships between them (as viewed by<br />
the <strong>MySQL</strong> <strong>Cluster</strong> Manager). Figure 3 illustrates a number of these entities and then there<br />
is a brief description of each.<br />
Copyright © 2010, Oracle and/or its affiliates. All rights reserved. 25/81