What version of CQL is CQLv4? Looking at the product compatibility page of the documentation shows versions 3.4, 3.3, 3.2... etc. Does the v4 in CQLv4 stand for 3.4?
I'm trying to find which versions of Cassandra are compatible with CQLv4.
https://docs.datastax.com/en/landing_page/doc/landing_page/compatibility.html?scroll=compatibilityDocument__cql-versions
I think that this table could do a better job for you. Protocol version 4 starts with Cassandra 2.2, and continues to version 3.x
Related
As I have checked Scylla DB documentation and not found clearly where we can upgrade directly from Scylla version 2.1.x to 3.x.x directly.Is there any middle version upgrade required between 2.1.x to 3.x.x? Please help
The process is not documented, because it was not tested
You can follow the 2.1 to 2.2 instructions using 3.0, and everything should work, but the safest path will be 2.1 --> 2.2 --> 2.3 --> 3.0.2
Tzach
(ScyllaDB Product Manager)
I am using the Java driver 4.0.0 and DB version 3.1. When I try to query, using FILTER, the ArangoCursor returns with a null element. Tried using Vpack and POJO. Neither of them work.
This is a bug in the DB in version 3.1.RC2. It is fixed in final version 3.1, which we release at the moment. It should be available in the next 1-2 days. With that version you need the driver in version 4.1.0, because we changed the velocystream protocol in the DB version 3.1, to remove the need of an extra velocystream endpoint. Driver version 4.1.0 only works with the final release and not with the RCs.
Does anyone know if Cassandra 2.2.3 supports Oracle Java 8? Is there a place where we can go to see supported Java versions?
I am not aware of a table or location that lists a cross-reference of all Cassandra versions and the Java versions that they support. But the Cassandra 2.2 installation documentation has this information:
Prerequisites
Latest version of Oracle Java Platform, Standard Edition 8 (JDK) or OpenJDK 7.
That can change with the version of Cassandra that you are installing. The Cassandra 2.1 installation doc also adds:
Note: It is recommended to use the latest version of Oracle Java 8 on all nodes. (Oracle Java 7 is also supported.)
I'm trying to understand restrictions of upgrade from/to different versions of cassandra.
On the one hand, Cassandra docs
http://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgradeC_c.html
are saying "Cassandra 3.0.x restrictions: Upgrade from Cassandra 2.1 versions greater or equal to 2.1.9...", and I understand that as 'you couldn't upgrade to 3.0 from 2.1.8 and prior 2.1.* versions'.
On the other hand, there are no any restrictions on upgrading from, say, 2.1.8 (version prior to 2.1.9) to 2.1.11 (version grater then 2.1.9), in particular, 2.1.8->2.1.11 upgrade don't require upgrade of sstables.
So, could someone explain, why it's possible to upgrade from 2.1.9 to 3.0 but not from 2.1.8 to 3.0?
The docs restrict you from upgrading from early 2.1 versions to 3.0 because there are bug fixes and stability improvements in the later 2.1 releases that affect upgrades.
The best practice is to go to the latest patch on your branch before upgrading a major release. I.E. go to the latest 2.1.x and then go to 3.0.
Note: 3.0.0 dropped last night and it is very early in its release cycle. Make sure you test thoroughly in a qa environment before upgrading your production instance and follow the upgrade docs carefully.
I am trying to build a simple project with Spark+Cassandra for a SQL-analytics demo.
I need to use Cassandra v2.0.14 (can't upgrade it for now). I am unable to find the correct version of Spark and Spark-cassandra-connector. I referred to Datastax's git project at - https://github.com/datastax/spark-cassandra-connector, and I know that the Spark and Spark-cassandra-connector versions need to match and be compatible with Cassandra. Hence, would like anyone to help pointing out the exact versions for Spark, Spark-Cassandra-connector. I tried using v1.1.0 and v1.2.1 for both Spark and Spark-Cassandra-connector - but unable to build the spark-cassandra-connector jat jar with neither the supplied sbt (fails because the downloaded sbt-launch jar just contains a 404 not found html), nor my local sbt v0.13.8 (fails for compilation error for "import sbtassembly.Plugin.", "import AssemblyKeys.")
The connector works with Cassandra 2.0 and 2.1 but some features may also work fine with 2.2 and 3.0 (not officially supported yet) using the older Java driver 2.1. This is because C* Java driver supports a wide range of Cassandra versions. The newer driver works with older C* versions, but also the older driver versions work with newer C* versions, excluding new C* features.
However, there is a one minor caveat with using C* 2.0:
Since version 1.3.0, we dropped the thrift client from the connector. This move was to simplify connectivity code and make it easier to debug - debugging one type of connection should be easier than two. It either connects or not, no more surprises of a kind "it writes fine, but can't connect for reading". Unfortunately, not all of the thrift functionality was exposed by the native protocol in C* 2.0 nor in the system tables. Therefore, if you use C* prior to version 2.1.5, automatic split sizing won't work properly and you have to tell the connector the preferred number of splits. This is to be set in ReadConf object passed at the creation of the RDD.
As for the interface between the Connector and Spark, there is much less freedom. Spark APIs change quite often and you typically need a connector dedicated to the Spark version you use. See the version table in the README.
(fails because the downloaded sbt-launch jar just contains a 404 not found html)
This looks like an SBT problem, not a connector problem.
I just tried to do sbt clean assembly on all v1.2.5, v1.3.0, b1.4 and it worked fine.
if you can upgrade version of spark then you can connect with spark with cassandra .
put following maven dependency in pom file :-
cassandra-all
cassandra-core
cassandra-mapping
cassandra-thrift
cassandra-client
spark-cassandra-connector
spark-cassandra-connector-java
this will be work.