Hi, all WAL modes except NONE protects from data consistency problem (B+Tree, pages, etc), which is why I suggest to avoid saying 'corrupted' about 'unapplied updates'.
Log Only and Background may cause unapplied updates in case of OS/process failures. None mode IMO is not an option in case data consistency is needed. пт, 16 февр. 2018 г. в 20:49, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Guys, > > While we're on this topic, what is the difference between BACKGROUND and > NONE in terms of semantics and provided guarantees? To me it looks like > both guarantee to recover the state since last checkpoint and anything else > can potentially be lost, so from user perspective they are the same. Am I > missing something here? > > Also there is the following in Javadoc for NONE: "If an Ignite node is > terminated in NONE mode abruptly, it is likely that the data stored on disk > is corrupted and work directory will need to be cleared for a node > restart.". If this is really the case, I'm not sure NONE makes sense at > all. Why would I enable persistence if I'm likely to clear the storage on > restart? > > -Val > > On Fri, Feb 16, 2018 at 8:39 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > What is the reason to have DEFAULT mode at all if you claim LOG_ONLY to > be > > completely safe? :) > > > > And how it could be safe provided that without fsync we loose part of WAL > > itself in case of crash? > > > > пт, 16 февр. 2018 г. в 19:32, Dmitry Pavlov <dpavlov....@gmail.com>: > > > > > Thank you. Data can't be corrupted in case crash because of WAL replay > > > (since completed checkpoint). Physical records are used to restore > > probably > > > corrupted pages in persistent store (we overwrite so called 'grey > zone' - > > > pages we don't know for sure if they have been written). > > > > > > Only one effect is unwritten one or several last transactions. It is > not > > > the same with corrupted data. > > > > > > пт, 16 февр. 2018 г. в 19:19, Vladimir Ozerov <voze...@gridgain.com>: > > > > > > > Log only mode is not safe - data might be corrupted in case of system > > > > crash. Oracle - fsync, Postgres - fsync, SQL Server - fsync, > Cassandra > > - > > > > similar to our “background”. > > > > > > > > пт, 16 февр. 2018 г. в 19:11, Dmitry Pavlov <dpavlov....@gmail.com>: > > > > > > > > > Hi Vladimir, > > > > > > > > > > What you saying is defenetely make sence. > > > > > > > > > > In the same time LOG_ONLY is also safe mode, user will be able to > > > restore > > > > > system after crash. If it is not true, we should create critical > > ticket > > > > and > > > > > fix it. > > > > > > > > > > Do you know other databases defaults, such as Cassandra, Oracle, > > > Postgre? > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > пт, 16 февр. 2018 г. в 18:41, Vladimir Ozerov < > voze...@gridgain.com > > >: > > > > > > > > > > > Igniters, > > > > > > > > > > > > Sorry for pouring oil on the flames, but from database > perspective > > > > moving > > > > > > from FSYNC to non-FSYNC mode appears to be a mistake. When you > work > > > > with > > > > > > database, your main expectation is that it will save your data. > All > > > > > > production database vendor make sure that you are safe, not that > > you > > > > are > > > > > > fast. Moreover, some vendors even prevent you from being in > unsafe > > > mode > > > > > > (e.g. you cannot disable fsync in SQL Server at all). > > > > > > > > > > > > If we continue going in this direction, we will end up with a > > > product, > > > > > > which is unsafe out of the box and require tons of documentation > to > > > > > > understand how to make it safe. Definitely not the right message > to > > > the > > > > > > market. This is like a car without brakes - would you like to > drive > > > it? > > > > > If > > > > > > this is Need For Speed game and you have unlimited lives > (in-memory > > > > cache > > > > > > with backing store), then yes. If this is a real life with > > > > (persistence) > > > > > - > > > > > > then no. > > > > > > > > > > > > On Fri, Feb 16, 2018 at 5:20 PM, Dmitriy Setrakyan < > > > > > dsetrak...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > Well, I cannot say that I like the name LOG_ONLY, but I would > > vote > > > to > > > > > > keep > > > > > > > it for now, given that it is already documented in many places, > > > > blogs, > > > > > > and > > > > > > > examples. > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > On Fri, Feb 16, 2018 at 8:13 AM, Ivan Rakov < > > ivan.glu...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Looks like it's an Ignite term - I've never heard of it > outside > > > > > Ignite > > > > > > > > scope. > > > > > > > > > > > > > > > > Though, renaming existing enum value requires keeping old as > > > > > > deprecated. > > > > > > > > DEFAULT is confusing enough to pay this price. > > > > > > > > As for LOG_ONLY, I think we can keep it as long as it has > good > > > and > > > > > > > > definitive javadoc. > > > > > > > > > > > > > > > > Best Regards, > > > > > > > > Ivan Rakov > > > > > > > > > > > > > > > > > > > > > > > > On 16.02.2018 17:07, Dmitriy Setrakyan wrote: > > > > > > > > > > > > > > > >> Igniters, just to clarify, does the term LOG_ONLY mean > > anything > > > in > > > > > the > > > > > > > >> industry or is this just an Ignite term? > > > > > > > >> > > > > > > > >> D. > > > > > > > >> > > > > > > > >> On Fri, Feb 16, 2018 at 8:03 AM, Anton Vinogradov < > > > > > > > >> avinogra...@gridgain.com> > > > > > > > >> wrote: > > > > > > > >> > > > > > > > >> Log only mode: flushes application buffers. > > > > > > > >>> So, in synced mode without fsync guarantee. That's why I > > > propose > > > > to > > > > > > > >>> rename > > > > > > > >>> it as SYNC. > > > > > > > >>> > > > > > > > >>> On Fri, Feb 16, 2018 at 4:49 PM, Ilya Lantukh < > > > > > ilant...@gridgain.com > > > > > > > > > > > > > > >>> wrote: > > > > > > > >>> > > > > > > > >>> I am OK with either FSYNC or STRICT variant. > > > > > > > >>>> > > > > > > > >>>> LOG_ONLY name means "log without fsync". > > > > > > > >>>> > > > > > > > >>>> On Fri, Feb 16, 2018 at 4:05 PM, Dmitriy Setrakyan < > > > > > > > >>>> > > > > > > > >>> dsetrak...@apache.org> > > > > > > > >>> > > > > > > > >>>> wrote: > > > > > > > >>>> > > > > > > > >>>> On Fri, Feb 16, 2018 at 7:02 AM, Ivan Rakov < > > > > > ivan.glu...@gmail.com> > > > > > > > >>>>> > > > > > > > >>>> wrote: > > > > > > > >>>> > > > > > > > >>>>> Why create a new term to define something that has > already > > > been > > > > > > > >>>>>> > > > > > > > >>>>> defined? > > > > > > > >>>> > > > > > > > >>>>> That makes sense. I'm ok with FSYNC. > > > > > > > >>>>>> Anton, I don't understand why we should rename LOG_ONLY > to > > > > SYNC. > > > > > > We > > > > > > > >>>>>> started this discussion with bad naming of DEFAULT, but > > this > > > > has > > > > > > > >>>>>> > > > > > > > >>>>> nothing > > > > > > > >>>> > > > > > > > >>>>> to > > > > > > > >>>>> > > > > > > > >>>>>> do with LOG_ONLY (even though it may be scientific - but > > > SYNC > > > > > > sounds > > > > > > > >>>>>> scientific as well). > > > > > > > >>>>>> > > > > > > > >>>>>> I agree with Ivan, we should not go wild with renaming. > > > > > However, I > > > > > > > >>>>> > > > > > > > >>>> would > > > > > > > >>> > > > > > > > >>>> like to find out what is the meaning behind the LOG_ONLY > > name. > > > > Can > > > > > > > >>>>> > > > > > > > >>>> someone > > > > > > > >>>> > > > > > > > >>>>> explain? > > > > > > > >>>>> > > > > > > > >>>>> D. > > > > > > > >>>>> > > > > > > > >>>>> > > > > > > > >>>> > > > > > > > >>>> -- > > > > > > > >>>> Best regards, > > > > > > > >>>> Ilya > > > > > > > >>>> > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
