Sean Busbey
added a comment - 21/Feb/14 23:05 I can verify that given a 1.4 instance, 1.6.0-SNAPSHOT properly says "Nooooooope."
The error message is the generic "This version of Accumulo doesn't work with the version from your data" from server/base/src/main/java/org/apache/accumulo/server/Accumulo.java
if (dataVersion != ServerConstants.DATA_VERSION && dataVersion != ServerConstants.PREV_DATA_VERSION) {
throw new RuntimeException( "This version of accumulo (" + codeVersion + ") is not compatible with files stored using data version " + dataVersion);
}
Does this upgrade just need to be manual? Would an upgrade from 1.5.1-rc2 be sufficient?

Sean Busbey
added a comment - 20/Mar/14 17:02 In flight patch for ACCUMULO-2451 (as seen on the reviewboard for ACCUMULO-2061 ) changes the upgrade process, so this ticket needs to wait for that to land.

Sean Busbey
added a comment - 28/Mar/14 21:58 As a part of this, I plan to update the README's section on upgrading. Right now it still gives the 1.4 -> 1.5 instructions.
Besides the instructions about Fate that will be added as a part of ACCUMULO-2519 , are there any other special considerations?

Furthermore, as the user manual chapter points out, multivolume configurations are an advanced option only needed at a particular scale. It's not something we should be calling out in the README for common upgrades.

Sean Busbey
added a comment - 02/Apr/14 09:15 Josh Elser , that sounds like something that should be covered in the user manual chapter on multi volume set ups .
For one thing, I would expect to do such an upgrade in two steps
Upgrade 1.5.x -> 1.6.x and verify
move from single volume to multi volume and verify
This looks, to me, like a distinct step unrelated to upgrades.
Furthermore, as the user manual chapter points out, multivolume configurations are an advanced option only needed at a particular scale. It's not something we should be calling out in the README for common upgrades.
Can you please file a follow on ticket?

Didn't realize that documentation was already added to the user manual for it (kudos to those involved). Configuration of volumes before the upgrade process is complete is exactly what I was thinking about (mostly, because I did it myself at least once).

Josh Elser
added a comment - 02/Apr/14 15:51 Didn't realize that documentation was already added to the user manual for it (kudos to those involved). Configuration of volumes before the upgrade process is complete is exactly what I was thinking about (mostly, because I did it myself at least once).

1. Clarify the "if your instance previously upgraded from 1.4 to 1.5" statement to only apply to recent upgrades (e.g. the 1.4->1.6 path). That may be confusing for people who have been on 1.5 for some time. Maybe something like "For those attempting to upgrade to 1.6 from 1.4 through 1.5, ..."? That seems a bit wordy too.
2. In the last paragraph, quote "metadata" to be clear that we're referring to the table named "metadata" and not "table metadata".

Josh Elser
added a comment - 05/Apr/14 00:33 Two minor changes, if you could:
1. Clarify the "if your instance previously upgraded from 1.4 to 1.5" statement to only apply to recent upgrades (e.g. the 1.4->1.6 path). That may be confusing for people who have been on 1.5 for some time. Maybe something like "For those attempting to upgrade to 1.6 from 1.4 through 1.5, ..."? That seems a bit wordy too.
2. In the last paragraph, quote "metadata" to be clear that we're referring to the table named "metadata" and not "table metadata".
Otherwise, looks good. Very thorough.

Clarify the "if your instance previously upgraded from 1.4 to 1.5" statement to only apply to recent upgrades (e.g. the 1.4->1.6 path). That may be confusing for people who have been on 1.5 for some time. Maybe something like "For those attempting to upgrade to 1.6 from 1.4 through 1.5, ..."? That seems a bit wordy too.

If they upgraded from 1.4 to 1.5 with an offline table that has walog entries, that all happened to be the only things on tablet server that was off (or that ran into problems attempting to do the copy, it won't matter how long ago it was. Presuming they ever bring the table back online.

I could maybe explain that the 1.4 to 1.5 upgrade process asynchronously handled migrating 1.4 write ahead logs and that 1.6 can no longer make retries?

In the last paragraph, quote "metadata" to be clear that we're referring to the table named "metadata" and not "table metadata".

I did mean "table metadata". We write into multiple tables as a part of the upgrade, not just into the reserved metadata table. (the new reserved root, for example)

Sean Busbey
added a comment - 05/Apr/14 00:41 Clarify the "if your instance previously upgraded from 1.4 to 1.5" statement to only apply to recent upgrades (e.g. the 1.4->1.6 path). That may be confusing for people who have been on 1.5 for some time. Maybe something like "For those attempting to upgrade to 1.6 from 1.4 through 1.5, ..."? That seems a bit wordy too.
If they upgraded from 1.4 to 1.5 with an offline table that has walog entries, that all happened to be the only things on tablet server that was off (or that ran into problems attempting to do the copy, it won't matter how long ago it was. Presuming they ever bring the table back online.
I could maybe explain that the 1.4 to 1.5 upgrade process asynchronously handled migrating 1.4 write ahead logs and that 1.6 can no longer make retries?
In the last paragraph, quote "metadata" to be clear that we're referring to the table named "metadata" and not "table metadata".
I did mean "table metadata". We write into multiple tables as a part of the upgrade, not just into the reserved metadata table. (the new reserved root, for example)

Josh Elser
added a comment - 05/Apr/14 01:00 I could maybe explain that the 1.4 to 1.5 upgrade process asynchronously handled migrating 1.4 write ahead logs and that 1.6 can no longer make retries?
I think that would be a good idea. Perhaps a disclaimer that those successfully running 1.5 upgraded from 1.4 don't need to perform the verification of no local WALs, too.
I did mean "table metadata". We write into multiple tables as a part of the upgrade, not just into the reserved metadata table. (the new reserved root, for example)
Oh I see. What about ".. in both ZooKeeper and the Accumulo system tables." instead? That would match nomenclature better I believe.

Sean Busbey
added a comment - 06/Apr/14 03:16 Verified upgrade works from 1.5.0, 1.5.1, 1.5.2-SNAPSHOT.
(1.5.2-SNAPSHOT test included starting with data written in 1.4.x in addition to data written in 1.5.2-SNAP).