HBase升級路徑

HBase升級路徑

HBase：從 0.98.x 升級到 1.x

在本節(jié)中，首先，你需要注意 1.0.0 版本以上的 HBase 做出了重大的更改，所以在繼續(xù)升級過程前，你應(yīng)該仔細(xì)閱讀這些重要的更改部分，以免發(fā)生意外。

HBase 1.0.0+ 重要更改部分：

在這里，我們列出了自 0.98.x 版本之后的 1.0.0 以上版本的重要更改，您應(yīng)該知道這些更改會在升級后生效。

• HBase 1.0.0+ 中 ZooKeeper 3.4 是必需的。
• HBase 默認(rèn)端口已更改：
  

  HBase使用的端口已更改。他們曾經(jīng)是在600XX范圍內(nèi)。在HBase 1.0.0中，它們已經(jīng)從臨時端口范圍中移出，并且是160XX（主 Web UI 為 60010，現(xiàn)在為16010; RegionServer Web UI 為 60030，現(xiàn)在為16030等）。如果要保留舊的端口位置，請將hbase-default.xml中的端口設(shè)置配置復(fù)制到hbase-site.xml中，將它們更改回 HBase 0.98.x 版本的舊值，并確保在重新啟動之前已分發(fā)了配置。
  

• HBase 主端口綁定更改：
  

  在 HBase 1.0.x 中，HBase Master綁定RegionServer端口以及主端口。此行為從1.0之前的 HBase 版本更改。在 HBase 1.1 和 2.0 分支中，此行為將恢復(fù)為 HBase 主服務(wù)器未綁定RegionServer端口的 1.0 行為。
  

• hbase.bucketcache.percentage.in.combinedcache 配置已被刪除：
  

  如果您正在使用BucketCache，則可能已使用此配置。如果不使用 BucketCache，則此更改不會影響您。它的移除意味著您的 L1 LruBlockCache 現(xiàn)在使用 hfile.block.cache.size 來調(diào)整大小，即，如果您不在執(zhí)行 BucketCache，您可以調(diào)整堆上 L1 LruBlockCache 的大小 - 并且 BucketCache 大小不適用于該 hbase.bucketcache.size 設(shè)置。您可能需要調(diào)整 configs 以將 LruBlockCache 和 BucketCache 大小設(shè)置為 0.98.x 和之前的大小。如果你沒有設(shè)置這個配置，它的默認(rèn)值是 0.9。如果你什么都不做，你的 BucketCache 將會增加10％。您的 L1 LruBlockCache 將成為 java 堆大小的 hfile.block.cache.size 倍（hfile.block.cache.size 是 0.0 到 1.0 之間的浮點數(shù)）。

HBase：從 0.96.x 升級到 0.98.x

HBase 從 0.96.x 到 0.98.x 的滾動升級工作。這兩個版本不是二進(jìn)制兼容的。

需要執(zhí)行其他步驟才能利用 0.98.x 的一些新功能，包括單元可見性標(biāo)簽，單元 ACL 和透明服務(wù)器端加密。有關(guān)更多信息，請參閱保護(hù) Apache HBase。顯著的性能改進(jìn)包括對提前寫日志線程模型的更改，它在高負(fù)載、反向掃描儀、MapReduce 快照文件和帶區(qū)壓縮的情況下提供更高的事務(wù)吞吐量。

客戶端和服務(wù)器可以運行 0.98.x 和 0.96.x 版本。但是，由于 Java API 中的更改，應(yīng)用程序可能需要重新編譯。

HBase：從 0.94.x 升級到 0.98.x

HBase 從 0.94.x 直接到 0.98.x 的滾動升級不起作用。升級路徑遵循與從 0.94.x 升級到 0.96.x 相同的過程。需要額外的步驟才能使用 0.98.x 的一些新功能。

HBase：從 0.94.x 升級到 0.96.x

Singularity

您必須完全停止舊版本的 0.94.x 群集才能進(jìn)行升級。如果您正在群集之間進(jìn)行復(fù)制，則兩個群集都必須進(jìn)行升級。請確保它完全處于關(guān)機(jī)狀態(tài)。WAL 文件越少，升級運行的速度就越快（升級將在文件系統(tǒng)中找到的所有日志文件都分解為升級過程的一部分）。所有客戶端也必須升級到 0.96。

