序言

持续整理下常用的命令cuiyaonan2000@163.com

Command

文件拷贝

当从多个源拷贝时，如果两个源冲突，distcp会停止拷贝并提示出错信息，.

如果在目的位置发生冲突，会根据选项设置解决。

默认情况会跳过已经存在的目标文件（比如不用源文件做替换操作）。

每次操作结束时 都会报告跳过的文件数目，但是如果某些拷贝操作失败了，但在之后的尝试成功了， 那么报告的信息可能不够精确。

#这条命令会把master集群的/foo/bar目录下的所有文件或目录名展开并存储到一个临时文件中，这些文件内容的#拷贝工作被分配给多个map任务， 然后每个TaskTracker分别执行从master1到master2的拷贝操作。注意#distcp使用绝对路径进行操作。hadoop distcp hdfs://master1:8020/foo/bar hdfs://master2:8020/bar/foo#命令行中可以指定多个源目录,但是只能有1个目标地址
hadoop distcp hdfs://master1:8020/foo/a hdfs://master1:8020/foo/b hdfs://master2:8020/bar/foo#-f的作用就是从srclist  这个文件中读取多个数据源地址,复制到目标地址
#比如srclist 的内容是
#hdfs://master1:8020/foo/a 
#hdfs://master1:8020/foo/b
hadoop distcp -f hdfs://master1:8020/srclist hdfs://master2:8020/bar/foo 

标识	描述	备注
-p[rbugp]	Preserve   r: replication number   b: block size   u: user   g: group   p: permission	修改次数不会被保留。并且当指定 -update 时，更新的状态不会 被同步，除非文件大小不同（比如文件被重新创建）。
-i	忽略失败	就像在 附录中提到的，这个选项会比默认情况提供关于拷贝的更精确的统计， 同时它还将保留失败拷贝操作的日志，这些日志信息可以用于调试。最后，如果一个map失败了，但并没完成所有分块任务的尝试，这不会导致整个作业的失败。
-log <logdir>	记录日志到 <logdir>	DistCp为每个文件的每次尝试拷贝操作都记录日志，并把日志作为map的输出。 如果一个map失败了，当重新执行时这个日志不会被保留。
-m <num_maps>	同时拷贝的最大数目	指定了拷贝数据时map的数目。请注意并不是map数越多吞吐量越大。
-overwrite	覆盖目标	如果一个map失败并且没有使用-i选项，不仅仅那些拷贝失败的文件，这个分块任务中的所有文件都会被重新拷贝。 就像下面提到的，它会改变生成目标路径的语义，所以 用户要小心使用这个选项。
-update	如果源和目标的大小不一样则进行覆盖	像之前提到的，这不是"同步"操作。 执行覆盖的唯一标准是源文件和目标文件大小是否相同；如果不同，则源文件替换目标文件。 像 下面提到的，它也改变生成目标路径的语义， 用户使用要小心。
-f <urilist_uri>	使用<urilist_uri> 作为源文件列表	这等价于把所有文件名列在命令行中。 urilist_uri 列表应该是完整合法的URI。

Hbase hbck

hbck工具可以检测hbase集群的region一致性和完整性，同时可以修复损坏的集群数据

工作模式两种：一致性检测只读模式，和多阶段修复模式

集群的一致性状态修复

1. region一致性: 集群中所有region都被assign，且region在Master内存、ZK和hbase：meta表三个地方一致
2. 表完整性: 集群中的任意一张表，每个rowkey都仅能存在于一个region区间中

　　
#test 是表名
hbase hbck -fixMeta  -fixAssignments test

命令

hbase hbck

一般集群规模较大尽量不要直接执行，最好是对表进行扫描，直接在命令后加表名即可，多个表直接空格隔开

返回结果为Status: INCONSISTENT 或者Status: OK ;

如果region在move、split、merger时，执行命令是会显示有问题的，所以最好多次执行看

常用参数

• -details 可以输出更详细的信息
• -summary 只打印表和状态的的概要信息
• -metaonly 只检查hbase:meta表的状态
• ​ -fixAssignments 用来修复region的分配，assign问题，如果有region没有assign或者同时assign到多台RS上等问题
• ​ -fixMeta 用来修复元数据，即HDFS上和元数据表中记录不一致问题，原则上是认为HDFS是正确的，即如果HDFS中有这个region，元数据表中没有，就在元数据表中添加，如果元数据表多了，就删除
• ​ -noHdfsChecking 不从hdfs上检查region信息，即假设meta表示正确的
• ​ -fixHdfsHoles 修复hdfs中的region黑洞，一般会和-fixAssignments -fixMeta参数一起用，或者使用
• -repairHoles参数等同于 这三个参数同时使用
• ​ -fixRITAssignment 修复长RIT region
• ​ -repair 如果不知道用什么参数的话，就用这个参数，包含了常用的修复参数，也包含个高危操作

SNAPSHOT快照迁移

总体思路：

　　1、启用快照配置 
　　2、原集群执行快照，然后执行ExportSnapshot 导出到老集群。注意权限问题。 
　　3、导出后，修改对应的权限，然后执行恢复即可

注意点：

　　1、注意文件目录权限 
　　2、注意配置各自的hostname和IP映射 
　　3、注意压缩库是否都配置了

设置支持压缩

在hbase-env.sh中添加如下属性：

export JAVA_LIBRARY_PATH=/usr/lib/hadoop/lib/native/Linux-amd64-64:/usr/lib/hadoop/lib/native

启用快照 

　　hbase-site.xml中添加 hbase.snapshot.enabled为true

生成快照

生成的快照默认在hbase目录的.hbase-snapshot文件加下cuiyaonan2000@163.com

　su - hbasehbase>create 'test_tmp_2017', {NAME => 'F', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'ROW',COMPRESSION => 'SNAPPY'}hbase>flush ’test_tmp_2017'hbase>snapshot ’test_tmp_2017', ’test_tmp_2017_sp'hbase>list_snapshotshbase>delete_snapshot ’test_tmp_2017_sp'

修改新集群快照目录权限（hdfs用户执行） 

su - hdfs
hdfs dfs -chmod -R 777 /apps/hbase/data/.hbase-snapshot ;
hdfs dfs -chmod -R 777 /apps/hbase/data/archive ;