Re: Making RF4 useful aka primary and secondary ranges
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 Muellerwrote: > 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
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 Brotmanwrote: > 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
Since this is basically driver syntactic sugar... Yes I'll try that. On Wed, Mar 14, 2018 at 5:59 PM, Jonathan Haddadwrote: > 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
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 Muellerwrote: > 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
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 Jirsawrote: > 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
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
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 Muellerwrote: > 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
For my reference: https://issues.apache.org/jira/browse/CASSANDRA-7168 On Wed, Mar 14, 2018 at 4:46 PM, Ariel Weisbergwrote: > 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
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
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
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
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 Brotmanwrote: 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
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 Brotmanwrote: 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