序言
持续整理下常用的命令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一致性和完整性，同时可以修复损坏的集群数据
工作模式两种：一致性检测只读模式，和多阶段修复模式
集群的一致性状态修复
- region一致性: 集群中所有region都被assign，且region在Master内存、ZK和hbase：meta表三个地方一致
- 表完整性: 集群中的任意一张表，每个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 ;
