[ 
https://issues.apache.org/jira/browse/CASSANDRA-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hanna updated CASSANDRA-15071:
-------------------------------------
    Description: 
We've recently completed a successful migration between two data centers in our 
Cassandra cluster.

After adding the new DC nodes onto the existing cluster, and setting the 
keyspaces to replicate to both DCs and rebuilding the new DC nodes from the old 
one,  we've cut-over the applications using those keyspaces o start using the 
new DC exclusively by connecting to its end-points and performing `LOCAL_` 
consistency level requests there (DCAwareRoundRobinPolicy on LOCAL DC).

We noticed that once the apps started to read data from the materialized views 
in the new DC, that an inconsistency emerged, which wasn't there in the 
original DC from which we've migrated.
I.e - source/old DC had the materialized view reflecting the column update on 
the base table, while target/new DC didn't (the column value in the MV remained 
the same as it was in the base table, prior to the update).

We only found out about it being logged with a support ticket, and for now, 
mitigated it by simply recreating the materialized view.

Looking for a root cause for such behavior, is this expected, is this somewhat 
of a requirement which wasn't fulfilled yet for the MV mechanism, such as the 
ones mentioned in CASSANDRA-13826?

Thanks,
Avi K

  was:
We've recently completed a successful migration between two data centers in our 
Cassandra cluster.

After adding the new DC nodes onto the existing cluster, and setting the 
keyspaces to replicate to both DCs and rebuilding the new DC nodes from the old 
one,  we've cut-over the applications using those keyspaces o start using the 
new DC exclusively by connecting to its end-points and performing `LOCAL_` 
consistency level requests there (DCAwareRoundRobinPolicy on LOCAL DC).

We noticed that once the apps started to read data from the materialized views 
in the new DC, that an inconsistency emerged, which wasn't there in the 
original DC from which we've migrated.
I.e - source/old DC had the materialized view reflecting the column update on 
the base table, while target/new DC didn't (the column value in the MV remained 
the same as it was in the base table, prior to the update).

We only found out about it being logged with a support ticket, and for now, 
mitigated it by simply recreating the materialized view.

Looking for a root cause for such behavior, is this expected, is this somewhat 
of a requirement which wasn't fulfilled yet for the MV mechanism, such as the 
ones mentioned in https://issues.apache.org/jira/browse/CASSANDRA-13826?

Thanks,
Avi K


> Materialized View Inconsistent With Base Table Update After Migrating To New 
> DC
> -------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-15071
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15071
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Consistency/Bootstrap and Decommission, 
> Feature/Materialized Views
>            Reporter: Avraham Kalvo
>            Priority: High
>              Labels: cassandra, materializedviews, rebuilding
>
> We've recently completed a successful migration between two data centers in 
> our Cassandra cluster.
> After adding the new DC nodes onto the existing cluster, and setting the 
> keyspaces to replicate to both DCs and rebuilding the new DC nodes from the 
> old one,  we've cut-over the applications using those keyspaces o start using 
> the new DC exclusively by connecting to its end-points and performing 
> `LOCAL_` consistency level requests there (DCAwareRoundRobinPolicy on LOCAL 
> DC).
> We noticed that once the apps started to read data from the materialized 
> views in the new DC, that an inconsistency emerged, which wasn't there in the 
> original DC from which we've migrated.
> I.e - source/old DC had the materialized view reflecting the column update on 
> the base table, while target/new DC didn't (the column value in the MV 
> remained the same as it was in the base table, prior to the update).
> We only found out about it being logged with a support ticket, and for now, 
> mitigated it by simply recreating the materialized view.
> Looking for a root cause for such behavior, is this expected, is this 
> somewhat of a requirement which wasn't fulfilled yet for the MV mechanism, 
> such as the ones mentioned in CASSANDRA-13826?
> Thanks,
> Avi K



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to