I introduced the issue in f86bb90119 where
I changed discovery.WaitForEndPoints() to require a Go context.
In case of a reparent (e.g. moving away from the current master to
slave/spare), the binlog player will be reset/stopped.
As part of that, its context will be cancelled. The same context is used
within Iteration() to wait for the list of healthy endpoints
(WaitForEndPoints()). Due to the cancelled context, WaitForEndPoints() will always return with an error and
therefore Iteration() will
never break out of Loop(). To fix this, I'm checking at the beginning of
Iteration() if the context is still valid.
I've also extended WaitForEndPoints to return a different error when it
actually did not timeout.
The command blocks until a QPS rate of 0.0 was observed on all selected tablets.
The command uses the healthcheck module to continously check the current health of all tablets.
Added an integration (wait_for_drain_test.go) and end2end test (in tabletmanager.py).
This is necessary when multiple Healthcheck structs are instantiated, for example when a vtctl command contacts multiple cells simultaneously. In that case, the stats suffix could be the cell name.
This is the first installment for the new v3 analysis. This change
analyzes just the FROM clause, without the ON clauses, and identifies
possible chunks. For now, chunks are possible only for unsharded
keyspaces. Once we add ON clause analysis, we'll be able to find
chunks for sharded keyspaces also.
The new functions are currently not called from anywhere. There
are some basic unit tests for now, which will also be evolved as
functionality grows.
This way we are consistent and all healthcheck related flags are properly grouped.
vttablet: Split up flag "binlog_player_retry_delay" into the existing flag and "binlog_player_healthcheck_retry_delay". Now the two flags are used for two different purposes. Similar to the worker code, all healthcheck flags are properly grouped now.
This avoids confusing it with a "ctx" variable.
(ctw probably once was the correct receiver name because TopologyWatcher was once called CellTopologyWatcher?)
Renamed strategy flag from "-populate_blp_checkpoint" to
"-skip_populate_blp_checkpoint".
Since it's on by default now, I've removed all occurrences where the old
flag was set explicitly.
PHP is not very good at differentiating strings from ints. So,
we have to be more forgiving, especially when strings are received
where ints are expected.
For now, I'm allowing just this. Other implicit type conversions
are unsafe. In particular, 0x... notation is treated differently
in MySQL for strings.
These were logged originally to verify that contention was rare.
If it turned out to be common in practice, we should go back to
pessimistic locking.
Contention on the serving graph has indeed been rare, but when it does
happen, these messages are confusing because they seem to indicate a
problem.
The select subquery in insert...select was not locking rows. This
introduces race conditions for self-join inserts like select(max).
So, it's safer to lock the rows we're selecting.
v3 didn't handle []byte bind vars correctly. This fails
only in situations when there's more than one bind var of
[]byte type. I've now added a test for this specific case.
- Schema of destination tablet never must be empty.
- During CopySchemaShard, the schema of the destination changes and the fake must reflect this properly. Added SchemaFunc to FakeMysqlDaemon to realize this.
Although the copy was successful, we have to verify it to catch the case where the database already existed on the destination, but with different options e.g. a different character set.
In that case, MySQL would have skipped our CREATE DATABASE IF NOT EXISTS statement. We want to fail early in this case because vtworker SplitDiff fails in case of such an inconsistency as well.
schemamanager: Log warning that the flag is set only if it's actually a big schema.
Added integration test using VtctlPipe. The test is based on copy_schema_shard_test.go.
There is currently no big schema change support in open source;
therefore, it is better to allow schema manager to do big schema changes
without enfocing 100,000 rows limit. Add flag "-force" for vtctl command
"ApplySchema" so it accepts big schema changes.
Fix issues in MigrateServedTypes actuator/task ("cell" -> "cells",
reordered parameters such that the vtctld address is the last one).
automation unit tests: Check that all fake results were consumed.
fake vtctl client: Added support for registering the same result for the
same command multiple times. The reference count is decreased every time
the result is streamed.
NOTE: This is an automated export. Changes were already LGTM'd internally.
One vtworker command may be very long running (on the order of days). If the command is executed via an RPC, the output of the command is currently only stored in memory. There are several situations where this output may get lost halfway:
- if vtworker crashes
- if the consumer crashes and vtworker gets reset
From an operations perspective, we want avoid this and preserve the output instead.
Therefore, the output of each RPC will be logged to the console (and consequently, depending on the flags of the Go log package, to a file as well).
NOTE: The previous code also set a NewMemoryLogger() for the Wrangler. But this wasn't actually necessary.
I confused sql.Open() with sql.Driver.Open(). The first one is the general Go interface which still requires db.Ping() to check if a connection works. Driver.Open() is not related to this at all. (It gets called when the Go sql package actually opens the connection e.g. when db.Ping() is called.)
I've included generic information about Vitess and also more details on vtgate for the following reasons:
My goal is to list our Go SQL driver here: https://github.com/golang/go/wiki/SQLDrivers
If we get listed, it will link to: https://github.com/youtube/vitess/tree/master/go/vt/
Somebody who clicks the link, will see the content of README.md first and this will be their initial contact with Vitess. From there, they'll hopefully go to vitess.io or the godoc page :)
Fixed testing streaming queries in v3 mode ("streaming" option got accidentally lost when I added the v2 mode).
Added support for streaming queries for v2 mode in test.
Before this change, the tests did test the implementation itself without going through the Go SQL interface. I think this change makes more sense because we test now the behavior through the SQL interface and that's what the user is expecting in the first place.
Other changes:
- used test description in test errors
- replaced t.Errorf with t.Fatalf where it made sense
This is more explicit. The Go "sql" package also talks about "drivers": https://golang.org/pkg/database/sql/
To get a sense how other drivers are named, here's a list: https://github.com/golang/go/wiki/SQLDrivers
We decided to have "vitess" in the name as well to make it clear in application code that this is the Vitess Go SQL driver.
also: Renamed main files from client*.go to driver*.go.
Michael Berlin
Anthony Yeh
Shawn Smith
Ammar Aijazi
Ammar Aijazi
Alain Jobart
Liang
sougou
Alain Jobart
thompsonja
Joshua Thompson
Rasta
Shengzhe Yao
Matt Harden
Yim