Re: Making RF4 useful aka primary and secondary ranges

[Jason Brown]

I feel like we've had a very similar conversation (not so) recently:
https://lists.apache.org/thread.html/9952c419398a1a2f22e2887e3492f9d6899365f0ea7c2b68d6fbe0d4@%3Cuser.cassandra.apache.org%3E

Which led to the creation of this JIRA:
https://issues.apache.org/jira/browse/CASSANDRA-13645


On Wed, Mar 14, 2018 at 4:23 PM, Carl Mueller 
wrote:

> Since this is basically driver syntactic sugar... Yes I'll try that.
>
>
> On Wed, Mar 14, 2018 at 5:59 PM, Jonathan Haddad 
> wrote:
>
> > You could use a load balancing policy at the driver level to do what you
> > want, mixed with the existing consistency levels as Jeff suggested.
> >
> > On Wed, Mar 14, 2018 at 3:47 PM Carl Mueller <
> carl.muel...@smartthings.com
> > >
> > wrote:
> >
> > > But we COULD have CL2 write (for RF4)
> > >
> > > The extension to this idea is multiple backup/secondary replicas. So
> you
> > > have RF5 or RF6 or higher, but still are performing CL2 against the
> > > preferred first three for both read and write.
> > >
> > > You could also ascertain the general write health of affected ranges
> > before
> > > taking a node down for maintenance from the primary, and then know the
> > > switchover is in good shape. Yes there are CAP limits and race
> conditions
> > > there, but you could get pretty good assurances (all repaired, low/zero
> > > queued hinted handoffs, etc).
> > >
> > > This is essentially like if you had two datacenters, but are doing
> > > local_quorum on the one datacenter. Well, except switchover is a bit
> more
> > > granular if you run out of replicas in the local.
> > >
> > >
> > >
> > > On Wed, Mar 14, 2018 at 5:17 PM, Jeff Jirsa  wrote:
> > >
> > > > Write at CL 3 and read at CL 2
> > > >
> > > > --
> > > > Jeff Jirsa
> > > >
> > > >
> > > > > On Mar 14, 2018, at 2:40 PM, Carl Mueller <
> > > carl.muel...@smartthings.com>
> > > > wrote:
> > > > >
> > > > > Currently there is little use for RF4. You're getting the
> > requirements
> > > of
> > > > > QUORUM-3 but only one extra backup.
> > > > >
> > > > > I'd like to propose something that would make RF4 a sort of more
> > > heavily
> > > > > backed up RF3.
> > > > >
> > > > > A lot of this is probably achievable with strictly driver-level
> > logic,
> > > so
> > > > > perhaps it would belong more there.
> > > > >
> > > > > Basically the idea is to have four replicas of the data, but only
> > have
> > > to
> > > > > practically do QUORUM with three nodes. We consider the first three
> > > > > replicas the "primary replicas". On an ongoing basis for QUORUM
> reads
> > > and
> > > > > writes, we would rely on only those three replicas to satisfy
> > > > > two-out-of-three QUORUM. Writes are persisted to the fourth replica
> > in
> > > > the
> > > > > normal manner of cassandra, it just doesn't count towards the
> QUORUM
> > > > write.
> > > > >
> > > > > On reads, with token and node health awareness by the driver, if
> the
> > > > > primaries are all healthy, two-of-three QUORUM is calculated from
> > > those.
> > > > >
> > > > > If however one of the three primaries is down, read QUORUM is a bit
> > > > > different:
> > > > > 1) if the first two replies come from the two remaining primaries
> and
> > > > > agree, the is returned
> > > > > 2) if the first two replies are a primary and the "hot spare" and
> > those
> > > > > agree, that is returned
> > > > > 3) if the primary and hot spare disagree, wait for the next primary
> > to
> > > > > return, and then take the agreement (hopefully) that results
> > > > >
> > > > > Then once the previous primary comes back online, the read quorum
> > goes
> > > > back
> > > > > to preferring that set, with the assuming hinted handoff and repair
> > > will
> > > > > get it back up to snuff.
> > > > >
> > > > > There could also be some mechanism examining the hinted handoff
> > status
> > > of
> > > > > the four to determine when to reactivate the primary that was down.
> > > > >
> > > > > For mutations, one could prefer a "QUORUM plus" that was a quorum
> of
> > > the
> > > > > primaries plus the hot spare.
> > > > >
> > > > > Of course one could do multiple hot spares, so RF5 could still be
> > > treated
> > > > > as RF3 + hot spares.
> > > > >
> > > > > The goal here is more data resiliency but not having to rely on as
> > many
> > > > > nodes for resiliency.
> > > > >
> > > > > Since the data is ring-distributed, the fact there are primary
> owners
> > > of
> > > > > ranges should still be evenly distributed and no hot nodes should
> > > result
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>

