Still no resolution for this. Did anyone else encounter same behavior?
On Thu, May 2, 2019 at 1:54 PM Evgeny Inberg wrote:
> Yes, sstable upgraded on each node.
>
> On Thu, 2 May 2019, 13:39 Nick Hatfield
> wrote:
>
>> Just curious but, did you make sure to run the ssta
Yes, sstable upgraded on each node.
On Thu, 2 May 2019, 13:39 Nick Hatfield wrote:
> Just curious but, did you make sure to run the sstable upgrade after you
> completed the move from 2.x to 3.x ?
>
>
>
> *From:* Evgeny Inberg [mailto:evg...@gmail.com]
> *Sent:* Thursday,
that one disk fails . It may be copying data to the right
> places on startup, can you see if sstables are being moved on disk?
>
> --
> Jeff Jirsa
>
>
> On May 1, 2019, at 6:04 AM, Evgeny Inberg wrote:
>
> I have upgraded a Cassandra cluster from version 2.0.x to 3.11.
I have upgraded a Cassandra cluster from version 2.0.x to 3.11.4 going
trough 2.1.14.
After the upgrade, noticed that each node is taking about 10-15 minutes to
start, and server is under a very heavy load.
Did some digging around and got view leads from the debug log.
Messages like:
*Keyspace.java
assandra.db.marshal.BytesType Default column value validator:
org.apache.cassandra.db.marshal.BytesType Columns sorted by:
org.apache.cassandra.db.marshal.BytesType Row cache size / save period in
seconds: 0.0/0 Key cache size / save period in seconds:20.0/14400 Memtable
thresholds: 2.3247/1440/496 (millions of ops/minutes/MB) GC grace
seconds: 864000 Compaction min/max thresholds: 4/32 Read repair chance: 1.0
Replicate on write: true Built indexes: []
Thanks in advance.
Evgeny.
