cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5063) Aliasing Keyspaces
Date Fri, 14 Dec 2012 14:58:13 GMT


T Jake Luciani commented on CASSANDRA-5063:

This isn't renaming, this is like a unix soft link.

All it would be is a new system table

create table aliases (
     alias_name text PRIMARY KEY,
     keyspace_name text

CQL would add support like.

create KEYSPACE ALIAS prod ON prod2012;

Then when a request comes in we simply de-alias the keyspace in the coordinator.


Another use case for this is a backup recovery or rebuild of a corrupted data keyspace.  When
you want to flip from the old to the new you don't want to re-deploy all of your software
with the new config. Most databases support aliases so this is not a new idea.

The name could be said for table aliases.  But we can leave that for another ticket.

> Aliasing Keyspaces
> ------------------
>                 Key: CASSANDRA-5063
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Carl Yeksigian
> The way we are working with our cassandra is that we have multiple keyspaces, each of
them representing the same data in different forms. We would like to have a single name representing
the current production keyspace, while we are working on backloading our development keyspaces.
> The proposed work flow would be:
> - create keyspace prod1
> - alias keyspace prod to prod1
> - create keyspace prod2
> - backload prod2
> - alias keyspace prod to prod2
> - drop keyspace prod1
> It would be really nice if we weren't referring to "prod1" and "prod2", rather always
referencing "prod", and the aliasing would happen in Cassandra.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message