[jira] [Updated] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-20672: --- Attachment: HBASE-20672.master.003.patch > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.master.001.patch, HBASE-20672.master.002.patch, > HBASE-20672.master.003.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506288#comment-16506288 ] Ankit Jain commented on HBASE-20672: Added new patch HBASE-20672.master.003.patch. Fixed the code checkstyle issues and other issues as per comments. > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.master.001.patch, HBASE-20672.master.002.patch, > HBASE-20672.master.003.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-20672: --- Release Note: Exposing 2 new metrics in HBase to provide ReadRequestRate and WriteRequestRate at region server level. These metrics give the rate of request handled by the region server and are reset after every monitoring interval. Attachment: HBASE-20672.branch-1.v1.patch Status: Patch Available (was: Open) > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.v1.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-20672: --- Attachment: HBASE-20672.branch-1.001.patch > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.001.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-20672: --- Attachment: (was: HBASE-20672.branch-1.v1.patch) > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.001.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-20672: --- Attachment: HBASE-20672.master.001.patch > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.master.001.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505451#comment-16505451 ] Ankit Jain edited comment on HBASE-20672 at 6/7/18 11:13 PM: - Updated the patch as per the comments. HBASE-20672.master.002.patch was (Author: jain.ankit): Update the patch as per the comments. HBASE-20672.master.002.patch > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.master.001.patch, HBASE-20672.master.002.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505451#comment-16505451 ] Ankit Jain commented on HBASE-20672: Update the patch as per the comments. HBASE-20672.master.002.patch > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.master.001.patch, HBASE-20672.master.002.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-20672: --- Attachment: HBASE-20672.master.002.patch > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.master.001.patch, HBASE-20672.master.002.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508604#comment-16508604 ] Ankit Jain commented on HBASE-20672: Hey [~stack], Thank you for your comments. The intention behind these new metrics is to get a more real time understanding about the amount of read and write operations done by region server. The current metrics ReadRequestCount and WriteRequestCount are essentially values incremented from the start of the service and hence it makes it difficult to analyze the current operation load on the region server. Regarding your concern about extra overhead involved, for this patch we have not added any extra counters and are reusing the already existing ones. For populating the values for the rates, we are performing basic arithmetic operations using the values returned by preexisting counters. Currently, metric calculation happens after every 5000 ms at region server level (DEFAULT_REGIONSERVER_METRICS_PERIOD = 5000;). So that is what is currently being considered as monitoring interval. So I guess it is just the monitoring system thing and is not specifically related to Hbase. I hope my comments answers your questions. Do let me know if any other concerns. > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.master.001.patch, HBASE-20672.master.002.patch, > HBASE-20672.master.003.patch > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508604#comment-16508604 ] Ankit Jain edited comment on HBASE-20672 at 6/11/18 9:51 PM: - Hey [~stack], Thank you for your comments. The intention behind these new metrics is to get a more real time understanding about the amount of read and write operations done by region server. The current metrics ReadRequestCount and WriteRequestCount are essentially values incremented from the start of the service and hence it makes it difficult to analyze the current operation load on the region server. Regarding your concern about extra overhead involved, for this patch we have not added any extra counters and are reusing the already existing ones. For populating the values for the rates, we are performing basic arithmetic operations using the values returned by preexisting counters. Currently, metric calculation happens after every 5000 ms at region server level (DEFAULT_REGIONSERVER_METRICS_PERIOD = 5000. So that is what is currently being considered as monitoring interval. So I guess it is just the monitoring system thing and is not specifically related to Hbase. I hope my comments answers your questions. Do let me know if any other concerns. was (Author: jain.ankit): Hey [~stack], Thank you for your comments. The intention behind these new metrics is to get a more real time understanding about the amount of read and write operations done by region server. The current metrics ReadRequestCount and WriteRequestCount are essentially values incremented from the start of the service and hence it makes it difficult to analyze the current operation load on the region server. Regarding your concern about extra overhead involved, for this patch we have not added any extra counters and are reusing the already existing ones. For populating the values for the rates, we are performing basic arithmetic operations using the values returned by preexisting counters. Currently, metric calculation happens after every 5000 ms at region server level (DEFAULT_REGIONSERVER_METRICS_PERIOD = 5000;). So that is what is currently being considered as monitoring interval. So I guess it is just the monitoring system thing and is not specifically related to Hbase. I hope my comments answers your questions. Do let me know if any other concerns. > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.master.001.patch, HBASE-20672.master.002.patch, > HBASE-20672.master.003.patch, hits1vs2.4.40.400.png > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
Ankit Jain created HBASE-20672: -- Summary: Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval Key: HBASE-20672 URL: https://issues.apache.org/jira/browse/HBASE-20672 Project: HBase Issue Type: Improvement Components: metrics Reporter: Ankit Jain Assignee: Ankit Jain Hbase currently provides counter read/write requests (ReadRequestCount, WriteRequestCount). That said it is not easy to use counter that reset only after a restart of the service, we would like to expose 2 new metrics in HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-20672: --- Attachment: HBASE-20672.branch-2.001.patch > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.branch-2.001.patch, HBASE-20672.master.001.patch, > HBASE-20672.master.002.patch, HBASE-20672.master.003.patch, > hits1vs2.4.40.400.png > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20672) Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at every monitoring interval
[ https://issues.apache.org/jira/browse/HBASE-20672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-20672: --- Attachment: HBASE-20672.branch-1.002.patch > Create new HBase metrics ReadRequestRate and WriteRequestRate that reset at > every monitoring interval > - > > Key: HBASE-20672 > URL: https://issues.apache.org/jira/browse/HBASE-20672 > Project: HBase > Issue Type: Improvement > Components: metrics >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20672.branch-1.001.patch, > HBASE-20672.branch-1.002.patch, HBASE-20672.branch-2.001.patch, > HBASE-20672.master.001.patch, HBASE-20672.master.002.patch, > HBASE-20672.master.003.patch, hits1vs2.4.40.400.png > > > Hbase currently provides counter read/write requests (ReadRequestCount, > WriteRequestCount). That said it is not easy to use counter that reset only > after a restart of the service, we would like to expose 2 new metrics in > HBase to provide ReadRequestRate and WriteRequestRate at region server level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22216) "Waiting on master failover to complete" shows 30 to 40 time per milliseconds
[ https://issues.apache.org/jira/browse/HBASE-22216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-22216: --- Summary: "Waiting on master failover to complete" shows 30 to 40 time per milliseconds (was: "Waiting on master failover to complete" shows 30 to 40 time per millisecond ) > "Waiting on master failover to complete" shows 30 to 40 time per milliseconds > -- > > Key: HBASE-22216 > URL: https://issues.apache.org/jira/browse/HBASE-22216 > Project: HBase > Issue Type: Bug > Components: logging, Operability, proc-v2 >Affects Versions: 1.3.0 >Reporter: Xu Cang >Assignee: Ankit Jain >Priority: Minor > > "Waiting on master failover to complete" appears 30 to 40 times per > *millisecond* from one host when master is initializing. > This message is too noisy, epecially when there are issues when master init. > Should fix this by either rate-limiting or even revisit is that normal > #executeFromState gets called 30-40 times per ms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-22216) "Waiting on master failover to complete" shows 30 to 40 time per milliseconds
[ https://issues.apache.org/jira/browse/HBASE-22216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain reassigned HBASE-22216: -- Assignee: Ankit Jain (was: Ankit Jain) > "Waiting on master failover to complete" shows 30 to 40 time per milliseconds > -- > > Key: HBASE-22216 > URL: https://issues.apache.org/jira/browse/HBASE-22216 > Project: HBase > Issue Type: Bug > Components: logging, Operability, proc-v2 >Affects Versions: 1.3.0 >Reporter: Xu Cang >Assignee: Ankit Jain >Priority: Minor > > "Waiting on master failover to complete" appears 30 to 40 times per > *millisecond* from one host when master is initializing. > This message is too noisy, epecially when there are issues when master init. > Should fix this by either rate-limiting or even revisit is that normal > #executeFromState gets called 30-40 times per ms. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (HBASE-25102) fix replication.stats.thread.period.seconds default setting bug
[ https://issues.apache.org/jira/browse/HBASE-25102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-25102: --- Attachment: Screen Shot 2020-10-07 at 8.59.23 PM.png > fix replication.stats.thread.period.seconds default setting bug > > > Key: HBASE-25102 > URL: https://issues.apache.org/jira/browse/HBASE-25102 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 2.2.6, 2.3.2 >Reporter: ruanhui >Priority: Minor > Attachments: Screen Shot 2020-10-07 at 8.59.23 PM.png > > > replication.stats.thread.period.seconds is in seconds while default TimeUnit > is TimeUnit.MILLISECONDS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25102) fix replication.stats.thread.period.seconds default setting bug
[ https://issues.apache.org/jira/browse/HBASE-25102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209991#comment-17209991 ] Ankit Jain commented on HBASE-25102: [~frostruan]: Thanks for putting this JIRA. I just want to confirm are you referring to the default value being set in Replication.java in milliseconds (Refer to the screenshot)? or do you see any other gaps as well. Thanks !Screen Shot 2020-10-07 at 8.59.23 PM.png! > fix replication.stats.thread.period.seconds default setting bug > > > Key: HBASE-25102 > URL: https://issues.apache.org/jira/browse/HBASE-25102 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 2.2.6, 2.3.2 >Reporter: ruanhui >Priority: Minor > Attachments: Screen Shot 2020-10-07 at 8.59.23 PM.png > > > replication.stats.thread.period.seconds is in seconds while default TimeUnit > is TimeUnit.MILLISECONDS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24764) Add support of enabling default peer configs via hbase-site.xml for all replication peers.
[ https://issues.apache.org/jira/browse/HBASE-24764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-24764: --- Summary: Add support of enabling default peer configs via hbase-site.xml for all replication peers. (was: Add support of enabling default peer configs via hbase-site.xml for all default replication peers.) > Add support of enabling default peer configs via hbase-site.xml for all > replication peers. > -- > > Key: HBASE-24764 > URL: https://issues.apache.org/jira/browse/HBASE-24764 > Project: HBase > Issue Type: Improvement >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > > Currently, if a user needs to apply some common peer configs to all the > default replication peers, 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 default replication > peer configs as part of hbase-site.xml like > hbase.replication.peer.default.config="k1=v1;k2=v2.." which can be just > applied by a rolling restart. Example below: > > hbase.replication.peer.default.configs > hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 > > This will be empty by default, but one can override to have default configs > in place. > The final peer configuration would be a merge of this default config + > whatever users override during the peer creation/update (if any). > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24764) Add support of adding default peer configs via hbase-site.xml for all replication peers.
[ https://issues.apache.org/jira/browse/HBASE-24764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-24764: --- Summary: Add support of adding default peer configs via hbase-site.xml for all replication peers. (was: Add support of enabling default peer configs via hbase-site.xml for all replication peers.) > Add support of adding default peer configs via hbase-site.xml for all > replication peers. > > > Key: HBASE-24764 > URL: https://issues.apache.org/jira/browse/HBASE-24764 > Project: HBase > Issue Type: Improvement >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > > Currently, if a user needs to apply some common peer configs to all the > default replication peers, 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 default replication > peer configs as part of hbase-site.xml like > hbase.replication.peer.default.config="k1=v1;k2=v2.." which can be just > applied by a rolling restart. Example below: > > hbase.replication.peer.default.configs > hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 > > This will be empty by default, but one can override to have default configs > in place. > The final peer configuration would be a merge of this default config + > whatever users override during the peer creation/update (if any). > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HBASE-24764) Add support of adding default peer configs via hbase-site.xml for all replication peers.
[ https://issues.apache.org/jira/browse/HBASE-24764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-24764 started by Ankit Jain. -- > Add support of adding default peer configs via hbase-site.xml for all > replication peers. > > > Key: HBASE-24764 > URL: https://issues.apache.org/jira/browse/HBASE-24764 > Project: HBase > Issue Type: Improvement >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-24764-master.patch > > > Currently, if a user needs to apply some common peer configs to all the > default replication peers, 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 default replication > peer configs as part of hbase-site.xml like > hbase.replication.peer.default.config="k1=v1;k2=v2.." which can be just > applied by a rolling restart. Example below: > > hbase.replication.peer.default.configs > hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 > > This will be empty by default, but one can override to have default configs > in place. > The final peer configuration would be a merge of this default config + > whatever users override during the peer creation/update (if any). > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24764) Add support of adding default peer configs via hbase-site.xml for all replication peers.
[ https://issues.apache.org/jira/browse/HBASE-24764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-24764: --- Attachment: HBASE-24764-master.patch > Add support of adding default peer configs via hbase-site.xml for all > replication peers. > > > Key: HBASE-24764 > URL: https://issues.apache.org/jira/browse/HBASE-24764 > Project: HBase > Issue Type: Improvement >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-24764-master.patch > > > Currently, if a user needs to apply some common peer configs to all the > default replication peers, 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 default replication > peer configs as part of hbase-site.xml like > hbase.replication.peer.default.config="k1=v1;k2=v2.." which can be just > applied by a rolling restart. Example below: > > hbase.replication.peer.default.configs > hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 > > This will be empty by default, but one can override to have default configs > in place. > The final peer configuration would be a merge of this default config + > whatever users override during the peer creation/update (if any). > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24764) Add support of adding base peer configs via hbase-site.xml for all replication peers.
[ https://issues.apache.org/jira/browse/HBASE-24764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-24764: --- Description: Today, if a user needs to apply some common base peer configs to all the replication peers 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: hbase.replication.peer.base.configs hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 This will be empty by default, but one can override to have base configs in place. The final peer configuration would be a merge of this newly added base config + whatever users override during the peer creation/update (if any). 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. was: Currently, if a user needs to apply some common peer configs to all the default replication peers, 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 default replication peer configs as part of hbase-site.xml like hbase.replication.peer.default.config="k1=v1;k2=v2.." which can be just applied by a rolling restart. Example below: hbase.replication.peer.default.configs hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 This will be empty by default, but one can override to have default configs in place. The final peer configuration would be a merge of this default config + whatever users override during the peer creation/update (if any). 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. > Add support of adding base peer configs via hbase-site.xml for all > replication peers. > - > > Key: HBASE-24764 > URL: https://issues.apache.org/jira/browse/HBASE-24764 > Project: HBase > Issue Type: Improvement >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-24764-master.patch > > > Today, if a user needs to apply some common base peer configs to all the > replication peers 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: > > hbase.replication.peer.base.configs > > hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 > > This will be empty by default, but one can override to have base configs in > place. > The final peer configuration would be a merge of this newly added base config > + whatever users override during the peer creation/update (if any). > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24764) Add support of adding base peer configs via hbase-site.xml for all replication peers.
[ https://issues.apache.org/jira/browse/HBASE-24764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-24764: --- Summary: Add support of adding base peer configs via hbase-site.xml for all replication peers. (was: Add support of adding default peer configs via hbase-site.xml for all replication peers.) > Add support of adding base peer configs via hbase-site.xml for all > replication peers. > - > > Key: HBASE-24764 > URL: https://issues.apache.org/jira/browse/HBASE-24764 > Project: HBase > Issue Type: Improvement >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-24764-master.patch > > > Currently, if a user needs to apply some common peer configs to all the > default replication peers, 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 default replication > peer configs as part of hbase-site.xml like > hbase.replication.peer.default.config="k1=v1;k2=v2.." which can be just > applied by a rolling restart. Example below: > > hbase.replication.peer.default.configs > hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 > > This will be empty by default, but one can override to have default configs > in place. > The final peer configuration would be a merge of this default config + > whatever users override during the peer creation/update (if any). > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24764) Add support of adding base peer configs via hbase-site.xml for all replication peers.
[ https://issues.apache.org/jira/browse/HBASE-24764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-24764: --- Description: Today, if a user needs to apply some common base peer configs to all the replication peers on a given 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: hbase.replication.peer.base.configs hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 This will be empty by default, but one can override to have base configs in place. The final peer configuration would be a merge of this newly added base config + whatever users override during the peer creation/update (if any). 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. was: Today, if a user needs to apply some common base peer configs to all the replication peers 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: hbase.replication.peer.base.configs hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 This will be empty by default, but one can override to have base configs in place. The final peer configuration would be a merge of this newly added base config + whatever users override during the peer creation/update (if any). 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. > Add support of adding base peer configs via hbase-site.xml for all > replication peers. > - > > Key: HBASE-24764 > URL: https://issues.apache.org/jira/browse/HBASE-24764 > Project: HBase > Issue Type: Improvement >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Attachments: HBASE-24764-master.patch > > > Today, if a user needs to apply some common base peer configs to all the > replication peers on a given 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: > > hbase.replication.peer.base.configs > > hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 > > This will be empty by default, but one can override to have base configs in > place. > The final peer configuration would be a merge of this newly added base config > + whatever users override during the peer creation/update (if any). > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HBASE-25119) Fix property name added as part of HBASE-24764 in branch-1
[ https://issues.apache.org/jira/browse/HBASE-25119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-25119 started by Ankit Jain. -- > Fix property name added as part of HBASE-24764 in branch-1 > -- > > Key: HBASE-25119 > URL: https://issues.apache.org/jira/browse/HBASE-25119 > Project: HBase > Issue Type: Improvement > Components: Replication >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > > A new property was added as part of this > https://issues.apache.org/jira/browse/HBASE-24764. > Master branch has the name as "hbase.replication.peer.base.config" > while branch-1 has the name as "hbase.replication.peer.default.config" > > As part of this Jira fix the name in branch-1 to be consistent. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25119) Fix property name added as part of HBASE-24764 in branch-1
Ankit Jain created HBASE-25119: -- Summary: Fix property name added as part of HBASE-24764 in branch-1 Key: HBASE-25119 URL: https://issues.apache.org/jira/browse/HBASE-25119 Project: HBase Issue Type: Improvement Components: Replication Reporter: Ankit Jain Assignee: Ankit Jain A new property was added as part of this https://issues.apache.org/jira/browse/HBASE-24764. Master branch has the name as "hbase.replication.peer.base.config" while branch-1 has the name as "hbase.replication.peer.default.config" As part of this Jira fix the name in branch-1 to be consistent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24764) Add support of adding base peer configs via hbase-site.xml for all replication peers.
[ https://issues.apache.org/jira/browse/HBASE-24764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-24764: --- Release Note: Adds a new configuration parameter "hbase.replication.peer.base.config" which accepts a semi-colon separated key=CSV pairs (example: k1=v1;k2=v2_1,v3...). When this configuration is set on the server side, these kv pairs are added to every peer configuration if not already set. Peer specific configuration overrides have precedence over the above default configuration. This is useful in cases when some configuration has to be set for all the peers by default and one does not want to add to every peer definition. was: Adds a new configuration parameter "hbase.replication.peer.default.config" which accepts a semi-colon separated key=CSV pairs (example: k1=v1;k2=v2_1,v3...). When this configuration is set on the server side, these kv pairs are added to every peer configuration if not already set. Peer specific configuration overrides have precedence over the above default configuration. This is useful in cases when some configuration has to be set for all the peers by default and one does not want to add to every peer definition. > Add support of adding base peer configs via hbase-site.xml for all > replication peers. > - > > Key: HBASE-24764 > URL: https://issues.apache.org/jira/browse/HBASE-24764 > Project: HBase > Issue Type: Improvement > Components: Replication >Affects Versions: 3.0.0-alpha-1, 1.7.0, 2.4.0 >Reporter: Ankit Jain >Assignee: Ankit Jain >Priority: Minor > Fix For: 3.0.0-alpha-1, 1.7.0, 2.4.0 > > Attachments: HBASE-24764-master.patch > > > Today, if a user needs to apply some common base peer configs to all the > replication peers on a given 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: > > hbase.replication.peer.base.configs > > hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 > > This will be empty by default, but one can override to have base configs in > place. > The final peer configuration would be a merge of this newly added base config > + whatever users override during the peer creation/update (if any). > 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25209) Add CLI support to remove a particular configuration from ReplicationPeerConfig.
[
https://issues.apache.org/jira/browse/HBASE-25209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217879#comment-17217879
]
Ankit Jain commented on HBASE-25209:
Closing this out as we can set an empty string as part of the config CONFIG =>
\{ "foo" => ""} using update_peer_configuration which will also work and there
is no immediate need for this request.
> Add CLI support to remove a particular configuration from
> ReplicationPeerConfig.
>
>
> Key: HBASE-25209
> URL: https://issues.apache.org/jira/browse/HBASE-25209
> Project: HBase
> Issue Type: Improvement
> Components: Replication, shell
> Environment: {code:java}
> // code placeholder
> {code}
>Reporter: Ankit Jain
>Assignee: Ankit Jain
>Priority: Minor
>
> Currently, there is no easy way to remove a configuration from
> ReplicationPeerConfig after it is being set.
> This can come in handy at multiple instances when we want to remove a
> particular configuration when it's not needed anymore or it is causing
> unexpected behavior. For eg in case there is a need to remove a walFilter
> (hbase.replication.source.custom.walentryfilters) configuration.
> As part of this Jira we want to add that support.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (HBASE-25209) Add CLI support to remove a particular configuration from ReplicationPeerConfig.
[
https://issues.apache.org/jira/browse/HBASE-25209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Jain resolved HBASE-25209.
Resolution: Not A Problem
> Add CLI support to remove a particular configuration from
> ReplicationPeerConfig.
>
>
> Key: HBASE-25209
> URL: https://issues.apache.org/jira/browse/HBASE-25209
> Project: HBase
> Issue Type: Improvement
> Components: Replication, shell
> Environment: {code:java}
> // code placeholder
> {code}
>Reporter: Ankit Jain
>Assignee: Ankit Jain
>Priority: Minor
>
> Currently, there is no easy way to remove a configuration from
> ReplicationPeerConfig after it is being set.
> This can come in handy at multiple instances when we want to remove a
> particular configuration when it's not needed anymore or it is causing
> unexpected behavior. For eg in case there is a need to remove a walFilter
> (hbase.replication.source.custom.walentryfilters) configuration.
> As part of this Jira we want to add that support.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-25209) Add CLI support to remove a particular configuration from ReplicationPeerConfig.
Ankit Jain created HBASE-25209:
--
Summary: Add CLI support to remove a particular configuration from
ReplicationPeerConfig.
Key: HBASE-25209
URL: https://issues.apache.org/jira/browse/HBASE-25209
Project: HBase
Issue Type: Improvement
Components: Replication, shell
Environment: {code:java}
// code placeholder
{code}
Reporter: Ankit Jain
Assignee: Ankit Jain
Currently, there is no easy way to remove a configuration from
ReplicationPeerConfig after it is being set.
This can come in handy at multiple instances when we want to remove a
particular configuration when it's not needed anymore or it is causing
unexpected behavior. For eg in case there is a need to remove a walFilter
(hbase.replication.source.custom.walentryfilters) configuration.
As part of this Jira we want to add that support.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (HBASE-24764) Add support of enabling default peer configs via hbase-site.xml for all default replication peers.
Ankit Jain created HBASE-24764: -- Summary: Add support of enabling default peer configs via hbase-site.xml for all default replication peers. Key: HBASE-24764 URL: https://issues.apache.org/jira/browse/HBASE-24764 Project: HBase Issue Type: Improvement Reporter: Ankit Jain Assignee: Ankit Jain Currently, if a user needs to apply some common peer configs to all the default replication peers, 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 default replication peer configs as part of hbase-site.xml like hbase.replication.peer.default.config="k1=v1;k2=v2.." which can be just applied by a rolling restart. Example below: hbase.replication.peer.default.configs hbase.replication.source.custom.walentryfilters=x,y,z;hbase.rpc.protection=abc;hbase.xxx.custom_property=123 This will be empty by default, but one can override to have default configs in place. The final peer configuration would be a merge of this default config + whatever users override during the peer creation/update (if any). 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. -- This message was sent by Atlassian Jira (v8.3.4#803005)
