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 > > > > > >>>> > > > > > >>>> > > > > > > > > > > > > > > > > > > > > >
