在Insight界面，通过分片恢复管理功能自动恢复相应数据。
说明
支持恢复一个备机或一个未加入集群的未管理机。
对没有备机的主机进行恢复，结果不保证正确，请谨慎。
1.在Insight界面中，选择菜单[租户管理→集群实例→备份恢复→恢复管理→新增→分片]，进入分片恢复管理界面。
2.选择需要恢复的Group、是否检测Binlog备份时间、是否一致性回滚及需要恢复的DN。
3.选择恢复所使用的备份文件，可以根据备份开始时间和结束时间进行筛选。
4.选择恢复时间进行恢复。
说明
对“是否一致性回滚”的说明：
恢复备机时，一般选择不进行一致性回滚。恢复一个未管理机器时，可以根据需要选择是否一致性回滚。
5.选择菜单[租户管理→集群实例→备份恢复→恢复管理]，查看恢复的结果。示例如下：
6.在进行恢复DN的$HOME/zxdb/log目录下restore.log文件（Insight界面自动恢复功能的log日志），查看自动恢复的各个步骤的结果。
说明
restore.log不会自动删除。在执行恢复时，日志会采用末尾添加的方式增加到日志文件中。
本恢复操作只针对主备机数据均异常情况下，需要全集群恢复的步骤，即所有group节点均需要执行恢复操作。
说明
在恢复备机或未管理机时，请采用自动恢复方式。
手动恢复只适用于针对主备机数据均异常的情况。
基于NFS共享目录的恢复准备。
1.检查NFS共享目录下目录结构、备份文件，确定NFS共享目录下子目录结构及恢复需要的文件是否齐全。
2.检查确定待恢复的DN可以访问NFS共享目录，即待恢复的DN的backup_root目录也关联到共享目录下。
3.执行恢复步骤前，需禁用业务，在Insight页面禁用CN。
4.停止主、备节点DN进程，防止恢复过程中发生主备关系切换。
执行如下命令，停数据库：
dbmoni -stop
恢复示例说明：
● 恢复节点与备份文件节点为同一个节点。
● DN安装用户为dbagent1、IP为192.168.1.117。
● 全量备份开始时刻=“2018-05-09 18:21:05”，全量备份结束时刻= “2018-05-09 18:21:25”；
● 增量备份开始时刻=“2018-05-10 00:00:11”，增量备份结束时刻=“2018-05-10 00:00:19”。
● 想要恢复到的时刻=“2018-05-10 00:00:19”。
恢复步骤：
1.以dbagent1用户登陆系统。
2.根据需要执行如下命令中的一个，将恢复数据文件到datadir(etc/my.cnf中定义的)。
● 命令一：
适用情景：只需要将备份文件恢复到DN中，不应用binlog.
可以根据实际情况指定全量备份文件或全量备份文件+增量备份文件。
restore.py --full_backup_filename="/home/backup_root/DBCluster_1/DATA_BACKUP/20220121090341/Data/Node_1_192.168.1.117_5533/192.168.1.117_FULL_20180503084213.xbstream" --incr_backup_filename="" --my_cnf=/home/dbagent1/etc/my.cnf --db_user=user --db_password=password --encrypt_user="root" --encrypt_password="xxxx" --result_file=/home/dbagent1/restore.result
user:指dbagent访问DN的用户
password:指dbagent访问DN的用户密码
● 命令二：
适用情景：将备份文件恢复到DN中，并应用binlog到某个时间，不回退活跃事务。
restore.py --full_backup_filename="/home/backup_root/DBCluster_1/DATA_BACKUP/20220121090341/Data/Node_1_192.168.1.117_5533/192.168.1.117_FULL_20180503084213.xbstream" --incr_backup_filename="" --binlog_backup_dir='/home/backup_root/DBCluster_1/LOGICAL_BACKUP/Binlog/Node_1' --my_cnf=/home/dbagent1/etc/my.cnf --db_user=user --db_password=password --encrypt_user="root" --encrypt_password="xxxx" --end_timestamp='2018-05-10 00:00:19' --result_file=/home/dbagent1/restore.result
user:指dbagent访问DN的用户
password:指dbagent访问DN的用户密码
● 恢复单库单表时添加参数
--databases=db1 --tables=db1.tb1
其中--tables参数支持通配符，比如--tables=db3.%可用来恢复全库db3。
--databases和--tables两个参数不要同时使用。
● 恢复多库多表时，使用逗号分隔的列表格式
--databases=db1,db2 --tables=db1.tb1,db2.tb2
● 恢复库表时，不支持回滚活跃事务
● 命令三：
适用情景：将备份文件恢复到DN中，然后应用binlog到某个时间，并且回退活跃事务到一致状态。
restore.py --full_backup_filename="/home/backup_root/DBCluster_1/DATA_BACKUP/20220121090341/Data/Node_1_192.168.1.117_5533/192.168.1.117_FULL_20180503084213.xbstream" --incr_backup_filename="" --binlog_backup_dir='/home/backup_root/DBCluster_1/LOGICAL_BACKUP/Binlog/Node_1/' --my_cnf=/home/dbagent1/etc/my.cnf --db_user=user --db_password=password --encrypt_user="root" --encrypt_password="xxxx" --end_timestamp='2018-05-10 00:00:19' --rollback_active_tx --cmdata=/home/backup_root/ --result_file=/home/dbagent1/restore.result
user:指dbagent访问DN的用户
password:指dbagent访问DN的用户密码
说明
恢复DN时指定了binlog dir和应用到的目标时间，需要保证binlog dir目录中的binlog文件是齐全的。如果binlog dir中的binlog文件没有从所用的备份文件至应用时间的完整binlog文件，恢复的DN可能会出现数据不完整或恢复过程中出现错误。
命令参数说明参见下表。
| 参数 | 说明 |
|---|---|
--my_cnf | 指定DN的my.cnf文件（带路径）。如果不指定，默认是$HOME/etc/my.cnf |
--db_user | 待恢复DN的用户名。这里的用户名与下面的密码，并不是用于配置恢复完成后的DN的用户名与密码，而是用于在需要访问恢复后的DN的时候，采用指定的用户名与密码来访问它。指定的用户名与密码需要与DN备份文件里的一致。 |
--db_password | 待恢复DN的用户名对应的密码（加密后的） |
--full_backup_filename | 指定恢复DN所用到的全量备份文件（带路径） |
--incr_backup_filename | 指定恢复DN所用到的增量备份文件（带路径）。如果不指定，则表示从全量备份文件恢复DN。 |
--encrypt_user | 指定备份包的加密用的用户名 |
--encrypt_password | 指定备份包的加密用的用户名对应的密码（加密后的） |
--binlog_backup_dir | 指定binlog所在目录，用于应用binlog。如果不指定，则表示不应用binlog |
--end_binlog_file | 指定回放binlog时，应用结束的binlog文件 |
--end_binlog_pos | 指定回放binlog时，应用结束的binlog位置 |
--end_timestamp | 指定应用binlog到哪个时间点，格式为'YYYY-MM-DD hh:mm:ss' |
--end_gtid | 指定回放binlog时，应用结束的gtid |
--rollback_active_tx | 指定需要回退活跃事务。如果不指定，则表示不回退活跃事务。 |
--cmdata | 指定Active_Tx_info历史文件的存放目录，用于在回退活跃事务时读取活跃事务信息。指定的值应该与clustermanager中配置文件里的配置项backup_root_directory的值是相同目录 |
--databases | 指定需要恢复的单个库，多个时用逗号隔开，不支持仅恢复到DN不应用binlog的场景（即命令一），格式为db1,db2,db3 |
--tables | 指定需要恢复的单张表，多个时用逗号隔开，支持通配符，不支持仅恢复到DN不应用binlog的场景（即命令一），格式为db1.tb1,db2.tb2,db3.% |
--result_file | 指定用于保存恢复过程的状态文件 |
--resume | 指定是否从上一次失败的阶段接着进行恢复操作。 |
-h, --help | 打印帮助信息。 |
说明
命令执行完成后，执行结果日志最后中看到“restore succcess”，表示执行成功。
3.启动DN：
1)执行如下命令，删除$HOME/etc/dbagent_info/ binlogbackup.info文件。
rm $HOME/etc/dbagent_info/binlogbackup.info
2)执行如下命令，启用数据库。
dbmoni -start
集群中所有的group主机恢复建议采用如下步骤：
1.主机DN用户下执行如下命令，清空主机节点data目录下数据。
rm -rf $HOME/data/*
2.备机DN用户下执行如下命令，停止备机节点DN进程。
dbmoni -stop
3.主机DN用户下执行如下命令，将备机节点data目录下的数据拷贝至对应主机节点的data目录下。
scp -r root@备机IP:备机data目录/* $HOME/data/
4.删除$HOME/etc/dbagent_info/ binlogbackup.info文件
rm $HOME/etc/dbagent_info/binlogbackup.info
5.先启动主机节点DN进程，再启动备机节点DN进程
1)先主机DN用户下执行：dbmoni -start。
2)待主机启动成功后，在备机DN用户下执行：dbmoni -start。
在主备机上先后执行启动DN的命令。
执行如下命令，启动数据库：
dbmoni -start
1.如果恢复的DN在恢复之前是一个没有加入集群的DN（即未管理状态），则不会自动加入到任何一个Group中作为备机。
说明
如果需要加入集群，一定是加入到与恢复采用的备份相同的集群中。
2.如果恢复的DN原本是某集群中某个Group中的备机，那么恢复成功之后，Clustermanager组件将自动修复主备关系，即，将恢复的DN作为备机接入原主机中。
3.检查主备复制关系是否正常。
1)登录主机SQL客户端上执行show processlist，可以看到类型这样：
“Binlog Dump | 173 | Master has sent all binlog to slave; waiting for binlog to be updated”
表示主备复制连接线程正常。
2)登录备机SQL客户端执行show slave status G，可以看到类型这样：
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.107
Master_User: repl
…
且无Last_SQL_Error为空，表示主备关系正常。
恢复完成后，执行对应业务测试，确保恢复后业务正常，验证新业务是否可以从主机同步到备机。
1.Insight页面，选择菜单[租户管理]，进入租户管理页面。
2.选择恢复完成的集群，查看“数据节点”中每个DN状态是为“正常”，主备角色与原主备角色一致；确定集群中group节点在Insight页面状态展示正常。
3.选择菜单[集群实例→业务管理→DDL执行]，选择恢复的集群创建DDL。
drop database if exists recover_test ;
create database if not exists recover_test ;
Create table recover_test.t11(id1 int,id2 float(8,4),id3 double(10,6),id4 datetime,id5 varchar(10),primary key(id1));
4.登录绑定该集群的CN客户端，向表recover_test.t11插入数据。
insert into recover_test.t11(id1,id2,id3,id4,id5)
values(1,1.11,1.11,'2015-12-01 11:11:11','aab'),(2,1.12,1.12,'2015-12-01 11:11:11','aac'),(3,1.13,1.13,'2015-12-01 11:11:11','bba'),
(4,2.13,2.13,'2015-12-02 11:11:11',''),(5,3.13,4.14,'2014-12-01 11:11:11','ddd'),(6,3.15,1.15,'2011-12-01 11:11:11','bba'),
(7,4.16,1.16,'2015-12-03 11:11:11',null),(8,5.16,5.17,'2013-12-01 11:11:11','aab'),(9,1.11,1.17,'2012-12-01 11:11:11','ccd');
5.分别登录DN的主备机，查看主备机数据是否一致。
select * from recover_test.t11;
说明
如果select结果在主备上一致，表示主备复制关系正常，可以正常复制数据。
6.选择菜单[集群实例→业务管理→DDL执行]，选择恢复的集群创建DDL。
drop database if exists recover_test ;
