You are moving an application that uses MySQL from on-premises to Google Cloud. The application will run on Compute Engine and will use Cloud SQL. You want to cut over to the Compute Engine deployment of the application with minimal downtime and no data loss to your customers. You want to migrate the application with minimal modification. You also need to determine the cutover strategy. What should you do?
To achieve minimal downtime and no data loss during the migration of your MySQL-based application to Google Cloud, a replication strategy is advisable. Setting up Cloud VPN for private network connectivity between the Compute Engine application and the on-premises MySQL server ensures secure data transfer. Starting the Compute Engine application while configuring it to read and write to the on-premises MySQL server maintains continuity. Establishing replication between the on-premises MySQL server and Cloud SQL ensures ongoing data synchronization. Once replication is complete, promoting the Cloud SQL replica to a standalone instance guarantees minimal downtime during the final switch. Finally, restarting the Compute Engine application to read and write to the newly promoted Cloud SQL instance completes the migration with minimal impact to customers.
C. 1. Set up Cloud VPN to provide private network connectivity between the Compute Engine application and the on-premises MySQL server. 2. Stop the on-premises application. 3. Start the Compute Engine application, configured to read and write to the on-premises MySQL server. 4. Create the replication configuration in Cloud SQL. 5. Configure the source database server to accept connections from the Cloud SQL replica. 6. Finalize the Cloud SQL replica configuration. 7. When replication has been completed, stop the Compute Engine application. 8. Promote the Cloud SQL replica to a standalone instance. 9. Restart the Compute Engine application, configured to read and write to the Cloud SQL standalone instance.
Agree with C. The only confusing is step "5. Configure the source database server to accept connections from the Cloud SQL replica." Is that not replication should go in the opposite direction from the on-premise (a.k.a. "source") database to Cloud SQL replica (presuming the latter is configured with a public IP address)?
Ans C, from this guy muhasinem External replica promotion migration In the migration strategy of external replica promotion, you create an external database replica and synchronize the existing data to that replica. This can happen with minimal downtime to the existing database. When you have a replica database, the two databases have different roles that are referred to in this document as primary and replica. After the data is synchronized, you promote the replica to be the primary in order to move the management layer with minimal impact to database uptime. In Cloud SQL, an easy way to accomplish the external replica promotion is to use the automated migration workflow. This process automates many of the steps that are needed for this type of migration.
The answer is C) Every single option with mysqldump is wrong as it causes a significant downtime because the mysqldump command takes a snapshot of all data in the database. Depending on the size of your database, this process can take from less than a second to several hours. If any data is changed after the snapshot is taken, those changes are not captured in the final snapshot. hence no DDL,DML,TCL should take place during this period i.e application has to be down while mysqldump runs. BUT THIS IS NOT WHAT WE WANT, we want to minimized DOWNTIME. In support of Option C) read this google documentation on mysql migration specifically external replica promotion migration section, it explicitly mentions minimal downtime. https://cloud.google.com/architecture/migrating-mysql-to-cloudsql-concept#external_replica_promotion_migration
Answer is C we have a new service https://cloud.google.com/database-migration
Correct Answer: C - The best option for migrating your MySQL database is to use an external replica promotion. In this strategy, you create a replica database and set your existing database as the primary. You wait until the two databases are in sync, and you then promote your MySQL replica database to be the primary. This process minimizes database downtime related to the database migration. - https://cloud.google.com/architecture/migrating-mysql-to-cloudsql-concept#external_replica_promotion_migration
Well, as a guy who performed several migrations from on premise to cloud, I would never use one of those 4 scenarios except for small and clearly non critical applications. ^^ That said, at least the C tells you to use the replication method to replicate data from the local VM to the cloud which is the best way to get a correctly copied database. So let's go with C.
Examtopic providing A as correct answer is causing confusion,
C is ok
Ans - C, MySQL has two features that can help you migrate to Cloud SQL. These features are the basis for two strategies for migrating MySQL databases: export/import migration and external replica promotion migration. import/export normally requires downtime for the database during the entire migration in order to keep all data in sync. In the migration strategy of external replica promotion, you create an external database replica and synchronize the existing data to that replica. This can happen with minimal downtime to the existing database. https://cloud.google.com/architecture/migrating-mysql-to-cloudsql-concept
IMHO a) is the wrong answer - we have to choose c) considering that we have to minimize downtime. see: https://cloud.google.com/architecture/migrating-mysql-to-cloudsql-concept Export/import migration (alterantive a): ...This normally requires downtime for the database during the entire migration in order to keep all data in sync. External replica promotion migration: This can happen with minimal downtime to the existing database.
C is correct
is the only one that make sense.
mysql dump always causes long downtime.
Yes, totally agreed that answer is C.
C is correct - import/export strategy will need downtime hence second strategy - external replica promotion should be used that does not require any downtime.
Isn't option C adding more modifications? The ask in the question was to make minimal modifications.. Any thoughts?
With the given options I think B and D are ruled out. With A the downtime could be long. Perhaps the closest seems to be then C and it talks about replicating the data from On-Prem MySQL to Cloud SQL while the application continues to have access to On-Prem and a final cut-over to CloudSQL after replication has completed. Almost zero data-loss which is one of the requirement.
why not B?
With B you going to create downtime when MySQL dump will be applied. Whereas for B we are moving the service layer using the existing MySQL on-prem then will switch to hcp cloud SQL once that is ready. So least downtime.
C is correct for sure
hey guys new Qs posted as of July 12th, 2021, All 21 new Qs in Question #152
A is wrong, step "6. Modify the source code of the application to write queries to both databases and read from its local database." makes no sense.
C is right answer. This will support minimum downtime, no customer data lose and no code modifications. Suggested A is wrong.
vote C
Upvote
Voted for C. Official docs suggests that mysql dump requires longer downtime and replica requires only minimal downtime. https://cloud.google.com/architecture/migrating-mysql-to-cloudsql-concept#migration_methods
C is ok
A https://cloud.google.com/database-migration/docs/mysql/mysql-dump?hl=en
vote for C...migrate using a replica
I think I selected A for this in the exam but think so C
C provides least downtime. A might result in long downtime if DB is large, also needs code modification, however code reversal post cutover is not mentioned.
I will go with C to minimize downtime.
In option A, Step 2 and Step 8 mention - "Stop the on-premise application". This is a bit weird. And also the downtime can be long. Option C looks to be very clear.
Answer is C - Very low downtime. And correct sequence of steps.
C because it has minimal modification to the application or database. Also it's easier to fail back to the original solution if the cloud implementation has issues (assuming that there will be a "post-go-live" monitoring period).
C for minimal downtime
Option C is not the correct answer because it involves modifying the application to read and write to both the on-premises MySQL server and Cloud SQL, which would involve significant modification to the application and could introduce potential complications or errors. It is generally better to minimize modification to the application when performing a migration. Option D, on the other hand, involves simply importing a mysqldump of the on-premises MySQL server into Cloud SQL and starting the application on Compute Engine, which is a simpler and more straightforward approach that involves minimal modification to the application.
C seems to be the best answer but it is still a bit confusing. So basically there's a bi-directional sync between the 2 databases? Cloud instance is the primary and is writing into the on-prem and on-prem is being replicated into the Cloud.
Correct Answer A C is unnecceory expensive and loss of data at after step 3
Option A, writing to two databases form the app :( Option C all the way, it also aligns to GCP Data Migration Service.
B is the correct answ
Answer C: MySQL migration either through Export/Import or Replica Promotion. The Export/Import requires downtime rather than Replica needs a minimal downtime.
Answer is C
the question focuses on your use of replica for no downtime
* minimal downtime
C is the correct answer https://cloud.google.com/architecture/migrating-mysql-to-cloudsql-concept
A incur data loss. C is my choice.
C is the answer here guys
Go fro C
make sense
https://cloud.google.com/architecture/migrating-mysql-to-cloudsql-concept#external_replica_promotion_migration_overview
Both A and C are correct . A is short-cut way to save time but our proper path and practice is C . If we ll use C method , there is no chance of any data loss and minimum downtime require than A because through C we are setting up replication and after application test we can finalize the steps . In A where is Online transaction happening every second is not applicable .
A is wrong because:" Modify the source code of the application to write queries to both databases and read from its local database" why both database if the database onprem is stopped ?
Correct Answer is C
yes, C is the correct one
https://cloud.google.com/architecture/migrating-mysql-to-cloudsql-concept#external_replica_promotion_migration_overview
c is right
C because it has minimal modification to the application or database. Also it's easier to fail back to the original solution if the cloud implementation has issues (assuming that there will be a "post-go-live" monitoring period).
C is ok
Answer is C
I wonder how Examtopics determines the so-called "Correct Answer" ..... C is correct
Minimal downtime. Downtime in A is time to take mysql dump + fix potential failures, not good. Downtime in C is just the time from restart the service.