Add TiDB single sandbox support

[morgo]

Is your feature request related to a problem? Please describe.

I would like to propose single sandbox support for TiDB, to allow developers to easily test compatibility without having to install a full distributed system (tidb+tikv+pd).

Describe the solution you'd like

TiDB can run with something called mocktikv (goleveldb) instead of tikv, which means that only one server component needs to be setup. In my own testing it is 5x slower than tikv, but the advantage is that you only need a tidb-server setup, and no pd or tikv.

The memory footprint is smaller than MySQL, so it's possible some might even prefer it for development.

Describe alternatives you've considered

I've looked at alternatives installation methods like Homebrew etc, but they do not solve the use case of having multiple versions installed concurrently. The TiDB release schedule is every 6 months, so dbdeployer is really useful in providing a system of organizing binaries for TiDB developers.

Additional context

I have looked at the initial work, and much of it can be implemented by sandbox templates and some core changes that @datacharmer already has planned (discussed at FOSDEM). Let me try and comment in terms of each:

Core

• Requires support for detecting TiDB flavor Define criteria to detect the flavor of a tarball contents #53 unpack command should create a FLAVOR file for the extracted tarball #52
• Requires support for unnumbered tarballs unpack command fails when tarball name doesn't include a version #51
• Requires support for --client-from (or similar) Add support for --client-from=X #49
• Requires support for 'capabilities' of which TiDB will be only single, with no gtids, binlog (initially), relay log, show log (initially, because there is no general log), add option, semisync, expose dd tables. Change evaluation of version to include a flavor #50
• Tarball inspection for files lib/libmysqlclient.so and scripts/mysql_install_db needs to be moved into either "capabilities" or "flavors".

Templates

I will send a pull request after some discussion, but my initial testing shows that the major template changes are:

• init_db_template
• my_cnf_template
• status_template * may need some discussion due to dependency
• start_template
• stop_template
• Change grants_template to be based on grants_template57 (TiDB has no_auto_create_user too)

TBD:
I think that these two templates can be kept vanila assuming support for --client-from is added:

• my_template
• use_template

[datacharmer]

TODO: add a flavor+capability rule to prevent deploying replication sandboxes.

[morgo]

I believe it will also need to refuse to deploy if neither $MYSQL_EDITOR or --client-from is specified. The load_grants template requires the client to be configured, so it can't be deferred till later.

Edit: confirmed this bug exists.

The my script also will not work if only a $MYSQL_EDITOR is specified, and not a --client-from. But client from works as expected! I can use mysqldump no problem :-)

[datacharmer]

I am about to commit the check that will prevent replication, or a deployment without --client-from.
I will also make sure that template names are unique across collections.

I've noticed that when I deploy several TiDB sandboxes, the server UUID is always the same(d530594e-1c86-11e5-878b-6b36ce6799ca), and also the variable datadir is always /usr/local/mysql/data/. Are they known issues?

[morgo]

Yes. TiDB traditionally has lied about variables it doesn't support. We are moving away from this behavior though, and I have proposals to cleanup sysvars and define compatibility criteria:

• datadir doesn't make sense for TiDB in the typical case (using tikv for storage). But it makes sense for when using mocktikv as we are here.
• The server UUID does not apply to TiDB. Each tidb server is stateless, membership-less and not special :-)

[datacharmer]

The implementation is almost finished. To complete it, I'd like to make TiDB installations compatible with MySQL, so that I can include a TiDB deployment in the functional test suite (currently I only have a mock test).

What's missing for integration:

• test_sb:
  • Ability to show the server port (currently it always shows 3306)
  • Ability of detecting whether the server is running. Current implementation uses the PID file. We can overwrite the template to use the socket instead. I am open to suggestions
• status:
  • show an on/off message as it happens for other deployments.

[morgo]

I have created pingcap/tidb#9362 for the port issue and assigned myself.

I didn't think to use socket, but that makes sense to me. Should we also clean up the startup script to delete a stale socket file if there is no tidb-server process to match it? The alternative is to print a warning saying stale socket file.

[datacharmer]

Cleaning up the start is a good idea.
If tidb-server were able to produce a PID file (with a --pid option) we could reuse the same scripts already in place for MySQL, or at least part of them.

[morgo]

I think you are right - TiDB should produce a pid file. I have created pingcap/tidb#9379 to track.

It touches a few more server components, so it might take 1-2 weeks to write and merge. Is that ok?

[datacharmer]

No pressure. What’s in the current code is good enough for now. I will merge it as it is.
When we have an improvement, we can open a PR to integrate

[morgo]

I looked into this. It is not technically mysqld that offers pidfile support, but mysqld_safe. See #64

Please note that there is also a bug in my implementation of showing an accurate port. It will be fixed in pingcap/tidb#9383

[morgo]

This has been added to dbdeployer 1.19.0