We can retire the DLR. However, the async wal replication feature for the region replicas depends on the replay code paths in HRegion. In short, the WAL is tailed from primary, and gets replayed from the secondary ( https://issues.apache.org/jira/browse/HBASE-11568). We cannot strip those parts out, but we can get rid of the assignment and some of the other machinery.
Enis On Fri, Aug 21, 2015 at 12:13 PM, Vladimir Rodionov <[email protected]> wrote: > Do you guys mean WALPlayer? It seems - no. What code are you referring to? > > -Vlad > > On Fri, Aug 21, 2015 at 11:45 AM, Stack <[email protected]> wrote: > > > DLR is a good idea. We need it. It helps with our MTTR. > > > > +1 though on pulling the current DLR. Perhaps the current set of issues > > could be fixed with some concentrated dev but even then, I'd be wary > > turning it on. It is hard to track, distributed all over the code base, > and > > it extends a foundation that is itself a little shakey (our AM and crash > > handling, currently for redo). > > > > A purge would get rid of a bunch of if/else code and the dropping of > > 'special' staging sequence files on region open. > > > > Lets purge now then come back later with a DLRv2. > > > > St.Ack > > > > > > On Fri, Aug 21, 2015 at 8:45 AM, Sean Busbey <[email protected]> > wrote: > > > > > What do folks think about removing the current implementation of > > > Distributed Log Replay? > > > > > > The feature has been unstable for a long time and it doesn't look like > > > getting it ready for prime time is a priority for anyone right now. As > it > > > currently stands, it seems like a dangerous sharp edge waiting for any > > > unfortunate souls who opt to turn it on. > > > > > > We could make a tag or perhaps a feature branch that marks the current > > > state of the code in trunk, just in case the eventual implementor(s) > want > > > to start from this code rather than a ground-up redo. > > > > > > -- > > > Sean > > > > > >
