Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> [DISCUSS] Should we support upgrading 1.4 -> 1.6 w/o going through 1.5?


Copy link to this message
-
Re: [DISCUSS] Should we support upgrading 1.4 -> 1.6 w/o going through 1.5?
The upgrade test looks something like:

* Start up 1.4 (or 1.5)
* Create tables with a variety of configurations (LZO/Snappy/GZ, Bloom
Filter On/Off, Block Cache On/Off)
* Load some data into these tables, enough such that flushes and
compactions start to occur.
* Abruptly kill all of the servers. This ensures that there are WALs
around. Unfortunately, we can't have any compactions in progress at this
point, since that causes a Fate Operation, and that would prevent the
upgrade from completing.
* Upgrade the bits, start 1.6, and wait for the upgrade steps to finish.
* Check for data loss
* Trigger some compactions and wait for those to finish. In a previous
iteration, we discovered an issue where the relative path'd files and WALs
were not being properly deleted from !0.
* Check for data loss.
* Restart the tablet servers to force tablets to reload (test for orphaned
files).
* Check for data loss.

We did not try using custom iterators.

Mike
On Wed, Jul 30, 2014 at 4:58 PM, Christopher <[EMAIL PROTECTED]> wrote:
 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB