在本节中，先前稳定的 HBase 版本相比所发生的重大变化，一定要仔细阅读，然后再进行升级。以免发生意外。
首先，我们将介绍升级到 HBase 2.0+时可能遇到的部署/操作更改。之后，我们将告知下游应用程序的更改。请注意，协处理器包含在操作部分中。另外请注意，本节并不旨在传达您可能感兴趣的新功能的信息。有关更改的完整摘要，请参阅您计划升级到的版本的源发布工件中的 changes.txt 文件。
更新到 HBase 2.0+的基本最低先决条件
如之前章节所述 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 和 Apache HBase Operational Management.
配置设置不再位于 HBase 2.0+
下列配置设置不再适用或不可用。有关详细信息，请参阅详细的发行说明。
hbase.config.read.zookeeper.config (查看 ZooKeeper configs no longer read from zoo.cfg )
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
hbase.master.distributed.log.replay 详见： "Distributed Log Replay" feature broken and removed
hbase.regionserver.disallow.writes.when.recovering 详见： "Distributed Log Replay" feature broken and removed
hbase.regionserver.wal.logreplay.batch.size 详见： "Distributed Log Replay" feature broken and removed
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 所述的客户端超时。
hbase.client.serverside.retries.multiplier 现在默认 3. 之前默认 10.建议下游用户使用 Timeout settings 所述的客户端超时。
hbase.master.fileSplitTimeout 默认 10 分钟，之前是 30 秒
hbase.regionserver.logroll.multiplier 默认 0.5\之前 0.95. 此更改与下面的块大小加倍有关。结合起来，这两个配置更改应该使 WAL 的大小与 HBase-1.x 中的大小大致相同，但是小块的发生率应该更低，因为在达到块大小阈值之前，我们无法滚动 WAL。 详见： 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
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)，它在 hbase 1.2.0 中被有效删除。如果您当前正在使用该功能，请确保执行干净的关机，确保完成所有 DLR 工作，并在升级之前禁用该功能。
prefix-tree 编码移除
前缀树编码已从 hbase 2.0.0 中删除(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
指标变化
以下指标已更改名称：
以下指标改变了其含义：
基于每个区域服务器发布的度量“blockcacheevictioncount”不再包括由于其来自的 hfiles 无效（例如通过压缩）而从缓存中删除的块。
度量'totalRequestCount'每个请求增加一次；以前它是由请求中携带的Actions数量增加的；例如，如果一个请求是由四个 get 和两个 puts 组成的multi，那么我们将“totalrequestcount”增加六次；现在，不管怎样，我们都将增加一次。希望在 HBase-2.0.0 中看到该指标的较低值。
'readRequestCount'现在对返回非空行的读取进行计数，在较旧的 HBase 中，无论结果是否为，我们都会增加“readrequestcount”。如果请求不存在的行，此更改将使读取请求图的配置文件变平。YCSB 读取繁重的工作负载可以根据数据库的加载方式来实现这一点。
已删除以下指标：
添加了以下指标：
更改日志
HBase-2.0.0 现在使用 slf4j 作日志组件.之前是 log4j (1.2). 对于大多数情况，转换应该是无缝的；slf4j 能够很好地解释 log4j.properties 日志配置文件，这样您就不会注意到日志系统的排放量有任何差异。
也就是说, log4j.properties 需要刷新下. 详见例子: 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
区域服务器组命令（在 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 已弃用的管理员命令删除。
在适用的情况下，列出了替换命令。
区域服务器内存消耗更改。
从 HBase 1.4 之前的版本升级的用户应阅读本节中的说明 Region Server memory consumption changes..
此外，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.
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）部分所述。
HBase 2.0+中的协处理器 API 已更改
所有协处理器 API 都经过重构，以提高针对未来 HBase 版本的二进制 API 兼容性的可支持性。如果您或您所依赖的应用程序具有自定义 HBase 协处理器，您应阅读 the release notes for 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）。
过滤器的行为更改
过滤器 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的指导的下游客户端用户将必须检查 Maven 为影响而引入的依赖关系集。 LimitedPrivate Coprocessor API 的下游用户需要检查运行时环境是否有影响。 有关我们对协调兼容运行时版本一直存在问题的第三方库的新处理的详细信息，请参阅参考指南部分The hbase-thirdparty dependency and shading/relocation）。
对客户端 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 , 1.x 中 HBASE-21013 . 还有 HBASE-21008. 性能
在读取和写入路径发生重大变化的情况下，升级到 hbase-2.0.0 时，您可能会看到性能配置文件发生变化。 在发布时，写入可能会更慢，读取相同或更好，取决于上下文。准备好花时间重新调整 (详见: Apache HBase Performance Tuning). 性能也是一个正在积极审查的领域，因此期待在即将发布的版本中进行改进 (详见: HBASE-20188 TESTING Performance).
集成测试和 Kerberos
集成测试（IntegrationTests *）过去依赖于 Kerberos 凭证缓存来对安全集群进行身份验证。 当凭证缓存中的票证过期时，这会导致由于身份验证失败导致测试失败。 从 hbase-2.0.0（和 hbase-1.3.0 +）开始，集成测试客户端将使用配置属性hbase.client.keytab.file和hbase.client.kerberos.principal。 它们是必需的。 客户端将从配置的 keytab 文件执行登录，并在后台自动刷新凭据以获取进程生命周期(详见: HBASE-16231).
协处理器在 2.0 中发生了很大变化，从类层次结构中的顶级设计更改到更改/删除的方法，接口等。 (详见 jira: HBASE-18169 Coprocessor fix and cleanup before 2.0.0 release). 这种种广泛变化的原因是:
传递接口而不是实现; e.g. TableDescriptor 而不是 HTableDescriptor and Region 而不是 HRegion (HBASE-18241 更改 client.Table 和 client.Admin 并非使用 HTableDescriptor).
设计重构让实现者需要填写更少的样板，因此我们可以进行更多的编译时检查 (HBASE-17732)
从协处理器 API 清除协议缓冲区 (HBASE-18859, HBASE-16769, etc)
减少我们向 Coprocessors 公开的内容，删除过于私密而无法公开的内部的钩子(例如: HBASE-18453 CompactionRequest 不应该暴露给用户; HBASE-18298 RegionServerServices 对 CP 公开的接口清理;)
要在 2.0 中使用协处理器，应该针对新 API 重建它们，否则它们将无法加载，HBase 进程将会死亡。
升级协处理器的建议更改顺序：
直接实现观察者接口，而不是扩展 Base * Observer 类。 更改
Foo extends BaseXXXObserver 到 Foo implements XXXObserver. (HBASE-17312).
适应从继承到组合的设计变更 (HBASE-17732) 像 此例.
getTable()已从中删除，协处理器应自行管理 Table 实例。
这里 hbase-example 模块中可以找到使用新 API 编写协处理器的一些示例
最后，如果 api 被更改/删除，会以无法修复的方式打破你，并且如果有充分的理由将其添加回去，请将其通知我们(dev@hbase.apache.org).
滚动升级目前是一项实验性功能。 他们的测试有限。 在我们有限的经历中，有可能发现一些极端情况，所以如果你走这条路，你应该小心。 下一节Upgrade process from 1.x to 2.x中描述的停止/升级/启动是最安全的方式
以下是 1.4 集群滚动升级的提前要求
前提
升级到最新的 1.4.x 版本。 Pre 1.4 版本也可以使用但未经过测试，因此请在升级到 2.x 之前升级到 1.4.3+，除非您是专家并且熟悉区域分配和崩溃处理。 有关如何升级到 1.4.x 的信息，请参见Upgrading from pre-1.4 to 1.4+ 部分。
确保启用了无 zk 赋值，即将hbase.assignment.usezk设置为false。 这是最重要的事情。 它允许 1.x 主服务器为 2.x 区域服务器分配/取消分配区域。 有关如何从基于 zk 的分配迁移到 zk less 赋值，请参阅 HBASE-11059的发行说明部分。
我们测试了从 1.4.3 到 2.1.0 的滚动升级，但如果要升级到 2.0.x，它也应该可以工作。
说明
卸载 region 服务升级到 2.1.0. 从 HBASE-17931 看出，其他系统表的元区域和区域将立即移动到该区域服务器。 如果没有，请手动将它们移动到新的区域服务器。 这非常重要，因为
元区域的模式是硬编码的，如果元在旧的区域服务器上，则新的区域服务器不能访问它，因为它没有一些族，例如，表状态。
较低版本的客户端可以与具有更高版本的服务器通信，但反之亦然。 如果元区域位于旧区域服务器上，则新区域服务器将使用具有较高版本的客户端与具有较低版本的服务器通信，这可能引入奇怪的问题。
滚动升级所有其他区域服务器。
升级 masters.
在滚动升级期间，区域服务器崩溃是可以的。 1.x 主服务器可以为 1.x 和 2.x 区域服务器分配区域，HBASE-19166修复了问题，以便 1.x 区域服务器还可以读取 2.x 区域服务器写入的 WAL 并将其拆分。
在滚动升级之前，请仔细阅读Changes of Note!部分。 确保不使用 2.0 中删除的功能，例如前缀树编码，旧的 hfile 格式等。它们都可能无法升级并使群集处于中间状态并且难以恢复。
如果您成功运行此处方，请通知开发者列表，并附上您的经验说明和/或更新上述内容以及您可能采取的任何偏差，以便其他人走这条路线可以从您的努力中受益。
要升级现有的 HBase 1.x 群集，您应该：
现有 1.x 群集关闭
更新协处理器
首先升级主角色
升级 RegionServers
（最终）升级客户端
从 HBase 1.4 之前的版本升级的用户应该知道，对于最大为 32G 的堆大小（使用 CompressedOops），memstore 对象（KeyValue，对象和数组头大小等）的堆使用估计已经更准确，从而导致 他们在实践中下降了 10-50％。 由于“更胖”的冲洗，这也导致更少的冲洗和压缩。因人而异。 因此，刷新之前 memstore 的实际堆使用量可能会增加最多 100％。 如果已根据观察到的使用情况调整了区域服务器的已配置内存限制，则此更改可能会导致更糟糕的 GC 行为或甚至 OutOfMemory 错误。 将环境属性（不是 hbase-site.xml）“hbase.memorylayout.use.unsafe”设置为 false 以禁用。
在 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.
注意:
现在，执行原始扫描将返回根据 TTL 设置已过期的结果。
如果在 Kerberos 下运行集成测试，请参阅Integration Tests and Kerberos.
有关升级过程的详细信息，请参阅专门针对要升级到的 HBase 版本发布的文档。