ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vyacheslav Daradur <daradu...@gmail.com>
Subject Re: AI 3.0: writeSynchronizationMode re-thinking
Date Thu, 25 Apr 2019 15:39:50 GMT
Hi, Sergey,

Makes sense to me in case of performance issues, but may lead to losing data.

>> *by the new option *syncPartitions=N* (not best name just for referring)

Seems similar to "Write Concern"[1] in MongoDB. It is used in the same
way as you described.

On the other hand, if you have such issues it should be investigated
first: why it causes performance drops: network issues etc.

[1] https://docs.mongodb.com/manual/reference/write-concern/

On Thu, Apr 25, 2019 at 6:24 PM Sergey Kozlov <skozlov@gridgain.com> wrote:
>
> Ilya
>
> See comments inline.
> On Thu, Apr 25, 2019 at 5:11 PM Ilya Kasnacheev <ilya.kasnacheev@gmail.com>
> wrote:
>
> > Hello!
> >
> > When you have 2 backups and N = 1, how will conflicts be resolved?
> >
>
> > Imagine that you had N = 1, and primary node failed immediately after
> > operation. Now you have one backup that was updated synchronously and one
> > which did not. Will they stay unsynced, or is there any mechanism of
> > re-syncing?
> >
>
> Same way as Ignite processes the failures for PRIMARY_SYNC.
>
>
> >
> > Why would one want to "update for 1 primary and 1 backup synchronously,
> > update the rest of backup partitions asynchronously"? What's the use case?
> >
>
> The case to have more backups but do not pay the performance penalty for
> that :)
> For the distributed systems one backup looks like risky. But more backups
> directly impacts to performance.
> Other point is to split the strict consistent apps like bank apps and the
> other apps like fraud detection, analytics, reports and so on.
> In that case you can configure partitions distribution by a custom affinity
> and have following:
>  - first set of nodes for critical (from consistency point) operations
>  - second set of nodes have async backup partitions only for other
> operations (reports, analytics)
>
>
>
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 25 апр. 2019 г. в 16:55, Sergey Kozlov <skozlov@gridgain.com>:
> >
> > > Igniters
> > >
> > > I'm working with the wide range of cache configurations and found (from
> > my
> > > standpoint) the interesting point for the discussion:
> > >
> > > Now we have following *writeSynchronizationMode *options:
> > >
> > >    1. *FULL_ASYNC*
> > >       -  primary partition updated asynchronously
> > >       -  backup partitions updated asynchronously
> > >    2. *PRIMARY_SYNC*
> > >       - primary partition updated synchronously
> > >       - backup partitions updated asynchronously
> > >    3. *FULL_SYNC*
> > >       - primary partition updated synchronously
> > >       - backup partitions updated synchronously
> > >
> > > The approach above is covering everything if you've 0 or 1 backup.
> > > But for 2 or more backups we can't reach the following case (something
> > > between *PRIMARY_SYNC *and *FULL_SYNC*):
> > >  - update for 1 primary and 1 backup synchronously
> > >  - update the rest of backup partitions asynchronously
> > >
> > > The idea is to join all current modes into single one and replace
> > > *writeSynchronizationMode
> > > *by the new option *syncPartitions=N* (not best name just for referring)
> > > covers the approach:
> > >
> > >    - N = 0 means *FULL_ASYNC*
> > >    - N = (backups+1) means *FULL_SYNC*
> > >    - 0 < N < (backups+1) means either *PRIMARY_SYNC *(N=1) or new mode
> > >    described above
> > >
> > > IMO it will allow to make more flexible and consistent configurations
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com



-- 
Best Regards, Vyacheslav D.

Mime
View raw message