Hi, alexhguerra,
Users sometimes want to migrate their (normal) relational database with “zero” downtime. While downtime can be reduced, migration cannot be done without any impact on applications (that is, zero downtime). Replication causes replication lag.
The instant the decision is made to “migrate” all applications from one replica to another, applications (and therefore customers) have to wait (that is, downtime) at least as long as the “replication lag” before using the new database. In practice, the downtime is a few orders of magnitude higher (minutes to hours) because:
* Database queries can take multiple seconds to complete and in flight queries must be completed or aborted at the time of migration.
* The database has to be “warmed up” if it has substantial buffer memory - common in large databases.
* If database shards have duplicate tables, some writes may need to be paused while the shards are being migrated.
* Applications must be stopped at source and restarted in GCP and connection to the GCP database instance must be established.
* Network routes to the applications must be rerouted. Based on how DNS entries are set up, this can take some time.
All of these can be reduced with some planning and “cost” (some operations not permitted for some time before/after migration).
More about: https://cloud.google.com/architecture/database-migration-concepts-principles-part-1?hl=en