Hi, All nodes being the same (in terms of functionality) is something we wanted to stick with at least for now. I think we want a design that changes the operational, availability, and consistency story as little as possible when it's completed.
Ariel On Fri, Aug 31, 2018, at 2:27 PM, Carl Mueller wrote: > SOrry to spam this with two messages... > > This ticket is also interesting because it is very close to what I imagined > a useful use case of RF4 / RF6: being basically RF3 + hot spare where you > marked (in the case of RF4) three nodes as primary and the fourth as hot > standby, which may be equivalent if I understand the paper/protocol to > RF3+1 transient. > > On Fri, Aug 31, 2018 at 1:07 PM Carl Mueller <carl.muel...@smartthings.com> > wrote: > > > I put these questions on the ticket too... Sorry if some of them are > > stupid. > > > > So are (basically) these transient nodes basically serving as centralized > > hinted handoff caches rather than having the hinted handoffs cluttering up > > full replicas, especially nodes that have no concern for the token range > > involved? I understand that hinted handoffs aren't being replaced by this, > > but is that kind of the idea? > > > > Are the transient nodes "sitting around"? > > > > Will the transient nodes have cheaper/lower hardware requirements? > > > > During cluster expansion, does the newly streaming node acquiring data > > function as a temporary transient node until it becomes a full replica? > > Likewise while shrinking, does a previously full replica function as a > > transient while it streams off data? > > > > Can this help vnode expansion with multiple concurrent nodes? Admittedly > > I'm not familiar with how much work has gone into fixing cluster expansion > > with vnodes, it is my understanding that you typically expand only one node > > at a time or in multiples of the datacenter size > > > > On Mon, Aug 27, 2018 at 12:29 PM Ariel Weisberg <ar...@weisberg.ws> wrote: > > > >> Hi all, > >> > >> I wanted to give everyone an update on how development of Transient > >> Replication is going and where we are going to be as of 9/1. Blake > >> Eggleston, Alex Petrov, Benedict Elliott Smith, and myself have been > >> working to get TR implemented for 4.0. Up to now we have avoided merging > >> anything related to TR to trunk because we weren't 100% sure we were going > >> to make the 9/1 deadline and even minimal TR functionality requires > >> significant changes (see 14405). > >> > >> We focused on getting a minimal set of deployable functionality working, > >> and want to avoid overselling what's going to work in the first version. > >> The feature is marked explicitly as experimental and has to be enabled via > >> a feature flag in cassandra.yaml. The expected audience for TR in 4.0 is > >> more experienced users who are ready to tackle deploying experimental > >> functionality. As it is deployed by experienced users and we gain more > >> confidence in it and remove caveats the # of users it will be appropriate > >> for will expand. > >> > >> For 4.0 it looks like we will be able to merge TR with support for normal > >> reads and writes without monotonic reads. Monotonic reads require blocking > >> read repair and blocking read repair with TR requires further changes that > >> aren't feasible by 9/1. > >> > >> Future TR support would look something like > >> > >> 4.0.next: > >> * vnodes (https://issues.apache.org/jira/browse/CASSANDRA-14404) > >> > >> 4.next: > >> * Monotonic reads ( > >> https://issues.apache.org/jira/browse/CASSANDRA-14665) > >> * LWT (https://issues.apache.org/jira/browse/CASSANDRA-14547) > >> * Batch log (https://issues.apache.org/jira/browse/CASSANDRA-14549) > >> * Counters (https://issues.apache.org/jira/browse/CASSANDRA-14548) > >> > >> Possibly never: > >> * Materialized views > >> > >> Probably never: > >> * Secondary indexes > >> > >> The most difficult changes to support Transient Replication should be > >> behind us. LWT, Batch log, and counters shouldn't be that hard to make > >> transient replication aware. Monotonic reads require some changes to the > >> read path, but are at least conceptually not that hard to support. I am > >> confident that by 4.next TR will have fewer tradeoffs. > >> > >> If you want to take a peek the current feature branch is > >> https://github.com/aweisberg/cassandra/tree/14409-7 although we will be > >> moving to 14409-8 to rebase on to trunk. > >> > >> Regards, > >> Ariel > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
