Create the target database first, with the same engine (PostgreSQL to PostgreSQL, MySQL to MySQL, MariaDB to MariaDB) and a version no older than the source. Data flows straight from the source into the new database. The migration itself is free; the database is billed as usual.
| Method | How it works | Downtime |
|---|---|---|
| Migrate and keep in sync (recommended) | Copies everything, then follows the source’s changes until you cut over | Minutes, at cutover |
| One-time copy (full dump) | Copies everything once | Stop writing to the source while it runs |
Step by step
- Open the target database, go to the Migrate in tab and click Start a migration.
- Choose the method, then enter the source’s host, port, user and password, and the encryption (TLS is the default).
- Allow the address shown on the page in the source’s firewall or security group. For an address that never changes, add a NAT Gateway for the database’s subnet.
- Click Test connection, then choose the databases to migrate. Each lands under the same name, and the target databases must be empty.
- Click Run checks and fix anything it flags. The page also lists what the source needs (see below).
- Click Start migration. The page shows the copy, then In sync with how far behind the source it is.
- When you’re ready, stop your application writing to the source, click Cut over, wait for Completed, then point your application at the new database.
What the source needs for continuous sync
| Engine | Needs |
|---|---|
| PostgreSQL | wal_level=logical (on Amazon RDS: rds.logical_replication=1), a user with REPLICATION (RDS: rds_replication) who owns the tables or a publication made for you, and a free replication slot. Tables need a primary key to sync updates and deletes. |
| MySQL / MariaDB | The binary log on with binlog_format=ROW and kept at least a day, a non-zero server_id, and a user with SELECT, SHOW VIEW, TRIGGER, EVENT, RELOAD, REPLICATION SLAVE and REPLICATION CLIENT. MyISAM tables aren’t copied at one point in time. |
- While in sync, a MySQL or MariaDB target is read-only for applications. On PostgreSQL, don’t write to the migrated tables on the target, and don’t change table structure on the source: DDL such as
ALTER TABLEisn’t synced. - Count rows compares row counts on both sides at any time; cutover counts again for you.
- Users and grants on the source aren’t migrated. The migrated data belongs to the target’s main user; add other users on the Users & passwords tab afterwards.
- A read replica can’t be a target. Migrate into the primary; its replicas and standby get the data too.
Practise first: migrate into a database in your testing project, run your app against it, then do the real move.
If something goes wrong
Test connection fails
Check the host and port, that the source allows the address shown on the page, and the encryption setting. Use Not encrypted only when the source is in the same VPC.
Cutover paused: some tables have different row counts
Something still writes to the source. Stop every writer, then click Cut over again. If you have checked the tables listed, Cut over although rows differ goes ahead anyway.
It says replication is gone from this database
This can happen after the database fails over. Click Start again to migrate from the beginning; data already migrated is cleared first.
It asks me to drop a replication slot on the source
We couldn’t remove the slot we made. Run the pg_drop_replication_slot command shown, or the source keeps WAL until its disk fills.