cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Cassandra Wiki] Update of "FAQ" by gdusbabek
Date Mon, 19 Apr 2010 13:08:58 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "FAQ" page has been changed by gdusbabek.
The comment on this change is: Added a FAQ entry explaining why no schema is defined initially..


   * [[#change_replication|Can I change the ReplicationFactor on a live cluster?]]
   * [[#large_file_and_blob_storage|Can I store large files or BLOBs in Cassandra?]]
   * [[#jmx_localhost_refused|Nodetool says "Connection refused to host:", for any
remote host. What gives?]]
+  * [[#no_keyspaces|Why were none of the keyspaces described in cassandra.xml loaded?]]
@@ -218, +219 @@

  If you are not using DNS, then make sure that your `/etc/hosts` files are accurate on both
ends. If that fails try passing the `-Djava.rmi.server.hostname=$IP` option to the JVM at
startup (where `$IP` is the address of the interface you can reach from the remote machine).
+ <<Anchor(no_keyspaces)>>
+ == Why were none of the keyspaces described in cassandra.xml loaded? ==
+ Prior to 0.7, cassandra loaded a set of static keyspaces defined in cassandra.xml (previously
storage-conf.xml).  [[|CASSANDRA-44]] added
the ability to modify schema dynamically on a live cluster.  Part of this change required
that we ignore the schema defined in cassandra.xml.  The upshot is that you need to define
the schema yourself.  There are currently two ways to do this.  First, in 0.7 there is a `loadSchemaFromXML`
method defined in `StorageServiceMBean` that will load the schema defined in storage-conf.xml.
 This is a one-time operation.  A node that has had its schema defined via `loadSchemaFromXML`
will load its schema from the system table on subsequent restarts.  Second, you can modify
the schema on a node using the `system_*` thrift operations (see [[API|API]]).
+ It is recommended that you only perform schema updates on one node and let cassandra propagate
changes to the rest of the cluster.  If you try to perform the same updates simultaneously
on multiple nodes, you run the risk of introducing inconsistent migrations, which will lead
to a confused cluster.

View raw message