Hello,
Does anyone know how I can see queries coming when they're as prepared
statements when trace is turned on Cassandra 3.x?
If trace doesn't show, any ideas how I can see these type of queries?
Hi,
The nodetool output should be accurate and reliable.
But using nodetool command for monitoring is not a very good idea.
Nodetool has its own resource overhead each time it is invoked.
You should ideally use a standard monitoring tool/method.
Regards,
Anup Shirolkar
On Tue, 23 Oct 2018
Hi All,
Is nodetool info information is accurate to monitor memory usage, intially
with 3.1.0 we had monitoring nodetool infor for heap usage and it never
reported this information as high,after upgrading to 3.11.2 we started
getting high usage using nodetool info later upgraded to 3.11.3 and sa
Nodetool will eventually return when it’s done
You can also watch nodetool compactionstats
--
Jeff Jirsa
> On Oct 22, 2018, at 10:53 AM, Ian Spence wrote:
>
> Environment: Cassandra 2.2.9, GNU/Linux CentOS 6 + 7. Two DCs, 3 RACs in DC1
> and 6 in DC2.
>
> We recently added 16 new nodes to
Environment: Cassandra 2.2.9, GNU/Linux CentOS 6 + 7. Two DCs, 3 RACs in DC1
and 6 in DC2.
We recently added 16 new nodes to our 38-node cluster (now 54 nodes). What
would be the safest and most
efficient way of running a cleanup operation? I’ve experimented with running
cleanup on a single nod
Thanks Mick.
We're on datastax java driver version: 2.1.10.2 and we aren't using the client
side timestamps. Anyway, we went ahead and verified that all client machines
and cassandra machines are in sync with regards to time.
We've also verified that no reads and writes are going to the remot
Ok, thanks.
My conclusion:
1. I will set unchecked_tombstone_compaction to true to get old data with
tombstones removed
2. I will exclude TWCS tables from repair
Regarding exclude table from repair, is there any easy way to do this?
Nodetool repaire do not support excludes.
Regards
Hi, we built a simple system to migrate live cassandra data to other
databases, mainly by using these queries:
1. SELECT DISTINCT TOKEN(partition_key) FROM table WHERE
TOKEN(partition_key) > current_offset AND TOKEN(partition_key) <=
upper_bound LIMIT token_fetch_size
2. Any cql query that retriev