[ https://issues.apache.org/jira/browse/CASSANDRA-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17773888#comment-17773888 ]
sean commented on CASSANDRA-14404: ---------------------------------- In Cassandra 4.0.X, We have a table with 2 materialized views. When a Cassandra node is down. Some write operations may fail. It works fine in Cassandra 3.11.x. May be related to this change. client exception: com.datastax.oss.driver.api.core.servererrors.WriteFailureException: Cassandra failure during write query at consistency LOCAL_QUORUM (2 responses were required but only 1 replica responded, 2 failed) at com.datastax.oss.driver.api.core.servererrors.WriteFailureException.copy(WriteFailureException.java:142) at com.datastax.oss.driver.internal.core.util.concurrent.CompletableFutures.getUninterruptibly(CompletableFutures.java:149) at com.datastax.oss.driver.internal.core.cql.CqlRequestSyncProcessor.process(CqlRequestSyncProcessor.java:53) at com.datastax.oss.driver.internal.core.cql.CqlRequestSyncProcessor.process(CqlRequestSyncProcessor.java:30) at com.datastax.oss.driver.internal.core.session.DefaultSession.execute(DefaultSession.java:230) at com.datastax.oss.driver.api.core.cql.SyncCqlSession.execute(SyncCqlSession.java:54) Cassandra: [MutationStage-11] [org.apache.cassandra.db.Keyspace] Unknown exception caught while attempting to update MaterializedView! cycling.cycling_task org.apache.cassandra.exceptions.UnavailableException: Cannot achieve consistency level ONE at org.apache.cassandra.exceptions.UnavailableException.create(UnavailableException.java:37) at org.apache.cassandra.locator.ReplicaPlans.assureSufficientLiveReplicas(ReplicaPlans.java:170) at org.apache.cassandra.locator.ReplicaPlans.assureSufficientLiveReplicasForWrite(ReplicaPlans.java:113) at org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:354) at org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:345) at org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:339) at org.apache.cassandra.service.StorageProxy.wrapViewBatchResponseHandler(StorageProxy.java:1312) at org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:1004) at org.apache.cassandra.db.view.TableViews.pushViewReplicaUpdates(TableViews.java:167) at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:647) at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:513) at org.apache.cassandra.db.Mutation.apply(Mutation.java:215) at org.apache.cassandra.db.Mutation.apply(Mutation.java:220) at org.apache.cassandra.db.Mutation.apply(Mutation.java:229) at org.apache.cassandra.service.StorageProxy$4.runMayThrow(StorageProxy.java:1537) at org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2326) > Transient Replication & Cheap Quorums: Decouple storage requirements from > consensus group size using incremental repair > ----------------------------------------------------------------------------------------------------------------------- > > Key: CASSANDRA-14404 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14404 > Project: Cassandra > Issue Type: New Feature > Components: Consistency/Hints, Consistency/Repair, Feature/2i Index, > Feature/Materialized Views, Legacy/Coordination, Legacy/Core, Legacy/CQL, > Legacy/Distributed Metadata, Legacy/Local Write-Read Paths, Legacy/Testing, > Legacy/Tools > Reporter: Ariel Weisberg > Assignee: Ariel Weisberg > Priority: Normal > Fix For: 5.x > > > Transient Replication is an implementation of [Witness > Replicas|http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.146.3429&rep=rep1&type=pdf] > that leverages incremental repair to make full replicas consistent with > transient replicas that don't store the entire data set. Witness replicas are > used in real world systems such as Megastore and Spanner to increase > availability inexpensively without having to commit to more full copies of > the database. Transient replicas implement functionality similar to > upgradable and temporary replicas from the paper. > With transient replication the replication factor is increased beyond the > desired level of data redundancy by adding replicas that only store data when > sufficient full replicas are unavailable to store the data. These replicas > are called transient replicas. When incremental repair runs transient > replicas stream any data they have received to full replicas and once the > data is fully replicated it is dropped at the transient replicas. > Cheap quorums are a further set of optimizations on the write path to avoid > writing to transient replicas unless sufficient full replicas are available > as well as optimizations on the read path to prefer reading from transient > replicas. When writing at quorum to a table configured to use transient > replication the quorum will always prefer available full replicas over > transient replicas so that transient replicas don't have to process writes. > Rapid write protection (similar to rapid read protection) reduces tail > latency when full replicas are slow/unavailable to respond by sending writes > to additional replicas if necessary. > Transient replicas can generally service reads faster because they don't have > to do anything beyond bloom filter checks if they have no data. With vnodes > and larger size clusters they will not have a large quantity of data even in > failure cases where transient replicas start to serve a steady amount of > write traffic for some of their transiently replicated ranges. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org