Zero-Downtime Database Migration: The 2018 Survival Guide for Norwegian Infrastructure

Let’s be honest. The phrase "scheduled maintenance window" is becoming a relic. If you tell a client in 2018 that their e-commerce platform needs to go dark for four hours to move from a legacy dedicated server to a cloud VPS, they won't thank you for your caution. They will ask why you aren't like Amazon. Migration day is usually the only day caffeine doesn't work, because the adrenaline of potentially corrupting 500GB of InnoDB tables keeps you plenty awake.

I have overseen migrations for high-traffic portals in Oslo where a 500ms latency spike triggers a barrage of Slack notifications. The margin for error is nonexistent. Whether you are moving from on-premise iron to a high-performance VPS or shuffling between data centers to satisfy the new GDPR requirements that hit us in May, the physics of moving data remains the same. You need bandwidth, you need IOPS, and you need a plan that assumes everything will fail.

The Latency Trap: Why Geography Matters

Before we touch a single config file, look at your network topology. Many DevOps engineers assume the internet is a flat plane. It isn't. If your target audience is in Norway, hosting your database in a cheap Frankfurt or Amsterdam data center introduces a permanent latency penalty. We are talking about the difference between 25ms and 5ms. In a complex JOIN query fetching data for a frontend render, those milliseconds stack up.

When migrating, throughput is your bottleneck. If you are pushing data over the public internet, you are at the mercy of the hops between your old provider and the new one. This is why peering at NIX (Norwegian Internet Exchange) is critical. When we provision instances on CoolVDS, we see reduced hop counts to major Norwegian ISPs. Lower latency doesn't just mean faster page loads; it means faster replication lag recovery during the cutover phase.

Step 1: The Transport Layer

Don't use plain FTP, and for the love of root, don't use unencrypted netcat unless you want to explain a data breach to Datatilsynet. We use rsync over SSH, but standard settings are often too slow for terabyte-scale datasets. Encryption is CPU expensive. If you are on a trusted private network (VPN or distinct VLAN), you can lower the encryption overhead, but over the WAN, we need to balance security and speed.

Here is a robust command for the initial sync of static assets (like user uploads) that preserves permissions and provides progress:

rsync -avzhe "ssh -p 22" --progress --stats /var/www/html/storage/ user@target-ip:/var/www/html/storage/

Pro Tip: If you are migrating a massive dataset and CPU is your bottleneck on the receiving end (common with compression), drop the -z flag. On modern 1Gbps or 10Gbps links, the CPU time spent compressing data often slows you down more than the network transfer itself. Test throughput with iperf3 before committing.

Step 2: Database Replication Strategy

For the database, mysqldump is fine for a 500MB WordPress site. It is suicide for a 50GB Magento store. The table locks will kill your live site, and the restore time will extend your maintenance window into next week. In late 2018, the industry standard for zero-downtime migration is Master-Slave Replication.

We use Percona XtraBackup. It allows you to take a hot backup of your MySQL/MariaDB data without locking your tables (for InnoDB). Here is the workflow:

1. Install Percona XtraBackup on the source server.
2. Create the backup while the live site is running.
3. Stream the backup to the new CoolVDS NVMe instance.

Here is how to stream a backup directly to the new server without writing to the local disk (saving IOPS on the source):

innobackupex --stream=xbstream /tmp | ssh user@new-server-ip "xbstream -x -C /var/lib/mysql/"

Once the data is there, you prepare the backup and configure the new server as a SLAVE. This catches up on all the writes that happened during the transfer.

Optimizing the Import

The slowest part of any migration is the disk write speed on the destination. This is where hardware choices expose themselves. Spinning rust (HDDs) will choke on random writes during the restore/catch-up phase. SSDs are better. NVMe is the only responsible choice in 2018 for database workloads.

On CoolVDS, our KVM instances map directly to NVMe storage. However, you still need to tune MySQL to utilize that speed. During the import phase, temporarily relax your ACID compliance to speed up writes. Add this to your my.cnf on the new server (revert after migration!):

[mysqld]
# DANGEROUS: Only for import phase
innodb_flush_log_at_trx_commit = 0
innodb_doublewrite = 0
sync_binlog = 0

# Performance essentials
innodb_buffer_pool_size = 6G  # Set to 70% of available RAM
innodb_log_file_size = 1G
innodb_io_capacity = 2000     # Crank this up for NVMe

Setting innodb_io_capacity to 2000 (or higher) tells MySQL, "I have fast storage, don't hold back." Default values often assume you are running on a laptop hard drive from 2010.

Step 3: The Cutover and GDPR Compliance

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

1. Switch your application to "Read-Only" mode (maintenance page).
2. Verify the slave has processed the final transaction.
3. Promote the CoolVDS slave to MASTER.
4. Point your DNS or Load Balancer to the new IP.

A note on GDPR: Since May 25th, data residency is not just a technical detail; it's a legal one. If you are migrating personal data of Norwegian citizens, ensure your hosting provider offers a Data Processing Agreement (DPA). Moving data to a provider that routes traffic through non-EEA territories without Privacy Shield certification creates a compliance headache you don't need.

Troubleshooting: The "Gotchas"

If you are moving from MySQL 5.7 to MySQL 8.0 (which went GA earlier this year), watch out for the default authentication plugin change to caching_sha2_password. Old PHP drivers (pre-7.2) will fail to connect. You might need to revert the user to legacy authentication:

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';

Migration is stress testing for your infrastructure. If your target VPS has "noisy neighbors" stealing CPU cycles, your replication catch-up will stall. We built CoolVDS on KVM specifically to isolate resources. We don't oversell CPU, because when you are processing binary logs at 50MB/s, you need every cycle you paid for.

Don't let slow I/O or poor planning kill your uptime. Plan the network route, use hot backups, and run on NVMe.

Ready to test your migration plan? Deploy a high-performance CoolVDS instance in Norway in under 55 seconds and see the IOPS difference yourself.