Starting with MySQL 8.0, we will drop libmysqld (aka “embedded server”). This change will affect only a handful of users, but for context let me start with an introduction.

Introduction

libmysqld (also referred to as “the embedded server”) is a way of using MySQL without the client server protocol. This long-standing feature was disabled in MySQL 5.0, and then re-introduced in MySQL 5.1, and allows an application to link against MySQL using essentially the same API as libmysqlclient. This has the benefit of simplified management of embedded applications, and potential performance advantages.

The libmysqld server however comes with some documented restrictions:

1. No user-defined functions (UDFs).
2. No stack trace on core dump.
3. You cannot set this up as a master or a slave (no replication).
4. Very large result sets may be unusable on low memory systems.
5. You cannot connect to an embedded server from an outside process with sockets or TCP/IP. However, you can connect to an intermediate application, which in turn can connect to an embedded server on the behalf of a remote client or outside process.
6. InnoDB is not reentrant in the embedded server and cannot be used for multiple connections, either successively or simultaneously.
7. The Event Scheduler is not available. Because of this, the event_scheduler system variable is disabled.
8. The embedded server cannot share the same secure_file_priv directory with another server. As of MySQL 5.7.8, the default value for this directory can be set at build time with the INSTALL_SECURE_FILE_PRIV_EMBEDDEDDIR CMake option.
9. Performance Schema is not supported.

Decision to remove libmysqld in 8.0

The event that made us first reevaluate support for libmysqld, is that the generic tarball size of MySQL 8.0 DMR has stretched to almost 1GB (965M) in compressed size. There are actually a number of causes for this:

1. New features (obviously)
2. Refactoring code, and making good use of C++ libraries such as Boost increases size
3. Converting command line utilities from Perl to C++ improves our cross platform experience and reduces dependencies, but also increases size
4. Code optimizations frequently increase size

On top of these causes, any increase in server binary size is amplified because a standard download includes many versions of the MySQL Server. To use some uncompressed numbers from the package mysql-8.0.0-dmr-linux-glibc2.12-x86_64.tar.gz:

• 332M – bin/mysqld
• 313M – bin/mysql_client_test_embedded
• 312M – bin/mysql_embedded
• 312M – bin/mysqltest_embedded
• 277M – bin/mysqld-debug
• 873M – lib/libmysqld.a
• 719M – lib/libmysqld-debug.a

For most users, bin/mysqld is the only version of the MySQL Server that they will interact with. However, for debugging some complex bugs it is also useful that bin/mysqld-debug is included in the same package downloads. This enables a user to quickly switch back and forth, without any complexity from having to download and install new software or manage multiple installations of MySQL on the same host.

The inclusion of the embedded server binaries and libraries increases the package download by approximately 621MB (and 2.6GB uncompressed).  That is to say that if these are removed, that 965M package comes down to only 344M.  A nice saving!

As a side note:
For users that require ultra-lean installations, we also have a special version of MySQL that ships in Docker images. This package removes the debug binary, a few auxiliary utilities, and strips symbols. For MySQL 8.0 DMR the package size is 14.3MB compressed.

Upgrade Path Moving Forward

As part of our investigation into removing libmysqld, we spoke to our customers, support team, users who had filed bugs on libmysqld, and looked into dependencies on libmysqld in Linux distributions. The investigation concluded that the actual usage of libmysqld is actually quite low in comparison to mysqld (our client-server option).

Since libmysqld uses a comparable API to libmysqlclient, the upgrade path is relatively straight forward:

1. Bring up a standalone MySQL server (mysqld).
2. Modify application code to remove API calls that are specific to libmysqld.
3. Modify application code to connect to the standalone MySQL server.
4. Modify build scripts to use libmysqlclient rather than libmysqld. For example, if you use mysql_config, invoke it with the --libs option rather than --libmysqld-libs.

We will continue to support libmysqld for the lifetime of MySQL 5.7, but plan to mark it as deprecated so that our future intentions are made clear to users in our current GA release.

Conclusion

For the 99.999% of MySQL users who are web properties and end users, this will result in zero change in how MySQL is used.  That is, other than a substantial reduction to the size of downloads as we expect to slim down to one third of our original size.

It is also important to point out that there are many side benefits: as an engineering team we are able to increase our own productivity as we spend less time waiting for MySQL to compile! This means more time (and focus) spent on developing the core features of MySQL.  If you have not already, please check out what’s new in our first DMR of 8.0.

Thank you for using MySQL!