-
Notifications
You must be signed in to change notification settings - Fork 9
Fix bug in vtgate when running with keyspace filtering #199
Conversation
Signed-off-by: Richard Bailey <rbailey@slack-corp.com>
Signed-off-by: Richard Bailey <rbailey@slack-corp.com>
Signed-off-by: Richard Bailey <rbailey@slack-corp.com>
Signed-off-by: Richard Bailey <rbailey@slack-corp.com>
This makes sense to me. In other words, if I'm reading this correctly: if you have filters on, you can't safely access the topo because it doesn't have the full view. For the context of online DDL's, you need the full topo, so you need to make sure that you run them from a vtgate that is not filtering. |
go/vt/vtgate/vcursor_impl.go
Outdated
@@ -477,6 +490,9 @@ func (vc *vcursorImpl) TabletType() topodatapb.TabletType { | |||
|
|||
// SubmitOnlineDDL implements the VCursor interface | |||
func (vc *vcursorImpl) SubmitOnlineDDL(onlineDDl *schema.OnlineDDL) error { | |||
if vc.topoServer == nil { | |||
return vterrors.New(vtrpcpb.Code_INTERNAL, "Unable to apply DDL, missing toposerver in vcursor") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one nit - this error might be too cryptic for an end user. I wonder if we should mention that probably they have a keyspace filter and that is incompatible with online DDLs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough -- I referenced filtered keyspaces in the error but since it's a bit indirect i'm going to leave the general commentary around why the failure is happening as well.
More or less. Technically I don't actually think it needs the full topo, the impl for writing the request into topo looks like:
which has a limited impact -- it's writing only to the |
Taking your 👍 as a Ship it to merge this branch down, feel free to claw it back if we don't want to roll this out |
This checks if a vtgate is currently filtering keyspaces before requesting the TopoServer. This is necessary because a TopoServer can't be accessed in those cases as the filtered Topo in those cases could make it unsafe to make writes since all reads would be returning a subset of the actual topo data. The only use of the requested topoServer that I found was in the DDL handling path and was introduced in vitessio#6547. This is deployed on dev but should get testing (endtoend or unit, unclear on best path atm) before going upstream.
This checks if a vtgate is currently filtering keyspaces before requesting the TopoServer. This is necessary because a TopoServer can't be accessed in those cases as the filtered Topo in those cases could make it unsafe to make writes since all reads would be returning a subset of the actual topo data. The only use of the requested topoServer that I found was in the DDL handling path and was introduced in vitessio#6547. This is deployed on dev but should get testing (endtoend or unit, unclear on best path atm) before going upstream. # Conflicts: # go/vt/vtgate/vcursor_impl.go Signed-off-by: Richard Bailey <rbailey@slack-corp.com>
This checks if a vtgate is currently filtering keyspaces before requesting the TopoServer. This is necessary because a TopoServer can't be accessed in those cases as the filtered Topo in those cases could make it unsafe to make writes since all reads would be returning a subset of the actual topo data. The only use of the requested topoServer that I found was in the DDL handling path and was introduced in vitessio#6547. This is deployed on dev but should get testing (endtoend or unit, unclear on best path atm) before going upstream. # Conflicts: # go/vt/vtgate/vcursor_impl.go Signed-off-by: Richard Bailey <rbailey@slack-corp.com>
Description
This checks if a vtgate is currently filtering keyspaces before requesting the TopoServer. This is necessary because a TopoServer can't be accessed in those cases as the filtered Topo in those cases could make it unsafe to make writes since all reads would be returning a subset of the actual topo data.
The only use of the requested topoServer that I found was in the DDL handling path and was introduced in vitessio#6547.
This is deployed on dev but should get testing (endtoend or unit, unclear on best path atm) before going upstream.