Don't Let a Migration Murder Your Uptime

I still wake up in a cold sweat remembering a migration I botched in 2018. We were moving a 500GB MySQL cluster for a retail client in Oslo. I thought a simple mysqldump during the night would cut it. It didn't. The restore took six hours longer than estimated, the shop lost morning traffic, and my coffee intake reached lethal levels. Never again.

Database migration isn't just about moving bytes from Server A to Server B. It's about maintaining data integrity, minimizing locking, and—specifically for us operating in Norway and the EEA—adhering to strict data residency requirements enforced by Datatilsynet. With the Schrems II ruling still shaking up the industry, moving data blindly is a legal liability.

This guide is for the battle-hardened sysadmin. We aren't doing the "shut it down and copy it" method. We are doing live replication with minimal cutover time. And we are doing it on infrastructure that doesn't choke on I/O.

Phase 1: The Infrastructure Audit

Before you even touch a config file, look at your hardware. If you are migrating a write-heavy database to a VPS using standard spinning rust (HDD) or even SATA SSDs on a shared bus, stop. You are setting yourself up for high I/O wait times.

In 2022, NVMe is the baseline. Period. When we benchmark CoolVDS instances against legacy VPS providers, the difference in IOPS isn't just a number; it's the difference between a query finishing in 20ms or hanging for 2 seconds because a "noisy neighbor" is compiling a kernel next door. KVM virtualization provides the isolation, but the disk speed dictates the throughput.

Latency Matters

If your users are in Norway, your database needs to be in Norway. Routing traffic through Frankfurt adds 15-20ms of round-trip time. That adds up fast on complex joins. Checking your ping to NIX (Norwegian Internet Exchange) is a good sanity check.

# Check latency from your potential new host to NIX
ping -c 5 194.19.255.1

Phase 2: The Strategy (Replication, Not Dump)

For datasets larger than 10GB, the "Dump and Restore" method is obsolete. The downtime is linear to the database size. The professional approach is Master-Slave Replication.

You set up the new server (CoolVDS) as a slave (replica) of your current production server. Once they are in sync, you promote the slave to master. Downtime is reduced to the seconds it takes to switch your app's connection string.

Scenario A: MySQL / MariaDB

Ensure your source server has binary logging enabled. Without this, replication is impossible.

# /etc/mysql/my.cnf on the SOURCE server
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 100M

After restarting MySQL, create a replication user. Restrict it to the specific IP of your new CoolVDS instance for security. Don't use % wildcard; that's asking for a breach.

CREATE USER 'replicator'@'185.x.x.x' IDENTIFIED BY 'ComplexPassword_2022!';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'185.x.x.x';
FLUSH PRIVILEGES;

Pro Tip: If your dataset is huge, use Percona XtraBackup instead of mysqldump. It creates a physical backup without locking the database, which allows for a faster initial sync.

Scenario B: PostgreSQL 14

PostgreSQL 14 (current stable) makes this robust with replication slots. Edit your postgresql.conf:

wal_level = replica
max_wal_senders = 10
wal_keep_size = 512MB  # Critical if your network is jittery

And update pg_hba.conf to allow the connection:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     rep_user        185.x.x.x/32            scram-sha-256

Phase 3: The Data Transfer

Once the config is ready, you need the initial dataset. For MySQL, if you aren't using XtraBackup, use mysqldump with the --single-transaction flag to ensure data consistency without locking InnoDB tables.

mysqldump -u root -p --all-databases --master-data=2 --single-transaction --routines --triggers > full_dump.sql

Transfer this to your CoolVDS instance securely. We use rsync over SSH because it allows resuming if the connection drops—a lifesaver when moving 100GB+ files.

rsync -avz --progress -e "ssh -p 22" full_dump.sql user@new-server-ip:/tmp/

Phase 4: Optimization & Cutover

Before you switch traffic, tune the new server. A fresh installation usually comes with generic defaults. If you have 32GB RAM on your CoolVDS instance, don't leave the defaults active.

MySQL Tuning Example:

[mysqld]
# Allocate 70-80% of RAM to the buffer pool for a dedicated DB server
innodb_buffer_pool_size = 24G
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 1 # Essential for ACID compliance
max_connections = 500

Once the slave is running and Seconds_Behind_Master is 0, you are ready.

1. Lower the TTL on your DNS records to 300 seconds a day before.
2. Put your application in "Maintenance Mode" (or Read-Only).
3. Verify the slave has processed all transactions.
4. Promote the slave to Master.
5. Update application config to point to the new IP.
6. Lift Maintenance Mode.

The GDPR & Datatilsynet Angle

Here is where the generic tutorials fail you. Since July 2020, relying on Privacy Shield for US transfers is illegal. If you are migrating away from a US hyperscaler to a local provider, you are doing your compliance officer a favor.

Ensure your hosting provider guarantees data residency. At CoolVDS, our data centers are strictly within the EEA (Norway/Europe), ensuring that you don't run afoul of Chapter V of the GDPR. We have seen clients get audited by Datatilsynet, and having a clear data topology map showing "Data Stays in Norway" simplifies that conversation significantly.

Why We Build on CoolVDS

I don't recommend tools I don't use. We built CoolVDS because we were tired of "virtual CPUs" that vanished under load. When you are running a database, IOPS are the currency of performance. Our standard NVMe storage arrays deliver the low latency required for high-transaction databases like Magento or heavy ERP systems.

Database migration is stressful. But with the right hardware foundation and a replication-first strategy, it doesn't have to be a disaster. Plan your config, secure your transport, and keep your data on Norwegian soil.

Ready to test your replication speed? Deploy a high-performance NVMe instance on CoolVDS in under 55 seconds and see the I/O difference yourself.