Re: A JIRA proposing a seperate repository for the online documentation

[Murukesh Mohanan]

I think this was how it was in the dark ages, with the wiki and all. I
believe the reason why they shifted to in-tree docs is that this way,
people who make changes to the code are more likely to make the
corresponding doc changes as well, and reviewers have it easier to ensure
docs are updated with new patches. The wiki was often left behind the code.
So I they will move back to an out-of-tree doc system again. The way
Michael put it in CASSANDRA-13907, the main blocker behind having docs for
multiple versions online is that it's a pain just to get the docs for trunk
updated. Once the current site update process is improved, multiple
versions can more easily be added.


On Thu, Mar 15, 2018 at 1:22 Kenneth Brotman 
wrote:

> https://issues.apache.org/jira/browse/CASSANDRA-14313
>
>
>
> For some reason I'm told by many committers that we should not have sets of
> documentation for other versions than the current version in a tree for
> that
> version.  This has made it difficult, maybe impossible to have
> documentation
> for all the supported versions on the website at one time.
>
>
>
> As a solution I propose that we maintain the online documentation in a
> separate repository that is managed as the current repository under the
> guidance of the Apache Cassandra PMC (Project Management Committee); and
> that in the new repository . . .
>
>
>
> Please see the jira.  I hope it's a good answer to everyone.
>
>
>
> KennethBrotman
>
>
>
>
>
> --

Murukesh Mohanan,
Yahoo! Japan

Re: Making RF4 useful aka primary and secondary ranges

[Carl Mueller]

Since this is basically driver syntactic sugar... Yes I'll try that.


On Wed, Mar 14, 2018 at 5:59 PM, Jonathan Haddad  wrote:

