Schema Tracking Refactor: Merge schema-tracking in health-streamer into schema.Engine#13121
Conversation
Signed-off-by: Manan Gupta <manan@planetscale.com>
…in vttablets Signed-off-by: Manan Gupta <manan@planetscale.com>
…amer Signed-off-by: Manan Gupta <manan@planetscale.com>
…reload Signed-off-by: Manan Gupta <manan@planetscale.com>
…s as well Signed-off-by: Manan Gupta <manan@planetscale.com>
…it correctly Signed-off-by: Manan Gupta <manan@planetscale.com>
…ine instead of detecting the schema changes on its own Signed-off-by: Manan Gupta <manan@planetscale.com>
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
If a new flag is being introduced:
If a workflow is added or modified:
Bug fixes
Non-trivial changes
New/Existing features
Backward compatibility
|
…formation in a database Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
…at are removed Signed-off-by: Manan Gupta <manan@planetscale.com>
|
|
||
| // StreamTabletHealthUntil invokes a HealthStream on a local cluster Vttablet and | ||
| // returns the responses. It waits until a certain condition is met. The amount of time to wait is an input that it takes. | ||
| func (cluster *LocalProcessCluster) StreamTabletHealthUntil(ctx context.Context, vttablet *Vttablet, timeout time.Duration, condition func(shr *querypb.StreamHealthResponse) bool) error { |
There was a problem hiding this comment.
there are existing usages of StreamTabletHealth can those also use this utility function?
There was a problem hiding this comment.
There is an inherent difference between the two. StreamTabletHealth gets you specified number of stream responses back, which can then be processed. On the other hand StreamTabletHealthUntil is meant to be used where the test doesn't care if we consume more responses and only verifies if a certain check is ever true.
The tests currently using StreamTabletHealth actually can't really use StreamTabletHealthUntil because they want to run a test on the next packet, and not an eventual packet.
| func (vtctldclient *VtctldClientProcess) PlannedReparentShard(Keyspace string, Shard string, alias string) (err error) { | ||
| output, err := vtctldclient.ExecuteCommandWithOutput( | ||
| "PlannedReparentShard", | ||
| fmt.Sprintf("%s/%s", Keyspace, Shard), | ||
| "--new-primary", alias) | ||
| if err != nil { | ||
| log.Errorf("error in PlannedReparentShard output %s, err %s", output, err.Error()) |
There was a problem hiding this comment.
there are other places as well we are doing this call, like InitializeShard can it be reused
There was a problem hiding this comment.
We could, but eventually we want to move to using vtctldclient and not vtctlclient. So I thought it prudent to add a PRS call to vtctldclient. This is what we should be using going forward in all our tests.
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
Signed-off-by: Manan Gupta <manan@planetscale.com>
harshit-gangal
left a comment
There was a problem hiding this comment.
looks good overall. this is a significant improvement on the schema engine and more cleaner code and also fixes the issue with view change tracking.
Signed-off-by: Manan Gupta <manan@planetscale.com>
Description
This PR refactors schema tracking to merge the schema tracking in
healthstreamerintoschema.Engine.We still have the schema tracking in
healthstreameraround because of backward compatibility, which we will remove in a later release. However, we have removed the ticker on which we would run thereloadfunction and instead do it in response to a signal from theschema.Engine.The schema tracking introduced in
schema.Enginestores a little more information than what we had inhealthstreamerto support the upcoming use case of #12967.This PR also fixes the issue described in #13182. Now, we all the health streamer to write to the database only when the tablet is in a primary serving state. So, when the call to
tm.QueryServiceControl.SetServingTypesucceeds, we can now guarantee that the health streamer will not be writing anything anymore.Website docs - vitessio/website#1487
Related Issue(s)
Checklist
Deployment Notes