- a reusable proto3 encoding / decoding class.
- the core gRPC code (includes query routing and error handling).
That way it's trivial to use proto3 on any other transport.
This is only necessary at the moment because gRPC 0.13 has a bug that
occurs when error messages contain newlines. However, we might as well
keep it this way because newlines in Go errors are not really
conventional anyway.
Some tests had to be modified to not assume that masters without
replicas will still accept writes. Also, some tests would create tablets
as SPARE without enabling healthcheck. As a result, the tablet has no
way of knowing whether it will eventually be a replica or rdonly, and
hence can't decide whether to enable semi-sync before starting
replication.
Healthcheck is basically required now, and definitely will be once we
fully switch to vtgate discovery mode. So I've removed cases where
tablets were being started SPARE without enabling healthcheck.
For SUPER queries (presumed to be administrative in nature),
this will test the connection given to us by the dbaPool before using
it. If we get "MySQL server has gone away (errno 2006)", try once to
reconnect before giving up.
This makes SUPER queries more resilient when mysqld goes away and then
comes back.
There was a bug that only showed up in time zones with positive offset
from GMT. I've added explicit tests for time zones with positive and
negative offsets.
When using semi-sync with rpl_semi_sync_master_wait_no_slave=1 and
rpl_semi_sync_master_timeout=[effectively infinite], it's necessary to
toggle master-side semi-sync at the proper times to prevent slaves from
getting stuck (since they have no slaves of their own to ACK).
This commit adds a new vttablet flag -enable_semi_sync, which causes the
replication-management features of Vitess (e.g. InitShardMaster and
various reparent operations) to automatically manage semi-sync settings.
With these settings, it becomes (reasonably) safe to reparent away from
an unresponsive master, as long as the following can be verified:
* All semi-sync slaves have stopped replicating from the old master.
* The chosen new master is the farthest ahead in replication.
Currently we only allow slaves marked in Vitess terms as "replica"
tablets to be semi-sync slaves (i.e. to send ACKs). Vitess slaves marked as
"rdonly" will NOT ACK, because they are not eligible to become masters,
so we never want them to be the only slave with the latest update.
This means when using semi-sync, every shard must have at least 2 live
"replica" type tablets (including the master) in order to accept writes.
The log depth was right when using ConsoleLogger through a TeeLogger,
but it was wrong when using ConsoleLogger directly. It turns out this
was because in the TeeLogger case, an extra autogenerated conversion
method was being inserted in the call stack, messing up the depth
calculation:
9877900c8c/src/cmd/compile/internal/gc/subr.go (L2245)
I fixed this by converting ConsoleLogger to only use pointer receivers,
and setting the depth according to the correct stack, without the
autogenerated method.
I didn't see any way to redirect glog, so I'm using the subprocess
technique for the test.
Because of the session cookie, only one asynchronous call can be
in-flight at a time. Violating that constraint is a bug in the client
app, so we throw an IllegalStateException to prevent race conditions.
Anthony Yeh
Michael Berlin
Liang
Alain Jobart
Alain Jobart
sougou
Rasta