Thank you so much Bowen for your advice on this. Really appreciate it!
Thanks,Jiayong Sun
On Monday, August 16, 2021, 11:56:39 AM PDT, Bowen Song
wrote:
Hi Jiayong,
You will need to reduce the num_tokens on all existing nodes in the cluster in
order to "fix" the repair. Only a
Hi Bowen,
> "how many tables are being written frequently" - there are normally about
>less then 10 tables being written concurrently.Regarding the "num_token",
>unfortunately we can change it now since it would require rebuilding all
>rings/nodes of the cluster. Actually we used to add a ring
Hi Jiayong,
You will need to reduce the num_tokens on all existing nodes in the
cluster in order to "fix" the repair. Only adding new DCs with lower
num_tokens value is not going to solve the problem for you. In practice,
you have two ways to reduce it on all existing nodes. You can either
b
Hello Jiayong,
/>//There is only one major table taking 90% of writes. /
In your case, what matters isn't the 90% writes, but the remaining 10%.
If the remaining 10% writes are spread over 100 different tables, your
Cassandra node will end up flushing over 600 times per minute.
Therefore, "h
Hi Bowen,
There is only one major table taking 90% of writes. I will try to increase the
"commitlog_segment_size_in_mb" value to 1 GB and set "max_mutation_size_in_kb"
to 16MB. Currently we don't set the "commitlog_total_space_in_mb" value so it
should be using default of 8192 MB (8 GB). What d