Chapter 3. Upgrading

Table of Contents

3.1. HBase version numbers
3.1.1. Odd/Even Versioning or "Development"" Series Releases
3.1.2. Binary Compatibility
3.1.3. Rolling Upgrades
3.2. Upgrading from 0.98.x to 1.0.x
3.2.1. Changes of Note!
3.2.2. Rolling upgrade from 0.98.x to HBase 1.0.0
3.2.3. Upgrading to 1.0 from 0.94
3.3. Upgrading from 0.96.x to 0.98.x
3.4. Upgrading from 0.94.x to 0.98.x
3.5. Upgrading from 0.94.x to 0.96.x
3.5.1. Executing the 0.96 Upgrade
3.6. Upgrading from 0.92.x to 0.94.x
3.7. Upgrading from 0.90.x to 0.92.x
3.7.1. You can’t go back!
3.7.2. MSLAB is ON by default
3.7.3. Distributed Log Splitting is on by default
3.7.4. Memory accounting is different now
3.7.5. On the Hadoop version to use
3.7.6. HBase 0.92.0 ships with ZooKeeper 3.4.2
3.7.7. Online alter is off by default
3.7.8. WebUI
3.7.9. Security tarball
3.7.10. Changes in HBase replication
3.7.11. RegionServer now aborts if OOME
3.7.12. HFile V2 and the “Bigger, Fewer” Tendency
3.8. Upgrading to HBase 0.90.x from 0.20.x or 0.89.x

You cannot skip major versions upgrading. If you are upgrading from version 0.90.x to 0.94.x, you must first go from 0.90.x to 0.92.x and then go from 0.92.x to 0.94.x.


It may be possible to skip across versions -- for example go from 0.92.2 straight to 0.98.0 just following the 0.96.x upgrade instructions -- but we have not tried it so cannot say whether it works or not.

Review Chapter 2, Apache HBase Configuration, in particular the section on Hadoop version.

3.1. HBase version numbers

HBase has not walked a straight line where version numbers are concerned. Since we came up out of hadoop itself, we originally tracked hadoop versioning. Later we left hadoop versioning behind because we were moving at a different rate to that of our parent. If you are into the arcane, checkout our old wiki page on HBase Versioning which tries to connect the HBase version dots.

3.1.1. Odd/Even Versioning or "Development"" Series Releases

Ahead of big releases, we have been putting up preview versions to start the feedback cycle turning-over earlier. These "Development" Series releases, always odd-numbered, come with no guarantees, not even regards being able to upgrade between two sequential releases (we reserve the right to break compatibility across "Development" Series releases). Needless to say, these releases are not for production deploys. They are a preview of what is coming in the hope that interested parties will take the release for a test drive and flag us early if we there are issues we've missed ahead of our rolling a production-worthy release.

Our first "Development" Series was the 0.89 set that came out ahead of HBase 0.90.0. HBase 0.95 is another "Development" Series that portends HBase 0.96.0.

3.1.2. Binary Compatibility

When we say two HBase versions are compatible, we mean that the versions are wire and binary compatible. Compatible HBase versions means that clients can talk to compatible but differently versioned servers. It means too that you can just swap out the jars of one version and replace them with the jars of another, compatible version and all will just work. Unless otherwise specified, HBase point versions are binary compatible. You can safely do rolling upgrades between binary compatible versions; i.e. across point versions: e.g. from 0.94.5 to 0.94.6. See Does compatibility between versions also mean binary compatibility? discussion on the hbaes dev mailing list.

3.1.3. Rolling Upgrades

A rolling upgrade is the process by which you update the servers in your cluster a server at a time. You can rolling upgrade across HBase versions if they are binary or wire compatible. See <xlnk></xlnk> for more on what this means. Coarsely, a rolling upgrade is a graceful stop each server, update the software, and then restart. You do this for each server in the cluster. Usually you upgrade the Master first and then the regionservers. See <xlink></xlink> for tools that can help use the rolling upgrade process.

For example, in the below, hbase was symlinked to the actual hbase install. On upgrade, before running a rolling restart over the cluser, we changed the symlink to point at the new HBase software version and then ran

$ HADOOP_HOME=~/hadoop-2.6.0-CRC-SNAPSHOT ~/hbase/bin/ --config ~/conf_hbase

The rolling-restart script will first gracefully stop and restart the master, and then each of the regionservers in turn. Because the symlink was changed, on restart the server will come up using the new hbase version. Check logs for errors as the rolling upgrade proceeds. Rolling Upgrade between versions that are Binary/Wire compatibile

Unless otherwise specified, HBase point versions are binary compatible. You can do a <xlink></xlink> between hbase point versions. For example, you can go to 0.94.6 from 0.94.5 by doing a rolling upgrade across the cluster replacing the 0.94.5 binary with a 0.94.6 binary.

In the minor version-particular sections below, we call out where the versions are wire/protocol compatible and in this case, it is also possible to do a <xlink></xlink>. For example, in <xlink></xlink>, we state that it is possible to do a rolling upgrade between hbase-0.98.x and hbase-1.0.0.

comments powered by Disqus