一、灾难恢复
我们知道，数据库的日常维护，最重要的就是备份和恢复。有同事（也有DBA）告诉我说，cluster的维护成本很高。就我看来，Mysql发布这个版本的集群方案，是经过严格测试的。官方宣称99.999%的可用性，毫秒级实时性非常诱人。引用官方的一张图：
在所有的管理节点，绝大部分的API节点（Mysqld节点和Memcache节点），超过半数的数据节点都崩溃的情况下，cluster仍然可以保障你的业务正常运行。节点的事务如果出现冲突，cluster会自动修复，如果其中任意一台数据节点出现故障无法启动，那么，我们马上可以换上新的，使用ndbd --initial初始化节点，alter online table重新同步写入数据就行。
二、日常备份和恢复
cluster的备份命令非常容易，在管理节点上执行：
mgmd>start backup
语法：
START BACKUP [backup_id] [wait_option] [snapshot_option]
官方文档我就不抄了。控制台会显示当前备份的简要信息，如：哪个节点开始备份等。你也可以指定具体哪个节点开始备份。cluster的备份数据存放在每个数据节点的数据目录下，从1开始，每次备份产生一个备份目录，形如：BACKUP-备份id。在不指定节点的情况下，每个节点会依次备份。cluster的备份是在线的，不闭塞的，这样我们在备份时完全不用担心会造成数据库堵塞。恢复数据同样简单，我们在每个数据节点（注意：是每个数据节点，不是其中某一个）发出如下指令：
shell>/opt/soft/mysql/bin/ndb_resotre -c "管理服务器IP:1186" -n 节点id -b 备份id -r 就行，如果不想记binlog日志，可以加上--no-binlog参数，全部参数列表请参考官方文档。
在上文，我强调要在每个数据节点执行操作，但是，这只是为保险起见，事实上，在最少情况下，只需要在相同节点组的任意一个节点各操作一次就行。例如，如上图典型的4数据节点集群，node1和2属于node group1，node3和4属于node group2，在恢复时，我们只需要在node1和node3上各执行一次恢复指令就行了。其个中原因，大家可以再看图多思考就会明白。
三、在线扩展节点
Mysql cluster宣称可以在业务量大大增长时，在线添加节点以适应业务需求。方法如下：
（注：以下192.168.0.10是管理节点IP）
1.添加一个[ndbd]并在config.ini里加入
2.停掉mgmd : 10 stop 再重启 ndb_mgmd -f config.ini --reload (这里10是管理节点的id)
3.在已存在的数据节点上rolling restart :
mgmd>原数据节点ID1 restart
mgmd>原数据节点ID2 restart
可以在ndbinfo.nodes表检查确认所有的数据节点使用了新的配置
4.rolling restart所有的sql和api节点 (如果有配置/etc/init.d/mysql.server restart也一样)
mysqladmin -uroot -ppassword shutdown
mysqld_safe --ndbcluster --ndb-connectstring=192.168.0.10 &
5.在新节点上执行初始化启动
ndbd -c 192.168.0.10 --initial
6.建新节点组3,4是新节点的ID
mgmd>CREATE NODEGROUP 3,4
7.再分配集群数据,对每个表执行一次
ALTER ONLINE TABLE tbl REORGANIZE PARTITION.
如果数据量很大，这个过程比较慢，请耐心等待。（如果要数落cluster的不足，我认为在线添加数据节点算是一个）
四、Replication
今天，Mysql的replication异步复制技术已经相当成熟，使用也非常频繁。cluster同样对replication提供了支持。配置非常简单，仅需在cluster中任意一台myql节点上启用binlog，作为master，然后在从库上不启用ndb引擎，其他配置和mysqld之间的replication完全一样。这里需要注意的一点是，你的binlog_format需要设置为STATEMENT，一定不要设置为MIXED，否则你的触发器将会令你的同步出错。这可能是cluster的一个bug，我没有深究。
