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?

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?

Regards,
-- 
Ilya Kasnacheev


чт, 25 апр. 2019 г. в 16:55, Sergey Kozlov <skoz...@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
>

Reply via email to