[jira] [Updated] (CASSANDRA-15071) Materialized View Inconsistent With Base Table Update After Migrating To New DC
[ https://issues.apache.org/jira/browse/CASSANDRA-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15071: Bug Category: Parent values: Correctness(12982) Complexity: Challenging Discovered By: User Report Status: Open (was: Triage Needed) > 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 (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15071) Materialized View Inconsistent With Base Table Update After Migrating To New DC
[ 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
[jira] [Updated] (CASSANDRA-15071) Materialized View Inconsistent With Base Table Update After Migrating To New DC
[ https://issues.apache.org/jira/browse/CASSANDRA-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Hanna updated CASSANDRA-15071: - Component/s: Feature/Materialized Views > 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 > https://issues.apache.org/jira/browse/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
