-
-
Notifications
You must be signed in to change notification settings - Fork 7
Rolling HDFS upgrade #571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rolling HDFS upgrade #571
Changes from all commits
a5e9547
fc6cc0d
2eb38a8
38809e2
a36de0f
acffa82
98baaad
5a552d3
c1e13a2
e1476a2
8af1db6
44b5e59
947931e
5970585
13129b5
eb19010
d5a092a
f0df2b7
49cf9d9
c582a3a
b24c25f
1e68f1d
10e5220
808f926
a9809ba
0604aa6
c142421
6ae8e0b
46eedee
2a25ff4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,107 @@ | ||
= Upgrading HDFS | ||
|
||
IMPORTANT: HDFS upgrades are experimental, and details may change at any time | ||
|
||
HDFS currently requires a manual process to upgrade. This guide will take you through an example case, upgrading an example cluster (from our xref:getting_started/index.adoc[Getting Started] guide) from HDFS 3.3.6 to 3.4.0. | ||
|
||
== Preparing for the worst | ||
|
||
Upgrades can fail, and it is important to prepare for when that happens. Apache HDFS supports https://hadoop.apache.org/docs/r3.4.0/hadoop-project-dist/hadoop-hdfs/HdfsRollingUpgrade.html#Downgrade_and_Rollback[two ways to revert an upgrade]: | ||
|
||
Rollback:: Reverts all user data to the pre-upgrade state. Requires taking the cluster offline. | ||
Downgrade:: Downgrades the HDFS software but preserves all changes made by users. Can be performed as a rolling change, keeping the cluster online. | ||
|
||
The Stackable Operator for HDFS supports downgrading but not rollbacks. | ||
|
||
In order to downgrade, revert the `.spec.image.productVersion` field, and then proceed to xref:#finalize[finalizing] once the cluster is downgraded: | ||
|
||
[source,shell] | ||
---- | ||
$ kubectl patch hdfs/simple-hdfs --patch '{"spec": {"image": {"productVersion": "3.3.6"}}}' --type=merge | ||
hdfscluster.hdfs.stackable.tech/simple-hdfs patched | ||
---- | ||
|
||
== Preparing HDFS | ||
|
||
HDFS must be configured to initiate the upgrade process. To do this, put the cluster into upgrade mode by running the following commands in an HDFS superuser environment | ||
(either a client configured with a superuser account, or from inside a NameNode pod): | ||
|
||
// This could be automated by the operator, but dfsadmin does not have good machine-readable output. | ||
// It *can* be queried over JMX, but we're not so lucky for finalization. | ||
NickLarsenNZ marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
[source,shell] | ||
---- | ||
$ hdfs dfsadmin -rollingUpgrade prepare | ||
Check notice on line 34 in docs/modules/hdfs/pages/usage-guide/upgrading.adoc
|
||
PREPARE rolling upgrade ... | ||
Preparing for upgrade. Data is being saved for rollback. | ||
Run "dfsadmin -rollingUpgrade query" to check the status | ||
for proceeding with rolling upgrade | ||
Block Pool ID: BP-841432641-10.244.0.29-1722612757853 | ||
Start Time: Fri Aug 02 15:49:12 GMT 2024 (=1722613752341) | ||
Finalize Time: <NOT FINALIZED> | ||
|
||
$ # Then run query until the HDFS is ready to proceed | ||
$ hdfs dfsadmin -rollingUpgrade query | ||
Check notice on line 44 in docs/modules/hdfs/pages/usage-guide/upgrading.adoc
|
||
QUERY rolling upgrade ... | ||
Preparing for upgrade. Data is being saved for rollback. | ||
Run "dfsadmin -rollingUpgrade query" to check the status | ||
for proceeding with rolling upgrade | ||
Block Pool ID: BP-841432641-10.244.0.29-1722612757853 | ||
Start Time: Fri Aug 02 15:49:12 GMT 2024 (=1722613752341) | ||
Finalize Time: <NOT FINALIZED> | ||
|
||
$ # It is safe to proceed when the output indicates so, like this: | ||
$ hdfs dfsadmin -rollingUpgrade query | ||
Check notice on line 54 in docs/modules/hdfs/pages/usage-guide/upgrading.adoc
|
||
QUERY rolling upgrade ... | ||
Proceed with rolling upgrade: | ||
Block Pool ID: BP-841432641-10.244.0.29-1722612757853 | ||
Start Time: Fri Aug 02 15:49:12 GMT 2024 (=1722613752341) | ||
Finalize Time: <NOT FINALIZED> | ||
---- | ||
|
||
== Starting the upgrade | ||
|
||
Once HDFS is ready to upgrade, the HdfsCluster can be updated with the new product version: | ||
|
||
[source,shell] | ||
---- | ||
$ kubectl patch hdfs/simple-hdfs --patch '{"spec": {"image": {"productVersion": "3.4.0"}}}' --type=merge | ||
hdfscluster.hdfs.stackable.tech/simple-hdfs patched | ||
---- | ||
|
||
Then wait until all pods have restarted, are in the Ready state, and running the new HDFS version. | ||
|
||
NOTE: This will automatically enable the NameNodes' compatibility mode, allowing them to start despite the fsImage version mismatch. | ||
|
||
NOTE: Services will be upgraded in order: JournalNodes, then NameNodes, then DataNodes. | ||
|
||
[#finalize] | ||
== Finalizing the upgrade | ||
|
||
Once all HDFS pods are running the new version, the HDFS upgrade can be finalized (from the HDFS superuser environment as described in the preparation step): | ||
|
||
[source,shell] | ||
---- | ||
$ hdfs dfsadmin -rollingUpgrade finalize | ||
Check notice on line 85 in docs/modules/hdfs/pages/usage-guide/upgrading.adoc
|
||
FINALIZE rolling upgrade ... | ||
Rolling upgrade is finalized. | ||
Block Pool ID: BP-841432641-10.244.0.29-1722612757853 | ||
Start Time: Fri Aug 02 15:49:12 GMT 2024 (=1722613752341) | ||
Finalize Time: Fri Aug 02 15:58:39 GMT 2024 (=1722614319854) | ||
---- | ||
|
||
// We can't safely automate this, because finalize is asynchronous and doesn't tell us whether all NameNodes have even received the request to finalize. | ||
NickLarsenNZ marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
WARNING: Please ensure that all NameNodes are running and available before proceeding. NameNodes that have not finalized yet will crash on launch when taken out of compatibility mode. | ||
|
||
Finally, mark the cluster as upgraded: | ||
|
||
[source,shell] | ||
---- | ||
$ kubectl patch hdfs/simple-hdfs --subresource=status --patch '{"status": {"deployedProductVersion": "3.4.0"}}' --type=merge | ||
hdfscluster.hdfs.stackable.tech/simple-hdfs patched | ||
---- | ||
|
||
NOTE: `deployedProductVersion` is located in the _status_ subresource, which will not be modified by most graphical editors, and `kubectl` requires the `--subresource=status` flag. | ||
|
||
The NameNodes will then be restarted a final time, taking them out of compatibility mode. |
Uh oh!
There was an error while loading. Please reload this page.