This logic already existed in go/cmd/vttablet/healthz.go for /healthz, but
did not exist for broadcastHealth() and did not exist for deciding whether
to return a cached health value to a newly-connected streaming health client.
Signed-off-by: David Weitzman <dweitzman@pinterest.com>
The row streamer needed to refresh credentials before connecting
to mysql.
Also fixed some flaky tests.
Signed-off-by: Sugu Sougoumarane <ssougou@gmail.com>
In this change the query routing takes the possibility that
there could be multiple target options for a given table. The
design for this is explained in #4790.
At a high level:
* VSchema.FindTableOrVindex function can return a list of
tables instead of a single one.
* The route planbuilder creates multiple routeOptions, one
for each table returned.
* All actions that affected the plan of a route are changed
to update all routeOptions.
* If a particular routeOption cannot accommodate a pushed
down construct, it's removed from the list. Previously,
this was an error case. But if no options are left, then
we return an error.
* If two routeOptions qualify for a merge of routes, then
all other combinations that don't qualify are discarded.
This is the case for joins, subqueries and unions.
More details:
vindexTable was renamed to the more appropriate vschemaTable.
In order to achieve this, a new routeOption data type was
introduced, and route was changed to contain a list of
routeOptions.
In symtab, tables used to point at the vschema table that
was used to build them. Since a table can now represent
multiple target tables, this field has been moved into
routeOption.
In symtab, columns used to contain a vindex member. Since
this can change depending on the target table, the routeOption
now contains a map of column to vindexes instead.
The routeOption also contains the vschemaTable. DMLs use
this information. Since DMLs have to be more deterministic
about the table they write to, they always choose the
first option.
At the beginning of the Wireup phase, we evaluate all existing
options and decide on the best available.
To be done:
When a table has multiple targets, the targets can have different
names than the original table. If so, the queries have to be
rewritten to address the new target tables. In order to do this,
each routeOption will contain a list of substitutions that will
be made during the Wireup phase.
Tests have to be written for the new flows.
Signed-off-by: Sugu Sougoumarane <ssougou@gmail.com>
This is the first part of the changes to implement #4790.
This part implements all the management functionality for
routing rules.
Signed-off-by: Sugu Sougoumarane <ssougou@gmail.com>
This is an alternate and experimental version where we replace
the vtworker SplitClone and VerticalSplitClone with a vreplication
based approach.
I want to get this submitted so people can try this and provide
feedback. If the performance is acceptable, then we can solidify
this with more checks and tests.
Signed-off-by: Sugu Sougoumarane <ssougou@gmail.com>
The previous (untested) implementation turned out to be in the wrong
place in the TabletServer execution tier and did not properly log
the actual statements being executed.
Implement this the right way by returning the statements that were
really executed out from the TxPool, then using those to determine
whether or not to log the statement.
Signed-off-by: Michael Demmer <mdemmer@slack-corp.com>
Mark Solters
Sugu Sougoumarane
Michael Demmer
SataQiu
David Weitzman
deepthi
xichengliudui
Michael Demmer
Rafael Chacon
Alex Charis
Máximo Cuadros