September 29, 2026 by Rene Cannao · Release Tech
#dbdeployer #mariadb #mysql #postgresql #proxysql #galera #open-source

dbdeployer v2.4.2: Faster MariaDB Sandboxes, Better Cluster Checks, and Five Months of Progress

dbdeployer v2.4.2 is out. If you use v2.4.0 or v2.4.1 to deploy MariaDB sandboxes, this is an upgrade you will notice: it removes a readiness wait that could turn a small replication deployment into several minutes of waiting.

It is also a good moment to catch up. In April, we wrote about why ProxySQL took over dbdeployer’s maintenance, the capabilities arriving in v2.1.1, and the provider architecture behind PostgreSQL support. Ronald followed up in June with a PostgreSQL and ProxySQL walkthrough. Since those first announcements, several releases have made the tool more useful across MariaDB, PostgreSQL, and clustered deployments.

For anyone meeting dbdeployer for the first time: it creates local database sandboxes for development, testing, and reproducing problems. You unpack database binaries, choose a topology, and get running instances with scripts to connect, stop, restart, and test them. The database processes run under your own user account; the host still needs the runtime libraries required by the chosen binaries.

What v2.4.2 fixes

MariaDB deployments stop waiting for a cluster that does not exist

In v2.4.0 and v2.4.1, ordinary MariaDB nodes could spend about two minutes each waiting for Galera readiness. The v2.4.2 release notes report a three-node replication deployment going from roughly eight minutes to twenty seconds after the fix. Actual times depend on the machine and binaries.

dbdeployer now decides when generating the sandbox whether a Galera readiness check belongs there. Only Galera and Percona XtraDB Cluster (PXC) nodes receive that wait.

Cluster readiness checks now work for joining nodes

Joining Galera/PXC nodes previously received a check that could not authenticate after state transfer. It would silently time out and let deployment continue.

The check now uses the appropriate sandbox credentials. A node that does not become ready within 120 seconds fails deployment, with an error identifying the node and its log. This replaces a later, less useful failure during grant setup.

More MariaDB versions in CI

The release verifies MariaDB 11.4.13, 12.3.3, and 13.0.2 for single and replication sandboxes alongside 10.11.9. Checks cover MariaDB’s CHANGE MASTER TO syntax and deployment time budgets. The tested 12.x and 13.x binaries require glibc 2.28 or newer. See the versioned changelog for the full details.

MariaDB: from downloading a version to testing a cluster

One of the useful additions in v2.3.0 was downloading MariaDB through the MariaDB Foundation API. You can request a release by version even when it is absent from dbdeployer’s bundled tarball list.

On a compatible Linux host, this downloads and unpacks MariaDB 12.3.3, creates a standard three-node replication sandbox, and runs its replication test:

dbdeployer downloads get-by-version 12.3.3 --flavor=mariadb --unpack
dbdeployer deploy replication 12.3.3
~/sandboxes/rsandbox_12_3_3/test_replication

That is the everyday workflow we want to preserve: choose a version, create the environment, and check that it behaves as expected.

The MariaDB work also includes support for current client executable names, better handling when a minimal download is unavailable, and fixes to version comparisons and replication authentication for MariaDB 11 and later. These details matter when a tool supports several related databases whose packaging and behavior have diverged.

For cluster testing, MariaDB Galera has its own topology. After unpacking a MariaDB distribution with Galera support, deployment uses the same familiar command with a different topology flag. For example, with MariaDB 11.8.6 binaries already unpacked:

dbdeployer deploy replication 11.8.6 --topology=galera
~/sandboxes/galera_msb_11_8_6/check_nodes

PXC uses --topology=pxc and requires a PXC distribution. Both cluster topologies run on Linux and need their host dependencies installed. The MariaDB Galera guide and PXC guide cover the prerequisites and verification steps.

The May release added integration coverage for both cluster families; July’s v2.4.0 added MariaDB Galera 11.8.6 to the tested configurations. Today’s release strengthens the readiness checks those deployments rely on.

PostgreSQL: making the complete workflow more reliable

PostgreSQL support was already part of our April announcement. The work since then has addressed what happens when you use it repeatedly, across versions and alongside other sandboxes.

