cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9560) Changing durable_writes on a keyspace is only applied after restart of node
Date Mon, 29 Jun 2015 20:50:05 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606374#comment-14606374
] 

Carl Yeksigian commented on CASSANDRA-9560:
-------------------------------------------

After Aleksey has reviewed and is satisfied with the patch, he'll commit it and this bug will
be resolved as fixed. Then it will be set to be included in the next release.

> Changing durable_writes on a keyspace is only applied after restart of node
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9560
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9560
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Single node
>            Reporter: Fred A
>            Assignee: Carl Yeksigian
>             Fix For: 2.1.x, 2.0.x
>
>
> When mutations for a column family is about to be applied, the cached instance of the
keyspace metadata is read. But the schema mutation for durable_writes hasn't been applied
to this cached instance.
> I'm not too familiar with the codebase but after some debugging (2.1.3), it's somehow
related to:
> {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid}
> public void apply()
> {
>    Keyspace ks = Keyspace.open(keyspaceName);
>     ks.apply(this, ks.metadata.durableWrites);
> }
> {code}
> Where a cached instance of the keyspace is opened but it's metadata hasn't been updated
with the earlier applied durable_writes mutation, since it seems that the cached keyspace
instance is lazily build at startup but after that, never updated. I'm also a little bit concerned
if other values in the cached keyspace instance suffers from the same issue, e.g. replication_factor...

> I've seen the same issue in 2.1.5 and the only way to resolve this issue is to restart
the node to let the keyspace instance cache reload from disk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message