1. queryservice should not publish stats if either flag EnablePublishStats
is enabled or var name is empty.
2. stats.NewInt should call Publish if name is empty.
3. mysqlctl.NewMysqld publishes dba stats only if dbaName is not empty.
4. mysqlctl.NewMysqld publishes app stats only if appName is not empty.
5. QueryEngine publishes stats only if flag EnablePublishStats is enabled.
6. RowCacheInvalidator publishes stats only if flag EnablePublishStats is enabled.
CachePool launches a memcache process, if failed, it will sleep 100 millis
before the next attempt. This slows down the unit test since a fake memcache
service is guaranteed to succeed.
The base images are meant for development, and include everything needed
to bootstrap and build Vitess.
For actual deployment, we can drop all the dev packages and just put the
binaries into a fresh image.
At this time, the savings in image size are:
vitess/base = 2.269GB -> vitess/lite = 568.4MB
vitess/etcd:v0.4.6 = 442.4MB -> vitess/etcd:v0.4.6-lite = 108.6MB
This makes Kubernetes pods start a lot faster, since each node has to
download the images.
go/streamlog/streamlog.go starts a separate go routine for each new logger instance.
In the querylogz_test.go, it tries to call logger.Send(logStats) and then assumes this
logStats has been delivered. Then it calls querylogzHandler and verifies the result.
However, it is not guaranteed the message will be delivered after Send call, because Send
just put the message into dataQueue and only the go routine delivers it to each consumers.
We don't STOP SLAVE, RESET SLAVE in InitSlave any more.
We don't use BreakSlaves on new master in InitMaster
any more, we just use a couple SQL statements to init binlogs.
Under load, Begin gets occasionally called just when the context
is about to expire. In such cases, the query gets killed as soon
as it's issued. However, The Begin call itself almost never fails
because it's too fast. So, this just results in the connection
getting closed, which isn't seen until the next statement executes,
and results in a confusing 2006 error.
So, we give ourselves a 10ms grace period to make sure that we
give Begin enough time to succeed. This way, we won't see as many
confusing error messages.
There's a race condition between context and resource pool.
If a context is already expired, there's still a chance that
a Get will succeed because both channels are ready to communicate.
This bug also masked another bug in dbconnpool and some other
bugs in our tests.
All fixed now.
As part of removing googleBinlogEvent parsing support, I reworked the
binlog_streamer_test to use fake events instead of real ones. The actual
parsing of real events is already tested in its own unit test. Using
fake events simplifies the binlog_streamer_test, which really is only
meant to test the logic for converting a stream of events into a stream
of transaction objects.