To elaborate:
If you manage to screw things up to where it thinks a node has data,
but it does not (adding a node without bootstrap would do this, for
instance, which is probably what you did), at most data in the token
range assigned to that node will be affected.
On Tue, Jun 1, 2010 at 12:45
Depending on the key, the request would have been proxied to the first
or second node.
The CLI uses a consistency level of ONE, meaning that only a single
node's data would have been considered when you get().
Also, the responsible nodes for a given key are mapped accordingly at
request time, and
I am trying to get a cluster up and working for the first time.
I got one server up and running, with lots of data on it, which I can see
with the CLI.
I added my 2nd server, they seem to recognize each other.
Now I can't see my data with the CLI. I do a get and it returns null. The
data files
OK. Got it working.
I had some data in the 2nd server from previous failed attempts at hooking
up to the cluster. When I deleted that data and tried again, it said
bootstrapping and my 1st server started working again.
On Mon, May 31, 2010 at 4:50 PM, David Boxenhorn da...@lookin2.com wrote:
I
So this means that I can take my entire cluster off line if I make a
mistake adding a new server??? Yikes!
On Mon, May 31, 2010 at 6:41 PM, David Boxenhorn da...@lookin2.com wrote:
OK. Got it working.
I had some data in the 2nd server from previous failed attempts at hooking
up to the
No.
On Mon, May 31, 2010 at 10:47 AM, David Boxenhorn da...@lookin2.com wrote:
So this means that I can take my entire cluster off line if I make a
mistake adding a new server??? Yikes!
On Mon, May 31, 2010 at 6:41 PM, David Boxenhorn da...@lookin2.com wrote:
OK. Got it working.
I had
You say no, but that is exactly what I just observed. Can I have some more
explanation?
To recap: I added a server to my cluster. It had some junk in the
system/LocationInfo files from previous, unsuccessful attempts to add the
server to the cluster. (They were unsuccessful because I hadn't