> You could use a load balancing policy at the driver level to do what you
> want, mixed with the existing consistency levels as Jeff suggested.
>
> On Wed, Mar 14, 2018 at 3:47 PM Carl Mueller  >
> wrote:
>
> > But we COULD have CL2 write (for RF4)
> >
> > The extension to this idea is multiple backup/secondary replicas. So you
> > have RF5 or RF6 or higher, but still are performing CL2 against the
> > preferred first three for both read and write.
> >
> > You could also ascertain the general write health of affected ranges
> before
> > taking a node down for maintenance from the primary, and then know the
> > switchover is in good shape. Yes there are CAP limits and race conditions
> > there, but you could get pretty good assurances (all repaired, low/zero
> > queued hinted handoffs, etc).
> >
> > This is essentially like if you had two datacenters, but are doing
> > local_quorum on the one datacenter. Well, except switchover is a bit more
> > granular if you run out of replicas in the local.
> >
> >
> >
> > On Wed, Mar 14, 2018 at 5:17 PM, Jeff Jirsa  wrote:
> >
> > > Write at CL 3 and read at CL 2
> > >
> > > --
> > > Jeff Jirsa
> > >
> > >
> > > > On Mar 14, 2018, at 2:40 PM, Carl Mueller <
> > carl.muel...@smartthings.com>
> > > wrote:
> > > >
> > > > Currently there is little use for RF4. You're getting the
> requirements
> > of
> > > > QUORUM-3 but only one extra backup.
> > > >
> > > > I'd like to propose something that would make RF4 a sort of more
> > heavily
> > > > backed up RF3.
> > > >
> > > > A lot of this is probably achievable with strictly driver-level
> logic,
> > so
> > > > perhaps it would belong more there.
> > > >
> > > > Basically the idea is to have four replicas of the data, but only
> have
> > to
> > > > practically do QUORUM with three nodes. We consider the first three
> > > > replicas the "primary replicas". On an ongoing basis for QUORUM reads
> > and
> > > > writes, we would rely on only those three replicas to satisfy
> > > > two-out-of-three QUORUM. Writes are persisted to the fourth replica
> in
> > > the
> > > > normal manner of cassandra, it just doesn't count towards the QUORUM
> > > write.
> > > >
> > > > On reads, with token and node health awareness by the driver, if the
> > > > primaries are all healthy, two-of-three QUORUM is calculated from
> > those.
> > > >
> > > > If however one of the three primaries is down, read QUORUM is a bit
> > > > different:
> > > > 1) if the first two replies come from the two remaining primaries and
> > > > agree, the is returned
> > > > 2) if the first two replies are a primary and the "hot spare" and
> those
> > > > agree, that is returned
> > > > 3) if the primary and hot spare disagree, wait for the next primary
> to
> > > > return, and then take the agreement (hopefully) that results
> > > >
> > > > Then once the previous primary comes back online, the read quorum
> goes
> > > back
> > > > to preferring that set, with the assuming hinted handoff and repair
> > will
> > > > get it back up to snuff.
> > > >
> > > > There could also be some mechanism examining the hinted handoff
> status
> > of
> > > > the four to determine when to reactivate the primary that was down.
> > > >
> > > > For mutations, one could prefer a "QUORUM plus" that was a quorum of
> > the
> > > > primaries plus the hot spare.
> > > >
> > > > Of course one could do multiple hot spares, so RF5 could still be
> > treated
> > > > as RF3 + hot spares.
> > > >
> > > > The goal here is more data resiliency but not having to rely on as
> many
> > > > nodes for resiliency.
> > > >
> > > > Since the data is ring-distributed, the fact there are primary owners
> > of
> > > > ranges should still be evenly distributed and no hot nodes should
> > result
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: Making RF4 useful aka primary and secondary ranges

[Jonathan Haddad]

You could use a load balancing policy at the driver level to do what you
want, mixed with the existing consistency levels as Jeff suggested.

On Wed, Mar 14, 2018 at 3:47 PM Carl Mueller 
wrote:

