This repository has been archived by the owner on Sep 30, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
support for
PseudoGTIDPreferIndependentMultiMatch
This is an optional step back in grouping/bucketing multiple servers in a Pseudo-GTID operation, such as
match-replicas
orrelocate-replicas
orregroup-replicas-pgtid
.What I've evidenced is that many times grouping servers in a Pseudo-GTID operation reduces overall match time:
orchestrator
optimizes for less binary log inspection, less Pseudo-GTID search & computation, applying computed changes onto servers in same bucket.However, a particular case that I'm facing now involves multi-DC servers who happen to be on same Pseudo-GTID bucket. They are very frequently grouped in the same bucket. However cross-DC network has such latency that if local servers need to wait on a remote server to do computation, there is substantial delay in matching those local servers.
In this case it is more beneficial to independently match servers one at a time. There will be waste of search, more binlog inspection on the master of given replicas. But each server would relocate as soon as possible (granted, said overhead may add latency to each operation).
In this case overall operation time may be longer; sum of "wait time" for each replica may be longer, but some replicas may relocate quicker than they would with the grouping solution.
everything in life is a compromise, and fortunately we are able to set a flag to control the behavior we want. I am nonetheless on the hunt to reduce number of flags, but this will happen on another iteration.
The new variable
PseudoGTIDPreferIndependentMultiMatch
is introduced, and is backwards compatible (defaultsfalse
). Set totrue
to enable per-replica independent relocation on bulk operations such asmatch-replicas
,relocate-replicas
etc.