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 StuHood. http://wiki.apache.org/cassandra/FAQ?action=diff&rev1=64&rev2=65 -------------------------------------------------- * [[#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?]] * [[#iter_world|How can I iterate over all the rows in a ColumnFamily?]] - * [[#no_keyspaces|Why were none of the keyspaces described in cassandra.xml loaded?]] + * [[#no_keyspaces|Why were none of the keyspaces described in storage-conf.xml loaded?]] * [[#gui|Is there a GUI admin tool for Cassandra?]] <<Anchor(cant_listen_on_ip_any)>> @@ -238, +238 @@ <<Anchor(no_keyspaces)>> - == Why were none of the keyspaces described in cassandra.xml loaded? == + == Why were none of the keyspaces described in storage-conf.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]]). + Prior to 0.7, cassandra loaded a set of static keyspaces defined in a storage-conf.xml file. [[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 storage-conf.xml. Additionally, 0.7 converts to YAML based configuration. + + If you have an existing storage-conf.xml file, you will first need to convert it to YAML using the `bin/config-converter` tool, which can generate a cassandra.yaml file from a storage-conf.xml file. Once you have a cassandra.yaml, it is possible to do a one-time load of the schema it defines. 0.7 adds a `loadSchemaFromYAML` method to `StorageServiceMBean` (triggered via JMX: see https://issues.apache.org/jira/browse/CASSANDRA-1001 ) which will load the schema defined in cassandra.yaml, but this is a one-time operation. A node that has had its schema defined via `loadSchemaFromYAML` will load its schema from the system table on subsequent restarts, which means that any further changes to the schema need to be made using the `system_*` thrift operations (see [[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.
