Conversation
Signed-off-by: Rafael Chacon <rafael@slack-corp.com>
Signed-off-by: Rafael Chacon <rafael@slack-corp.com>
* Prior to this commit, flavorpos was using lexicographical comparison of the gtids. Thas was a bug in this context. Signed-off-by: Rafael Chacon <rafael@slack-corp.com>
When generating masterGTIDSet in file:pos most likely you will have a topology like the following: Source A -> Target B (B has a vreplication stream from A) From the target perspective, the source A is the master and you want to generate a gtid that is based on binlog file position of that server. As an example, let's see this topology: Master A -> Source B -> Target C (C has vreplication stream from B) Prior to this change, masterGTIDSet was returning the binlogfile:pos of A. But in reality, the Target C wants the position of B. Signed-off-by: Rafael Chacon <rafael@slack-corp.com>
setassociative
left a comment
setassociative
left a comment
There was a problem hiding this comment.
This is an admittedly clumsy read through as it's large and I don't have deep knowledge of the existing vreplication/vdiff code but it feels good to me. Backed by extensive manual + testing I think this is good to merge.
|
|
||
| // The db name is set by the Start function called above | ||
| agent.VREngine = vreplication.NewEngine(ts, tabletAlias.Cell, mysqld, func() binlogplayer.DBClient { | ||
| agent.VREngine = vreplication.NewEngine(ts, tabletAlias.GetCell(), agent.Tablet(), mysqld, func() binlogplayer.DBClient { |
There was a problem hiding this comment.
Just to be clear when we agent.Tablet() we get a clone of the proto object at that point -- is there danger that it will change in the background in some meaningful way before we come through and run the vtdiff?
There was a problem hiding this comment.
Yeah, that is correct. There is no danger, because in this context we always assume that you will be running vdiff from the current tablet, against it's external source.
| healthcheckRetryDelay = flag.Duration("vreplication_healthcheck_retry_delay", 5*time.Second, "healthcheck retry delay") | ||
| healthcheckTimeout = flag.Duration("vreplication_healthcheck_timeout", 1*time.Minute, "healthcheck retry delay") | ||
| retryDelay = flag.Duration("vreplication_retry_delay", 5*time.Second, "delay before retrying a failed binlog connection") | ||
| onlyOnceVdiff sync.Once |
There was a problem hiding this comment.
it doesn't look like this is used -- is that intentional?
There was a problem hiding this comment.
oh good catch. This is from a previous incarnation when I did not have an api to control vdiff. Let me remove.
| // Wait for the conn.ExecuteFetch() call to return. | ||
| <-done | ||
| // Close the connection. Upon Recycle() it will be thrown out. | ||
| conn.Close() |
There was a problem hiding this comment.
Because you defer conn.Close() at the executeFetchContext call site this will happen twice. Safe to call multiple times but not sure if you want to leave it out of this code path.
There was a problem hiding this comment.
This one of the other things I had to copy from other places to make this work against an external database. This comes from: https://github.com/tinyspeck/vitess/blob/master/go/vt/mysqlctl/query.go#L98
* Address PR review + some other cleanup per linter Signed-off-by: Rafael Chacon <rafael@slack-corp.com>
2 participants
Description
Asks for reviewer