[
https://issues.apache.org/jira/browse/HBASE-18775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16176929#comment-16176929
]
Zach York commented on HBASE-18775:
-----------------------------------
[~ashish singhi] I'm not convinced that this should be implemented as a
coprocessor. The current read-only regions aren't implemented as a coprocessor.
I'd like to hear your pros/cons for each approach, perhaps there is something
I'm missing.
As for the ZK option, it seems like there is a desire (especially for large
clusters) to use ZK as little as possible (although maybe this is only for
assignment). Is there an inherent scaling issue with using ZK? Perhaps [~tedyu]
[~stack] might know better (than me) about the limitations of using ZK for
large clusters. I do like the more dynamic aspect of this (although in our
initial approach this setting was final unless the server was restarted with
new configs). It could be useful to turn a read-replica into a primary cluster.
> Add a Global Read-Only property to turn off all writes for the cluster
> ----------------------------------------------------------------------
>
> Key: HBASE-18775
> URL: https://issues.apache.org/jira/browse/HBASE-18775
> Project: HBase
> Issue Type: Sub-task
> Components: master, regionserver
> Affects Versions: HBASE-18477
> Reporter: Zach York
> Assignee: Zach York
> Attachments: HBASE-18775.HBASE-18477.001.patch,
> HBASE-18775.HBASE-18477.002.patch, HBASE-18775.HBASE-18477.003.patch,
> HBASE-18775.HBASE-18477.004.patch
>
>
> As part of HBASE-18477, we need a way to turn off all modification for a
> cluster. This patch extends the read only mode used by replication to disable
> all data and metadata operations.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
