It was upgraded from on older version of openJDK 11; not sure which
one. Not that old though; we keep the machines pretty well updated.
Fix didn't work:
export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true"
[ieproc@pallas ieDocs]$ nodetool status -r
nodetool: Failed to connect to '127.0.0.1:71
Oof. From which version did you upgrade?
I would try:
> export _JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true"
There's a chance that fixes it (for an unpleasant reason).
Did you get a specific stack trace / log message at all? or just that
error?
On Tue, Apr 26, 2022 at 1:47 PM Joe Obernbe
Hi All - upgraded java recently
(java-11-openjdk-11.0.15.0.9-2.el7_9.x86_64) , and now getting:
nodetool: Failed to connect to '127.0.0.1:7199' - URISyntaxException:
'Malformed IPv6 address at index 7: rmi://[127.0.0.1]:7199'.
whenever running nodetool.
What am I missing?
Thanks!
-Joe
--
If the number of rows is known and bounded and would be under 100 MB in size, I
would suggest adding an artificial partition key so that all rows are in one
partition. I recommend this technique for something like an application
settings table that is retrieved infrequently (like on app start-up
This would be a good use case for Spark + Cassandra.
-Joe
On 4/26/2022 8:48 AM, 18624049226 wrote:
We have a business scenario. We must execute the following statement:
select * from tbl;
This CQL has no WHERE condition.
What I want to ask is that if the data in this table is more than one
Yes, you CAN change the fetch size to adjust how many pages of results are
returned. But, if you have a million rows, you may still do hundreds or
thousands of queries, one after the next. Even if each is 1ms, it's going
to take a long time.
What Dor suggested is generating a number of SELECT stat
Thank you for your reply!
What I want to know is that the data volume of this table is not
massive. If the logic of CQL cannot be modified, just inside Cassandra,
are there any parameters that can affect the behavior of this query? For
example, the fetchSize parameter of other databases?
在 2
select * reads all of the data from the cluster, obviously it would be bad
if you'll
run a single query and expect it to return 'fast'. The best way is to
divide the data
set into chunks which will be selected by the range ownership per node, so
you'll
be able to query in parallel the entire cluste
We have a business scenario. We must execute the following statement:
select * from tbl;
This CQL has no WHERE condition.
What I want to ask is that if the data in this table is more than one
million or more, what methods or parameters can improve the performance
of this CQL?
Hello,
You can use spark to read from hdfs and write to Cassandra.
The connector spark<>Cassandra is available here =>
https://github.com/datastax/spark-cassandra-connector
Greetings,
Ahmed
Le jeu. 14 avr. 2022 à 08:21, Juraj Šustek a écrit :
> Erick,
>
> first of all, thank you for your resp
take a look at cassandra-sstable-tools from instclustr, ti provides a lot
of information for sstables: largest partitions and others =>
https://github.com/instaclustr/cassandra-sstable-tools
Cheers,
Ahmed
Le ven. 15 avr. 2022 à 18:09, Bowen Song a écrit :
> Look at the system.log file, you wil
11 matches
Mail list logo
