cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berenguer Blasi (Jira)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-16856) Prevent broken schema pulls
Date Mon, 16 Aug 2021 05:29:00 GMT

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

Berenguer Blasi updated CASSANDRA-16856:
----------------------------------------
    Description: 
There's a race condition around pulling schema changes, that can occur in case the schema
changes push/propagation mechanism is not immediately effective (e.g. because of network delay,
or because of the pulling node being down, etc.).

If schema changes happen on node 1, these changes do not reach node 2 immediately through
the SCHEMA.PUSH mechanism, and are first recognized during gossiping, the corresponding SCHEMA.PULL
request from node 2 can catch the node 1 schema in the middle of it being modified by another
schema change request. This can easily lead to problems (e.g. if a new table is being added,
and the node 2 request reads the changes that need to be applied to  system_schema.tables,
but not the ones that need to be applied to system_schema.columns).

This PR addresses that by synchronizing the SCHEMA.PULL "RPC call" executed in node 1 by a
request from node 2 with the method for applying schema changes in node 1.

  was:
There's a race condition around pulling schema changes, that can occur
in case the schema changes push/propagation mechanism is not
immediately effective (e.g. because of network delay, or because of
the pulling node being down, etc.).

If schema changes happen on node 1, these changes do not reach node 2
immediately through the SCHEMA.PUSH mechanism, and are first
recognized during gossiping, the corresponding SCHEMA.PULL request
from node 2 can catch the node 1 schema in the middle of it being
modified by another schema change request. This can easily lead to
problems (e.g. if a new table is being added, and the node 2 request
reads the changes that need to be applied to system_schema.tables, but
not the ones that need to be applied to system_schema.columns).

This PR addresses that by synchronizing the SCHEMA.PULL "RPC call"
executed in node 1 by a request from node 2 with the method for
applying schema changes in node 1.


> Prevent broken schema pulls
> ---------------------------
>
>                 Key: CASSANDRA-16856
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16856
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Cluster/Gossip
>            Reporter: Berenguer Blasi
>            Assignee: Berenguer Blasi
>            Priority: Normal
>
> There's a race condition around pulling schema changes, that can occur in case the schema
changes push/propagation mechanism is not immediately effective (e.g. because of network delay,
or because of the pulling node being down, etc.).
> If schema changes happen on node 1, these changes do not reach node 2 immediately through
the SCHEMA.PUSH mechanism, and are first recognized during gossiping, the corresponding SCHEMA.PULL
request from node 2 can catch the node 1 schema in the middle of it being modified by another
schema change request. This can easily lead to problems (e.g. if a new table is being added,
and the node 2 request reads the changes that need to be applied to  system_schema.tables,
but not the ones that need to be applied to system_schema.columns).
> This PR addresses that by synchronizing the SCHEMA.PULL "RPC call" executed in node 1
by a request from node 2 with the method for applying schema changes in node 1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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


Mime
View raw message