mchus/bible
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add mandatory DB backup rule

Browse Source
This commit is contained in:
Mikhail Chusavitin
2026-03-07 21:39:37 +03:00
parent 72e10622ba
commit 548eb70d55
1 changed files with 19 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
rules/patterns/go-database/contract.md
View File

@@ -1,6 +1,6 @@
# Contract: Database Patterns (Go / MySQL / MariaDB) # Contract: Database Patterns (Go / MySQL / MariaDB)
Version: 1.0 Version: 1.1
## MySQL Transaction Cursor Safety (CRITICAL) ## MySQL Transaction Cursor Safety (CRITICAL)
@@ -104,9 +104,27 @@ items, _ := repo.GetItemsByPricelistIDs(ids) // 1 query with WHERE id IN (...)
// then group in Go // then group in Go
``` ```
## Backup Before Any DB Change
Any operation that changes persisted database state must have a fresh backup taken immediately before execution.
This applies to:
- Go migrations
- Manual SQL runbooks
- Data backfills and repair scripts
- Imports, bulk updates, and bulk deletes
- Admin tools or one-off operator commands
Rules:
- No schema change or data mutation is allowed on a non-ephemeral database without a current backup.
- "Small" or "safe" changes are not exceptions.
- The operator must know how to restore from that backup before applying the change.
- If a migration or script is intended for production/staging, the rollout instructions must state the backup step explicitly.
## Migration Policy ## Migration Policy
- Migrations are numbered sequentially and never modified after merge. - Migrations are numbered sequentially and never modified after merge.
- Take and verify a fresh backup before applying migrations to any non-ephemeral database.
- Each migration must be reversible where possible (document rollback in a comment). - Each migration must be reversible where possible (document rollback in a comment).
- Never rename a column in one migration step — add new, backfill, drop old across separate deploys. - Never rename a column in one migration step — add new, backfill, drop old across separate deploys.
- Auto-apply migrations on startup is acceptable for internal tools; document if used. - Auto-apply migrations on startup is acceptable for internal tools; document if used.