Thanks for pointer. We haven't much changed data model since long, so
before workarounds (scrub) worth understanding root cause of problem.
This might be reason why running upgradesstables in parallel was not
recommended.
-Shishir
On Sat, 30 Nov 2019, 10:37 Jeff Jirsa, wrote:
> Scrub really shou
Scrub really shouldn’t be required here.
If there’s ever a step that reports corruption, it’s either a very very old
table where you dropped columns previously or did something “wrong” in the past
or a software bug. The old dropped column really should be obvious in the stack
trace - anything
Some more background. We are planning (tested) binary upgrade across all
nodes without downtime. As next step running upgradesstables. As C*
file format and version (from format big, version mc to format bti, version
aa (Refer
https://docs.datastax.com/en/dse/6.0/dse-admin/datastax_enterprise/tools
Hello Shishir,
It shouldn't be necessary to take downtime to perform upgrades of a
Cassandra cluster. It sounds like the biggest issue you're facing is the
upgradesstables step. upgradesstables is not strictly necessary before a
Cassandra node re-enters the cluster to serve traffic; in my experien
Hi,
Need input on cassandra upgrade strategy for below:
1. We have Datacenter across 4 geography (multiple isolated deployments in
each DC).
2. Number of Cassandra nodes in each deployment is between 6 to 24
3. Data volume on each nodes between 150 to 400 GB
4. All production environment has DR se
Hi Rahul
Also have a look at https://issues.apache.org/jira/browse/CASSANDRA-14358 .
We saw this on a 2.1.x cluster and there it also took ~10 minutes till the
restarted node was really fully available in the cluster. the echo ACKs
from some nodes simply seemed to never reach the target
Georg
A
Query based on a field with a non-primary key and a secondary index, and
then update based on the primary key. Can it be more efficient than mysql?
