NDB Cluster 存储引擎物理备份
NDB Cluster 存储引擎也是一款事务性存储引擎，和Innodb 一样也有redo 日志。NDB
Cluter 存储引擎自己提供了备份功能，可以通过相关的命令实现。当然，停机冷备的方法
也是有效的。
在线联机备份步骤如下：
1、连接上管理服务器；
2、在管理节点上面执行“START BACKUP” 命令；
3、在管理节点上发出备份指令之后，管理节点会通知所有数据节点开始进行备份，并
反馈通知结果。
4、管理节点在通知发出备份指令之前会生成一个备份号来唯一定位这次备份所产生
的备份集。当各数据节点收到备份指令之后，就会开始进行备份操作。
5、当所有数据节点都完成备份之后，管理节点才会反馈“备份完成”的信息给客户端。

由于NDB Cluster 的备份，备份指令是从管理节点发起，且并不会等待备份完成就会
返回，所以也没办法直接通过“Ctrl + c” 或者其他方式来中断备份进程，所以NDB
Cluster 提供了相应的命令来中断当前正在进行的备份操作，如下：
1、登录管理节点
2、执行“ABORT BACKUP backup_id”，命令中的backup_id 即之前发起备份命令的
时候所产生的备份号。
3、管理结带你上会用消息“放弃指示的备份backup_id”确认放弃请求，注意，则时
候其实并没有收到数据节点对请求的实际回应。
4、然后管理节点才会将中断备份的指令发送到所有数据节点上面，然后当各个数据节
点都中断备份并删除了当前产生的备份文件之后，才会返回“备份backup_id 因＊
＊＊而放弃”。至此，中断备份操作完成。

通过NDB Cluster 存储引擎自己的备份命令来进行备份之后，会将前面所提到的三种
文件存放在参与备份的节点上面，且被存放在三个不同的文件中，类似如下：
BACKUP-backup_id.node_id.ctl，内容包含相关的控制信息和元数据的控制文件。每个
节点均会将相同的表定义（对于Cluster 中的所有表）保存在自己的该文件中。
BACKUP-backup_id-n.node_id.data，数据备份文件，被分成多个不同的片段来保存，
在备份过程中，不同的节点将保存不同的备份数据所产生的片段，每个节点保存的文件都会
有信息指明数据所属表的部分，且在备份片段文件最后还包含了最后的校验信息，以确保备
份能够正确恢复。
BACKUP-backup_id.node_id.log，事务日志备份文件中仅包含已提交事务的相关信息，
且仅保存已在备份中保存的表上的事务，各个阶段所保存的日志信息也不一样，因为仅仅针
对各节点所包含的数据记录相关的日志信息。
上面的备份文件命名规则中，backup_id 是指备份号，不同的备份集会针对有一个不
同的备份号，node_id 则是指明该备份文件属于哪个数据节点，而在数据文件的备份文件中
的n 则是指明片段号。

恢复的时候必须要将备份集中文件恢复到对应的数据节点之上，否则无法正确完成恢
复过程。
通过NDB Cluster 所提供的备份命令来生成的备份集，需要使用专用的备份恢复软
件ndb_restore 来进行。ndb_restore 软件将从备份集中读取出备份相关的控制信息，而
且ndb_restore 软件必须在单独的数据节点上面分别进行。所以当初备份进行过程中有多
少数据节点，现在就需要运行多少次ndb_restore。而且，首次通过ndb_restore 来进行
恢复的话，还必须恢复元数据，也就是会重建所有的数据库和表。

数据库性能优化：
商业需求合理化，
系统架构最优化，
逻辑实现精简化，
硬件设施理性化。

ssh sddxwins@192.168.1.2 ~/toolbar_stat/shell/disk_warning_v3.sh

select distinct mdn from