[
https://issues.apache.org/jira/browse/HBASE-21201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760023#comment-16760023
]
Josh Elser commented on HBASE-21201:
------------------------------------
{quote}if we don't satisfy the assert condition (this.peerQuorumAddress !=
null), that's a bug. I usually use "assert" when I want to check an internal
logic, and use an Exception when checking arguments or something outside. What
do you think? we don't need it?
{quote}
I see. I was thinking that this could happen via user-input. I'm OK if you want
to restore that assert on commit.
The only other thing I'm noticing is that we could stand to benefit from a UT
that validates we expect at least two options. Not something you have to add
here, but if you're looking to do some more clean-up here (checkstyle fixing),
that'd be a nice addition to also make ;)
+1 to commit v2
> Support to run VerifyReplication MR tool without peerid
> -------------------------------------------------------
>
> Key: HBASE-21201
> URL: https://issues.apache.org/jira/browse/HBASE-21201
> Project: HBase
> Issue Type: Improvement
> Components: hbase-operator-tools
> Affects Versions: 3.0.0, 2.2.0
> Reporter: Sujit P
> Assignee: Toshihiro Suzuki
> Priority: Major
> Attachments: HBASE-21201.master.001.patch,
> HBASE-21201.master.002.patch
>
>
> In some use cases, hbase clients writes to separate clusters(probably
> different datacenters) tables for redundancy. As an administrator/application
> architect, I would like to find out if both cluster tables are in the same
> state (cell by cell). One of the tools that is readily available to use is
> VerifyRep which is part of replication.
> However, it requires peerId to be setup on atleast of the involved cluster.
> PeerId is unnecessary in this use-case scenario and possibly cause unintended
> consequences as the clusters aren't really replication peers neither do We
> prefer them to be.
> Looking at the code:
> Tool attempts to get only the clusterKey which is essentially ZooKeeper
> quorum url
>
> {code:java}
> //VerifyReplication.java
> private static Pair<ReplicationPeerConfig, Configuration>
> getPeerQuorumConfig(final Configuration conf, String peerId)
> .
> .
> return Pair.newPair(peerConfig,
> ReplicationUtils.getPeerClusterConfiguration(peerConfig, conf));
> //ReplicationUtils.java
> public static Configuration getPeerClusterConfiguration(ReplicationPeerConfig
> peerConfig, Configuration baseConf) throws ReplicationException {
> Configuration otherConf;
> try {
> otherConf = HBaseConfiguration.createClusterConf(baseConf,
> peerConfig.getClusterKey());{code}
>
>
> So I would like to propose to update the tool to pass the remote cluster
> ZkQuorum as an argument (ex. --peerQuorumAddress
> clusterBzk1,clusterBzk2,clusterBzk3:2181/hbase-secure ) and use it
> effectively without dependence on replication peerId, similar to
> peerFSAddress. The are certain advantages in doing so as follows:
> * Reduce the development/maintenance of separate tool for above scenario
> * Allow the tool to be more useful for other scenarios as well such as
> ** validating backups in remote cluster HBASE-19106
> ** compare cloned tableA and original tableA in same/remote cluster incase
> of user error before restoring snapshot to original table to find the records
> that need to be added/invalid/missing etc
> ** Allow backup operators who are non-Hbase admins(who shouldn't be adding
> the peerId) to run the tool, since currently only Hbase superuser can add a
> peerId for reasons discussed in HBASE-21163.
> Please post your comments
> Thanks
> cc: [~clayb], [~brfrn169] , [~vrodionov] , [~rashidaligee]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
