On Mon, Dec 1, 2014 at 8:39 PM, Robert Coli wrote:
> Why not use the much more robustly designed and maintained community based
> project, tablesnap?
For two reasons:
- Because I am tired of the deployment model of Python apps which
require me to set up virtual environments.
- Because
On Thu, Nov 27, 2014 at 2:34 AM, Jens Rantil wrote:
> Late answer; You can find my backup script here:
> https://gist.github.com/JensRantil/a8150e998250edfcd1a3
>
Why not use the much more robustly designed and maintained community based
project, tablesnap?
https://github.com/JeremyGrosser/tabl
Late answer; You can find my backup script here:
https://gist.github.com/JensRantil/a8150e998250edfcd1a3
Basically you need to set S3_BUCKET, PGP_KEY_RECIPIENT, configure s3cmd (using
s3cmd --configure) and then issue `./backup-keyspace.sh your-keyspace` to
backup it to S3. We run the script i
D-5 and D
o bring the cluster online
Do you think it would work?
From: Jens Rantil [mailto:jens.ran...@tink.se]
Sent: mardi 25 novembre 2014 10:03
To: user@cassandra.apache.org
Subject: Re: Cassandra backup via snapshots in production
> Truncate does trigger snapshot creation though
Does
> Truncate does trigger snapshot creation though
Doesn’t it? With “auto_snapshot: true” it should.
———
Jens Rantil
Backend engineer
Tink AB
Email: jens.ran...@tink.se
Phone: +46 708 84 18 32
Web: www.tink.se
Facebook Linkedin Twitter
On Tue, Nov 25, 2014 at 9:21 AM, DuyHai Doan wrote:
True
Delete in CQL just create tombstone so from the storage engine pov it's
just adding some physical columns
Truncate does trigger snapshot creation though
Le 21 nov. 2014 19:29, "Robert Coli" a écrit :
> On Fri, Nov 21, 2014 at 8:40 AM, Jens Rantil wrote:
>
>> > The main purpose is to prote
On Fri, Nov 21, 2014 at 8:40 AM, Jens Rantil wrote:
> > The main purpose is to protect us from human errors (eg. unexpected
> manipulations: delete, drop tables, …).
>
> If that is the main purpose, having "auto_snapshot: true” in
> cassandra.yaml will be enough to protect you.
>
OP includes "de
> The main purpose is to protect us from human errors (eg. unexpected
> manipulations: delete, drop tables, …).
If that is the main purpose, having "auto_snapshot: true” in cassandra.yaml
will be enough to protect you.
Regarding backup, I have a small script that creates a named snapshot
On Tue, Nov 18, 2014 at 6:50 AM, Ngoc Minh VO
wrote:
> We are looking for a solution to backup data in our C* cluster (v2.0.x,
> 16 nodes, 4 x 500GB SSD, RF = 6 over 2 datacenters).
>
> The main purpose is to protect us from human errors (eg. unexpected
> manipulations: delete, drop tables, …).
Hello all,
We are looking for a solution to backup data in our C* cluster (v2.0.x, 16
nodes, 4 x 500GB SSD, RF = 6 over 2 datacenters).
The main purpose is to protect us from human errors (eg. unexpected
manipulations: delete, drop tables, …).
We are thinking of:
- Backup: add a 2TB H
10 matches
Mail list logo