+1 to change PRIMARY_SYNC to FULL_SYNC. I think it is not reasonable to set readFromBackup=true by default, especially for replicated caches, but FULL_SYNCE will keep cache in consistent state.
2017-08-04 13:23 GMT+03:00 Anton Vinogradov <[email protected]>: > +1 to change PRIMARY_SYNC to FULL_SYNC and keep readFromBackup=true > > Dmitriy, > Why should we wait for 3.0? > This change looks safe for me. > > On Wed, Aug 2, 2017 at 9:51 PM, Dmitriy Setrakyan <[email protected]> > wrote: > > > We have to wait with any default changes to 3.0, unfortunately. > > > > On Wed, Aug 2, 2017 at 8:30 PM, Vladimir Ozerov <[email protected]> > > wrote: > > > > > Not sure about readFromBackup, but changing PRIMARY_SYNC to FULL_SYNC > > looks > > > safe to me. Any other thoughts? > > > > > > ср, 2 авг. 2017 г. в 21:10, Denis Magda <[email protected]>: > > > > > > > +1 for both suggestions but I’m not sure we can do the change till > 3.0. > > > > > > > > — > > > > Denis > > > > > > > > > On Aug 2, 2017, at 1:27 AM, Vladimir Ozerov <[email protected]> > > > > wrote: > > > > > > > > > > +1 for readFromBackup=false as well :-) Another example of default > > > value > > > > > with subtle effects. > > > > > > > > > > On Wed, Aug 2, 2017 at 11:11 AM, Alexey Goncharuk < > > > > > [email protected]> wrote: > > > > > > > > > >> Vladimir, > > > > >> > > > > >> Personally, I agree that we should put correctness over > performance, > > > > >> however (1) is not a correct statement for TRANSACTIONAL caches. A > > > > >> transactional client always validates the result of an operation > and > > > > throw > > > > >> a correct exception if operation failed. (1) is true for ATOMIC > > > caches, > > > > >> though. > > > > >> > > > > >> A user can get in trouble in this default for both TX and ATOMIC > > > caches > > > > if > > > > >> a put is performed from a backup node and readFromBackup is set to > > > > false. > > > > >> In this case, the simple read-after-write scenario may fail. I > would > > > > rather > > > > >> set readFromBackup to false by default, however, this fixes > neither > > > the > > > > SQL > > > > >> nor ATOMIC caches issues. > > > > >> > > > > >> +1 for the change, and extend the warning for partitioned caches > > with > > > > >> readFromBackup=true and PRIMARY_SYNC. > > > > >> > > > > >> > > > > >> > > > > >> 2017-08-02 10:58 GMT+03:00 Vladimir Ozerov <[email protected] > >: > > > > >> > > > > >>> Igniters, > > > > >>> > > > > >>> I want to re-iterate idea of changing default synchronization > mode > > > from > > > > >>> PRIMARY_SYNC to FULL_SYNC. > > > > >>> > > > > >>> Motivation: > > > > >>> 1) If user set [cacheMode=PARTITIONED, backups=1] he still could > > > loose > > > > >> data > > > > >>> silently. Because primary node could report success to the client > > and > > > > >> then > > > > >>> crash before data is propagated to backups. > > > > >>> 2) If user set [cacheMode=REPLICATED] and use SQL, he will might > > get > > > > >>> invalid results if cache is being updated concurrently - well > known > > > > >> issue. > > > > >>> > > > > >>> The only advantage of PRIMARY_SYNC is slightly better > performance, > > > but > > > > we > > > > >>> should prefer correctness over performance. > > > > >>> > > > > >>> Proposed changes: > > > > >>> 1) Make FULL_SYNC default; > > > > >>> 2) Print a warning about possibly incorrect SQL results if > > REPLICATED > > > > >> cache > > > > >>> is started in PRIMARY_SYNC mode. > > > > >>> > > > > >>> Thoughts? > > > > >>> > > > > >>> Vladimir. > > > > >>> > > > > >> > > > > > > > > > > > > > >
