[
https://issues.apache.org/jira/browse/ZOOKEEPER-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459816#comment-17459816
]
Mate Szalay-Beko commented on ZOOKEEPER-4425:
---------------------------------------------
bq. Doesn't a fuzzy snapshot alone allow a node to start up with potential
partial data loss?
normally not, as you run a distributed cluster and all zookeeper servers store
the full state. So you can recover from any other servers if needed. Also, when
a server is "reconnecting" to the quorum (let's say after a crash), the current
leader will sync with the new joiner (sending all the missing transactions)
before the newly joined server would be allowed to serve any request.
bq. due backup and clean-up process mishandling, I assumed no data files
present at all
it is true, if you delete all the snapshots and all the transaction logs from
all the servers, then it might be handy to force a snapshot. Strange scenario
though, fortunately I never saw this on production clusters yet :)
> 4lw Command: On demand snapshot
> -------------------------------
>
> Key: ZOOKEEPER-4425
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4425
> Project: ZooKeeper
> Issue Type: New Feature
> Components: server
> Reporter: Pablo Francisco Pérez Hidalgo
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Working with disaster recovery scenarios at work, we found that having the
> capacity of telling a ZooKeeper instance to take a snapshot, thus dumping
> into files the contents of its view of the internal database, could be a last
> resource hatch out of potential data loss.
> As an example, imagine that all the voting members of the ensemble are wiped
> out due a wrong deployment configuration change. A single surviving observer
> could hold on its memory the last copy of most recently updated the ensemble
> data. Sending it a _*snap*_ *four letter words command* that forced it to
> save a snapshot of that information into disk could be a very convenient way
> of recovering the database.
>
> This issue aims to discuss the addition of this feature and serve as the gate
> for a an already available patch providing this feature.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
