Database Administrator

HOWTOs

Concrete operational procedures from the courses on this page.

• How to migrate a relational database to Amazon RDS or Aurora with DMS at near-zero downtime

  not executable: Needs a billed AWS account with a DMS replication instance, a source database that exposes change capture, and an RDS or Aurora target reachable from that instance. No runner in the fleet has that account. LocalStack does not implement a full-load-and-CDC DMS task a reader can trust as proof of these steps, so nothing here is executed.

  Moving a live relational database onto RDS or Aurora with an AWS DMS full-load-and-CDC task: the schema and index work around the load, the CDC latency gate that decides when a cutover is safe, and the reverse replication path that keeps rollback open.

  AWS Databases

• How to restore an Amazon RDS or Aurora database to a point in time after data corruption

  not executable: Needs a billed AWS account with an RDS or Aurora source that has automated backups enabled, because restore-db-instance-to-point-in-time and restore-db-cluster-to-point-in-time create a new billed instance beside the source. No runner in the fleet has that account. A local emulator cannot prove real PITR against AWS automated backups, so nothing here is executed.

  Recovering from a bad write by restoring RDS or Aurora point-in-time recovery into a new instance beside the untouched source, validating the restore time, and choosing between a full cutover and a selective repair.

  AWS Databases

• How to ship a breaking schema change with zero downtime using expand and contract

  verified on linux-amd64-proxmox, amd64, 2026-10-19, sha256:f635f01f2426dc7d8c5153a0bb556f1e585e8d27004bfa0b25cbac3dd61e4913

  Making a backward-incompatible column, table, or store change safe to ship while old and new application code run at once, by staging it across several releases that each stay compatible with the one before.

  Schema Migration and Change Management

• How to recover from a failed or partially applied migration

  verified on linux-amd64-proxmox, amd64, 2026-10-19, sha256:f635f01f2426dc7d8c5153a0bb556f1e585e8d27004bfa0b25cbac3dd61e4913

  What to do when a migration run fails partway, times out, or succeeds without being recorded and the schema, data, and migration history no longer agree: re-establishing the true state and moving forward without editing an applied migration.

  Schema Migration and Change Management

• How to run an online schema change without long locks

  not executable: The procedure is the copy-and-swap path (gh-ost, pt-online-schema-change, pg-osc): throttle thresholds on Threads_running and replica lag, a cut-over taken while the application is writing, and rollback through a retained table that stays current only under live write traffic. None of that is observable on an idle disposable database, which would pass without exercising the locks and lag the HOWTO exists to avoid. The native PostgreSQL commands it points to (CREATE INDEX CONCURRENTLY, NOT VALID then VALIDATE CONSTRAINT) are executed in the expand-and-contract HOWTO Scenario.

  Altering a large, busy table without the maintenance window a plain ALTER would need, covering when the database engine can do the change natively and when a copy-and-swap tool is the safer route.

  Schema Migration and Change Management