API 已經(jīng)改變。您需要重新編譯 0.96 的代碼，您可能需要調(diào)整應(yīng)用程序以適應(yīng)新的 API（TODO：更改列表）。

執(zhí)行 0.96 升級

在升級過程中，HDFS 和 ZooKeeper 必須啟動并運行！

HBase 0.96.0 附帶升級腳本，請運行：

$ bin/hbase upgrade

以查看其用法。該升級腳本有兩種主要模式：check 和 execute。

check

檢查（check）步驟針對正在運行的 0.94 群集運行。從下載的 0.96.x 二進(jìn)制文件運行它。檢查步驟正在尋找 HFile v1 文件的存在。這些在 HBase 0.96.0 中不受支持。要讓它們重寫為 HFile v2，您必須運行壓縮。

檢查步驟在其運行結(jié)束時打印統(tǒng)計數(shù)據(jù)（在日志中 grep 用于 “Result:”），打印其掃描的表的絕對路徑、找到的任何 HFile v1 文件、包含所述文件的區(qū)域（這些區(qū)域?qū)⑿枰蟮膲嚎s）以及任何如果找到損壞的文件。一個損壞的文件是不可讀的，所以未定義（HFile v1 和 HFile v2 都沒有）。

要運行檢查步驟，請運行：

$ bin/hbase upgrade -check

這里是示例輸出：

Tables Processed:
hdfs://localhost:41020/myHBase/.META.
hdfs://localhost:41020/myHBase/usertable
hdfs://localhost:41020/myHBase/TestTable
hdfs://localhost:41020/myHBase/t

Count of HFileV1: 2
HFileV1:
hdfs://localhost:41020/myHBase/usertable    /fa02dac1f38d03577bd0f7e666f12812/family/249450144068442524
hdfs://localhost:41020/myHBase/usertable    /ecdd3eaee2d2fcf8184ac025555bb2af/family/249450144068442512

Count of corrupted files: 1
Corrupted Files:
hdfs://localhost:41020/myHBase/usertable/fa02dac1f38d03577bd0f7e666f12812/family/1
Count of Regions with HFileV1: 2
Regions to Major Compact:
hdfs://localhost:41020/myHBase/usertable/fa02dac1f38d03577bd0f7e666f12812
hdfs://localhost:41020/myHBase/usertable/ecdd3eaee2d2fcf8184ac025555bb2af

There are some HFileV1, or corrupt files (files with incorrect major version)

在上面的示例輸出中，兩個區(qū)域中有兩個 HFile v1 文件和一個損壞的文件，應(yīng)該刪除損壞的文件。具有 HFile v1 的地區(qū)需要進(jìn)行大規(guī)模壓縮。為了緊湊，請啟動hbase shell 并查看如何壓縮單個區(qū)域。完成主要壓縮后，重新運行檢查步驟，并且 HFile v1 文件應(yīng)該消失，替換為 HFile v2 實例。

默認(rèn)情況下，檢查步驟將掃描 HBase 根目錄（在配置中定義為 hbase.rootdir）。要僅掃描特定目錄，請傳遞 dir 選項。

$ bin/hbase upgrade -check -dir /myHBase/testTable

上述命令將檢測 /myHBase/testTable 目錄中的 HFile v1 文件。

一旦檢查步驟報告所有 HFile v1 文件已被重寫，則繼續(xù)進(jìn)行升級是安全的。

execute

在檢查步驟顯示群集沒有 HFile v1 后，繼續(xù)升級是安全的。接下來是執(zhí)行（execute）步驟。在執(zhí)行 execute 步驟之前，您必須關(guān)閉您的 0.94.x CLUSTER。如果檢測到正在運行的 HBase 主服務(wù)器或 RegionServer，則 execute 步驟將不會運行。

在升級過程中，HDFS 和 ZooKeeper 應(yīng)該啟動并運行。如果 zookeeper 由 HBase 管理，那么您可以啟動 zookeeper，以便通過運行升級：

$ ./hbase/bin/hbase-daemon.sh start zookeeper

執(zhí)行升級步驟由三個子步驟組成。

