You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Track state of upgrade to eliminate re-running upgrade code (#5357)
During an upgrade the UpgradeCoordinator will run Upgraders
for each version between the current version of the stored
data and the current version of the installed software. The
UpgradeCoordinator runs all of the necessary Upgraders on
ZooKeeper, then runs all of them on the root table, and then
finally runs all of them on the metadata table. This means
that when upgrading through multiple versions the version of
the data stored in ZooKeeper could be multiple versions ahead
of the root and metadata tables, until the Upgraders are run
on those tables.
When a failure occurs in the Upgrade the system is left in a
partially upgraded state. The user needs to find and fix any
issues before trying to start the system again. When the Manager
starts the next time it will attempt to do the upgrade from
the very beginning. An Upgrader implementation for one version
needs to be coded to handle the upgrade process running again,
so it needs to take into account the fact that the ZooKeeper
data has already been modified and skip that step, for example.
However, an Upgrader for one version can't account for the
changes in a future version.
This change creates a temporary object stored in ZooKeeper that
is created when an upgrade starts and deleted when the upgrade
finishes. It keeps track of the version of the ZooKeeper, root,
and metadata as the Upgraders are run against those objects and
the overall target version of the upgrade. TheUpgradeCoordinator
has been modified to use this object so that it does not re-run
Upgraders on those objects when they have already run successfully.
This change also fixes EasyMock usage in AccumuloTest unit test for
upgrades observed while adding the context to the
UpgradeCoordinator constructor and moves the PreUpgradeValidation
inside the UpgradeCoordinator (since they are related responsibilities).
Closes#5347
Co-authored-by: Christopher Tubbs <ctubbsii@apache.org>
0 commit comments