> But we COULD have CL2 write (for RF4)
>
> The extension to this idea is multiple backup/secondary replicas. So you
> have RF5 or RF6 or higher, but still are performing CL2 against the
> preferred first three for both read and write.
>
> You could also ascertain the general write health of affected ranges before
> taking a node down for maintenance from the primary, and then know the
> switchover is in good shape. Yes there are CAP limits and race conditions
> there, but you could get pretty good assurances (all repaired, low/zero
> queued hinted handoffs, etc).
>
> This is essentially like if you had two datacenters, but are doing
> local_quorum on the one datacenter. Well, except switchover is a bit more
> granular if you run out of replicas in the local.
>
>
>
> On Wed, Mar 14, 2018 at 5:17 PM, Jeff Jirsa  wrote:
>
> > Write at CL 3 and read at CL 2
> >
> > --
> > Jeff Jirsa
> >
> >
> > > On Mar 14, 2018, at 2:40 PM, Carl Mueller <
> carl.muel...@smartthings.com>
> > wrote:
> > >
> > > Currently there is little use for RF4. You're getting the requirements
> of
> > > QUORUM-3 but only one extra backup.
> > >
> > > I'd like to propose something that would make RF4 a sort of more
> heavily
> > > backed up RF3.
> > >
> > > A lot of this is probably achievable with strictly driver-level logic,
> so
> > > perhaps it would belong more there.
> > >
> > > Basically the idea is to have four replicas of the data, but only have
> to
> > > practically do QUORUM with three nodes. We consider the first three
> > > replicas the "primary replicas". On an ongoing basis for QUORUM reads
> and
> > > writes, we would rely on only those three replicas to satisfy
> > > two-out-of-three QUORUM. Writes are persisted to the fourth replica in
> > the
> > > normal manner of cassandra, it just doesn't count towards the QUORUM
> > write.
> > >
> > > On reads, with token and node health awareness by the driver, if the
> > > primaries are all healthy, two-of-three QUORUM is calculated from
> those.
> > >
> > > If however one of the three primaries is down, read QUORUM is a bit
> > > different:
> > > 1) if the first two replies come from the two remaining primaries and
> > > agree, the is returned
> > > 2) if the first two replies are a primary and the "hot spare" and those
> > > agree, that is returned
> > > 3) if the primary and hot spare disagree, wait for the next primary to
> > > return, and then take the agreement (hopefully) that results
> > >
> > > Then once the previous primary comes back online, the read quorum goes
> > back
> > > to preferring that set, with the assuming hinted handoff and repair
> will
> > > get it back up to snuff.
> > >
> > > There could also be some mechanism examining the hinted handoff status
> of
> > > the four to determine when to reactivate the primary that was down.
> > >
> > > For mutations, one could prefer a "QUORUM plus" that was a quorum of
> the
> > > primaries plus the hot spare.
> > >
> > > Of course one could do multiple hot spares, so RF5 could still be
> treated
> > > as RF3 + hot spares.
> > >
> > > The goal here is more data resiliency but not having to rely on as many
> > > nodes for resiliency.
> > >
> > > Since the data is ring-distributed, the fact there are primary owners
> of
> > > ranges should still be evenly distributed and no hot nodes should
> result
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Making RF4 useful aka primary and secondary ranges

[Carl Mueller]

But we COULD have CL2 write (for RF4)

The extension to this idea is multiple backup/secondary replicas. So you
have RF5 or RF6 or higher, but still are performing CL2 against the
preferred first three for both read and write.

You could also ascertain the general write health of affected ranges before
taking a node down for maintenance from the primary, and then know the
switchover is in good shape. Yes there are CAP limits and race conditions
there, but you could get pretty good assurances (all repaired, low/zero
queued hinted handoffs, etc).

This is essentially like if you had two datacenters, but are doing
local_quorum on the one datacenter. Well, except switchover is a bit more
granular if you run out of replicas in the local.



On Wed, Mar 14, 2018 at 5:17 PM, Jeff Jirsa  wrote:

> Write at CL 3 and read at CL 2
>
> --
> Jeff Jirsa
>
>
> > On Mar 14, 2018, at 2:40 PM, Carl Mueller 
> wrote:
> >
> > Currently there is little use for RF4. You're getting the requirements of
> > QUORUM-3 but only one extra backup.
> >
> > I'd like to propose something that would make RF4 a sort of more heavily
> > backed up RF3.
> >
> > A lot of this is probably achievable with strictly driver-level logic, so
> > perhaps it would belong more there.
> >
> > Basically the idea is to have four replicas of the data, but only have to
> > practically do QUORUM with three nodes. We consider the first three
> > replicas the "primary replicas". On an ongoing basis for QUORUM reads and
> > writes, we would rely on only those three replicas to satisfy
> > two-out-of-three QUORUM. Writes are persisted to the fourth replica in
> the
> > normal manner of cassandra, it just doesn't count towards the QUORUM
> write.
> >
> > On reads, with token and node health awareness by the driver, if the
> > primaries are all healthy, two-of-three QUORUM is calculated from those.
> >
> > If however one of the three primaries is down, read QUORUM is a bit
> > different:
> > 1) if the first two replies come from the two remaining primaries and
> > agree, the is returned
> > 2) if the first two replies are a primary and the "hot spare" and those
> > agree, that is returned
> > 3) if the primary and hot spare disagree, wait for the next primary to
> > return, and then take the agreement (hopefully) that results
> >
> > Then once the previous primary comes back online, the read quorum goes
> back
> > to preferring that set, with the assuming hinted handoff and repair will
> > get it back up to snuff.
> >
> > There could also be some mechanism examining the hinted handoff status of
> > the four to determine when to reactivate the primary that was down.
> >
> > For mutations, one could prefer a "QUORUM plus" that was a quorum of the
> > primaries plus the hot spare.
> >
> > Of course one could do multiple hot spares, so RF5 could still be treated
> > as RF3 + hot spares.
> >
> > The goal here is more data resiliency but not having to rely on as many
> > nodes for resiliency.
> >
> > Since the data is ring-distributed, the fact there are primary owners of
> > ranges should still be evenly distributed and no hot nodes should result
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Making RF4 useful aka primary and secondary ranges

