chore(nextcloud): migrate MariaDB 10.11 -> 11.8 LTS #75

Merged

copper merged 1 commit from worktree-nextcloud-mariadb-11.8 into main

2026-09-16 21:45:51 +00:00

claude-bot commented

2026-09-16 21:38:01 +00:00

Collaborator

Summary

In-place major-version migration of Nextcloud's MariaDB, task #7 of the infra update audit. Unlike the Forgejo Postgres 16→18 migration, this is not a dump/restore — MariaDB's official image supports in-place upgrades (mariadb-upgrade against the existing datadir), confirmed via MariaDB's own upgrade guide (direct 10.11→11.8 hop is explicitly supported, no forced 11.4 stopover).

Changes to ccnet-nextcloud-swarm/nextcloud-swarm-stack.yml:

db image mariadb:10.11 → mariadb:11.8
--require_secure_transport=OFF added to db's command line — cheap insurance in case MariaDB 11.8's zero-configuration TLS work ever flips the upstream default (app↔db traffic is plaintext over the internal overlay network; initial research suggesting this default already changed at 11.8 turned out to trace back to AWS RDS's own parameter group, not upstream — kept the flag anyway)
MARIADB_AUTO_UPGRADE: "1" added — triggers mariadb-upgrade automatically on first start against the existing datadir

Execution notes

Quiesced nextcloud/cron/push to 0 (not just occ maintenance:mode) before the DB touch — mariadb-upgrade must not race live app connections
Took both a logical (mariadb-dump, 360MB) and physical (cp -a datadir, 2.5G) backup before the upgrade; user pulled a copy of the physical backup off-cluster before proceeding
Verified clean prior shutdown indirectly (swarm's aggressive container GC removed the stopped task before its logs could be read directly) by briefly restarting on 10.11 and confirming no InnoDB crash-recovery messages
mariadb-upgrade ran all 8 phases cleanly, no errors
Verified via oc_filecache row count (979,127, exact match pre/post) and a clean occ files:scan — stronger than a trivial table-count check since an in-place upgrade doesn't touch user data
Physical backup (db.10.11-bak) landed on the default Ceph pool rather than swarm-nvme — cp -a doesn't carry ceph.dir.layout.pool xattrs, same lesson as the Forgejo Postgres migration. Cosmetic for a rollback-only copy.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TAp6m6GGf1PKfff1HKziBB

## Summary In-place major-version migration of Nextcloud's MariaDB, task #7 of the infra update audit. Unlike the Forgejo Postgres 16→18 migration, this is **not** a dump/restore — MariaDB's official image supports in-place upgrades (`mariadb-upgrade` against the existing datadir), confirmed via MariaDB's own upgrade guide (direct 10.11→11.8 hop is explicitly supported, no forced 11.4 stopover). Changes to `ccnet-nextcloud-swarm/nextcloud-swarm-stack.yml`: - `db` image `mariadb:10.11` → `mariadb:11.8` - `--require_secure_transport=OFF` added to `db`'s command line — cheap insurance in case MariaDB 11.8's zero-configuration TLS work ever flips the upstream default (app↔db traffic is plaintext over the internal overlay network; initial research suggesting this default already changed at 11.8 turned out to trace back to AWS RDS's own parameter group, not upstream — kept the flag anyway) - `MARIADB_AUTO_UPGRADE: "1"` added — triggers `mariadb-upgrade` automatically on first start against the existing datadir ## Execution notes - Quiesced `nextcloud`/`cron`/`push` to 0 (not just `occ maintenance:mode`) before the DB touch — `mariadb-upgrade` must not race live app connections - Took both a logical (`mariadb-dump`, 360MB) and physical (`cp -a` datadir, 2.5G) backup before the upgrade; user pulled a copy of the physical backup off-cluster before proceeding - Verified clean prior shutdown indirectly (swarm's aggressive container GC removed the stopped task before its logs could be read directly) by briefly restarting on 10.11 and confirming no InnoDB crash-recovery messages - `mariadb-upgrade` ran all 8 phases cleanly, no errors - Verified via `oc_filecache` row count (979,127, exact match pre/post) and a clean `occ files:scan` — stronger than a trivial table-count check since an in-place upgrade doesn't touch user data - Physical backup (`db.10.11-bak`) landed on the default Ceph pool rather than `swarm-nvme` — `cp -a` doesn't carry `ceph.dir.layout.pool` xattrs, same lesson as the Forgejo Postgres migration. Cosmetic for a rollback-only copy. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01TAp6m6GGf1PKfff1HKziBB

claude-bot added 1 commit

2026-09-16 21:38:01 +00:00

chore(nextcloud): migrate MariaDB 10.11 -> 11.8 LTS (in-place) 180a349472

Zero-downtime-to-app-data engine bump via MariaDB's in-place major
upgrade path (mariadb-upgrade against the existing datadir), not a
dump/restore like Forgejo's Postgres migration. Verified via oc_filecache
row count (979,127, exact match pre/post) and a clean occ files:scan.

Adds --require_secure_transport=OFF as insurance against MariaDB 11.8's
zero-configuration TLS defaults (app<->db traffic is plaintext over the
internal overlay network) and MARIADB_AUTO_UPGRADE=1 to trigger the
system-table upgrade automatically on first start of the new image.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TAp6m6GGf1PKfff1HKziBB

copper merged commit eb7adb36b4 into main

2026-09-16 21:45:51 +00:00

copper referenced this pull request from a commit

2026-09-16 21:45:53 +00:00

Merge pull request 'chore(nextcloud): migrate MariaDB 10.11 -> 11.8 LTS' (#75) from worktree-nextcloud-mariadb-11.8 into main