HBase升級(jí)路徑

HBase升級(jí)路徑

HBase：從 0.98.x 升級(jí)到 1.x

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

HBase 1.0.0+ 重要更改部分：

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

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

  HBase使用的端口已更改。他們?cè)?jīng)是在600XX范圍內(nèi)。在HBase 1.0.0中，它們已經(jīng)從臨時(shí)端口范圍中移出，并且是160XX（主 Web UI 為 60010，現(xiàn)在為16010; RegionServer Web UI 為 60030，現(xiàn)在為16030等）。如果要保留舊的端口位置，請(qǐng)將hbase-default.xml中的端口設(shè)置配置復(fù)制到hbase-site.xml中，將它們更改回 HBase 0.98.x 版本的舊值，并確保在重新啟動(dòng)之前已分發(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，則此更改不會(huì)影響您。它的移除意味著您的 L1 LruBlockCache 現(xiàn)在使用 hfile.block.cache.size 來(lái)調(diào)整大小，即，如果您不在執(zhí)行 BucketCache，您可以調(diào)整堆上 L1 LruBlockCache 的大小 - 并且 BucketCache 大小不適用于該 hbase.bucketcache.size 設(shè)置。您可能需要調(diào)整 configs 以將 LruBlockCache 和 BucketCache 大小設(shè)置為 0.98.x 和之前的大小。如果你沒(méi)有設(shè)置這個(gè)配置，它的默認(rèn)值是 0.9。如果你什么都不做，你的 BucketCache 將會(huì)增加10％。您的 L1 LruBlockCache 將成為 java 堆大小的 hfile.block.cache.size 倍（hfile.block.cache.size 是 0.0 到 1.0 之間的浮點(diǎn)數(shù)）。

HBase：從 0.96.x 升級(jí)到 0.98.x

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

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

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

HBase：從 0.94.x 升級(jí)到 0.98.x

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

HBase：從 0.94.x 升級(jí)到 0.96.x

Singularity

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

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

執(zhí)行 0.96 升級(jí)

在升級(jí)過(guò)程中，HDFS 和 ZooKeeper 必須啟動(dòng)并運(yùn)行！

HBase 0.96.0 附帶升級(jí)腳本，請(qǐng)運(yùn)行：

$ bin/hbase upgrade

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

check

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

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

要運(yùn)行檢查步驟，請(qǐng)運(yùn)行：

$ 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)

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

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

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

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

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

execute

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

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

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

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

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

要運(yùn)行執(zhí)行步驟，請(qǐng)確保首先在服務(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í)行步驟的輸出看起來(lái)不錯(cuò)，請(qǐng)停止開(kāi)始執(zhí)行升級(jí)的zookeeper實(shí)例：

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

然后就可以啟動(dòng) hbase-0.96.0。

故障排除

舊客戶端連接到0.96群集

出現(xiàn)如下的異常，升級(jí)過(guò)程將會(huì)失敗：

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)

升級(jí) META 以使用 Protocol Buffers（Protobuf）

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

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

HBase：從 0.92.x 升級(jí)到 0.94.x

我們?cè)?jīng)認(rèn)為 HBase 的 0.92 版本和 0.94 版本是接口兼容的，您可以在這些版本之間進(jìn)行滾動(dòng)升級(jí)，但是后來(lái)我們發(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)行滾動(dòng)升級(jí)。

HBase：從 0.90.x 升級(jí)到 0.92.x

升級(jí)指南

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

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

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

不可回退：

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

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

在 0.92.0 中，該 hbase.hregion.memstore.mslab.enabled 標(biāo)志被設(shè)置為 true。在 0.90.x 中是 false。啟用它時(shí)，即使內(nèi)存存儲(chǔ)為零或僅包含一些小元素，memstores 也會(huì)逐步為 MSLAB 2MB 塊分配內(nèi)存。這通常很好，但是如果您在 0.90.x 群集中每個(gè) RegionServer 有很多區(qū)域（并且 MSLAB 已關(guān)閉），則可能會(huì)發(fā)現(xiàn)自己升級(jí)時(shí)出現(xiàn) OOME，因?yàn)?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 單獨(dú)分割的。在 0.92.0 中，日志分割由群集完成。這應(yīng)該大大減少分割日志和使區(qū)域重新聯(lián)機(jī)所需的時(shí)間。

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

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

可用的 Hadoop 版本：

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

如果在 Hadoop 1.0.x（或 CDH3u3）上運(yùn)行，請(qǐng)啟用本地讀取。

HBase 0.92.0 附帶 ZooKeeper 3.4.2：

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

WebUI：

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

安全 tarball：

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

HBase復(fù)制的變化：

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

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

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

HFile v2 和“更大，更少”的趨勢(shì)：

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

HBase：從 0.20.x 或 0.89.x 升級(jí)到 HBase 0.90.x

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

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

最后，如果從 0.20.x 升級(jí)，請(qǐng)檢查您的 shell 中的 .META 模式。在過(guò)去，我們會(huì)建議用戶使用 16kb 的 MEMSTORE_FLUSHSIZE，在 shell 中運(yùn)行：

hbase> scan '-ROOT-'

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