You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hbase.apache.org by st...@apache.org on 2012/11/28 06:34:26 UTC
svn commit: r1414530 - /hbase/trunk/src/docbkx/upgrading.xml
Author: stack
Date: Wed Nov 28 05:34:25 2012
New Revision: 1414530
URL: http://svn.apache.org/viewvc?rev=1414530&view=rev
Log:
Start in doc'ing how to cross the singularity
Modified:
hbase/trunk/src/docbkx/upgrading.xml
Modified: hbase/trunk/src/docbkx/upgrading.xml
URL: http://svn.apache.org/viewvc/hbase/trunk/src/docbkx/upgrading.xml?rev=1414530&r1=1414529&r2=1414530&view=diff
==============================================================================
--- hbase/trunk/src/docbkx/upgrading.xml (original)
+++ hbase/trunk/src/docbkx/upgrading.xml Wed Nov 28 05:34:25 2012
@@ -33,46 +33,22 @@
<para>
Review <xref linkend="configuration" />, in particular the section on Hadoop version.
</para>
- <section xml:id="upgrade0.90">
- <title>Upgrading to HBase 0.90.x from 0.20.x or 0.89.x</title>
- <para>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.
- </para>
- <para>
- Be sure to remove the <filename>hbase-default.xml</filename> from
- your <filename>conf</filename>
- directory on upgrade. A 0.20.x version of this file will have
- sub-optimal configurations for 0.90.x HBase. The
- <filename>hbase-default.xml</filename> file is now bundled into the
- HBase jar and read from there. If you would like to review
- the content of this file, see it in the src tree at
- <filename>src/main/resources/hbase-default.xml</filename> or
- see <xref linkend="hbase_default_configurations" />.
- </para>
- <para>
- Finally, if upgrading from 0.20.x, check your
- <varname>.META.</varname> schema in the shell. In the past we would
- recommend that users run with a 16kb
- <varname>MEMSTORE_FLUSHSIZE</varname>.
- Run <code>hbase> scan '-ROOT-'</code> in the shell. This will output
- the current <varname>.META.</varname> schema. Check
- <varname>MEMSTORE_FLUSHSIZE</varname> size. Is it 16kb (16384)? If so, you will
- need to change this (The 'normal'/default value is 64MB (67108864)).
- Run the script <filename>bin/set_meta_memstore_size.rb</filename>.
- This will make the necessary edit to your <varname>.META.</varname> schema.
- Failure to run this change will make for a slow cluster <footnote>
- <para>
- See <link xlink:href="https://issues.apache.org/jira/browse/HBASE-3499">HBASE-3499 Users upgrading to 0.90.0 need to have their .META. table updated with the right MEMSTORE_SIZE</link>
- </para>
- </footnote>
- .
-
- </para>
- </section>
+ <section xml:id="upgrade0.96">
+ <title>Upgrading from 0.94.x to 0.96.x</title>
+ <subtitle>The Singularity</subtitle>
+ <para>You will have to stop your old 0.94 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
+ so there are no WAL files laying around (TODO: Can 0.96 read 0.94 WAL files?). Make sure
+ zookeeper is cleared of state. All clients must be upgraded to 0.96 too.
+ </para>
+ <para>The API has changed in a few areas; in particular how you use coprocessors (TODO: MapReduce too?)
+ </para>
+ </section>
+ <section xml:id="upgrade0.94">
+ <title>Upgrading from 0.92.x to 0.94.x</title>
+ <para>0.92 and 0.94 are interface compatible. You can do a rolling upgrade between these versions.
+ </para>
+ </section>
<section xml:id="upgrade0.92">
<title>Upgrading from 0.90.x to 0.92.x</title>
<subtitle>Upgrade Guide</subtitle>
@@ -173,7 +149,7 @@ The block size default size has been cha
<section><title>Experimental off-heap cache
</title>
<para>
-A new cache was contributed to 0.92.0 to act as a solution between using the âon-heapâ cache which is the current LRU cache the region servers have and the operating system cache which is out of our control.
+A new cache was contributed to 0.92.0 to act as a solution between using the âon-heapâ cache which is the current LRU cache the region servers have and the operating system cache which is out of our control.
To enable, set â-XX:MaxDirectMemorySizeâ in hbase-env.sh to the value for maximum direct memory size and specify hbase.offheapcache.percentage in hbase-site.xml with the percentage that you want to dedicate to off-heap cache. This should only be set for servers and not for clients. Use at your own risk.
See this blog post for additional information on this new experimental feature: http://www.cloudera.com/blog/2012/01/caching-in-hbase-slabcache/
</para>
@@ -201,4 +177,44 @@ If you have lots of regions now -- more
</para>
</section>
</section>
+ <section xml:id="upgrade0.90">
+ <title>Upgrading to HBase 0.90.x from 0.20.x or 0.89.x</title>
+ <para>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.
+ </para>
+ <para>
+ Be sure to remove the <filename>hbase-default.xml</filename> from
+ your <filename>conf</filename>
+ directory on upgrade. A 0.20.x version of this file will have
+ sub-optimal configurations for 0.90.x HBase. The
+ <filename>hbase-default.xml</filename> file is now bundled into the
+ HBase jar and read from there. If you would like to review
+ the content of this file, see it in the src tree at
+ <filename>src/main/resources/hbase-default.xml</filename> or
+ see <xref linkend="hbase_default_configurations" />.
+ </para>
+ <para>
+ Finally, if upgrading from 0.20.x, check your
+ <varname>.META.</varname> schema in the shell. In the past we would
+ recommend that users run with a 16kb
+ <varname>MEMSTORE_FLUSHSIZE</varname>.
+ Run <code>hbase> scan '-ROOT-'</code> in the shell. This will output
+ the current <varname>.META.</varname> schema. Check
+ <varname>MEMSTORE_FLUSHSIZE</varname> size. Is it 16kb (16384)? If so, you will
+ need to change this (The 'normal'/default value is 64MB (67108864)).
+ Run the script <filename>bin/set_meta_memstore_size.rb</filename>.
+ This will make the necessary edit to your <varname>.META.</varname> schema.
+ Failure to run this change will make for a slow cluster <footnote>
+ <para>
+ See <link xlink:href="https://issues.apache.org/jira/browse/HBASE-3499">HBASE-3499 Users upgrading to 0.90.0 need to have their .META. table updated with the right MEMSTORE_SIZE</link>
+ </para>
+ </footnote>
+ .
+
+ </para>
+ </section>
</chapter>