v2.4.0 improved several parts of that workflow:

  • Binary extraction: corrected the layout of binaries extracted from Debian packages so PostgreSQL can locate its shared files, and included handling for the libpq5 runtime dependency.
  • Port allocation: prevented collisions across single, replication, and multiple deployments.
  • Replica readiness: made deployment wait for PostgreSQL replicas to accept queries before returning.
  • Replication verification: added a generated test_replication script that checks data flow.
  • ProxySQL integration: corrected port, script, and sandbox-directory handling for PostgreSQL topologies with ProxySQL.

That last distinction between a running process and a usable replica is especially relevant to automated tests. A test should be able to start its workload when deployment returns, without guessing how long to sleep first.

v2.4.1 then made deploy postgresql honor the placement and credential options already familiar to MySQL users: --sandbox-home, --sandbox-directory, --port, --db-user, and --db-password.

For example, if PostgreSQL 16.13 is already unpacked, you can give a project its own named sandbox and explicit port:

dbdeployer deploy postgresql 16.13 \
  --sandbox-home="$HOME/project-sandboxes" \
  --sandbox-directory=orders-dev \
  --port=15432

"$HOME/project-sandboxes/orders-dev/use" -c "SELECT version();"

Use the version you actually unpacked and an available port. For the full path from downloading packages to running a replicated PostgreSQL topology through ProxySQL, the June walkthrough remains a useful companion.

Testing the database and the proxy together

dbdeployer is particularly useful to us because it can create the environment around a proxy test: database nodes, replication, users, and ProxySQL configuration.

For supported topologies, adding --with-proxysql includes the proxy in the deployment. For example, on a Linux host with the required Galera dependencies, MariaDB 11.8.6 unpacked, and proxysql available in PATH:

dbdeployer deploy replication 11.8.6 \
  --topology=galera \
  --with-proxysql

~/sandboxes/galera_msb_11_8_6/proxysql/use_proxy -e "SELECT @@port;"

Run this as an alternative to the earlier Galera example, or choose a separate sandbox directory if you want both environments. The query goes through ProxySQL and identifies the backend port that served it.

This gives developers a practical starting point for reproducing routing problems, exploring cluster behavior, and testing application connections. The ProxySQL integration guide covers the generated access scripts and configuration.

Reliability work beyond the headline features

The releases since April also include smaller changes that make repeated deployment less frustrating: clearer installer dependency errors, improved checksum handling, and retries when deleting a sandbox races with a recently killed process.

There was also a security fix in v2.2.3 for archive extraction: chained symlinks in a malicious tarball could escape the extraction directory. That fix is included in v2.4.2, along with an early compatibility check for MySQL Shell before InnoDB Cluster deployment. Both are documented in the changelog.

The testing work has expanded alongside the features. PXC and MariaDB Galera gained integration coverage, PostgreSQL gained replication data-flow checks, and deployment time limits now help catch regressions where a command eventually succeeds but takes far too long. Today’s MariaDB fix is a good example of why elapsed time belongs in that testing.

Install or upgrade

For an existing installation, update to this release and check the installed version:

dbdeployer update v2.4.2
dbdeployer --version

For a fresh installation, the installer selects the latest release for your platform and verifies its checksum:

curl -fsSL https://raw.githubusercontent.com/ProxySQL/dbdeployer/master/scripts/dbdeployer-install.sh | bash

The v2.4.2 release page also provides binaries for Linux and macOS, on amd64 and arm64, with checksums. Availability of database binaries and individual topologies varies by platform.

No configuration migration is required. Existing sandboxes continue to work; newly generated sandboxes receive the corrected deployment behavior. Updating the dbdeployer executable does not rewrite scripts in sandboxes you already created.

When we took over maintenance, we wanted to keep Giuseppe Maxia’s work useful to the people who depend on it and extend it to more of the database environments we test every day. These releases continue that work. Thanks to everyone contributing fixes and reporting the cases that did not work as expected.

Try dbdeployer v2.4.2, and if a deployment fails, open an issue with the database version, platform, command, and relevant logs. A reproducible sandbox is a good place to start solving a database problem.