Fascinated by the world of cloud databases? Explore the methods for structuring, scaling, and securing database solutions on Google Cloud as you gear up for the Professional Cloud Database Engineer exam!
Before moving any data, a team must understand what they are migrating and where it is going. Database Assessment tools help inventory existing databases, identify dependencies, and evaluate compatibility with target GCP services. The assessment covers schema structure, stored procedures, data types, and application queries that might break after migration. Teams use this information to choose between a homogeneous migration (same database engine, such as Oracle to Cloud SQL for MySQL) and a heterogeneous migration (different engine, such as SQL Server to Cloud Spanner). The assessment also determines whether the migration can be done online with minimal downtime or must be done offline during a maintenance window.
GCP provides several tools that match different migration scenarios. Database Migration Service (DMS) handles continuous replication for homogeneous migrations to Cloud SQL and supports both one-time and ongoing data sync. For heterogeneous migrations, Striim or custom Dataflow pipelines transform and move data between incompatible systems. Transfer Appliance works for very large datasets where network transfer would take too long; the appliance is shipped to the data center, loaded, and sent back to Google for ingestion. The choice depends on network bandwidth, data volume, downtime tolerance, and whether the source and target use the same database engine.
Replication keeps data consistent between the source and target during and after migration. Change Data Capture (CDC) reads database transaction logs to capture inserts, updates, and deletes as they happen, sending only the changes to the target. This approach keeps the target nearly in sync with the source, which is critical for online migrations where the source continues serving traffic. For ongoing replication after migration, Cloud SQL read replicas offload read traffic and provide a failover target, while Cloud Spanner uses built-in replication across regions for high availability. The replication direction matters: one-way replication sends changes from source to target, while bidirectional replication allows both databases to accept writes but requires conflict resolution logic.
The final step moves traffic from the source database to the target. A cutover plan specifies the order of operations: stop writes to the source, verify the target has all data, update application connection strings, and redirect traffic. Validation checks compare row counts, checksums, and sample queries between source and target to catch data loss or corruption. Teams often perform a dry run cutover in a staging environment to measure downtime and test rollback procedures. If the cutover fails, the rollback plan restores the source database and reconnects applications, preserving the original state with minimal data loss.
Prepare and test your skills
Prepare and test your skills
A homogeneous migration transfers data between the same database engine, whereas a heterogeneous migration moves data between different database engines. Homogeneous migrations to Cloud SQL can use Database Migration Service (DMS) for continuous replication, while heterogeneous migrations rely on tools like Striim or custom Dataflow pipelines to transform and move data.
Change Data Capture (CDC) reads database transaction logs to capture inserts, updates, and deletes as they happen and transmits only those changes to the target. This keeps the target system nearly in sync with the source, allowing the migration to proceed while the source database continues serving live traffic.
Transfer Appliance should be used for very large datasets when transferring data over the network would take too long. The physical appliance is shipped directly to the data center, loaded with data, and returned to Google for ingestion.
Data integrity is verified using validation checks that compare row counts, checksums, and sample queries between the source and target databases to catch data loss or corruption. Teams also execute dry run cutovers in staging environments to measure downtime and test rollback procedures before performing the final cutover.