# Apache HBase 運營管理 本章將介紹運行 Apache HBase 集群所需的操作工具和實踐。操作主題與[故障排除和調試 Apache HBase](#trouble) ， [Apache HBase 性能調優](#performance)和 [Apache HBase 配置](#configuration)的主題相關，但本身就是一個獨特的主題。 ## 150\. HBase 工具和實用程序 HBase 為集群的管理，分析和調試提供了多種工具。大多數這些工具的入口點是 _bin / hbase_ 命令，盡管 _dev-support /_ 目錄中提供了一些工具。 要查看 _bin / hbase_ 命令的使用說明，請運行它，不帶參數或使用`-h`參數。這些是 HBase 0.98.x 的使用說明。某些命令（例如`version`，`pe`，`ltt`，`clean`）在以前的版本中不可用。 ``` $ bin/hbase Usage: hbase [<options>] <command> [<args>] Options: --config DIR Configuration direction to use. Default: ./conf --hosts HOSTS Override the list in 'regionservers' file --auth-as-server Authenticate to ZooKeeper using servers configuration Commands: Some commands take arguments. Pass no args or -h for usage. shell Run the HBase shell hbck Run the HBase 'fsck' tool. Defaults read-only hbck1. Pass '-j /path/to/HBCK2.jar' to run hbase-2.x HBCK2. snapshot Tool for managing snapshots wal Write-ahead-log analyzer hfile Store file analyzer zkcli Run the ZooKeeper shell master Run an HBase HMaster node regionserver Run an HBase HRegionServer node zookeeper Run a ZooKeeper server rest Run an HBase REST server thrift Run the HBase Thrift server thrift2 Run the HBase Thrift2 server clean Run the HBase clean up script classpath Dump hbase CLASSPATH mapredcp Dump CLASSPATH entries required by mapreduce pe Run PerformanceEvaluation ltt Run LoadTestTool canary Run the Canary tool version Print the version backup Backup tables for recovery restore Restore tables from existing backup image regionsplitter Run RegionSplitter tool rowcounter Run RowCounter tool cellcounter Run CellCounter tool CLASSNAME Run the class named CLASSNAME ``` 下面的一些工具和實用程序是 Java 類，它們直接傳遞給 _bin / hbase_ 命令，如使用說明的最后一行所述。其他如`hbase shell`（ [Apache HBase Shell](#shell) ），`hbase upgrade`（[升級](#upgrading)）和`hbase thrift`（ [Thrift API 和過濾語言](#thrift)） ，在本指南的其他地方記錄。 ### 150.1。加納利 Canary 工具可以幫助用戶“測試”HBase 集群狀態。默認的“區域模式”從每個區域的每個列族中獲取一行。在“regionserver 模式”中，Canary 工具將從每個集群的 RegionServers 上的隨機區域中獲取一行。在“zookeeper 模式”中，Canary 將讀取 zookeeper 集合的每個成員上的根 znode。 要查看用法，請傳遞`-help`參數（如果未傳遞參數，則 Canary 工具將在默認區域“mode”中開始執行，從群集中的每個區域獲取一行）。 ``` 2018-10-16 13:11:27,037 INFO [main] tool.Canary: Execution thread count=16 Usage: canary [OPTIONS] [<TABLE1> [<TABLE2]...] | [<REGIONSERVER1> [<REGIONSERVER2]..] Where [OPTIONS] are: -h,-help show this help and exit. -regionserver set 'regionserver mode'; gets row from random region on server -allRegions get from ALL regions when 'regionserver mode', not just random one. -zookeeper set 'zookeeper mode'; grab zookeeper.znode.parent on each ensemble member -daemon continuous check at defined intervals. -interval <N> interval between checks in seconds -e consider table/regionserver argument as regular expression -f <B> exit on first error; default=true -failureAsError treat read/write failure as error -t <N> timeout for canary-test run; default=600000ms -writeSniffing enable write sniffing -writeTable the table used for write sniffing; default=hbase:canary -writeTableTimeout <N> timeout for writeTable; default=600000ms -readTableTimeouts <tableName>=<read timeout>,<tableName>=<read timeout>,... comma-separated list of table read timeouts (no spaces); logs 'ERROR' if takes longer. default=600000ms -permittedZookeeperFailures <N> Ignore first N failures attempting to connect to individual zookeeper nodes in ensemble -D<configProperty>=<value> to assign or override configuration params -Dhbase.canary.read.raw.enabled=<true/false> Set to enable/disable raw scan; default=false Canary runs in one of three modes: region (default), regionserver, or zookeeper. To sniff/probe all regions, pass no arguments. To sniff/probe all regions of a table, pass tablename. To sniff/probe regionservers, pass -regionserver, etc. See http://hbase.apache.org/book.html#_canary for Canary documentation. ``` > `Sink`類使用`hbase.canary.sink.class`配置屬性進行實例化。 此工具將向用戶返回非零錯誤代碼，以便與其他監視工具（如 Nagios）協作。錯誤代碼定義是： ``` private static final int USAGE_EXIT_CODE = 1; private static final int INIT_ERROR_EXIT_CODE = 2; private static final int TIMEOUT_ERROR_EXIT_CODE = 3; private static final int ERROR_EXIT_CODE = 4; private static final int FAILURE_EXIT_CODE = 5; ``` 以下是基于以下給定情況的一些示例：給定兩個名為 test-01 和 test-02 的 Table 對象，每個對象分別具有兩個列族 cf1 和 cf2，部署在 3 個 RegionServers 上。請參見下表。 | RegionServer 的 | 測試 01 | 測試 02 | | --- | --- | --- | | RS1 | R1 | R2 | | RS2 | r2 | | | RS3 | r2 | r1 | 以下是基于先前給定案例的一些示例輸出。 #### 150.1.1。 Canary 測試每個表的每個區域的每個列族（商店） ``` $ ${HBASE_HOME}/bin/hbase canary 3/12/09 03:26:32 INFO tool.Canary: read from region test-01,,1386230156732.0e3c7d77ffb6361ea1b996ac1042ca9a. column family cf1 in 2ms 13/12/09 03:26:32 INFO tool.Canary: read from region test-01,,1386230156732.0e3c7d77ffb6361ea1b996ac1042ca9a. column family cf2 in 2ms 13/12/09 03:26:32 INFO tool.Canary: read from region test-01,0004883,1386230156732.87b55e03dfeade00f441125159f8ca87\. column family cf1 in 4ms 13/12/09 03:26:32 INFO tool.Canary: read from region test-01,0004883,1386230156732.87b55e03dfeade00f441125159f8ca87\. column family cf2 in 1ms ... 13/12/09 03:26:32 INFO tool.Canary: read from region test-02,,1386559511167.aa2951a86289281beee480f107bb36ee. column family cf1 in 5ms 13/12/09 03:26:32 INFO tool.Canary: read from region test-02,,1386559511167.aa2951a86289281beee480f107bb36ee. column family cf2 in 3ms 13/12/09 03:26:32 INFO tool.Canary: read from region test-02,0004883,1386559511167.cbda32d5e2e276520712d84eaaa29d84\. column family cf1 in 31ms 13/12/09 03:26:32 INFO tool.Canary: read from region test-02,0004883,1386559511167.cbda32d5e2e276520712d84eaaa29d84\. column family cf2 in 8ms ``` 所以你可以看到，table test-01 有兩個區域和兩個列族，因此默認的“區域模式”中的 Canary 工具將從 4 個（2 個區域* 2 個商店）不同的商店中挑選 4 個小塊數據。這是默認行為。 #### 150.1.2。對特定表格的每個區域的每個列族（商店）進行 Canary 測試 您還可以通過傳遞表名來測試一個或多個特定表。 ``` $ ${HBASE_HOME}/bin/hbase canary test-01 test-02 ``` #### 150.1.3。使用 RegionServer 粒度進行 Canary 測試 在“regionserver 模式”中，Canary 工具將從每個 RegionServer 中選取一小段數據（在“regionserver 模式”下，您還可以將一個或多個 RegionServer 名稱作為參數傳遞給 canary-test）。 ``` $ ${HBASE_HOME}/bin/hbase canary -regionserver 13/12/09 06:05:17 INFO tool.Canary: Read from table:test-01 on region server:rs2 in 72ms 13/12/09 06:05:17 INFO tool.Canary: Read from table:test-02 on region server:rs3 in 34ms 13/12/09 06:05:17 INFO tool.Canary: Read from table:test-01 on region server:rs1 in 56ms ``` #### 150.1.4。金絲雀測試與正則表達式模式 在“區域模式”下，您可以為表名傳遞正則表達式，在“regionserver 模式”下，可以為服務器名傳遞正則表達式。下面將測試 table test-01 和 test-02。 ``` $ ${HBASE_HOME}/bin/hbase canary -e test-0[1-2] ``` #### 150.1.5。運行金絲雀測試作為“守護進程” 通過選項`-interval`定義的間隔重復運行（默認值為 60 秒）。如果發生任何錯誤，此守護程序將自行停止并返回非零錯誤代碼。要讓守護程序繼續運行錯誤，請傳遞-f 標志，并將其值設置為 false（請參閱上面的用法）。 ``` $ ${HBASE_HOME}/bin/hbase canary -daemon ``` 要以 5 秒的間隔重復運行而不是因錯誤而停止，請執行以下操作。 ``` $ ${HBASE_HOME}/bin/hbase canary -daemon -interval 5 -f false ``` #### 150.1.6。如果金絲雀測試卡住，則強制超時 在某些情況下，請求被卡住，并且沒有響應被發送回客戶端。這可能發生在主服務器尚未注意到的死區域服務器上。因此，我們提供了一個超時選項來終止金絲雀測試并返回非零錯誤代碼。以下設置超時值為 60 秒（默認值為 600 秒）。 ``` $ ${HBASE_HOME}/bin/hbase canary -t 60000 ``` #### 150.1.7。在金絲雀中啟用寫嗅探 默認情況下，canary 工具僅檢查讀取操作。要啟用寫入嗅探，可以在設置了`-writeSniffing`選項的情況下運行 canary。啟用寫入嗅探時，金絲雀工具將創建一個 hbase 表，并確保將表的區域分發到所有區域服務器。在每個嗅探期間，金絲雀將嘗試將數據放入這些區域以檢查每個區域服務器的寫入可用性。 ``` $ ${HBASE_HOME}/bin/hbase canary -writeSniffing ``` 默認寫表為`hbase:canary`，可以使用選項`-writeTable`指定。 ``` $ ${HBASE_HOME}/bin/hbase canary -writeSniffing -writeTable ns:canary ``` 每個 put 的默認值大小為 10 個字節。您可以通過配置鍵設置它：`hbase.canary.write.value.size`。 #### 150.1.8。將讀/寫失敗視為錯誤 默認情況下，金絲雀工具僅記錄讀取失敗 - 由于例如 RetriesExhaustedException 等 - 并將返回'正常'退出代碼。要將讀/寫失敗視為錯誤，可以使用`-treatFailureAsError`選項運行 canary。啟用時，讀/寫失敗將導致錯誤退出代碼。 ``` $ ${HBASE_HOME}/bin/hbase canary -treatFailureAsError ``` #### 150.1.9。在啟用 Kerberos 的群集中運行 Canary 要在啟用 Kerberos 的群集中運行 Canary，請在 _hbase-site.xml_ 中配置以下兩個屬性： * `hbase.client.keytab.file` * `hbase.client.kerberos.principal` 當 Canary 以守護進程模式運行時，Kerberos 憑據每 30 秒刷新一次。 要為客戶端配置 DNS 接口，請在 _hbase-site.xml_ 中配置以下可選屬性。 * `hbase.client.dns.interface` * `hbase.client.dns.nameserver` 示例 40.啟用 Kerberos 的群集中的 Canary 此示例顯示具有有效值的每個屬性。 ``` <property> <name>hbase.client.kerberos.principal</name> <value>hbase/_HOST@YOUR-REALM.COM</value> </property> <property> <name>hbase.client.keytab.file</name> <value>/etc/hbase/conf/keytab.krb5</value> </property> <!-- optional params --> <property> <name>hbase.client.dns.interface</name> <value>default</value> </property> <property> <name>hbase.client.dns.nameserver</name> <value>default</value> </property> ``` ### 150.2。 RegionSplitter ``` usage: bin/hbase regionsplitter <TABLE> <SPLITALGORITHM> SPLITALGORITHM is the java class name of a class implementing SplitAlgorithm, or one of the special strings HexStringSplit or DecimalStringSplit or UniformSplit, which are built-in split algorithms. HexStringSplit treats keys as hexadecimal ASCII, and DecimalStringSplit treats keys as decimal ASCII, and UniformSplit treats keys as arbitrary bytes. -c <region count> Create a new table with a pre-split number of regions -D <property=value> Override HBase Configuration Settings -f <family:family:...> Column Families to create with new table. Required with -c --firstrow <arg> First Row in Table for Split Algorithm -h Print this usage help --lastrow <arg> Last Row in Table for Split Algorithm -o <count> Max outstanding splits that have unfinished major compactions -r Perform a rolling split of an existing region --risky Skip verification steps to complete quickly. STRONGLY DISCOURAGED for production systems. ``` 有關其他詳細信息，請參見[手動區域分割](#manual_region_splitting_decisions)。 ### 150.3。健康檢查員 您可以將 HBase 配置為定期運行腳本，如果它失敗了 N 次（可配置），請讓服務器退出。有關配置和詳細信息，請參閱 _HBASE-7351 定期運行狀況檢查腳本 _。 ### 150.4。司機 幾個經常訪問的實用程序作為`Driver`類提供，并由 _bin / hbase_ 命令執行。這些實用程序代表在群集上運行的 MapReduce 作業。它們以下列方式運行，將 _UtilityName_ 替換為您要運行的實用程序。此命令假定您已將環境變量`HBASE_HOME`設置為服務器上解壓縮 HBase 的目錄。 ``` ${HBASE_HOME}/bin/hbase org.apache.hadoop.hbase.mapreduce.UtilityName ``` 可以使用以下實用程序： `LoadIncrementalHFiles` 完成批量數據加載。 `CopyTable` 將表從本地群集導出到對等群集。 `Export` 將表數據寫入 HDFS。 `Import` 導入先前`Export`操作寫入的數據。 `ImportTsv` 以 TSV 格式導入數據。 `RowCounter` 計算 HBase 表中的行數。 `CellCounter` 計算 HBase 表中的單元格。 `replication.VerifyReplication` 比較兩個不同集群中表的數據。警告：自時間戳更改以來，它不適用于 incrementColumnValues 的單元格。請注意，此命令與其他命令位于不同的程序包中。 除`RowCounter`和`CellCounter`之外的每個命令都接受單個`--help`參數來打印使用說明。 ### 150.5。 HBase `hbck` hbase-1.x 附帶的`hbck`工具已在 hbase-2.x 中設置為只讀。由于 hbase 內部組件已更改，因此無法修復 hbase-2.x 群集。其只讀模式的評估也不應該受到信任，因為它不了解 hbase-2.x 操作。 下一節中描述的新工具 [HBase `HBCK2`](#HBCK2) 取代`hbck`。 ### 150.6。 HBase `HBCK2` `HBCK2`是 [HBase `hbck`](#hbck) 的后繼者，hbase-1.x 修復工具（A.K.A `hbck1`）。使用它代替`hbck1`進行 hbase-2.x 安裝修復。 `HBCK2`不作為 hbase 的一部分發貨。它可以作為 [Apache HBase HBCK2 工具](https://github.com/apache/hbase-operator-tools/tree/master/hbase-hbck2)的伴隨 [hbase-operator-tools](https://github.com/apache/hbase-operator-tools) 存儲庫的子項目找到。 `HBCK2`被移出 hbase，因此除了 hbase 核心之外，它還能以節奏發展。 有關`HBCK2`與`hbck1`的區別，請參閱 [](HBCK2) [https://github.com/apache/hbase-operator-tools/tree/master/hbase-hbck2](https://github.com/apache/hbase-operator-tools/tree/master/hbase-hbck2) 主頁，以及如何構建和使用它。 構建完成后，您可以按如下方式運行`HBCK2`： ``` $ hbase hbck -j /path/to/HBCK2.jar ``` 這將生成描述命令和選項的`HBCK2`用法。 ### 150.7。 HFile 工具 參見 [HFile 工具](#hfile_tool)。 ### 150.8。 WAL 工具 #### 150.8.1。 FSHLog 工具 `FSHLog`上的主要方法提供手動拆分和轉儲設施。傳遞它 WALs 或分裂的產物， _recover.edits_ 的內容。目錄。 您可以通過執行以下操作獲取 WAL 文件內容的文本轉儲： ``` $ ./bin/hbase org.apache.hadoop.hbase.regionserver.wal.FSHLog --dump hdfs://example.org:8020/hbase/WALs/example.org,60020,1283516293161/10.10.21.10%3A60020.1283973724012 ``` 如果文件有任何問題，返回代碼將為非零，因此您可以通過將`STDOUT`重定向到`/dev/null`并測試程序返回來測試文件的健康性。 類似地，您可以通過執行以下操作強制拆分日志文件目錄： ``` $ ./bin/hbase org.apache.hadoop.hbase.regionserver.wal.FSHLog --split hdfs://example.org:8020/hbase/WALs/example.org,60020,1283516293161/ ``` ##### WALPrettyPrinter `WALPrettyPrinter`是一個帶有可配置選項的工具，用于打印 WAL 的內容。您可以使用'wal'命令通過 HBase cli 調用它。 ``` $ ./bin/hbase wal hdfs://example.org:8020/hbase/WALs/example.org,60020,1283516293161/10.10.21.10%3A60020.1283973724012 ``` > WAL 打印舊版本的 HBase > > 在版本 2.0 之前，`WALPrettyPrinter`在 HBase 的預寫日志的內部名稱之后被稱為`HLogPrettyPrinter`。在這些版本中，您可以使用與上面相同的配置打印 WAL 的內容，但使用'hlog'命令。 > > ``` > $ ./bin/hbase hlog hdfs://example.org:8020/hbase/.logs/example.org,60020,1283516293161/10.10.21.10%3A60020.1283973724012 > ``` ### 150.9。壓縮工具 見 [compression.test](#compression.test) 。 ### 150.10。 CopyTable CopyTable 是一個實用程序，可以將部分或全部表復制到同一個集群或另一個集群。目標表必須首先存在。用法如下： ``` $ ./bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable --help /bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable --help Usage: CopyTable [general options] [--starttime=X] [--endtime=Y] [--new.name=NEW] [--peer.adr=ADR] <tablename> Options: rs.class hbase.regionserver.class of the peer cluster, specify if different from current cluster rs.impl hbase.regionserver.impl of the peer cluster, startrow the start row stoprow the stop row starttime beginning of the time range (unixtime in millis) without endtime means from starttime to forever endtime end of the time range. Ignored if no starttime specified. versions number of cell versions to copy new.name new table's name peer.adr Address of the peer cluster given in the format hbase.zookeeer.quorum:hbase.zookeeper.client.port:zookeeper.znode.parent families comma-separated list of families to copy To copy from cf1 to cf2, give sourceCfName:destCfName. To keep the same name, just give "cfName" all.cells also copy delete markers and deleted cells Args: tablename Name of the table to copy Examples: To copy 'TestTable' to a cluster that uses replication for a 1 hour window: $ bin/hbase org.apache.hadoop.hbase.mapreduce.CopyTable --starttime=1265875194289 --endtime=1265878794289 --peer.adr=server1,server2,server3:2181:/hbase --families=myOldCf:myNewCf,cf2,cf3 TestTable For performance consider the following general options: It is recommended that you set the following to >=100\. A higher value uses more memory but decreases the round trip time to the server and may increase performance. -Dhbase.client.scanner.caching=100 The following should always be set to false, to prevent writing data twice, which may produce inaccurate results. -Dmapred.map.tasks.speculative.execution=false ``` > 掃描儀緩存 > > 輸入的緩存掃描通過作業配置中的`hbase.client.scanner.caching`進行配置。 > > 版 > > 默認情況下，CopyTable 實用程序僅復制最新版本的行單元格，除非在命令中明確指定了`--versions=n`。 有關`CopyTable`的更多信息，請參閱 Jonathan Hsieh 的[在線 HBase 備份和 CopyTable](https://blog.cloudera.com/blog/2012/06/online-hbase-backups-with-copytable-2/) 博客文章。 ### 150.11。哈希表/ SyncTable HashTable / SyncTable 是一個用于同步表數據的兩步工具，其中每個步驟都實現為 MapReduce 作業。與 CopyTable 類似，它可用于在相同或遠程群集下進行部分或整個表數據同步。但是，它以比 CopyTable 更有效的方式執行同步。 HashTable（第一步）不是復制指定行鍵/時間段范圍內的所有單元格，而是為源表上的批處理單元格創建散列索引，并將其作為結果輸出。在下一個階段，SyncTable 掃描源表，現在計算表格單元格的哈希索引，將這些哈希值與 HashTable 的輸出進行比較，然后只掃描（并比較）單元格以獲得不同的哈希值，只更新不匹配的單元格。這樣可以減少網絡流量/數據傳輸，這可能會在同步遠程群集上的大型表時產生影響。 #### 150.11.1。第 1 步，HashTable 首先，在源表集群上運行 HashTable（這是將其狀態復制到其對應表的表）。 用法： ``` $ ./bin/hbase org.apache.hadoop.hbase.mapreduce.HashTable --help Usage: HashTable [options] <tablename> <outputpath> Options: batchsize the target amount of bytes to hash in each batch rows are added to the batch until this size is reached (defaults to 8000 bytes) numhashfiles the number of hash files to create if set to fewer than number of regions then the job will create this number of reducers (defaults to 1/100 of regions -- at least 1) startrow the start row stoprow the stop row starttime beginning of the time range (unixtime in millis) without endtime means from starttime to forever endtime end of the time range. Ignored if no starttime specified. scanbatch scanner batch size to support intra row scans versions number of cell versions to include families comma-separated list of families to include Args: tablename Name of the table to hash outputpath Filesystem path to put the output data Examples: To hash 'TestTable' in 32kB batches for a 1 hour window into 50 files: $ bin/hbase org.apache.hadoop.hbase.mapreduce.HashTable --batchsize=32000 --numhashfiles=50 --starttime=1265875194289 --endtime=1265878794289 --families=cf2,cf3 TestTable /hashes/testTable ``` **batchsize** 屬性定義在單個散列值中將給定區域的單元數據散列在一起的程度。正確調整大小會對同步效率產生直接影響，因為它可能會導致 SyncTable 的映射器任務執行的掃描次數減少（該過程的下一步）。經驗法則是，不同步的單元數量越少（找到差異的概率越低），可以確定更大的批量大小值。 #### 150.11.2。第 2 步，SyncTable 在源群集上完成 HashTable 后，可以在目標群集上運行 SyncTable。就像復制和其他同步作業一樣，它要求源集群上的所有 RegionServers / DataNode 都可以由目標集群上的 NodeManagers 訪問（其中將運行 SyncTable 作業任務）。 Usage: ``` $ ./bin/hbase org.apache.hadoop.hbase.mapreduce.SyncTable --help Usage: SyncTable [options] <sourcehashdir> <sourcetable> <targettable> Options: sourcezkcluster ZK cluster key of the source table (defaults to cluster in classpath's config) targetzkcluster ZK cluster key of the target table (defaults to cluster in classpath's config) dryrun if true, output counters but no writes (defaults to false) doDeletes if false, does not perform deletes (defaults to true) doPuts if false, does not perform puts (defaults to true) Args: sourcehashdir path to HashTable output dir for source table (see org.apache.hadoop.hbase.mapreduce.HashTable) sourcetable Name of the source table to sync from targettable Name of the target table to sync to Examples: For a dry run SyncTable of tableA from a remote source cluster to a local target cluster: $ bin/hbase org.apache.hadoop.hbase.mapreduce.SyncTable --dryrun=true --sourcezkcluster=zk1.example.com,zk2.example.com,zk3.example.com:2181:/hbase hdfs://nn:9000/hashes/tableA tableA tableA ``` 當需要只讀，差異報告時， **dryrun** 選項很有用，因為它只會產生指示差異的 COUNTERS，但不會執行任何實際更改。它可以用作 VerifyReplication 工具的替代方案。 默認情況下，SyncTable 將使目標表成為源表的精確副本（至少，對于指定的 startrow / stoprow 或/和 starttime / endtime）。 將 doDeletes 設置為 false 會修改默認行為，以便不刪除源上缺少的目標單元格。同樣，將 doPuts 設置為 false 會修改默認行為，以便不在目標上添加缺少的單元格。將 doDeletes 和 doPuts 都設置為 false 會產生與將 dryrun 設置為 true 相同的效果。 > 在雙向復制方案中將 doDeletes 設置為 false > > 在雙向復制或源集群和目標集群都可以獲取數據的其他情況下，建議始終將 doDeletes 選項設置為 false，因為在 SyncTable 目標集群上插入但尚未復制到源的任何其他單元格將被刪除，并且可能永遠失去了。 > > 將 sourcezkcluster 設置為實際源群集 ZK quoru > > 雖然不是必需的，但如果未設置 sourcezkcluster，則 SyncTable 將連接到源和目標的本地 HBase 集群，這不會產生任何有意義的結果。 > > 不同 Kerberos 領域的遠程集群 > > 目前，無法為不同 Kerberos 領域上的遠程群集運行 SyncTable。有一些工作要在 [HBASE-20586](https://jira.apache.org/jira/browse/HBASE-20586) 上解決這個問題 ### 150.12。出口 Export 是一個實用程序，它將表的內容轉儲到序列文件中的 HDFS。可以通過協處理器端點或 MapReduce 運行導出。通過以下方式調用 **基于 mapreduce 的出口** ``` $ bin/hbase org.apache.hadoop.hbase.mapreduce.Export <tablename> <outputdir> [<versions> [<starttime> [<endtime>]]] ``` **基于端點的導出** > 通過將`org.apache.hadoop.hbase.coprocessor.Export`添加到`hbase.coprocessor.region.classes`，確保啟用了導出協處理器。 ``` $ bin/hbase org.apache.hadoop.hbase.coprocessor.Export <tablename> <outputdir> [<versions> [<starttime> [<endtime>]]] ``` outputdir 是導出前不存在的 HDFS 目錄。完成后，導出的文件將由調用導出命令的用戶擁有。 **基于端點的導出和基于 Mapreduce 的導出的比較** | | 基于端點的導出 | 基于 Mapreduce 的導出 | | --- | --- | --- | | HBase 版本要求 | 2.0+ | 0.2.1+ | | Maven 依賴 | HBase 的端點 | hbase-mapreduce（2.0 +），hbase-server（2.0 之前） | | 轉儲前的要求 | 在目標表上掛載 endpoint.Export | 部署 MapReduce 框架 | | 讀延遲 | 低，直接從區域讀取數據 | 傳統的 RPC 掃描 | | 讀可伸縮性 | 取決于地區的數量 | 取決于映射器的數量（請參閱 TableInputFormatBase #getSplits） | | 超時 | 操作超時。由 hbase.client.operation.timeout 配置 | 掃描超時。由 hbase.client.scanner.timeout.period 配置 | | 許可要求 | 閱讀，執行 | 讀 | | 容錯 | 沒有 | 取決于 MapReduce | > 要查看使用說明，請運行不帶任何選項的命令。可用選項包括指定列族和導出期間應用過濾器。 默認情況下，`Export`工具僅導出給定單元格的最新版本，而不管存儲的版本數量。要導出多個版本，請用所需的版本數替換。 注意：輸入掃描的緩存是通過作業配置中的`hbase.client.scanner.caching`配置的。 ### 150.13。進口 Import 是一個實用程序，它將加載已導出回 HBase 的數據。通過以下方式調用 ``` $ bin/hbase org.apache.hadoop.hbase.mapreduce.Import <tablename> <inputdir> ``` > 要查看使用說明，請運行不帶任何選項的命令。 要在 0.96 群集中或之后導入 0.94 導出的文件，您需要在運行導入命令時設置系統屬性“hbase.import.version”，如下所示： ``` $ bin/hbase -Dhbase.import.version=0.94 org.apache.hadoop.hbase.mapreduce.Import <tablename> <inputdir> ``` ### 150.14。 ImportTsv ImportTsv 是一個實用程序，它將 TSV 格式的數據加載到 HBase 中。它有兩個不同的用法：通過 Puts 將數據從 HDFS 中的 TSV 格式加載到 HBase 中，并準備通過`completebulkload`加載 StoreFiles。 通過 Puts 加載數據（即非批量加載）： ``` $ bin/hbase org.apache.hadoop.hbase.mapreduce.ImportTsv -Dimporttsv.columns=a,b,c <tablename> <hdfs-inputdir> ``` 要生成 StoreFiles 以進行批量加載： ``` $ bin/hbase org.apache.hadoop.hbase.mapreduce.ImportTsv -Dimporttsv.columns=a,b,c -Dimporttsv.bulk.output=hdfs://storefile-outputdir <tablename> <hdfs-data-inputdir> ``` 這些生成的 StoreFiles 可以通過 [completebulkload](#completebulkload) 加載到 HBase 中。 #### 150.14.1。 ImportTsv 選項 不帶參數運行`ImportTsv`會打印簡要的用法信息： ``` Usage: importtsv -Dimporttsv.columns=a,b,c <tablename> <inputdir> Imports the given input directory of TSV data into the specified table. The column names of the TSV data must be specified using the -Dimporttsv.columns option. This option takes the form of comma-separated column names, where each column name is either a simple column family, or a columnfamily:qualifier. The special column name HBASE_ROW_KEY is used to designate that this column should be used as the row key for each imported record. You must specify exactly one column to be the row key, and you must specify a column name for every column that exists in the input data. By default importtsv will load data directly into HBase. To instead generate HFiles of data to prepare for a bulk data load, pass the option: -Dimporttsv.bulk.output=/path/for/output Note: the target table will be created with default column family descriptors if it does not already exist. Other options that may be specified with -D include: -Dimporttsv.skip.bad.lines=false - fail if encountering an invalid line '-Dimporttsv.separator=|' - eg separate on pipes instead of tabs -Dimporttsv.timestamp=currentTimeAsLong - use the specified timestamp for the import -Dimporttsv.mapper.class=my.Mapper - A user-defined Mapper to use instead of org.apache.hadoop.hbase.mapreduce.TsvImporterMapper ``` #### 150.14.2。 ImportTsv 示例 例如，假設我們將數據加載到名為'datatsv'的表中，其中 ColumnFamily 稱為'd'，其中包含兩列“c1”和“c2”。 假設輸入文件存在如下： ``` row1 c1 c2 row2 c1 c2 row3 c1 c2 row4 c1 c2 row5 c1 c2 row6 c1 c2 row7 c1 c2 row8 c1 c2 row9 c1 c2 row10 c1 c2 ``` 要使 ImportTsv 使用此輸入文件，命令行需要如下所示： ``` HADOOP_CLASSPATH=`${HBASE_HOME}/bin/hbase classpath` ${HADOOP_HOME}/bin/hadoop jar ${HBASE_HOME}/hbase-mapreduce-VERSION.jar importtsv -Dimporttsv.columns=HBASE_ROW_KEY,d:c1,d:c2 -Dimporttsv.bulk.output=hdfs://storefileoutput datatsv hdfs://inputfile ``` ...在本例中，第一列是 rowkey，這就是使用 HBASE_ROW_KEY 的原因。文件中的第二列和第三列將分別導入為“d：c1”和“d：c2”。 #### 150.14.3。 ImportTsv 警告 如果您準備了大量數據以進行批量加載，請確保對目標 HBase 表進行適當的預分割。 #### 150.14.4。也可以看看 有關將 HFiles 批量加載到 HBase 中的更多信息，請參見 [arch.bulk.load](#arch.bulk.load) ### 150.15。 CompleteBulkLoad `completebulkload`實用程序會將生成的 StoreFiles 移動到 HBase 表中。該實用程序通常與 [importtsv](#importtsv) 的輸出結合使用。 有兩種方法可以通過顯式類名和驅動程序調用此實用程序： 顯式類名 ``` $ bin/hbase org.apache.hadoop.hbase.tool.LoadIncrementalHFiles <hdfs://storefileoutput> <tablename> ``` 司機 ``` HADOOP_CLASSPATH=`${HBASE_HOME}/bin/hbase classpath` ${HADOOP_HOME}/bin/hadoop jar ${HBASE_HOME}/hbase-server-VERSION.jar completebulkload <hdfs://storefileoutput> <tablename> ``` #### 150.15.1。 CompleteBulkLoad 警告 通過 MapReduce 生成的數據通常使用與正在運行的 HBase 進程不兼容的文件權限創建。假設您在啟用權限的情況下運行 HDFS，則需要在運行 CompleteBulkLoad 之前更新這些權限。 有關將 HFile 批量加載到 HBase 中的更多信息，請參見 [arch.bulk.load](#arch.bulk.load) 。 ### 150.16。 WALPlayer WALPlayer 是一個將 WAL 文件重放到 HBase 中的實用程序。 可以為一組表或所有表重放 WAL，并且可以提供時間范圍（以毫秒為單位）。 WAL 被過濾到這組表。輸出可以選擇性地映射到另一組表。 WALPlayer 還可以生成 HFile 以供以后批量導入，在這種情況下，只能指定一個表，并且不能指定映射。 通過以下方式調用 ``` $ bin/hbase org.apache.hadoop.hbase.mapreduce.WALPlayer [options] <wal inputdir> <tables> [<tableMappings>]> ``` 例如： ``` $ bin/hbase org.apache.hadoop.hbase.mapreduce.WALPlayer /backuplogdir oldTable1,oldTable2 newTable1,newTable2 ``` 默認情況下，WALPlayer 作為 mapreduce 作業運行。若要不將 WALPlayer 作為集群上的 mapreduce 作業運行，請通過在命令行上添加標志`-Dmapreduce.jobtracker.address=local`來強制它在本地進程中運行。 #### 150.16.1。 WALPlayer 選項 不帶參數運行`WALPlayer`會打印簡要的用法信息： ``` Usage: WALPlayer [options] <wal inputdir> <tables> [<tableMappings>] Replay all WAL files into HBase. <tables> is a comma separated list of tables. If no tables ("") are specified, all tables are imported. (Be careful, hbase:meta entries will be imported in this case.) WAL entries can be mapped to new set of tables via <tableMappings>. <tableMappings> is a comma separated list of target tables. If specified, each table in <tables> must have a mapping. By default WALPlayer will load data directly into HBase. To generate HFiles for a bulk data load instead, pass the following option: -Dwal.bulk.output=/path/for/output (Only one table can be specified, and no mapping is allowed!) Time range options: -Dwal.start.time=[date|ms] -Dwal.end.time=[date|ms] (The start and the end date of timerange. The dates can be expressed in milliseconds since epoch or in yyyy-MM-dd'T'HH:mm:ss.SS format. E.g. 1234567890120 or 2009-02-13T23:32:30.12) Other options: -Dmapreduce.job.name=jobName Use the specified mapreduce job name for the wal player For performance also consider the following options: -Dmapreduce.map.speculative=false -Dmapreduce.reduce.speculative=false ``` ### 150.17。 RowCounter [RowCounter](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/RowCounter.html) 是一個 mapreduce 作業，用于計算表的所有行。這是一個很好的實用程序，可用作健全性檢查，以確保如果存在元數據不一致的問題，HBase 可以讀取表的所有塊。它將在一個進程中運行 mapreduce，但如果你有一個 MapReduce 集群可以利用它，它將運行得更快。可以使用`--starttime=[starttime]`和`--endtime=[endtime]`標志限制要掃描的數據的時間范圍。可以使用`--range=[startKey],[endKey][;[startKey],[endKey]…?]`選項基于鍵限制掃描數據。 ``` $ bin/hbase rowcounter [options] <tablename> [--starttime=<start> --endtime=<end>] [--range=[startKey],[endKey][;[startKey],[endKey]...]] [ ...] ``` RowCounter 每個單元只計算一個版本。 性能考慮使用`-Dhbase.client.scanner.caching=100`和`-Dmapreduce.map.speculative=false`選項。 ### 150.18。 CellCounter HBase 發布了另一個叫做 [CellCounter](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/mapreduce/CellCounter.html) 的診斷 mapreduce 工作。與 RowCounter 一樣，它收集有關您的表的更細粒度的統計信息。 CellCounter 收集的統計數據更精細，包括： * 表中的總行數。 * 所有行中的 CF 總數。 * 所有行的總限定符。 * 每個 CF 的總發生次數。 * 每個限定符的總出現次數。 * 每個限定符的版本總數。 該程序允許您限制運行的范圍。提供行正則表達式或前綴以限制要分析的行。使用`--starttime=&lt;starttime&gt;`和`--endtime=&lt;endtime&gt;`標志指定掃描表的時間范圍。 使用`hbase.mapreduce.scan.column.family`指定掃描單列族。 ``` $ bin/hbase cellcounter <tablename> <outputDir> [reportSeparator] [regex or prefix] [--starttime=<starttime> --endtime=<endtime>] ``` 注意：就像 RowCounter 一樣，輸入的緩存掃描是通過作業配置中的`hbase.client.scanner.caching`配置的。 ### 150.19。 mlockall 用于 通過讓服務器在啟動時調用 [mlockall](http://linux.die.net/man/2/mlockall) ，可以選擇將服務器固定在物理內存中，從而降低在超額訂閱環境中換出的可能性。參見 [HBASE-4391 添加以 root 身份啟動 RS 的功能，并調用 mlockall](https://issues.apache.org/jira/browse/HBASE-4391) 了解如何構建可選庫并使其在啟動時運行。 ### 150.20。離線壓縮工具 **CompactionTool** 提供了一種運行壓縮（次要或主要）作為 RegionServer 的獨立進程的方法。它重用了 RegionServer 壓縮功能執行的相同內部實現類。但是，由于它在一個完全獨立的獨立 java 進程上運行，因此它會從重寫一組 hfiles 所涉及的開銷中釋放 RegionServers，這對于延遲敏感的用例非常重要。 Usage: ``` $ ./bin/hbase org.apache.hadoop.hbase.regionserver.CompactionTool Usage: java org.apache.hadoop.hbase.regionserver.CompactionTool \ [-compactOnce] [-major] [-mapred] [-D<property=value>]* files... Options: mapred Use MapReduce to run compaction. compactOnce Execute just one compaction step. (default: while needed) major Trigger major compaction. Note: -D properties will be applied to the conf used. For example: To stop delete of compacted file, pass -Dhbase.compactiontool.delete=false To set tmp dir, pass -Dhbase.tmp.dir=ALTERNATE_DIR Examples: To compact the full 'TestTable' using MapReduce: $ hbase org.apache.hadoop.hbase.regionserver.CompactionTool -mapred hdfs://hbase/data/default/TestTable To compact column family 'x' of the table 'TestTable' region 'abc': $ hbase org.apache.hadoop.hbase.regionserver.CompactionTool hdfs://hbase/data/default/TestTable/abc/x ``` 如上面的使用選項所示， **CompactionTool** 可以作為獨立客戶端或 mapreduce 作業運行。當作為 mapreduce 作業運行時，每個族目錄都作為輸入拆分處理，并由單獨的映射任務處理。 **compactionOnce** 參數控制在 **CompactionTool** 程序決定完成其工作之前將執行多少次壓縮循環。如果省略，它將假定它應該在每個指定的族上繼續運行壓縮，這由配置的給定壓縮策略確定。有關壓縮策略的更多信息，請參閱[壓縮](#compaction)。 如果需要進行主要壓實，可以指定**主要**標志。如果省略， **CompactionTool** 將假定默認需要較小的壓縮。 它還允許使用`-D`標志進行配置覆蓋。例如，在上面的使用部分中，`-Dhbase.compactiontool.delete=false`選項將指示壓縮引擎不從 temp 文件夾中刪除原始文件。 必須將目標為壓縮的文件指定為父 hdfs dirs。它允許多個 dirs 定義，只要這些 dirs 的每一個都是**家族**，**區域**或**表** dir。如果傳遞了表或區域目錄，程序將遞歸遍歷相關的子文件夾，有效地為表/區域級別下面的每個族運行壓縮。 由于這些目錄嵌套在 **hbase** hdfs 目錄樹下， **CompactionTool** 需要 hbase 超級用戶權限才能訪問所需的 hfiles。 > 在 MapReduce mod 中運行 > > MapReduce 模式提供了并行處理每個族目錄的功能，作為單獨的地圖任務。通常，在指定一個或多個表目錄作為壓縮目標時，以此模式運行是有意義的。但需要注意的是，如果要壓縮的族數變得太大，相關的 mapreduce 工作可能會對 **RegionServers** 的性能產生間接影響。由于 **NodeManagers** 通常與 RegionServers 共存，因此這些大型作業可能會與 **RegionServers** 競爭 IO /帶寬資源。 > > 由于性能影響，MajorSeraction 在 RegionServers 上完全禁用 > > **主要壓縮**可能是一項代價高昂的操作（參見[壓縮](#compaction)），并且確實可以影響 RegionServers 的性能，導致運營商完全禁用它以用于關鍵的低延遲應用。 **CompactionTool** 可以在這種情況下用作替代方案，但是，需要實現額外的自定義應用程序邏輯，例如決定給定壓縮運行的表/區域/族目標的調度和選擇。 有關 CompactionTool 的其他詳細信息，另請參閱 [CompactionTool](https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/regionserver/CompactionTool.html) 。 ### 150.21。 `hbase clean` `hbase clean`命令清除 ZooKeeper，HDFS 或兩者中的 HBase 數據。適合用于測試。運行它沒有使用說明選項。 `hbase clean`命令在 HBase 0.98 中引入。 ``` $ bin/hbase clean Usage: hbase clean (--cleanZk|--cleanHdfs|--cleanAll) Options: --cleanZk cleans hbase related data from zookeeper. --cleanHdfs cleans hbase related data from hdfs. --cleanAll cleans hbase related data from both zookeeper and hdfs. ``` ### 150.22。 `hbase pe` `hbase pe`命令運行 PerformanceEvaluation 工具，該工具用于測試。 PerformanceEvaluation 工具接受許多不同的選項和命令。有關使用說明，請運行不帶任何選項的命令。 PerformanceEvaluation 工具在最近的 HBase 版本中收到了許多更新，包括對命名空間的支持，對標簽的支持，單元級 ACL 和可見性標簽，對 RPC 調用的多重支持，增加的采樣大小，在測試期間隨機休眠的選項以及能力在測試開始之前“預熱”集群。 ### 150.23。 `hbase ltt` `hbase ltt`命令運行 LoadTestTool 實用程序，該實用程序用于測試。 您必須指定`-init_only`或`-write`，`-update`或`-read`中的至少一個。有關一般使用說明，請傳遞`-h`選項。 LoadTestTool 在最近的 HBase 版本中收到了許多更新，包括對命名空間的支持，對標簽的支持，單元級 ACLS 和可見性標簽，測試安全相關功能，指定每臺服務器的區域數量的能力，多次獲取 RPC 的測試呼叫和與復制有關的測試。 ### 150.24。升級前驗證程序 在從 HBase 1 升級到 HBase 2 之前，可以使用升級前驗證工具檢查群集是否存在已知的不兼容性。 ``` $ bin/hbase pre-upgrade command ... ``` #### 150.24.1。協處理器驗證 HBase 長期支持協處理器，但協處理器 API 可以在主要版本之間進行更改。協處理器驗證器嘗試確定舊的協處理器是否仍與實際的 HBase 版本兼容。 ``` $ bin/hbase pre-upgrade validate-cp [-jar ...] [-class ... | -table ... | -config] Options: -e Treat warnings as errors. -jar <arg> Jar file/directory of the coprocessor. -table <arg> Table coprocessor(s) to check. -class <arg> Coprocessor class(es) to check. -config Scan jar for observers. ``` 協處理器類可以通過`-class`選項顯式聲明，也可以通過`-config`選項從 HBase 配置中獲取。表級協處理器也可以通過`-table`選項進行檢查。該工具在其類路徑上搜索協處理器，但可以通過`-jar`選項進行擴展。可以使用多個`-class`測試多個類，使用多個`-table`選項測試多個表，并使用多個`-jar`選項將多個 jar 添加到類路徑中。 該工具可以報告錯誤和警告。錯誤意味著 HBase 將無法加載協處理器，因為它與當前版本的 HBase 不兼容。警告意味著可以加載協處理器，但它們無法按預期工作。如果給出`-e`選項，則該工具也將失敗以發出警告。 請注意，此工具無法驗證 jar 文件的每個方面，它只是進行一些靜態檢查。 For example: ``` $ bin/hbase pre-upgrade validate-cp -jar my-coprocessor.jar -class MyMasterObserver -class MyRegionObserver ``` 它驗證位于`my-coprocessor.jar`中的`MyMasterObserver`和`MyRegionObserver`類。 ``` $ bin/hbase pre-upgrade validate-cp -table .* ``` 它驗證表名與`.*`正則表達式匹配的每個表級協處理器。 #### 150.24.2。 DataBlockEncoding 驗證 HBase 2.0 從列族中刪除了`PREFIX_TREE`數據塊編碼。有關詳細信息，請檢查 [_ 前綴樹 _ 編碼已刪除](#upgrade2.0.prefix-tree.removed)。要驗證沒有任何列族在群集中使用不兼容的數據塊編碼，請運行以下命令。 ``` $ bin/hbase pre-upgrade validate-dbe ``` 此檢查驗證所有列族并打印出任何不兼容性。例如： ``` 2018-07-13 09:58:32,028 WARN [main] tool.DataBlockEncodingValidator: Incompatible DataBlockEncoding for table: t, cf: f, encoding: PREFIX_TREE ``` 這意味著表`t`，列族`f`的數據塊編碼不兼容。要修復，請在 HBase shell 中使用`alter`命令： ``` alter 't', { NAME => 'f', DATA_BLOCK_ENCODING => 'FAST_DIFF' } ``` 還請驗證 HFiles，這將在下一節中介紹。 #### 150.24.3。 HFile 內容驗證 即使數據塊編碼從`PREFIX_TREE`更改，仍然可能有包含以這種方式編碼的數據的 HFile。要驗證 HFiles 是否可用 HBase 2 讀取，請使用 _HFile 內容驗證器 _。 ``` $ bin/hbase pre-upgrade validate-hfile ``` 該工具將記錄損壞的 HFile 和有關根本原因的詳細信息。如果問題與 PREFIX_TREE 編碼有關，則必須在升級到 HBase 2 之前更改編碼。 以下日志消息顯示錯誤 HFile 的示例。 ``` 2018-06-05 16:20:46,976 WARN [hfilevalidator-pool1-t3] hbck.HFileCorruptionChecker: Found corrupt HFile hdfs://example.com:8020/hbase/data/default/t/72ea7f7d625ee30f959897d1a3e2c350/prefix/7e6b3d73263c4851bf2b8590a9b3791e org.apache.hadoop.hbase.io.hfile.CorruptHFileException: Problem reading HFile Trailer from file hdfs://example.com:8020/hbase/data/default/t/72ea7f7d625ee30f959897d1a3e2c350/prefix/7e6b3d73263c4851bf2b8590a9b3791e ... Caused by: java.io.IOException: Invalid data block encoding type in file info: PREFIX_TREE ... Caused by: java.lang.IllegalArgumentException: No enum constant org.apache.hadoop.hbase.io.encoding.DataBlockEncoding.PREFIX_TREE ... 2018-06-05 16:20:47,322 INFO [main] tool.HFileContentValidator: Corrupted file: hdfs://example.com:8020/hbase/data/default/t/72ea7f7d625ee30f959897d1a3e2c350/prefix/7e6b3d73263c4851bf2b8590a9b3791e 2018-06-05 16:20:47,383 INFO [main] tool.HFileContentValidator: Corrupted file: hdfs://example.com:8020/hbase/archive/data/default/t/56be41796340b757eb7fff1eb5e2a905/f/29c641ae91c34fc3bee881f45436b6d1 ``` ##### 修復 PREFIX_TREE 錯誤 將數據塊編碼更改為支持的數據塊編碼后，可能會出現`PREFIX_TREE`錯誤。之所以會發生這種情況，是因為有些 HFile 仍然使用`PREFIX_TREE`進行編碼，或者仍有一些快照。 為了修復 HFiles，請在表上運行一個主要的壓縮（根據日志消息它是`default:t`）： ``` major_compact 't' ``` HFile 也可以從快照中引用。當 HFile 位于`archive/data`下時就是這種情況。第一步是根據日志確定哪些快照引用 HFile（文件名是`29c641ae91c34fc3bee881f45436b6d1`）： ``` for snapshot in $(hbase snapshotinfo -list-snapshots 2> /dev/null | tail -n -1 | cut -f 1 -d \|); do echo "checking snapshot named '${snapshot}'"; hbase snapshotinfo -snapshot "${snapshot}" -files 2> /dev/null | grep 29c641ae91c34fc3bee881f45436b6d1; done ``` 這個 shell 腳本的輸出是： ``` checking snapshot named 't_snap' 1.0 K t/56be41796340b757eb7fff1eb5e2a905/f/29c641ae91c34fc3bee881f45436b6d1 (archive) ``` 這意味著`t_snap`快照引用了不兼容的 HFile。如果仍然需要快照，則必須使用 HBase shell 重新創建快照： ``` # creating a new namespace for the cleanup process create_namespace 'pre_upgrade_cleanup' # creating a new snapshot clone_snapshot 't_snap', 'pre_upgrade_cleanup:t' alter 'pre_upgrade_cleanup:t', { NAME => 'f', DATA_BLOCK_ENCODING => 'FAST_DIFF' } major_compact 'pre_upgrade_cleanup:t' # removing the invalid snapshot delete_snapshot 't_snap' # creating a new snapshot snapshot 'pre_upgrade_cleanup:t', 't_snap' # removing temporary table disable 'pre_upgrade_cleanup:t' drop 'pre_upgrade_cleanup:t' drop_namespace 'pre_upgrade_cleanup' ``` 有關詳細信息，請參閱 [HBASE-20649](https://issues.apache.org/jira/browse/HBASE-20649?focusedCommentId=16535476#comment-16535476) 。 ### 150.25。數據塊編碼工具 使用不同的數據塊編碼器測試各種壓縮算法，以便在現有的 HFile 上進行密鑰壓縮。用于測試，調試和基準測試。 您必須指定`-f`，這是 HFile 的完整路徑。 結果顯示了壓縮/解壓縮和編碼/解碼的性能（MB / s），以及 HFile 上的數據節省。 ``` $ bin/hbase org.apache.hadoop.hbase.regionserver.DataBlockEncodingTool Usages: hbase org.apache.hadoop.hbase.regionserver.DataBlockEncodingTool Options: -f HFile to analyse (REQUIRED) -n Maximum number of key/value pairs to process in a single benchmark run. -b Whether to run a benchmark to measure read throughput. -c If this is specified, no correctness testing will be done. -a What kind of compression algorithm use for test. Default value: GZ. -t Number of times to run each benchmark. Default value: 12. -omit Number of first runs of every benchmark to omit from statistics. Default value: 2. ``` ## 151.區域管理 ### 151.1。主要壓實 可以通過 HBase shell 或 [Admin.majorCompact](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Admin.html#majorCompact-org.apache.hadoop.hbase.TableName-) 請求主要壓縮。 注意：主要壓縮不進行區域合并。有關壓縮的更多信息，請參見[壓縮](#compaction)。 ### 151.2。合并 Merge 是一個可以合并同一個表中相鄰區域的實用程序（請參閱 org.apache.hadoop.hbase.util.Merge）。 ``` $ bin/hbase org.apache.hadoop.hbase.util.Merge <tablename> <region1> <region2> ``` 如果您覺得自己擁有太多區域并希望對它們進行整合，那么 Merge 就是您需要的實用程序。必須在群集關閉時運行合并。有關用法示例，請參閱 [O'Reilly HBase Book](https://web.archive.org/web/20111231002503/http://ofps.oreilly.com/titles/9781449396107/performance.html) 。 您需要將 3 個參數傳遞給此應用程序。第一個是表名。第二個是要合并的第一個區域的完全限定名稱，例如“table_name，\ x0A，1342956111995.7cef47f192318ba7ccc75b1bbf27a82b。”。第三個是要合并的第二個區域的完全限定名稱。 此外，還有一個 Ruby 腳本附加到 [HBASE-1621](https://issues.apache.org/jira/browse/HBASE-1621) 以進行區域合并。 ## 152.節點管理 ### 152.1。節點退役 您可以通過在特定節點上的 HBase 目錄中運行以下腳本來停止單個 RegionServer： ``` $ ./bin/hbase-daemon.sh stop regionserver ``` RegionServer 將首先關閉所有區域，然后自行關閉。關閉時，ZooKeeper 中 RegionServer 的臨時節點將過期。主人會注意到 RegionServer 已經消失，并將其視為“崩潰”的服務器;它將重新分配 RegionServer 攜帶的節點。 > 在退役之前禁用負載均衡器 > > 如果負載均衡器在節點關閉時運行，那么負載均衡器和主服務器恢復剛剛停用的 RegionServer 之間可能存在爭用。首先禁用平衡器，避免任何問題。見下面的 [lb](#lb) 。 > > 殺死節點 > > 在 hbase-2.0 中，在 bin 目錄中，我們添加了一個名為 _ConsideAsDead.sh_ 的腳本，可用于殺死 regionserver。在 zookeeper 超時到期之前，專用監視工具可以檢測到硬件問題。 _ 考慮 AsDead.sh_ 是一個將 RegionServer 標記為死的簡單函數。它刪除服務器的所有 znode，開始恢復過程。將腳本插入監視/故障檢測工具以啟動更快的故障轉移。小心如何使用這種破壞性工具。如果需要在 hbase-2.0 之前的 hbase 版本中使用它，請復制腳本。 上述區域服務器停止的一個缺點是區域可能會在很長一段時間內脫機。地區按順序關閉。如果服務器上有許多區域，則關閉的第一個區域可能不會重新聯機，直到所有區域關閉并且在主站注意到 RegionServer 的 znode 消失之后。在 Apache HBase 0.90.2 中，我們添加了一個設備，讓節點逐漸減少負載，然后關閉自己。 Apache HBase 0.90.2 添加了 _graceful _stop.sh_ 腳本。這是它的用法： ``` $ ./bin/graceful_stop.sh Usage: graceful_stop.sh [--config &conf-dir>] [--restart] [--reload] [--thrift] [--rest] &hostname> thrift If we should stop/start thrift before/after the hbase stop/start rest If we should stop/start rest before/after the hbase stop/start restart If we should restart after graceful stop reload Move offloaded regions back on to the stopped server debug Move offloaded regions back on to the stopped server hostname Hostname of server we are to stop ``` 要停用已加載的 RegionServer，請運行以下命令：$ ./bin/graceful_stop.sh HOSTNAME 其中`HOSTNAME`是承載您將停用的 RegionServer 的主機。 > 在'HOSTNAME 上 > > 傳遞給 _graceful _stop.sh_ 的`HOSTNAME`必須與 hbase 用于識別 RegionServers 的主機名匹配。檢查主 UI 中的 RegionServers 列表，了解 HBase 如何引用服務器。它通常是主機名，但也可以是 FQDN。無論 HBase 使用什么，這都應該通過 _graceful _stop.sh_ 解除授權腳本。如果您傳遞 IP，則該腳本還不夠智能，無法創建它的主機名（或 FQDN），因此在檢查服務器當前是否正在運行時它將失敗;優雅的地區卸貨將無法運行。 _graceful _stop.sh_ 腳本將一次一個地移出退役的 RegionServer 區域，以最大限度地減少區域流失。它將在移動下一個區域之前驗證在新位置部署的區域，依此類推，直到退役的服務器攜帶零區域。此時，_graceful _stop.sh_ 告訴 RegionServer `stop`。此時主服務器會注意到 RegionServer 已經消失但所有區域都已經重新部署，并且因為 RegionServer 干凈利落，所以沒有 WAL 日志可以拆分。 > 負載均衡器 > > 假設在`graceful_stop`腳本運行時禁用了區域負載平衡器（否則平衡器和解除授權腳本將最終爭奪區域部署）。使用 shell 禁用平衡器： > > ``` > hbase(main):001:0&gt; balance_switch false > true > 0 row(s) in 0.3590 seconds > ``` > > 這會關閉平衡器。要啟用，請執行： > > ``` > hbase(main):001:0&gt; balance_switch true > false > 0 row(s) in 0.3590 seconds > ``` > > `graceful_stop`將檢查平衡器，如果啟用，將在其開始工作前將其關閉。如果由于錯誤而提前退出，則不會重置平衡器。因此，除了`graceful_stop`在完成 w / graceful_stop 之后重新啟用平衡器之外，最好還是管理平衡器。 #### 152.1.1。同時停用多個 Regions 服務器 如果您有一個大型群集，則可能希望通過同時正常停止多個 RegionServers 來同時停用多臺計算機。為了同時優雅地排空多個區域服務器，可以將 RegionServers 置于“排空”狀態。這是通過在 _hbase _root / draining_ znode 下的 ZooKeeper 中創建一個條目，將 RegionServer 標記為引出節點來完成的。這個 znode 的格式`name,port,startcode`就像 _hbase _root / rs_ znode 下的 regionserver 條目一樣。 沒有這種設施，退出多個節點可能是非最佳的，因為從一個區域服務器排出的區域可能被移動到也正在耗盡的其他區域服務器。將 RegionServers 標記為處于排水狀態會阻止這種情況發生。有關詳細信息，請參閱[博客文章](http://inchoate-clatter.blogspot.com/2012/03/hbase-ops-automation.html)。 #### 152.1.2。壞或失敗的磁盤 如果在磁盤普通模具的情況下每臺機器有相當數量的磁盤，那么設置 [dfs.datanode.failed.volumes.tolerated](#dfs.datanode.failed.volumes.tolerated) 就可以了。但通常磁盤會執行“John Wayne” - 即在 _dmesg_ 中花費一段時間來減少噴射錯誤 - 或者由于某種原因，運行速度比他們的同伴慢得多。在這種情況下，您希望停用磁盤。你有兩個選擇。您可以[停用 datanode](https://wiki.apache.org/hadoop/FAQ#I_want_to_make_a_large_cluster_smaller_by_taking_out_a_bunch_of_nodes_simultaneously._How_can_this_be_done.3F) ，或者破壞性較小，因為只有壞磁盤數據會被重新復制，可以停止 datanode，卸載壞卷（在 datanode 使用它時你無法卸載卷） ，然后重新啟動 datanode（假設您已設置 dfs.datanode.failed.volumes.tolerated＆gt; 0）。區域服務器會在其日志中拋出一些錯誤，因為它會重新校準從哪里獲取數據 - 它也可能會滾動其 WAL 日志 - 但總的來說，但是對于某些延遲峰值，它應該繼續保持正常運行。 > 短路讀 > > 如果您正在進行短路讀取，則必須在停止 datanode 之前將區域移出 regionserver;當短路讀取時，雖然 chmod'd 區域服務器無法訪問，因為它已經打開文件，即使 datanode 已關閉，它也能夠繼續從壞磁盤讀取文件塊。重新啟動 datanode 后，將區域移回。 ### 152.2。滾動重啟 某些群集配置更改需要重新啟動整個群集或 RegionServers 才能獲取更改。此外，支持滾動重新啟動以升級到次要版本或維護版本，如果可能的話，還支持主要版本。請參閱要升級到的發行版的發行說明，以了解執行滾動升級的能力限制。 根據您的具體情況，有多種方法可以重新啟動群集節點。這些方法詳述如下。 #### 152.2.1。使用`rolling-restart.sh`腳本 HBase 附帶一個腳本 _bin / rolling-restart.sh_ ，它允許您在整個集群，僅主服務器或 RegionServers 上執行滾動重新啟動。該腳本作為您自己腳本的模板提供，未經過明確測試。它需要配置無密碼的 SSH 登錄，并假定您已使用 tarball 進行部署。該腳本要求您在運行之前設置一些環境變量。檢查腳本并根據需要進行修改。 _rolling-restart.sh_ 一般用法 ``` $ ./bin/rolling-restart.sh --help Usage: rolling-restart.sh [--config <hbase-confdir>] [--rs-only] [--master-only] [--graceful] [--maxthreads xx] ``` 僅在 RegionServers 上滾動重新啟動 要僅在 RegionServers 上執行滾動重新啟動，請使用`--rs-only`選項。如果您需要重新啟動單個 RegionServer，或者進行僅影響 RegionServers 而不影響其他 HBase 進程的配置更改，則可能需要執行此操作。 僅在 Masters 上滾動重啟 要在活動和備份主站上執行滾動重新啟動，請使用`--master-only`選項。如果您知道配置更改僅影響主服務器而不影響 RegionServers，或者您需要重新啟動運行主服務器的服務器，則可以使用此方法。 優雅的重啟 如果指定`--graceful`選項，則使用 _bin / graceful _stop.sh_ 腳本重新啟動 RegionServers，該腳本會在重新啟動 RegionServer 之前將區域移出 RegionServer。這樣更安全，但可以延遲重啟。 限制線程數 要將滾動重啟限制為僅使用特定數量的線程，請使用`--maxthreads`選項。 #### 152.2.2。手動滾動重啟 要保留對流程的更多控制，您可能希望在群集中手動執行滾動重新啟動。這使用`graceful-stop.sh`命令[退役](#decommission)。在此方法中，您可以單獨重新啟動每個 RegionServer，然后將其舊區域移回原位，保留位置。如果還需要重新啟動主服務器，則需要單獨執行此操作，并在使用此方法重新啟動 RegionServers 之前重新啟動主服務器。以下是此類命令的示例。您可能需要根據您的環境進行定制。此腳本僅對 RegionServers 進行滾動重新啟動。它在移動區域之前禁用負載平衡器。 ``` $ for i in `cat conf/regionservers|sort`; do ./bin/graceful_stop.sh --restart --reload --debug $i; done &> /tmp/log.txt &; ``` 監視 _/tmp/log.txt_ 文件的輸出以跟蹤腳本的進度。 #### 152.2.3。制作自己的滾動重啟腳本的邏輯 如果要創建自己的滾動重新啟動腳本，請使用以下準則。 1. 解壓縮新版本，驗證其配置，并使用`rsync`，`scp`或其他安全同步機制將其同步到群集的所有節點。 2. 首先重啟 master。如果新的 HBase 目錄與舊的 HBase 目錄不同，則可能需要修改這些命令，例如升級。 ``` $ ./bin/hbase-daemon.sh stop master; ./bin/hbase-daemon.sh start master ``` 3. 從 Master 中使用以下腳本正常重新啟動每個 RegionServer。 ``` $ for i in `cat conf/regionservers|sort`; do ./bin/graceful_stop.sh --restart --reload --debug $i; done &&gt; /tmp/log.txt & ``` 如果您正在運行 Thrift 或 REST 服務器，請傳遞--thrift 或--rest 選項。對于其他可用選項，請運行`bin/graceful-stop.sh --help`命令。 重啟多個 RegionServers 時，重要的是要慢慢耗盡 HBase 區域。否則，多個區域同時脫機，必須重新分配給其他節點，這些節點也可能很快脫機。這可能會對性能產生負面影響。您可以在上面的腳本中注入延遲，例如，通過添加 Shell 命令，例如`sleep`。要在每次 RegionServer 重新啟動之間等待 5 分鐘，請將以上腳本修改為以下內容： ``` $ for i in `cat conf/regionservers|sort`; do ./bin/graceful_stop.sh --restart --reload --debug $i & sleep 5m; done &&gt; /tmp/log.txt & ``` 4. 再次重新啟動 Master，清除死服務器列表并重新啟用負載均衡器。 ### 152.3。添加新節點 在 HBase 中添加一個新的 regionserver 基本上是免費的，你只需這樣啟動：`$ ./bin/hbase-daemon.sh start regionserver`它將自己注冊到 master。理想情況下，您還在同一臺計算機上啟動了 DataNode，以便 RS 最終可以開始擁有本地文件。如果您依靠 ssh 來啟動守護進程，請不要忘記在主服務器上的 _conf / regionservers_ 中添加新主機名。 此時，區域服務器不提供數據，因為還沒有區域移動到它。如果啟用了平衡器，它將開始將區域移動到新 RS。在小型/中型群集上，這會對延遲產生非常不利的影響，因為許多區域將同時脫機。因此，建議在停用節點并手動移動區域時使用相同的方式禁用平衡器（或者更好，使用逐個移動它們的腳本）。 移動的區域都將具有 0％的位置，并且緩存中不會有任何塊，因此區域服務器必須使用網絡來處理請求。除了導致更高的延遲，它還可以使用您的所有網卡容量。出于實際目的，請考慮標準的 1GigE NIC 不能讀取比 _100MB / s_ 更多的內容。在這種情況下，或者如果您處于 OLAP 環境中并且需要具有位置，則建議主要壓縮移動的區域。 ## 153\. HBase 指標 HBase 會發出符合 [Hadoop 指標](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Metrics.html) API 的指標。從 HBase 0.95 &lt;sup class="footnote"&gt;[ [5](#_footnote_5 "View footnote.") ]&lt;/sup&gt; 開始，HBase 配置為發出一組默認的度量，默認采樣周期為每 10 秒。您可以將 HBase 指標與 Ganglia 結合使用。您還可以過濾發布的指標并擴展指標框架，以捕獲適合您環境的自定義指標。 ### 153.1。度量標準設置 對于 HBase 0.95 及更新版本，HBase 附帶默認指標配置或 _sink_ 。這包括各種各樣的指標，默認情況下每 10 秒發出一次。要配置給定區域服務器的度量標準，請編輯 _conf / hadoop-metrics2-hbase.properties_ 文件。重新啟動區域服務器以使更改生效。 要更改默認接收器的采樣率，請編輯以`*.period`開頭的行。要過濾發布的指標或擴展指標框架，請參閱 [https://hadoop.apache.org/docs/current/api/org/apache/hadoop/metrics2/package-summary.html](https://hadoop.apache.org/docs/current/api/org/apache/hadoop/metrics2/package-summary.html) > HBase Metrics 和 Gangli > > 默認情況下，HBase 會為每個區域服務器發出大量指標。 Ganglia 可能難以處理所有這些指標。考慮增加 Ganglia 服務器的容量或減少 HBase 發出的指標數量。請參閱[指標過濾](https://hadoop.apache.org/docs/current/api/org/apache/hadoop/metrics2/package-summary.html#filtering)。 ### 153.2。禁用指標 要禁用區域服務器的度量標準，請編輯 _conf / hadoop-metrics2-hbase.properties_ 文件并注釋掉所有未注釋的行。重新啟動區域服務器以使更改生效。 ### 153.3。發現可用的指標 您可以瀏覽可用的指標，無論是作為 JSON 輸出還是通過 JMX，而不是列出默認情況下 HBase 發出的每個指標。為主進程和每個區域服務器進程公開不同的度量標準。 過程：訪問可用度量標準的 JSON 輸出 1. 啟動 HBase 后，訪問區域服務器的 Web UI，默認情況下為 [http：// REGIONSERVER_HOSTNAME：60030](http://REGIONSERVER_HOSTNAME:60030) （或 HBase 1.0+中的端口 16030）。 2. 單擊頂部附近的 Metrics Dump 鏈接。區域服務器的度量標準顯示為 JSON 格式的 JMX bean 的轉儲。這將轉儲所有指標名稱及其值。要在列表中包含指標描述 - 這在您探索可用內容時非常有用 - 添加查詢字符串`?description=true`，以便您的網址變為 [http：// REGIONSERVER_HOSTNAME：60030 / jmx？description = true](http://REGIONSERVER_HOSTNAME:60030/jmx?description=true) 。并非所有 bean 和屬性都有描述。 3. 要查看 Master 的指標，請改為連接到 Master 的 Web UI（默認為 [http：// localhost：60010](http://localhost:60010) 或 HBase 1.0+中的端口 16010）并單擊其 Metrics Dump 鏈接。要在列表中包含指標描述 - 這在您探索可用內容時非常有用 - 添加查詢字符串`?description=true`，以便您的網址變為 [http：// REGIONSERVER_HOSTNAME：60010 / jmx？description = true](http://REGIONSERVER_HOSTNAME:60010/jmx?description=true) 。并非所有 bean 和屬性都有描述。 您可以使用許多不同的工具通過瀏覽 MBean 來查看 JMX 內容。此過程使用`jvisualvm`，這是 JDK 中通常可用的應用程序。 過程：瀏覽可用度量標準的 JMX 輸出 1. 啟動 HBase，如果它尚未運行。 2. 在具有 GUI 顯示的主機上運行命令`jvisualvm`。您可以從命令行或適用于您的操作系統的其他方法啟動它。 3. 確保已安裝 VisualVM-MBeans 插件。瀏覽到**工具→插件**。單擊“已安裝”并檢查是否列出了插件。如果沒有，請單擊“可用插件”，選擇它，然后單擊**安裝**。完成后，單擊**關閉**。 4. 要查看給定 HBase 進程的詳細信息，請雙擊左側面板中 Local 子樹中的進程。右側面板中將打開詳細視圖。單擊 MBeans 選項卡，該選項卡顯示為右側面板頂部的選項卡。 5. 要訪問 HBase 指標，請導航到相應的子 bean :. _ 大師：。_ RegionServer： 6. 每個度量標準的名稱及其當前值都顯示在“屬性”選項卡中。對于包含更多詳細信息（包括每個屬性的說明）的視圖，請單擊“元數據”選項卡。 ### 153.4。度量單位度量單位 根據需要，不同的度量以不同的單位表示。通常，度量單位在名稱中（如度量`shippedKBs`）。否則，請使用以下準則。如有疑問，您可能需要檢查給定指標的來源。 * 引用某個時間點的度量標準通常表示為時間戳。 * 引用年齡的度量標準（例如`ageOfLastShippedOp`）通常以毫秒表示。 * 引用內存大小的度量標準以字節為單位。 * 隊列的大小（例如`sizeOfLogQueue`）表示為隊列中的項目數。通過乘以塊大小來確定大小（HDFS 中的默認值為 64 MB）。 * 引用諸如給定類型的操作（例如`logEditsRead`）的數量之類的度量標準表示為整數。 ### 153.5。最重要的主要指標 注意：計數通常超過最后一個度量報告間隔。 hbase.master.numRegionServers 實時區域服務器的數量 hbase.master.numDeadRegionServers 死區服務器的數量 hbase.master.ritCount 過渡地區的數量 hbase.master.ritCountOverThreshold 轉換區域的數量超過閾值時間（默認值：60 秒） hbase.master.ritOldestAge 轉換中最長區域的年齡，以毫秒為單位 ### 153.6。最重要的 RegionServer 指標 Note: Counts are usually over the last metrics reporting interval. hbase.regionserver.regionCount 區域服務器托管的區域數量 hbase.regionserver.storeFileCount 當前由 regionserver 管理的磁盤上的存儲文件數 hbase.regionserver.storeFileSize 磁盤上存儲文件的聚合大小 hbase.regionserver.hlogFileCount 尚未歸檔的預寫日志數 hbase.regionserver.totalRequestCount 收到的請求總數 hbase.regionserver.readRequestCount 收到的讀取請求數 hbase.regionserver.writeRequestCount 收到的寫入請求數 hbase.regionserver.numOpenConnections RPC 層的打開連接數 hbase.regionserver.numActiveHandler 主動為請求提供服務的 RPC 處理程序的數量 hbase.regionserver.numCallsInGeneralQueue 當前排隊的用戶請求數 hbase.regionserver.numCallsInReplicationQueue 從復制中收到的當前排隊操作的數量 hbase.regionserver.numCallsInPriorityQueue 當前排隊的優先級（內部管家）請求的數量 hbase.regionserver.flushQueueLength memstore 刷新隊列的當前深度。如果增加，我們落后于清除 HDFS 的存儲庫。 hbase.regionserver.updatesBlockedTime 已阻止更新的毫秒數，因此可以刷新 memstore hbase.regionserver.compactionQueueLength 壓縮請求隊列的當前深度。如果增加，我們落后于 storefile 壓縮。 hbase.regionserver.blockCacheHitCount 塊緩存命中數 hbase.regionserver.blockCacheMissCount 塊緩存未命中數 hbase.regionserver.blockCacheExpressHitPercent 打開緩存請求的時間百分比達到緩存 hbase.regionserver.percentFilesLocal 可從本地 DataNode 讀取的存儲文件數據的百分比，0-100 hbase.regionserver。 &lt;op&gt;_&lt;measure&gt;&lt;/measure&gt;&lt;/op&gt; 操作延遲，其中&lt;op&gt;是 Append，Delete，Mutate，Get，Replay，Increment 之一;其中&lt;measure&gt;是 min，max，mean，median，75th_percentile，95th_percentile，99th_percentile&lt;/measure&gt; &lt;/op&gt;中的一個 hbase.regionserver.slow &lt;op&gt;計數&lt;/op&gt; 我們認為操作的數量很慢，其中&lt;op&gt;是以上列表中的一個&lt;/op&gt; hbase.regionserver.GcTimeMillis 垃圾收集所花費的時間，以毫秒為單位 hbase.regionserver.GcTimeMillisParNew 在年輕一代的垃圾收集中花費的時間，以毫秒為單位 hbase.regionserver.GcTimeMillisConcurrentMarkSweep 在舊一代的垃圾收集中花費的時間，以毫秒為單位 hbase.regionserver.authenticationSuccesses 身份驗證成功的客戶端連接數 hbase.regionserver.authenticationFailures 客戶端連接驗證失敗的次數 hbase.regionserver.mutationsWithoutWALCount 提交的寫入計數帶有一個標志，指示它們應繞過寫入日志 ## 154\. HBase 監測 ### 154.1。概觀 以下指標可以說是監控每個 RegionServer 進行“宏監控”的最重要指標，最好是使用像 [OpenTSDB](http://opentsdb.net/) 這樣的系統。如果您的群集出現性能問題，您可能會發現此群組存在異常情況。 HBase 的 * 見 [rs 指標](#rs_metrics) OS * IO 等待 * 用戶 CPU Java 的 * GC 有關 HBase 指標的更多信息，請參閱 [hbase 指標](#hbase_metrics)。 ### 154.2。慢查詢日志 HBase 慢查詢日志由可解析的 JSON 結構組成，這些結構描述了運行時間太長或產生過多輸出的客戶端操作（獲取，推送，刪除等）的屬性。 “太長而不能運行”和“太多輸出”的閾值是可配置的，如下所述。輸出在主區域服務器日志中內聯生成，因此很容易從上下文中發現與其他已記錄事件的更多詳細信息。它還附有識別標簽`(responseTooSlow)`，`(responseTooLarge)`，`(operationTooSlow)`和`(operationTooLarge)`，以便在用戶希望僅查看慢速查詢的情況下，使用 grep 輕松過濾。 #### 154.2.1。組態 有兩個配置旋鈕可用于調整記錄查詢的閾值。 * `hbase.ipc.warn.response.time`可以在不記錄的情況下運行查詢的最大毫秒數。默認為 10000 或 10 秒。可以設置為-1 以禁用按時間記錄。 * `hbase.ipc.warn.response.size`查詢無需記錄即可返回的響應的最大字節大小。默認為 100 兆字節。可以設置為-1 以禁用按大小記錄。 #### 154.2.2。度量 慢查詢日志向 JMX 公開指標。 * `hadoop.regionserver_rpc_slowResponse`一個全局指標，反映觸發記錄的所有響應的持續時間。 * `hadoop.regionserver_rpc_methodName.aboveOneSec`一個指標，反映持續時間超過一秒的所有響應的持續時間。 #### 154.2.3。產量 輸出用例如操作標記。 `(operationTooSlow)`如果調用是客戶端操作，例如 Put，Get 或 Delete，我們會為其公開詳細的指紋信息。如果沒有，它被標記為`(responseTooSlow)`并且仍然產生可解析的 JSON 輸出，但是只有關于 RPC 本身的持續時間和大小的冗長信息。如果響應大小觸發了日志記錄，則`TooLarge`將替換`TooSlow`，即使在大小和持續時間都觸發日志記錄的情況下也會出現`TooLarge`。 #### 154.2.4。例 ``` 2011-09-08 10:01:25,824 WARN org.apache.hadoop.ipc.HBaseServer: (operationTooSlow): {"tables":{"riley2":{"puts":[{"totalColumns":11,"families":{"actions":[{"timestamp":1315501284459,"qualifier":"0","vlen":9667580},{"timestamp":1315501284459,"qualifier":"1","vlen":10122412},{"timestamp":1315501284459,"qualifier":"2","vlen":11104617},{"timestamp":1315501284459,"qualifier":"3","vlen":13430635}]},"row":"cfcd208495d565ef66e7dff9f98764da:0"}],"families":["actions"]}},"processingtimems":956,"client":"10.47.34.63:33623","starttimems":1315501284456,"queuetimems":0,"totalPuts":1,"class":"HRegionServer","responsesize":0,"method":"multiPut"} ``` 請注意，“表”結構中的所有內容都是由 MultiPut 指紋生成的，而其余信息是特定于 RPC 的，例如處理時間和客戶端 IP /端口。其他客戶操作遵循相同的模式和相同的一般結構，由于各個操作的性質而具有必要的差異。在呼叫不是客戶端操作的情況下，將完全不存在詳細的指紋信息。 例如，這個特定的例子表明，慢速的可能原因只是一個非常大的（大約 100MB）多輸出，正如我們可以通過 multiput 中每個 put 的“vlen”或值長度字段來判斷的那樣。 。 ### 154.3。阻止緩存監控 從 HBase 0.98 開始，HBase Web UI 包括監視和報告塊緩存性能的功能。要查看塊緩存報告，請單擊。以下是報告功能的幾個示例。 圖 8.基本信息圖 9.配置圖 10.統計圖 11\. L1 和 L2 這不是所有可用屏幕和報告的詳盡列表。看一下 Web UI。 ### 154.4。快照空間使用情況監控 從 HBase 0.95 開始，HBase Master Web UI 中顯示了各個快照的快照使用信息。從 HBase 1.3 開始，這進一步增強，以顯示快照集的總文件文件大小。以下指標顯示在使用 HBase 1.3 及更高版本的主 Web UI 中。 * Shared Storefile Size 是快照和活動表之間共享的 Storefile 大小。 * Mob Storefile Size 是快照和活動表之間共享的 Mob Storefile 大小。 * 存檔的 Storefile Size 是存檔中的存儲文件大小。 存檔文件大小的格式為 NNN（MMM）。 NNN 是存檔中的存儲文件總大小，MMM 是存檔中特定于快照的存儲文件總大小（不與其他快照和表共享）。 圖 12.主快照概述圖 13.快照存儲文件統計示例 1 圖 14.快照存儲文件統計示例 2 圖 15.空快照 Storfile 統計示例 ## 155.群集復制 > 此信息以前在 [Cluster Replication](https://hbase.apache.org/0.94/replication.html) 中提供。 HBase 提供了一種群集復制機制，允許您使用源群集的預寫日志（WAL）來傳播更改，從而使一個群集的狀態與另一個群集的狀態保持同步。集群復制的一些用例包括： * 備份和災難恢復 * 數據聚合 * 地理數據分布 * 在線數據提取與離線數據分析相結合 > 以列族的粒度啟用復制。在為列族啟用復制之前，請在目標群集上創建要復制的表和所有列族。 > > 復制是異步的，因為我們將 WAL 發送到后臺的另一個集群，這意味著當您想通過復制進行恢復時，可能會丟失一些數據。為解決此問題，我們引入了一項稱為同步復制的新功能。由于機制有點不同所以我們使用一個單獨的部分來描述它。請參見[同步復制](#syncreplication)。 ### 155.1。復制概述 群集復制使用源推送方法。 HBase 集群可以是源（也稱為主服務器或主服務器，意味著它是新數據的發起者），目標服務器（也稱為從服務器或被動服務器，意味著它通過復制接收數據），或者可以同時滿足這兩個角色。復制是異步的，復制的目標是最終的一致性。當源接收對啟用了復制的列族的編輯時，該編輯將使用 WAL 傳播到所有目標群集，以用于管理相關區域的 RegionServer 上的該列族。 當數據從一個集群復制到另一個集群時，將通過集群 ID 跟蹤數據的原始源，集群 ID 是元數據的一部分。在 HBase 0.96 和更新的（ [HBASE-7709](https://issues.apache.org/jira/browse/HBASE-7709) ）中，還跟蹤已經消耗了數據的所有簇。這可以防止復制循環。 只要需要將數據復制到任何從屬群集，每個區域服務器的 WAL 必須保留在 HDFS 中。每個區域服務器都從需要復制的最舊日志中讀取，并跟蹤其在 ZooKeeper 中處理 WAL 的進度，以簡化故障恢復。指示從屬群集的進度的位置標記以及要處理的 WAL 的隊列對于每個從屬群集可以是不同的。 參與復制的集群可以具有不同的大小。主群集依賴于隨機化來嘗試平衡從屬群集上的復制流。預期從屬群集具有存儲容量來保存復制數據，以及它負責攝取的任何數據。如果從屬群集的空間不足或由于其他原因而無法訪問，則會拋出錯誤并且主服務器會保留 WAL 并每隔一段時間重試一次復制。 > 復制群集的一致性 > > 在復制過程中，您的應用程序如何構建在 HBase API 之上。 HBase 的復制系統至少為已啟用的列系列向每個已配置的目標群集提供客戶端編輯。如果未能到達給定目標，復制系統將以可能重復給定消息的方式重試發送編輯。 HBase 提供了兩種復制方式，一種是原始復制，另一種是串行復制。在以前的復制方式中，客戶端編輯沒有保證的交付順序。如果 RegionServer 發生故障，復制隊列的恢復將獨立于服務器先前處理的各個區域的恢復而發生。這意味著尚未復制的編輯可能由 RegionServer 提供服務，該 RegionServer 目前比在失敗后處理編輯的更復雜。 > > 這兩個屬性的組合（至少一次傳遞和缺少消息排序）意味著如果您的應用程序使用非冪等的操作，某些目標群集可能最終處于不同的狀態，例如，增量。 > > 為了解決這個問題，HBase 現在支持串行復制，它將編輯作為客戶端請求的順序發送到目標集群。請參見[串行復制](#_serial_replication)。 > > 術語變化 > > 以前， _master-master_ ， _master-slave_ 和 _cyclical_ 等術語用于描述 HBase 中的復制關系。這些術語增加了混淆，并且已經放棄了有利于討論適用于不同場景的集群拓撲。 群集拓撲 * 中央源群集可能會將更改傳播到多個目標群集，以進行故障轉移或由于地理分布。 * 源群集可能會將更改推送到目標群集，這可能還會將其自身的更改推送回原始群集。 * 許多不同的低延遲群集可能會將更改推送到一個集中式群集，以進行備份或資源密集型數據分析作業。然后，處理后的數據可能會被復制回低延遲群集。 可以將多個級別的復制鏈接在一起以滿足組織的需要。下圖顯示了一個假設的場景。使用箭頭跟隨數據路徑。 圖 16.復雜群集復制配置示例 HBase 復制借鑒了 MySQL 使用的基于 _ 語句的復制 _ 設計中的許多概念。而不是 SQL 語句，將復制整個 WALEdits（包括來自客戶端上的 Put 和 Delete 操作的多個單元格插入），以保持原子性。 ### 155.2。管理和配置群集復制 群集配置概述 1. 配置并啟動源和目標群集。在源群集和目標群集上創建具有相同名稱和列系列的表，以便目標群集知道將在何處存儲將接收的數據。 2. 源和目標群集中的所有主機都應該可以相互訪問。 3. 如果兩個群集都使用相同的 ZooKeeper 群集，則必須使用不同的`zookeeper.znode.parent`，因為它們無法在同一文件夾中寫入。 4. 在源群集上，在 HBase Shell 中，使用`add_peer`命令將目標群集添加為對等方。 5. 在源群集上，在 HBase Shell 中，使用`enable_table_replication`命令啟用表復制。 6. 檢查日志以查看是否正在進行復制。如果是這樣，您將看到來自 ReplicationSource 的以下消息。 ``` LOG.info("Replicating "+clusterId + " -> " + peerClusterId); ``` 串行復制配置 參見[串行復制](#_serial_replication) 群集管理命令 add_peer 在兩個群集之間添加復制關系。 * ID - 唯一字符串，不得包含連字符。 * CLUSTER_KEY：使用以下模板和適當的占位符組成：`hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent`。可以在主 UI 信息頁面上找到此值。 * STATE（可選）：ENABLED 或 DISABLED，默認值為 ENABLED list_peers 列出此群集已知的所有復制關系 enable_peer 啟用先前禁用的復制關系 disable_peer 禁用復制關系。 HBase 將不再向該對等集群發送編輯，但它仍會跟蹤在重新啟用時需要復制的所有新 WAL。只要存在對等體，在啟用或禁用復制時將保留 WAL。 remove_peer 禁用并刪除復制關系。 HBase 將不再向該對等集群發送編輯或跟蹤 WAL。 enable_table_replication&lt;table_name&gt;&lt;/table_name&gt; 為其所有列系列啟用表復制開關。如果在目標集群中找不到該表，則它將創建一個具有相同名稱和列族的表。 disable_table_replication&lt;table_name&gt;&lt;/table_name&gt; 禁用其所有列系列的表復制開關。 ### 155.3。串行復制 注意：此功能在 HBase 2.1 中引入 串行復制的功能 串行復制支持以與日志到達源群集相同的順序將日志推送到目標群集。 為什么需要串行復制？ 在 HBase 的復制中，我們通過在每個區域服務器中讀取 WAL 來將突變推送到目標集群。我們有一個 WAL 文件的隊列，所以我們可以按照創建時間的順序讀取它們。但是，當源群集中發生區域移動或 RS 故障時，在區域移動或 RS 失敗之前未被推送的 hlog 條目將被原始 RS（用于區域移動）或另一個接管剩余 hlog 的 RS 推送。死 RS（用于 RS 失敗），同一區域的新條目將由現在服務于區域的 RS 推送，但它們同時推送同一區域的 hlog 條目而不進行協調。 這種處理可能導致源和目標集群之間的數據不一致： 1. 有 put 然后刪除寫入源集群。 2. 由于區域移動/ RS 失敗，它們被不同的復制源線程推送到對等集群。 3. 如果在放入之前將刪除推送到對等集群，并且在將 put 推送到對等集群之前在對等集群中發生 flush 和 major-compact，則收集刪除并且放置在對等集群中，但是在源集群中，放置被掩蓋了刪除，因此源和目標集群之間的數據不一致。 串行復制配置 將復制節點的串行標志設置為 true。默認的串行標志為 false。 * 添加一個串行標志為 true 的新復制對等體 ``` hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", SERIAL => true ``` * 將復制對等方的串行標志設置為 false ``` hbase> set_peer_serial '1', false ``` * 將復制對等方的串行標志設置為 true ``` hbase> set_peer_serial '1', true ``` 首先在 [HBASE-9465](https://issues.apache.org/jira/browse/HBASE-9465) 中進行了系列復制，然后在 [HBASE-20046](https://issues.apache.org/jira/browse/HBASE-20046) 中進行了回復和重做。您可以在這些問題中找到更多詳細信息。 ### 155.4。驗證復制數據 `VerifyReplication` MapReduce 作業（包含在 HBase 中）對兩個不同集群之間的復制數據進行系統比較。在主群集上運行 VerifyReplication 作業，為其提供用于驗證的對等 ID 和表名。您可以通過指定時間范圍或特定系列來進一步限制驗證。這份工作的簡稱是`verifyrep`。要運行作業，請使用如下命令： + ``` $ HADOOP_CLASSPATH=`${HBASE_HOME}/bin/hbase classpath` "${HADOOP_HOME}/bin/hadoop" jar "${HBASE_HOME}/hbase-mapreduce-VERSION.jar" verifyrep --starttime=<timestamp> --endtime=<timestamp> --families=<myFam> <ID> <tableName> ``` * `VerifyReplication`命令打印出`GOODROWS`和`BADROWS`計數器，以指示正確復制和未復制的行。 ### 155.5。有關群集復制的詳細信息 圖 17.復制架構概述 #### 155.5.1。 WAL 編輯的生活 單個 WAL 編輯將經歷幾個步驟，以便復制到從屬群集。 1. HBase 客戶端使用 Put 或 Delete 操作來操作 HBase 中的數據。 2. 區域服務器以某種方式將請求寫入 WAL，如果未成功寫入則允許重放。 3. 如果更改的單元格對應于作為復制作用域的列族，則會將編輯添加到隊列以進行復制。 4. 在單獨的線程中，作為批處理的一部分，從日志中讀取編輯。僅保留符合復制條件的 KeyValues。可復制的 KeyValues 是列族的一部分，其列的范圍為 GLOBAL，不是`hbase:meta`等目錄的一部分，不是源自目標從屬群集，并且尚未被目標從群集使用。 5. 編輯用主 UUID 標記并添加到緩沖區。填充緩沖區或讀取器到達文件末尾時，緩沖區將發送到從屬群集上的隨機區域服務器。 6. 區域服務器按順序讀取編輯并將它們分成緩沖區，每個表一個緩沖區。讀取所有編輯后，使用 HBase 的普通客戶端[表](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Table.html)刷新每個緩沖區。主服務器的 UUID 和已經使用數據的從服務器的 UUID 將保留在應用的編輯中，以防止復制循環。 7. 在主服務器中，當前正在復制的 WALL 的偏移量在 ZooKeeper 中注冊。 8. 插入編輯的前三個步驟是相同的??。 9. 同樣在單獨的線程中，區域服務器以與上面相同的方式讀取，過濾和編輯日志編輯。從屬區域服務器不響應 RPC 調用。 10. 主人睡眠并再次嘗試可配置的次數。 11. 如果從屬區域服務器仍然不可用，則主服務器選擇要復制到的區域服務器的新子集，并再次嘗試發送編輯緩沖區。 12. 同時，WALs 被滾動并存儲在 ZooKeeper 的隊列中。由區域服務器將 _ 歸檔 _ 的日志從區域服務器的日志目錄移動到中央日志目錄，將更新其在復制線程的內存中隊列中的路徑。 13. 當從屬群集最終可用時，緩沖區的應用方式與正常處理時相同。然后，主區域服務器將復制在中斷期間累積的積壓日志。 傳播隊列故障轉移負載 復制處于活動狀態時，源群集中的一部分區域服務器負責將編輯內容傳送到接收器。與進程或節點崩潰時的所有其他區域服務器功能一樣，此責任必須進行故障轉移。建議使用以下配置設置來維護源群集中其余活動服務器上的復制活動的均勻分布： * 將`replication.source.maxretriesmultiplier`設置為`300`。 * 將`replication.source.sleepforretries`設置為`1`（1 秒）。該值與`replication.source.maxretriesmultiplier`的值相結合，導致重試周期持續約 5 分鐘。 * 在源群集站點配置中將`replication.sleep.before.failover`設置為`30000`（30 秒）。 在復制期間保留標記 默認情況下，用于群集之間復制的編解碼器會從單元格中剝離標記，例如單元級 ACL。要防止標記被剝離，您可以使用不剝離標記的其他編解碼器。在復制中涉及的源和接收區域服務器上配置`hbase.replication.rpc.codec`以使用`org.apache.hadoop.hbase.codec.KeyValueCodecWithTags`。該選項在 [HBASE-10322](https://issues.apache.org/jira/browse/HBASE-10322) 中引入。 #### 155.5.2。復制內部 ZooKeeper 中的復制狀態 HBase 復制在 ZooKeeper 中維護其狀態。默認情況下，狀態包含在基節點 _/ hbase / replication_ 中。該節點包含兩個子節點，`Peers` znode 和`RS` znode。 `Peers` Znode `peers` znode 默認存儲在 _/ hbase / replication / peers_ 中。它由所有對等復制集群的列表以及每個集群的狀態組成。每個對等方的值是其群集密鑰，它在 HBase Shell 中提供。群集密鑰包含群集仲裁中的 ZooKeeper 節點列表，ZooKeeper 仲裁的客戶端端口以及該群集上 HDFS 中 HBase 的基本 znode。 `RS` Znode `rs` znode 包含需要復制的 WAL 日志列表。此列表分為由區域服務器組織的一組隊列和區域服務器將日志傳送到的對等群集。 rs znode 為集群中的每個區域服務器都有一個子 znode。子 znode 名稱是區域服務器的主機名，客戶端端口和起始代碼。此列表包括實時和死區服務器。 #### 155.5.3。選擇要復制到的區域服務器 當主群集區域服務器向從群集啟動復制源時，它首先使用提供的群集密鑰連接到從屬的 ZooKeeper 集合。然后掃描 _rs /_ 目錄以發現所有可用的接收器（接受要復制的輸入流的區域服務器），并使用配置的比率隨機選擇它們的子集，其默認值為 10 ％。例如，如果從屬群集有 150 臺計算機，則將選擇 15 個作為此主群集區域服務器發送的編輯的潛在接收者。由于此選擇由每個主區域服務器執行，因此使用所有從屬區域服務器的概率非常高，并且此方法適用于任何大小的群集。例如，10 臺機器的主集群復制到 5 臺機器的從機集群，比率為 10％，這使得主集群區域服務器可以隨機選擇一臺機器。 ZooKeeper 觀察器由每個主集群的區域服務器放置在從集群的 _$ {zookeeper.znode.parent} / rs_ 節點上。此表用于監視從屬群集組成的變化。從節點集群中刪除節點后，或節點關閉或重新啟動時，主集群的區域服務器將通過選擇要復制到的新的從屬區域服務器池進行響應。 #### 155.5.4。跟蹤日志 每個主群集區域服務器在復制 znodes 層次結構中都有自己的 znode。它包含每個對等群集一個 znode（如果創建了 5 個從屬群集，創建了 5 個 znode），并且每個群集都包含要處理的 WAL 隊列。這些隊列中的每一個都將跟蹤該區域服務器創建的 WAL，但它們的大小可能不同。例如，如果一個從屬群集在一段時間內不可用，則不應刪除 WAL，因此在處理其他群集時，它們需要保留在隊列中。有關示例，請參見 [rs.failover.details](#rs.failover.details) 。 實例化源時，它包含區域服務器正在寫入的當前 WAL。在日志滾動期間，新文件將在可用之前添加到每個從屬群集的 znode 的隊列中。這可確保所有源都知道在區域服務器能夠向其中添加編輯之前存在新日志，但此操作現在更加昂貴。當復制線程無法從文件中讀取更多條目（因為它到達最后一個塊的末尾）并且隊列中有其他文件時，將丟棄隊列項。這意味著如果源是最新的并且從區域服務器寫入的日志中復制，則讀取當前文件的“結尾”將不會刪除隊列中的項目。 如果日志不再使用或日志數超過`hbase.regionserver.maxlogs`，則可以歸檔日志，因為插入速率比刷新區域的速度快。歸檔日志時，會通知源線程該日志的路徑發生更改。如果特定源已經完成了歸檔日志，它將忽略該消息。如果日志在隊列中，則路徑將在內存中更新。如果當前正在復制日志，則更改將以原子方式完成，以便讀取器在已移動時不會嘗試打開該文件。因為移動文件是 NameNode 操作，如果讀者當前正在讀取日志，則不會生成任何異常。 #### 155.5.5。閱讀，過濾和發送編輯 默認情況下，源會嘗試從 WAL 讀取并盡快將日志條目發送到接收器。速度受到日志條目過濾的限制只保留作用域為 GLOBAL 且不屬于目錄表的 KeyValues。速度也受到每個從站復制的編輯列表總大小的限制，默認情況下限制為 64 MB。使用此配置，具有三個從屬服務器的主群集區域服務器將使用最多 192 MB 來存儲要復制的數據。這不會考慮已過濾但未收集垃圾的數據。 一旦編輯的最大編輯大小被緩沖或讀者到達 WAL 的末尾，源線程就會停止讀取并隨機選擇一個接收器復制到（從通過僅保留從屬區域服務器的子集生成的列表） 。它直接向選定的區域服務器發出 RPC 并等待方法返回。如果 RPC 成功，源將確定當前文件是否已清空，或者是否包含需要讀取的更多數據。如果文件已清空，則源將刪除隊列中的 znode。否則，它會在日志的 znode 中注冊新的偏移量。如果 RPC 引發異常，源將在嘗試查找不同的接收器之前重試 10 次。 #### 155.5.6。清理日志 如果未啟用復制，則主服務器的日志清理線程將使用配置的 TTL 刪除舊日志。這種基于 TTL 的方法不適用于復制，因為已超過其 TTL 的存檔日志可能仍在隊列中。默認行為是增強的，因此如果日志超過其 TTL，則清理線程會查找每個隊列，直到找到日志，同時緩存已找到的隊列。如果未在任何隊列中找到日志，則將刪除該日志。下次清理過程需要查找日志時，它首先使用其緩存列表。 > 只要存在對等體，就會在啟用或禁用復制時保存 WAL。 #### 155.5.7。區域服務器故障轉移 當沒有區域服務器發生故障時，跟蹤 ZooKeeper 中的日志不會增加任何值。遺憾的是，區域服務器確實失敗，并且由于 ZooKeeper 具有高可用性，因此在發生故障時管理隊列的傳輸非常有用。 每個主集群區域服務器在每個其他區域服務器上保持觀察者，以便在一個人死亡時得到通知（就像主人一樣）。當發生故障時，他們都會競爭在死區服務器的 znode 中創建一個名為`lock`的 znode，該 znode 包含其隊列。成功創建它的區域服務器然后將所有隊列傳輸到它自己的 znode，一次一個，因為 ZooKeeper 不支持重命名隊列。隊列全部轉移后，將從舊位置刪除它們。使用附加了死服務器名稱的從屬群集的 ID 重命名已恢復的 znode。 接下來，主集群區域服務器為每個復制的隊列創建一個新的源線程，并且每個源線程遵循讀取/過濾器/發布模式。主要區別在于這些隊列永遠不會收到新數據，因為它們不屬于新的區域服務器。當閱讀器到達最后一個日志的末尾時，隊列的 znode 將被刪除，主群集區域服務器將關閉該復制源。 給定具有 3 個區域服務器的主集群復制到具有 id `2`的單個從屬服務器，以下層次結構表示 znodes 布局在某個時間點可能是什么。區域服務器的 znode 都包含一個包含單個隊列的`peers` znode。隊列中的 znode 名稱以`address,port.timestamp`的形式表示 HDFS 上的實際文件名。 ``` /hbase/replication/rs/ 1.1.1.1,60020,123456780/ 2/ 1.1.1.1,60020.1234 (Contains a position) 1.1.1.1,60020.1265 1.1.1.2,60020,123456790/ 2/ 1.1.1.2,60020.1214 (Contains a position) 1.1.1.2,60020.1248 1.1.1.2,60020.1312 1.1.1.3,60020, 123456630/ 2/ 1.1.1.3,60020.1280 (Contains a position) ``` 假設 1.1.1.2 丟失了 ZooKeeper 會話。幸存者將競爭創造一個鎖，并且，任意地，1.1.1.3 獲勝。然后，它將通過附加死服務器的名稱開始將所有隊列傳輸到其本地對等方 znode。在 1.1.1.3 之前能夠清理舊的 znode，布局將如下所示： ``` /hbase/replication/rs/ 1.1.1.1,60020,123456780/ 2/ 1.1.1.1,60020.1234 (Contains a position) 1.1.1.1,60020.1265 1.1.1.2,60020,123456790/ lock 2/ 1.1.1.2,60020.1214 (Contains a position) 1.1.1.2,60020.1248 1.1.1.2,60020.1312 1.1.1.3,60020,123456630/ 2/ 1.1.1.3,60020.1280 (Contains a position) 2-1.1.1.2,60020,123456790/ 1.1.1.2,60020.1214 (Contains a position) 1.1.1.2,60020.1248 1.1.1.2,60020.1312 ``` 一段時間之后，但在 1.1.1.3 之前能夠完成從 1.1.1.2 復制最后一個 WAL，它也會死掉。在正常隊列中也創建了一些新日志。然后，最后一個區域服務器將嘗試鎖定 1.1.1.3 的 znode 并開始傳輸所有隊列。新的布局將是： ``` /hbase/replication/rs/ 1.1.1.1,60020,123456780/ 2/ 1.1.1.1,60020.1378 (Contains a position) 2-1.1.1.3,60020,123456630/ 1.1.1.3,60020.1325 (Contains a position) 1.1.1.3,60020.1401 2-1.1.1.2,60020,123456790-1.1.1.3,60020,123456630/ 1.1.1.2,60020.1312 (Contains a position) 1.1.1.3,60020,123456630/ lock 2/ 1.1.1.3,60020.1325 (Contains a position) 1.1.1.3,60020.1401 2-1.1.1.2,60020,123456790/ 1.1.1.2,60020.1312 (Contains a position) ``` ### 155.6。復制指標 以下度量標準在全局區域服務器級別和對等級別公開： `source.sizeOfLogQueue` 復制源處理的 WAL 數（不包括正在處理的 WAL） `source.shippedOps` 發送的突變數量 `source.logEditsRead` 從復制源處的 WAL 讀取的突變數 `source.ageOfLastShippedOp` 復制源發送的最后一批的時間 `source.completedLogs` 已完成其已確認發送到與此源關聯的對等方的預寫日志文件的數量。此度量標準的增量是 HBase 復制的正常操作的一部分。 `source.completedRecoverQueues` 此源已完成發送到關聯對等方的恢復隊列數。在失敗的區域服務器面前，此度量標準的增量是 HBase 復制的正常恢復的一部分。 `source.uncleanlyClosedLogs` 復制系統在面對不正確關閉的文件到達可讀條目末尾后認為已完成的預寫日志文件數。 `source.ignoredUncleanlyClosedLogContentsInBytes` 如果未完全關閉預寫日志文件，則可能會有一些已部分序列化的條目。此度量標準包含 HBase 復制系統認為在面對不正確關閉的文件時跳過的文件末尾的此類條目的字節數。這些字節應該在不同的文件中，或者表示未被確認的客戶端寫入。 `source.restartedLogReading` HBase 復制系統檢測到無法正確解析完全關閉的預寫日志文件的次數。在這種情況下，系統從一開始就重放整個日志，確保相關對等體不能確認編輯。此度量標準的增量表示 HBase 復制系統難以正確處理底層分布式存儲系統中的故障。不應出現數據刪除，但您應檢查 Region Server 日志文件以獲取故障的詳細信息。 `source.repeatedLogFileBytes` 當 HBase 復制系統確定它需要重放給定的預寫日志文件時，此度量標準將增加復制系統認為在重新開始之前已由關聯對等方確認的字節數。 `source.closedLogsWithUnknownFileLength` 當 HBase 復制系統認為它位于預寫日志文件的末尾但是無法確定底層分布式存儲系統中該文件的長度時，會增加。可以指示 dataloss，因為復制系統無法確定可讀條目的末尾是否與文件的預期結束對齊。您應該檢查 Region Server 日志文件以獲取故障的詳細信息。 ### 155.7。復制配置選項 | 選項 | 描述 | 默認 | | --- | --- | --- | | zookeeper.znode.parent | 用于 HBase 的基本 ZooKeeper znode 的名稱 | / HBase 的 | | zookeeper.znode.replication | 用于復制的基本 znode 的名稱 | 復制 | | zookeeper.znode.replication.peers | 對等 znode 的名稱 | 同行 | | zookeeper.znode.replication.peers.state | 對等狀態 znode 的名稱 | 對等狀態 | | zookeeper.znode.replication.rs | rs znode 的名稱 | RS | | replication.sleep.before.failover | 在嘗試復制死區服務器 WAL 隊列之前，工作者應該睡多少毫秒。 | | | replication.executor.workers | 給定區域服務器應嘗試同時進行故障轉移的區域服務器數。 | 1 | ### 155.8。監控復制狀態 您可以使用 HBase Shell 命令`status 'replication'`來監視群集上的復制狀態。該命令有三個變體： _`status 'replication'` - 打印每個源及其接收器的狀態，按主機名排序。_ `status 'replication', 'source'` - 打印每個復制源的狀態，按主機名排序。 * `status 'replication', 'sink'` - 打印每個復制接收器的狀態，按主機名排序。 ## 156.在單個群集上運行多個工作負載 HBase 提供以下機制來管理處理多個工作負載的集群的性能：。 [配額](#quota)。 [請求隊列](#request_queues)。 [多種類型的隊列](#multiple-typed-queues) ### 156.1。配額 HBASE-11598 引入了 RPC 配額，允許您根據以下限制限制請求： 1. [給定時間范圍內請求（讀，寫或讀+寫）的數量或大小](#request-quotas) 2. [命名空間中允許的表數](#namespace_quotas) 可以對指定的用戶，表或命名空間強制實施這些限制。 啟用配額 默認情況下禁用配額。要啟用該功能，請在 _hbase-site.xml_ 文件中為所有群集節點將`hbase.quota.enabled`屬性設置為`true`。 一般配額語法 1. THROTTLE_TYPE 可以表示為 READ，WRITE 或默認類型（讀取+寫入）。 2. 時間范圍可以用以下單位表示：`sec`，`min`，`hour`，`day` 3. 請求大小可以用以下單位表示：`B`（字節），`K`（千字節），`M`（兆字節），`G`（千兆字節），`T`（兆兆字節），`P`（千兆字節） ） 4. 請求數表示為整數，后跟字符串`req` 5. 與時間相關的限制表示為 req / time 或 size / time。例如`10req/day`或`100P/hour`。 6. 表或區域的數量表示為整數。 設置請求配額 您可以提前設置配額規則，也可以在運行時更改限制。配額刷新期到期后，更改將傳播。此有效期默認為 5 分鐘。要更改它，請修改`hbase-site.xml`中的`hbase.quota.refresh.period`屬性。此屬性以毫秒表示，默認為`300000`。 ``` # Limit user u1 to 10 requests per second hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => '10req/sec' # Limit user u1 to 10 read requests per second hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => READ, USER => 'u1', LIMIT => '10req/sec' # Limit user u1 to 10 M per day everywhere hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => '10M/day' # Limit user u1 to 10 M write size per sec hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => WRITE, USER => 'u1', LIMIT => '10M/sec' # Limit user u1 to 5k per minute on table t2 hbase> set_quota TYPE => THROTTLE, USER => 'u1', TABLE => 't2', LIMIT => '5K/min' # Limit user u1 to 10 read requests per sec on table t2 hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => READ, USER => 'u1', TABLE => 't2', LIMIT => '10req/sec' # Remove an existing limit from user u1 on namespace ns2 hbase> set_quota TYPE => THROTTLE, USER => 'u1', NAMESPACE => 'ns2', LIMIT => NONE # Limit all users to 10 requests per hour on namespace ns1 hbase> set_quota TYPE => THROTTLE, NAMESPACE => 'ns1', LIMIT => '10req/hour' # Limit all users to 10 T per hour on table t1 hbase> set_quota TYPE => THROTTLE, TABLE => 't1', LIMIT => '10T/hour' # Remove all existing limits from user u1 hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => NONE # List all quotas for user u1 in namespace ns2 hbase> list_quotas USER => 'u1, NAMESPACE => 'ns2' # List all quotas for namespace ns2 hbase> list_quotas NAMESPACE => 'ns2' # List all quotas for table t1 hbase> list_quotas TABLE => 't1' # list all quotas hbase> list_quotas ``` 您還可以通過應用`GLOBAL_BYPASS`屬性來設置全局限制并從限制中排除用戶或表。 ``` hbase> set_quota NAMESPACE => 'ns1', LIMIT => '100req/min' # a per-namespace request limit hbase> set_quota USER => 'u1', GLOBAL_BYPASS => true # user u1 is not affected by the limit ``` 設置命名空間配額 通過在命名空間上設置`hbase.namespace.quota.maxtables property`，可以在創建命名空間時或通過更改現有命名空間來指定給定命名空間中允許的最大表或區域數。 每個命名空間限制表 ``` # Create a namespace with a max of 5 tables hbase> create_namespace 'ns1', {'hbase.namespace.quota.maxtables'=>'5'} # Alter an existing namespace to have a max of 8 tables hbase> alter_namespace 'ns2', {METHOD => 'set', 'hbase.namespace.quota.maxtables'=>'8'} # Show quota information for a namespace hbase> describe_namespace 'ns2' # Alter an existing namespace to remove a quota hbase> alter_namespace 'ns2', {METHOD => 'unset', NAME=>'hbase.namespace.quota.maxtables'} ``` 每個命名空間限制區域 ``` # Create a namespace with a max of 10 regions hbase> create_namespace 'ns1', {'hbase.namespace.quota.maxregions'=>'10' # Show quota information for a namespace hbase> describe_namespace 'ns1' # Alter an existing namespace to have a max of 20 tables hbase> alter_namespace 'ns2', {METHOD => 'set', 'hbase.namespace.quota.maxregions'=>'20'} # Alter an existing namespace to remove a quota hbase> alter_namespace 'ns2', {METHOD => 'unset', NAME=> 'hbase.namespace.quota.maxregions'} ``` ### 156.2。請求隊列 如果未配置限制策略，則當 RegionServer 收到多個請求時，它們現在將被放入等待空閑執行槽的隊列（HBASE-6721）。最簡單的隊列是 FIFO 隊列，其中每個請求在運行之前等待隊列中的所有先前請求完成。快速或交互式查詢可能會滯后于大量請求。 如果您能夠猜測請求需要多長時間，您可以通過將長請求推送到隊列末尾并允許短請求搶占它們來重新排序請求。最終，您仍然必須執行大型請求并確定其后面的新請求的優先級。短請求將更新，因此結果并不可怕，但與允許將大量請求拆分為多個較小請求的機制相比仍然不是最理想的。 HBASE-10993 引入了這樣一種系統，用于對長時間運行的掃描儀進行優先級排序。有兩種類型的隊列，`fifo`和`deadline`。要配置使用的隊列類型，請在`hbase-site.xml`中配置`hbase.ipc.server.callqueue.type`屬性。無法估計每個請求可能需要多長時間，因此取消優先級只會影響掃描，并且基于掃描請求所做的“下一次”調用的次數。假設當您進行全表掃描時，您的作業可能不是交互式的，因此如果存在并發請求，則可以通過設置`hbase.ipc.server.queue.max.call.delay`屬性將長時間運行的掃描延遲到可調整的限制。延遲的斜率由`(numNextCall * weight)`的簡單平方根計算，其中權重可通過設置`hbase.ipc.server.scan.vtime.weight`屬性進行配置。 ### 156.3。多類型隊列 您還可以通過配置指定數量的專用處理程序和隊列來確定不同類型請求的優先級或優先級。您可以使用單個處理程序在單個隊列中隔離掃描請求，并且所有其他可用隊列可以為短`Get`請求提供服務。 您可以使用靜態調整選項根據工作負載類型調整 IPC 隊列和處理程序。此方法是臨時的第一步，最終將允許您在運行時更改設置，并根據負載動態調整值。 多個隊列 為了避免爭用并分離不同類型的請求，請配置`hbase.ipc.server.callqueue.handler.factor`屬性，該屬性允許您增加隊列數量并控制可以共享同一隊列的處理程序數量。允許管理員增加隊列數量并確定多少處理程序共享同一隊列。 使用更多隊列可以在將任務添加到隊列或從隊列中選擇任務時減少爭用。您甚至可以為每個處理程序配置一個隊列權衡是，如果某些隊列包含長時間運行的任務，則處理程序可能需要等待從該隊列執行而不是從具有等待任務的另一個隊列中竊取。 讀寫隊列 使用多個隊列，您現在可以劃分讀取和寫入請求，為一種或另一種類型提供更多優先級（更多隊列）。使用`hbase.ipc.server.callqueue.read.ratio`屬性選擇提供更多讀取或更多寫入。 獲取和掃描隊列 與讀/寫拆分類似，您可以通過調整`hbase.ipc.server.callqueue.scan.ratio`屬性來拆分獲取和掃描，以便為獲取或掃描提供更多優先級。 `0.1`的掃描比率將為傳入的獲取提供更多的隊列/處理程序，這意味著可以同時處理更多的獲取，并且可以同時執行更少的掃描。值`0.9`將為掃描提供更多隊列/處理程序，因此執行的掃描次數將增加，并且獲取次數將減少。 ### 156.4。空間配額 [HBASE-16961](https://issues.apache.org/jira/browse/HBASE-16961) 為 HBase 引入了一種新的配額來利用：文件系統配額。這些“空間”配額限制了 HBase 名稱空間和表可以使用的文件系統上的空間量。如果惡意或無知的用戶有足夠的時間將數據寫入 HBase，則該用戶可以通過消耗所有可用空間來有效地崩潰 HBase（或更糟糕的 HDFS）。當沒有可用的文件系統空間時，HBase 崩潰，因為它無法再為預寫日志創建/同步數據。 此功能允許在表或命名空間的大小上設置限制。在命名空間上設置空間配額時，配額的限制適用于該命名空間中所有表的使用總和。在具有配額的命名空間中存在具有配額的表時，表配額優先于命名空間配額。這允許可以對表集合施加大限制的情況，但該集合中的單個表可以具有細粒度限制集。 現有的`set_quota`和`list_quota` HBase shell 命令可用于與空間配額交互。空間配額是`TYPE` `SPACE`的配額，具有`LIMIT`和`POLICY`屬性。 `LIMIT`是一個字符串，它指的是配額主題（例如表或命名空間）可能消耗的文件系統上的空間量。例如，`LIMIT`的有效值為`'10G'`，`'2T'`或`'256M'`。 `POLICY`是指當配額主體的使用量超過`LIMIT`時 HBase 將采取的行動。以下是有效的`POLICY`值。 * `NO_INSERTS` - 無法寫入新數據（例如`Put`，`Increment`，`Append`）。 * `NO_WRITES` - 與`NO_INSERTS`相同，但`Deletes`也不允許。 * `NO_WRITES_COMPACTIONS` - 與`NO_WRITES`相同，但也不允許壓縮。 * `DISABLE` - 禁用表，阻止所有讀/寫訪問。 設置簡單的空間配額 ``` # Sets a quota on the table 't1' with a limit of 1GB, disallowing Puts/Increments/Appends when the table exceeds 1GB hbase> set_quota TYPE => SPACE, TABLE => 't1', LIMIT => '1G', POLICY => NO_INSERTS # Sets a quota on the namespace 'ns1' with a limit of 50TB, disallowing Puts/Increments/Appends/Deletes hbase> set_quota TYPE => SPACE, NAMESPACE => 'ns1', LIMIT => '50T', POLICY => NO_WRITES # Sets a quota on the table 't3' with a limit of 2TB, disallowing any writes and compactions when the table exceeds 2TB. hbase> set_quota TYPE => SPACE, TABLE => 't3', LIMIT => '2T', POLICY => NO_WRITES_COMPACTIONS # Sets a quota on the table 't2' with a limit of 50GB, disabling the table when it exceeds 50GB hbase> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '50G', POLICY => DISABLE ``` 請考慮以下方案在命名空間上設置配額，覆蓋該命名空間中表的配額 表和命名空間空間配額 ``` hbase> create_namespace 'ns1' hbase> create 'ns1:t1' hbase> create 'ns1:t2' hbase> create 'ns1:t3' hbase> set_quota TYPE => SPACE, NAMESPACE => 'ns1', LIMIT => '100T', POLICY => NO_INSERTS hbase> set_quota TYPE => SPACE, TABLE => 'ns1:t2', LIMIT => '200G', POLICY => NO_WRITES hbase> set_quota TYPE => SPACE, TABLE => 'ns1:t3', LIMIT => '20T', POLICY => NO_WRITES ``` 在上面的場景中，名稱空間`ns1`中的表將不允許在文件系統之間消耗超過 100TB 的空間。表'ns1：t2'的大小僅允許為 200GB，并且當使用率超過此限制時將禁止所有寫入。表'ns1：t3'的大小允許增長到 20TB，并且還將禁止所有寫入，然后使用超出此限制。由于'ns1：t1'上沒有表配額，因此該表可以增長到 100TB，但僅當'ns1：t2'和'ns1：t3'使用零字節時才會增長。實際上，它的限制是'ns1：t2'和'ns1：t3'的當前使用量減去 100TB。 ### 156.5。禁用自動空間配額刪除 默認情況下，如果刪除具有空間配額的表或命名空間，則也會刪除配額本身。在某些情況下，可能需要不自動刪除空間配額。在這些情況下，用戶可以將系統配置為不通過 hbase-site.xml 自動刪除任何空間配額。 ``` <property> <name>hbase.quota.remove.on.table.delete</name> <value>false</value> </property> ``` 默認情況下，該值設置為`true`。 ### 156.6。具有空間配額的 HBase 快照 與 HBase 一起使用的非預期文件系統的一個常見區域是通過 HBase 快照。由于快照存在于 HBase 表管理之外，因此管理員突然意識到 HBase 快照正在使用數百 GB 或 TB 的空間并且這些空間被遺忘并且從未被刪除的情況并不少見。 [HBASE-17748](https://issues.apache.org/jira/browse/HBASE-17748) 是一個傘形 JIRA 問題，它擴展了原始空間配額功能，還包括 HBase 快照。雖然這是一個令人困惑的主題，但實現嘗試以盡可能合理和簡單的方式為管理員提供此支持。此功能不會對管理員與空間配額的交互進行任何更改，僅在表/命名空間使用的內部計算中進行。表和命名空間使用將根據下面定義的規則自動合并快照占用的大小。 作為回顧，我們將介紹快照的生命周期：快照是指向文件系統上的 HFile 列表的元數據。這就是為什么創建快照是一個非常便宜的操作;實際上沒有復制 HBase 表數據來執行快照。出于同樣的原因，將快照克隆到新表或恢復表是一種廉價的操作;新表引用文件系統中已存在但沒有副本的文件。要在空間配額中包含快照，我們需要在快照引用文件時定義哪個表“擁有”文件（“擁有”是指包含該文件的文件系統用法）。 考慮針對表格創建的快照。當快照引用文件并且表不再引用該文件時，“originating”表“擁有”該文件。當多個快照引用同一文件且沒有表引用該文件時，將選擇具有最低排序名稱（按字典順序排列）的快照，并且從“擁有”該文件創建該快照的表。 HFile 不是“重復計算”的表，而一個或多個快照指的是 HFile。 當表格“重新物化”時（通過`clone_snapshot`或`restore_snapshot`），會出現類似的文件所有權問題。在這種情況下，雖然重新表示的表引用了快照也引用的文件，但該表并不“擁有”該文件。創建快照的表仍然“擁有”該文件。當壓縮重新實現的表或刪除快照時，重新實現的表將唯一地引用新文件并“擁有”該文件的使用。類似地，當通過快照和`restore_snapshot`復制表時，新表將不會消耗任何配額大小，直到原始表停止引用文件，原因是由于原始表上的壓縮，新表上的壓縮，或原始表被刪除。 添加了一個新的 HBase shell 命令來檢查 HBase 實例中每個快照的計算大小。 ``` hbase> list_snapshot_sizes SNAPSHOT SIZE t1.s1 1159108 ``` ## 157\. HBase 備份 執行 HBase 備份有兩種廣泛的策略：使用完全群集關閉進行備份，以及在實時群集上備份。每種方法都有利有弊。 有關其他信息，請參閱 Sematext 博客上的 [HBase 備份選項](http://blog.sematext.com/2011/03/11/hbase-backup-options/)。 ### 157.1。完全關機備份 某些環境可以容忍其 HBase 群集的定期完全關閉，例如，如果它正在使用后端分析容量而不是服務于前端 Web 頁面。好處是 NameNode / Master 是 RegionServers 已關閉，因此沒有機會錯過對 StoreFiles 或元數據的任何正在進行的更改。顯而易見的是群集已關閉。步驟包括： #### 157.1.1。停止 HBase #### 157.1.2。 DistCp 使用 Distcp 可用于將 HDFS 中 HBase 目錄的內容復制到另一個目錄中的同一群集，或復制到另一個群集。 注意：Distcp 適用于這種情況，因為群集已關閉，并且沒有對文件的正在進行的編輯。通常不建議在實時群集上對 HBase 目錄中的文件進行分揀。 #### 157.1.3。恢復（如果需要） 從 HDFS 備份 hbase 目錄通過 distcp 復制到'real'hbase 目錄。復制這些文件的行為會創建新的 HDFS 元數據，這就是為什么這種恢復不需要從 HBase 備份時恢復 NameNode 的原因，因為它是特定 HDFS 目錄的恢復（通過 distcp） （即 HBase 部分）不是整個 HDFS 文件系統。 ### 157.2。實時群集備份 - 復制 此方法假定存在第二個集群。有關詳細信息，請參閱[復制](https://hbase.apache.org/book.html#_cluster_replication)上的 HBase 頁面。 ### 157.3。實時群集備份 - CopyTable [copytable](#copy.table) 實用程序可用于將數據從一個表復制到同一個集群上的另一個表，或者將數據復制到另一個集群上的另一個表。 由于群集已啟動，因此存在復制過程中可能遺漏編輯的風險。 ### 157.4。實時群集備份 - 導出 [export](#export) 方法將表的內容轉儲到同一群集上的 HDFS。要恢復數據，將使用 [import](#import) 實用程序。 由于群集已啟動，因此存在導出過程中可能錯過編輯的風險。 ## 158\. HBase 快照 HBase 快照允許您獲取表的副本（包括內容和元數據），并且性能影響非常小。快照是表元數據的不可變集合，以及在拍攝快照時包含表的 HFile 列表。快照的“克隆”從該快照創建新表，快照的“恢復”將表的內容返回到創建快照時的內容。 “克隆”和“恢復”操作不需要復制任何數據，因為底層 HFiles（包含 HBase 表數據的文件）不會被任何操作修改。 Simiarly，將快照導出到另一個集群對本地集群的 RegionServers 幾乎沒有影響。 在版本 0.94.6 之前，備份或克隆表的唯一方法是使用 CopyTable / ExportTable，或者在禁用表后復制 HDFS 中的所有 hfiles。這些方法的缺點是您可以降低區域服務器性能（復制/導出表），或者您需要禁用表，這意味著沒有讀取或寫入;這通常是不可接受的。 ### 158.1。組態 要打開快照支持，只需將`hbase.snapshot.enabled`屬性設置為 true 即可。 （默認情況下，快照在 0.95+中啟用，默認情況下在 0.94.6+時關閉） ``` <property> <name>hbase.snapshot.enabled</name> <value>true</value> </property> ``` ### 158.2。拍一張快照 無論是啟用還是禁用，您都可以創建表的快照。快照操作不涉及任何數據復制。 ``` $ ./bin/hbase shell hbase> snapshot 'myTable', 'myTableSnapshot-122112' ``` 拍攝快照而不刷新 默認行為是在拍攝快照之前在內存中執行數據刷新。這意味著內存中的數據包含在快照中。在大多數情況下，這是期望的行為。但是，如果您的設置可以容忍從快照中排除內存中的數據，則可以使用`snapshot`命令的`SKIP_FLUSH`選項在拍攝快照時禁用和刷新。 ``` hbase> snapshot 'mytable', 'snapshot123', {SKIP_FLUSH => true} ``` > 無論是啟用還是禁用刷新，都無法確定或預測給定快照中是否包含非常并發的插入或更新。快照僅是時間窗口中表的表示。快照操作到達每個區域服務器所花費的時間可能從幾秒到一分鐘不等，具體取決于資源負載和硬件或網絡的速度等因素。也無法知道給定的插入或更新是在內存中還是已刷新。 ### 158.3。列出快照 列出所有拍攝的快照（通過打印名稱和相關信息）。 ``` $ ./bin/hbase shell hbase> list_snapshots ``` ### 158.4。刪除快照 您可以刪除快照，如果不再需要，將刪除為該快照保留的文件。 ``` $ ./bin/hbase shell hbase> delete_snapshot 'myTableSnapshot-122112' ``` ### 158.5。從快照克隆表 從快照中，您可以創建一個新表（克隆操作），其中包含拍攝快照時的相同數據。克隆操作不涉及數據副本，對克隆表的更改不會影響快照或原始表。 ``` $ ./bin/hbase shell hbase> clone_snapshot 'myTableSnapshot-122112', 'myNewTestTable' ``` ### 158.6。恢復快照 還原操作需要禁用表，并且表將恢復到拍攝快照時的狀態，如果需要，還會更改數據和架構。 ``` $ ./bin/hbase shell hbase> disable 'myTable' hbase> restore_snapshot 'myTableSnapshot-122112' ``` > 由于 Replication 在日志級別工作，而快照在文件系統級別工作，因此在還原之后，副本將與主服務器處于不同的狀態。如果要使用還原，則需要停止復制并重做引導程序。 如果由于行為不當而導致部分數據丟失，而不是需要禁用表的完全恢復，您可以從快照克隆表并使用 Map-Reduce 作業從您復制所需的數據，克隆到主要的一個。 ### 158.7。快照操作和 ACL 如果您使用 AccessController 協處理器的安全性（請參閱 [hbase.accesscontrol.configuration](#hbase.accesscontrol.configuration) ），則只有全局管理員才能獲取，克隆或還原快照，并且這些操作不會捕獲 ACL 權限。這意味著還原表會保留現有表的 ACL 權限，而克隆表會創建一個沒有 ACL 權限的新表，直到管理員添加它們為止。 ### 158.8。導出到另一個群集 ExportSnapshot 工具將與快照（hfiles，日志，快照元數據）相關的所有數據復制到另一個群集。該工具執行類似于 distcp 的 Map-Reduce 作業，以在兩個集群之間復制文件，并且由于它在文件系統級別工作，因此 hbase 集群不必在線。 使用 16 個映射器將名為 MySnapshot 的快照復制到 HBase 集群 srv2（hdfs：/// srv2：8082 / hbase）： ``` $ bin/hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot MySnapshot -copy-to hdfs://srv2:8082/hbase -mappers 16 ``` 限制帶寬消耗 您可以通過指定`-bandwidth`參數來限制導出快照時的帶寬消耗，該參數需要一個表示每秒兆字節數的整數。以下示例將上述示例限制為 200 MB /秒。 ``` $ bin/hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot -snapshot MySnapshot -copy-to hdfs://srv2:8082/hbase -mappers 16 -bandwidth 200 ``` ### 158.9。將快照存儲在 Amazon S3 存儲桶中 您可以使用以下過程從 Amazon S3 存儲和檢索快照。 > 您還可以在 Microsoft Azure Blob 存儲中存儲快照。請參閱[在 Microsoft Azure Blob 存儲](#snapshots_azure)中存儲快照。 先決條件 * 您必須使用 HBase 1.0 或更高版本以及 Hadoop 2.6.1 或更高版本，這是第一個使用 Amazon AWS SDK 的配置。 * 您必須使用`s3a://`協議連接到 Amazon S3。舊的`s3n://`和`s3://`協議有各種限制，不使用 Amazon AWS SDK。 * 必須在運行用于導出和還原快照的命令的服務器上配置`s3a://` URI 并使其可用。 完成先決條件后，像平常一樣拍攝快照。之后，您可以使用`org.apache.hadoop.hbase.snapshot.ExportSnapshot`命令將其導出，如下所示，替換`copy-from`或`copy-to`指令中您自己的`s3a://`路徑，并根據需要替換或修改其他選項： ``` $ hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \ -snapshot MySnapshot \ -copy-from hdfs://srv2:8082/hbase \ -copy-to s3a://<bucket>/<namespace>/hbase \ -chuser MyUser \ -chgroup MyGroup \ -chmod 700 \ -mappers 16 ``` ``` $ hbase org.apache.hadoop.hbase.snapshot.ExportSnapshot \ -snapshot MySnapshot -copy-from s3a://<bucket>/<namespace>/hbase \ -copy-to hdfs://srv2:8082/hbase \ -chuser MyUser \ -chgroup MyGroup \ -chmod 700 \ -mappers 16 ``` 您也可以通過包含`-remote-dir`選項將`org.apache.hadoop.hbase.snapshot.SnapshotInfo`實用程序與`s3a://`路徑一起使用。 ``` $ hbase org.apache.hadoop.hbase.snapshot.SnapshotInfo \ -remote-dir s3a://<bucket>/<namespace>/hbase \ -list-snapshots ``` ## 159.在 Microsoft Azure Blob 存儲中存儲快照 您可以使用與[在 Amazon S3 存儲桶中存儲快照](#snapshots_s3)中相同的技術將快照存儲在 Microsoft Azure 博客存儲中。 Prerequisites * 您必須在 Hadoop 2.7.1 或更高版本上使用 HBase 1.2 或更高版本。沒有版本的 HBase 支持 Hadoop 2.7.0。 * 必須將主機配置為了解 Azure Blob 存儲文件系統。見 [https://hadoop.apache.org/docs/r2.7.1/hadoop-azure/index.html](https://hadoop.apache.org/docs/r2.7.1/hadoop-azure/index.html) 。 滿足先決條件后，請按照[在 Amazon S3 存儲桶中存儲快照](#snapshots_s3)中的說明，將協議說明符替換為`wasb://`或`wasbs://`。 ## 160.能力規劃和區域規劃 在規劃 HBase 群集的容量和執行初始配置時，需要考慮幾個因素。首先要充分了解 HBase 如何在內部處理數據。 ### 160.1。節點計數和硬件/ VM 配置 #### 160.1.1。物理數據大小 磁盤上的物理數據大小與數據的邏輯大小不同，并受以下因素影響： * HBase 開銷增加 * 參見 [keyvalue](#keyvalue) 和 [keysize](#keysize) 。每個鍵值（單元格）至少 24 個字節可以更多。小鍵/值意味著更多的相對開銷。 * KeyValue 實例聚合為塊，這些塊已編制索引。索引也必須存儲。 Blocksize 可以基于每個 ColumnFamily 進行配置。見 [regions.arch](#regions.arch) 。 * 由[壓縮](#compression)和數據塊編碼減少，具體取決于數據。另見[這個帖子](http://search-hadoop.com/m/lL12B1PFVhp1)。您可能希望測試哪些壓縮和編碼（如果有）對您的數據有意義。 * 區域服務器 [wal](#wal) 的大小增加（通常固定且可忽略不計 - 小于 RS 內存大小的一半，每 RS）。 * HDFS 復制增加 - 通常是 x3。 除了存儲數據所需的磁盤空間之外，由于區域計數和大小的一些實際限制，一個 RS 可能無法提供任意大量的數據（參見 [ops.capacity.regions](#ops.capacity.regions) ）。 #### 160.1.2。讀/寫吞吐量 節點數也可以由讀取和/或寫入所需的吞吐量驅動。每個節點可以獲得的吞吐量很大程度上取決于數據（尤其是密鑰/值大小）和請求模式，以及節點和系統配置。如果負載可能是節點數量增加的主要驅動因素，則應該針對峰值負載進行規劃。 PerformanceEvaluation 和 [ycsb](#ycsb) 工具可用于測試單個節點或測試集群。 對于寫入，通常每個 RS 可以達到 5-15Mb / s，因為每個區域服務器只有一個活動的 WAL。讀取沒有很好的估計，因為它很大程度上取決于數據，請求和緩存命中率。 [perf.casestudy](#perf.casestudy) 可能會有幫助。 #### 160.1.3。 JVM GC 限制 由于 GC 的成本，RS 目前無法使用非常大的堆。每個服務器運行多個 RS-es 也沒有好辦法（除了每臺機器運行多個 VM）。因此，建議專用于一個 RS 的~20-24Gb 或更少的存儲器。大堆大小需要 GC 調整。參見 [gcpause](#gcpause) ， [trouble.log.gc](#trouble.log.gc) 和其他地方（TODO：哪里？） ### 160.2。確定區域數量和大小 通常較少的區域使得運行集群更加平滑（您可以隨后手動拆分大區域（如果需要）以在集群上傳播數據或請求加載）;每個 RS 20-200 個區域是合理的范圍。無法直接配置區域數量（除非您完全 [disable.splitting](#disable.splitting) ）;調整區域大小以達到給定表大小的目標區域大小。 為多個表配置區域時，請注意，可以通過 [HTableDescriptor](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/HTableDescriptor.html) 以及 shell 命令在每個表的基礎上設置大多數區域設置。這些設置將覆蓋`hbase-site.xml`中的設置。如果您的表具有不同的工作負載/用例，那么這很有用。 另請注意，在這里討論區域大小時， _HDFS 復制因子不會（也不應該）被考慮在內，而其他因素 [ops.capacity.nodes.datasize](#ops.capacity.nodes.datasize) 應該是。_ 因此，如果你的數據被 HDFS 壓縮和復制 3 種方式，“9 Gb 區域”意味著 9 Gb 的壓縮數據。 HDFS 復制因子僅影響磁盤使用，對大多數 HBase 代碼不可見。 #### 160.2.1。查看當前的區域數量 您可以使用 HMaster UI 查看給定表的當前區域數。在“表”部分中，“在線區域”列中列出了每個表的聯機區域數。此總計僅包括內存中狀態，不包括禁用或脫機區域。 #### 160.2.2。每個 RS 的區域數 - 上限 在生產場景中，如果您擁有大量數據，通常會關注每臺服務器可以擁有的最大區域數。 [太多地區](#too_many_regions)就此問題進行了技術討論。基本上，區域的最大數量主要由 memstore 內存使用量決定。每個地區都有自己的 memstore;它們長大到可配置的大小;通常在 128-256 MB 范圍內，請參見 [hbase.hregion.memstore.flush.size](#hbase.hregion.memstore.flush.size) 。每個列族存在一個 memstore（因此，如果表中有一個 CF，則每個區域只有一個）。 RS 將總內存的一部分專用于其存儲器（參見 [hbase.regionserver.global.memstore.size](#hbase.regionserver.global.memstore.size) ）。如果超出此內存（memstore 使用率過高），則可能會導致不良后果，例如無響應的服務器或壓縮風暴。每個 RS 的區域數量（假設一個表）的良好起點是： ``` ((RS memory) * (total memstore fraction)) / ((memstore size)*(# column families)) ``` 這個公式是偽代碼。以下是使用實際可調參數的兩個公式，首先是 HBase 0.98+，第二個是 HBase 0.94.x. HBase 0.98.x ``` ((RS Xmx) * hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size * (# column families)) ``` HBase 0.94.x ``` ((RS Xmx) * hbase.regionserver.global.memstore.upperLimit) / (hbase.hregion.memstore.flush.size * (# column families))+ ``` 如果給定的 RegionServer 具有 16 GB 的 RAM，并且具有默認設置，則該公式可以達到 16384 * 0.4 / 128~51 個區域，每個 RS 是一個起點。公式可以擴展到多個表;如果它們都具有相同的配置，只需使用總系列數。 這個數字可以調整;上面的公式假設您所有的區域都以大致相同的速率填充。如果只有一部分區域將被主動寫入，則可以將結果除以該分數以獲得更大的區域計數。然后，即使寫入所有區域，也不會均勻地填充所有區域存儲器，并且最終出現抖動，即使它們是（由于并發刷新的數量有限）。因此，人們可以擁有比起點多 2-3 倍的區域;然而，增加的數字會增加風險。 對于寫入繁重的工作負載，可以在配置中增加 memstore 分數，但代價是塊緩存;這也將允許一個人擁有更多的地區。 #### 160.2.3。每個 RS 的區域數 - 下限 HBase 通過跨多個服務器的區域來擴展。因此，如果您有 16 個數據的 2 個區域，則在 20 節點計算機上，您的數據將集中在幾臺計算機上 - 幾乎整個群集都將處于空閑狀態。這真的不夠強調，因為一個常見的問題是將 200MB 數據加載到 HBase 中，然后想知道為什么你真棒的 10 節點集群沒有做任何事情。 另一方面，如果您擁有大量數據，您可能還需要選擇更多區域以避免區域過大。 #### 160.2.4。最大區域大小 對于生產場景中的大型表，最大區域大小主要受到壓縮的限制 - 非常大的壓縮，尤其是壓縮。 major，會降低集群性能。目前，推薦的最大區域大小為 10-20Gb，最佳區域為 5-10Gb。對于較早的 0.90.x 代碼庫，regionsize 的上限約為 4Gb，默認值為 256Mb。 區域分成兩部分的大小通常通過 [hbase.hregion.max.filesize](#hbase.hregion.max.filesize) 配置;有關詳細信息，請參閱 [arch.region.splits](#arch.region.splits) 。 如果你不能很好地估計表的大小，那么在開始時，最好堅持使用默認的區域大小，對于熱表可能會更小（或者手動拆分熱區以將負載分散到集群上），或者與如果您的細胞大小往往較大（100k 及以上），則區域尺寸較大。 在 HBase 0.98 中，添加了實驗條帶壓縮功能，允許更大的區域，特別是對于日志數據。見 [ops.stripe](#ops.stripe) 。 #### 160.2.5。每個區域服務器的總數據大小 根據區域大小和每個區域服務器區域數量的上述數字，在樂觀估計中，每個 RS 10 GB×100 個區域將為每個區域服務器提供高達 1TB 的服務，這與一些報告的多 PB 用例一致。但是，重要的是要考慮 RS 級別的數據與緩存大小比率。每個服務器有 1TB 的數據和 10 GB 的塊緩存，只有 1％的數據會被緩存，這幾乎不能覆蓋所有的塊索引。 ### 160.3。初始配置和調整 首先，參見[重要配置](#important_configurations)。請注意，某些配置（多于其他配置）取決于特定方案。特別注意： * [hbase.regionserver.handler.count](#hbase.regionserver.handler.count) - 請求處理程序線程數，對高吞吐量工作負載至關重要。 * [config.wals](#config.wals) - WAL 文件的阻塞數量取決于您的 memstore 配置，應相應地設置以防止在執行大量寫入時可能阻塞。 然后，在設置群集和表時需要考慮一些因素。 #### 160.3.1。 Compactions 根據讀/寫卷和延遲要求，最佳壓縮設置可能不同。有關詳細信息，請參見[壓縮](#compaction)。 但是，在為大數據量配置時，請記住壓縮會影響寫入吞吐量。因此，對于寫入密集型工作負載，您可以選擇較少頻繁的壓縮和每個區域的更多存儲文件。壓縮的最小文件數（`hbase.hstore.compaction.min`）可以設置為更高的值; [hbase.hstore.blockingStoreFiles](#hbase.hstore.blockingStoreFiles) 也應該增加，因為在這種情況下可能會累積更多文件。您也可以考慮手動管理壓縮： [managed.compactions](#managed.compactions) #### 160.3.2。預分割表格 根據每個 RS 的區域的目標數量（參見 [ops.capacity.regions.count](#ops.capacity.regions.count) ）和 RS 的數量，可以在創建時預分割表。當表開始填滿時，這將避免一些昂貴的拆分，并確保表已經分布在許多服務器上。 如果預計該表會增長到足以證明其合理性，則應創建每個 RS 至少一個區域。不建議立即分成完整目標區域數（例如 50 * RSes 數），但可以選擇低中間值。對于多個表，建議保守預分裂（例如，每個 RS 最多預分割 1 個區域），特別是如果您不知道每個表將增長多少。如果分割太多，最終可能會出現太多區域，某些表區域的區域太多。 對于預分割方法，請參見[手動區域分割決策](#manual_region_splitting_decisions)和 [precreate.regions](#precreate.regions) 。 ## 161.表重命名 在 hbase 及更早版本的 0.90.x 版本中，我們有一個簡單的腳本，它將重命名 hdfs 表目錄，然后編輯 hbase：meta 表，用 new 替換舊表名的所有提及。該腳本被稱為`./bin/rename_table.rb`。該腳本已被棄用和刪除，主要是因為它沒有維護并且腳本執行的操作是殘酷的。 從 hbase 0.94.x 開始，您可以使用快照工具重命名表。以下是使用 hbase shell 的方法： ``` hbase shell> disable 'tableName' hbase shell> snapshot 'tableName', 'tableSnapshot' hbase shell> clone_snapshot 'tableSnapshot', 'newTableName' hbase shell> delete_snapshot 'tableSnapshot' hbase shell> drop 'tableName' ``` 或者在代碼中它將如下： ``` void rename(Admin admin, String oldTableName, TableName newTableName) { String snapshotName = randomName(); admin.disableTable(oldTableName); admin.snapshot(snapshotName, oldTableName); admin.cloneSnapshot(snapshotName, newTableName); admin.deleteSnapshot(snapshotName); admin.deleteTable(oldTableName); } ``` ## 162\. RegionServer 分組 RegionServer Grouping（A.K.A `rsgroup`）是一種高級功能，用于將區域服務器劃分為獨特的組以進行嚴格隔離。它只應由足夠復雜的用戶使用，以便了解完整的含義并具有足夠的背景來管理 HBase 集群。它是由雅虎開發的！并且他們在大型網格集群上大規模運行它。請參閱雅虎的 [HBase！比例](http://www.slideshare.net/HBaseCon/keynote-apache-hbase-at-yahoo-scale)。 RSGroups 是使用 shell 命令定義和管理的。 shell 驅動一個 Coprocessor 端點，其 API 被標記為私有，因為這是一個不斷發展的功能;協處理器 API 不供公眾使用。可以將服務器添加到具有主機名和端口對的組中，并且可以將表移動到該組，以便只有同一 rsgroup 中的區域服務器可以托管表的區域。 RegionServers 和表一次只能屬于一個 rsgroup。默認情況下，所有表和區域服務器都屬于`default` rsgroup。系統表也可以使用常規 API 放入 rsgroup。自定義平衡器實現跟蹤每個 rsgroup 的分配，并確保將區域移動到該 rsgroup 中的相關區域服務器。 rsgroup 信息存儲在常規 HBase 表中，并且在集群引導時使用基于 zookeeper 的只讀緩存。 要啟用，請將以下內容添加到 hbase-site.xml 并重新啟動主服務器： ``` <property> <name>hbase.coprocessor.master.classes</name> <value>org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint</value> </property> <property> <name>hbase.master.loadbalancer.class</name> <value>org.apache.hadoop.hbase.rsgroup.RSGroupBasedLoadBalancer</value> </property> ``` 然后使用 shell _rsgroup_ 命令創建和操作 RegionServer 組：例如添加一個 rsgroup，然后添加一個服務器。要查看 hbase shell 類型中可用的 rsgroup 命令列表，請執行以下操作： ``` hbase(main):008:0> help ‘rsgroup’ Took 0.5610 seconds ``` 高級別，使用 _add _rsgroup_ 命令創建一個不同于`default`組的 rsgroup。然后使用 _move_servers _rsgroup_ 和 _move_tables _rsgroup_ 命令將服務器和表添加到該組。如果表格很慢，請使用 _balance _rsgroup_ 命令遷移到組專用服務器（如果不需要），則必要時為組運行余額。要監視命令的效果，請參閱 Master UI 主頁末尾的`Tables`選項卡。如果單擊某個表，則可以查看它所部署的服務器。您應該在這里看到使用 shell 命令完成的分組的反映。如果出現問題，請查看主日志。 以下是使用一些 rsgroup 命令的示例。要添加組，請執行以下操作： ``` hbase(main):008:0> add_rsgroup 'my_group' Took 0.5610 seconds ``` > 必須啟用 RegionServer Groups > > 如果尚未在主服務器中啟用 rsgroup 協處理器端點，并且運行任何 rsgroup shell 命令，您將看到如下錯誤消息： > > ``` > ERROR: org.apache.hadoop.hbase.exceptions.UnknownProtocolException: No registered master coprocessor service found for name RSGroupAdminService > at org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:604) > at org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:1140) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133) > at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:277) > at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:257) > ``` 使用 _move_servers _rsgroup_ 命令將服務器（由主機名+端口指定）添加到剛創組中，如下所示： ``` hbase(main):010:0> move_servers_rsgroup 'my_group',['k.att.net:51129'] ``` > 主機名和端口與 ServerNam > > rsgroup 功能是指群集中僅具有主機名和端口的服務器。它不使用標識 RegionServers 的 HBase ServerName 類型; ie hostname + port + starttime 來區分 RegionServer 實例。 rsgroup 功能在 RegionServer 重新啟動時保持工作，因此 ServerName 的啟動時間 - 因此 ServerName 類型 - 不合適。管理 服務器在群集的生命周期中來回走動。目前，您必須手動將 rsgroups 中引用的服務器與正在運行的集群中的節點的實際狀態對齊。我們的意思是，如果您停用服務器，那么您必須更新 rsgroups 作為服務器停用過程中刪除引用的一部分。 但是，你說沒有 _remove_offline_servers_rsgroup_command！ 刪除服務器的方法是將其移動到`default`組。 `default`組很特別。所有 rsgroup，但`default` rsgroup，都是靜態的，因為通過 shell 命令進行的編輯會持久保存到系統`hbase:rsgroup`表中。如果它們引用了已停用的服務器，則需要更新它們以撤消引用。 `default`組與其他 rsgroup 不同，因為它是動態的。其服務器列表鏡像了集群的當前狀態;即如果您關閉屬于`default` rsgroup 的服務器，然后執行 _get _rsgroup_ `default`以在 shell 中列出其內容，則將不再列出服務器。對于非`default`組，雖然模式可能處于脫機狀態，但它將保留在非`default`組的服務器列表中。但是，如果將脫機服務器從非默認 rsgroup 移動到默認值，它將不會顯示在`default`列表中。它將被刪除。 ### 162.1。最佳實踐 rsgroup 功能的作者，雅虎！ HBase 工程團隊已經在他們的網格上運行了很長一段時間，并根據他們的經驗提出了一些最佳實踐。 #### 162.1.1。隔離系統表 有一個系統 rsgroup，其中所有系統表都是或者只是將系統表保留在`default` rsgroup 中，并且所有用戶空間表都在非`default` rsgroups 中。 #### 162.1.2。死節點 雅虎已經發現它在規模上有用，可以保留特殊的死組或可疑節點組;這是一種讓它們在運行之前保持運行的方法。 小心替換 rsgroup 中的死節點。確保在開始移除死亡之前有足夠的活動節點。如果必須，首先移動好的實時節點。 ### 162.2。故障排除 查看主日志將為您提供有關 rsgroup 操作的信息。 如果卡住，請重新啟動主進程。 ### 162.3。刪除 RegionServer 分組 除了從`hbase-site.xml`中刪除相關屬性之外，從啟用了它的群集中刪除 RegionServer 分組功能還涉及更多步驟。這是為了清除 RegionServer 分組相關的元數據，以便在將來重新啟用該功能時，舊的元數據不會影響群集的功能。 * 將非默認 rsgroup 中的所有表移動到`default` regionserver 組 ``` #Reassigning table t1 from non default group - hbase shell hbase(main):005:0> move_tables_rsgroup 'default',['t1'] ``` * 將非默認 rsgroup 中的所有 regionservers 移動到`default` regionserver 組 ``` #Reassigning all the servers in the non-default rsgroup to default - hbase shell hbase(main):008:0> move_servers_rsgroup 'default',['rs1.xxx.com:16206','rs2.xxx.com:16202','rs3.xxx.com:16204'] ``` * 刪除所有非默認 rsgroups。隱式創建的`default` rsgroup 不必刪除 ``` #removing non default rsgroup - hbase shell hbase(main):009:0> remove_rsgroup 'group2' ``` * 刪除`hbase-site.xml`中所做的更改并重新啟動群集 * 從`hbase`中刪除表`hbase:rsgroup` ``` #Through hbase shell drop table hbase:rsgroup hbase(main):001:0> disable 'hbase:rsgroup' 0 row(s) in 2.6270 seconds hbase(main):002:0> drop 'hbase:rsgroup' 0 row(s) in 1.2730 seconds ``` * 使用 zkCli.sh 從集群 ZooKeeper 中刪除 znode `rsgroup` ``` #From ZK remove the node /hbase/rsgroup through zkCli.sh rmr /hbase/rsgroup ``` ### 162.4。 ACL 要啟用 ACL，請將以下內容添加到 hbase-site.xml 并重新啟動 Master： ``` <property> <name>hbase.security.authorization</name> <value>true</value> <property> ``` ## 163\. Region Normalizer Region Normalizer 嘗試在表中創建大小相同的區域。它通過找到粗略的平均值來做到這一點。任何大于這個大小兩倍的區域都會被拆分。任何小得多的區域都會合并到一個相鄰區域。最好在群集運行一段時間之后的停機時間運行 Normalizer，或者在一系列活動（例如大型刪除）之后說。 （下面的大部分內容是由 Romil Choksi 在 [HBase Region Normalizer](https://community.hortonworks.com/articles/54987/hbase-region-normalizer.html) ）的博客中批發復制的。 區域規范化器自 HBase-1.2 起可用。它運行一組預先計算的合并/拆分操作，以調整與給定表的平均區域大小相比太大或太小的區域。調用時的 Region Normalizer 計算 HBase 中所有表的規范化“計劃”。在計算計劃時，將忽略系統表（例如 hbase：meta，hbase：命名空間，Phoenix 系統表等）和禁用規范化的用戶表。對于啟用規范化的表，規范化計劃跨多個表并行執行。 可以使用 HBase shell 中的“normalizer_switch”命令為整個集群全局啟用或禁用 Normalizer。還可以基于每個表控制規范化，默認情況下在創建表時禁用規范化。通過將 NORMALIZATION_ENABLED 表屬性設置為 true 或 false，可以啟用或禁用表的規范化。 檢查規范器狀態并啟用/禁用規范化器 ``` hbase(main):001:0> normalizer_enabled true 0 row(s) in 0.4870 seconds hbase(main):002:0> normalizer_switch false true 0 row(s) in 0.0640 seconds hbase(main):003:0> normalizer_enabled false 0 row(s) in 0.0120 seconds hbase(main):004:0> normalizer_switch true false 0 row(s) in 0.0200 seconds hbase(main):005:0> normalizer_enabled true 0 row(s) in 0.0090 seconds ``` 啟用后，每 5 分鐘（默認情況下）在后臺調用 Normalizer，可以使用`hbase-site.xml`中的`hbase.normalization.period`進行配置。也可以使用 HBase shell 的`normalize`命令手動/編程調用 Normalizer。 HBase 默認使用`SimpleRegionNormalizer`，但只要用戶實現 RegionNormalizer 接口，用戶就可以設計自己的規范化器。有關`SimpleRegionNormalizer`用于計算其歸一化計劃的邏輯的詳細信息，請參見 [](https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/SimpleRegionNormalizer.html) 。 下面的示例顯示了為用戶表計算的規范化計劃，以及由 SimpleRegionNormalizer 計算的規范化計劃的結果。 考慮具有一些預分割區域的用戶表，所述預分割區域具有 3 個相等大的區域（大約 100K 行）和 1 個相對小的區域（大約 25K 行）。以下是 hbase 元表掃描的片段，顯示用戶表的每個預分割區域。 ``` table_p8ddpd6q5z,,1469494305548.68b9892220865cb6048 column=info:regioninfo, timestamp=1469494306375, value={ENCODED => 68b9892220865cb604809c950d1adf48, NAME => 'table_p8ddpd6q5z,,1469494305548.68b989222 09c950d1adf48\. 0865cb604809c950d1adf48.', STARTKEY => '', ENDKEY => '1'} .... table_p8ddpd6q5z,1,1469494317178.867b77333bdc75a028 column=info:regioninfo, timestamp=1469494317848, value={ENCODED => 867b77333bdc75a028bb4c5e4b235f48, NAME => 'table_p8ddpd6q5z,1,1469494317178.867b7733 bb4c5e4b235f48\. 3bdc75a028bb4c5e4b235f48.', STARTKEY => '1', ENDKEY => '3'} .... table_p8ddpd6q5z,3,1469494328323.98f019a753425e7977 column=info:regioninfo, timestamp=1469494328486, value={ENCODED => 98f019a753425e7977ab8636e32deeeb, NAME => 'table_p8ddpd6q5z,3,1469494328323.98f019a7 ab8636e32deeeb. 53425e7977ab8636e32deeeb.', STARTKEY => '3', ENDKEY => '7'} .... table_p8ddpd6q5z,7,1469494339662.94c64e748979ecbb16 column=info:regioninfo, timestamp=1469494339859, value={ENCODED => 94c64e748979ecbb166f6cc6550e25c6, NAME => 'table_p8ddpd6q5z,7,1469494339662.94c64e74 6f6cc6550e25c6\. 8979ecbb166f6cc6550e25c6.', STARTKEY => '7', ENDKEY => '8'} .... table_p8ddpd6q5z,8,1469494339662.6d2b3f5fd1595ab8e7 column=info:regioninfo, timestamp=1469494339859, value={ENCODED => 6d2b3f5fd1595ab8e7c031876057b1ee, NAME => 'table_p8ddpd6q5z,8,1469494339662.6d2b3f5f c031876057b1ee. d1595ab8e7c031876057b1ee.', STARTKEY => '8', ENDKEY => ''} ``` 使用 HBase shell 中的'normalize'調用規范化程序，HMaster 日志中的以下日志片段顯示了根據為 SimpleRegionNormalizer 定義的邏輯計算的規范化計劃。由于表中相鄰最小區域的總區域大小（以 MB 為單位）小于平均區域大小，因此歸一化器計算合并這兩個區域的計劃。 ``` 2016-07-26 07:08:26,928 DEBUG [B.fifo.QRpcServer.handler=20,queue=2,port=20000] master.HMaster: Skipping normalization for table: hbase:namespace, as it's either system table or doesn't have auto normalization turned on 2016-07-26 07:08:26,928 DEBUG [B.fifo.QRpcServer.handler=20,queue=2,port=20000] master.HMaster: Skipping normalization for table: hbase:backup, as it's either system table or doesn't have auto normalization turned on 2016-07-26 07:08:26,928 DEBUG [B.fifo.QRpcServer.handler=20,queue=2,port=20000] master.HMaster: Skipping normalization for table: hbase:meta, as it's either system table or doesn't have auto normalization turned on 2016-07-26 07:08:26,928 DEBUG [B.fifo.QRpcServer.handler=20,queue=2,port=20000] master.HMaster: Skipping normalization for table: table_h2osxu3wat, as it's either system table or doesn't have autonormalization turned on 2016-07-26 07:08:26,928 DEBUG [B.fifo.QRpcServer.handler=20,queue=2,port=20000] normalizer.SimpleRegionNormalizer: Computing normalization plan for table: table_p8ddpd6q5z, number of regions: 5 2016-07-26 07:08:26,929 DEBUG [B.fifo.QRpcServer.handler=20,queue=2,port=20000] normalizer.SimpleRegionNormalizer: Table table_p8ddpd6q5z, total aggregated regions size: 12 2016-07-26 07:08:26,929 DEBUG [B.fifo.QRpcServer.handler=20,queue=2,port=20000] normalizer.SimpleRegionNormalizer: Table table_p8ddpd6q5z, average region size: 2.4 2016-07-26 07:08:26,929 INFO [B.fifo.QRpcServer.handler=20,queue=2,port=20000] normalizer.SimpleRegionNormalizer: Table table_p8ddpd6q5z, small region size: 0 plus its neighbor size: 0, less thanthe avg size 2.4, merging them 2016-07-26 07:08:26,971 INFO [B.fifo.QRpcServer.handler=20,queue=2,port=20000] normalizer.MergeNormalizationPlan: Executing merging normalization plan: MergeNormalizationPlan{firstRegion={ENCODED=> d51df2c58e9b525206b1325fd925a971, NAME => 'table_p8ddpd6q5z,,1469514755237.d51df2c58e9b525206b1325fd925a971.', STARTKEY => '', ENDKEY => '1'}, secondRegion={ENCODED => e69c6b25c7b9562d078d9ad3994f5330, NAME => 'table_p8ddpd6q5z,1,1469514767669.e69c6b25c7b9562d078d9ad3994f5330.', STARTKEY => '1', ENDKEY => '3'}} ``` 區域規范化器根據其計算的計劃，將具有開始鍵的區域合并為“”并將結束鍵合并為“1”，將另一個區域的起始鍵合并為“1”并將結束鍵合并為“3”。現在，這些區域已合并，我們看到一個新區域，其開始鍵為''，結束鍵為'3' ``` table_p8ddpd6q5z,,1469516907210.e06c9b83c4a252b130e column=info:mergeA, timestamp=1469516907431, value=PBUF\x08\xA5\xD9\x9E\xAF\xE2*\x12\x1B\x0A\x07default\x12\x10table_p8ddpd6q5z\x1A\x00"\x011(\x000\x00 ea74d246741ba. 8\x00 table_p8ddpd6q5z,,1469516907210.e06c9b83c4a252b130e column=info:mergeB, timestamp=1469516907431, value=PBUF\x08\xB5\xBA\x9F\xAF\xE2*\x12\x1B\x0A\x07default\x12\x10table_p8ddpd6q5z\x1A\x011"\x013(\x000\x0 ea74d246741ba. 08\x00 table_p8ddpd6q5z,,1469516907210.e06c9b83c4a252b130e column=info:regioninfo, timestamp=1469516907431, value={ENCODED => e06c9b83c4a252b130eea74d246741ba, NAME => 'table_p8ddpd6q5z,,1469516907210.e06c9b83c ea74d246741ba. 4a252b130eea74d246741ba.', STARTKEY => '', ENDKEY => '3'} .... table_p8ddpd6q5z,3,1469514778736.bf024670a847c0adff column=info:regioninfo, timestamp=1469514779417, value={ENCODED => bf024670a847c0adffb74b2e13408b32, NAME => 'table_p8ddpd6q5z,3,1469514778736.bf024670 b74b2e13408b32\. a847c0adffb74b2e13408b32.' STARTKEY => '3', ENDKEY => '7'} .... table_p8ddpd6q5z,7,1469514790152.7c5a67bc755e649db2 column=info:regioninfo, timestamp=1469514790312, value={ENCODED => 7c5a67bc755e649db22f49af6270f1e1, NAME => 'table_p8ddpd6q5z,7,1469514790152.7c5a67bc 2f49af6270f1e1\. 755e649db22f49af6270f1e1.', STARTKEY => '7', ENDKEY => '8'} .... table_p8ddpd6q5z,8,1469514790152.58e7503cda69f98f47 column=info:regioninfo, timestamp=1469514790312, value={ENCODED => 58e7503cda69f98f4755178e74288c3a, NAME => 'table_p8ddpd6q5z,8,1469514790152.58e7503c 55178e74288c3a. da69f98f4755178e74288c3a.', STARTKEY => '8', ENDKEY => ''} ``` 對于具有 3 個較小區域和 1 個相對較大區域的用戶表，可以看到類似的示例。對于此示例，我們有一個用戶表，其中包含 1 個包含 100K 行的大區域，以及 3 個相對較小的區域，每個區域包含大約 33K 行。從規范化計劃可以看出，由于較大的區域是平均區域大小的兩倍以上，因此它被分成兩個區域 - 一個用起始鍵作為'1'，一個鍵作為'154717'，另一個區域用起始鍵作為'154717'。 '154717'和結束鍵為'3' ``` 2016-07-26 07:39:45,636 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] master.HMaster: Skipping normalization for table: hbase:backup, as it's either system table or doesn't have auto normalization turned on 2016-07-26 07:39:45,636 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SimpleRegionNormalizer: Computing normalization plan for table: table_p8ddpd6q5z, number of regions: 4 2016-07-26 07:39:45,636 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SimpleRegionNormalizer: Table table_p8ddpd6q5z, total aggregated regions size: 12 2016-07-26 07:39:45,636 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SimpleRegionNormalizer: Table table_p8ddpd6q5z, average region size: 3.0 2016-07-26 07:39:45,636 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SimpleRegionNormalizer: No normalization needed, regions look good for table: table_p8ddpd6q5z 2016-07-26 07:39:45,636 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SimpleRegionNormalizer: Computing normalization plan for table: table_h2osxu3wat, number of regions: 5 2016-07-26 07:39:45,636 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SimpleRegionNormalizer: Table table_h2osxu3wat, total aggregated regions size: 7 2016-07-26 07:39:45,636 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SimpleRegionNormalizer: Table table_h2osxu3wat, average region size: 1.4 2016-07-26 07:39:45,636 INFO [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SimpleRegionNormalizer: Table table_h2osxu3wat, large region table_h2osxu3wat,1,1469515926544.27f2fdbb2b6612ea163eb6b40753c3db. has size 4, more than twice avg size, splitting 2016-07-26 07:39:45,640 INFO [B.fifo.QRpcServer.handler=7,queue=1,port=20000] normalizer.SplitNormalizationPlan: Executing splitting normalization plan: SplitNormalizationPlan{regionInfo={ENCODED => 27f2fdbb2b6612ea163eb6b40753c3db, NAME => 'table_h2osxu3wat,1,1469515926544.27f2fdbb2b6612ea163eb6b40753c3db.', STARTKEY => '1', ENDKEY => '3'}, splitPoint=null} 2016-07-26 07:39:45,656 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] master.HMaster: Skipping normalization for table: hbase:namespace, as it's either system table or doesn't have auto normalization turned on 2016-07-26 07:39:45,656 DEBUG [B.fifo.QRpcServer.handler=7,queue=1,port=20000] master.HMaster: Skipping normalization for table: hbase:meta, as it's either system table or doesn't have auto normalization turned on …..…..…. 2016-07-26 07:39:46,246 DEBUG [AM.ZK.Worker-pool2-t278] master.RegionStates: Onlined 54de97dae764b864504704c1c8d3674a on hbase-test-rc-5.openstacklocal,16020,1469419333913 {ENCODED => 54de97dae764b864504704c1c8d3674a, NAME => 'table_h2osxu3wat,1,1469518785661.54de97dae764b864504704c1c8d3674a.', STARTKEY => '1', ENDKEY => '154717'} 2016-07-26 07:39:46,246 INFO [AM.ZK.Worker-pool2-t278] master.RegionStates: Transition {d6b5625df331cfec84dce4f1122c567f state=SPLITTING_NEW, ts=1469518786246, server=hbase-test-rc-5.openstacklocal,16020,1469419333913} to {d6b5625df331cfec84dce4f1122c567f state=OPEN, ts=1469518786246, server=hbase-test-rc-5.openstacklocal,16020,1469419333913} 2016-07-26 07:39:46,246 DEBUG [AM.ZK.Worker-pool2-t278] master.RegionStates: Onlined d6b5625df331cfec84dce4f1122c567f on hbase-test-rc-5.openstacklocal,16020,1469419333913 {ENCODED => d6b5625df331cfec84dce4f1122c567f, NAME => 'table_h2osxu3wat,154717,1469518785661.d6b5625df331cfec84dce4f1122c567f.', STARTKEY => '154717', ENDKEY => '3'} ```