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 <bursal...@yahoo.com.invalid> wrote: > Thank you again for Clear information Jon! i give up 🤗 > > Android’de Yahoo Postadan gönderildi > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> > > 0:53’’26e’ 26 Tem 2019 Cum tarihinde, Jon Haddad > <j...@jonhaddad.com> şunu yazdı: > The issues I have with MVs aren't related to how they aren't correctly > synchronized, although I'm not happy about that either. My issue with them > are in every cluster I've seen that uses them, the cluster has been > unstable, and I've put a lot of time into helping teams undo them. You > will almost certainly have several hours or days of downtime as a result of > using them. > > There's a good reason they're marked as experimental (and disabled by > default). You should maintain the other tables yourself. > > Jon > > > > On Thu, Jul 25, 2019 at 12:22 AM mehmet bursali > <bursal...@yahoo.com.invalid> wrote: > > Hi Jon, thanks for your suggestion (or warning :) ). > yes, i've read sth. about your point and i know that just because of > using MVs, there are really several issues open in JIRA on bootstrapping, > compaction and incremental repair stuff but, after reading almost all > jira tickets (with comments and history) related to using MVs, AFAU all > that issues come out by either loosing syncronization between base table > and MV by deleting columns or rows values on base table or having a huge > system that has large and dynamic number of nodes/data/workloads. We use > 3.11.3 version and most of the critical issues were fixed on 3.10 but of > course I might be miss sth so i 'll be glad if you point me some specific > jira ticket. > We have a certain use case that require updates on filtering (clustering) > columns.Our motivation for using MV was avoiding updates (delete + > create) on primaryKey columns because we suppose that cassandra developers > can manage this unpreferred operation better then us. I'm really confused > now. > > > > On Wednesday, July 24, 2019, 11:30:15 PM GMT+3, Jon Haddad < > j...@jonhaddad.com> wrote: > > > I really, really advise against using MVs. I've had to help a number of > teams move off them. Not sure what list of bugs you read, but if the list > didn't include "will destabilize your cluster to the point of constant > downtime" then the list was incomplete. > > Jon > > On Wed, Jul 24, 2019 at 6:32 AM mehmet bursali <bursal...@yahoo.com.invalid> > wrote: > > + additional info: our production environment is a multiDC cluster that > consist of 6 nodes in 2 DataCenters > > > > > On Wednesday, July 24, 2019, 3:35:11 PM GMT+3, mehmet bursali > <bursal...@yahoo.com.INVALID> wrote: > > > Hi Cassandra folks, > I'm planning to use Materialized View (MV) on production for some specific > cases. I've read a lot of blogs, technical documents about the risks of > using it and everything seems ok for our use case. > My question is about consistency(also durability) evaluation of MV usage > with an additional primary key column. İn one of our case, we select an > UDT column of base table as addtional primary key column on MV. (UDT > possible values are non nullable and restricted with domain.) . After > inserting a record in base table, this additonal column (MVs primary key > column) > value also will be updated for 1 or 2 time. So in our case, for each > update operation that will be occured on base table there are going to be > delete and create operations inside MV. > Does it matter from consistency(also durability) perspective that using > additional primary key column whether as partition column or clustering > column? > >
