phoenix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jamestay...@apache.org
Subject svn commit: r1693125 - in /phoenix/site: publish/release_notes.html source/src/site/markdown/release_notes.md
Date Tue, 28 Jul 2015 15:52:38 GMT
Author: jamestaylor
Date: Tue Jul 28 15:52:38 2015
New Revision: 1693125

URL: http://svn.apache.org/r1693125
Log:
Update release_notes.md with timeout params to set higher

Modified:
    phoenix/site/publish/release_notes.html
    phoenix/site/source/src/site/markdown/release_notes.md

Modified: phoenix/site/publish/release_notes.html
URL: http://svn.apache.org/viewvc/phoenix/site/publish/release_notes.html?rev=1693125&r1=1693124&r2=1693125&view=diff
==============================================================================
--- phoenix/site/publish/release_notes.html (original)
+++ phoenix/site/publish/release_notes.html Tue Jul 28 15:52:38 2015
@@ -1,7 +1,7 @@
 
 <!DOCTYPE html>
 <!--
- Generated by Apache Maven Doxia at 2015-07-27
+ Generated by Apache Maven Doxia at 2015-07-28
  Rendered using Reflow Maven Skin 1.1.0 (http://andriusvelykis.github.io/reflow-maven-skin)
 -->
 <html  xml:lang="en" lang="en">
@@ -159,13 +159,13 @@
    <pre>./psql.py -u my_host_name
 </pre> 
   </div> 
-  <p>This will look through all tables you’ve defined and indicate if any upgrades
are necessary.</p> 
+  <p>This will look through all tables you’ve defined and indicate if any upgrades
are necessary. Ensure your client-side <tt>phoenix.query.timeoutMs</tt> property
and server-side <tt>hbase.regionserver.lease.period</tt> are set high enough for
the command to complete.</p> 
   <p>To upgrade the tables, run the same command, but list the tables you’d like
upgraded like this:</p> 
   <div class="source"> 
    <pre>./psql.py -u my_host_name table1 table2 table3
 </pre> 
   </div> 
-  <p>This will first make a snapshot of your table and then upgrade it. If any problems
occur during the upgrade process, the snapshot of your original table will be restored.</p>

+  <p>This will first make a snapshot of your table and then upgrade it. If any problems
occur during the upgrade process, the snapshot of your original table will be restored. Again,
make sure your timeouts are set high enough, as the tables being upgraded need to be rewritten
in order to fix them.</p> 
   <p>For the case of BINARY columns, no update is required if you’ve always provided
all of the bytes making up that column value (i.e. you have not relied on Phoenix to auto-pad
the column up to the fixed length). In this case, you should bypass the upgrade by running
the following command:</p> 
   <div class="source"> 
    <pre>./psql.py -u -b my_host_name table1

Modified: phoenix/site/source/src/site/markdown/release_notes.md
URL: http://svn.apache.org/viewvc/phoenix/site/source/src/site/markdown/release_notes.md?rev=1693125&r1=1693124&r2=1693125&view=diff
==============================================================================
--- phoenix/site/source/src/site/markdown/release_notes.md (original)
+++ phoenix/site/source/src/site/markdown/release_notes.md Tue Jul 28 15:52:38 2015
@@ -21,13 +21,18 @@ To get an idea if any of your tables are
     ./psql.py -u my_host_name
 
 This will look through all tables you've defined and indicate if any upgrades are necessary.
+Ensure your client-side <code>phoenix.query.timeoutMs</code> property and server-side
+<code>hbase.regionserver.lease.period</code> are set high enough for the command
to complete.
+
 
 To upgrade the tables, run the same command, but list the tables you'd like upgraded like
this:
 
     ./psql.py -u my_host_name table1 table2 table3
 
 This will first make a snapshot of your table and then upgrade it. If any problems occur
-during the upgrade process, the snapshot of your original table will be restored.
+during the upgrade process, the snapshot of your original table will be restored. Again,
make
+sure your timeouts are set high enough, as the tables being upgraded need to be rewritten
+in order to fix them.
 
 For the case of BINARY columns, no update is required if you've always provided all of
 the bytes making up that column value (i.e. you have not relied on Phoenix to auto-pad the



Mime
View raw message