• 命名空間：HBase 0.96.0 支持命名空間。升級需要重新排序文件系統(tǒng)中的目錄以使命名空間正常工作。
• ZNodes：清除所有 znode，以便可以使用新的 protobuf'ed 格式將新的 znode 寫入其位置，并且可以將一些 znode 遷移到適當(dāng)位置：例如復(fù)制和表狀態(tài)znodes
• WAL 日志分割：如果 0.94.x 集群沒有完全關(guān)閉，我們將在0.96.0 啟動之前將 WAL 日志分割為遷移的一部分。這個 WAL 分割比本地分布式 WAL 分割運行速度慢，因為它全部在單個升級過程中。

要運行執(zhí)行步驟，請確保首先在服務(wù)器和客戶端的各處復(fù)制了 HBase 0.96.0 二進(jìn)制文件。確保 0.94.0 群集已關(guān)閉。然后執(zhí)行如下操作：

$ bin/hbase upgrade -execute

以下是一些示例輸出：

Starting Namespace upgrade
Created version file at hdfs://localhost:41020/myHBase with version=7
Migrating table testTable to hdfs://localhost:41020/myHBase/.data/default/testTable
.....
Created version file at hdfs://localhost:41020/myHBase with version=8
Successfully completed NameSpace upgrade.
Starting Znode upgrade
.....
Successfully completed Znode upgrade

Starting Log splitting
...
Successfully completed Log splitting

如果執(zhí)行步驟的輸出看起來不錯，請停止開始執(zhí)行升級的zookeeper實例：

$ ./hbase/bin/hbase-daemon.sh stop zookeeper

然后就可以啟動 hbase-0.96.0。

故障排除

舊客戶端連接到0.96群集

出現(xiàn)如下的異常，升級過程將會失?。?/p>

17:22:15  Exception in thread "main" java.lang.IllegalArgumentException: Not a host:port pair: PBUF
17:22:15  *
17:22:15   api-compat-8.ent.cloudera.com ??  ???(
17:22:15    at org.apache.hadoop.hbase.util.Addressing.parseHostname(Addressing.java:60)
17:22:15    at org.apache.hadoop.hbase.ServerName.&init>(ServerName.java:101)
17:22:15    at org.apache.hadoop.hbase.ServerName.parseVersionedServerName(ServerName.java:283)
17:22:15    at org.apache.hadoop.hbase.MasterAddressTracker.bytesToServerName(MasterAddressTracker.java:77)
17:22:15    at org.apache.hadoop.hbase.MasterAddressTracker.getMasterAddress(MasterAddressTracker.java:61)
17:22:15    at org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getMaster(HConnectionManager.java:703)
17:22:15    at org.apache.hadoop.hbase.client.HBaseAdmin.&init>(HBaseAdmin.java:126)
17:22:15    at Client_4_3_0.setup(Client_4_3_0.java:716)
17:22:15    at Client_4_3_0.main(Client_4_3_0.java:63)

升級 META 以使用 Protocol Buffers（Protobuf）

HBase 從 0.96 之前的版本升級時，META 需要轉(zhuǎn)換為使用協(xié)議緩沖區(qū)（Protobuf）。這是由配置選項 hbase.MetaMigrationConvertingToPB 控制，它在默認(rèn)情況下被設(shè)置為 true。因此，默認(rèn)情況下，您不需要采取任何措施。

遷移是一次性事件。但是，每次啟動群集時，META 都會進(jìn)行掃描以確保不需要轉(zhuǎn)換。如果您的區(qū)域數(shù)量非常多，則此掃描可能需要很長時間。在 0.98.5 開始，您可以在 HBase的-site.xml 中設(shè)置 hbase.MetaMigrationConvertingToPB 為 false ，以禁用此啟動掃描。

HBase：從 0.92.x 升級到 0.94.x

我們曾經(jīng)認(rèn)為 HBase 的 0.92 版本和 0.94 版本是接口兼容的，您可以在這些版本之間進(jìn)行滾動升級，但是后來我們發(fā)現(xiàn) HColumnDescriptor 中的HBASE-5357 Use builder 模式更改了方法簽名，不是返回 void，而是返回 HColumnDescriptor。這將拋出 java.lang.NoSuchMethodError: org.apache.hadoop.hbase.HColumnDescriptor.setMaxVersions(I)V，因此 0.92 和 0.94 不兼容，你不能在它們之間進(jìn)行滾動升級。

HBase：從 0.90.x 升級到 0.92.x

升級指南

您會發(fā)現(xiàn) 0.92.0 與 0.90.x 版本稍有不同，這里有一些需要注意的事項。

這些是升級前需要了解的重要內(nèi)容：

• 默認(rèn)情況下 MSLAB 處于開啟狀態(tài)。如果您有很多區(qū)域，請觀看該堆的使用情況。
  
• 默認(rèn)情況下，分布式日志分割處于開啟狀態(tài)。它應(yīng)該使 RegionServer 故障轉(zhuǎn)移更快。
  
• 有一個單獨的包安全。
  
• 如果 -XX: MaxDirectMemorySize 是設(shè)置在您的 hbase. sh，它將啟用實驗性的離堆緩存 (您可能不希望這樣)。

不可回退：

要移動到 0.92.0，你只需關(guān)閉群集，將 HBase 0.90.x 替換為 HBase 0.92.0 二進(jìn)制文件（確保清除所有 0.90.x 實例）并重新啟動（不能從 0.90.x 到 0.92.x 重新啟動，必須重新啟動）。在啟動時，.META. 表格內(nèi)容被重寫，從 info:regioninfo 列中移除表格模式。此外，首次啟動后完成的任何刷新都將以新的0.92.0 文件格式（帶有內(nèi)嵌塊（版本2）的 HBase 文件格式）寫入數(shù)據(jù)。這意味著一旦您在 HBase 數(shù)據(jù)目錄中啟動了 HBase 0.92.0，您就無法回到 0.90.x。

MSLAB 默認(rèn)為開啟：

在 0.92.0 中，該 hbase.hregion.memstore.mslab.enabled 標(biāo)志被設(shè)置為 true。在 0.90.x 中是 false。啟用它時，即使內(nèi)存存儲為零或僅包含一些小元素，memstores 也會逐步為 MSLAB 2MB 塊分配內(nèi)存。這通常很好，但是如果您在 0.90.x 群集中每個 RegionServer 有很多區(qū)域（并且 MSLAB 已關(guān)閉），則可能會發(fā)現(xiàn)自己升級時出現(xiàn) OOME，因為 thousands of regions * number of column families * 2MB MSLAB（至少）將堆放在頂部。設(shè)置hbase.hregion.memstore.mslab.enabled 為 false 或?qū)?hbase.hregion.memstore.mslab.chunksize 設(shè)置為小于2MB 的 MSLAB 大小。

