[ 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)