No - they'll hardlink into the snapshot folder on each data directory. They
are true hardlinks, so even if you could move it, it'd still be on the same
filesystem.
Typical behavior is to issue a snapshot, and then copy the data out as
needed (using something like https://github.com/JeremyGrosser/t
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, …).
On Fri, Dec 6, 2013 at 5:13 AM, Marcelo Elias Del Valle <
marc...@s1mbi0se.com.br> wrote:
> I am trying to create backups of my data on AWS. My goal is to store
> the backups on S3 or glacier, as it's cheap to store this kind of data. So,
> if I have a cluster with N nodes, I would like to cop
I believe SSTables are written to a temporary file then moved. If I
remember correctly, tools like tablesnap listen for the inotify event
IN_MOVED_TO. This should handle the "try to back up sstable while in
mid-write" issue.
On Fri, Dec 6, 2013 at 5:39 AM, Michael Theroux wrote:
> Hi Marcelo,
You should look at this - https://github.com/amorton/cassback i dont
believe its setup to use 1.2.10 and above but i believe is just small
tweeks to get it running.
Thanks
Rahul
On Fri, Dec 6, 2013 at 7:09 PM, Michael Theroux wrote:
> Hi Marcelo,
>
> Cassandra provides and eventually consisten
Hi Marcelo,
Cassandra provides and eventually consistent model for backups. You can do
staggered backups of data, with the idea that if you restore a node, and then
do a repair, your data will be once again consistent. Cassandra will not
automatically copy the data to other nodes (other than
a to be on SSD and the rest to be on the HDD, how will that
> work.
>
> From: Michael Kjellman [mailto:mkjell...@barracuda.com]
> Sent: 18 February 2013 20:08
> To: user@cassandra.apache.org
> Subject: Re: Cassandra backup
>
> There is this:
>
> http://www.datas
@cassandra.apache.org
Subject: Re: Cassandra backup
There is this:
http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-1-flexible-data-file-placement
But you'll need to design your data model around the fact that this is only as
granular as 1 column family
Best,
michael
From: Kanwar S
There is this:
http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-1-flexible-data-file-placement
But you'll need to design your data model around the fact that this is only as
granular as 1 column family
Best,
michael
From: Kanwar Sangha mailto:kan...@mavenir.com>>
Reply-To: "user@cassa
The incremental backups are generated when the flush is complete (Only
during the flush), If the node crash before the flush completes then the
commit logs in the local node's backup for the data in memory.
It wouldn't help to copy the Commit log across because they are not
immutable (They are recy
Many thanks Aaron. I will post a support issue for them. But will keep the
snapshot + incremental backups + commitlogs to recover any failure
situation.
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Cassandra-backup-queston-regarding-commitlogs-
If you delete the commit logs you are rolling back to exactly what was in the
snapshot. When you take a snapshot it flushes the memtables first, so there is
nothing in the commit log that is not in the snapshot. Rolling back to a
snapshot is rollback to that point in time.
If you want to resto
http://www.datastax.com/docs/1.0/operations/backup_restore
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Cassandra-backup-queston-regarding-commitlogs-tp7508823p7515679.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive
Can you provide a link to that page ?
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 1/05/2012, at 10:12 AM, Roshan wrote:
> Many Thanks Aaron.
>
> According to the datastax restore documentation, they ask to remove the
> commitlogs befor
Many Thanks Aaron.
According to the datastax restore documentation, they ask to remove the
commitlogs before restoring (Clear all files the
/var/lib/cassandra/commitlog (by default)).
In that case better not to follow this step in a server rash situation.
Thanks
/Roshan
--
View this message
When the server starts it reads the SSTables then applies the Commit Logs.
There is nothing you need to do other than leave the commit logs where they
are.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 30/04/2012, at 6:02 PM, Roshan wr
Hi Aaron
Thanks for the comments. Yes for the durability will keep them in a safe
place. But such crash situation, how can I restore the data (because those
are not in a SSTable and only in commit log).
Do I need to replay only that commit log when server starts after crash?
Will it override the
> 1. If I already have a Cassandra cluster running, would changing the
> incremental_backups parameter in the cassandra.yaml of each node, and then
> restart it do the trick?
Yes it is a per node setting.
> 2. Assuming I am creating a daily snapshot, what is the gain from setting
> incrementa
Each mutation is applied to the commit log before being applied to the
memtable. On server start the SSTables are read before replaying the commit
logs. This is part of the crash only software design and happens for every
start.
AFAIk there is no facility to snapshot commit log files as they ar
Tamar
Please don't jump to other users discussions. If you want to ask any issue,
create a new one, please.
Thanks.
--
View this message in context:
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Cassandra-backup-question-regarding-commitlogs-tp7508823p7511913.html
Sent from
I want to add a couple of questions regrading incremental backups:
1. If I already have a Cassandra cluster running, would changing the i
ncremental_backups parameter in the cassandra.yaml of each node, and then
restart it do the trick?
2. Assuming I am creating a daily snapshot, what is the gain
29 matches
Mail list logo
