0

For our db maintenance strategy we need to stop a running db before taking a copy of the vm running the db. Since the db is in production, we need to ensure the minimal amount of time for which the db is stopped, but also we want to be sure that the image/procedure is in a state in which we can restart the db without incurring in i/o issue on the image.

in pseudocode:

stop_db gcloud compute machine-images create ${IMAGE_NAME} --source-instance=... restart_db

Is there any difference using disk snapshot instead?

stop_db gcloud compute disks snapshot ${DISK} --snapshot-names=${SNAPSHOT_NAME} --async restart_db

How can we be sure that is safe to restart the db? is there a way to know that the "machine-images create" or "compute disks snapshot" api has "finished" the sync part?

The test we did so far are: test 1 with gcloud compute machine-images create: we check until "state is CREATING" and then restart the db

test 2 with gcloud compute disks snapshot: we check until "state is CREATING" and then restart the db

In both cases the time needed is more than 10 seconds, which is too high for our usecase. The time does not change if the disks are very similar in term of data stored (without delta between them)

nicon8
  • 1
  • 1
  • Have your considered using managed databases that support native snapshots? For disk snapshots, the key is to wait for the `freeze` to complete. AFAIK that is the equivalent of `creating`. Until that point do not restart the virtual machine. The freeze is very fast but there is management overhead scheduling the freeze. I am not aware of anything you can do to decrease that time. – John Hanley May 12 '23 at 07:32
  • Thank you for your answer. Unfortunately to change the db is not an option. Many services are based on this db, and there is no managed database for this tech. – nicon8 May 12 '23 at 07:58
  • Your database supports native snapshots. Why are you not using the built-in features? – John Hanley May 12 '23 at 08:07

0 Answers0