分布式日志分割處于默認(rèn)狀態(tài)：

此前，WAL 日志崩潰是由 Master 單獨分割的。在 0.92.0 中，日志分割由群集完成。這應(yīng)該大大減少分割日志和使區(qū)域重新聯(lián)機(jī)所需的時間。

內(nèi)存計算改變：

在 0.92.0 中，包含嵌入塊（版本2）索引和 bloom 過濾器的 HBase 文件格式占用了來自文件系統(tǒng)的相同 LRU 使用的高速緩存塊。在 0.90.x 版本中，HFile v1 指數(shù)位于 LRU 之外，因此即使索引位于沒有被使用的文件中，也會占用空間。利用 LRU 中的索引，你可能會發(fā)現(xiàn)塊緩存的空間較少。相應(yīng)地調(diào)整塊緩存。塊大小的默認(rèn)大小已經(jīng)從0.22.0（堆的20％）改變?yōu)?.25。

可用的 Hadoop 版本：

在 Hadoop 1.0.x（或 CDH3u3）上運行 0.92.0。性能優(yōu)勢值得推動。否則，我們的 Hadoop 處方就像以前一樣；您需要一個支持工作同步的 Hadoop。

如果在 Hadoop 1.0.x（或 CDH3u3）上運行，請啟用本地讀取。

HBase 0.92.0 附帶 ZooKeeper 3.4.2：

如果可以的話，升級你的 ZooKeeper。如果你不能，3.4.2 客戶端應(yīng)該與 3.3.X 集成（HBase 使用 3.4.2 API）進(jìn)行工作。

聯(lián)機(jī)更改默認(rèn)為關(guān)閉狀態(tài)：

在 0.92.0 中，我們添加了一個實驗性在線模式更改設(shè)施。它在默認(rèn)情況下是關(guān)閉的。您自擔(dān)風(fēng)險啟用它。聯(lián)機(jī)修改和分割表格不能很好地協(xié)同工作，所以請確保您的群集靜態(tài)使用此功能（現(xiàn)在）。

