[
https://issues.apache.org/jira/browse/HBASE-11393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15019182#comment-15019182
]
Enis Soztutar commented on HBASE-11393:
---------------------------------------
For the client API, we can remove it in 2.0. However, we still have to figure
out a way for keeping the data in zookeeper rolling upgradable. For branch-1,
we can do something like this:
- Master startup checks all the peer tableCF data, and writes that data to
ReplicationPeerConfiguration znode. This will auto-migrate existing data.
- The client API calls for changing peer tableCF data changes both the
ReplicationPeerConfiguration and the deprecated tableCF znode in string format.
- New Regionservers only read from ReplicationPeerConfiguration znode.
- Old regionservers during rolling upgrade can read from the old tableCF
znode. In this case, if a table with namespace was added, the replication might
not work. But once the upgrade is complete, replication will be fixed.
- In 2.0, we only read and write from the RPC znode.
> Replication TableCfs should be a PB object rather than a string
> ---------------------------------------------------------------
>
> Key: HBASE-11393
> URL: https://issues.apache.org/jira/browse/HBASE-11393
> Project: HBase
> Issue Type: Sub-task
> Reporter: Enis Soztutar
> Fix For: 2.0.0
>
> Attachments: HBASE-11393.patch, HBASE-11393_v1.patch,
> HBASE-11393_v10.patch, HBASE-11393_v2.patch, HBASE-11393_v3.patch,
> HBASE-11393_v4.patch, HBASE-11393_v5.patch, HBASE-11393_v6.patch,
> HBASE-11393_v7.patch, HBASE-11393_v8.patch, HBASE-11393_v9.patch
>
>
> We concatenate the list of tables and column families in format
> "table1:cf1,cf2;table2:cfA,cfB" in zookeeper for table-cf to replication peer
> mapping.
> This results in ugly parsing code. We should do this a PB object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
