Re: cassandra-cli and "uncreachable" status confusion
> How will you recommend doing schema level health checks (consistency) for > Cassandra within the cluster? describe cluster in the cli can be used to see how many schema versions there are. The similar functionality is included in most other clients. Cheers - Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 21/03/2012, at 11:08 AM, Shoaib Mir wrote: > On Wed, Mar 21, 2012 at 4:45 AM, aaron morton wrote: > no, describe cluster is a feature of the CLI. > > > How will you recommend doing schema level health checks (consistency) for > Cassandra within the cluster? > > cheers, > Shoaib >
Re: cassandra-cli and "uncreachable" status confusion
On Wed, Mar 21, 2012 at 4:45 AM, aaron morton wrote: > no, describe cluster is a feature of the CLI. > > How will you recommend doing schema level health checks (consistency) for Cassandra within the cluster? cheers, Shoaib
Re: cassandra-cli and "uncreachable" status confusion
no, describe cluster is a feature of the CLI. Cheers - Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 20/03/2012, at 11:24 AM, Shoaib Mir wrote: > On Tue, Mar 20, 2012 at 4:18 AM, aaron morton wrote: > There is a server side check to ensure that all available nodes share the > same schema version. > > > Is that checked using "describe cluster" ?? > > cheers, > Shoaib >
Re: cassandra-cli and "uncreachable" status confusion
That's correct. If you run describe cluster normally you'll see something like: Cluster Information: Snitch: org.apache.cassandra.locator.SimpleSnitch Partitioner: org.apache.cassandra.dht.RandomPartitioner Schema versions: 3a0f6a80-7140-11e1--511aec3785ff: [IP_OF_NODE, IP_OF_NODE , IP_OF_NODE ] If there are troubles with the schema multiple will be shown of them, like: Cluster Information: Snitch: org.apache.cassandra.locator.SimpleSnitch Partitioner: org.apache.cassandra.dht.RandomPartitioner Schema versions: 3a0f6a80-7140-11e1--511aec3785ff: [IP_OF_NODE, IP_OF_NODE ] 4e252abe-7140-11e1--511aec3785ff: [IP_OF_NODE ] 2012/3/19 Shoaib Mir > On Tue, Mar 20, 2012 at 4:18 AM, aaron morton wrote: > >> There is a server side check to ensure that all available nodes share the >> same schema version. >> >> > Is that checked using "describe cluster" ?? > > cheers, > Shoaib > >
Re: cassandra-cli and "uncreachable" status confusion
On Tue, Mar 20, 2012 at 4:18 AM, aaron morton wrote: > There is a server side check to ensure that all available nodes share the > same schema version. > > Is that checked using "describe cluster" ?? cheers, Shoaib
Re: cassandra-cli and "uncreachable" status confusion
There is a server side check to ensure that all available nodes share the same schema version. The migration will proceed though if any of the nodes are unavailable. Cheers - Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 17/03/2012, at 11:07 AM, Shoaib Mir wrote: > Hi guys, > > While creating schema on our cluster today I didn't get any errors even when > some of the hosts in the cluster were unreachable (not the ones in the same > data centre but in another region). cli kept on showing all nodes agreeing > where all nodes were agreeing. > > Now after this when I did "describe cluster" I did get appropriate > "unreachable" messages for the nodes that were timing out on connections. > > Can someone please explain if at the time of schema creation does the nodes > just talk to other nodes within the DC for agreement or it has to talk to > each and every node within the whole cluster before agreeing on schema > changes? > > cheers, > Shoaib
cassandra-cli and "uncreachable" status confusion
Hi guys, While creating schema on our cluster today I didn't get any errors even when some of the hosts in the cluster were unreachable (not the ones in the same data centre but in another region). cli kept on showing all nodes agreeing where all nodes were agreeing. Now after this when I did "describe cluster" I did get appropriate "unreachable" messages for the nodes that were timing out on connections. Can someone please explain if at the time of schema creation does the nodes just talk to other nodes within the DC for agreement or it has to talk to each and every node within the whole cluster before agreeing on schema changes? cheers, Shoaib
