Welcome to ExamTopics
ExamTopics Logo
- Expert Verified, Online, Free.

Unlimited Access

Get Unlimited Contributor Access to the all ExamTopics Exams!
Take advantage of PDF Files for 1000+ Exams along with community discussions and pass IT Certification Exams Easily.

Exam Professional Cloud Architect topic 1 question 163 discussion

Actual exam question from Google's Professional Cloud Architect
Question #: 163
Topic #: 1
[All Professional Cloud Architect Questions]

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?

  • A. Configure a cron job to use the gcloud tool to take regular backups using persistent disk snapshots.
  • B. Mount a Local SSD volume as the backup location. After the backup is complete, use gsutil to move the backup to Google Cloud Storage.
  • C. Use gcsfise to mount a Google Cloud Storage bucket as a volume directly on the instance and write backups to the mounted location using mysqldump.
  • D. Mount additional persistent disk volumes onto each virtual machine (VM) instance in a RAID10 array and use LVM to create snapshots to send to Cloud Storage
Show Suggested Answer Hide Answer
Suggested Answer: B ūüó≥ÔłŹ

Comments

Chosen Answer:
This is a voting comment (?) , you can switch to a simple comment.
Switch to a voting comment New
hannibal1969
Highly Voted 4 years, 7 months ago
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.
upvoted 52 times
heelhook_ambassador
2 years, 7 months ago
Thanks!
upvoted 1 times
...
kvenkatasudhakar
2 years, 7 months ago
We cannot attach and mount a local SSD to a running instance. I think it's C (GCFUSE)
upvoted 3 times
...
raf2121
2 years, 10 months ago
Point for Discussion Can local SSD be mounted in a running instance.
upvoted 4 times
JasonL_GCP
2 years, 9 months ago
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
upvoted 2 times
...
pr2web
2 years, 10 months ago
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
upvoted 2 times
nymets
2 years, 6 months ago
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
upvoted 3 times
...
...
SerGCP
1 year, 9 months ago
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.
upvoted 2 times
...
...
...
Rathish
Highly Voted 4 years, 4 months ago
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.
upvoted 15 times
...
46f094c
Most Recent 1 month ago
Selected Answer: A
"A" is the only one which gives an automated way to do it. All the rest involves a person action
upvoted 1 times
...
Saikatms
6 months ago
I'll go with B
upvoted 2 times
...
Santhoshsunkari
6 months, 1 week ago
B,https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up
upvoted 2 times
...
bandegg
6 months, 1 week ago
Selected Answer: C
It says a specific database, not all of it. Otherwise, why not just use the snapshots? They are no cost.
upvoted 1 times
...
Tamim321
7 months ago
Selected Answer: C
You can only add local ssd to a VM during creation.Hence going with option C
upvoted 1 times
Tamim321
7 months ago
Refer to link - https://cloud.google.com/compute/docs/disks/local-ssd#:~:text=You%20can%20only%20add%20Local,the%20types%20that%20do%20not.
upvoted 1 times
...
...
JC0926
1 year, 4 months ago
Selected Answer: B
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.
upvoted 2 times
Murtuza
9 months, 3 weeks ago
Local SSD are considered ephermeral and they are the most cost-effective and they are fast
upvoted 1 times
...
...
NodummyIQ
1 year, 6 months ago
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.
upvoted 1 times
RVivek
1 year, 5 months ago
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"
upvoted 1 times
...
...
omermahgoub
1 year, 6 months ago
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.
upvoted 3 times
omermahgoub
1 year, 6 months ago
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.
upvoted 1 times
...
...
minmin2020
1 year, 8 months ago
Selected Answer: C
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.
upvoted 1 times
...
AzureDP900
1 year, 9 months ago
I will go with B
upvoted 3 times
...
zellck
1 year, 10 months ago
Selected Answer: B
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.
upvoted 10 times
ashrafh
1 year, 8 months ago
best answer thank you
upvoted 1 times
...
...
Pradeepkumar
1 year, 11 months ago
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
upvoted 4 times
...
xman3
2 years ago
Selected Answer: C
>backups of a specific database
upvoted 2 times
...
Ric350
2 years ago
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!
upvoted 5 times
n_nana
1 year, 6 months ago
This clear confusion, Thank you.
upvoted 1 times
...
Ric350
2 years ago
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
upvoted 3 times
...
...
Nirca
2 years ago
Selected Answer: 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.
upvoted 1 times
...
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.

Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.

SaveCancel
Loading ...
ex Want to SAVE BIG on Certification Exam Prep?
close
ex Unlock All Exams with ExamTopics Pro 75% Off
  • arrow Choose From 1000+ Exams
  • arrow Access to 10 Exams per Month
  • arrow PDF Format Available
  • arrow Inline Discussions
  • arrow No Captcha/Robot Checks
Limited Time Offer
Ends in