DomGarguilo commented on code in PR #456: URL: https://github.com/apache/accumulo-website/pull/456#discussion_r2051131784
########## _docs-2/administration/upgrading.md: ########## @@ -4,6 +4,48 @@ category: administration order: 7 --- +## Changes to the upgrade process + +In upgrade notes for prior releases we have advised that users should ensure that no FATE +transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the +fact that the internal serialization of FATE transactions is not guaranteed to be +compatible between versions. Accumulo never provided any tooling around the upgrade process +and left it up the user, which can cause problems if older versions of FATE transactions +exist and the user already deployed the new version of software. The user would have to +re-install the old version of software to remove the FATE transactions. + +Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to +make it easier for the user to validate their instance is ready for upgrade. In earlier +versions the upgrade process would start when the user started the instance with the +new version of software. The process ran entirely in the Manager and it was the users +responsibility to read the upgrade notes to perform any necessary pre-upgrade steps. + +The new upgrade process introduces a new `accumulo upgrade` command which will be used +after shutting down the instance with the old version of software and before starting +the instance with the new version of software. The `upgrade` command has two options, +`--prepare` and `--start`. `--prepare` is designed to be executed by the user after shutting +down the instance. This option will check that the Manager is down, validate that there +are no existing FATE transactions, remove all of the server locks in ZooKeeper, and place +a node in ZooKeeper that will prevent server processes from being started again. If there +are FATE transactions, the command will fail giving the user the opportunity to clean them +up. The `--prepare` option can then be run again. + +The `--start` option is designed to be executed by the user before starting the instance Review Comment: ```suggestion The `--start` option is designed to be executed by the user before starting the instance (and after running the `--prepare` step) ``` I'm not too sure if this should be included since we say below that its not absolutely necessary for `--prepare` to be run ########## _docs-2/administration/upgrading.md: ########## @@ -4,6 +4,48 @@ category: administration order: 7 --- +## Changes to the upgrade process + +In upgrade notes for prior releases we have advised that users should ensure that no FATE +transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the +fact that the internal serialization of FATE transactions is not guaranteed to be +compatible between versions. Accumulo never provided any tooling around the upgrade process +and left it up the user, which can cause problems if older versions of FATE transactions +exist and the user already deployed the new version of software. The user would have to +re-install the old version of software to remove the FATE transactions. + +Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to +make it easier for the user to validate their instance is ready for upgrade. In earlier +versions the upgrade process would start when the user started the instance with the +new version of software. The process ran entirely in the Manager and it was the users +responsibility to read the upgrade notes to perform any necessary pre-upgrade steps. + +The new upgrade process introduces a new `accumulo upgrade` command which will be used +after shutting down the instance with the old version of software and before starting +the instance with the new version of software. The `upgrade` command has two options, +`--prepare` and `--start`. `--prepare` is designed to be executed by the user after shutting +down the instance. This option will check that the Manager is down, validate that there +are no existing FATE transactions, remove all of the server locks in ZooKeeper, and place +a node in ZooKeeper that will prevent server processes from being started again. If there Review Comment: ```suggestion a node in ZooKeeper that will prevent server processes from being started again before the upgrade is complete. If there ``` ########## _docs-2/administration/upgrading.md: ########## @@ -4,6 +4,48 @@ category: administration order: 7 --- +## Changes to the upgrade process + +In upgrade notes for prior releases we have advised that users should ensure that no FATE +transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the +fact that the internal serialization of FATE transactions is not guaranteed to be +compatible between versions. Accumulo never provided any tooling around the upgrade process +and left it up the user, which can cause problems if older versions of FATE transactions +exist and the user already deployed the new version of software. The user would have to +re-install the old version of software to remove the FATE transactions. + +Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to +make it easier for the user to validate their instance is ready for upgrade. In earlier +versions the upgrade process would start when the user started the instance with the +new version of software. The process ran entirely in the Manager and it was the users +responsibility to read the upgrade notes to perform any necessary pre-upgrade steps. + +The new upgrade process introduces a new `accumulo upgrade` command which will be used Review Comment: "will be used" Would "should be" or "needs to be" fit better here? ########## _docs-2/administration/upgrading.md: ########## @@ -4,6 +4,48 @@ category: administration order: 7 --- +## Changes to the upgrade process + +In upgrade notes for prior releases we have advised that users should ensure that no FATE +transactions exist (see `Upgrading from 1.10 or 2.0 to 2.1` below). This is due to the +fact that the internal serialization of FATE transactions is not guaranteed to be +compatible between versions. Accumulo never provided any tooling around the upgrade process +and left it up the user, which can cause problems if older versions of FATE transactions +exist and the user already deployed the new version of software. The user would have to +re-install the old version of software to remove the FATE transactions. + +Starting with Accumulo 4.0 we are modifying the upgrade process steps in an attempt to +make it easier for the user to validate their instance is ready for upgrade. In earlier +versions the upgrade process would start when the user started the instance with the +new version of software. The process ran entirely in the Manager and it was the users +responsibility to read the upgrade notes to perform any necessary pre-upgrade steps. + +The new upgrade process introduces a new `accumulo upgrade` command which will be used +after shutting down the instance with the old version of software and before starting +the instance with the new version of software. The `upgrade` command has two options, +`--prepare` and `--start`. `--prepare` is designed to be executed by the user after shutting +down the instance. This option will check that the Manager is down, validate that there +are no existing FATE transactions, remove all of the server locks in ZooKeeper, and place +a node in ZooKeeper that will prevent server processes from being started again. If there +are FATE transactions, the command will fail giving the user the opportunity to clean them +up. The `--prepare` option can then be run again. + +The `--start` option is designed to be executed by the user before starting the instance +with the newer version of software. The `--start` option will perform any necessary pre-upgrade +validation, any changes that are necessary for the new version of software to start, seed Review Comment: ```suggestion validation, make any changes that are necessary for the new version of software to start, seed ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@accumulo.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
