cesnimda
11 KiB
MariaDB 12.3 LTS migration investigation
Research checked against official sources on 2026-10-23. Recommendation: qualify 12.3.3 LTS as the next server target in a separate staging change, then seek operator approval for production cutover. The present standardisation work aligns with the owner-verified deployed 12.2.2-MariaDB-ubu2404; no 12.3 runtime, upgraded production copy, restore rehearsal or deployment is claimed here.
Release and support evidence
| Question | Verified finding |
|---|---|
| Current stable 12.3 patch | The Foundation's release inventory lists 12.3.3 Stable in August 2026. The Q3 maintenance announcement confirms 12.3.3. Official pages differ on the exact August day, so this plan relies on the version and month. Recheck for a newer stable patch when scheduling rehearsal. |
| First GA | The 12.3 LTS announcement identifies 12.3.2 as the first GA in May 2026. Do not select the older RC referenced by stale release-note indexes. |
| Maintenance horizon | The Foundation's maintenance policy and release table list 12.3 Community maintenance through 12 June 2029; Enterprise and Extended dates are TBC. Current policy provides Community LTS binaries for three years and critical/security source releases for two further years. This is not a promise of five years of Community binaries or a commercial support entitlement. |
Production currently uses floating mariadb:latest according to the owner. A subsequent pull can change the version independently of the application release. Before any planned upgrade, record and preserve the actual source image reference, platform, registry digest and server version; verify the proposed docker.io/library/mariadb:12.3.3 exists for the deployment architecture, retrieve its official registry manifest/index digest and record the selected platform manifest. Use a verified version@sha256:... reference for rehearsal and eventual rollout. No 12.3 digest was retrieved in this investigation, so none is invented here. A container .Image configuration ID is not a registry manifest digest. Version/digest verification remains a prerequisite, including for the rollback image.
Application and driver assessment
Repository inspection found net9.0, Pomelo 9.0.0, EF Core Relational 9.0.14 and locked MySqlConnector 2.4.0 in JobTrackerApi/JobTrackerApi.csproj and JobTrackerApi/packages.lock.json. Pomelo's 9.0.0 release notes allow EF Core 9.0.x, .NET 8+ and MySqlConnector 2.4.0+, but list MariaDB test coverage only through 11.6, including 11.4/10.11 LTS. They do not certify 12.2 or 12.3 for this application.
The current MySqlConnector compatibility table lists MariaDB 12.x (12.3). That driver-level statement is encouraging; it does not prove that this locked older driver, Pomelo SQL generation, EF migration chain and application transaction behavior work together on 12.3. Keep the current dependency set for the first controlled comparison; upgrade a dependency separately only for a verified incompatibility or maintenance need, and rerun the same acceptance lane. Configure Pomelo's MariaDB server version to match the tested target; an old hardcoded version or successful connection is insufficient evidence.
The 12.3 announcement specifically warns that innodb_snapshot_isolation now defaults to ON. Record actual source/target transaction_isolation, innodb_snapshot_isolation, SQL mode, charset and collation instead of assuming defaults. Exercise the production settings with controlled held-reader/writer and overlapping-write tests, transaction abort/recovery and stale-write contracts. Do not silently disable the new setting just to obtain a green test; any override needs a reason, a recorded configuration and its own qualification.
The present isolated12.2.2 Windows and official Ubuntu-image-filesystem runs both actually reported
innodb_snapshot_isolation=ON with REPEATABLE-READ; see runtime provenance.
Do not assume a source value of OFF from the release announcement. Production's actual isolation,
SQL mode and collation were not inspected, and12.3 itself has not been exercised here.
Rehearsal and migration gates
| Gate | Required proof before production approval |
|---|---|
| Freeze inputs | Preserve source image, application commit, configuration inventory, migration history and recovery files. Identify engines/plugins, authentication/TLS, collations and any replication/Galera topology; follow topology-specific guidance if present. Pin the proposed target image/platform and backup clients. |
| Prove recovery first | Restore a consistent pre-upgrade 12.2.2 recovery set into a separate 12.2.2 instance. Verify application startup, counts, owner boundaries, current/history revisions, attachments, frozen packages, encrypted data/key availability and deletion-tombstone replay. Record elapsed restore time and approved recovery objectives. |
| Upgrade an isolated copy | Follow the official cross-series upgrade guidance, including clean shutdown and engine/config review. Run and record mariadb-upgrade on the isolated upgraded copy with proper data-directory permissions; verify system tables and table checks. Do not substitute an EF migration for server-system upgrade. |
| Container entrypoint | Review the exact image's upgrade behavior before enabling MARIADB_AUTO_UPGRADE. Its automatic system-database backup is not a complete application recovery set. Never point the candidate image at the only original volume. |
| Application schema | Run the unchanged startup migration/reconciliation chain on fresh 12.3, the upgraded populated copy, and repeated startup. Compare schema/indexes/constraints and __EFMigrationsHistory; validate Unicode, JSON/text, timestamps, nulls, unique keys and foreign keys. Retain historical migrations; create a new reviewed migration only for an identified schema need. |
| Application behavior | Run real-server RD21 first-save/stale/overlap/rollback/held-reader-writer tests using independent contexts, tenant/security boundaries and related text writers, then affected browser workflows. Compare 12.2.2 and 12.3.3 using identical fixtures/settings; record exact versions, exits and persisted-state evidence. Confirm failures leave the context/database usable. SQLite and generated SQL remain separate evidence. |
| Target recovery and observation | Back up and restore the 12.3 candidate, validate full recovery again, measure representative query/lock/error behavior, and rehearse the rollback path below. Only then prepare an operator-reviewed maintenance window and production change. |
The generic upgrade documentation supports investigating a direct 12.2-to-12.3 upgrade; this is an inference about the rehearsal path, not a claim that the repository's populated database has been proven upgradeable. This investigation did not locate a dedicated 12.2-to-12.3 procedure. Recheck exact target release/configuration notes before execution.
Backup/deployment gaps found by read-only inspection
deploy/deploy.sh:350–365 prefers an arbitrary host mariadb-dump, falls back to host mysqldump, then uses floating mariadb:11 for the container client. deploy/deploy.sh:283 also uses that floating image for backup-directory ownership repair. A later migration implementation must select verified source-compatible dump/import tools and remove accidental client-version drift; this plan changes no deployment script.
Existing dump flags include --single-transaction --routines --events --quick. mariadb-dump documentation limits snapshot consistency to transactional engines and warns against concurrent DDL. It also documents dump-header incompatibility with older import clients. Inventory nontransactional tables and system users/grants/plugins/config separately; a dump of only the application database does not preserve the whole server. Schedule a write/DDL freeze and coordinate filesystem recovery artifacts for the cutover snapshot.
verify_sql_backup checks nonempty gzip, schema text and a dump trailer. Those are useful corruption checks, but an actual restore must prove usability. docs/infrastructure/backups.md already leaves current production restore qualification as an operator gate. Preserve application data, uploads/CV artifacts, Data Protection keys, tombstones and required configuration together. If physical backup is chosen, use matching server/backup versions, prepare with the same backup version, and restore into a separate stopped instance with an empty destination; see official backup/restore guidance. Retain the original untouched source and protected backup manifests/checksums until the approved retention window ends.
Rollback and approval
MariaDB explicitly states that in-place downgrade is unsupported. Do not start 12.2.2 against a data directory already upgraded by 12.3. Restore the verified pre-upgrade recovery set into a separate pinned 12.2.2 instance. Before target writes are admitted, this returns to the preserved source state. After target writes, restoring that snapshot would lose acknowledged work: either keep writes frozen through acceptance, or approve and rehearse a logical reverse-transfer/reconciliation strategy before cutover. Do not assume reverse replication or newer-feature SQL will work on the old server.
The automatic failure path in deploy/deploy.sh:638–648 restores previous backend/frontend images only. It neither downgrades MariaDB nor restores database schema/data; startup EF changes can outlive application rollback. A database upgrade needs a separate recovery decision, operator runbook, write-freeze window, verified backup location and explicit acceptance of any recovery-point loss. Production access, restart, backup execution, server/schema migration and cutover require their own operator authorization.
Decision: recommend 12.3 LTS for staged qualification; production migration is not ready. Outstanding gates are official image/digest/platform verification, populated upgrade and server-upgrade checks, exact locked-stack/runtime compatibility, isolation/concurrency proof, complete source/target restore rehearsals, measured downtime/recovery objectives and operator approval. No runtime tests, builds, production operations, image changes or CI/deployment edits were performed for this investigation.