hbase hbck2修复工具hbase-operator-tools-1.0.0.1.0.0.0-618-bin.tar.gz

<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> # Apache HBase HBCK2 Tool _HBCK2_ is the repair tool for Apache HBase clusters. Problems in operation are bugs. The need for an _HBCK2_ fix is meant as workaround until the bug is fixed and deployed in a new hbase version. ## _HBCK2_ vs _hbck1_ HBCK2 is the successor to [hbck](https://hbase.apache.org/book.html#hbck.in.depth), the repair tool that shipped with _hbase-1.x_ (A.K.A _hbck1_). Use _HBCK2_ in place of _hbck1_ making repairs against hbase-2.x clusters. _hbck1_ should not be run against an hbase-2.x install. It may do damage. While _hbck1_ is still bundled inside hbase-2.x -- to minimize surprise -- it is deprecated, to be removed in _hbase-3.x_. Its write-facility (`-fix`) has been removed. It can report on the state of an hbase-2.x cluster but its assessments will be inaccurate since it does not understand the internal workings of an hbase-2.x. _HBCK2_ does not work the way _hbck1_ used to, even for the case where commands are similarly named across the two versions. See the next section for how the tools differ. ## Philosophy _HBCK2_ performs a single, discrete task each time it is run. It does not presume a tool can analyze all about the running cluster and then repair 'all problems' found as _hbck1_ used suggest. _HBCK2_ is for fixes. For listings of inconsistencies or blockages in the running cluster, you go elsewhere, to the logs and UI of the running cluster Master. Once an issue has been identified, you use the _HBCK2_ tool to ask the Master to effect fixes or to skip-over bad state. Asking the Master to make the fixes rather than try and effect the repair locally in a fix-it tool's context is another important difference between _HBCK2_ and _hbck1_. More on how this interactive fix-it process works and on _HBCK2_ workings can be found in sections that follow. ## Obtaining _HBCK2_ Releases can be found under the HBase distribution directory. See the [HBASE Downloads Page](http://hbase.apache.org/downloads.html). ## Building _HBCK2_ Run: ``` $ mvn install ``` The built _HBCK2_ jar will be in the `target` sub-directory. ## Running _HBCK2_ The _HBCK2_ jar does not include dependencies; it is not built as a 'fat' jar. Dependencies must be `provided`. Building, adjusting the target hbase version in the top-level pom to match your deploy will make for the smoothest operation when run against your deploy (See the parent pom.xml `hbase-operator-tools` for the [hbase.version to set](https://github.com/apache/hbase-operator-tools/blob/master/pom.xml#L126)). Where runtime interaction between _HBCK2_ and running cluster can get interesting is when _HBCK2_ is in advance of your hbase deploy such that your hbase does not support all APIs in current _HBCK2_. Where _HBCK2_ does not have needed server-side support it should fail gracefully. Use an older release or upgrade your cluster (if you can). The easiest means of 'providing' _HBCK2_ its dependencies is by launching _HBCK2_ via the `$HBASE_HOME/bin/hbase` script. The `bin/hbase` script natively makes mention of `hbck` -- there is a `hbck` option listed in the help output. By default, running `bin/hbase hbck`, the built-in _hbck1_ tooling will be run. To run _HBCK2_, you need to point at a built _HBCK2_ jar using the `-j` option as in: ~~~~ $ ${HBASE_HOME}/bin/hbase --config /etc/hbase-conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.0.0-SNAPSHOT.jar ~~~~ where in the above, `/etc/hbase-conf` is where the deploy's configuration lives. The _HBCK2_ jar is at `~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.0.0-SNAPSHOT.jar`. The above command with no options or arguments passed will dump out the _HBCK2_ help: ``` usage: HBCK2 [OPTIONS] COMMAND <ARGS> Options: -d,--debug run with debug output -h,--help output this help message -p,--hbase.zookeeper.property.clientPort <arg> port of hbase ensemble -q,--hbase.zookeeper.quorum <arg> hbase ensemble -s,--skip skip hbase version check (PleaseHoldException) -v,--version this hbck2 version -z,--zookeeper.znode.parent <arg> parent znode of hbase ensemble Command: addFsRegionsMissingInMeta <NAMESPACE|NAMESPACE:TABLENAME>... Options: -d,--force_disable aborts fix for table if disable fails. To be used when regions missing from hbase:meta but directories are present still in HDFS. Can happen if user has run _hbck1_ 'OfflineMetaRepair' against an hbase-2.x cluster. Needs hbase:meta to be online. For each table name passed as parameter, performs diff between regions available in hbase:meta and region dirs on HDFS. Then for dirs with no hbase:meta matches, it reads the 'regioninfo' metadata file and re-creates given region in hbase:meta. Regions are re-created in 'CLOSED' state in the hbase:meta table, but not in the Masters' cache, and they are not assigned either. To get these regions online, run the HBCK2 'assigns'command printed when this command-run completes. NOTE: If using hbase releases older than 2.3.0, a rolling restart of HMasters is needed prior to executing the set of 'assigns' output. An example adding missing regions for tables 'tbl_1' in the default namespace, 'tbl_2' in namespace 'n1' and for all tables from namespace 'n2': $ HBCK2 addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2 Returns HBCK2 an 'assigns' command with all re-inserted regions. SEE ALSO: reportMissingRegionsInMeta SEE ALSO: fixMeta assigns [OPTIONS] <ENCODED_REGIONNAME/INPUTFILES_FOR_REGIONNAMES>... Options: -o,--override override ownership by another procedure -i,--inputFiles take one or more encoded region names A 'raw' assign that can be used even during Master initialization (if the -skip flag is specified). Skirts Coprocessors. Pass one or more encoded region names. 1588230740 is the hard-coded name for the hbase:meta region and de00010733901a05f5a2a3a382e27dd4 is an example of what a user-space encoded region name looks like. For example: $ HBCK2 assigns 1588230740 de00010733901a05f5a2a3a382e27dd4 Returns the pid(s) of the created AssignProcedure(s) or -1 if none. If -i or --inputFiles is specified, pass one or more input file names. Each file contains encoded region names, one per line. For example: $ HBCK2 assigns -i fileName1 fileName2 bypass [OPTIONS] <PID>... Options: -o,--override override if procedure is running/stuck -r,--recursive bypass parent and its children. SLOW! EXPENSIVE! -w,--lockWait milliseconds to wait before giving up; default=1 Pass one (or more) procedure 'pid's to skip to procedure finish. Parent of bypassed procedure will also be skipped to the finish. Entities will be left in an inconsistent state and will require manual fixup. May need Master restart to clear locks still held. Bypass fails if procedure has children. Add 'recursive' if all you have is a parent pid to finish parent and children. This