Start in doc'ing how to cross the singularity
git-svn-id: https://svn.apache.org/repos/asf/hbase/trunk@1414530 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Michael Stack
parent
7dc169f6d3
commit
54a761ed2d
|
|
@ -33,46 +33,22 @@
|
||||||
<para>
|
<para>
|
||||||
Review <xref linkend="configuration" />, in particular the section on Hadoop version.
|
Review <xref linkend="configuration" />, in particular the section on Hadoop version.
|
||||||
</para>
|
</para>
|
||||||
<section xml:id="upgrade0.90">
|
<section xml:id="upgrade0.96">
|
||||||
<title>Upgrading to HBase 0.90.x from 0.20.x or 0.89.x</title>
|
<title>Upgrading from 0.94.x to 0.96.x</title>
|
||||||
<para>This version of 0.90.x HBase can be started on data written by
|
<subtitle>The Singularity</subtitle>
|
||||||
HBase 0.20.x or HBase 0.89.x. There is no need of a migration step.
|
<para>You will have to stop your old 0.94 cluster completely to upgrade. If you are replicating
|
||||||
HBase 0.89.x and 0.90.x does write out the name of region directories
|
between clusters, both clusters will have to go down to upgrade. Make sure it is a clean shutdown
|
||||||
differently -- it names them with a md5 hash of the region name rather
|
so there are no WAL files laying around (TODO: Can 0.96 read 0.94 WAL files?). Make sure
|
||||||
than a jenkins hash -- so this means that once started, there is no
|
zookeeper is cleared of state. All clients must be upgraded to 0.96 too.
|
||||||
going back to HBase 0.20.x.
|
</para>
|
||||||
</para>
|
<para>The API has changed in a few areas; in particular how you use coprocessors (TODO: MapReduce too?)
|
||||||
<para>
|
</para>
|
||||||
Be sure to remove the <filename>hbase-default.xml</filename> from
|
</section>
|
||||||
your <filename>conf</filename>
|
<section xml:id="upgrade0.94">
|
||||||
directory on upgrade. A 0.20.x version of this file will have
|
<title>Upgrading from 0.92.x to 0.94.x</title>
|
||||||
sub-optimal configurations for 0.90.x HBase. The
|
<para>0.92 and 0.94 are interface compatible. You can do a rolling upgrade between these versions.
|
||||||
<filename>hbase-default.xml</filename> file is now bundled into the
|
</para>
|
||||||
HBase jar and read from there. If you would like to review
|
</section>
|
||||||
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.92">
|
<section xml:id="upgrade0.92">
|
||||||
<title>Upgrading from 0.90.x to 0.92.x</title>
|
<title>Upgrading from 0.90.x to 0.92.x</title>
|
||||||
<subtitle>Upgrade Guide</subtitle>
|
<subtitle>Upgrade Guide</subtitle>
|
||||||
|
|
@ -173,7 +149,7 @@ The block size default size has been changed in 0.92.0 from 0.2 (20 percent of h
|
||||||
<section><title>Experimental off-heap cache
|
<section><title>Experimental off-heap cache
|
||||||
</title>
|
</title>
|
||||||
<para>
|
<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.
|
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/
|
See this blog post for additional information on this new experimental feature: http://www.cloudera.com/blog/2012/01/caching-in-hbase-slabcache/
|
||||||
</para>
|
</para>
|
||||||
|
|
@ -201,4 +177,44 @@ If you have lots of regions now -- more than 100s per host -- you should look in
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
</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>
|
</chapter>
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue