-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Hbase-24764 : Add support of adding base peer configs via hbase-site.xml for all replication peers #2327
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
Conversation
…ml for all replication peers
|
💔 -1 overall
This message was automatically generated. |
|
💔 -1 overall
This message was automatically generated. |
|
🎊 +1 overall
This message was automatically generated. |
|
@bharathv : Can you please have a look at this ? This is for branch-1. |
|
Will do, waiting for a +1 from Stack on the original PR and then I can sign off on this. |
|
@bharathv : Can you take a look at this. Thanks. |
bharathv
left a comment
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.
Add a quick note in the commit message about how the replication design changes from branch-1 vs other branches affect this? (The part about multiple RS updating the ZK state and the last RPC wins and if there is a divergence in configuration across RS, the end result may be non-deterministic).
| String configName = entry.getKey(); | ||
| String configValue = entry.getValue(); | ||
| // Only override if base config does not exist in existing replication peer configs | ||
| if (!receivedPeerConfigMap.containsKey(configName)) { |
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.
nit: just use this.configuration directly?
…t to other branch for Hbase-24764. branch-1 does not have master based coordination for replication like master branch , and hence each RS is responsible for initing peers and updating ZK states. As part of this change we are updating zk state of peers after reading from configuration, so if there is a divergence in configuration across RS the result can be can be non-deteministic and the last RS RPC will win.
|
🎊 +1 overall
This message was automatically generated. |
JIRA: https://issues.apache.org/jira/browse/HBASE-24764
JIRA Description:
Today, if a user needs to apply some common base peer configs to all the replication peers on the cluster, the only way is to execute update_peer_config via CLI which requires manual intervention and can be tedious in case of large deployment fleet.
As part of this JIRA, we plan to add the support to have base replication peer configs as part of hbase-site.xml like hbase.replication.peer.base.config="k1=v1;k2=v2.." which can be easily updated and applied as part of a rolling restart.
Example below:
This property will be empty by default, but user can override to have base configs in place.
The final peer configuration would be a merge of whatever is currently present or what users override during the peer creation/update (if any) + this newly added base config.
Related Jira: https://issues.apache.org/jira/browse/HBASE-17543. HBASE-17543 added the support to add the WALEntryFilters to default endpoint via peer configuration.
By this new Jira we are extending the support to update peer configs via hbase-site.xml and hence WalEntryFilters or any other peer property can be applied just by rolling restart.
master branch PR : #2284