I'm currently managing a website hosted on Google Compute Engine, and we're planning to migrate from a legacy network protocol to a newer VPC that allows us to utilize Cloud NAT and Google DNS. While internal migrations can be done during off-hours without much issue, I'm particularly concerned about minimizing downtime for our public-facing website during this transition.
The steps I intend to follow include shutting down the VM, switching from the legacy network to the new VPC adapter, adding a network tag, and updating our database access, which is currently reliant on an external IP due to the limitations of the legacy setup.
For VMs, I usually use a blue/green deployment strategy where I clone the VM to the new network, test it, and then switch the public DNS when everything is good to go. However, I have some uncertainty about doing a similar process for our SQL database. I am worried that if I clone the database during the migration, I might end up with data discrepancies. Is there a reliable way to synchronize the database during this transition? I'm looking for guidance to ensure everything goes smoothly since this is my first time managing such a swap for an SQL database.
2 Answers
For minimizing downtime, what you described seems a lot like blue/green deployment, which is great for VMs. The approach would include creating a backup of your SQL database, upgrading that first, and then switching users over to the backup when ready. This method allows you to have minimal downtime since the failover is the only point where users might notice something. If you're utilizing a load balancer, you could do something similar by isolating the node before upgrading it – keeping things operational while you do necessary changes.
Is your website for a business or something else? If it's absolutely critical to avoid downtime, having multiple database nodes can truly bolster your setup. But if it's more of a personal project, you might just plan to do the migration during low traffic hours instead. Sometimes it's better to just go down for a short period, especially if that avoids a complex synchronization problem later on.
It's a business site, so I'm hoping for as little downtime as possible. Still, I want to weigh all options before making a decision.
That's a good strategy! I agree, as long as you isolate your upgrade processes, it can be done with minimal visibility to users. Just remember with data changes, the timing of your switch will be essential to avoid data loss.