[
https://issues.apache.org/jira/browse/HBASE-18822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757128#comment-16757128
]
Nihal Jain commented on HBASE-18822:
------------------------------------
My approach for the following points:
* Table creation/alter ops are replicated to all its peer irrespective of the
replication state of the peers. It is good behavior wise as it will ensure
things are in sync completely. But, what if the admin disables a peer, do we
still want to sync create table to the peer? Or should we sync to a peer only
if the peer is enabled?
** *APPROACH*: We will sync creation/alter ops for configured table
irrespective of the replication state of the peers, whether peer is ENABLED or
DISABLED.
* Similarly table creation/alter ops are replicated irrespective of the
replication scope. It is good behavior wise as it will ensure things are in
sync completely. But, still we discuss about should we sync to a peer only if
the replication scope is 1?
** *APPROACH*: Sync creation/alter ops for configured table irrespective of
the replication scope of the table.
* If table already exists in peer cluster but with a different descriptor, it
successfully creates table in active cluster. Should we log some warning if
table descriptor is different on the peer?
** *APPROACH*: Log arror and skip table. We also add tablename to fail message
list, which is logged at the end. Admins can check log and do the need ful.
* If we perform the following ops in order:
** (a) Create table in active cluster
** (b) Add peer cluster
** (c) Modify the table created in step a
** *RESULT*: It will get stuck in procedure retry loop (in RUNNABLE STATE) and
will get a TableNotFoundException in each retry. The procedure will never
complete as it think it is a retriable error.
** *APPROACH*: Handles non-existant tables in peer and log the error.
* Table with the same name exists in active and peer cluster; both having
familiy c1. If we alter the table t1 and set version = 5 for family c1 in
active cluster, it will skip modifying table in peer. Because the patch only
handles supporting add column / delete column. Not to alter existing column
families. But by sync don't we mean we want to sync everything? What if the
active goes down with t1:c1:version=5, while the peer which is used for
disaster recovery solution just supports t1:c1:version=1 (i.e. whatever was
descriptor property of the column family while creation)
** *APPROACH*: We also sync table attributes to the peer. It supports all of:
addColumnFamily / modifyColumnFamily / deleteColumnFamily / modifyTable
* Table with the same name exists in active and peer cluster but with families
f1, f2 in active and families c1, c2 in peer cluster. If we alter the table t1
to drop family f1 in active cluster, since the count logic is used (not
descriptor comparison. WHY?), it will replace the existing descriptor of peer
and drop families c1 and c2 (along with data, if any) from peer and add family
f1 to it (as this is the new descriptor in active).
** *APPROACH*: Mismatch in descriptor we will skip modification, we donot
consider replication scope while matching descriptors.
* Table with the same name exists in active and peer cluster but with families
f1, f2 in active and family c1 in peer cluster. If we alter the table t1 to
drop family f1 in active cluster, it will skip modifying table in peer as count
is same. Again, should we log some warning if table descriptor is different on
the peer?
** *APPROACH*: Not using count based logic.
> Create table for peer cluster automatically when creating table in source
> cluster of using namespace replication.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-18822
> URL: https://issues.apache.org/jira/browse/HBASE-18822
> Project: HBase
> Issue Type: Improvement
> Components: Replication
> Affects Versions: 2.0.0-alpha-2
> Reporter: Zheng Hu
> Assignee: Zheng Hu
> Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-18822.master.001.patch, HBASE-18822.v1.patch,
> HBASE-18822.v1.patch
>
>
> In our cluster of using namespace replication, we always forget to create
> table in peer cluster, which lead to replication get stuck.
> We have implemented the feature in our cluster: create table for peer
> cluster automatically when creating table in source cluster of using
> namespace replication.
>
> I'm not sure if someone else needs this feature, so create an issue here for
> discussing
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
