-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
HDFS-16688. Unresolved Hosts during startup are not synced by JournalNodes #4725
base: trunk
Are you sure you want to change the base?
Conversation
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
I was unable to replicate the test failure |
💔 -1 overall
This message was automatically generated. |
...oject/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/qjournal/client/IPCLoggerChannel.java
Show resolved
Hide resolved
...adoop-hdfs/src/main/java/org/apache/hadoop/hdfs/qjournal/client/IPCLoggerChannelMetrics.java
Show resolved
Hide resolved
hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/tools/TestGetConf.java
Show resolved
Hide resolved
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
ee9946b
to
f72c421
Compare
Rebased against trunk, addressing the conflict. |
💔 -1 overall
This message was automatically generated. |
…Nodes Allow unresolved names during startup, so that when the hosts become available they will be included in JournalNode synchronization. This also requires that mechanisms that return a string representation which includes the IP address had to be updated to handle unresolved addresses.
Add a new configuration property that allows journalnodes to be temporarily unresolved. This allows the default behavior to be the same, but allows namenodes and journalnodes to handle resolution later. When not required, the servers will trust that the configuration is the desired state.
This had initially been intended as a change to the test, since allowing unresolved addresses was the goal. I instead introduced a setting to control when resolution was required.
With the introduction of "dfs.namenode.edits.qjournals.resolution-required" (defaults to true) we can restore the original check for a thrown exception. Also update the hostname to avoid incidental local matches during lookup.
f72c421
to
1a2b49c
Compare
🎊 +1 overall
This message was automatically generated. |
Description of PR
During the JournalNode startup, it builds the list of servers in the JournalNode set, ignoring hostnames that cannot be resolved. In environments with dynamic IP address allocations this means that the JournalNodeSyncer will never sync with hosts that aren't resolvable during startup.
Allow unresolved names during startup, so that when the hosts become available they will be included in JournalNode synchronization. This also requires that mechanisms that return a string representation which includes the IP address had to be updated to handle unresolved addresses.
Resolution continues to be required by default. This patch adds a new configuration which allows the requirement to be disabled, enabling support for unresolved addresses.
How was this patch tested?
Integration tests were performed against an HA configuration running in Kubernetes, running Java 11. Starting the cluster with fewer replicas than the list of JournalNodes listed in the configurations started, and the logs showed attempts to sync against the missing replicas. Missing instances of the JournalNode were incorporated into synchronization and NameNode shared edits once they were started without any intervention.
For code changes:
LICENSE
,LICENSE-binary
,NOTICE-binary
files?