Your company runs several databases on a single MySQL instance. They need to take backups of a specific database at regular intervals. The backup activity needs to complete as quickly as possible and cannot be allowed to impact disk performance.
How should you configure the storage?
Mounting a Local SSD volume as the backup location will ensure high performance and minimal impact on disk performance due to the high IOPS and low latency characteristics of Local SSDs. This allows the backup process to complete quickly. Following the backup, the use of gsutil to transfer the backup to Google Cloud Storage provides a durable and reliable storage solution, ensuring the backups are secure and persist through potential instance failures.
I think it's B. If you use a tool like GCFUSE it will write immediatly to GCS which is a cost benefit because you don't need intermediate storage. In this case however "Quickly as possible" key for understanding. GCFUSE will write to GCS which is much slower than writing directly to an added SSD. During the write to GCS it would also execute reads for a longer period on the production database. Therefor writing to the extra SSD would be my recommended solution. Offloading from the SSD to GCS would not impact the running database because the data is already separated.
Point for Discussion Can local SSD be mounted in a running instance.
Yes they can. That's precisely why it makes Local SSD a good scratch / temp storage with very high IOPS. https://cloud.google.com/compute/docs/disks/local-ssd#formatandmount
No, you cannot attach a local SSD after the instance is created. "Because Local SSDs are located on the physical machine where your virtual machine instance is running, they can be created only during the instance creation process." The above is from https://cloud.google.com/compute/docs/disks/local-ssd#formatandmount
Good point, Because Local SSDs are located on the physical machine where your virtual machine instance is running, they can be created only during the instance creation process
The local SSD can be created only during the VM creation process. After than you can mount disk for in the destination path for export mysqldump. gsutil is the supported tool that you may used to migrate the dump to bucket.
Thanks!
We cannot attach and mount a local SSD to a running instance. I think it's C (GCFUSE)
Ans: B Persistent Disk snapshot not required: "They need to take backups of a specific database at regular intervals." "The backup activity needs to complete as quickly as possible and cannot be allowed to impact disk performance." This can be achieved by using both Local SSD & GCS Fuse (mounting GCS as directory), but as the question stats needs to complete as quickly as possible. General Rule: Any addition of components introduce a latency. I could not get write throughput of GCS & Local SSD, even if we consider both provides same throughput, streaming data through network to GCS Bucket introduce latency. Attached Local SSD has advantage in this case, since there is no network involved. From Local SSD to GCS bucket - copy job does not impact the mysql data disk.
B is the answer. https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket.
best answer thank you
B - I think this will clear things up. Local SSD is ATTACHED when CREATING the VM. The local SSDs are just LOCATED (on the physical host) where the VM is running. See here. https://cloud.google.com/compute/docs/disks/add-local-ssd#create_local_ssd You can have a VM with locally attached SSD in an unformatted and unmounted state or just not mounted! Maybe it was umounted and now needs to be re-mounted? Answer B says to MOUNT the local SSD. MOUNTING the SSD is done when the VM is RUNNING! We need to assume the VM was built with locally attached SSD but not formatted and mounted yet. See here. https://cloud.google.com/compute/docs/disks/add-local-ssd#format_and_mount_a_local_ssd_device!
Also, When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket. See here under "formatting secondary disks, backing up." https://cloud.google.com/compute/docs/instances/sql-server/best-practices#formatting_secondary_disks
This clear confusion, Thank you.
https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket. Though it is mentioned for SQL Server, the best practices are common for most of the databases. Also it is assumed that the Local SSD are already mounted while creating the VM
I will go with B
Option B is the most appropriate solution in this case. Mounting a Local SSD volume as the backup location will allow the backups to be taken quickly and efficiently, as Local SSDs have very high I/O performance and low latencies. Additionally, using gsutil to move the backups to Google Cloud Storage after they have been taken will provide a secure and durable storage location for the backups. A, configuring a cron job to use the gcloud tool to take regular backups using persistent disk snapshots, may not be the most efficient option because persistent disks have relatively lower I/O performance compared to Local SSDs. C, using gcsfuse to mount a Google Cloud Storage bucket as a volume directly on the instance and writing the backups to the mounted location using mysqldump, may not be the most efficient option because the backups would need to be transferred over the network, which could impact the performance of the backups.
D, mounting additional persistent disk volumes onto each VM instance in a RAID10 array and using LVM to create snapshots to send to Cloud Storage, may not be the most efficient option because it would require additional disk space and setup, and LVM snapshots may not be as fast as Local SSDs for taking backups.
>backups of a specific database
Option B would be the best choice for this scenario. Mounting a Local SSD volume as the backup location would ensure high performance and minimal impact on disk performance, while also allowing for quick backups. After the backup is complete, using gsutil to move the backup to Google Cloud Storage would provide a reliable and secure storage location for the backups. This approach is also cost-effective, as Local SSD volumes are less expensive than persistent disks.
Local SSD are considered ephermeral and they are the most cost-effective and they are fast
B,https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up
I'll go with B
It is B. Writing to Local SSD and the fasted method. (Expansive too) Coping from SSD to GCS is slow, yet not affecting the database.
Gcsfuse needs local storage for caching, usually local/non-persistent disks are used for this purpose. With gcsfuse you can have the backend storage mounted as a filesystem on the server. Mysqldump allows for hot database backups. Option C provides the automated solution needed to backup and store the database. Option B is the manual version where you need to mount the local SSD, run the backup and then transfer it to a bucket manually.
B is incorrect. The Local SSD volumes are only available on certain instance types, and they are not suitable for long-term storage as they are ephemeral and are deleted when the instance is deleted or stopped. For long-term storage, it is recommended to use persistent disks or Google Cloud Storage.
I guess umissed the second paryt of the answer B whic says "After the backup is complete, use gsutil to move the backup to Google Cloud Storage"
You can only add local ssd to a VM during creation.Hence going with option C
Refer to link - https://cloud.google.com/compute/docs/disks/local-ssd#:~:text=You%20can%20only%20add%20Local,the%20types%20that%20do%20not.
It says a specific database, not all of it. Otherwise, why not just use the snapshots? They are no cost.
"A" is the only one which gives an automated way to do it. All the rest involves a person action