[Tarantool-patches] [PATCH v3 0/4] replication: fix applying of rows originating from local instance
Georgy Kirichenko
kirichenkoga at gmail.com
Sun Feb 23 11:16:12 MSK 2020
Please do not think you are the only person who knows about byzantine faults.
Also there is little relevance between byzantine faults and my suggestion to
enforce replica-side checking.
In any case filtering on the master side is the most worst thing we could do.
In this case master has only one peer and have no chance to make a proper
decision if replica is broken. And we have no chance to know about it (except
assert which are excluded from release builds, or panic messages). For
instance if master skipped some rows then there are no any tracks of the
situation we could detect.
In the opposite case a replica could connect to as many masters as they need
to filter out all invalid data or hacked masters. At least we could enforce
replication stream meta checking.
Two major point I would like to mention are:
1. Replica could consistently follow all vclock members and apply all
transactions without gaps (I already got rid of them, I hope you remember)
2. Replica could protect itself against concurrent local writes (one was made
locally, the second one is returned from master)
On Saturday, February 22, 2020 11:49:30 PM MSK Konstantin Osipov wrote:
> * Georgy Kirichenko <kirichenkoga at gmail.com> [20/02/22 23:22]:
> > On Tuesday, February 18, 2020 8:37:03 PM MSK Serge Petrenko wrote:
> > Hi! Thanks for the patch.
> > I am pretty sure replica should be able to apply all replication stream
> > transaction in a proper way without any reliance on a master correctness.
> > Or signal an error if this is impossible. I am suggesting such logic
> > because a replica has the complete information about it own at the
> > moment. This includes local vclock, cfg, all existing appliers state and
> > incoming streams.
> It's an impossible and useless pursuit.
>
> Please read up on byzantine faults.
More information about the Tarantool-patches
mailing list