Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "LiveSchemaUpdates" page has been changed by gdusbabek. http://wiki.apache.org/cassandra/LiveSchemaUpdates?action=diff&rev1=3&rev2=4 -------------------------------------------------- - = Work In Progress. Refrain from modifying until I remove this. = - = Modifying Schema on a Live Cluster = == Under the Hood == @@ -15, +13 @@ == Operations == - === Client Side === + === Client Operation === * Add column family or keyspace * Drop column family or keyspace * Rename column family or keyspace - These are all executed via the Thrift interface. It is expected that you have `ALL` access if you are using security. For rename and drop operations the client will block until all associated files are renamed or deleted. + These are all executed via the [[API|Thrift API]]. It is expected that you have `ALL` access if you are using security. For rename and drop operations the client will block until all associated files are renamed or deleted. - === Server Side === + === Server Migration Process === Applying a migration consists of the following steps: 1. Generate the migration, which includes a new version UUID. 2. Update `SCHEMA_CF` with a new schema row. @@ -32, +30 @@ 6. Update runtime data structures (create directories, etc.) === Handling Failure === - A node can fail during any step of the update process. Here is an examination of what will happen if a node fails after each part of the update process. + A node can fail during any step of the update process. Here is an examination of what will happen if a node fails after each part of the update process (see Server Migration Process above). 1. Nothing has been applied. Update fails outright. 2. Extra data exists in SCHEMA_CF but will be ignored because "Last Migration" was not updated. 3. Extra data exists in SCHEMA_CF and MIGRATION_CF but will be ignored because "Last Migration" was not updated. - 4. Broken: commit log will not be replayed until *after* schemas are loaded on restart. This means that the "Last Migration" will be read, but will not be able to be loaded and applied. + 4. '''Broken''': commit log will not be replayed until *after* schemas are loaded on restart. This means that the "Last Migration" will be read, but will not be able to be loaded and applied. 5. Startup will happen normally. 6. Startup will happen normally. @@ -50, +48 @@ When a schema update originates from the client (Thrift), gossip promulgation is bypassed and this ''announce-announce-push'' approach is used to push migrations to other nodes. - === New Cluster === + === New Cluster (Fresh 0.7) === - === Existing Cluster === + For new clusters, things will work best if you start with one node and apply migrations using Thrift until you get the schema you want. Then bring new nodes online and they will pull migrations from the first node (or each other in a large cluster). + + Alternatively, you could then shut down the first node and manually copy its `SCHEMA_CF` and `MIGRATIONS_CF` to each new node in the cluster. + + === Existing Cluster (Upgrade from 0.6) === + To provide some backwards compatibility, we've provided a JMX method in the `StorageServiceMBean` that can be used to manually load schema definitions from storage-conf.xml. This is a one-shot operation though, and will only work on a system that contains no existing migrations. If you are upgrading a cluster, you will probably only have to do this for one node (a seed). Gossip will take care of promulgating the changes to the rest of the nodes as they come online. === Concurrency === It is entirely possible and expected that a node will receive migration pushes from multiple nodes. Because of this, all migrations are applied on a single-threaded stage and versions are checked throughout to make sure that no migration is applied twice, and no migration is applied out of sync.
