cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Sibley (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-11204) Add support for EACH_ONE write consistency level
Date Mon, 22 Feb 2016 16:00:19 GMT

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

Andrew Sibley updated CASSANDRA-11204:
--------------------------------------
    Description: 
I have seen CASSANDRA-4412 where this was originally proposed, and infact a patch is attached
which includes many of the changes I thought would be necessary (perhaps this was never merged
because it was not tested or something?)

Anyway, CASSANDRA-4412 seems to have been closed as the raiser of the ticket could not justify
a use case, but I have a use case for EACH_ONE:

I have a 2 Data Centre setup, each with 3 nodes, and replication set to 3 per DC (ie. every
node has all rows of my data). My app is write heavy, and writes need to be fast, so I have
a relatively low consistency level (QUORUM is too slow, so I'm using TWO at the moment). I
would like to have strong consistency guarantees, but also tolerate a DC outage. My applications
run in the same 2 DCs as Cassandra, meaning if a DC fails, some of my apps are almost certain
to fail as well and apps will need to read data from Cassandra (eg. apps being moved over
to the other DC, or other instances in the other DC loading more data into memory).

This means that it is possible (likely) that an app will be writing some data, this will be
written to the local DC. If that DC fails, so will the app, and the latest writes will have
only been written to the local DC, and may not have replicated to the remote DC yet (and now
they won't until the local DC is alive again). The app will now be started up in the remote
DC - it will startup, try to read from ALL (fail), then QUORUM (fail), then THREE (pass).
But the THREE will only be able to read from the DC which is still alive, which likely doesn't
have the latest writes.

I know I cannot achieve absolute consistency with 1 DC down (3/6 nodes are down), but I would
like to try as best I can to guarantee a high level of consistency even during a DC outage,
as the data is highly critical.

However, if I had EACH_ONE available, I could guarantee that both DCs have at least one node
with the latest data (through EACH_ONE write level). Then I could try reading at ALL (fail
if a DC is down), then QUORUM (fail if a DC is down), then THREE / LOCAL_ALL (they're the
same in my setup - both will pass). THREE / LOCAL_ALL in this scenario is still OK, as I know
both DCs have at least one copy of the latest data.

Obviously there are other scenarios which this doesn't help (my app ends up writing to one
node in each DC, but both of those nodes fail before either manages to replicate to any other
nodes), but I think this is much less likely as the DCs are independent. An entire DC outage
will definitely happen at some stage though (power outage, networking issue, etc).

In summary, I think EACH_ONE write level would generally be beneficial to those with a small
number of DCs who want to ensure every DC has some data, to protect critical data against
DC outages.

  was:
I have seen CASSANDRA-4412 where this was originally proposed, and infact a patch is attached
which includes many of the changes I thought would be necessary (perhaps this was never merged
because it was not tested or something?)

Anyway, CASSANDRA-4412 seems to have been closed as the raiser of the ticket could not justify
a use case, but I have a use case for EACH_ONE:

I have a 2 Data Centre setup, each with 3 nodes, and replication set to 3 per DC (ie. every
node has all rows of my data). My app is write heavy, and writes need to be fast, so I have
a relatively low consistency level (QUORUM is too slow, so I'm using TWO at the moment). I
would like to have strong consistency guarantees, but also tolerate a DC outage. My applications
run in the same 2 DCs as Cassandra, meaning if a DC fails, some of my apps are almost certain
to fail as well and apps will need to read data from Cassandra (eg. apps being moved over
to the other DC, or other instances in the other DC loading more data into memory).

This means that it is possible (likely) that an app will be writing some data, this will be
written to the local DC. If that DC fails, so will the app, and the latest writes will have
only been written to the local DC, and may not have replicated to the remote DC yet (and now
they won't until the local DC is alive again). The app will now be started up in the remote
DC - it will startup, try to read from ALL (fail), then QUORUM (fail), then THREE (pass).
But the THREE will only be able to read from the DC which is still alive, which likely doesn't
have the latest writes.

I know I cannot achieve absolute consistency with 1 DC down (3/6 nodes are down), but I would
like to try as best I can to guarantee a high level of consistency even during a DC outage,
as the data is highly critical.

However, if I had EACH_ONE available, I could guarantee that both DCs have at least one node
with the latest data (through EACH_ONE write level). Then I could try reading at ALL (fail
if a DC is down), then QUORUM (fail if a DC is down), then THREE (pass). THREE in this scenario
is still OK, as I know both DCs have at least one copy of the latest data.

Obviously there are other scenarios which this doesn't help (my app ends up writing to one
node in each DC, but both of those nodes fail before either manages to replicate to any other
nodes), but I think this is much less likely as the DCs are independent. An entire DC outage
will definitely happen at some stage though (power outage, networking issue, etc).

In summary, I think EACH_ONE write level would generally be beneficial to those with a small
number of DCs who want to ensure every DC has some data, to protect critical data against
DC outages.


> Add support for EACH_ONE write consistency level
> ------------------------------------------------
>
>                 Key: CASSANDRA-11204
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11204
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Andrew Sibley
>
> I have seen CASSANDRA-4412 where this was originally proposed, and infact a patch is
attached which includes many of the changes I thought would be necessary (perhaps this was
never merged because it was not tested or something?)
> Anyway, CASSANDRA-4412 seems to have been closed as the raiser of the ticket could not
justify a use case, but I have a use case for EACH_ONE:
> I have a 2 Data Centre setup, each with 3 nodes, and replication set to 3 per DC (ie.
every node has all rows of my data). My app is write heavy, and writes need to be fast, so
I have a relatively low consistency level (QUORUM is too slow, so I'm using TWO at the moment).
I would like to have strong consistency guarantees, but also tolerate a DC outage. My applications
run in the same 2 DCs as Cassandra, meaning if a DC fails, some of my apps are almost certain
to fail as well and apps will need to read data from Cassandra (eg. apps being moved over
to the other DC, or other instances in the other DC loading more data into memory).
> This means that it is possible (likely) that an app will be writing some data, this will
be written to the local DC. If that DC fails, so will the app, and the latest writes will
have only been written to the local DC, and may not have replicated to the remote DC yet (and
now they won't until the local DC is alive again). The app will now be started up in the remote
DC - it will startup, try to read from ALL (fail), then QUORUM (fail), then THREE (pass).
But the THREE will only be able to read from the DC which is still alive, which likely doesn't
have the latest writes.
> I know I cannot achieve absolute consistency with 1 DC down (3/6 nodes are down), but
I would like to try as best I can to guarantee a high level of consistency even during a DC
outage, as the data is highly critical.
> However, if I had EACH_ONE available, I could guarantee that both DCs have at least one
node with the latest data (through EACH_ONE write level). Then I could try reading at ALL
(fail if a DC is down), then QUORUM (fail if a DC is down), then THREE / LOCAL_ALL (they're
the same in my setup - both will pass). THREE / LOCAL_ALL in this scenario is still OK, as
I know both DCs have at least one copy of the latest data.
> Obviously there are other scenarios which this doesn't help (my app ends up writing to
one node in each DC, but both of those nodes fail before either manages to replicate to any
other nodes), but I think this is much less likely as the DCs are independent. An entire DC
outage will definitely happen at some stage though (power outage, networking issue, etc).
> In summary, I think EACH_ONE write level would generally be beneficial to those with
a small number of DCs who want to ensure every DC has some data, to protect critical data
against DC outages.



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

Mime
View raw message