WebUI：

網(wǎng)絡(luò)用戶界面（web UI）在 0.92.0 中添加了一些附加功能。它顯示當(dāng)前正在轉(zhuǎn)換的區(qū)域的列表，最近的壓縮/刷新和正在運行的進(jìn)程的進(jìn)程列表（如果一切正常并且請求正在及時處理，通常是空的）。其他添加內(nèi)容包括按區(qū)域請求、調(diào)試 servlet 轉(zhuǎn)儲等。

安全 tarball：

我們現(xiàn)在運送兩個 tarballs：安全和不安全的 HBase。

HBase復(fù)制的變化：

0.92.0 增加了兩個新功能：multi-slave 復(fù)制和 multi-master 復(fù)制。啟用它的方式與添加新的對等方式相同，因此為了擁有 multi-master，您只需運行 add_peer，就可以為每個群集充當(dāng)其他從屬群集的主節(jié)點。沖突是在時間戳級別處理的，這可能是也可能不是您想要的，因此需要在每個用例基礎(chǔ)上對其進(jìn)行評估。復(fù)制在 0.92 仍然是實驗性的，默認(rèn)情況下是禁用的，運行需要您自擔(dān)風(fēng)險。

如果 OOME，RegionServer 現(xiàn)在會中止：

如果一個 OOME，我們現(xiàn)在有 JVM kill RegionServer 進(jìn)程，所以它快速下降。之前，RegionServer 可能會在受傷的狀態(tài)下徘徊一段時間后停滯。要禁用此功能，并建議您將其保留原位，則需要編輯 bin/hbase 文件。

HFile v2 和“更大，更少”的趨勢：

0.92.0 以新格式存儲數(shù)據(jù)，HBase 文件格式包含內(nèi)嵌塊（版本2）。隨著 HBase 的運行，它會將您的所有數(shù)據(jù)從 HFile v1 移至 HFile v2 格式。此自動遷移將在刷新和緊湊排列運行時在后臺運行。HFile v2 允許 HBase 運行更大的區(qū)域/文件。事實上，我們鼓勵所有前進(jìn)的 HBase 都傾向于 Facebook axiom #1，運行時區(qū)域更大，區(qū)域更少。如果你現(xiàn)在有很多區(qū)域 - 每個主機(jī)超過100個 - 你應(yīng)該考慮在你移動到 0.92.0（在 0.92.0，默認(rèn)大小現(xiàn)在是 1G，從 256M 開始）之后設(shè)置你的區(qū)域大小，然后運行在線合并工具。

HBase：從 0.20.x 或 0.89.x 升級到 HBase 0.90.x

此版本的 0.90.x HBase 可以在 HBase 0.20.x 或 HBase 0.89.x 寫入的數(shù)據(jù)上啟動。不需要遷移步驟。HBase 0.89.x 和 0.90.x 以不同的方式地寫出了區(qū)域目錄的名稱，它們用區(qū)域名稱的 md5 哈希來命名，而不是 jenkins 哈希，所以這意味著一旦啟動，就不會返回到 HBase 0.20 。X。

確保在升級時從 conf 目錄中刪除 hbase-default.xml。此文件的 0.20.x 版本將具有用于 0.90.x HBase 的子優(yōu)化配置。在 HBase 的 -default.xml 文件中現(xiàn)在被捆綁到 HBase jar 上進(jìn)行讀取。如果您想查看此文件的內(nèi)容，請在：src/main/resources/hbase-default.xml 的 src 樹中查看它，或者參閱 HBase 默認(rèn)配置。

最后，如果從 0.20.x 升級，請檢查您的 shell 中的 .META 模式。在過去，我們會建議用戶使用 16kb 的 MEMSTORE_FLUSHSIZE，在 shell 中運行：

hbase> scan '-ROOT-'

這將輸出當(dāng)前 .META. 模式。檢查 MEMSTORE_FLUSHSIZE 大小。它是 16kb（16384）嗎？如果是的話，你需要修改它(默認(rèn)的值是 64MB (67108864)) 運行腳本bin/set_meta_memstore_size.rb，這個腳本會修改.META.schema。如果不運行的話，集群會比較慢。