You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Romain HARDOUIN <ro...@urssaf.fr> on 2012/08/02 09:16:08 UTC
RE Restore snapshot
No it's not possible
"Desimpel, Ignace" <Ig...@nuance.com> a écrit sur 01/08/2012
14:58:49 :
> Hi,
>
> Is it possible to restore a snapshot of a keyspace on a live
> cassandra cluster (I mean without restarting)?
>
Re: RE Restore snapshot
Posted by Tyler Hobbs <ty...@datastax.com>.
On Thu, Aug 2, 2012 at 6:14 AM, Romain HARDOUIN
<ro...@urssaf.fr>wrote:
>
> Then http://www.datastax.com/docs/1.1/operations/backup_restore should
> mention it :-)
I opened a ticket with our docs team to cover that. Thanks!
--
Tyler Hobbs
DataStax <http://datastax.com/>
Re: RE Restore snapshot
Posted by Jonathan Ellis <jb...@gmail.com>.
Yes.
On Thu, Aug 2, 2012 at 5:33 AM, Radim Kolar <hs...@filez.com> wrote:
>
>> 1) I assume that I have to call the loadNewSSTables() on each node?
>
> this is same as "nodetool refresh?"
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: RE Restore snapshot
Posted by Radim Kolar <hs...@filez.com>.
> 1) I assume that I have to call the loadNewSSTables() on each node?
this is same as "nodetool refresh?"
RE: RE Restore snapshot
Posted by "Desimpel, Ignace" <Ig...@nuance.com>.
Great! I will use the hardlinks to 'restore' the data files on each node (super fast)!
I have some related questions :
1) I assume that I have to call the loadNewSSTables() on each node?
2) To be on the save side, I guess I better drop the existing keyspace and then recreate using the definition at the time of the snapshot. But is it allowed the copy the 'old' data files after that with respect to new internal ids versus ids maintained (if any) in the data files?
3) A quick look at the code (took 1.0.5), is it possible that the Table.open is also calling the initCaches on the CFs, but the loadNewSSTables is not?
4) As a solution to 3) : I'm working with embedded Cassandra servers, so I think it would be possible for me to do the following
*Drop KS x if present
*Create KS x from old definition
*On each node :
*** Table.clear(x)
*** Delete any remaining files in the directory x
*** Restore data files from snapshot for KS x
*** Table.open(x);
-----Original Message-----
From: Sylvain Lebresne [mailto:sylvain@datastax.com]
Sent: donderdag 2 augustus 2012 11:46
To: user@cassandra.apache.org
Subject: Re: RE Restore snapshot
Actually that's wrong, it is perfectly possible to restore a snapshot on a live cassandra cluster.
There is even basically 2 solutions:
1) use the sstableloader (http://www.datastax.com/dev/blog/bulk-loading)
2) copy the snapshot sstable in the right place and call the JMX method loadNewSSTables() (in the column family MBean, which mean you need to do that per-CF).
--
Sylvain
On Thu, Aug 2, 2012 at 9:16 AM, Romain HARDOUIN <ro...@urssaf.fr> wrote:
>
> No it's not possible
>
> "Desimpel, Ignace" <Ig...@nuance.com> a écrit sur 01/08/2012
> 14:58:49 :
>
>> Hi,
>>
>> Is it possible to restore a snapshot of a keyspace on a live
>> cassandra cluster (I mean without restarting)?
>>
RE: RE Restore snapshot
Posted by md...@orange.com.
De : mdione.ext@orange.com [mailto:mdione.ext@orange.com]
> > De : Sylvain Lebresne [mailto:sylvain@datastax.com]
> > > 2) copy the snapshot sstable in the right place and call the JMX
> > > method
> > > loadNewSSTables() (in the column family MBean, which mean you need
> > > to do that per-CF).
> >
> > How does this affect the contents of the CommitLogs? I mean, I
> > imagine using this for rollback'ing errors in the app side, like
> > some/many/all objects deleted. How will updates/deletes saved in
> > CommitLogs impact the data restored this way? Also: while I'm
> > restoring a KS of CF, is it possible to cut write requests but not
> > reads? I hope I'm explaining myself clearly...
>
> In particular, I'm thinking on a restore like this:
>
> * the app does something stupid.
> * (if possible) I stop writes to the KS or CF.
> * remove the db files with the wrong data.
> * I put the db files from the restore.
> * nodetool refresh
> * profit!
> [...]
> * and here's the error at repair time:
>
> root@pnscassandra04:~# nodetool repair one_cf cf_1
>
> INFO [RMI TCP Connection(56)-10.234.169.244] 2012-08-10 17:03:12,354
> StorageService.java (line 1925) Starting repair command #3, repairing 5
> ranges.
> INFO [AntiEntropySessions:5] 2012-08-10 17:03:12,358
> AntiEntropyService.java (line 666) [repair #811be330-e2fc-11e1-0000-
> b64817724cbd] new session: will sync
> pnscassandra04.vdev.bas.s1.p.fti.net/10.234.169.244, /10.234.169.245,
> /10.234.169.241, /10.234.169.242, /10.234.169.243 on range
> (34028236692093846346337460743176821145,6805647338418769269267492148635
> 3642291] for one_cf.[cf_1] INFO [AntiEntropySessions:5] 2012-08-10
> 17:03:12,359 AntiEntropyService.java (line 871) [repair #811be330-e2fc-
> 11e1-0000-b64817724cbd] requesting merkle trees for cf_1 (to
> [/10.234.169.245, /10.234.169.241, /10.234.169.242, /10.234.169.243,
> pnscassandra04.vdev.bas.s1.p.fti.net/10.234.169.244])
> ERROR [ValidationExecutor:2] 2012-08-10 17:03:12,361
> AbstractCassandraDaemon.java (line 134) Exception in thread
> Thread[ValidationExecutor:2,1,main]
> java.io.IOError: java.io.FileNotFoundException:
> /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-13-
> Data.db (No such file or directory) [...]
>
> I understand that this procedure (refresh+repair in one node) makes
> absolutely no sense, but the error leads me to think that after
> refresh, the 'wrong' databases are still taken in account. Is it that
> the whole procedure is bad from the start and I should use
> SSTableLoader instead?
Ok, I just did the refresh without the repair on all the nodes at the
same time, and the error is still there. Should I drop the CF or KS before
doing this kind of restore?
--
Marcos Dione
SysAdmin
Astek Sud-Est
pour FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo
04 97 12 62 45 - mdione.ext@orange.com
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
RE: RE Restore snapshot
Posted by md...@orange.com.
De : mdione.ext@orange.com [mailto:mdione.ext@orange.com]
> In particular, I'm thinking on a restore like this:
>
> * the app does something stupid.
> * (if possible) I stop writes to the KS or CF.
In fact, given that I'm about to restore the KS/CF to an old state, I can safely do this:
* drop and restore the schema.
> * remove the db files with the wrong data.
> * I put the db files from the restore.
> * nodetool refresh
> * profit!
This works perfectly.
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
RE: RE Restore snapshot
Posted by md...@orange.com.
> De : Sylvain Lebresne [mailto:sylvain@datastax.com]
> > 2) copy the snapshot sstable in the right place and call the JMX
> > method
> > loadNewSSTables() (in the column family MBean, which mean you need to
> > do that per-CF).
>
> How does this affect the contents of the CommitLogs? I mean, I
> imagine using this for rollback'ing errors in the app side, like
> some/many/all objects deleted. How will updates/deletes saved in
> CommitLogs impact the data restored this way? Also: while I'm restoring
> a KS of CF, is it possible to cut write requests but not reads? I hope
> I'm explaining myself clearly...
In particular, I'm thinking on a restore like this:
* the app does something stupid.
* (if possible) I stop writes to the KS or CF.
* remove the db files with the wrong data.
* I put the db files from the restore.
* nodetool refresh
* profit!
But on Friday I did it slightly different (too tired, I was confused),
and only did the refresh on one node and then a repair on the same, and
it failed like this:
* state just after the app did something stupid:
root@pnscassandra04:~# tree /var/opt/hosting/db/cassandra/data/one_cf/cf_1/
/var/opt/hosting/db/cassandra/data/one_cf/cf_1/
|-- one_cf-cf_1-hd-13-CompressionInfo.db
|-- one_cf-cf_1-hd-13-Data.db
|-- one_cf-cf_1-hd-13-Filter.db
|-- one_cf-cf_1-hd-13-Index.db
|-- one_cf-cf_1-hd-13-Statistics.db
|-- one_cf-cf_1-hd-14-CompressionInfo.db
|-- one_cf-cf_1-hd-14-Data.db
|-- one_cf-cf_1-hd-14-Filter.db
|-- one_cf-cf_1-hd-14-Index.db
|-- one_cf-cf_1-hd-14-Statistics.db
|-- one_cf-cf_1-hd-15-CompressionInfo.db
|-- one_cf-cf_1-hd-15-Data.db
|-- one_cf-cf_1-hd-15-Filter.db
|-- one_cf-cf_1-hd-15-Index.db
|-- one_cf-cf_1-hd-15-Statistics.db
`-- snapshots
`-- 1344609231532
|-- one_cf-cf_1-hd-10-CompressionInfo.db
|-- one_cf-cf_1-hd-10-Data.db
|-- one_cf-cf_1-hd-10-Filter.db
|-- one_cf-cf_1-hd-10-Index.db
|-- one_cf-cf_1-hd-10-Statistics.db
|-- one_cf-cf_1-hd-11-CompressionInfo.db
|-- one_cf-cf_1-hd-11-Data.db
|-- one_cf-cf_1-hd-11-Filter.db
|-- one_cf-cf_1-hd-11-Index.db
|-- one_cf-cf_1-hd-11-Statistics.db
|-- one_cf-cf_1-hd-12-CompressionInfo.db
|-- one_cf-cf_1-hd-12-Data.db
|-- one_cf-cf_1-hd-12-Filter.db
|-- one_cf-cf_1-hd-12-Index.db
|-- one_cf-cf_1-hd-12-Statistics.db
|-- one_cf-cf_1-hd-9-CompressionInfo.db
|-- one_cf-cf_1-hd-9-Data.db
|-- one_cf-cf_1-hd-9-Filter.db
|-- one_cf-cf_1-hd-9-Index.db
`-- one_cf-cf_1-hd-9-Statistics.db
* I remove the 'wrong' databases
root@pnscassandra04:~# rm -v /var/opt/hosting/db/cassandra/data/one_cf/cf_1/*.db
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-13-CompressionInfo.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-13-Data.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-13-Filter.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-13-Index.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-13-Statistics.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-14-CompressionInfo.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-14-Data.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-14-Filter.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-14-Index.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-14-Statistics.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-15-CompressionInfo.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-15-Data.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-15-Filter.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-15-Index.db'
removed `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-15-Statistics.db'
* restore
root@pnscassandra04:~# for i in /var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/*; do
ln -v $i /var/opt/hosting/db/cassandra/data/one_cf/cf_1/;
done
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-10-CompressionInfo.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-10-CompressionInfo.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-10-Data.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-10-Data.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-10-Filter.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-10-Filter.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-10-Index.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-10-Index.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-10-Statistics.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-10-Statistics.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-11-CompressionInfo.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-11-CompressionInfo.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-11-Data.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-11-Data.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-11-Filter.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-11-Filter.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-11-Index.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-11-Index.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-11-Statistics.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-11-Statistics.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-12-CompressionInfo.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-12-CompressionInfo.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-12-Data.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-12-Data.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-12-Filter.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-12-Filter.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-12-Index.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-12-Index.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-12-Statistics.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-12-Statistics.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-9-CompressionInfo.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-9-CompressionInfo.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-9-Data.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-9-Data.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-9-Filter.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-9-Filter.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-9-Index.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-9-Index.db'
`/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-9-Statistics.db' => `/var/opt/hosting/db/cassandra/data/one_cf/cf_1/snapshots/1344609231532/one_cf-cf_1-hd-9-Statistics.db'
* and refresh
root@pnscassandra04:~# nodetool refresh one_cf cf_1
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,426 ColumnFamilyStore.java (line 460) Loading new SSTables for one_cf/cf_1...
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,432 ColumnFamilyStore.java (line 488) Renaming new SSTable /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-9 to /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-16
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,432 SSTableReader.java (line 170) Opening /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-16 (2263898 bytes)
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,488 ColumnFamilyStore.java (line 488) Renaming new SSTable /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-11 to /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-17
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,489 SSTableReader.java (line 170) Opening /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-17 (2124847 bytes)
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,517 ColumnFamilyStore.java (line 488) Renaming new SSTable /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-10 to /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-18
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,517 SSTableReader.java (line 170) Opening /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-18 (2526508 bytes)
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,551 ColumnFamilyStore.java (line 488) Renaming new SSTable /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-12 to /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-19
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,551 SSTableReader.java (line 170) Opening /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-19 (146340 bytes)
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,555 ColumnFamilyStore.java (line 510) Loading new SSTables and building secondary indexes for one_cf/cf_1: [SSTableReader(path='/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-17-Data.db'), SSTableReader(path='/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-19-Data.db'), SSTableReader(path='/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-16-Data.db'), SSTableReader(path='/var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-18-Data.db')]
INFO [RMI TCP Connection(54)-10.234.169.244] 2012-08-10 17:00:54,555 ColumnFamilyStore.java (line 526) Done loading load new SSTables for one_cf/cf_1
* and here's the error at repair time:
root@pnscassandra04:~# nodetool repair one_cf cf_1
INFO [RMI TCP Connection(56)-10.234.169.244] 2012-08-10 17:03:12,354 StorageService.java (line 1925) Starting repair command #3, repairing 5 ranges.
INFO [AntiEntropySessions:5] 2012-08-10 17:03:12,358 AntiEntropyService.java (line 666) [repair #811be330-e2fc-11e1-0000-b64817724cbd] new session: will sync pnscassandra04.vdev.bas.s1.p.fti.net/10.234.169.244, /10.234.169.245, /10.234.169.241, /10.234.169.242, /10.234.169.243 on range (34028236692093846346337460743176821145,68056473384187692692674921486353642291] for one_cf.[cf_1]
INFO [AntiEntropySessions:5] 2012-08-10 17:03:12,359 AntiEntropyService.java (line 871) [repair #811be330-e2fc-11e1-0000-b64817724cbd] requesting merkle trees for cf_1 (to [/10.234.169.245, /10.234.169.241, /10.234.169.242, /10.234.169.243, pnscassandra04.vdev.bas.s1.p.fti.net/10.234.169.244])
ERROR [ValidationExecutor:2] 2012-08-10 17:03:12,361 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[ValidationExecutor:2,1,main]
java.io.IOError: java.io.FileNotFoundException: /var/opt/hosting/db/cassandra/data/one_cf/cf_1/one_cf-cf_1-hd-13-Data.db (No such file or directory)
[...]
I understand that this procedure (refresh+repair in one node) makes absolutely
no sense, but the error leads me to think that after refresh, the 'wrong' databases
are still taken in account. Is it that the whole procedure is bad from the start and
I should use SSTableLoader instead?
--
Marcos Dione
SysAdmin
Astek Sud-Est
pour FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo
04 97 12 62 45 - mdione.ext@orange.com
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
RE: RE Restore snapshot
Posted by md...@orange.com.
De : Sylvain Lebresne [mailto:sylvain@datastax.com]
> 2) copy the snapshot sstable in the right place and call the JMX method
> loadNewSSTables() (in the column family MBean, which mean you need to
> do that per-CF).
How does this affect the contents of the CommitLogs? I mean,
I imagine using this for rollback'ing errors in the app side, like
some/many/all objects deleted. How will updates/deletes saved in
CommitLogs impact the data restored this way? Also: while I'm
restoring a KS of CF, is it possible to cut write requests but
not reads? I hope I'm explaining myself clearly...
--
Marcos Dione
SysAdmin
Astek Sud-Est
pour FT/TGPF/OPF/PORTAIL/DOP/HEBEX @ Marco Polo
04 97 12 62 45 - mdione.ext@orange.com
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
Re: RE Restore snapshot
Posted by Romain HARDOUIN <ro...@urssaf.fr>.
Then http://www.datastax.com/docs/1.1/operations/backup_restore should
mention it :-)
Sylvain Lebresne <sy...@datastax.com> a écrit sur 02/08/2012 11:45:46 :
> Actually that's wrong, it is perfectly possible to restore a snapshot
> on a live cassandra cluster.
> There is even basically 2 solutions:
> 1) use the sstableloader (http://www.datastax.com/dev/blog/bulk-loading)
> 2) copy the snapshot sstable in the right place and call the JMX
> method loadNewSSTables() (in the column family MBean, which mean you
> need to do that per-CF).
>
> --
> Sylvain
Re: RE Restore snapshot
Posted by Sylvain Lebresne <sy...@datastax.com>.
Actually that's wrong, it is perfectly possible to restore a snapshot
on a live cassandra cluster.
There is even basically 2 solutions:
1) use the sstableloader (http://www.datastax.com/dev/blog/bulk-loading)
2) copy the snapshot sstable in the right place and call the JMX
method loadNewSSTables() (in the column family MBean, which mean you
need to do that per-CF).
--
Sylvain
On Thu, Aug 2, 2012 at 9:16 AM, Romain HARDOUIN
<ro...@urssaf.fr> wrote:
>
> No it's not possible
>
> "Desimpel, Ignace" <Ig...@nuance.com> a écrit sur 01/08/2012
> 14:58:49 :
>
>> Hi,
>>
>> Is it possible to restore a snapshot of a keyspace on a live
>> cassandra cluster (I mean without restarting)?
>>