Re: Recreating materialized views in cassandra

eating a JIRA describing: what's the workload/queries and how does it end up in an inconsistent state if you can reproduce it? On Wed, 29 Jul 2020 at 20:49, Jasonstack Zhao Yang < jasonstack.z...@gmail.com> wrote: > > The cluster started to crash when some partitions in MV crossed 1 G

Re: Recreating materialized views in cassandra

mentions cluster instability while creating and deleting mv's > > The cluster started to crash when some partitions in MV crossed 1 GB size >> at few nodes, whereas in other nodes it is less than 50 MB. > > > Should we be worried about this? > > On Mon, Jul 27, 2020

Re: Recreating materialized views in cassandra

Hi, > We are facing data inconsistency issues between base tables and materialized views. do you run "nodetool repair" on both base and view regularly? > What are all the possible scenarios that we should be watching out for in a production environment? more cpu/io/gc for populating views. > C

Re: Materialized View's additional PrimaryKey column

Hi Jon, Do you have any clue what's the cause of downtime using MV? eg. memory pressure, or overloaded by view writes? Thanks. On Fri, 26 Jul 2019 at 13:59, mehmet bursali wrote: > Thank you again for Clear information Jon! i give up 🤗 > > Android’de Yahoo Postadan gönderildi >

Re: Commit Log question

Hi Charulata, IMO, 64MB is fine unless you archive commit log or scan it for backup. Zhao Charulata Sharma (charshar) 于2017年4月28日周五 上午8:01写道： > Hi , > > Can anyone please tell me the implication of increasing the > commitlog_segment_size_in_mb > from the default value of 32 MB to a higher

Re: Drop tables takes too long

Hi Bohdan, Carlos, Could you try some jvm tool to find out which thread are allocating memory or gc? maybe the migration stage thread.. BTW, is your cluster under high load while dropping table? As far as I remember, in older c* version, it applies the schema mutation in memory, ie. DROP, then f