[Jeff Jirsa]

Write at CL 3 and read at CL 2

-- 
Jeff Jirsa


> On Mar 14, 2018, at 2:40 PM, Carl Mueller  
> wrote:
> 
> Currently there is little use for RF4. You're getting the requirements of
> QUORUM-3 but only one extra backup.
> 
> I'd like to propose something that would make RF4 a sort of more heavily
> backed up RF3.
> 
> A lot of this is probably achievable with strictly driver-level logic, so
> perhaps it would belong more there.
> 
> Basically the idea is to have four replicas of the data, but only have to
> practically do QUORUM with three nodes. We consider the first three
> replicas the "primary replicas". On an ongoing basis for QUORUM reads and
> writes, we would rely on only those three replicas to satisfy
> two-out-of-three QUORUM. Writes are persisted to the fourth replica in the
> normal manner of cassandra, it just doesn't count towards the QUORUM write.
> 
> On reads, with token and node health awareness by the driver, if the
> primaries are all healthy, two-of-three QUORUM is calculated from those.
> 
> If however one of the three primaries is down, read QUORUM is a bit
> different:
> 1) if the first two replies come from the two remaining primaries and
> agree, the is returned
> 2) if the first two replies are a primary and the "hot spare" and those
> agree, that is returned
> 3) if the primary and hot spare disagree, wait for the next primary to
> return, and then take the agreement (hopefully) that results
> 
> Then once the previous primary comes back online, the read quorum goes back
> to preferring that set, with the assuming hinted handoff and repair will
> get it back up to snuff.
> 
> There could also be some mechanism examining the hinted handoff status of
> the four to determine when to reactivate the primary that was down.
> 
> For mutations, one could prefer a "QUORUM plus" that was a quorum of the
> primaries plus the hot spare.
> 
> Of course one could do multiple hot spares, so RF5 could still be treated
> as RF3 + hot spares.
> 
> The goal here is more data resiliency but not having to rely on as many
> nodes for resiliency.
> 
> Since the data is ring-distributed, the fact there are primary owners of
> ranges should still be evenly distributed and no hot nodes should result

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

Re: Making RF4 useful aka primary and secondary ranges

[Carl Mueller]

I also wonder if the state of hinted handoff can inform the validity of
extra replicas. Repair is mentioned in 7168.


On Wed, Mar 14, 2018 at 4:55 PM, Carl Mueller 
wrote:

