This query:
select columnfamily_name from system.schema_columnfamilies
where keyspace_name='system'
has empty result in Cassandra 2.1, in 2.0 it returns table names:
IndexInfo
NodeIdInfo
batchlog
compaction_history
compactions_in_progress
hints
local
paxos
peer_events
peers
range_xfers
schema_columnfamilies
schema_columns
schema_keyspaces
schema_triggers
sstable_activity
Is there a way to list names of system tables in Cassandra 2.1?
this question is not correct. It is working on linux installation, it just does not work on my windows installation. So I am getting results on 2.0 and nothing on 2.1 - there must be something wrong with my installation.....
Related
This is what I have in cassandra.yaml
prepared_statements_cache_size_mb: 500MB
Is it possible to see the actual value of that variable once you're in cqlsh?
Since Cassandra 4.0 you'll able to do that by reading from system_views.settings table.
See the blog post from TLP on topic of virtual tables...
Because CQL statements are sent to the cluster (which should be three or more nodes), you can't use CQL to read settings on an individual node. The value for prepared_statements_cache is just for that node.
You could use JMX to read org.apache.cassandra.config.Config on a node, including prepared_statements_cache_size_mb.
I am learning Cassandra from academy.datastax.com. I am trying the Replication and Consistency demo on local machine. RF = 3 and Consistency = 1.
When my Node3 is down and I am updating my table using update command, the SYSTEM.HINTS table is expected to store hint for node3 but it is always empty.
Do I need to make any configurational changes for hints to work or the defaults are ok?
surjanrawat$ ccm node1 nodetool getendpoints mykeyspace mytable 1
127.0.0.3
127.0.0.4
127.0.0.5
surjanrawat$ ccm status
Cluster: 'mycluster'
--------------------
node1: UP
node3: DOWN
node2: UP
node5: UP
node4: UP
cqlsh:mykeyspace> select * from system.hints ;
target_id | hint_id | message_version | mutation
-----------+---------+-----------------+----------
(0 rows)
Did you use the exact same version of Cassandra to create the cluster? Since version 3+ the hints are stored in the local filesystem of the coordinator. I ask this because the exact same thing happened to me during that Datastax demo (I used 3.0.3 instead of 2.1.5) I replayed the steps but with 2.1.5 and the hints where there in the table just as expected.
Came across this post as I ran into the same issue. Latest versions of cassandra don't store the hints in system.hints table. I am using cassandra 3.9 and the hints are stored in the file system.
It is configured in cassandra.yaml file.
# Directory where Cassandra should store hints.
# If not set, the default directory is $CASSANDRA_HOME/data/hints.
# hints_directory: /var/lib/cassandra/hints
In my case I was using ccm and I was able to find the hints at
${user_home}/.ccm/mycluster/node1/hints
where mycluster is my cluster name and node1 is my node name. Hope this helps someone.
In order to understand why no hints are being written you need a good grasp on how Cassandra replicates data.
A replication factor of 2 means two copies of each row, where each
copy is on a different node. All replicas are equally important; there
is no primary or master replica.
With a replication factor of 3 and 5 nodes in the cluster you could lose another node and still not store hints because your data replication strategy is still valid. Try killing two more nodes and then check the hints table.
I know similar questions have been asked before but I think my use case is very specific for which I could not find any answer.
In Production we are using Cassandra 1.2 with ByteOrderPartitioner in a 6 Node cluster with Priam as seed management tool. We have recently upgraded all the dependencies and trying to migrate to Cassandra 3.0.2 with Murmur Partitioner and for backward compatibility we need to enable thrift on new cluster .Also we want to migrate away from Priam also.
I was able to setup new cluster but facing lot of issues during data migration. I tried 3 things:
1) Use Copy Command : Fails when number of rows is large
2) SSTable2Json : Cassandra 3.0.2 has stopped supporting SSTable2Json
3) SSTableloader: Failing I think because of different cassandra version of source and destination
java.lang.RuntimeException: Could not retrieve endpoint ranges:
at org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:233)
at org.apache.cassandra.io.sstable.SSTableLoader.stream(SSTableLoader.java:119)
at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:67)
Caused by: InvalidRequestException(why:unconfigured table schema_columnfamilies)
at org.apache.cassandra.thrift.Cassandra$execute_cql3_query_result.read(Cassandra.java:37849)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at org.apache.cassandra.thrift.Cassandra$Client.recv_execute_cql3_query(Cassandra.java:1562)
at org.apache.cassandra.thrift.Cassandra$Client.execute_cql3_query(Cassandra.java:1547)
at org.apache.cassandra.tools.BulkLoader$ExternalClient.init(BulkLoader.java:225)
... 2 more
Right now I am kind of stuck,any help regarding this will be deeply appreciated. Please let me know if you need more details.
No, You cannot upgrade your sstables from 1.2 to 3.0.2 directly since the sstable will differ for different version. This link describes the steps for upgrading the cassandra versions. But it also does not helps for you, since you are having a change in the partitioner type.
Changing the partitioner type is not yet supported in cassandra as of
now (Link).
One of the solution I would prefer is,
Create a stand alone utility which is of cassandra 3.0.2 version to read all the data from you source cassandra and write to sstable
with the help of CQLSSTableWriter with the partition type of Murmur Partitioner (The trick is, you are writing
the sstable with the version 3.0.2, so this sstable will be easily
recognized by your new cluster). Then use SSTableLoader in your target cluster
But I am not sure about why you still require backward compatibility, while creating CQLSSTableWritter you can specify the column family schema with keyword
"WITH COMPACT STORAGE". But I didn't tried CQLSSTableWritter with "WITH COMPACT STORAGE", but without "WITH COMPACT STORAGE" I had tried, it will work for your case too.
Ok so if you try to migrate directly from 1.2 to 3.0.2, you're really looking for trouble.
The migration path should be
latest minor or 1.2
2.0 latest minor
2.1 latest minor
3.0.2
For each jump between version, read the https://github.com/apache/cassandra/blob/trunk/NEWS.txt file to know if you need special actions (upgrade sstable, ...)
I am new to Cassandra so I have started with current version of CQL(Cassandra 2.x).So I want major difference between CQL for Cassandra 2.x and CQL for Cassandra 1.2.
Based on http://www.datastax.com/documentation/cql/3.1/cql/cql_intro_c.html (and its differences from http://www.datastax.com/documentation/cql/3.0/cql/cql_reference/about_cql_ref_c.html) the main difference(s) are:
Lightweight transactions using the IF keyword in INSERT and UPDATE
statements.
Initial support for triggers.
The ALTER TABLE DROP command, which had been removed in the earlier release.
Column aliases, similar to aliases in RDBMS SQL, in a SELECT statement.
Indexing of any part, partition key or clustering columns, portion of a compound primary key.
CQL for Cassandra 2.0 deprecated super columns. Cassandra continues to support apps that query super columns, translating super columns on the fly into CQL constructs and results.
The ASSUME command has been removed.
The COPY command supports collections.
New CQL table attributes: default_time_to_live, memtable_flush_period_in_ms, populate_io_cache_on_flush, speculative_retry
I want to use cassandra c++ driver. Its still working on version 2. (binary protocol version 2)
I want to use this to connect to cassandra 2.1
Is it possible to create a prepared statement and insert a UDT value into it.
or UDT can only be used with protocol version 3
regards
UDT are only available in cassandra 2.1 (and later)
https://issues.apache.org/jira/browse/CASSANDRA-5590