perf(dev-env): tune local database performance defaults

[WRasada]

Problem

The dev-env database containers run with stock settings that are hostile to bulk imports:

• Binary logging is on (MySQL 8 default): every imported byte is journaled into binlogs nothing consumes locally — ~30GB of pure write amplification for a 30GB dump. myloader's own SET SESSION SQL_LOG_BIN = 0 opt-out fails (the wordpress user lacks SYSTEM_VARIABLES_ADMIN), so this always happens.
• 128M buffer pool / ~100M redo log (defaults): large imports stall constantly on Redo log writer is waiting for a new redo log file / log_checkpointer still lagging behind warnings.
• fsync per commit (innodb_flush_log_at_trx_commit=1): durability guarantees that are meaningless for a disposable local database, paid for on every one of myloader's transactions.

Fix

assets/dev-env.lando.template.yml.ejs, both database branches. Note these are server-wide
mysqld startup flags — they benefit all local database use (the buffer pool in particular
helps everyday WordPress queries on large sites), with the most dramatic gains on bulk imports:

Setting	MySQL 8.4	MariaDB
Binary logging	--skip-log-bin	already off by default
Buffer pool	--innodb-buffer-pool-size=1G	same
Redo capacity	--innodb-redo-log-capacity=1G	--innodb-log-file-size=1G
Commit flushing	--innodb-flush-log-at-trx-commit=2	same

DEV_ENVIRONMENT_VERSION is bumped 2.3.3 → 2.3.4 (src/lib/constants/dev-environment.ts) so existing environments re-render the template and rebuild automatically on their next vip dev-env start — no manual dev-env update needed.

Testing

• Verified the rendered .lando.yml and live values after the auto-update path (maybeUpdateVersion() → updateEnvironment() → lando rebuild): log_bin=0, pool 1G, redo 1G, flush=2
• 201k-table / 30GB import: schema creation phase completed ~30% faster than with stock settings, with zero redo-log stall warnings (previously continuous)
• Upgrade path validated end-to-end: created an environment on the previous defaults (dev-env version 2.3.3, binlogging active, 128M pool), published a post, then started it with this branch — it auto-updated to 2.3.4 non-interactively, rebuilt, came up cleanly with the new flags applied over the existing data directory, the post survived, and the site loaded with no database errors (manually verified in the browser as well)
• New e2e spec __tests__/devenv-e2e/014-database-defaults.spec.js covers both scenarios permanently: (1) a fresh environment runs with non-stock database defaults, and (2) an environment stamped with the previous version auto-updates on start, applies the new defaults to its existing data directory, and keeps its data. Assertions use floors (e.g. pool > stock 128M) rather than pinned values, so future tuning of the sizes does not break the test — only losing an override does

Trade-off note

innodb_flush_log_at_trx_commit=2 means up to ~1s of writes can be lost if the host crashes (not just mysqld). For a local dev database that is recreated from imports, this is the intended trade.

Changelog Description

Changed

• Dev-env: Improved local database performance defaults — these apply to all database use, with the largest gains on big SQL imports (binary logging disabled on MySQL, InnoDB buffer pool raised to 1G to match the VIP production default, larger redo log, relaxed per-commit flushing). Existing environments pick the settings up automatically on their next start

Related

• Companion PRs: fix(dev-env): use -o so myloader drops existing tables before import #2871 (myloader -o fix), fix(dev-env): recompute mydumper section sizes after search-replace #2872 (search-replace size fix), fix(validations): avoid ENGINE != InnoDB false positives on row data #2873 (ENGINE validation)

🤖 Generated with Claude Code

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[sjinks]

Is this change friendly to existing environments? That is, if I create a dev env with an old VIP CLI, then run this VIP CLI and restart the environment, will it start?

[WRasada]

Good question. Something I did not test, and I'll run some tests and validate

[WRasada]

Alright. This validated fine and found no issues with existing environments.

I created a new environment on trunk (old 2.3.3 dev-env defaults), created an example post, switched to this branch and restarted the environment. It auto-updated to 2.3.4 and rebuilt, the site loaded fine with no database connection errors, the post survived, and the new flags were verified live in the container.

I also added an e2e test (014-database-defaults.spec.js).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

This pull request has been marked stale because it has been open for 60 days with no activity. If there is no activity within 7 days, it will be closed.

This is an automation to keep pull requests manageable and actionable and is not a comment on the quality of this pull request nor on the work done so far. Closed PRs are still valuable to the project and their branches are preserved.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

This PR tunes the local dev-env MySQL/MariaDB container startup flags to make bulk SQL imports (and everyday large-site queries) dramatically faster, at the cost of durability guarantees that are meaningless for a disposable local database. It is one of four companion dev-env import PRs (#2871–#2874). The DEV_ENVIRONMENT_VERSION bump ensures existing environments re-render the template and rebuild automatically on their next vip dev-env start, so no manual dev-env update is required.

Changes:

• Add InnoDB tuning flags to both DB branches of dev-env.lando.template.yml.ejs: MySQL gets --skip-log-bin, 1G buffer pool, 1G redo-log-capacity, and flush-log-at-trx-commit=2; MariaDB gets the equivalents (1G buffer pool, 1G log-file-size, flush=2), with binary logging already off by default.
• Bump DEV_ENVIRONMENT_VERSION from 2.3.3 to 2.3.4 to force auto re-render/rebuild of existing environments.
• Add e2e spec 014-database-defaults.spec.js covering fresh non-stock defaults plus MySQL and MariaDB 10.3 upgrade-in-place paths (data survival + tuned values), using floor assertions rather than pinned sizes.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
assets/dev-env.lando.template.yml.ejs	Adds documented InnoDB performance flags to the MySQL and MariaDB mysqld command lines.
src/lib/constants/dev-environment.ts	Bumps DEV_ENVIRONMENT_VERSION so existing environments auto-rebuild with the new template.
__tests__/devenv-e2e/014-database-defaults.spec.js	New e2e coverage for fresh defaults and upgrade-in-place (MySQL + MariaDB) with data-survival checks.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.