incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Sutton <ray.sut...@gmail.com>
Subject Re: Backup strategy
Date Wed, 06 Nov 2013 01:19:19 GMT
I don't understand how the creation of a snapshot causes any load
whatsoever. By definition, a snapshot is a hard link of an existing
SSTable. The SSTable is not being physically copied so there is no disk
I/O, it's just a reference to an inode.

--
Ray  //o-o\\



On Tue, Nov 5, 2013 at 8:09 PM, Aaron Turner <synfinatic@gmail.com> wrote:

> Why not just have a small DC/ring of nodes which you just do your
> snapshots/backups from?
>
> I wouldn't take nodes offline from the ring just to back them up.
>
> The other option is to add sufficient nodes to handle your existing
> request I/O + backups.  Sounds like you might be already I/O
> constrained.
> --
> Aaron Turner
> http://synfin.net/         Twitter: @synfinatic
> https://github.com/synfinatic/tcpreplay - Pcap editing and replay
> tools for Unix & Windows
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety.
>     -- Benjamin Franklin
>
>
> On Tue, Nov 5, 2013 at 4:36 PM, Sridhar Chellappa
> <schellap2009@gmail.com> wrote:
> > We are running into problems where Backup jobs are taking away a huge
> > bandwidth out of the C* nodes. While we can schedule a particular timing
> > window for backups alone, the request pattern is so random; there is no
> > particular time where we can schedule backups, periodically.
> >
> > My current thinking is to run backups against a replica that does not
> serve
> > requests. Questions:
> >
> > Is it the right strategy?
> > if it is - how do I pull a replica out from serving requests ?
> > If not, what is the right  backup strategy ?
>

Mime
View raw message