Workload Manager best practices for MySQL
This document lists the best practices that Workload Manager supports forevaluating MySQL workloads running on Google Cloud. To learn aboutWorkload Manager, seeProduct overview.
Severity levels
When you run an evaluation, Workload Manager evaluates resources by comparing theircurrent state with best practices. If a resource doesn't comply with a selected best practice,Workload Manager assigns it a severity level that indicates how far the resourceis out of compliance. The Google Cloud console marks each non-compliant resource with an icon.The following table explains these icons, their corresponding severity levels, how the currentresource setting might impact your workload, and recommendations for modifying the resource to adhereto best practices.| Icon | Severity level | Impacts | Recommendation |
|---|---|---|---|
 | Critical | System Reliability, Unplanned Outages, Unsupported Configuration | Resolve as soon as possible to prevent an impact on system availability and data integrity due to a high risk of an unplanned outage. |
 | High | Degraded Performance, System Stability | Resolve during the next planned maintenance window. |
 | Medium | Suboptimal Performance, Supportability | Resolve at your earliest convenience. |
 | Low | Informational, Non-essential Behavior | Although there's no resolution needed, reviewing this best practice can provide useful insights. |
Best practices for MySQL workloads
The following table shows the Workload Manager best practices forevaluating MySQL workloads that run on Google Cloud.
Note that to enable Workload Manager for evaluating your MySQL workloads,you mustset up Google Cloud's Agent for Compute Workloads on the host VMs.
Select one or more rule categories to filter the following table.
| Category | Best practice name and description | Severity | Last updated |
|---|---|---|---|
| MySQL General | Check that the Google Cloud Agent for Compute Workloads is set up correctly on all instances in the evaluation scope Instances in the evaluation scope must have the Google Cloud Agent for Compute Workloads configured to run Workload Manager evaluations. If you have not configured the agent correctly, evaluation results can be incomplete or inaccurate. The minimum recommended version is 1.2. | Critical | August 27, 2025 |
| MySQL General | Enable automatic restart for VMs running MySQL workloads To ensure that the VM restarts automatically in the event of a failure, enable the Compute Engine automatic restart policy for any VM that is running a MySQL workload. | Critical | August 27, 2025 |
| MySQL General | Provision Hyperdisk with minimum IOPS and throughput The default provisioned IOPS and throughput values for small Hyperdisks can be too low to guarantee proper performance. We recommend that you raise these values to a minimum of 10,000 IOPS and 1 GiB/s throughput. From November 10th 2025, the severity of this evaluation rule has been updated from Medium to High. This change also applies to existing evaluations that include this rule. For more information, seeDefault performance. | High | November 10, 2025 |
| MySQL General | Set VM maintenance policy to MIGRATE for MySQL workloads To prevent any platform maintenance events from stopping or restarting a VM that is running MySQL workloads, the onHostMaintenance parameter for the VM must be set to the recommended option MIGRATE. For more information, seeSet VM host maintenance policy. | Critical | August 27, 2025 |
| MySQL General | Do not run MySQL workloads on PD Standard or Hyperdisk Throughput disk types Google Cloud recommends that you do not run MySQL workloads on PD Standard and Hyperdisk Throughput disk types, because these are hard disk-based disks and might lead to degraded performance. From November 10th 2025, the severity of this evaluation rule has been updated from Medium to High. This change also applies to existing evaluations that include this rule. For more information, seePersistent disk types,Hyperdisks, andHyperdisk Throughput. | High | November 10, 2025 |
| MySQL General | Ensure replication is sent to a machine in a different zone or region To maintain proper high availability, we strongly recommend that you send your replication to a machine in a different zone or region from the primary location. From November 10th 2025, the severity of this evaluation rule has been updated from Medium to High. This change also applies to existing evaluations that include this rule. For more information, seeWell-Architected Framework: Reliability pillar. | High | November 10, 2025 |
| MySQL General | Ensure innodb_buffer_pool_size occupies a majority of the memory for the machine For optimized performance, Google Cloud recommends allocating the innodb_buffer_pool_size parameter a 50% or greater share of the machine's memory. This ensures that the buffer pool has enough memory to store data and improve performance. This guideline doesn't apply to smaller VMs with less than 4 GB of total memory where such an allocation might not be possible. From November 10th 2025, the severity of this evaluation rule has been updated from Medium to High. This change also applies to existing evaluations that include this rule. | High | November 10, 2025 |
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-12-17 UTC.