> For my reference: https://issues.apache.org/jira/browse/CASSANDRA-7168
>
>
> On Wed, Mar 14, 2018 at 4:46 PM, Ariel Weisberg  wrote:
>
>> Hi,
>>
>> There is a JIRA for decoupling the size of the group size used for
>> consensus with level of data redundancy. https://issues.apache.org/jira
>> /browse/CASSANDRA-13442
>>
>> It's been discussed quite a bit offline and I did a presentation on it at
>> NGCC. Hopefully we will see some movement on it soon.
>>
>> Ariel
>>
>> On Wed, Mar 14, 2018, at 5:40 PM, Carl Mueller wrote:
>> > Currently there is little use for RF4. You're getting the requirements
>> of
>> > QUORUM-3 but only one extra backup.
>> >
>> > I'd like to propose something that would make RF4 a sort of more heavily
>> > backed up RF3.
>> >
>> > A lot of this is probably achievable with strictly driver-level logic,
>> so
>> > perhaps it would belong more there.
>> >
>> > Basically the idea is to have four replicas of the data, but only have
>> to
>> > practically do QUORUM with three nodes. We consider the first three
>> > replicas the "primary replicas". On an ongoing basis for QUORUM reads
>> and
>> > writes, we would rely on only those three replicas to satisfy
>> > two-out-of-three QUORUM. Writes are persisted to the fourth replica in
>> the
>> > normal manner of cassandra, it just doesn't count towards the QUORUM
>> write.
>> >
>> > On reads, with token and node health awareness by the driver, if the
>> > primaries are all healthy, two-of-three QUORUM is calculated from those.
>> >
>> > If however one of the three primaries is down, read QUORUM is a bit
>> > different:
>> > 1) if the first two replies come from the two remaining primaries and
>> > agree, the is returned
>> > 2) if the first two replies are a primary and the "hot spare" and those
>> > agree, that is returned
>> > 3) if the primary and hot spare disagree, wait for the next primary to
>> > return, and then take the agreement (hopefully) that results
>> >
>> > Then once the previous primary comes back online, the read quorum goes
>> back
>> > to preferring that set, with the assuming hinted handoff and repair will
>> > get it back up to snuff.
>> >
>> > There could also be some mechanism examining the hinted handoff status
>> of
>> > the four to determine when to reactivate the primary that was down.
>> >
>> > For mutations, one could prefer a "QUORUM plus" that was a quorum of the
>> > primaries plus the hot spare.
>> >
>> > Of course one could do multiple hot spares, so RF5 could still be
>> treated
>> > as RF3 + hot spares.
>> >
>> > The goal here is more data resiliency but not having to rely on as many
>> > nodes for resiliency.
>> >
>> > Since the data is ring-distributed, the fact there are primary owners of
>> > ranges should still be evenly distributed and no hot nodes should result
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
>

Re: Making RF4 useful aka primary and secondary ranges

[Carl Mueller]

For my reference: https://issues.apache.org/jira/browse/CASSANDRA-7168


On Wed, Mar 14, 2018 at 4:46 PM, Ariel Weisberg  wrote:

> Hi,
>
> There is a JIRA for decoupling the size of the group size used for
> consensus with level of data redundancy. https://issues.apache.org/
> jira/browse/CASSANDRA-13442
>
> It's been discussed quite a bit offline and I did a presentation on it at
> NGCC. Hopefully we will see some movement on it soon.
>
> Ariel
>
> On Wed, Mar 14, 2018, at 5:40 PM, Carl Mueller wrote:
> > Currently there is little use for RF4. You're getting the requirements of
> > QUORUM-3 but only one extra backup.
> >
> > I'd like to propose something that would make RF4 a sort of more heavily
> > backed up RF3.
> >
> > A lot of this is probably achievable with strictly driver-level logic, so
> > perhaps it would belong more there.
> >
> > Basically the idea is to have four replicas of the data, but only have to
> > practically do QUORUM with three nodes. We consider the first three
> > replicas the "primary replicas". On an ongoing basis for QUORUM reads and
> > writes, we would rely on only those three replicas to satisfy
> > two-out-of-three QUORUM. Writes are persisted to the fourth replica in
> the
> > normal manner of cassandra, it just doesn't count towards the QUORUM
> write.
> >
> > On reads, with token and node health awareness by the driver, if the
> > primaries are all healthy, two-of-three QUORUM is calculated from those.
> >
> > If however one of the three primaries is down, read QUORUM is a bit
> > different:
> > 1) if the first two replies come from the two remaining primaries and
> > agree, the is returned
> > 2) if the first two replies are a primary and the "hot spare" and those
> > agree, that is returned
> > 3) if the primary and hot spare disagree, wait for the next primary to
> > return, and then take the agreement (hopefully) that results
> >
> > Then once the previous primary comes back online, the read quorum goes
> back
> > to preferring that set, with the assuming hinted handoff and repair will
> > get it back up to snuff.
> >
> > There could also be some mechanism examining the hinted handoff status of
> > the four to determine when to reactivate the primary that was down.
> >
> > For mutations, one could prefer a "QUORUM plus" that was a quorum of the
> > primaries plus the hot spare.
> >
> > Of course one could do multiple hot spares, so RF5 could still be treated
> > as RF3 + hot spares.
> >
> > The goal here is more data resiliency but not having to rely on as many
> > nodes for resiliency.
> >
> > Since the data is ring-distributed, the fact there are primary owners of
> > ranges should still be evenly distributed and no hot nodes should result
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Making RF4 useful aka primary and secondary ranges

