Done, https://issues.apache.org/jira/browse/CASSANDRA-564
On Thu, Nov 19, 2009 at 01:17:16PM -0600, Jonathan Ellis wrote:
> Currently, no. Feel free to open a ticket. It would be fairly easy
> to make the decommission code in trunk handle this.
>
> On Thu, Nov 19, 2009 at 1:13 PM, Anthony Molin
On Thu, Nov 19, 2009 at 1:18 PM, Freeman, Tim wrote:
> I'm not going to be on Amazon, but I'm planning to use hostnames instead of
> IP's and a dynamically generated /etc/hosts file and I think that would deal
> with this problem. I'm sure a private DNS server would be just as good.
>
> My real
riginal Message-
From: Anthony Molinaro [mailto:antho...@alumni.caltech.edu]
Sent: Thursday, November 19, 2009 11:14 AM
To: cassandra-user@incubator.apache.org
Subject: Re: Cassandra backup and restore procedures
So, is there anyway to recover if you can't guarantee the same IP address?
S
Currently, no. Feel free to open a ticket. It would be fairly easy
to make the decommission code in trunk handle this.
On Thu, Nov 19, 2009 at 1:13 PM, Anthony Molinaro
wrote:
> So, is there anyway to recover if you can't guarantee the same IP address?
> Since we are running on EC2 (as I'm sure
So, is there anyway to recover if you can't guarantee the same IP address?
Since we are running on EC2 (as I'm sure are others on the list), and there
is no way to make this guarantee.
Is this sort of recoverability on the roadmap anywhere?
Thanks,
-Anthony
On Wed, Nov 18, 2009 at 01:50:20PM -0
oh interesting, it uses IP for hinted hand off? which brings up
another interesting question, if the node that went down never came up
again, how long will the hinted handoff keep going? Indefinitely?
On the first topic of backup/restore, you suggested copying the
sstable files over from the 2 nei
No, bootstrap is currently only for adding new nodes, not replacing dead ones.
On Wed, Nov 18, 2009 at 1:47 PM, Simon Smith wrote:
> I'm sorry if this was covered before, but if you lose a node and
> cannot bring it (or a replacement) back with the same IP address or
> DNS name, is your only opti
I'm sorry if this was covered before, but if you lose a node and
cannot bring it (or a replacement) back with the same IP address or
DNS name, is your only option to restart the entire cluster? E.g. if
I have nodes 1, 2, and 3 with replication factor 3, and then I lose
node 3, is it possible to br
On Wed, Nov 18, 2009 at 1:15 PM, Jon Graham wrote:
> Hello Jonathan,
>
> Is the system table information contained in the "system/Location*" files?
Yes
> How do I know which nodes hold the replicated copies when using ordered
> preserving partitioning? Are replicas always stored in neighboring
Hello Jonathan,
Is the system table information contained in the "system/Location*" files?
How do I know which nodes hold the replicated copies when using ordered
preserving partitioning? Are replicas always stored in neighboring nodes?
Are the left (before) and right (after) nodes you mentione
Tokens can change, so IP is used for node identification, e.g. for
hinted handoff.
On Wed, Nov 18, 2009 at 1:00 PM, Ramzi Rabah wrote:
> Hey Jonathan, why should a replacement node keep the same IP
> address/DNS name as the original node? Wouldn't having the same token
> as the node that went dow
Hey Jonathan, why should a replacement node keep the same IP
address/DNS name as the original node? Wouldn't having the same token
as the node that went down be sufficient (provided that you did the
steps above of copying the data from the 2 neighboring nodes)?
On Wed, Nov 18, 2009 at 10:30 AM, Jo
On Wed, Nov 18, 2009 at 12:05 PM, Jon Graham wrote:
> Hello Everyone,
>
> Is there a recommended backup/restore procedure to be able to recover a
> failed node?
Until tickets 193 and 520 are done, the easiest thing is to copy all
the sstables from the other nodes that have replicas for the ranges
13 matches
Mail list logo
