Stop scheduling maintenance windows for database moves. It's 2023.
I still see it in Slack channels and Jira tickets: "Site maintenance scheduled: Saturday 02:00 - 06:00 for server migration." If you are running a static brochure site, fine. But if you are managing a high-transaction e-commerce platform or a SaaS application targeting the Nordic market, four hours of downtime is unacceptable. It's also unnecessary.
I have spent the last decade fixing failed migrations. The pattern is always the same: a `mysqldump` that took longer than expected, a corrupted `rsync` transfer because the file system changed mid-flight, or latency issues because someone thought hosting a database in Virginia made sense for users in Oslo.
This guide isn't about using fancy SaaS migration tools that hide the logic from you. This is about the battle-tested, shell-based method of Replication-Based Migration. We are going to treat your new server not as a backup target, but as a live replica until the split-second cutover.
The Architecture of a Live Move
The concept is simple, even if the execution requires nerves of steel. We don't "move" the database. We extend it. We establish a Master-Slave relationship between your old legacy host and your new high-performance instance (ideally running on pure NVMe storage to handle the catch-up I/O).
The Workflow:
- Configure the Source (Old Server) for replication.
- Take a consistent snapshot (without locking the DB for hours).
- Restore on the Destination (New CoolVDS Instance).
- Start replication to process the "delta" (changes that happened during the transfer).
- Switch the application pointer.
1. Preparing the Source (MySQL/MariaDB Example)
If you haven't enabled binary logging, you can't do this. Edit your `my.cnf` or `my.ini`. You need `GTID` (Global Transaction ID) enabled for sanity. Dealing with log file positions manually is a recipe for disaster in 2023.
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
expire_logs_days = 7
max_binlog_size = 100M
# GTID settings for robustness
gtid_mode = ON
enforce_gtid_consistency = ON
Restart the service. Yes, this requires a momentary blip, but it's the only one you'll have until the final cutover.
Pro Tip: When moving data across the internet, security is not optional. Do not just open port 3306 to the world. Use a VPN tunnel or restrict the firewall specifically to the IP of your CoolVDS instance. If you are using our infrastructure, we recommend setting up a private VLAN if both nodes are within our ecosystem. If migrating from outside, use `iptables` or `ufw` strictly.
2. The Replication User
Create a user strictly for the replication process. Do not use root.
CREATE USER 'repl_user'@'192.168.1.50' IDENTIFIED BY 'ComplexPassword_2023!';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.1.50';
FLUSH PRIVILEGES;
The Heavy Lift: Physical Backups over Logical Dumps
Stop using `mysqldump` for datasets larger than 5GB. It is single-threaded (mostly) and rebuilding indexes on the receiving end takes forever. Use Percona XtraBackup (for MySQL) or Mariabackup. These tools copy the physical data files while the database remains hot.
Here is how we stream a backup from the old server directly to your new NVMe instance on CoolVDS using `socat`. This avoids writing to the disk on the source (which might be full/slow).
On the Destination (CoolVDS):
socat -u TCP-LISTEN:4444,reuseaddr stdout | xbstream -x -C /var/lib/mysql/tmp_migration/On the Source (Old Host):
mariabackup --backup --stream=xbstream | socat -u stdio TCP:NEW_SERVER_IP:4444This pipeline is efficient. It maxes out your bandwidth, not your CPU. Once the transfer hits our network, the high write speeds of our NVMe storage ensure the data lands without I/O bottlenecks. Bottlenecks are usually why replication lags and migrations fail.
3. Catching Up
Once the snapshot is restored and permissions fixed (`chown -R mysql:mysql`), you start the slave. Because we used GTID, the new server knows exactly where it left off.
CHANGE MASTER TO
MASTER_HOST='OLD_SERVER_IP',
MASTER_USER='repl_user',
MASTER_PASSWORD='ComplexPassword_2023!',
MASTER_AUTO_POSITION=1;
START SLAVE;
Monitor the `Seconds_Behind_Master`. It should drop to zero. If you are migrating to CoolVDS from a budget VPS provider, you will often see the replication apply logs faster than the source can generate them, thanks to superior CPU stealing governance and disk I/O.
The Local Context: Latency and Law
Why does this matter for Norwegian businesses? Two reasons: Physics and Datatilsynet.
Latency (The Physics)
If your application servers are in Oslo and your database is in Frankfurt, you are eating a 15-25ms round-trip penalty on every query. For a complex Magento page load generating 100 queries, that is 2.5 seconds of sheer network wait time. By migrating to a local provider with direct peering to NIX (Norwegian Internet Exchange), you drop that latency to sub-2ms.
GDPR & Schrems II (The Law)
Since the Schrems II ruling, transferring personal data to US-owned cloud providers has become a legal minefield. Many CTOs are repatriating data to sovereign European infrastructure to satisfy compliance requirements. When you migrate to CoolVDS, you are ensuring the data resides physically in Norway, under Norwegian jurisdiction, simplifying your GDPR compliance posture immediately.
4. The Cutover
The scary part. But since your data is already there and synced, it's painless.
- Set the old application to "Read Only" mode (optional, but safer).
- Verify `Seconds_Behind_Master` is 0.
- Stop the Slave on the new server: `STOP SLAVE; RESET SLAVE ALL;`.
- Update your application's `config.php` / `.env` file to point to the new CoolVDS IP.
If you've lowered your DNS TTL (Time To Live) to 300 seconds a day before, propagation will be swift. Or, better yet, swap the floating IP if you are using a load balancer.
Summary
Migrations expose the weak points in your stack. Slow disks, poor network peering, and sloppy configurations will halt a live transfer. We built CoolVDS with KVM virtualization and NVMe storage specifically to handle high-stress operations like this. We don't throttle your I/O when you need it most.
Don't let legacy infrastructure hold your data hostage. Spin up a test instance today and benchmark the I/O. You'll see why the migration is worth the effort.