[
https://issues.apache.org/jira/browse/HBASE-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596503#comment-14596503
]
Hadoop QA commented on HBASE-13622:
-----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12741074/HBASE-13622.1.patch
against master branch at commit d51a184051d968dc3bdc00b1c9257c0a9e5ff8a6.
ATTACHMENT ID: 12741074
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.1 2.5.2 2.6.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+* Example: File, ZK encoding, directory layout is upgraded automatically
as part of an HBase upgrade. User can downgrade to the older version and
everything will continue to work.
+|File Format Compatibility | N
footnote:[comp_matrix_offline_upgrade_note,Running an offline upgrade tool
without downgrade might be needed. We will typically only support migrating
data from major version X to major version X+1.] | Y |Y
+Sometimes things don't go as planned when attempting an upgrade. This section
explains how to perform a _rollback_ to an earlier HBase release. Note that
this should only be needed between Major and some Minor releases. You should
always be able to _downgrade_ between HBase Patch releases within the same
Minor version. These instructions may require you to take steps before you
start the upgrade process, so be sure to read through this section beforehand.
+This section describes how to perform a _rollback_ on an upgrade between HBase
minor and major versions. In this document, rollback refers to the process of
taking an upgraded cluster and restoring it to the old version _while losing
all changes that have occurred since upgrade_. By contrast, a cluster
_downgrade_ would restore an upgraded cluster to the old version while
maintaining any data written since the upgrade. We currently only offer
instructions to rollback HBase clusters. Further, rollback only works when
these instructions are followed prior to performing the upgrade.
+When these instructions talk about rollback vs downgrade of prerequisite
cluster services (i.e. HDFS), you should treat leaving the service version the
same as a degenerate case of downgrade.
+Unless you are doing an all-service rollback, the HBase cluster will lose any
configured peers for HBase replication. If your cluster is configured for HBase
replication, then prior to following these instructions you should document all
replication peers. After performing the rollback you should then add each
documented peer back to the cluster. For more information on enabling HBase
replication, listing peers, and adding a peer see
<<hbase.replication.management>>. Note also that data written to the cluster
since the upgrade may or may not have already been replicated to any peers.
Determining which, if any, peers have seen replication data as well as rolling
back the data in those peers is out of the scope of this guide.
+Unless you are doing an all-service rollback, going through a rollback
procedure will likely destroy all locality for Region Servers. You should
expect degraded performance until after the cluster has had time to go through
compactions to restore data locality. Optionally, you can force a compaction to
speed this process up at the cost of generating cluster load.
+The instructions below assume default locations for the HBase data directory
and the HBase znode. Both of these locations are configurable and you should
verify the value used in your cluster before proceeding. In the event that you
have a different value, just replace the default with the one found in your
configuration
+* HBase data directory is configured via the key 'hbase.rootdir' and has a
default value of '/hbase'.
+* HBase znode is configured via the key 'zookeeper.znode.parent' and has a
default value of '/hbase'.
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/14504//testReport/
Release Findbugs (version 2.0.3) warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/14504//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/14504//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/14504//console
This message is automatically generated.
> document upgrade rollback
> -------------------------
>
> Key: HBASE-13622
> URL: https://issues.apache.org/jira/browse/HBASE-13622
> Project: HBase
> Issue Type: Improvement
> Components: documentation
> Affects Versions: 0.98.0, 1.0.0, 1.1.0
> Reporter: Sean Busbey
> Assignee: Sean Busbey
> Labels: operability, upgrade
> Fix For: 1.2.0
>
> Attachments: HBASE-13622.1.patch
>
>
> I have some docs on doing a rollback of an hbase upgrade that are currently
> vendor specific. polish them up, make them suitable for HBase generally, and
> add them to the ref guide.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
