Adds a single-file mysqldump backup + reimport-on-restore hook (mysql_backup.sh). The published recipe dumps via mysqldump --tab but ships no restore hook, so restore was a silent no-op (data loss). Same fix class as the postgres recipes. Caught by cc-ci P4 data-integrity test.
Adds a single-file mysqldump backup + reimport-on-restore hook (mysql_backup.sh). The published recipe dumps via mysqldump --tab but ships no restore hook, so restore was a silent no-op (data loss). Same fix class as the postgres recipes. Caught by cc-ci P4 data-integrity test.
The previous recipe backed the DB up as a mysqldump --tab into /var/lib/mysql-files with NO restore
hook (and the mysql data volume itself was not backupbot-labelled), so a restored backup silently
kept the live, un-restored DB state — data loss on restore. Add mysql_backup.sh (backup: gzipped
mysqldump --databases ghost into the data volume; restore: reimport it) wired via backupbot
backup.pre-hook + restore.post-hook, mirroring the postgres recipes (mattermost-lts, immich). Bump
1.2.0 -> 1.3.0.
backupbot restores backed-up files by volume; an absolute backup.path is not mapped back into the
volume on restore, so the restore.post-hook reimported a missing dump. Use
backupbot.backup.volumes.mysql.path=backup.sql.gz (mirrors the postgres recipes).
Ghost's fresh-DB first boot runs a full schema migration (dozens of CREATE
TABLEs, each a separate MySQL round-trip; ~6-9min on a small/slow node). The
1m start_period + 10x30s retries (~6min grace) is too tight there: swarm marks
the still-migrating task unhealthy and kills it mid-migration, leaving a stale
migrations_lock row so every later task deadlocks (MigrationsAreLockedError).
start_period only widens the startup grace window: a healthy check still marks
the task healthy immediately, so fast hosts are unaffected. It cannot be exposed
as an env var (abra validates the literal compose 'duration' format BEFORE env
substitution, rejecting ${VAR} / "${VAR:-1m}" with FATA 'Does not match format
duration'), so a literal bump is the only way to widen it.
Reopened. This PR was auto-closed in error by the old /recipe-upgradesuperseded behavior when upgrade PR #2 was opened — but it's unrelated to that upgrade: it's a real backup/restore data-loss fix (restore was a silent no-op). That auto-close-superseded behavior has now been removed, so unrelated open PRs stay open. @notplants please review.
Reopened. This PR was auto-closed in error by the old `/recipe-upgrade` *superseded* behavior when upgrade PR #2 was opened — but it's unrelated to that upgrade: it's a real backup/restore data-loss fix (restore was a silent no-op). That auto-close-superseded behavior has now been removed, so unrelated open PRs stay open. @notplants please review.
autonomic-bot
changed title from fix(backup): reimport mysqldump on restore (restore was a no-op) to fix(backup) + chore: upgrade to 1.3.0+6.42.0-alpine2026-06-02 02:05:09 +00:00
Move the mysqldump/gunzip commands directly into the
backupbot.backup.pre-hook / backupbot.restore.post-hook label values
on the db service and delete the external mysql_backup.sh + its
config mount + MYSQL_BACKUP_VERSION. Matches the inline pattern used
by akaunting / engelsystem / forgejo and removes one file from the
recipe surface area.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adds a single-file mysqldump backup + reimport-on-restore hook (mysql_backup.sh). The published recipe dumps via mysqldump --tab but ships no restore hook, so restore was a silent no-op (data loss). Same fix class as the postgres recipes. Caught by cc-ci P4 data-integrity test.
Ghost's fresh-DB first boot runs a full schema migration (dozens of CREATE TABLEs, each a separate MySQL round-trip; ~6-9min on a small/slow node). The 1m start_period + 10x30s retries (~6min grace) is too tight there: swarm marks the still-migrating task unhealthy and kills it mid-migration, leaving a stale migrations_lock row so every later task deadlocks (MigrationsAreLockedError). start_period only widens the startup grace window: a healthy check still marks the task healthy immediately, so fast hosts are unaffected. It cannot be exposed as an env var (abra validates the literal compose 'duration' format BEFORE env substitution, rejecting ${VAR} / "${VAR:-1m}" with FATA 'Does not match format duration'), so a literal bump is the only way to widen it.Auto-closed by /recipe-upgrade: superseded by upgrade-1.3.0+6.42.0-alpine (fresh upgrade against current upstream main)
Reopened. This PR was auto-closed in error by the old
/recipe-upgradesuperseded behavior when upgrade PR #2 was opened — but it's unrelated to that upgrade: it's a real backup/restore data-loss fix (restore was a silent no-op). That auto-close-superseded behavior has now been removed, so unrelated open PRs stay open. @notplants please review.fix(backup): reimport mysqldump on restore (restore was a no-op)to fix(backup) + chore: upgrade to 1.3.0+6.42.0-alpine!testme
🌻 cc-ci —
ghost@26ef5e66✅ passedfull logs · dashboard
!testme
26ef5e6625to11bac13e30!testme
🌻 cc-ci —
ghost@11bac13e✅ passedfull logs · dashboard