Skip to content

Conversation

@beautifulentropy
Copy link
Member

@beautifulentropy beautifulentropy commented Nov 13, 2025

Ahead of the move from ProxySQL + MariaDB to Vitess + MySQL 8 in #8468. Vitess blocks partition related DDL, so partitions need to be removed from all schemas under sa/db*. The team has agreed that this drift from Production is acceptable because it lets us begin testing on Vitess and MySQL sooner.

Separately, thisUpdate and nextUpdate were relying on an implicit DEFAULT NULL. We now make that explicit, matching how we define other DATETIME columns. Also, add a missing DROP TABLE incidents; to our combined schema migration.

Part of #7736

@github-actions
Copy link
Contributor

@beautifulentropy, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values.

@aarongable aarongable requested review from a team and jprenken and removed request for a team November 13, 2025 21:20
@beautifulentropy beautifulentropy merged commit 15d53b2 into main Nov 13, 2025
17 checks passed
@beautifulentropy beautifulentropy deleted the vitess-says-no-partitions branch November 13, 2025 22:57
npurtova pushed a commit to plesk/boulder that referenced this pull request Nov 25, 2025
Ahead of the move from ProxySQL + MariaDB to Vitess + MySQL 8 in letsencrypt#8468.
Vitess blocks partition related DDL, so partitions need to be removed
from all schemas under `sa/db*`. The team has agreed that this drift
from Production is acceptable because it lets us begin testing on Vitess
and MySQL sooner.

Separately, `thisUpdate` and `nextUpdate` were relying on an implicit
`DEFAULT NULL`. We now make that explicit, matching how we define other
DATETIME columns. Also, add a missing `DROP TABLE `incidents`;` to our
combined schema migration.

Part of letsencrypt#7736
aarongable pushed a commit that referenced this pull request Dec 8, 2025
The original plan for getting the Vitess infrastructure running was to
use
[vttestserver](https://vitess.io/docs/22.0/reference/programs/vttestserver)
as a starting point to reach a minimum viable setup. However,
vttestserver didn’t work out because some of its defaults conflicted
with how we clean up rows and the level of resources (threads) we need.

Fortunately, vttestserver is just a wrapper around
[vtcombo](https://vitess.io/docs/21.0/reference/programs/vtcombo) that
generates a [vttest
protobuf](https://github.com/vitessio/vitess/blob/v22.0.1/proto/vttest.proto)
describing the configuration for an in-memory topology server started by
vtcombo, encoded in JSON. By modifying vttestserver’s
[run.sh](https://github.com/vitessio/vitess/blob/v22.0.1/docker/vttestserver/run.sh),
we're able to interact with vtcombo directly, passing the JSON
configuration along with other vttestserver defaults reverse-engineered
from run.sh and
[vtprocess.go](https://github.com/vitessio/vitess/blob/v22.0.1/go/vt/vttest/vtprocess.go).

Vitess doesn’t provide a `vtcombo` image, we must build our own. Build
and upload a [boulder-vtcomboserver
image](https://hub.docker.com/repository/docker/letsencrypt/boulder-vtcomboserver)
on top of Docker's official MySQL 8.4 image, which provides native arm64
support. The accompanying tag-and-upload shell script defaults to amd64
for CI.

As an aside, Vitess’s official Dockerfiles are only published for amd64,
and modifying them to build for arm64 would prove difficult because
Oracle doesn’t publish MySQL arm64 binaries in its [Debian apt
repository](https://repo.mysql.com/apt/debian/pool/mysql-8.0/m/mysql-community).

With boulder-vtcomboserver up and running I was able to find/validate
the following issues and provide workarounds:

- **Problem:** db-migrate, the tool we use to apply database migrations,
must be configured to talk to MariaDB and to MySQL through Vitess
(vtgate + vttablet).
**Solution:** Create two new dbconfig YAML files (mariadb and vitess)
and use `test/entrypoint.sh` to set the appropriate file for
`sql-migrate` (`test/create_db.sh`) to use. Also, symlink each of these
two new files from db to db-next just like the old dbconfig.yml file.

- **Problem:** Vitess does not allow database `CREATE` statements and
any DDL containing them will be rejected by vtgate.
**Solution:** These databases are already created by vtcombo since
they’re defined as KEYSPACES. Skip database creation in
`test/create_db.sh`.

- **Problem:** Vitess does not allow user creation or grants (`CREATE
USER`, `GRANT`), and any DDL containing these commands will be blocked
by vtgate.
**Solution:** Skip user creation and grant steps in `test/create_db.sh`.
Set `%` for `--vschema_ddl_authorized_users` as vttestserver does, and
revisit this later for a more complete approach.

- **Problem:** vttablet default for maximum number of rows returned from
a (non-streaming) query (10,000) is too low for Boulder’s needs, causing
queries to fail due to vttablet rejecting them.
**Solution:** Increase `--queryserver-config-max-result-size` to
1,000,000 and `--queryserver-config-warn-result-size` to 1,000,000.

- **Problem:** vttablet default for connection pool size (16) and
maximum number of concurrent transactions (20) are too low for Boulder’s
needs, causing queries to fail due to vttablet being overloaded.
**Solution:** Increase `--queryserver-config-pool-size` to 64 and
`--queryserver-config-transaction-cap` to 80.
  
- **Problem:** Vitess does not allow `TRIGGER` statements and any DDL
containing them will be rejected by vtgate. Without TRIGGER statements
TestIssuanceCertStorageFailed, an integration test, will fail.
**Soluton:** Run these TRIGGER statements in an entrypoint
scripttest/vtcomboserver/install_trigger.sh, bypassing vtgate entirely.

Depends on #8479
Depends on #8489
Depends on #8490
Depends on #8494
Fixes #7736
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants