Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add TiDB single sandbox support #54

Closed
morgo opened this issue Feb 5, 2019 · 11 comments

Comments

@morgo
Copy link
Contributor

commented Feb 5, 2019

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 #53 #52
  • Requires support for unnumbered tarballs #51
  • Requires support for --client-from (or similar) #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. #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:

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

@datacharmer

This comment has been minimized.

Copy link
Owner

commented Feb 10, 2019

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

@morgo

This comment has been minimized.

Copy link
Contributor Author

commented Feb 10, 2019

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

This comment has been minimized.

Copy link
Owner

commented Feb 10, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 10, 2019

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

This comment has been minimized.

Copy link
Owner

commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Owner

commented Feb 20, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2019

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

This comment has been minimized.

Copy link
Owner

commented Feb 20, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2019

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 comment has been minimized.

Copy link
Contributor Author

commented Feb 26, 2019

This has been added to dbdeployer 1.19.0

@morgo morgo closed this Feb 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.