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.. http://wiki.apache.org/cassandra/FAQ?action=diff&rev1=55&rev2=56 -------------------------------------------------- * [[#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: 127.0.1.1", for any remote host. What gives?]] + * [[#no_keyspaces|Why were none of the keyspaces described in cassandra.xml loaded?]] <<Anchor(cant_listen_on_ip_any)>> @@ -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). [[https://issues.apache.org/jira/browse/CASSANDRA-44|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. +
