Upgrading · HBase? 中文參考指南 3.0

# HBase 升級 > 貢獻者：[xixici](https://github.com/xixici) 當你想要升級時，你不能跳過主要版本。當你從版本 0.98.x 到 2.x 時，你必須首先升級到 1.2.x 再從 1.2.x 升級到 2.x。回顧 [Apache HBase 配置](#configuration)章節，還有 [Hadoop](https://hadoop.apache.org)，并熟悉 [支持和測試](#hbase_supported_tested_definitions). ## 11\. HBase 版本號和兼容性 ### 11.1\. 期望語義版本控制從版本 1.0.0 開始，HBase 采用 [Semantic Versioning](http://semver.org/)作為版本控制。對于給定的版本號 MAJOR.MINOR.PATCH，增加如下內容： MINOR 版本，當您以向后兼容的方式添加功能時 PATCH 版本，當您進行向后兼容的錯誤修復時預發布和構建元數據的其他標簽可作為 MAJOR.MINOR.PATCH 格式的擴展。 * MAJOR 版本，當你進行不兼容的 API 更改時 * MINOR 版本，當您以向后兼容的方式添加功能時 * PATCH 版本，當您進行向后兼容的錯誤修復時 * 預發布和構建元數據的其他標簽可作為 MAJOR.MINOR.PATCH 格式的擴展。兼容性維度除了通常的 API 版本考慮之外，HBase 還有其他需要考慮的兼容性維度。 Client-Server 線協議兼容性： * 允許不同步更新客戶端和服務器。 * 我們只能允許先升級服務器。也就是說，服務器將向后兼容舊客戶端，這樣新的 API 就可以使用。 * 示例：用戶應該能夠使用舊客戶端連接到升級的群集。 Server-Server 協議兼容性： * 不同版本的服務器可以共存于同一個群集中。 * 服務器之間的有線協議是兼容的。 * 分布式任務的工作人員（如復制和日志拆分）可以共存于同一個群集中。 * 相關協議（如使用 ZK 進行協調）也不會改變。 * 示例：用戶可以執行滾動升級。文件格式兼容性： * 支持文件格式向前和向后兼容 * 示例：文件、ZK 編碼、目錄布局自動升級為 HBase 升級的一部分。用戶可以降級到舊版本，并且一切都將繼續工作。客戶端 API 兼容性： * 允許更改或刪除現有的客戶端 API。 * 在我們更改/刪除主要版本之前，API 需要被棄用。 * 修補程序（patch）版本中提供的 API 將在所有后續修補程序版本中提供。但是，可能會添加新的 API，這些 API 在以前的修補程序版本中將不可用。 * 修補程序版本中引入的新 API 只能以源代碼兼容的方式添加：即實現公共 API 的代碼將繼續編譯[[1](#_footnote_1 "View footnote.")]:。示例：使用新廢用的 API 的用戶不需要使用 HBase API 調用修改應用程序代碼，直到下一個主要版本。 * 示例：在下一個主要版本之前，使用新棄用的 API 的用戶不需要修改應用程序的 HBase API 調用代碼。客戶端二進制兼容性： * 寫入給定修補程序版本中提供的 API 的客戶端代碼可以運行不變（不需要重新編譯），以抵補新的 jar 后續補丁版本。 * 寫入給定修補程序版本中提供的 API 的客戶端代碼可能無法針對早期修補程序版本中的舊 jar 運行。示例：舊編譯的客戶端代碼將在 jar 中保持不變。 * 示例：舊編譯的客戶端代碼將在 jar 中保持不變。 * 如果客戶端實現 HBase 接口，則可能需要重新編譯升級到較新的次要（minor）版本。服務器端有限的 API 兼容性（取自 Hadoop）： * 內部 API 被標記為“穩定（Stable）”，“正在發展（Evolving）”或“不穩定（Unstable）”。 * 這意味著協處理器和插件（可插入類，包括復制）的二進制兼容性，只要這些只使用標記的接口/類。 * 例如：舊編譯的協處理器，過濾器或插件代碼將在新 jar 中保持不變。相關性兼容性： * HBase 的升級除 Apache Hadoop 外，不需要依賴項目的兼容升級，包括運行 Java 時。 * HBase 的升級不需要依賴項目的兼容升級，包括 Java 。 * 示例：將 HBase 升級到支持 _ 依賴兼容性 _ 的版本不需要升級 Apache ZooKeeper 服務。 * 示例：示例：如果當前版本的 HBase 支持在 JDK 8 上運行，則升級到支持 _ 依賴兼容性 _ 的版本也將在 JDK 8 上運行。 > Hadoop 版本 > > 之前，我們嘗試維護基礎 Hadoop 服務的依賴兼容性，但在過去幾年中，這已經證明是站不住腳的。雖然 HBase 項目試圖維持對舊版本 Hadoop 的支持，但我們刪除了次要版本的“受支持”指示符。此外，Hadoop 項目有自己的一組兼容性指南，這意味著在某些情況下，會破壞指南，也就是必須更新到較新的受支持的次要版本。操作兼容性： * 度量標準的更改 * 服務的行為變化 * 通過 `/jmx/` 端點公開的 JMX API 概要 * 修補程序（patch）升級是一種直接替代方案。任何不是 Java 二進制和源代碼兼容的更改都將不被允許[[2](#_footnote_2 "View footnote.")]。在修補程序版本中降級版本可能不兼容。 * 次要（minor）升級不需要修改應用程序/客戶端代碼。理想情況下，這將是一個直接替換，但如果使用新的 jar，則客戶端代碼，協處理器，過濾器等可能必須重新編譯。 * 主要（major）升級允許 HBase 做出重大改變。 | | Major | Minor | Patch | | --- | --- | --- | --- | | 客戶端 - 服務器線路兼容性 | N | Y | Y | | 服務器 - 服務器兼容性 | N | Y | Y | | 文件格式兼容性 | N [[4](#_footnote_4 "View footnote.")] | Y | Y | | 客戶端 API 兼容性 | N | Y | Y | | 客戶端二進制兼容性 | N | N | Y | | 服務器端有限的 API 兼容性 | | 穩定性（Stable） | N | Y | Y | | 發展性（Evolving） | N | N | Y | | 不穩定性（Unstable） | N | N | N | | 相關性兼容性 | N | Y | Y | | 操作兼容性 | N | N | Y | #### 11.1.1\. HBase API HBase 有很多 API 要點，但對于上面的兼容性矩陣，我們區分了 Client API（客戶端 API），Limited Private API（有限的私有 API）和 Private API（私有 API）。HBase 使用 [Apache Yetus Audience Annotations](https://yetus.apache.org/documentation/0.5.0/interface-classification/) 來定義穩定性 * InterfaceAudience ([javadocs](https://yetus.apache.org/documentation/0.5.0/audience-annotations-apidocs/org/apache/yetus/audience/InterfaceAudience.html)): 捕捉預期的受眾，可能的值包括： * Public：對于最終用戶和外部項目是安全的； * LimitedPrivate：用于我們期望可插入的內部組件，如協處理器； * Private：嚴格用于 HBase 自身內部定義為 IA 的類中，Private 可以用作聲明 `IA.LimitedPrivate` 接口的參數或返回值。將`IA.Private`對象視為不透明；不要嘗試直接訪問其方法或字段。 * InterfaceStability ([javadocs](https://yetus.apache.org/documentation/0.5.0/audience-annotations-apidocs/org/apache/yetus/audience/InterfaceStability.html)): 描述允許接口更改的類型。可能的值包括： * Stable：接口是固定的，預計不會改變； * Evolving：界面可能會在未來的 minor 版本中改變； * Unstable：界面可能隨時更改請記住 HBase 項目中 `InterfaceAudience` 注釋和 `InterfaceStability` 注釋之間的以下相互作用： * `IA.Public` 類本質上是穩定的，并堅持我們有關升級類型（主要，次要或修補程序）的穩定性保證。 * `IA.LimitedPrivate` 類應始終使用給定的 `InterfaceStability` 值的其中一個進行注釋。如果他們不是，你應該假定他們是 `IS.Unstable`。 * `IA.Private` 類應該被認為是隱含不穩定的，不能保證發布之間的穩定性。 HBase Client API HBase 客戶端 API 由所有標記有 InterfaceAudience.Public 接口的類或方法組成。hbase-client 和依賴模塊中的所有主類都有 InterfaceAudience.Public，InterfaceAudience.LimitedPrivate 或 InterfaceAudience.Private 標記。并非所有其他模塊（hbase-server 等）中的類都有標記。如果一個類沒有使用上述中的一個注釋，則它被認為是一個 InterfaceAudience.Private 類。 HBase LimitedPrivate API LimitedPrivate 注釋為接口附帶了一組目標使用者。這些使用者是協處理器，phoenix，復制端點實現等。此時，HBase 只能保證修補程序版本之間的這些接口的源和二進制兼容性。 HBase Private API 所有使用 InterfaceAudience.Private 注釋的類或沒有注釋的所有類僅在 HBase 內部使用。接口和方法簽名可以隨時改變。如果您依賴于標記為 Private 的特定界面，則應打開 jira 以建議將界面更改為 Public 或 LimitedPrivate，或者為此目的公開的接口。二進制兼容性：當我們說兩個 HBase 版本是兼容的時，我們的意思是這些版本是線（wire）和二進制兼容的。兼容的 HBase 版本意味著客戶可以與兼容但不同版本的服務器通話。這也意味著你可以換出一個版本的 jar，并用另一個兼容版本的 jar 替換它們，所有的 jar 都可以工作。除非另有說明，否則 HBase 主要的版本都是二進制兼容的。您可以安全地在二進制兼容版本之間進行滾動升級。例如從 1.2.4 到 1.2.6\.詳見:[Does compatibility between versions also mean binary compatibility?] 在 HBase 論壇的討論。 ### 11.2\. 滾動升級滾動升級是您一次更新服務器群集中的服務器的過程。如果它們是二進制或線路兼容的，則可以跨 HBase 版本進行滾動升級。詳見：[Rolling Upgrade Between Versions that are Binary/Wire Compatible](#hbase.rolling.restart) 粗略地說，滾動升級是正常地停止每臺服務器，更新軟件，然后重新啟動。您可以為集群中的每個服務器執行此操作。通常先升級 Master，然后再升級 RegionServers。查看 [Rolling Restart](#rolling) 例如，下面的 HBase 是 symlinked 實際的 HBase 安裝。在升級之前，在群集上運行滾動重啟之前，我們將 symlink 更改為指向新的 HBase 軟件版本，然后運行： ``` $ HADOOP_HOME=~/hadoop-2.6.0-CRC-SNAPSHOT ~/hbase/bin/rolling-restart.sh --config ~/conf_hbase ``` 滾動重新啟動腳本將首先正常停止并重新啟動主服務器，然后依次重新啟動每個 RegionServer。由于 symlink 被更改，所以重新啟動時，服務器將使用新的 HBase 版本。隨著滾動升級的進行，檢查日志中是否有錯誤。在兼容二進制/Wire 的版本之間進行滾動升級：除非另有說明，否則 HBase 指向的版本是二進制兼容的。您可以在 HBase 主要版本之間進行[滾動升級](#hbase.rolling.upgrade)。例如，您可以通過在集群中進行滾動升級，使用 0.94.6 二進制文件替換 0.94.5 二進制文件，從而從 0.94.5 轉到 0.94.6。在次要（minor）版本中，我們調用的版本是有線/協議兼容的，在這種情況下，也可以執行[滾動升級](#hbase.rolling.upgrade)。 ## 12\. 版本恢復當你在試著升級 HBase 的時候，你可能會遇到升級失敗的問題，并且想要將其恢復成之前的版本。本節就介紹如何執行 _ 回滾 _ 以將 HBase 恢復為到較早的版本。請注意，這應該只在主要版本和一些次要版本之間需要。您應該始終能夠在相同次要版本的 HBase Patch 版本之間進行 _ 降級 _。這些說明可能要求您在開始升級過程之前注意相關的事項，因此請務必事先閱讀本節。 ### 12.1\. 警告回滾與降級本節介紹如何對 HBase 次要版本和主要版本之間的升級執行回滾。在本文檔中，回滾指的是采取升級后的集群并將其恢復到舊版本的過程，同時 _ 丟失升級后發生的所有更改 _。相比之下，群集降級會將升級后的群集恢復到舊版本，同時保留升級后寫入的任何數據。我們目前僅提供回滾 HBase 集群的說明。此外，只有在執行升級之前遵循這些說明，回滾才有效。當這些指令談論回滾與降級的先決條件群集服務（即 HDFS）時，您應該將服務版本與退化的降級案例視為相同。復制除非您正在執行全部服務回滾，否則 HBase 群集將會丟失任何配置的對等 HBase 復制。如果您的集群配置為 HBase 復制，那么在按照這些說明[Managing and Configuring Cluster Replication](#hbase.replication.management)進行操作之前，您應該記錄所有復制節點。執行回滾之后，您應該將每個記錄的對等點添加回群集。另外要注意，自升級后寫入群集的數據可能已經或可能未被復制到任何對等方。數據位置除非您正在執行全部服務回滾，否則通過回滾過程可能會破壞 Region Server 的所有局部位置。在群集有時間通過緊湊排列恢復數據位置之前，您應該期望性能的降級。或者，您可以強制壓縮來加速此過程，但要以生成群集負載為代價。可配置的位置以下說明假設 HBase 數據目錄和 HBase znode 的默認位置。這兩個位置都是可配置的，您應該在繼續操作之前驗證群集中使用的值。如果您有不同的值，只需將默認值替換為在配置中找到的 HBase 數據目錄，它是通過密鑰 "HBase" (rootdir) 配置的，并且具有默認的 "/HBase"。* HBase znode 通過密鑰'zookeeper.znode.parent'進行配置，默認值為'/ hbase'。 ### 12.2\. 所有服務回滾如果您要執行 HDFS 和 ZooKeeper 服務的回滾，那么 HBase 的數據將在此過程中回滾。要求 * 能夠回滾 HDFS 和 ZooKeeper 升級前在升級前不需要額外的步驟。作為一項額外的預防措施，您可能希望使用 distcp 將 HBase 數據備份到要升級的群集之外。為此，請本節內容中的按照“HDFS 降級后回滾”的“升級前”部分中的步驟操作，但它是復制到另一個 HDFS 實例，而不是在同一實例中。執行回滾 1. 停止 HBase 2. 執行 HDFS 和 ZooKeeper 的回滾（HBase 應該保持停止狀態） 3. 將安裝的 HBase 版本更改為以前的版本 4. 啟動 HBase 5. 驗證 HBase 內容 - 使用 HBase shell 列出表格并掃描一些已知值。 ### 12.3\. HDFS 回滾和 ZooKeeper 降級后回滾如果您將回滾 HDFS，但通過 ZooKeeper 降級，那么 HBase 將處于不一致的狀態。在完成此過程之前，您必須確保集群未啟動。要求 * 能夠回滾 HDFS * 能夠降級 ZooKeeper 升級前在升級前不需要額外的步驟。作為一種額外的預防措施，您可能希望使用 distcp 將 HBase 數據備份到要升級的群集之外。為此，請本節內容中的按照“HDFS 降級后回滾”的“升級前”部分中的步驟操作，但它將復制到另一個 HDFS 實例，而不是在同一實例中。執行回滾 1. 停止 HBase 2. 執行 HDFS 回滾和 ZooKeeper 降級（HBase 應該保持停止狀態） 3. 將安裝的 HBase 版本更改為以前的版本 4. 清除與 HBase 相關的 ZooKeeper 信息。警告：此步驟將永久銷毀所有復制對等點。清理 ZooKeeper 中的 HBase 信息 ``` [hpnewton@gateway_node.example.com ~]$ zookeeper-client -server zookeeper1.example.com:2181,zookeeper2.example.com:2181,zookeeper3.example.com:2181 Welcome to ZooKeeper! JLine support is disabled rmr /hbase quit Quitting... ``` 5. 啟動 HBase 6. 驗證 HBase 內容 - 使用 HBase shell 列出表格并掃描一些已知值。 ### 12.4\. HDFS 降級后回滾如果您要執行 HDFS 降級，則無論 ZooKeeper 是否通過回滾、降級或重新安裝，您都需要遵循這些指示信息。要求 * 可以降級 HDFS * 升級前群集必須能夠運行 MapReduce 作業 * HDFS 超級用戶訪問 * 在 HDFS 中至少有兩個 HBase 數據目錄的副本空間可以降級 HDFS 升級前在開始升級過程之前，您必須對 HBase 的支持數據進行完整備份。以下說明介紹了在當前 HDFS 實例中備份數據的過程。或者，您可以使用 distcp 命令將數據復制到另一個 HDFS 群集。 1. 停止 HBase 群集 2. 將 HBase 數據目錄復制到備份位置, 方法[distcp command](https://hadoop.apache.org/docs/current/hadoop-distcp/DistCp.html)是使用 distcp 命令作為 HDFS 超級用戶 (下面顯示在啟用安全的群集上) 使用 distcp 備份 HBase 數據目錄： ``` [hpnewton@gateway_node.example.com ~]$ kinit -k -t hdfs.keytab hdfs@EXAMPLE.COM [hpnewton@gateway_node.example.com ~]$ hadoop distcp /hbase /hbase-pre-upgrade-backup ``` 3. Distcp 將啟動一個 mapreduce 作業來處理以分布式方式復制文件。檢查 distcp 命令的輸出，以確保此作業成功完成。執行回滾 1. 停止 HBase 2. 執行 HDFS 的降級和 ZooKeeper 的降級/回滾（HBase 應該保持停止狀態） 3. 將安裝的 HBase 版本更改為以前的版本 4. 將 HBase 數據目錄從升級前恢復為 HDFS 超級用戶 (如下所示在啟用安全的群集上)。如果您將數據備份到另一個 HDFS 群集而不是本地，則需要使用 distcp 命令將其復制回當前的 HDFS 群集。恢復 HBase 數據目錄： ``` [hpnewton@gateway_node.example.com ~]$ kinit -k -t hdfs.keytab hdfs@EXAMPLE.COM [hpnewton@gateway_node.example.com ~]$ hdfs dfs -mv /hbase /hbase-upgrade-rollback [hpnewton@gateway_node.example.com ~]$ hdfs dfs -mv /hbase-pre-upgrade-backup /hbase ``` 5. 清除與 HBase 相關的 ZooKeeper 信息。警告：此步驟將永久銷毀所有復制對等點。清理 ZooKeeper 中的 HBase 信息： ``` [hpnewton@gateway_node.example.com ~]$ zookeeper-client -server zookeeper1.example.com:2181,zookeeper2.example.com:2181,zookeeper3.example.com:2181 Welcome to ZooKeeper! JLine support is disabled rmr /hbase quit Quitting... ``` 6. 啟動 HBase 7. 驗證 HBase 內容 - 使用 HBase shell 列出表格并掃描一些已知值。 ## 13\. HBase 升級路徑 ### 13.1\. 從 1.x 升級到 2.x 在本節中，先前穩定的 HBase 版本相比所發生的重大變化，一定要仔細閱讀，然后再進行升級。以免發生意外。 #### 13.1.1\. 變化通告首先，我們將介紹升級到 HBase 2.0+時可能遇到的部署/操作更改。之后，我們將告知下游應用程序的更改。請注意，協處理器包含在操作部分中。另外請注意，本節并不旨在傳達您可能感興趣的新功能的信息。有關更改的完整摘要，請參閱您計劃升級到的版本的源發布工件中的 changes.txt 文件。更新到 HBase 2.0+的基本最低先決條件如之前章節所述 [Basic Prerequisites](#basic.prerequisites), HBase 2.0+ 需要依賴 Java 8 和 Hadoop 2.6\. HBase 社區建議在升級您的 HBase 版本之前，確保您已經完成了任何必要的先決條件升級。 HBCK 一定要匹配 HBase 版本 **一定不要**在 HBase 2.0+ 集群上使用 HBase 1.x 版本的 HBCK。 HBCK 是嚴格綁定 HBase 版本的。對 hbase 2.0+集群使用早期版本的 hbck 工具將以不可恢復的方式破壞性地改變集群。從 HBase 2.0 開始， HBCK (也叫做 _HBCK1_ 或 _hbck1_)是一個只讀工具，可以報告某些非公共系統內部的狀態。您不應該依賴這些內部構件的格式和內容來保持 HBase 版本之間的一致性。替代品詳見： [HBase `HBCK2`](#HBCK2) 和 [Apache HBase Operational Management](#ops_mgt). 配置設置不再位于 HBase 2.0+ 下列配置設置不再適用或不可用。有關詳細信息，請參閱詳細的發行說明。 * hbase.config.read.zookeeper.config (查看 [ZooKeeper configs no longer read from zoo.cfg](#upgrade2.0.zkconfig) ) * hbase.zookeeper.useMulti (HBase 現在使用 ZK’s multi functionality) * hbase.rpc.client.threads.max * hbase.rpc.client.nativetransport * hbase.fs.tmp.dir * hbase.bucketcache.combinedcache.enabled * hbase.bucketcache.ioengine 不再支持 'heap' 值. * hbase.bulkload.staging.dir * hbase.balancer.tablesOnMaster 嚴格地說，它并沒有被刪除，但它的意義已經發生了根本性的改變，用戶不應該設置它。詳見： ["Master hosting regions" feature broken and unsupported](#upgrade2.0.regions.on.master) * hbase.master.distributed.log.replay 詳見： ["Distributed Log Replay" feature broken and removed](#upgrade2.0.distributed.log.replay) * hbase.regionserver.disallow.writes.when.recovering 詳見： ["Distributed Log Replay" feature broken and removed](#upgrade2.0.distributed.log.replay) * hbase.regionserver.wal.logreplay.batch.size 詳見： ["Distributed Log Replay" feature broken and removed](#upgrade2.0.distributed.log.replay) * hbase.master.catalog.timeout * hbase.regionserver.catalog.timeout * hbase.metrics.exposeOperationTimes * hbase.metrics.showTableName * hbase.online.schema.update.enable (HBase 不再支持) * hbase.thrift.htablepool.size.max 在 HBase 2.0+重命名的配置屬性已重命名以下屬性。在運行時設置舊屬性將失敗。 | 舊名稱 | 新名稱 | | --- | --- | | hbase.rpc.server.nativetransport | hbase.netty.nativetransport | | hbase.netty.rpc.server.worker.count | hbase.netty.worker.count | | hbase.hfile.compactions.discharger.interval | hbase.hfile.compaction.discharger.interval | | hbase.hregion.percolumnfamilyflush.size.lower.bound | hbase.hregion.percolumnfamilyflush.size.lower.bound.min | 在 HBase 2.0+中具有不同默認值的配置以下配置設置更改了它們的默認值。在適用的情況下，將給出 hbase 1.2 行為的設置值。 * hbase.security.authorization 默認 false. 之前版本的 default 是 true * hbase.client.retries.number 現在默認 10\. 之前默認 35\.建議下游用戶使用 [Timeout settings](#config_timeouts) 所述的客戶端超時。 * hbase.client.serverside.retries.multiplier 現在默認 3\. 之前默認 10\.建議下游用戶使用 [Timeout settings](#config_timeouts) 所述的客戶端超時。 * hbase.master.fileSplitTimeout 默認 10 分鐘，之前是 30 秒 * hbase.regionserver.logroll.multiplier 默認 0.5\之前 0.95\. 此更改與下面的塊大小加倍有關。結合起來，這兩個配置更改應該使 WAL 的大小與 HBase-1.x 中的大小大致相同，但是小塊的發生率應該更低，因為在達到塊大小閾值之前，我們無法滾動 WAL。詳見： [HBASE-19148](https://issues.apache.org/jira/browse/HBASE-19148) * hbase.regionserver.hlog.blocksize 默認為 wal dir 的 hdfs 默認塊大小的 2 倍。以前它等于 wal dir 的 hdfs 默認塊大小。 * hbase.client.start.log.errors.counter 更改為 5,以前是 9 * hbase.ipc.server.callqueue.type 改為“FIFO”。在 HBase 版本 1.0-1.2 中，這是“最后期限”。在之前和之后的 1.x 版本中，它已經默認為“FIFO”。 * hbase.hregion.memstore.chunkpool.maxsize 默認為 1.0, 之前是 0.0. 實際上，這意味著以前當 memstore onheap 時，我們不會使用區塊池，現在我們將使用。有關 mslab 區塊池的更多信息，請參閱[Long GC pauses](#gcpause) * hbase.master.cleaner.interval 默認為 10 分鐘, 之前是 1 分鐘. * hbase.master.procedure.threads 現在將默認為可用 CPU 數量的 1/4，但不少于 16 個線程。以前，線程數等于 CPU 數。 * hbase.hstore.blockingStoreFiles 現在是 16。以前是 10。 * hbase.http.max.threads 現在是 16。以前是 10。 * hbase.client.max.perserver.tasks 現在是 2。以前是 5 * hbase.normalizer.period 現在是 5 分鐘。以前是 30 分鐘. * hbase.regionserver.region.split.policy 現在是步進式分割策略。以前，它增加邊界區域策略。 * replication.source.ratio 現在是 0.5。以前是 0.1. “主托管區域”功能已損壞且不受支持 hbase 1.y 中的“master 充當區域服務器”功能和相關后續工作在 hbase 2.y 中不起作用，不應在生產設置中使用，因為 master 初始化時出現死鎖。建議下游用戶將相關的配置設置視為實驗性的，并將該功能視為不適合生產設置。相關變更的簡要概述： * 默認情況下，Master 不再承載區域 * hbase.balancer.tablesonmaster 是一個布爾值，默認為 false（如果它包含 hbase 1.x 表列表，則默認為 false） * hbase.balancer.tablesonmaster.systemtablesonly 是保持用戶表遠離 master 的布爾值。缺省假 * 那些希望復制舊服務器列表配置的人應該部署一個獨立的區域服務器進程，然后依賴于區域服務器組。 “分布式日志回放”功能已中斷并已刪除分布式日志重播功能已損壞，已從 hbase 2.y+中刪除。因此，所有相關的配置、度量、RPC 字段和日志記錄都已被刪除。請注意，在運行到 hbase 1.0 時發現此功能不可靠，默認為未使用，當我們開始忽略打開該功能的配置時 ([HBASE-14465](https://issues.apache.org/jira/browse/HBASE-14465))，它在 hbase 1.2.0 中被有效刪除。如果您當前正在使用該功能，請確保執行干凈的關機，確保完成所有 DLR 工作，并在升級之前禁用該功能。 _prefix-tree_ 編碼移除前綴樹編碼已從 hbase 2.0.0 中刪除([HBASE-19179](https://issues.apache.org/jira/browse/HBASE-19179))。在 HBase-1.2.7、HBase-1.4.0 和 HBase-1.3.2 中已棄用。此功能被刪除，因為它未被積極維護。如果有興趣恢復這種可以在慢寫代價高昂的情況下改善隨機讀取延遲的功能，可以在 _dev at hbase dot apache dot org_ 上寫下 hbase 開發者列表。升級到 HBase 2.0+之前，需要從所有表中刪除前綴樹編碼。要首先執行此操作，您需要將編碼從前綴樹更改為 HBase 2.0 中支持的其他內容。之后，您必須主要壓縮以前使用前綴樹編碼的表。要檢查哪些列族使用的數據塊編碼不兼容，可以使用[Pre-Upgrade Validator](#ops.pre-upgrade) 指標變化以下指標已更改名稱： * 以前以"AssignmentManger" [sic]名稱發布的度量現在"AssignmentManager"名稱發布。以下指標改變了其含義： * 基于每個區域服務器發布的度量“blockcacheevictioncount”不再包括由于其來自的 hfiles 無效（例如通過壓縮）而從緩存中刪除的塊。 * 度量'totalRequestCount'每個請求增加一次；以前它是由請求中攜帶的`Actions`數量增加的；例如，如果一個請求是由四個 get 和兩個 puts 組成的`multi`，那么我們將“totalrequestcount”增加六次；現在，不管怎樣，我們都將增加一次。希望在 HBase-2.0.0 中看到該指標的較低值。 * 'readRequestCount'現在對返回非空行的讀取進行計數，在較舊的 HBase 中，無論結果是否為，我們都會增加“readrequestcount”。如果請求不存在的行，此更改將使讀取請求圖的配置文件變平。YCSB 讀取繁重的工作負載可以根據數據庫的加載方式來實現這一點。已刪除以下指標： * 與分布式日志重播功能相關的度量不再存在。以前在區域服務器上下文中的名稱“replay”下找到了它們。有關詳細信息，請參閱 ["Distributed Log Replay" feature broken and removed](#upgrade2.0.distributed.log.replay) 添加了以下指標： * 'totalRowActionRequestCount'是匯總讀和寫的區域行操作的計數。更改日志 HBase-2.0.0 現在使用 [slf4j](https://www.slf4j.org/) 作日志組件.之前是 [log4j (1.2)](http://logging.apache.org/log4j/1.2/). 對于大多數情況，轉換應該是無縫的；slf4j 能夠很好地解釋 _log4j.properties_ 日志配置文件，這樣您就不會注意到日志系統的排放量有任何差異。也就是說, _log4j.properties_ 需要刷新下. 詳見例子: [HBASE-20351](https://issues.apache.org/jira/browse/HBASE-20351)在每次 shell 命令調用時，一個過時的日志配置文件都顯示為 netty 配置，并在 debug 級別轉儲為前導碼。 zookeeper 配置不再從 zoo.cfg 中讀取 HBase 不再選擇讀取與 ZooKeeper 相關的配置設置的“zoo.cfg”文件。如果您以前依賴“hbase.config.read.zookeeper.config”配置來實現此功能，則應在向每個屬性名添加前綴“hbase.zookeeper.property.”的同時，將任何需要的設置遷移到 hbase-site.xml 文件。權限更改以下與權限相關的更改要么更改了語義，要么更改了默認值： * 授予用戶的權限現在與該用戶的現有權限合并，而不是重寫它們。詳見: [the release note on HBASE-17472](https://issues.apache.org/jira/browse/HBASE-17472) * 區域服務器組命令（在 1.4.0 中添加）現在需要管理員權限。大多數管理 API 不適用于來自 HBase 2.0 之前的客戶機的 HBase 2.0+群集。從 HBase 2.0 之前的客戶機使用時，許多管理命令都不起作用。這包括一個 hbase shell，該 shell 具有來自 hbase 2.0 之前版本的庫 jar。在您還可以更新到所需的客戶端版本之前，您需要計劃管理 API 和命令的使用中斷。當從 HBase 2.0 之前的客戶機執行時，以下客戶機操作不適用于 HBase 2.0+群集： * list_procedures * split * merge_region * list_quotas * enable_table_replication * disable_table_replication * Snapshot related commands 1.0 已棄用的管理員命令刪除。在適用的情況下，列出了替換命令。 * 'hlog'命令已被刪除。下游用戶應該依賴'wal'命令。區域服務器內存消耗更改。從 HBase 1.4 之前的版本升級的用戶應閱讀本節中的說明 [Region Server memory consumption changes.](#upgrade1.4.memory). 此外，HBase 2.0 改變了如何跟蹤 memstore 內存以進行刷新決策。以前，數據大小和存儲開銷都用于計算沖洗 threashold 的利用率。現在，只使用數據大小來做出每個區域的決策。在全球范圍內，添加存儲開銷用于做出有關強制刷新的決策。用于拆分和合并的 Web UI 對行前綴進行操作以前，Web UI 包含表狀態頁面上的功能，以根據編碼的區域名稱進行合并或拆分。在 HBase 2.0 中，此功能通過采用行前綴來工作。從 HBase 1.4 之前對 Replication 用戶進行特殊升級用戶在 1.4.0 版本之前運行 HBase 版本并使用復制時，請務必閱讀本節中的說明[Replication peer’s TableCFs config](#upgrade1.4.replication). HBase shell 變化 HBase shell 命令依賴于捆綁的 JRuby 實例。捆綁的 JRuby 已從 1.6.8 版更新到 9.1.10.0 版。它表示從 Ruby 1.8 到 Ruby 2.3.3 的更改，它為用戶腳本引入了不兼容的語言更改。 HBase shell 命令現在忽略早期 HBase 1.4 版本中存在的'--return-values'標志。相反，shell 總是表現得像傳遞了那個標志。如果您希望避免在控制臺中打印表達式結果，則應更改 IRB 配置，如[_irbrc_](#irbrc)）部分所述。 HBase 2.0+中的協處理器 API 已更改所有協處理器 API 都經過重構，以提高針對未來 HBase 版本的二進制 API 兼容性的可支持性。如果您或您所依賴的應用程序具有自定義 HBase 協處理器，您應閱讀 [the release notes for HBASE-18169](https://issues.apache.org/jira/browse/HBASE-18169) ，了解您將需要的更改的詳細信息在升級到 HBase 2.0+之前制作。例如，如果你在 HBase 1.2 中有一個 BaseRegionObserver，那么至少你需要更新它以實現 RegionObserver 和 RegionCoprocessor 并添加方法 ``` ... @Override public Optional<RegionObserver> getRegionObserver() { return Optional.of(this); } ... ``` HBase 2.0+無法再寫入 HFile v2 文件。 HBase 簡化了我們內部的 HFile 處理。因此，我們再也無法在版本 3 \的默認版本之前編寫 HFile 版本。升級用戶應確保在升級之前 hbase-site.xml 中的 hfile.format.version 未設置為 2。如果不這樣做將導致 Region Server 失敗。 HBase 仍然可以讀取以舊版本 2 格式編寫的 HFile。 HBase 2.0+無法再讀取基于序列文件的 WAL 文件。 HBase 無法再讀取以 Apache Hadoop 序列文件格式編寫的已棄用的 WAL 文件。應將 hbase.regionserver.hlog.reader.impl 和 hbase.regionserver.hlog.reader.impl 配置條目設置為使用基于 Protobuf 的 WAL 讀取器/寫入器類。此實現是 HBase 0.96 以來的默認實現，因此傳統 WAL 文件不應成為大多數下游用戶關注的問題。干凈的群集關閉應確保沒有 WAL 文件。如果您不確定給定的 WAL 文件格式，可以使用`hbase wal`命令在 HBase 集群脫機時解析文件。在 HBase 2.0+中，此命令將無法讀取基于 WAL 的序列文件。有關該工具的更多信息，請參閱[WALPrettyPrinter](#hlog_tool.prettyprint)）。過濾器的行為更改過濾器 ReturnCode NEXT_ROW 已重新定義為跳過當前系列中的下一行，而不是跳到所有系列中的下一行。它更合理，因為 ReturnCode 是商店級別的概念，而不是區域級別。下游 HBase 2.0+用戶應該使用著色客戶端強烈建議下游用戶依賴 Maven 坐標 org.apache.hbase：hbase-shaded-client 來運行它們。此工件包含與 HBase 集群通信所需的所有實現詳細信息，同時最大限度地減少暴露的第三方依賴項的數量。請注意，此工件公開 org.apache.hadoop 包空間中的某些類（例如 o.a.h.configuration.Configuration），以便我們可以保持與我們的公共 API 的源兼容性。包含這些類，以便可以將它們更改為使用與 HBase 客戶端代碼的其余部分相同的重定位第三方依賴項。如果您還需要**在代碼中使用 Hadoop，則應確保所有與 Hadoop 相關的 jar 都位于類路徑中的 HBase 客戶端 jar 之前。運行時類路徑的重大更改 HBase 的許多內部依賴項已從運行時類路徑中更新或刪除。不遵循[Downstream HBase 2.0+ users should use the shaded client](#upgrade2.0.shaded.client.preferred)的指導的下游客戶端用戶將必須檢查 Maven 為影響而引入的依賴關系集。 LimitedPrivate Coprocessor API 的下游用戶需要檢查運行時環境是否有影響。有關我們對協調兼容運行時版本一直存在問題的第三方庫的新處理的詳細信息，請參閱參考指南部分[The hbase-thirdparty dependency and shading/relocation](#thirdparty)）。對客戶端 API 的源和二進制兼容性進行多次重大更改 HBase 的 Java 客戶端 API 有許多更改可以破壞源和二進制兼容性的詳細信息，請參閱要升級到的版本的兼容性檢查報告。跟蹤實施變化 HBase 跟蹤功能的支持實現已從 Apache HTrace 3 更新為 HTrace 4，其中包括幾個重大更改。雖然 HTrace 3 和 4 可以在同一運行時共存，但它們不會相互集成，從而導致不相交的跟蹤信息。此升級期間 HBase 的內部更改足以進行編譯，但尚未確認跟蹤功能中沒有回歸。請考慮此功能在不久的將來會過期。如果您以前依賴與 HBase 操作集成的客戶端跟蹤，則建議您將使用情況升級到 HTrace 4。 HFile 不再向前兼容由 2.0.0, 2.0.1, 2.1.0 生成的 HFile 與 1.4.6-, 1.3.2.1-, 1.2.6.1-和其他非活動版本不向前兼容。為什么 HFile 失去兼容性是新版本(2.0.0, 2.0.1, 2.1.0)中的 hbase 使用 protobuf 序列化/反序列化 TimeRangeTracker（TRT），而舊版本使用 DataInput / DataOutput。為解決這個問題,詳見: 2.x 中 [HBASE-21012](https://jira.apache.org/jira/browse/HBASE-21012) , 1.x 中 [HBASE-21013](https://jira.apache.org/jira/browse/HBASE-21013) . 還有 [HBASE-21008](https://jira.apache.org/jira/browse/HBASE-21008). 性能在讀取和寫入路徑發生重大變化的情況下，升級到 hbase-2.0.0 時，您可能會看到性能配置文件發生變化。在發布時，寫入可能會更慢，讀取相同或更好，取決于上下文。準備好花時間重新調整 (詳見: [Apache HBase Performance Tuning](#performance)). 性能也是一個正在積極審查的領域，因此期待在即將發布的版本中進行改進 (詳見: [HBASE-20188 TESTING Performance](https://issues.apache.org/jira/browse/HBASE-20188)). 集成測試和 Kerberos 集成測試（`IntegrationTests *`）過去依賴于 Kerberos 憑證緩存來對安全集群進行身份驗證。當憑證緩存中的票證過期時，這會導致由于身份驗證失敗導致測試失敗。從 hbase-2.0.0（和 hbase-1.3.0 +）開始，集成測試客戶端將使用配置屬性`hbase.client.keytab.file`和`hbase.client.kerberos.principal`。它們是必需的。客戶端將從配置的 keytab 文件執行登錄，并在后臺自動刷新憑據以獲取進程生命周期(詳見: [HBASE-16231](https://issues.apache.org/jira/browse/HBASE-16231)). #### 13.1.2\. 將協處理器升級到 2.0 協處理器在 2.0 中發生了很大變化，從類層次結構中的頂級設計更改到更改/刪除的方法，接口等。 (詳見 jira: [HBASE-18169 Coprocessor fix and cleanup before 2.0.0 release](https://issues.apache.org/jira/browse/HBASE-18169)). 這種種廣泛變化的原因是: 1. 傳遞接口而不是實現; e.g. TableDescriptor 而不是 HTableDescriptor and Region 而不是 HRegion ([HBASE-18241](https://issues.apache.org/jira/browse/HBASE-18241) 更改 client.Table 和 client.Admin 并非使用 HTableDescriptor). 2. 設計重構讓實現者需要填寫更少的樣板，因此我們可以進行更多的編譯時檢查 ([HBASE-17732](https://issues.apache.org/jira/browse/HBASE-17732)) 3. 從協處理器 API 清除協議緩沖區 ([HBASE-18859](https://issues.apache.org/jira/browse/HBASE-18859), [HBASE-16769](https://issues.apache.org/jira/browse/HBASE-16769), etc) 4. 減少我們向 Coprocessors 公開的內容，刪除過于私密而無法公開的內部的鉤子(例如: [HBASE-18453](https://issues.apache.org/jira/browse/HBASE-18453) CompactionRequest 不應該暴露給用戶; [HBASE-18298](https://issues.apache.org/jira/browse/HBASE-18298) RegionServerServices 對 CP 公開的接口清理;) 要在 2.0 中使用協處理器，應該針對新 API 重建它們，否則它們將無法加載，HBase 進程將會死亡。升級協處理器的建議更改順序： 1. 直接實現觀察者接口，而不是擴展 Base * Observer 類。更改 `Foo extends BaseXXXObserver` 到 `Foo implements XXXObserver`. ([HBASE-17312](https://issues.apache.org/jira/browse/HBASE-17312)). 2. 適應從繼承到組合的設計變更 ([HBASE-17732](https://issues.apache.org/jira/browse/HBASE-17732)) 像 [此例](https://github.com/apache/hbase/blob/master/dev-support/design-docs/Coprocessor_Design_Improvements-Use_composition_instead_of_inheritance-HBASE-17732.adoc#migrating-existing-cps-to-new-design). 3. getTable()已從中刪除，協處理器應自行管理 Table 實例。 [這里 hbase-example 模塊](https://github.com/apache/hbase/tree/branch-2.0/hbase-examples/src/main/java/org/apache/hadoop/hbase/coprocessor/example)中可以找到使用新 API 編寫協處理器的一些示例最后，如果 api 被更改/刪除，會以無法修復的方式打破你，并且如果有充分的理由將其添加回去，請將其通知我們([dev@hbase.apache.org](mailto:dev@hbase.apache.org)). #### 13.1.3\. 從 1.x 到 2.x 的滾動升級滾動升級目前是一項實驗性功能。他們的測試有限。在我們有限的經歷中，有可能發現一些極端情況，所以如果你走這條路，你應該小心。下一節[Upgrade process from 1.x to 2.x](#upgrade2.0.process)中描述的停止/升級/啟動是最安全的方式以下是 1.4 集群滾動升級的提前要求前提 * 升級到最新的 1.4.x 版本。 Pre 1.4 版本也可以使用但未經過測試，因此請在升級到 2.x 之前升級到 1.4.3+，除非您是專家并且熟悉區域分配和崩潰處理。有關如何升級到 1.4.x 的信息，請參見[Upgrading from pre-1.4 to 1.4+](#upgrade1.4) 部分。 * 確保啟用了無 zk 賦值，即將`hbase.assignment.usezk`設置為`false`。這是最重要的事情。它允許 1.x 主服務器為 2.x 區域服務器分配/取消分配區域。有關如何從基于 zk 的分配遷移到 zk less 賦值，請參閱 [HBASE-11059](https://issues.apache.org/jira/browse/HBASE-11059)的發行說明部分。 * 我們測試了從 1.4.3 到 2.1.0 的滾動升級，但如果要升級到 2.0.x，它也應該可以工作。說明 1. 卸載 region 服務升級到 2.1.0\. 從 [HBASE-17931](https://issues.apache.org/jira/browse/HBASE-17931) 看出，其他系統表的元區域和區域將立即移動到該區域服務器。如果沒有，請手動將它們移動到新的區域服務器。這非常重要，因為 * 元區域的模式是硬編碼的，如果元在舊的區域服務器上，則新的區域服務器不能訪問它，因為它沒有一些族，例如，表狀態。 * 較低版本的客戶端可以與具有更高版本的服務器通信，但反之亦然。如果元區域位于舊區域服務器上，則新區域服務器將使用具有較高版本的客戶端與具有較低版本的服務器通信，這可能引入奇怪的問題。 2. 滾動升級所有其他區域服務器。 3. 升級 masters. 在滾動升級期間，區域服務器崩潰是可以的。 1.x 主服務器可以為 1.x 和 2.x 區域服務器分配區域，[HBASE-19166](https://issues.apache.org/jira/browse/HBASE-19166)修復了問題，以便 1.x 區域服務器還可以讀取 2.x 區域服務器寫入的 WAL 并將其拆分。 > 在滾動升級之前，請仔細閱讀[Changes of Note!](#_changes_of_note)部分。確保不使用 2.0 中刪除的功能，例如前綴樹編碼，舊的 hfile 格式等。它們都可能無法升級并使群集處于中間狀態并且難以恢復。 > 如果您成功運行此處方，請通知開發者列表，并附上您的經驗說明和/或更新上述內容以及您可能采取的任何偏差，以便其他人走這條路線可以從您的努力中受益。 #### 13.1.4\. 從 1.x 升級到 2.x 的升級過程要升級現有的 HBase 1.x 群集，您應該： * 現有 1.x 群集關閉 * 更新協處理器 * 首先升級主角色 * 升級 RegionServers * （最終）升級客戶端 ### 13.2\. Upgrading from pre-1.4 to 1.4+ #### 13.2.1\. Region Server memory consumption changes. 從 HBase 1.4 之前的版本升級的用戶應該知道，對于最大為 32G 的堆大小（使用 CompressedOops），memstore 對象（KeyValue，對象和數組頭大小等）的堆使用估計已經更準確，從而導致他們在實踐中下降了 10-50％。由于“更胖”的沖洗，這也導致更少的沖洗和壓縮。因人而異。因此，刷新之前 memstore 的實際堆使用量可能會增加最多 100％。如果已根據觀察到的使用情況調整了區域服務器的已配置內存限制，則此更改可能會導致更糟糕的 GC 行為或甚至 OutOfMemory 錯誤。將環境屬性（不是 hbase-site.xml）“hbase.memorylayout.use.unsafe”設置為 false 以禁用。 #### 13.2.2\. Replication peer’s TableCFs 設置在 1.4 之前，表名不能包含復制對等體的 TableCFs 配置的名稱空間。通過將 TableCF 添加到存儲在 Zookeeper 上的 ReplicationPeerConfig 來修復它。因此，當升級到 1.4 時，您必須首先更新 Zookeeper 上的原始 ReplicationPeerConfig 數據。當您的群集具有具有 TableCFs 配置的復制對等方時，有四個步驟可以升級。 * 禁用 replication peer. * 如果 master 有權寫入復制對等 znode，則直接滾動更新 master。如果沒有，請使用 TableCFsUpdater 工具更新復制對等方的配置。 ``` $ bin/hbase org.apache.hadoop.hbase.replication.master.TableCFsUpdater update ``` * 滾動升級 regionservers. * 開啟 replication peer. 注意: * 無法使用舊客戶端（1.4 之前）更改復制對等方的配置。由于客戶端將直接向 Zookeeper 寫入配置，因此舊客戶端將錯過 TableCFs 配置。并且舊客戶端將 TableCFs 配置寫入舊的 tablecfs znode，它不適用于新版本的 regionserver。 #### 13.2.3\. 原始數據掃描忽略 TTL 現在，執行原始掃描將返回根據 TTL 設置已過期的結果。 ### 13.3\. 從 1.3 之前升級到 1.3+ 如果在 Kerberos 下運行集成測試，請參閱[Integration Tests and Kerberos](#upgrade2.0.it.kerberos). ### 13.4\. 升級到 1.x 有關升級過程的詳細信息，請參閱專門針對要升級到的 HBase 版本發布的文檔。