1. zk集群数据迁移和恢复
zk集群数据迁移和恢复
一、zk数据迁移，有如下两种方案：
1、利用zk集群超过半数仍然可用的特性，比如集群中有5个节点，可以将其中1~2个节点割裂出去，再添加1个新的节点，组成新的集群，以此实现数据迁移；
2、直接拷贝集群的元数据文件到新集群；
但第1种方案并不是最佳选择，例如zk集群连接数负载高，如果此时再减少节点数，则会导致集群负载变得更高，甚至集群崩溃。故采用第2种方案，通过拷贝元数据的方式来实现集群数据迁移和恢复。
二、zk数据迁移和恢复的实现思路
1、搭建好新的zk集群，并且启动集群（此时集群还没有数据）；
2、停止新集群所有节点的zk进程；
3、删除新集群所有节点数据目录下的文件，包括：事务日志、快照、epoch文件
4、将老集群leader节点的事务日志、快照、epoch文件拷贝到新集群所有节点对应的数据目录下；
5、重新启动新集群；
三、注意事项：
如果新集群的两个epoch文件不删掉的话，会造成新集群无法启动；原因是：如果只是拷贝了老集群的快照、事务日志到新集群，新集群的节让渣点在启动时会碧滑宽识别epoch文件中记录的当前epoch值，然后将这个epoch值和从老集群拷贝过来的元数据中的事务ID（zxid）进行比较，发现并不匹配，就会造成新集群无法正常启动。故需要将新集群中各个节点的epoch文件删除，将老集群的epoch文件、快照文件、事务日志文件一并拷贝到新集群的各个节点。
四、zk数据迁移和恢复的具体操作步骤：
1、搭建新集群：
1）、rpm -ivh jdk-8u20-linux-x64.rpm
2）、cd /data/ && tar -zxvf zk_server.tgz ###解压到/data或者/data1
3）、cd /data/ && mv zk_server zk.1 ###myid为1的节点，家目录为/data/zk.1、myid为2的节点，家目录为/data/zk.2
4）、解压之后，可以看到3个目录：
cd /data/zk.1 && ls -l
zk_data ###保存zk快照数据的主目录
zk_log ###保存zk事务日志的主目录
zookeeper ###程序路径，包含配置文件
5）、cd /data/zk.1/zk_data && echo 1 > myid ###配置节点myid，myid为1的节点配置成1，myid为2的节点配置成2，myid为3的节点配置3
6）、cd /data/zk.1/zookeeper/conf && cp -ar zoo.cfg.template zoo.cfg
7）、vim zoo.cfg
tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
autopurge.snapRetainCount=500
autopurge.purgeInterval = 48
dataDir=/data/zk.1/zk_data ###myid为2则配置为/data/zk.2/zk_data
dataLogDir=/data/zk.1/zk_log ###myid为2则配置为/data/zk.2/zk_log
server.1=节点1的IP:8880:7770 #节点1的配置
server.2=节点2的IP:8880:7770 #节点2的配置
server.3=节点3的IP:8880:7770 #节点3的悔亮配置
8）、其余2个节点的安装部署方法也是一样
9）、依次启动3个节点，并检查状态
启动：
cd /data/zk.1/zookeeper/bin/ && nohup sh zkServer.sh start > zookeeper.out &
检查节点状态：
cd /data/zk.1/zookeeper/bin/ && ./zkServer.sh status
连接本地节点，查看数据：
cd /data/zk.1/zookeeper/bin/ && ./zkCli.sh -server 127.0.0.1:2181
2、停止新集群所有节点的zk进程：
cd /data/zk.1/zookeeper/bin/ && sh zkServer.sh stop
cd /data/zk.2/zookeeper/bin/ && sh zkServer.sh stop
cd /data/zk.3/zookeeper/bin/ && sh zkServer.sh stop
3、删除新集群所有节点数据目录下的文件，包括：事务日志、快照、epoch文件（以节点1为例）：
cd /data/zk.1/zk_data/version-2 && rm -f snapshot.* && rm -f acceptedEpoch && rm -f currentEpoch
cd /data/zk.1/zk_log/version-2 && rm -f log.*
4、将老集群leader节点的事务日志、快照、epoch文件拷贝到新集群所有节点对应的数据目录下（以leader节点的数据为准）：
1）、备份老集群leader节点的数据目录下的文件（拷贝到本地的新建的zk_meta_dir目录）
最新的log事务日志文件 ###不是所有的log文件，而是最新的log文件
最新的snapshot文件 ###不是所有的snapshot文件，而是最新的snapshot文件
acceptedEpoch文件
currentEpoch文件
2）、将leader节点zk_meta_dir目录的log文件、snapshot文件、Epoch文件分发到新集群每个节点对应的目录，例如节点1的/data/zk.1/zk_data/version-2、/data/zk.1/zk_log/version-2
5、重新启动新集群：
以节点1为例：
cd /data/zk.1/zookeeper/bin/ && nohup sh zkServer.sh start > zookeeper.out &
2. 不小心把zk的子节点和数据删除了 怎么恢复啊，求大神指点
没有散销删除数据库文件(*.mdb,*.ldb)的话重新附加一遍就可以了
要是删除了颂答数据库野掘慧文件的话，用数据恢复软件，Fanl Date或者DG把数据库文件恢复出来再附加进去就可以了
3. 九、宕机恢复原理
1、Master负载并不很高，基本采用热备的方式来实现Master高可用
2、RegionServer宕机的恢复主要原因有。
2.1、Full GC异常
2.2、HDFS异常
2.3、物理节点宕机
2.4、HBase Bug
3、RegionServer故障恢复原理
3.1、利用ZK临时节点机制，RS在启动会在ZK注册成临时节点，同时Master会Watch这个节点，一般情况下RegionServe会周期性的向ZK发送心跳，如果在超时时间内没有收到心跳，临时节点就会离线，这个消息马上会通知给到Master,Master检测到RS宕机
3.2、切分未持久化的HLog日志，HLog包含多个Region的数据，为了能够按照Region一个个进行数据恢复，首先需要对HLog按照Region进行分组。把同一个Region的日志放一块，便于一个个Region回放。
3.3、Master重新分配宕机RegionServer上的region,将这些Region重新分配到其他可用的RS上。
3.4、按照Region回放吵段HLog
3.5、完成修复，对外提供服务
4、HLog切分大有学问
4.1、0.96版本之前的切分策略:Master单机切分HLog
4.1.1、将待切分的日志重命名，主要防止在某些情况下RS并没有真正宕机，但是Master已经在进行故障恢复了，但是RS还在接受写入请求导致数据不一致。重命名之后此时用户的请求就会异常终止。
4.1.2、读取HLog数据对数据按照Region分组。
4.1.3、切分完成之后Master会对每个Region HLog数据写入各个Region对应的HDFS目录。
4.1.4、Region对日志按顺序进行会回放。
缺点：如升孝誉果需要恢复的数据有几十G 或者更大，Master单机切片的搞法可能需要数小时。
4.2、分布式切分HLog策略
4.2.1、Master将待切分的日志路径发布到ZK节点上，每个日志为一个任务，每个任务都有对应的状态，起始状态为TASK_UNASSIGNED
4.2.2、RS启动之后都注册这个节点等待新任务，一旦Master发布任务，RS就会抢占该任务
4.2.3、抢占任务先看任务状态，如果是TASK_UNASSIGNED，则说明没有被抢占，然后尝试去修改状态为TASK_OWEND，慎隐如果修改成功，表名任务抢占成功。如果修改失败说明被别的RS抢占了。
4.2.4、RS抢占任务成功了之后，将任务分给相应的线程处理，如果处理成功则修改状态为TASK_DONE;如果失败，则状态修改为TASK_ERR。
4.2.5、Master一直监听ZK节点状态的变更，如果状态为TASK_ERR,则重新发布任务，如果成功则删除对应的节点。
4.2.6、分布式切分举例
1）假设Master当前发布了4个任务，即当前需要回放4个日志文件HLog1(H1)、HLog2(H2)、HLog3(H3)、Hlog4(h4)
2）假设RS1抢占了H1,H2；RS2抢占了H3；RS3抢占到了H4
3）以RS1为例，他会把H1，H2，分给2个HlogSpliter线程进行处理，HLogSpliter负责对日志文件执行具体的切分，
具体切分步骤用4.1策略差不多
优点：通过多RS同时执行HLog切分，解决了Master单机切分带来的耗时长的问题
缺点：假设一个宕机的RS上有200个Region,有90个Hlog,由于每个HLog都需要按Region分组，所以这种切分方法会产生90*200=18 000 个小文件。
4.4、分布式日志回放策略
相比分布式切分HLog策略，流程上主要改动了两点
1）、不是先切分在分配Region，而是先分配Region之后再进行Hlog切分，并且此时的Region是recovering状态，可以对外提供写服务
2）、切分HLog逻辑同4.2区别是分布式回放策略并没有先写入文件，而是直接回放。
这种设计大大减少小文件的IO消耗，解决4.2的短板。