[
https://issues.apache.org/jira/browse/HBASE-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13738877#comment-13738877
]
Jean-Daniel Cryans commented on HBASE-9141:
-------------------------------------------
bq. One way to avoid that is pass -deleteOldZnode option to the restore
command. That would ensure that we delete any previous znode before starting
the restore process. I could make that a default option in restore command.
I'm more concerned if the operator someone messes up and starts the cluster
with like half the znodes.
bq. Otherwise, if we truly want to be atomic while restoring, I think, we could
make use of ZK multi api.
Yes.
> Replication Znodes Backup Tool
> ------------------------------
>
> Key: HBASE-9141
> URL: https://issues.apache.org/jira/browse/HBASE-9141
> Project: HBase
> Issue Type: Improvement
> Components: migration, Replication
> Affects Versions: 0.94.10
> Reporter: Himanshu Vashishtha
> Assignee: Himanshu Vashishtha
> Fix For: 0.95.2
>
> Attachments: HBase-9141.patch, HBase-9141-v1.patch
>
>
> While migrating to 0.96, we recommend deleting old znodes so users not face
> issues like HBASE-7766, and let HBase create them out of box.
> Though HBase tends to store only ephemeral data in zookeeper, replication has
> a different approach. Almost all of its data (state, peer info, logs, etc) is
> present in zookeeper. We would like to preserve them in order to not do
> re-adding of peers, and ensuring complete replication after we have migrated
> to 0.96.
> This jira adds a tool to serialize/de-serialize replication znodes to the
> underlying filesystem. This could be used while migrating to 0.96.0.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
