I was unable to duplicate this problem using a 3 node cluster. Here were my steps: 1. bring up a seed node, give it a schema using loadSchemaFromYaml 2. bring up a second node. it received schema from the seed node. 3. bring the seed node down. 4. bring up a third node, but set it's seed to be the second node (this is important!).
Is it possible in your testing that you only had one seed node (the original node), which is the node you shut down? If a node cannot contact a seed node, it never really joins the cluster and effectively becomes its own cluster of one node. In this case it follows that it would never receive schema definitions as well. If this isn't the case and you're still experiencing this, please let me know the steps in which you bring nodes up and down so I can replicate. Gary. On Fri, Jun 11, 2010 at 06:42, Gary Dusbabek <gdusba...@gmail.com> wrote: > I've filed this as > https://issues.apache.org/jira/browse/CASSANDRA-1182. I've created > steps to reproduce based on your email and placed them in the ticket > description. Can you confirm that I've described things correctly? > > Gary. > > On Thu, Jun 10, 2010 at 17:16, Ronald Park <ronald.p...@cbs.com> wrote: >> Hi, >> >> We've been fiddling around with a small Cassandra cluster, bringing nodes up >> and down, to get a feel for how things are replicated and how spinning up a >> new node works (before having to learn it live :). We are using the trunk >> because we want to use the expiration feature. Along with that comes the >> new keyspace api to load the 'schema'. >> >> What we found was that, if the node on which we originally installed the >> keyspace was down when a new node is added, the new node does not get the >> keyspace schema. In some regards, it is now the 'master', at least in >> distributing the keyspace data. Is this a known limitation? >> >> Thanks, >> Ron >> >
