After upgrading to DSE 5 solr_query is not working. Below is the new DSE, cqlsh and Cassandra versions.
[cqlsh 5.0.1 | Cassandra 3.0.7.1158 | DSE 5.0.0 | CQL spec 3.4.0 |
Native protocol v4]
I am connecting using PHP Driver. The exception catching is
Must not send frame with CUSTOM_PAYLOAD flag for native protocol
version < 4
and the
error code is 33554442
When I run the same query on cqlsh it is working but not through the Php-driver.
$countSearchParam = '{"q":"'.$searchParam.'" }';
try{
$countStatement = $this->session->prepare(
"SELECT count(*) FROM table WHERE solr_query = ? ");
$countresults = $this->session->execute($countStatement, new Cassandra\ExecutionOptions(array(
'arguments' => array($countSearchParam)
)));
foreach ($countresults as $row) {
$cntArr = get_object_vars($row['count']);
$totCount = $cntArr['value'];
}
}catch(Exception $e){
}
PHP driver v1.1 does not support native protocol v4; however v1.2 is in the testing stages of development and will support v4 along with new features introduced in Cassandra v2.2 and v3.x. A version with specific DSE 5.0 features will begin after PHP driver v1.2 is released.
You can follow v1.2 release here.
Related
I installed cassandra and run cqlsh:
Connected to Test Cluster at localhost:9160.
[cqlsh 4.1.1 | Cassandra 2.0.10 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
and enter clear command on cqlsh. But i got this
cqlsh> clear;
Bad Request: line 1:0 no viable alternative at input 'clear'
cqlsh> clear
... ;
Bad Request: line 1:0 no viable alternative at input 'clear'
cqlsh>
the clear command was added in Cassandra 2.2.1 (commit) and you're using very old 2.0.10. If you just learning Cassandra, start with Cassandra 4.x, not use the version that was released 8 years ago...
Cassandra version: 3.9, CQLSH version: 5.0.1
Can I query Cassandra configuration (cassandra.yaml) using cqlsh?
No, it's not possible in your version. It's possible only starting with Cassandra 4.0 that has so-called virtual tables, and there is a special table for configurations: system_views.settings:
cqlsh:test> select * from system_views.settings ;
name | value
-------------------------------------------------+-------
transparent_data_encryption_options_enabled | false
transparent_data_encryption_options_iv_length | 16
trickle_fsync | false
trickle_fsync_interval_in_kb | 10240
truncate_request_timeout_in_ms | 60000
....
You can find more information on the virtual tables in the following blog post from TLP.
In the meantime, you can access configuration parameters via JMX.
Hi anyone instruct me which version of cassandra should I use to run cqlsh-3.4.3, So that i will be able to run GROUP BY queries.
Currently My environment is
[cqlsh 5.0.1 | Cassandra 3.9 | CQL spec 3.4.2 | Native protocol v4]
Error on trying bin/cqlsh --cqlversion=3.4.3
Connection error: ('Unable to connect to any servers', {'127.0.0.1': ProtocolError("cql_version '3.4.3' is not supported by remote (w/ native protocol). Supported versions: [u'3.4.2']",)})
Please Suggest.Thanks.
Same Error while tried with cassandra 3.7 Also.
You can try to force cqlsh to use a specific cql version using the option
--cqlversion="#.#.#"
example: cqlsh 127.0.0.1 9042 --cqlversion="3.2.0" (in your case: 3.4.2)
example of mine:
me#XXX:~$ cqlsh <cassandra_ip>
Connection error: ('Unable to connect to any servers', {<cassandra_ip>: ProtocolError("cql_version '3.4.2' is not supported by remote (w/ native protocol). Supported versions: [u'3.3.1']",)})
me#XXX:~$ cqlsh <cassandra_ip> --cqlversion="3.3.1"
Connected to UAT Analytics Cluster at <cassandra_ip>:9042.
[cqlsh 5.0.1 | Cassandra 2.2.8 | CQL spec 3.3.1 | Native protocol v4]
Use HELP for help.
cqlsh>
UPDATE
(1) group by will be supported in CQL 3.4.3 and Cassandra 3.10.
(2) It is not recommended to upgrade CQL spec for Cassandra of specific version. OR it is impossible to upgrade CQL spec version for one Cassandra version (here).
(3) In order to use group by, you should upgrade cassandra to 3.10, OR user defined functions, OR change your table design...
Just installed 64 bit DevCenter 1.5.0 on my Windows 7x64 pc. Now I am trying to connect DevCenter to our Apache Cassandra installation on a remote server. Within DevCenter, I'm getting an error when I try to connect to a remote Cassandra installation. The message from the error log is
!ENTRY Connection # open 4 0 2016-05-19 08:03:02.529
!MESSAGE com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: host.domain.com/###.##.##.###:9042 (com.datastax.driver.core.TransportException: [host.domain.com/###.##.##.###:9042] Cannot connect))
I can however connect command line using cqlsh and it shows
cqlsh 5.0.1 | Cassandra 2.1.14 | CQL spec 3.2.1 | Native protocol v3.
In my cqlshrc file - I have to specify [cql] version = 3.2.1 and the certificate to make the connection function.
From what I have read - to make DevCenter connect - I had to do a couple of things
1) Create a truststore for the certificate and reference it in the connection properties with the password - and that seems to be ok I believe (info from the DataStax site)
2) The second thing I needed to do was change the cassandra.yaml file in C:\Program Files\DataStax-DDC\apache-cassandra\conf - change the rpc_address to the host.domain.com and verify start_native_transport: true (StackOverflow)
I am not sure what I am missing - to successfully connect DataStax DevCenter on my windows 7 machine to the apache cassandra installation on a remote server (host.domain.com).
I have a two node and I installed DataStax OpsCenter on 10.5.0.201 but I give error ( Unable connect to any seed nodes ) when I create new cluster on OpsCenter. Can you check my config ?
address.yaml ( 10.5.0.201 )
address.yaml ( 10.5.0.203 )
nodetool status
DataStax OpsCenter
startup.log (10.5.0.201)
agent.log ( 10.5.0.201 )
Versions
Python 2.6.6
java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02) Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)
OpsCenter 5.2.4
Best Regards
In the comments of cassandra.yaml
# Note that unlike listen_address, you can specify 0.0.0.0, but you must also
# set broadcast_rpc_address to a value other than 0.0.0.0.
I would recommend to set rpc_address: 10.5.0.201 for the 1st node and to retry