[
https://issues.apache.org/jira/browse/CASSANDRA-19383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17847423#comment-17847423
]
Gábor Auth commented on CASSANDRA-19383:
----------------------------------------
It looks like, I ran into the same issue:
[https://lists.apache.org/thread/qt2q8dmb21lffzhrm3w9ymfrb4ps0qkc]
In my case, it is a very small 4-nodes cluster, with very minimal data (~100 MB
at all), in my case, it occurs only on tables with more than one materialized
view, regardless the size of the table, in the thread the affected table has
only ~1300 rows and less than 200 kB data, so it might be a concurrency issue
under the hood instead of heavy I/O or CPU usage.
> Restarting a node causes MV unavailable exceptions afterward
> ------------------------------------------------------------
>
> Key: CASSANDRA-19383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19383
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
> Reporter: Brandon Williams
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> If a cluster is started with materialized views enabled and a client is
> constantly writing to one, when a node is restarted shortly after startup it
> may throw UEs:
> {quote}
> INFO [GossipStage:1] 2024-02-09 06:17:10,073 Gossiper.java:1419 - Node
> /10.5.11.102:7000 has restarted, now UP
> ERROR [MutationStage-2] 2024-02-09 06:17:10,074 Keyspace.java:650 - Unknown
> exception caught while attempting to update MaterializedView!
> stresstest.transport_orders
> 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:169)
> at
> org.apache.cassandra.locator.ReplicaPlans.assureSufficientLiveReplicasForWrite(ReplicaPlans.java:112)
> at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:353)
> at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:344)
> at
> org.apache.cassandra.locator.ReplicaPlans.forWrite(ReplicaPlans.java:338)
> at
> org.apache.cassandra.service.StorageProxy.wrapViewBatchResponseHandler(StorageProxy.java:1417)
> at
> org.apache.cassandra.service.StorageProxy.mutateMV(StorageProxy.java:1077)
> at
> org.apache.cassandra.db.view.TableViews.pushViewReplicaUpdates(TableViews.java:169)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:645)
> at org.apache.cassandra.db.Keyspace.applyFuture(Keyspace.java:476)
> at org.apache.cassandra.db.Mutation.applyFuture(Mutation.java:223)
> at
> org.apache.cassandra.db.MutationVerbHandler.doVerb(MutationVerbHandler.java:54)
> at
> org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:430)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:142)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:750)
> {quote}
> It's not immediately clear what the impact of this is since the error is on
> restart and not communicated back to the client.
--
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