[Ariel Weisberg]

Hi,

There is a JIRA for decoupling the size of the group size used for consensus 
with level of data redundancy. 
https://issues.apache.org/jira/browse/CASSANDRA-13442

It's been discussed quite a bit offline and I did a presentation on it at NGCC. 
Hopefully we will see some movement on it soon.

Ariel

On Wed, Mar 14, 2018, at 5:40 PM, Carl Mueller wrote:
> Currently there is little use for RF4. You're getting the requirements of
> QUORUM-3 but only one extra backup.
> 
> I'd like to propose something that would make RF4 a sort of more heavily
> backed up RF3.
> 
> A lot of this is probably achievable with strictly driver-level logic, so
> perhaps it would belong more there.
> 
> Basically the idea is to have four replicas of the data, but only have to
> practically do QUORUM with three nodes. We consider the first three
> replicas the "primary replicas". On an ongoing basis for QUORUM reads and
> writes, we would rely on only those three replicas to satisfy
> two-out-of-three QUORUM. Writes are persisted to the fourth replica in the
> normal manner of cassandra, it just doesn't count towards the QUORUM write.
> 
> On reads, with token and node health awareness by the driver, if the
> primaries are all healthy, two-of-three QUORUM is calculated from those.
> 
> If however one of the three primaries is down, read QUORUM is a bit
> different:
> 1) if the first two replies come from the two remaining primaries and
> agree, the is returned
> 2) if the first two replies are a primary and the "hot spare" and those
> agree, that is returned
> 3) if the primary and hot spare disagree, wait for the next primary to
> return, and then take the agreement (hopefully) that results
> 
> Then once the previous primary comes back online, the read quorum goes back
> to preferring that set, with the assuming hinted handoff and repair will
> get it back up to snuff.
> 
> There could also be some mechanism examining the hinted handoff status of
> the four to determine when to reactivate the primary that was down.
> 
> For mutations, one could prefer a "QUORUM plus" that was a quorum of the
> primaries plus the hot spare.
> 
> Of course one could do multiple hot spares, so RF5 could still be treated
> as RF3 + hot spares.
> 
> The goal here is more data resiliency but not having to rely on as many
> nodes for resiliency.
> 
> Since the data is ring-distributed, the fact there are primary owners of
> ranges should still be evenly distributed and no hot nodes should result

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

Making RF4 useful aka primary and secondary ranges

[Carl Mueller]

Currently there is little use for RF4. You're getting the requirements of
QUORUM-3 but only one extra backup.

I'd like to propose something that would make RF4 a sort of more heavily
backed up RF3.

A lot of this is probably achievable with strictly driver-level logic, so
perhaps it would belong more there.

