Database Migration Service is the managed Google Cloud service for moving an existing database into Cloud SQL. It handles the initial bulk copy of your data and then keeps the destination in sync with the source through continuous replication, which lets you cut over with very little downtime once the two sides are caught up. The Professional Cloud Database Engineer exam tends not to ask whether you can start a migration. It asks what you do when a migration behaves in a way you did not expect, and a handful of specific scenarios come up often enough that they are worth knowing in detail. Each one comes down to understanding how the replication actually works underneath rather than how the setup wizard looks.
The first scenario involves a PostgreSQL source. You start the migration, the schema gets created on the Cloud SQL destination, and yet some of your data never arrives. The tables exist but stay empty. This happens because Database Migration Service migrates only tables that have primary keys. A table without one is silently left out of the data flow even though its structure was copied over.
The fix is to add primary key constraints to the affected tables on the source database. A primary key gives every row a unique identifier, and the replication engine relies on that identifier to track each row and apply changes accurately on the destination. Without a unique way to address a row, there is no reliable way to replicate inserts, updates, and deletes for that table, so it is excluded. Once the primary keys are in place on the source, those tables can be picked up and synchronized to Cloud SQL.
The second scenario also uses a PostgreSQL source, and here the migration job is already running. You need to bring a new table into the migration, but you do not want to stop and restart the job to do it. Restarting a migration is disruptive, so the goal is to extend the existing replication stream in place.
To do this you work with the replication plugin directly rather than through the migration job. PostgreSQL migrations use the pglogical extension on the source, and pglogical organizes the tables it replicates into a replication set. The default stream corresponds to a replication set named default. Adding a table is a matter of registering it with that set so the logical replication engine starts including it.
SELECT pglogical.replication_set_add_table('default', 'table_name');Calling this function on the source tells the replication engine to add the named table to the existing default stream. The new table then syncs to Cloud SQL alongside everything else, without a full restart of the migration job. This is a good example of why the exam cares about the mechanics. The answer is not a button in the console, it is a call into the replication plugin that the migration is built on.
The third scenario is a MySQL source where the main concern is the performance of the production database. Migrating a large database means reading a lot of data out of the source, and if the migration job pulls directly from the primary instance, that extraction work competes with live application traffic. For a busy production system that load can be a problem.
The approach here is to point the migration job at a read replica instead of the primary. The read replica stays in sync with the primary, so it holds the same data, and directing the migration at the replica moves the heavy read and extraction work off the primary entirely. Database Migration Service pulls from the replica while production traffic continues to hit the primary undisturbed. The migration still lands in Cloud SQL, but the source system that users depend on is kept isolated from the migration process.
The pattern across these three cases is that each problem is solved by reasoning about the replication layer, not by changing the migration job's high level settings. Empty tables on a PostgreSQL destination point to missing primary keys on the source. Adding a table mid-flight points to the pglogical replication set rather than a restart. Protecting a production MySQL instance points to migrating from a read replica so the extraction load lands somewhere else. When the Professional Cloud Database Engineer exam describes a migration that is not doing what you expect, it helps to ask which part of the replication mechanism the symptom is describing, because that is usually where the correct answer lives.
Our Professional Cloud Database Engineer course covers Cloud SQL migration with Database Migration Service alongside read replicas and high availability, with practice questions that drill these distinctions.
