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 <synfina...@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 > <schellap2...@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 ? >
