3.1.1 改变了以前管理MySQL Cluster方式

　　当使用MySQL Cluster管理器管理您的MySQL Cluster时，管理员不再编辑配置文件(例如config.ini和my.cnf);相反，这些文件由代理创建和维护。事实上，如果这些文件是手动编辑的，更改将会被代理商内部产生的配置信息覆盖。每个代理存储所有Cluster配置

　　数据，但是它仅创建运行在那台主机上的配置节点所要求的配置文件。图5显示的是该情况的一个实例.

　　同样的，当使用MySQL Cluster管理器的时候，管理员不得使用ndb_mgm命令(直接连接到管理节点也就意味着代理本身将没有与其执行任何操作的可见性)进行管理操作。

　　MySQL Cluster管理器的引进不会消除管理节点的需求;特别的是它们还将继续发挥很多关键作用：

　　● 当数据节点开始(或重启)，它们连接到管理节点以检索配置数据(管理节点依次抓取由代理创建的配置文件中的数据)。

　　● 当通过MySQL Cluster管理器停止或重启一个数据节点，状态更改实际上是由管理节点执行的。

　　● 管理节点能够继续扮演的是仲裁的角色(避免一个裂脑情形)。基于这个原因，它对于运行独立主机上数据节点的这些进程仍然是很重要的。

　　● 一些记录信息(例如，内存使用)在Cluster管理器中目前不可用，并且仍然使用ndb_mgm工具执行。

　　当使用MySQL Cluster管理器时，“代理”进程不再需要(或创建)数据节点，因为它成为代理侦查失败数据节点的责任以及如果需要的话重建的义务。此外，代理扩大了该功能包含管理节点和MySQL服务器节点。

　　值得注意的是，代理本身没有天使进程，并且因此为了达到最高水平的可用性，管理员也许选择使用一个进程监控器来侦查一个代理故障并可以自动重启它。当一个代理不可用时，MySQL Cluster数据库继续以一个容错方式运行，但是管理变更没有执行直到它重启之后。当代理进程重启后，它重新确立了与其他代理的通信，并且已经获得所有当前配置数据，确保管理功能得到恢复。