You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "maoling (JIRA)" <ji...@apache.org> on 2019/08/08 06:43:00 UTC

[jira] [Updated] (ZOOKEEPER-3318) [CLI way]Add a complete backup mechanism for zookeeper internal

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

maoling updated ZOOKEEPER-3318:
-------------------------------
    Summary: [CLI way]Add a complete backup mechanism for zookeeper internal  (was: Add a complete backup mechanism for zookeeper internal)

> [CLI way]Add a complete backup mechanism for zookeeper internal
> ---------------------------------------------------------------
>
>                 Key: ZOOKEEPER-3318
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3318
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: other
>            Reporter: maoling
>            Assignee: maoling
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> 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.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)