Database Migration Service¶

DMS replicates data between heterogeneous and homogeneous sources/targets — useful for cloud migrations, version upgrades, and continuous replication for DR.

Supported pairs¶

Source	Target
PostgreSQL (any 11+)	Cloud Digit Managed PostgreSQL
MySQL/MariaDB (5.7+, 10.3+)	Cloud Digit Managed MySQL/MariaDB
MongoDB (3.6+)	Cloud Digit Managed MongoDB
Oracle (11g+)	Managed PostgreSQL (with conversion)
SQL Server (2014+)	Managed MySQL or PostgreSQL
Cloud Digit DBs	Another region (DR replication)

Conversion (Oracle → Postgres, SQL Server → MySQL) handles schema and most syntax; manual review of stored procedures.

IAM¶

Role	Can do
dms.viewer	List replication tasks, view progress
dms.operator	Start / pause / resume replication tasks
dms.builder	Create replication tasks and endpoints
dms.admin	Above + delete endpoints, manage CDC config

Endpoint configuration¶

Source and target endpoints store credentials in Cloud Digit Secrets Manager (no plain-text DSNs in DMS config):

bash cd dms endpoint create \ --name onprem-pg \ --engine postgres \ --host 192.168.10.5 --port 5432 \ --database prod \ --credential-secret openbao://acme/onprem-pg-rw

Migration phases¶

A full DMS migration:

1. Full load — bulk copy current data
2. CDC — Change-Data-Capture, replicates ongoing changes
3. Cutover — apps switch from source to target; CDC catches the final delta

The platform supports all three or any subset (full-load only, CDC only, or both).

Network¶

Source must be reachable from Cloud Digit: - Public-IP source: target must allow Cloud Digit egress IPs - VPN/Direct Connect source: routable from the DMS workload subnet - Cloud Digit-to-Cloud Digit: automatic

Related¶

• DMS — Operation
• DMS — Troubleshooting

Metrics¶

Metric	Healthy	Alert
dms.task.state	running	error, failed
dms.full_load.percent_complete	rising	stuck
dms.cdc.lag_seconds	< 5 s	> 30 s
dms.cdc.events_per_sec	matches source rate	< 50% of source rate (lag building)
dms.errors_24h	0	> 0

Pre-migration assessment¶

Before the real cutover, do a dry-run:

bash cd dms assess --source onprem-pg --target managed-pg-prod

Reports: - Schema objects (tables, views, sequences, functions) - Datatype compatibility issues - Estimated full-load duration - Required source modifications (e.g., enable WAL for CDC)

Full load + CDC¶

bash cd dms task create \ --name onprem-to-cloud \ --source onprem-pg \ --target managed-pg-prod \ --type full-load-and-cdc \ --tables 'public.*' \ --start now

Full load uses parallel workers per table (configurable). For 1 TB+ databases, expect hours.

Cutover ceremony¶

1. Quiesce app writes (read-only mode, or scheduled maintenance)
2. Wait for dms.cdc.lag_seconds = 0
3. Final consistency check: row counts, checksum sample
4. Stop the task: cd dms task stop --task <id>
5. Repoint app to new database
6. Resume traffic

Total downtime typically 5–10 minutes for an organized cutover.

Continuous replication for DR¶

Don't stop the task post-cutover — use CDC for ongoing replication to a DR target:

bash cd dms task create --type cdc-only --source managed-pg-prod-dha --target managed-pg-prod-ctg

dms.cdc.lag_seconds becomes the RPO metric.

Related¶

• DMS — Administration
• DMS — Troubleshooting

Endpoint test fails¶

bash cd dms endpoint test --endpoint onprem-pg

Symptom	Likely cause
Connection refused	Network / SG / firewall
Authentication failed	Wrong credential in Secrets Manager
must be superuser to access	DMS user needs replication permissions
WAL level must be logical	Source Postgres not configured for CDC

For Postgres CDC: wal_level = logical, max_replication_slots ≥ 10, max_wal_senders ≥ 10. Restart required.

Full load slow¶

Tune parallelism:

bash cd dms task update --task <id> --parallel-workers 8

Bottleneck identification: - Source disk read saturated → can't go faster - Target write saturated → resize target - Network plane → check inter-region link - Single huge table → table-level parallelism with WHERE slicing

CDC lag climbing¶

dms.cdc.lag_seconds > 30 and rising:

• Source generating more events than target can apply
• A specific large transaction stuck (DDL on a huge table)
• Replication slot conflict (Postgres) — another consumer reading the WAL

Pause writes briefly to let CDC catch up; investigate; resume.

"Replication slot was removed"¶

A Postgres replication slot lost during a primary failover or manual cleanup. CDC can't resume from a missing slot.

• Re-create the slot on the source
• Re-bootstrap the task (full load again, then CDC)

Data drift after cutover¶

Source and target counts don't match, or specific rows differ:

bash cd dms validate --task <id> --tables 'public.orders' --sample 10000

Common causes: - Trigger on source modified data after the task started; trigger fired on target too (double-apply) - Sequence values not migrated; new inserts on target reused IDs - Default values differed between Oracle and Postgres conversion

Schema conversion gaps¶

After Oracle→Postgres conversion, things that often need manual review: - Stored procedures with Oracle-specific syntax - Materialized views - Indexes with function expressions - Trigger logic

DMS reports unresolved issues in the assessment; address before cutover.

Related¶

• DMS — Administration
• DMS — Operation