A journey towards continuous innovation and cloud adoption
Data deluge and data explosion is coming at us from many sources. The Multiplicity of inbound data and its compounding growth has put pressure on already strained on-prem datastores and databases operating at full capacity. Cloud offers enterprises and businesses a fast path towards managing growth in the databases effectively by moving to cloud.
Performance degrades, user experience drops, replication fails, and response times increase, all too familiar issues we have seen, can be addressed by such migrations. However, migration to cloud is always regarded as a high risk type of an endeavour, and delayed or put on the back burner till in some cases is inevitable and causes loss of productivity, performance and market share. What if there was a way to get enterprises ready to move and all the heavy lifting was factored in and built in a service! Wala that movement has arrived. Get Primed up for migration but not the long cycle! Google has just launched the Database Migration Service for early adopters(Nov 2020). This self service is inline with Google Cloud aim of democratizing data and data science to all levels of practitioners and offer repeatability with accelerated (High reward/QuickROI) migrations efforts. According to a survey conducted by Stratoscale – 52% of the customers think of Database migration to cloud as a trigger to digital transformation and over 48% think of the move to Public Cloud as bringing significant cost reductions to business operations.
Google Cloud Platform has launched its (pre-GA mode) Database Migration Services In Nov 2020. DMS currently focuses on homogeneous migrations – that is, migrations across compatible database engines, which don’t require transformations such as schema conversion from source to destination. In this case, the goal of the migration is for the migrated database to be as close as possible to a copy of the source database, available in the Cloud SQL destination.
Database Migration Service (DMS) makes it easy to migrate your production databases to Cloud SQL with minimal downtime. This serverless offering eliminates the manual hassle of provisioning, managing, and monitoring migration-specific resources. DMS leverages the native replication capabilities of MySQL and PostgreSQL to maximize the fidelity and reliability of your migration. The best part is that the service is free and it’s available for enterprise to use and deploy. It is applicable to My SQL, and SQL Server with PostgreSQL in early access mode. The only key requirements are for the source DB to be homogeneous and requiring no schema conversions between migration from source to targets. The service promotes minimal downtime and automates database provisioning, storage capacity management, and other time-consuming tasks.
- Serverless : True DBaaS model
- Business : Low Risk and quick ROI
- Secure : Google IAM Security
- Scalable : Infinitely scalable with no effort required
- Downtime : Minimal downtime
- Innovation : Access to Built in integrations – GKE, BigQuery
What makes it different?
While the fully managed DB service is very attractive for businesses and enterprises, the elements of risk and effort also need to be reviewed in the light of efforts and risk-reward calculations. The service is enabled by the Discovery Document Templates that take care of connectivity, source and targets ID’s and migration jobs selected. These pre-built and designed templates allow and account for all items to be taken care of in case of a database migration and have been tested and validated by Google engineers and developers. This not only reduces the risk, but the upfront planning and development effort by an order of magnitude depending on an organization and team’s maturity and Cloud skill’s as it relates to various services in Google Cloud Platform. This enables the business to move very quickly from on-prem to cloud leveraging all the DMS tools and workflow.
Document Discovery Templates
The provided templates enable a very focused and low risk (minimal downtime) migration approach by following the workflow as below:
- Enable API’s in GCP platform Console
- Create a migration job
- Describe the migration Job (details around source, type, meta data)
- You need to decide if this is one time or continuous replication over a period of time when perhaps network traffic is low and or database polling is not in effect
- Create connection Profiles
- Define a connection profile that represents the connectivity info of the source database, which will be used in the migration job
- Note that migrations are frequently initiated directly against the primary database, but in the cases where the primary is load-sensitive, or many DDLs run on it, it’s preferable to connect to a read replica
- If you have completed the above steps, you are ready to start the migration using test jobs and testing the overall process from source to target in terms of connectivity, data movement and replication integrity
Once you have done the source database assessment based on the pre-qualification criteria and application dependencies, it is optimal to group the qualified databases in a migration wave based on affinity grouping and application mapping. Careful planning in terms of database sizing and required duration of actual migration (data transfer) and sync-up efforts helps in defining the overall timeline and cut-over sequencing. Depending on the type of migration approach – one time or continuous replication, the CDC will initiate the start of the process and finish once the data has been moved and the 2 databases are in sync. Last step is promotion of the destination Cloud SQL target into primary by disconnecting it from the source and promoting it to being the primary. The destination database now becomes the primary database, and dependent applications should read and write to it. Standard Housekeeping prior to migration shutdown any writes to the db, no connections and running scripts when you start the migration job.
The Database Migration Service for MySQL supports one-time and continuous migrations from source databases to Cloud SQL destination databases. Destination database supported is Cloud SQL for MySQL 5.6, 5.7, 8.0
5.5, 5.6, 5.7, 8.0
|Amazon RDS |
5.6, 5.7, 8.0
5.5, 5.6, 5.7, 8.0
Restrictions and Limitations
- If the source is RDS MySQL, or a source that doesn’t grant SUPERUSER privileges, then additional steps are required for successful migration, including a brief write downtime on the source. For more information, see the RDS-specific section for guidelines
- The MySQL system database isn’t migrated as part of the server migration, which means information about user roles isn’t included
- Encrypted databases can’t be migrated
- During migration, the destination Cloud SQL database is in read-only mode, to prevent modification of the database which might break the migration process or data integrity. After the destination is promoted, it becomes writable
- Up to 2,000 connection profiles and 1,000 migration jobs can exist at any given time. To create space for more, migration jobs (including completed ones) and connection profiles can be deleted