Repository: hbase-site Updated Branches: refs/heads/asf-site c0d3a592d -> 92d12755f
http://git-wip-us.apache.org/repos/asf/hbase-site/blob/92d12755/book.html ---------------------------------------------------------------------- diff --git a/book.html b/book.html index 558ecaa..f799af7 100644 --- a/book.html +++ b/book.html @@ -6601,9 +6601,286 @@ Quitting...</code></pre> <h2 id="_upgrade_paths"><a class="anchor" href="#_upgrade_paths"></a>13. Upgrade Paths</h2> <div class="sectionbody"> <div class="sect2"> -<h3 id="upgrade1.4"><a class="anchor" href="#upgrade1.4"></a>13.1. Upgrading to 1.4+</h3> +<h3 id="upgrade2.0"><a class="anchor" href="#upgrade2.0"></a>13.1. Upgrading from 1.x to 2.x</h3> +<div class="paragraph"> +<p>In this section we will first call out significant changes compared to the prior stable HBase release and then go over the upgrade process. Be sure to read the former with care so you avoid suprises.</p> +</div> +<div class="sect3"> +<h4 id="_changes_of_note"><a class="anchor" href="#_changes_of_note"></a>13.1.1. Changes of Note!</h4> +<div class="paragraph"> +<p>First we’ll cover deployment / operational changes that you might hit when upgrading to HBase 2.0+. After that we’ll call out changes for downstream applications. Please note that Coprocessors are covered in the operational section. Also note that this section is not meant to convey information about new features that may be of interest to you. For a complete summary of changes, please see the CHANGES.txt file in the source release artifact for the version you are planning to upgrade to.</p> +</div> +<div id="upgrade2.0.basic.requirements" class="paragraph"> +<div class="title">Update to basic prerequisite minimums in HBase 2.0+</div> +<p>As noted in the section <a id="basic.prerequisites"></a>, HBase 2.0+ requires a minimum of Java 8 and Hadoop 2.6. The HBase community recommends ensuring you have already completed any needed upgrades in prerequisites prior to upgrading your HBase version.</p> +</div> +<div id="upgrade2.0.hbck" class="paragraph"> +<div class="title">HBCK must match HBase server version</div> +<p>You <strong>must not</strong> use an HBase 1.x version of HBCK against an HBase 2.0+ cluster. HBCK is strongly tied to the HBase server version. Using the HBCK tool from an earlier release against an HBase 2.0+ cluster will destructively alter said cluster in unrecoverable ways.</p> +</div> +<div class="paragraph"> +<p>As of HBase 2.0, HBCK is a read-only tool that can report the status of some non-public system internals. You should not rely on the format nor content of these internals to remain consistent across HBase releases.</p> +</div> +<div id="upgrade2.0.removed.configs" class="paragraph"> +<div class="title">Configuration settings no longer in HBase 2.0+</div> +<p>The following configuration settings are no longer applicable or available. For details, please see the detailed release notes.</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>hbase.config.read.zookeeper.config (see <a id="upgrade2.0.zkconfig"></a> for migration details)</p> +</li> +<li> +<p>hbase.zookeeper.useMulti (HBase now always uses ZK’s multi functionality)</p> +</li> +<li> +<p>hbase.rpc.client.threads.max</p> +</li> +<li> +<p>hbase.rpc.client.nativetransport</p> +</li> +<li> +<p>hbase.fs.tmp.dir</p> +</li> +<li> +<p>hbase.bucketcache.combinedcache.enabled</p> +</li> +<li> +<p>hbase.bucketcache.ioengine no longer supports the 'heap' value.</p> +</li> +<li> +<p>hbase.bulkload.staging.dir</p> +</li> +<li> +<p>hbase.balancer.tablesOnMaster wasn’t removed, strictly speaking, but its meaning has fundamentally changed and users should not set it. See the section <a id="upgrade2.0.regions.on.master"></a> for details.</p> +</li> +</ul> +</div> +<div id="upgrade2.0.changed.defaults" class="paragraph"> +<div class="title">Configuration settings with different defaults in HBase 2.0+</div> +<p>The following configuration settings changed their default value. Where applicable, the value to set to restore the behavior of HBase 1.2 is given.</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>hbase.security.authorization now defaults to false. set to true to restore same behavior as previous default.</p> +</li> +<li> +<p>hbase.client.retries.number is now set to 10. Previously it was 35. Downstream users are advised to use client timeouts as described in section <a id="config_timeouts"></a> instead.</p> +</li> +<li> +<p>hbase.client.serverside.retries.multiplier is now set to 3. Previously it was 10. Downstream users are advised to use client timesout as describe in section <a id="config_timeouts"></a> instead.</p> +</li> +<li> +<p>hbase.master.fileSplitTimeout is now set to 10 minutes. Previously it was 30 seconds.</p> +</li> +<li> +<p>hbase.regionserver.logroll.multiplier is now set to 0.5. Previously it was 0.95.</p> +</li> +<li> +<p>hbase.regionserver.hlog.blocksize defaults to 2x the HDFS default block size for the WAL dir. Previously it was equal to the HDFS default block size for the WAL dir.</p> +</li> +<li> +<p>hbase.client.start.log.errors.counter changed to 5. Previously it was 9.</p> +</li> +<li> +<p>hbase.ipc.server.callqueue.type changed to 'fifo'. In HBase versions 1.0 - 1.2 it was 'deadline'. In prior and later 1.x versions it already defaults to 'fifo'.</p> +</li> +<li> +<p>hbase.hregion.memstore.chunkpool.maxsize is 1.0 by default. Previously it was 0.0. Effectively, this means previously we would not use a chunk pool when our memstore is onheap and now we will. See the section <a id="gcpause"></a> for more infromation about the MSLAB chunk pool.</p> +</li> +</ul> +</div> +<div id="upgrade2.0.regions.on.master" class="paragraph"> +<div class="title">"Master hosting regions" feature broken and unsupported</div> +<p>The feature "Master acts as region server" and associated follow-on work available in HBase 1.y is non-functional in HBase 2.y and should not be used in a production setting due to deadlock on Master initialization. Downstream users are advised to treat related configuration settings as experimental and the feature as inappropriate for production settings.</p> +</div> +<div class="paragraph"> +<p>A brief summary of related changes:</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>Master no longer carries regions by default</p> +</li> +<li> +<p>hbase.balancer.tablesOnMaster is a boolean, default false (if it holds an HBase 1.x list of tables, will default to false)</p> +</li> +<li> +<p>hbase.balancer.tablesOnMaster.systemTablesOnly is boolean to keep user tables off master. default false</p> +</li> +<li> +<p>those wishing to replicate old list-of-servers config should deploy a stand-alone RegionServer process and then rely on Region Server Groups</p> +</li> +</ul> +</div> +<div id="upgrade2.0.metrics" class="paragraph"> +<div class="title">Changed metrics</div> +<p>The following metrics have changed names:</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>Metrics previously published under the name "AssignmentManger" [sic] are now published under the name "AssignmentManager"</p> +</li> +</ul> +</div> +<div class="paragraph"> +<p>The following metrics have changed their meaning:</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>The metric 'blockCacheEvictionCount' published on a per-region server basis no longer includes blocks removed from the cache due to the invalidation of the hfiles they are from (e.g. via compaction).</p> +</li> +</ul> +</div> +<div id="upgrade2.0.zkconfig" class="paragraph"> +<div class="title">ZooKeeper configs no longer read from zoo.cfg</div> +<p>HBase no longer optionally reads the 'zoo.cfg' file for ZooKeeper related configuration settings. If you previously relied on the 'hbase.config.read.zookeeper.config' config for this functionality, you should migrate any needed settings to the hbase-site.xml file while adding the prefix 'hbase.zookeeper.property.' to each property name.</p> +</div> +<div id="upgrade2.0.permissions" class="paragraph"> +<div class="title">Changes in permissions</div> +<p>The following permission related changes either altered semantics or defaults:</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>Permissions granted to a user now merge with existing permissions for that user, rather than over-writing them. (see <a href="https://issues.apache.org/jira/browse/HBASE-17472";>the release note on HBASE-17472</a> for details)</p> +</li> +<li> +<p>Region Server Group commands (added in 1.4.0) now require admin privileges.</p> +</li> +</ul> +</div> +<div id="upgrade2.0.admin.commands" class="paragraph"> +<div class="title">Most Admin APIs don’t work against an HBase 2.0+ cluster from pre-HBase 2.0 clients</div> +<p>A number of admin commands are known to not work when used from a pre-HBase 2.0 client. This includes an HBase Shell that has the library jars from pre-HBase 2.0. You will need to plan for an outage of use of admin APIs and commands until you can also update to the needed client version.</p> +</div> +<div class="paragraph"> +<div class="title">Deprecated in 1.0 admin commands have been removed.</div> +<p>The following commands that were deprecated in 1.0 have been removed. Where applicable the replacement command is listed.</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>The 'hlog' command has been removed. Downstream users should rely on the 'wal' command instead.</p> +</li> +</ul> +</div> +<div id="upgrade2.0.memory" class="paragraph"> +<div class="title">Region Server memory consumption changes.</div> +<p>Users upgrading from versions prior to HBase 1.4 should read the instructions in section <a id="upgrade1.4.memory"></a>.</p> +</div> +<div class="paragraph"> +<p>Additionally, HBase 2.0 has changed how memstore memory is tracked for flushing decisions. Previously, both the data size and overhead for storage were used to calculate utilization against the flush threashold. Now, only data size is used to make these per-region decisions. Globally the addition of the storage overhead is used to make decisions about forced flushes.</p> +</div> +<div id="upgrade2.0.ui.splitmerge.by.row" class="paragraph"> +<div class="title">Web UI for splitting and merging operate on row prefixes</div> +<p>Previously, the Web UI included functionality on table status pages to merge or split based on an encoded region name. In HBase 2.0, instead this functionality works by taking a row prefix.</p> +</div> +<div id="upgrade2.0.replication" class="paragraph"> +<div class="title">Special upgrading for Replication users from pre-HBase 1.4</div> +<p>User running versions of HBase prior to the 1.4.0 release that make use of replication should be sure to read the instructions in the section <a id="upgrade1.4.replication"></a>.</p> +</div> +<div id="upgrade2.0.jruby" class="paragraph"> +<div class="title">HBase shell now based on JRuby 9.1.10.0</div> +<p>The bundled JRuby 1.6.8 has been updated to version 9.1.10.0. The represents a change from Ruby 1.8 to Ruby 2.3.3, which introduces non-compatible language changes for user scripts.</p> +</div> +<div id="upgrade2.0.coprocessors" class="paragraph"> +<div class="title">Coprocessor APIs have changed in HBase 2.0+</div> +<p>All Coprocessor APIs have been refactored to improve supportability around binary API compatibility for future versions of HBase. If you or applications you rely on have custom HBase coprocessors, you should read <a href="https://issues.apache.org/jira/browse/HBASE-18169";>the release notes for HBASE-18169</a> for details of changes you will need to make prior to upgrading to HBase 2.0+.</p> +</div> +<div class="paragraph"> +<p>For example, if you had a BaseRegionObserver in HBase 1.2 then at a minimum you will need to update it to implement both RegionObserver and RegionCoprocessor and add the method</p> +</div> +<div class="listingblock"> +<div class="content"> +<pre class="CodeRay highlight"><code data-lang="java">... + <span class="annotation">@Override</span> + <span class="directive">public</span> Optional<RegionObserver> getRegionObserver() { + <span class="keyword">return</span> Optional.of(<span class="local-variable">this</span>); + } +...</code></pre> +</div> +</div> +<div id="upgrade2.0.hfile3.only" class="paragraph"> +<div class="title">HBase 2.0+ can no longer write HFile v2 files.</div> +<p>HBase has simplified our internal HFile handling. As a result, we can no longer write HFile versions earlier than the default of version 3. Upgrading users should ensure that hfile.format.version is not set to 2 in hbase-site.xml before upgrading. Failing to do so will cause Region Server failure. HBase can still read HFiles written in the older version 2 format.</p> +</div> +<div id="upgrade2.0.pb.wal.only" class="paragraph"> +<div class="title">HBase 2.0+ can no longer read Sequence File based WAL file.</div> +<p>HBase can no longer read the deprecated WAL files written in the Apache Hadoop Sequence File format. The hbase.regionserver.hlog.reader.impl and hbase.regionserver.hlog.reader.impl configuration entries should be set to use the Protobuf based WAL reader / writer classes. This implementation has been the default since HBase 0.96, so legacy WAL files should not be a concern for most downstream users.</p> +</div> +<div class="paragraph"> +<p>A clean cluster shutdown should ensure there are no WAL files. If you are unsure of a given WAL file’s format you can use the <code>hbase wal</code> command to parse files while the HBase cluster is offline. In HBase 2.0+, this command will not be able to read a Sequence File based WAL. For more information on the tool see the section <a id="hlog_tool.prettyprint"></a>.</p> +</div> +<div id="upgrade2.0.filters" class="paragraph"> +<div class="title">Change in behavior for filters</div> +<p>The Filter ReturnCode NEXT_ROW has been redefined as skipping to next row in current family, not to next row in all family. itâs more reasonable, because ReturnCode is a concept in store level, not in region level.</p> +</div> +<div id="upgrade2.0.shaded.client.preferred" class="paragraph"> +<div class="title">Downstream HBase 2.0+ users should use the shaded client</div> +<p>Downstream users are strongly urged to rely on the Maven coordinates org.apache.hbase:hbase-shaded-client for their runtime use. This artifact contains all the needed implementation details for talking to an HBase cluster while minimizing the number of third party dependencies exposed.</p> +</div> +<div class="paragraph"> +<p>Note that this artifact exposes some classes in the org.apache.hadoop package space (e.g. o.a.h.configuration.Configuration) so that we can maintain source compatibility with our public API. Those classes are included so that they can be altered to use the same relocated third party dependencies as the rest of the HBase client code. In the event that you need to <strong>also</strong> use Hadoop in your code, you should ensure all Hadoop related jars precede the HBase client jar in your classpath.</p> +</div> +<div id="upgrade2.0.mapreduce.module" class="paragraph"> +<div class="title">Downstream HBase 2.0+ users of MapReduce must switch to new artifact</div> +<p>Downstream users of HBase’s integration for Apache Hadoop MapReduce must switch to relying on the org.apache.hbase:hbase-shaded-mapreduce module for their runtime use. Historically, downstream users relied on either the org.apache.hbase:hbase-server or org.apache.hbase:hbase-shaded-server artifacts for these classes. Both uses are no longer supported and in the vast majority of cases will fail at runtime.</p> +</div> +<div class="paragraph"> +<p>Note that this artifact exposes some classes in the org.apache.hadoop package space (e.g. o.a.h.configuration.Configuration) so that we can maintain source compatibility with our public API. Those classes are included so that they can be altered to use the same relocated third party dependencies as the rest of the HBase client code. In the event that you need to <strong>also</strong> use Hadoop in your code, you should ensure all Hadoop related jars precede the HBase client jar in your classpath.</p> +</div> +<div id="upgrade2.0.dependencies" class="paragraph"> +<div class="title">Significant changes to runtime classpath</div> +<p>A number of internal dependencies for HBase were updated or removed from the runtime classpath. Downstream client users who do not follow the guidance in <a id="upgrade2.0.shaded.client.preferred"></a> will have to examine the set of dependencies Maven pulls in for impact. Downstream users of LimitedPrivate Coprocessor APIs will need to examine the runtime environment for impact. For details on our new handling of third party libraries that have historically been a problem with respect to harmonizing compatible runtime versions, see the reference guide section <a id="thirdparty"></a>.</p> +</div> +<div id="upgrade2.0.public.api" class="paragraph"> +<div class="title">Multiple breaking changes to source and binary compatibility for client API</div> +<p>The Java client API for HBase has a number of changes that break both source and binary compatibility for details see the Compatibility Check Report for the release you’ll be upgrading to.</p> +</div> +</div> <div class="sect3"> -<h4 id="_replication_peer_s_tablecfs_config"><a class="anchor" href="#_replication_peer_s_tablecfs_config"></a>13.1.1. Replication peer’s TableCFs config</h4> +<h4 id="upgrade2.0.rolling.upgrades"><a class="anchor" href="#upgrade2.0.rolling.upgrades"></a>13.1.2. Rolling Upgrade from 1.x to 2.x</h4> +<div class="paragraph"> +<p>There is no rolling upgrade from HBase 1.x+ to HBase 2.x+. In order to perform a zero downtime upgrade, you will need to run an additional cluster in parallel and handle failover in application logic.</p> +</div> +</div> +<div class="sect3"> +<h4 id="upgrade2.0.process"><a class="anchor" href="#upgrade2.0.process"></a>13.1.3. Upgrade process from 1.x to 2.x</h4> +<div class="paragraph"> +<p>To upgrade an existing HBase 1.x cluster, you should:</p> +</div> +<div class="ulist"> +<ul> +<li> +<p>Clean shutdown of existing 1.x cluster</p> +</li> +<li> +<p>Upgrade Master roles first</p> +</li> +<li> +<p>Upgrade RegionServers</p> +</li> +<li> +<p>(Eventually) Upgrade Clients</p> +</li> +</ul> +</div> +</div> +</div> +<div class="sect2"> +<h3 id="upgrade1.4"><a class="anchor" href="#upgrade1.4"></a>13.2. Upgrading from pre-1.4 to 1.4+</h3> +<div class="sect3"> +<h4 id="upgrade1.4.memory"><a class="anchor" href="#upgrade1.4.memory"></a>13.2.1. Region Server memory consumption changes.</h4> +<div class="paragraph"> +<p>Users upgrading from versions prior to HBase 1.4 should be aware that the estimates of heap usage by the memstore objects (KeyValue, object and array header sizes, etc) have been made more accurate for heap sizes up to 32G (using CompressedOops), resulting in them dropping by 10-50% in practice. This also results in less number of flushes and compactions due to "fatter" flushes. YMMV. As a result, the actual heap usage of the memstore before being flushed may increase by up to 100%. If configured memory limits for the region server had been tuned based on observed usage, this change could result in worse GC behavior or even OutOfMemory errors. Set the environment property (not hbase-site.xml) "hbase.memorylayout.use.unsafe" to false to disable.</p> +</div> +</div> +<div class="sect3"> +<h4 id="upgrade1.4.replication"><a class="anchor" href="#upgrade1.4.replication"></a>13.2.2. Replication peer’s TableCFs config</h4> <div class="paragraph"> <p>Before 1.4, the table name can’t include namespace for replication peer’s TableCFs config. It was fixed by add TableCFs to ReplicationPeerConfig which was stored on Zookeeper. So when upgrade to 1.4, you have to update the original ReplicationPeerConfig data on Zookeeper firstly. There are four steps to upgrade when your cluster have a replication peer with TableCFs config.</p> </div> @@ -6643,14 +6920,20 @@ Quitting...</code></pre> </ul> </div> </div> +<div class="sect3"> +<h4 id="upgrade1.4.rawscan"><a class="anchor" href="#upgrade1.4.rawscan"></a>13.2.3. Raw scan now ignores TTL</h4> +<div class="paragraph"> +<p>Doing a raw scan will now return results that have expired according to TTL settings.</p> +</div> +</div> </div> <div class="sect2"> -<h3 id="upgrade1.0"><a class="anchor" href="#upgrade1.0"></a>13.2. Upgrading from 0.98.x to 1.x</h3> +<h3 id="upgrade1.0"><a class="anchor" href="#upgrade1.0"></a>13.3. Upgrading from 0.98.x to 1.x</h3> <div class="paragraph"> <p>In this section we first note the significant changes that come in with 1.0.0+ HBase and then we go over the upgrade process. Be sure to read the significant changes section with care so you avoid surprises.</p> </div> <div class="sect3"> -<h4 id="_changes_of_note"><a class="anchor" href="#_changes_of_note"></a>13.2.1. Changes of Note!</h4> +<h4 id="_changes_of_note_2"><a class="anchor" href="#_changes_of_note_2"></a>13.3.1. Changes of Note!</h4> <div class="paragraph"> <p>In here we list important changes that are in 1.0.0+ since 0.98.x., changes you should be aware that will go into effect once you upgrade.</p> </div> @@ -6692,7 +6975,7 @@ using 0.98.11 servers with any other client version.</p> </div> </div> <div class="sect3"> -<h4 id="upgrade1.0.rolling.upgrade"><a class="anchor" href="#upgrade1.0.rolling.upgrade"></a>13.2.2. Rolling upgrade from 0.98.x to HBase 1.0.0</h4> +<h4 id="upgrade1.0.rolling.upgrade"><a class="anchor" href="#upgrade1.0.rolling.upgrade"></a>13.3.2. Rolling upgrade from 0.98.x to HBase 1.0.0</h4> <div class="admonitionblock note"> <table> <tr> @@ -6711,7 +6994,7 @@ You cannot do a <a href="#hbase.rolling.upgrade">rolling upgrade</a> from 0.96.x </div> </div> <div class="sect3"> -<h4 id="upgrade1.0.scanner.caching"><a class="anchor" href="#upgrade1.0.scanner.caching"></a>13.2.3. Scanner Caching has Changed</h4> +<h4 id="upgrade1.0.scanner.caching"><a class="anchor" href="#upgrade1.0.scanner.caching"></a>13.3.3. Scanner Caching has Changed</h4> <div class="paragraph"> <div class="title">From 0.98.x to 1.x</div> <p>In hbase-1.x, the default Scan caching 'number of rows' changed. @@ -6724,14 +7007,14 @@ for further discussion.</p> </div> </div> <div class="sect3"> -<h4 id="upgrade1.0.from.0.94"><a class="anchor" href="#upgrade1.0.from.0.94"></a>13.2.4. Upgrading to 1.0 from 0.94</h4> +<h4 id="upgrade1.0.from.0.94"><a class="anchor" href="#upgrade1.0.from.0.94"></a>13.3.4. Upgrading to 1.0 from 0.94</h4> <div class="paragraph"> <p>You cannot rolling upgrade from 0.94.x to 1.x.x. You must stop your cluster, install the 1.x.x software, run the migration described at <a href="#executing.the.0.96.upgrade">Executing the 0.96 Upgrade</a> (substituting 1.x.x. wherever we make mention of 0.96.x in the section below), and then restart. Be sure to upgrade your ZooKeeper if it is a version less than the required 3.4.x.</p> </div> </div> </div> <div class="sect2"> -<h3 id="upgrade0.98"><a class="anchor" href="#upgrade0.98"></a>13.3. Upgrading from 0.96.x to 0.98.x</h3> +<h3 id="upgrade0.98"><a class="anchor" href="#upgrade0.98"></a>13.4. Upgrading from 0.96.x to 0.98.x</h3> <div class="paragraph"> <p>A rolling upgrade from 0.96.x to 0.98.x works. The two versions are not binary compatible.</p> </div> @@ -6743,15 +7026,15 @@ for further discussion.</p> </div> </div> <div class="sect2"> -<h3 id="_upgrading_from_0_94_x_to_0_98_x"><a class="anchor" href="#_upgrading_from_0_94_x_to_0_98_x"></a>13.4. Upgrading from 0.94.x to 0.98.x</h3> +<h3 id="_upgrading_from_0_94_x_to_0_98_x"><a class="anchor" href="#_upgrading_from_0_94_x_to_0_98_x"></a>13.5. Upgrading from 0.94.x to 0.98.x</h3> <div class="paragraph"> <p>A rolling upgrade from 0.94.x directly to 0.98.x does not work. The upgrade path follows the same procedures as <a href="#upgrade0.96">Upgrading from 0.94.x to 0.96.x</a>. Additional steps are required to use some of the new features of 0.98.x. See <a href="#upgrade0.98">Upgrading from 0.96.x to 0.98.x</a> for an abbreviated list of these features.</p> </div> </div> <div class="sect2"> -<h3 id="upgrade0.96"><a class="anchor" href="#upgrade0.96"></a>13.5. Upgrading from 0.94.x to 0.96.x</h3> +<h3 id="upgrade0.96"><a class="anchor" href="#upgrade0.96"></a>13.6. Upgrading from 0.94.x to 0.96.x</h3> <div class="sect3"> -<h4 id="_the_singularity"><a class="anchor" href="#_the_singularity"></a>13.5.1. The "Singularity"</h4> +<h4 id="_the_singularity"><a class="anchor" href="#_the_singularity"></a>13.6.1. The "Singularity"</h4> <div class="paragraph"> <p>You will have to stop your old 0.94.x cluster completely to upgrade. If you are replicating between clusters, both clusters will have to go down to upgrade. Make sure it is a clean shutdown. The less WAL files around, the faster the upgrade will run (the upgrade will split any log files it finds in the filesystem as part of the upgrade process). All clients must be upgraded to 0.96 too.</p> </div> @@ -6760,7 +7043,7 @@ for further discussion.</p> </div> </div> <div class="sect3"> -<h4 id="executing.the.0.96.upgrade"><a class="anchor" href="#executing.the.0.96.upgrade"></a>13.5.2. Executing the 0.96 Upgrade</h4> +<h4 id="executing.the.0.96.upgrade"><a class="anchor" href="#executing.the.0.96.upgrade"></a>13.6.2. Executing the 0.96 Upgrade</h4> <div class="admonitionblock note"> <table> <tr> @@ -6925,7 +7208,7 @@ Successfully completed Log splitting</pre> </div> </div> <div class="sect2"> -<h3 id="s096.migration.troubleshooting"><a class="anchor" href="#s096.migration.troubleshooting"></a>13.6. Troubleshooting</h3> +<h3 id="s096.migration.troubleshooting"><a class="anchor" href="#s096.migration.troubleshooting"></a>13.7. Troubleshooting</h3> <div id="s096.migration.troubleshooting.old.client" class="paragraph"> <div class="title">Old Client connecting to 0.96 cluster</div> <p>It will fail with an exception like the below. Upgrade.</p> @@ -6947,7 +7230,7 @@ Successfully completed Log splitting</pre> </div> </div> <div class="sect3"> -<h4 id="_upgrading_code_meta_code_to_use_protocol_buffers_protobuf"><a class="anchor" href="#_upgrading_code_meta_code_to_use_protocol_buffers_protobuf"></a>13.6.1. Upgrading <code>META</code> to use Protocol Buffers (Protobuf)</h4> +<h4 id="_upgrading_code_meta_code_to_use_protocol_buffers_protobuf"><a class="anchor" href="#_upgrading_code_meta_code_to_use_protocol_buffers_protobuf"></a>13.7.1. Upgrading <code>META</code> to use Protocol Buffers (Protobuf)</h4> <div class="paragraph"> <p>When you upgrade from versions prior to 0.96, <code>META</code> needs to be converted to use protocol buffers. This is controlled by the configuration option <code>hbase.MetaMigrationConvertingToPB</code>, which is set to <code>true</code> by default. Therefore, by default, no action is required on your part.</p> </div> @@ -6957,15 +7240,15 @@ Successfully completed Log splitting</pre> </div> </div> <div class="sect2"> -<h3 id="upgrade0.94"><a class="anchor" href="#upgrade0.94"></a>13.7. Upgrading from 0.92.x to 0.94.x</h3> +<h3 id="upgrade0.94"><a class="anchor" href="#upgrade0.94"></a>13.8. Upgrading from 0.92.x to 0.94.x</h3> <div class="paragraph"> <p>We used to think that 0.92 and 0.94 were interface compatible and that you can do a rolling upgrade between these versions but then we figured that <a href="https://issues.apache.org/jira/browse/HBASE-5357";>HBASE-5357 Use builder pattern in HColumnDescriptor</a> changed method signatures so rather than return <code>void</code> they instead return <code>HColumnDescriptor</code>. This will throw <code>java.lang.NoSuchMethodError: org.apache.hadoop.hbase.HColumnDescriptor.setMaxVersions(I)V</code> so 0.92 and 0.94 are NOT compatible. You cannot do a rolling upgrade between them.</p> </div> </div> <div class="sect2"> -<h3 id="upgrade0.92"><a class="anchor" href="#upgrade0.92"></a>13.8. Upgrading from 0.90.x to 0.92.x</h3> +<h3 id="upgrade0.92"><a class="anchor" href="#upgrade0.92"></a>13.9. Upgrading from 0.90.x to 0.92.x</h3> <div class="sect3"> -<h4 id="_upgrade_guide"><a class="anchor" href="#_upgrade_guide"></a>13.8.1. Upgrade Guide</h4> +<h4 id="_upgrade_guide"><a class="anchor" href="#_upgrade_guide"></a>13.9.1. Upgrade Guide</h4> <div class="paragraph"> <p>You will find that 0.92.0 runs a little differently to 0.90.x releases. Here are a few things to watch out for upgrading from 0.90.x to 0.92.0.</p> </div> @@ -7055,7 +7338,7 @@ Successfully completed Log splitting</pre> </div> </div> <div class="sect2"> -<h3 id="upgrade0.90"><a class="anchor" href="#upgrade0.90"></a>13.9. Upgrading to HBase 0.90.x from 0.20.x or 0.89.x</h3> +<h3 id="upgrade0.90"><a class="anchor" href="#upgrade0.90"></a>13.10. Upgrading to HBase 0.90.x from 0.20.x or 0.89.x</h3> <div class="paragraph"> <p>This version of 0.90.x HBase can be started on data written by HBase 0.20.x or HBase 0.89.x. There is no need of a migration step. HBase 0.89.x and 0.90.x does write out the name of region directories differently — it names them with a md5 hash of the region name rather than a jenkins hash — so this means that once started, there is no going back to HBase 0.20.x.</p> </div> @@ -37325,7 +37608,7 @@ The server will return cellblocks compressed using this same compressor as long <div id="footer"> <div id="footer-text"> Version 3.0.0-SNAPSHOT<br> -Last updated 2018-03-24 14:53:18 UTC +Last updated 2018-03-24 19:20:03 UTC </div> </div> </body> http://git-wip-us.apache.org/repos/asf/hbase-site/blob/92d12755/devapidocs/constant-values.html ---------------------------------------------------------------------- diff --git a/devapidocs/constant-values.html b/devapidocs/constant-values.html index 8a3e7f5..630ddc5 100644 --- a/devapidocs/constant-values.html +++ b/devapidocs/constant-values.html @@ -3740,14 +3740,14 @@ <!-- --> </a><code>public static final <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/String.html?is-external=true"; title="class or interface in java.lang">String</a></code></td> <td><code><a href="org/apache/hadoop/hbase/Version.html#date">date</a></code></td> -<td class="colLast"><code>"Sat Mar 24 15:05:23 UTC 2018"</code></td> +<td class="colLast"><code>"Sat Mar 24 19:31:54 UTC 2018"</code></td> </tr> <tr class="rowColor"> <td class="colFirst"><a name="org.apache.hadoop.hbase.Version.revision"> <!-- --> </a><code>public static final <a href="https://docs.oracle.com/javase/8/docs/api/java/lang/String.html?is-external=true"; title="class or interface in java.lang">String</a></code></td> <td><code><a href="org/apache/hadoop/hbase/Version.html#revision">revision</a></code></td> -<td class="colLast"><code>"e468b4022f76688851b3e0c34722f01a56bd624f"</code></td> +<td class="colLast"><code>"ce702df41ba32a466887aee10949bdc963e9c404"</code></td> </tr> <tr class="altColor"> <td class="colFirst"><a name="org.apache.hadoop.hbase.Version.srcChecksum"> http://git-wip-us.apache.org/repos/asf/hbase-site/blob/92d12755/devapidocs/src-html/org/apache/hadoop/hbase/Version.html ---------------------------------------------------------------------- diff --git a/devapidocs/src-html/org/apache/hadoop/hbase/Version.html b/devapidocs/src-html/org/apache/hadoop/hbase/Version.html index 8febec4..12eecfe 100644 --- a/devapidocs/src-html/org/apache/hadoop/hbase/Version.html +++ b/devapidocs/src-html/org/apache/hadoop/hbase/Version.html @@ -16,9 +16,9 @@ <span class="sourceLineNo">008</span>@InterfaceAudience.Private<a name="line.8"></a> <span class="sourceLineNo">009</span>public class Version {<a name="line.9"></a> <span class="sourceLineNo">010</span> public static final String version = "3.0.0-SNAPSHOT";<a name="line.10"></a> -<span class="sourceLineNo">011</span> public static final String revision = "e468b4022f76688851b3e0c34722f01a56bd624f";<a name="line.11"></a> +<span class="sourceLineNo">011</span> public static final String revision = "ce702df41ba32a466887aee10949bdc963e9c404";<a name="line.11"></a> <span class="sourceLineNo">012</span> public static final String user = "jenkins";<a name="line.12"></a> -<span class="sourceLineNo">013</span> public static final String date = "Sat Mar 24 15:05:23 UTC 2018";<a name="line.13"></a> +<span class="sourceLineNo">013</span> public static final String date = "Sat Mar 24 19:31:54 UTC 2018";<a name="line.13"></a> <span class="sourceLineNo">014</span> public static final String url = "git://jenkins-websites1.apache.org/home/jenkins/jenkins-slave/workspace/hbase_generate_website/hbase";<a name="line.14"></a> <span class="sourceLineNo">015</span> public static final String srcChecksum = "4bb21c67df33e6603cf92eaba9fe870f";<a name="line.15"></a> <span class="sourceLineNo">016</span>}<a name="line.16"></a> http://git-wip-us.apache.org/repos/asf/hbase-site/blob/92d12755/index.html ---------------------------------------------------------------------- diff --git a/index.html b/index.html index 0cd121a..994f1b4 100644 --- a/index.html +++ b/index.html @@ -371,6 +371,8 @@ Apache HBase is an open-source, distributed, versioned, non-relational database <div class="section"> <h2><a name="News"></a>News</h2> +<p>June 18th, 2018 <a class="externalLink" href="https://hbase.apache.org/hbasecon-2018";>HBaseCon 2018</a> @ San Jose Convention Center, San Jose, CA, USA</p> + <p>August 4th, 2017 <a class="externalLink" href="https://easychair.org/cfp/HBaseConAsia2017";>HBaseCon Asia 2017</a> @ the Huawei Campus in Shenzhen, China</p> <p>June 12th, 2017 <a class="externalLink" href="https://easychair.org/cfp/hbasecon2017";>HBaseCon2017</a> at the Crittenden Buildings on the Google Mountain View Campus</p>
