Details
-
New Feature
-
Status: In Progress
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
We already had some workaround ways for the backup, e.g:
scenario 1: just write a cron shell to copy the snapshots periodically.
scenario 2: use the observer as the role of backup, then write the snapshots to distributed file system. (e.g HDFS)
this issue is aiming to implement a complete backup mechanism for zookeeper internal:
the init propose:
1. for realtime backup.
write a new CLI:snapshot
1.1
[zk: 127.0.0.1:2180(CONNECTED) 0] snapshot backupDataDir
[zk: 127.0.0.1:2180(CONNECTED) 1] snapshot
***************************************************************************************************************
1.2
if no parameter, the default backupDataDir is the dataDir. the format of the backup-snapshot is just like: snapshot.f9f800002834 which is the same as the original one.
when recovering,moving the snapshot.f9f800002834 to the dataDir, then restart the ensemble.
1.3
don't worry about exposing the takeSnap() api to the client.Look at this two references:
https://github.com/etcd-io/etcd/blob/master/clientv3/snapshot/v3_snapshot.go
https://github.com/xetorthio/jedis/blob/master/src/main/java/redis/clients/jedis/commands/BasicCommands.java#L68
2. for no-realtime backup.
2.1
write a new tool/shell: zkBackup.sh which is the reverse proces of the zkCleanup.sh for no-realtime backup.
Attachments
Issue Links
- relates to
-
ZOOKEEPER-3499 [admin server way] Add a complete backup mechanism for zookeeper internal
- In Progress
- links to