Cassandra Schema Management Tool

John Sanda jsanda at redhat.com
Tue May 28 19:12:50 UTC 2013


On May 28, 2013, at 2:53 PM, John Sanda <jsanda at redhat.com> wrote:

> 
> On May 28, 2013, at 1:51 PM, Stefan Negrea <snegrea at redhat.com> wrote:
> 
>> 
>>> 
>>> Why not just a text file of CQL commands. Both the cassandra maven plugin and
>>> cqlsh support being passed a file of CQL commands. We can do the same.
>>> XML/JSON/etc. just means more code to maintain and validate.
>>> 
>> 
>> I would want to break down the scripts into steps and isolate potential failure. A single CQL file would just run top to bottom.
>> 
>>> 
>>> We will need some minimal capability for executing statements dynamically.
>>> When the installer runs and the schema is created, the replication factor
>>> will be set according to the cluster size. And if it is a single node
>>> cluster, then we will set gc_grace_seconds on each table to zero. With a
>>> single node, tombstones can be GC'd immediately. We can support this kind of
>>> stuff with simple tokenization though.
>>> 
>> 
>> 
>> I would not consider this kind of functionality schema management. This goes more into the area of configuration. For one, the users can add or remove nodes at any time. The schema management should not apply an update more than once, otherwise we can create a lot of confusion. The only goal of the schema management tool is to get the Cassandra schema updated from RHQ release to RHQ release. The actual configuration should be left to the other components of the application. So tasks like updating the gc grace period are configuration related and should be executed post schema installation/upgrade.
>> 
> 
> If you look at my most recent changes to SchemaManager you will see what I mean. It now has logic like,
> 
> if num storage nodes == 1 then
>    RF = 1
> else if num storage nodes is 2 or 3 then
>    RF = 2
> else
>    RF = 3
> 
> 
> We want to support that in the tooling.
> 

I want to expand on my previous comment a bit. I would slightly revise the goal of the tool to be getting the schema updated from release to release based on the current/know cluster topology. Schema changes will necessarily be handled differently than they are for postgres/oracle. The schema is going to vary in part based on the cluster size. If when I go to upgrade/install RHQ 4.8, I know that I want to run 3 storage nodes, then I want the RF of the rhq and system_auth keyspaces set accordingly, which will be different than if I am installing just a single storage node. These changes could be performed post-installation, but it will then require a number of admin tasks to be performed. There is no reason to have to do all that extra work if I know in advance that I will be starting out with a 3 node cluster.



More information about the rhq-devel mailing list