[
https://issues.apache.org/jira/browse/HBASE-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13734502#comment-13734502
]
Himanshu Vashishtha commented on HBASE-9141:
--------------------------------------------
I think you raised some good questions.
bq. It might be good to not put the znodes in place right away,
The intended use of this tool is to do a backup of znodes, and restore them.
IMHO, they are two separate commands (like along the lines of taking snapshot
of a table, and then cloning a snapshot, etc). If we use -backup and -restore
options separately, we don't have to do in place replacement. While restoring,
you could define any arbitrary znode as the would-be-parent znode and the
replication znodes would be restored under that znode (please refer to the move
section).
bq. so create them elsewhere and then move them in place all at once?
The main concern is what happens when we fail in b/w restoring. We don't want
to do any guessing about our last-failed-restore command (what happens if it
fails in b/w? do we have incomplete znodes, etc?). 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. Otherwise, if we truly want to be
atomic while restoring, I think, we could make use of ZK multi api.
Let me know if that is what you were thinking about. Thanks.
> 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
