On Thu, Jan 19, 2012 at 11:42 PM, kishore g wrote:
> User error is a valid use case. Are we assuming that because of user error
> the ZK is not usable at this point? if not, can some one please explain how
> having a back up can actually restore the data without bringing all zk
> servers down and
8:07 PM, Jordan Zimmerman wrote:
> >
> > It's that very replication that creates the need for backups. In there
> is
> >> a user error or a bad injection of data, the error will quickly
> replicate
> >> to all the instances. There's no way to r
mistake. Am I getting
> it right?
>
> -Flavio
>
>
> On Jan 19, 2012, at 8:07 PM, Jordan Zimmerman wrote:
>
> It's that very replication that creates the need for backups. In there is
>> a user error or a bad injection of data, the error will quickly replicate
>
Flavio,
Take as a use case the one where I am keeping configuration files in ZK.
These will be manual installed and thus subject to manual error.
Backups would be invaluable.
On Thu, Jan 19, 2012 at 6:39 PM, Flavio Junqueira wrote:
> Hi Ted, Znodes for leader election, group membership,
today.
>
> Patrick
>
> On Thu, Jan 19, 2012 at 10:16 AM, Jordan Zimmerman
> wrote:
> > Ted - are you referring to my original plan to backup the transaction
> logs
> > or the new idea of backing up certain nodes?
> >
> > -JZ
> >
> > On 1/19/12 10:11
M, Jordan Zimmerman wrote:
>
>> It's that very replication that creates the need for backups. In
>> there is
>> a user error or a bad injection of data, the error will quickly
>> replicate
>> to all the instances. There's no way to recover without an external
You're not talking about data corruption, are you? It is incorrect
data that has been introduced by a user or application by mistake. Am
I getting it right?
-Flavio
On Jan 19, 2012, at 8:07 PM, Jordan Zimmerman wrote:
It's that very replication that creates the need for backups.
It's that very replication that creates the need for backups. In there is
a user error or a bad injection of data, the error will quickly replicate
to all the instances. There's no way to recover without an external backup.
-JZ
On 1/19/12 10:39 AM, "Flavio Junqueira" wro
various
file
systems. Traditional NAS vendors all support this. At a lower cost
and
complexity point, you can get this from MapR clusters exposed as NFS
or by
a ZFS file system. This option also allows you to keep multiple
snapshots
from points in the past.
What Jordan is doing woul
n to backup the transaction logs
> or the new idea of backing up certain nodes?
>
> -JZ
>
> On 1/19/12 10:11 AM, "Ted Dunning" wrote:
>
>>What Jordan is doing would allow backups without special storage devices
>>and, with good backup of the log, would allow n
e:
>
> >What Jordan is doing would allow backups without special storage devices
> >and, with good backup of the log, would allow nearly current recovery in
> >the event of catastrophic loss. Yes, this loses some durability, but it
> >is
> >still very desirable.
>
>
Ted - are you referring to my original plan to backup the transaction logs
or the new idea of backing up certain nodes?
-JZ
On 1/19/12 10:11 AM, "Ted Dunning" wrote:
>What Jordan is doing would allow backups without special storage devices
>and, with good backup of the log, wo
exposed as NFS or by
a ZFS file system. This option also allows you to keep multiple snapshots
from points in the past.
What Jordan is doing would allow backups without special storage devices
and, with good backup of the log, would allow nearly current recovery in
the event of catastrophic loss
s used
for locks, leaders, etc. should _not_ be backed up.
I'm going to re-think my backup strategy. One idea is to backup certain
specified ZK Paths (anything used for meta data). These "backups" could be
done by using the ZK API to read the nodes/data and storing it somewhere.
A re
tructed in an algorithmic
manner. Perhaps the use case for a backup would be the one in which it
is being used as a database, for example, to keep the metadata of a
file system. Periodic backups or even keeping an observer, however,
won't guarantee that if you bring the system up us
Neha - can you send me your email address. Send it to:
jzimmer...@netflix.com
On 1/17/12 10:10 AM, "Neha Narkhede" wrote:
>Jordan,
>
>I'd be interested in previewing it. Let me know.
>
>Thanks,
>Neha
>
>On Mon, Jan 16, 2012 at 5:42 PM, Jordan Zimmerman
> wrote:
>> We'll be backing up to S3. Woul
OK - I'll give you access to the repo as soon as it's in a reasonable
state.
On 1/17/12 10:10 AM, "Neha Narkhede" wrote:
>Jordan,
>
>I'd be interested in previewing it. Let me know.
>
>Thanks,
>Neha
>
>On Mon, Jan 16, 2012 at 5:42 PM, Jordan Zimmerman
> wrote:
>> We'll be backing up to S3. Would
Jordan,
I'd be interested in previewing it. Let me know.
Thanks,
Neha
On Mon, Jan 16, 2012 at 5:42 PM, Jordan Zimmerman
wrote:
> We'll be backing up to S3. Wouldn't it be redundant to backup all the
> instances?
>
> -JZ
>
> P.S. I'm working on a ZooKeeper instance manager that will have
> backu
Not all the instances, any instance. Which would be a bit simpler than
having to look for leader then back up only that one.
C
On Mon, Jan 16, 2012 at 8:42 PM, Jordan Zimmerman wrote:
> We'll be backing up to S3. Wouldn't it be redundant to backup all the
> instances?
>
> -JZ
>
> P.S. I'm workin
We'll be backing up to S3. Wouldn't it be redundant to backup all the
instances?
-JZ
P.S. I'm working on a ZooKeeper instance manager that will have
backup/restore and a bunch of other stuff. We'll be open sourcing it. If
anyone is interested in previewing it let me know.
On 1/16/12 5:39 PM, "P
Why would you limit to the leader? Wouldn't backing up any server (as
long as it's active) be sufficient? If you search the list it's been
discussed before, using Observers seemed like a reasonable option as
well.
Patrick
On Fri, Jan 13, 2012 at 2:29 PM, Jordan Zimmerman
wrote:
> That's easy as
That's easy as the backup app is running on the same machine as the ZK
instance. I can use 'stat' to see if "my" instance is the leader.
On 1/13/12 2:28 PM, "Camille Fournier" wrote:
>You want to have to figure out who the leader is every time you want to
>take a backup? That would be the downsi
You want to have to figure out who the leader is every time you want to
take a backup? That would be the downside to this strategy I would think.
C
>From my phone
On Jan 13, 2012 5:24 PM, "Jordan Zimmerman" wrote:
> As a backup strategy, it seems I would only want to backup snapshots from
> the
As a backup strategy, it seems I would only want to backup snapshots from
the leader. Does that make sense?
-JZ
24 matches
Mail list logo