Basically the idea is to have four replicas of the data, but only have to
practically do QUORUM with three nodes. We consider the first three
replicas the "primary replicas". On an ongoing basis for QUORUM reads and
writes, we would rely on only those three replicas to satisfy
two-out-of-three QUORUM. Writes are persisted to the fourth replica in the
normal manner of cassandra, it just doesn't count towards the QUORUM write.

On reads, with token and node health awareness by the driver, if the
primaries are all healthy, two-of-three QUORUM is calculated from those.

If however one of the three primaries is down, read QUORUM is a bit
different:
1) if the first two replies come from the two remaining primaries and
agree, the is returned
2) if the first two replies are a primary and the "hot spare" and those
agree, that is returned
3) if the primary and hot spare disagree, wait for the next primary to
return, and then take the agreement (hopefully) that results

Then once the previous primary comes back online, the read quorum goes back
to preferring that set, with the assuming hinted handoff and repair will
get it back up to snuff.

There could also be some mechanism examining the hinted handoff status of
the four to determine when to reactivate the primary that was down.

For mutations, one could prefer a "QUORUM plus" that was a quorum of the
primaries plus the hot spare.

Of course one could do multiple hot spares, so RF5 could still be treated
as RF3 + hot spares.

The goal here is more data resiliency but not having to rely on as many
nodes for resiliency.

Since the data is ring-distributed, the fact there are primary owners of
ranges should still be evenly distributed and no hot nodes should result

A JIRA proposing a seperate repository for the online documentation

[Kenneth Brotman]

https://issues.apache.org/jira/browse/CASSANDRA-14313

 

For some reason I'm told by many committers that we should not have sets of
documentation for other versions than the current version in a tree for that
version.  This has made it difficult, maybe impossible to have documentation
for all the supported versions on the website at one time.  

 

As a solution I propose that we maintain the online documentation in a
separate repository that is managed as the current repository under the
guidance of the Apache Cassandra PMC (Project Management Committee); and
that in the new repository . . .

 

Please see the jira.  I hope it's a good answer to everyone.

 

KennethBrotman

 

 

RE: Pull request question

[Kenneth Brotman]

Thanks.  Something is not working right or I have brain fog.  I tried twice.  
Got unwanted results each time so I closed the pull requests with uncommitted 
merges.  I hope that is okay.  Here is the JIRA: 
https://issues.apache.org/jira/browse/CASSANDRA-14312

I must need to do something to sync my repository back up with the Apache 
Cassandra mirror site.  The pull requests were trying to bring over a bunch of 
other files.

Thanks for the reply.

Kenneth Brotman

-Original Message-
From: Dinesh Joshi [mailto:dinesh.jo...@yahoo.com.INVALID] 
Sent: Tuesday, March 13, 2018 11:13 PM
To: dev@cassandra.apache.org
Subject: Re: Pull request question

Hi Kenneth,
Normally you would open a Jira ticket and put the details in there including a 
link to your branch, pull request or patch. Is this pull request associated 
with a jira? If so, could you please point us to it? And yes, normally you 
would send pull requests against trunk unless they're for fixes to particular 
versions of Cassandra.
Dinesh 

On Tuesday, March 13, 2018, 10:48:22 PM PDT, Kenneth Brotman 
 wrote:  
 
 I made some sub directories and files so we could start to work on having 
separate versions of documentation.  I did the pull request to the truck.
Was that right?

 

Kenneth Brotman

  


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

Re: Pull request question

[Dinesh Joshi]

Hi Kenneth,
Normally you would open a Jira ticket and put the details in there including a 
link to your branch, pull request or patch. Is this pull request associated 
with a jira? If so, could you please point us to it? And yes, normally you 
would send pull requests against trunk unless they're for fixes to particular 
versions of Cassandra.
Dinesh 

On Tuesday, March 13, 2018, 10:48:22 PM PDT, Kenneth Brotman 
 wrote:  
 
 I made some sub directories and files so we could start to work on having
separate versions of documentation.  I did the pull request to the truck.
Was that right?

 

Kenneth Brotman