Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
3.4.0
-
Reviewed
Description
During rollingUpgrade, bootstrapStandby will fail with an exception due to different NameNodeLayoutVersions. We can ignore this safely during RollingUpgrade because different NameNodeLayoutVersions are expected.
- NameNodes will not be able to recover with BootstrapStandby if they go through destructive repair before the rollingUpgrade has been finalized.
Error during BootstrapStandby before change:
===================================================== About to bootstrap Standby ID nn2 from: Nameservice ID: MTPrime-MWHE01-0 Other Namenode ID: nn1 Other NN's HTTP address: https://MWHEEEAP002D9A2:81 Other NN's IPC address: MWHEEEAP002D9A2.ap.gbl/10.59.208.18:8020 Namespace ID: 895912530 Block pool ID: BP-1556042256-10.99.154.61-1663325602669 Cluster ID: MWHE01 Layout version: -64 isUpgradeFinalized: true ===================================================== 2023-08-28T19:35:06,940 ERROR [main] namenode.NameNode: Failed to start namenode. java.io.IOException: java.lang.RuntimeException: org.apache.hadoop.hdfs.server.namenode.TransferFsImage$HttpGetFailedException: Image transfer servlet at https://MWHEEEAP002D9A2:81/imagetransfer?getimage=1&txid=25683470&storageInfo=-64:895912530:1663325602669:MWHE01&bootstrapstandby=true failed with status code 403 Response message: This namenode has storage info -63:895912530:1663325602669:MWHE01 but the secondary expected -64:895912530:1663325602669:MWHE01 at org.apache.hadoop.hdfs.server.namenode.ha.BootstrapStandby.run(BootstrapStandby.java:583) ~[hadoop-hdfs-2.9.2-MT-SNAPSHOT.jar:?] at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1717) ~[hadoop-hdfs-2.9.2-MT-SNAPSHOT.jar:?] at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1819) [hadoop-hdfs-2.9.2-MT-SNAPSHOT.jar:?] Caused by: java.lang.RuntimeException: org.apache.hadoop.hdfs.server.namenode.TransferFsImage$HttpGetFailedException: Image transfer servlet at https://MWHEEEAP002D9A2:81
This is caused because the namespaceInfo sent from the proxy node does not include the effective layout version, which causes BootstrapStandby to send a request with a storageinfo param using the service layout version. This causes the proxy node to refuse the request, because it compares the storageinfo param against its storage info, which uses the effective layout version, not the service layout version.
To fix this we can modify the proxy.versionRequest() call stack to set the layout version using the effective layout version on the proxy node. We can then add logic to BootstrapStandby to properly handle the case where the proxy node is in rolling upgrade.