>do you run "nodetool repair" on both base and view regularly?
Yes, we run a full repair on our entire cluster every weekend which includes the keyspaces with the base table and materialized views But still, there are a ton of discrepancies in our base table and materialized view. Also, do you think putting the '-Dmv_enable_coordinator_batchlog=true' parameter in cassandra.yaml will solve or reduce the issue to some extent? Came across a Jira issue <https://issues.apache.org/jira/browse/CASSANDRA-15918> and this <https://medium.com/engineered-publicis-sapient/making-the-right-choices-in-cassandra-with-critical-configurations-and-data-size-speed-d358989d3437> blog which 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 at 10:18 PM Jasonstack Zhao Yang < jasonstack.z...@gmail.com> wrote: > 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. > > > Could there be any downtime in the Cassandra cluster while creating or > deleting these materialized views? > > no, but be careful about the latency/throughput impact on the regular > workload. > > On Tue, 28 Jul 2020 at 00:02, Saijal Chauhan <saijal.chau...@goevive.com> > wrote: > >> Hi, >> >> We are using Cassandra 3.0.13 >> We have the following datacenters: >> >> - DC1 with 7 Cassandra nodes with RF:3 >> - DC2 with 2 Cassandra nodes with RF:2 >> - DC3 with 2 Cassandra nodes with RF:2 >> >> We are facing data inconsistency issues between base tables and >> materialized views. >> The only solution to this problem seems to be the creation of new >> materialized views and dropping the old views. >> >> We are planning to recreate 4 materialized views, 2 belonging to the same >> base table. >> The size of each base table ranges up to 4 to 5GB. >> >> What are all the possible scenarios that we should be watching out for in >> a production environment? >> Could there be any downtime in the Cassandra cluster while creating or >> deleting these materialized views? >> >> Thank you. >> >
