You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here are some best practices to help you build a cloud-ready application by using Azure Database for MySQL. These best practices can reduce development time for your app.
19
+
Here are some best practices to help you build a cloud-ready application using Azure Database for MySQL. These best practices can reduce the development time for your app.
19
20
20
21
## Configuration of application and database resources
21
22
22
23
### Keep the application and database in the same region
23
24
24
-
Make sure all your dependencies are in the same region when deploying your application in Azure. Spreading instances across regions or availability zones creates network latency, which might affect the overall performance of your application.
25
+
Ensure all your dependencies are in the same region when deploying your application in Azure. Spreading instances across regions or availability zones creates network latency, which might affect the overall performance of your application.
25
26
26
27
### Keep your MySQL server secure
27
28
@@ -35,34 +36,34 @@ For security, you must always connect to your MySQL server over SSL and configur
35
36
36
37
### Use advanced networking with AKS
37
38
38
-
When accelerated networking is enabled on a VM, there is lower latency, reduced jitter, and decreased CPU utilization on the VM. To learn more, see [Best practices for Azure Kubernetes Service and Azure Database for MySQL](concepts-aks.md)
39
+
When accelerated networking is enabled on a VM, there's lower latency, reduced jitter, and decreased CPU utilization on the VM. To learn more, see [Best practices for Azure Kubernetes Service and Azure Database for MySQL](single-server/concepts-aks.md).
39
40
40
41
### Tune your server parameters
41
42
42
-
For read-heavy workloads tuning server parameters, `tmp_table_size` and `max_heap_table_size` can help optimize for better performance. To calculate the values required for these variables, look at the total per-connection memory values and the base memory. The sum of per-connection memory parameters, excluding `tmp_table_size`, combined with the base memory accounts for total memory of the server.
43
+
For read-heavy workloads tuning server parameters, `tmp_table_size` and `max_heap_table_size` can help optimize for better performance. To calculate the values required for these variables, look at the total per-connection and base memory values. The sum of per-connection memory parameters, excluding `tmp_table_size`, combined with the base memory accounts for total memory of the server.
43
44
44
45
To calculate the largest possible size of `tmp_table_size` and `max_heap_table_size`, use the following formula:
45
46
46
47
`(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections`
47
48
48
-
> [!NOTE]
49
-
> Total memory indicates the total amount of memory that the server has across the provisioned vCores. For example, in a General Purpose two-vCore Azure Database for MySQL server, the total memory will be 5 GB * 2. You can find more details about memory for each tier in the [pricing tier](single-server/concepts-pricing-tiers.md) documentation.
50
-
>
51
-
> Base memory indicates the memory variables, like `query_cache_size` and `innodb_buffer_pool_size`, that MySQL will initialize and allocate at server start. Per-connection memory, like `sort_buffer_size` and `join_buffer_size`, is memory that's allocated only when a query needs it.
49
+
> [!NOTE]
50
+
> Total memory indicates the total amount of memory that the server has across the provisioned vCores. For example, in a General Purpose two-vCore Azure Database for MySQL server, the total memory will be 5 GB * 2. You can find more details about memory for each tier in the [pricing tier](single-server/concepts-pricing-tiers.md) documentation.
51
+
>
52
+
> Base memory indicates the memory variables, like `query_cache_size` and `innodb_buffer_pool_size`, that MySQL will initialize and allocate at the server start. Per-connection memory, like `sort_buffer_size` and `join_buffer_size`, is the memory allocated only when a query needs it.
52
53
53
-
### Create non-admin users
54
+
### Create nonadmin users
54
55
55
-
[Create non-admin users](how-to-create-users.md) for each database. Typically, the user names are identified as the database names.
56
+
[Create nonadmin users](how-to-create-users.md) for each database. Typically, the user names are identified as the database names.
56
57
57
58
### Reset your password
58
59
59
-
You can [reset your password](single-server/how-to-create-manage-server-portal.md#update-admin-password) for your MySQL server by using the Azure portal.
60
+
You can [reset your password](single-server/how-to-create-manage-server-portal.md#update-admin-password) for your MySQL server using the Azure portal.
60
61
61
62
Resetting your server password for a production database can bring down your application. It's a good practice to reset the password for any production workloads at off-peak hours to minimize the impact on your application's users.
62
63
63
64
## Performance and resiliency
64
65
65
-
Here are a few tools and practices that you can use to help debug performance issues with your application.
66
+
Here are a few tools and practices to help debug your application's performance issues.
66
67
67
68
### Enable slow query logs to identify performance issues
68
69
@@ -72,21 +73,21 @@ Audit logs are also available through Azure Diagnostics logs in Azure Monitor lo
72
73
73
74
### Use connection pooling
74
75
75
-
Managing database connections can have a significant impact on the performance of the application as a whole. To optimize performance, you must reduce the number of times that connections are established and the time for establishing connections in key code paths. Use [connection pooling](single-server/concepts-connectivity.md#access-databases-by-using-connection-pooling-recommended) to connect to Azure Database for MySQL to improve resiliency and performance.
76
+
Managing database connections can have a significant impact on the performance of the application as a whole. To optimize performance, you must reduce the number of times connections are established and the time for establishing connections in key code paths. Use [connection pooling](single-server/concepts-connectivity.md#access-databases-by-using-connection-pooling-recommended) to connect to Azure Database for MySQL to improve resiliency and performance.
76
77
77
-
You can use the [ProxySQL](https://proxysql.com/) connection pooler to efficiently manage connections. Using a connection pooler can decrease idle connections and reuse existing connections, which will help avoid problems. See [How to set up ProxySQL](https://techcommunity.microsoft.com/t5/azure-database-for-mysql/connecting-efficiently-to-azure-database-for-mysql-with-proxysql/ba-p/1279842) to learn more.
78
+
You can use the [ProxySQL](https://proxysql.com/) connection pooler to manage connections efficiently. Using a connection pooler can decrease idle connections and reuse existing connections, which helps avoid problems. See [How to set up ProxySQL](https://techcommunity.microsoft.com/t5/azure-database-for-mysql/connecting-efficiently-to-azure-database-for-mysql-with-proxysql/ba-p/1279842) to learn more.
78
79
79
80
### Retry logic to handle transient errors
80
81
81
82
Your application might experience [transient errors](single-server/concepts-connectivity.md#handling-transient-errors) where connections to the database are dropped or lost intermittently. In such situations, the server is up and running after one to two retries in 5 to 10 seconds.
82
83
83
-
A good practice is to wait for 5 seconds before your first retry. Then follow each retry by increasing the wait gradually, up to 60 seconds. Limit the maximum number of retries at which point your application considers the operation failed, so you can then further investigate. See [How to troubleshoot connection errors](single-server/how-to-troubleshoot-common-connection-issues.md) to learn more.
84
+
A good practice is to wait for 5 seconds before your first retry. Then follow each retry by increasing the wait gradually, up to 60 seconds. Limit the maximum number of retries, at which point your application considers the operation failed, so you can further investigate. See [How to troubleshoot connection errors](single-server/how-to-troubleshoot-common-connection-issues.md) to learn more.
84
85
85
86
### Enable read replication to mitigate failovers
86
87
87
-
You can use [Data-in Replication](single-server/how-to-data-in-replication.md) for failover scenarios. When you're using read replicas, no automated failover between source and replica servers occurs.
88
+
For failover scenarios, you can use [Data-in Replication](single-server/how-to-data-in-replication.md). No automated failover between source and replica servers occurs when using read replicas.
88
89
89
-
You'll notice a lag between the source and the replica because the replication is asynchronous. Network lag can be influenced by many factors, like the size of the workload running on the source server and the latency between datacenters. In most cases, replica lag ranges from a few seconds to a couple of minutes.
90
+
You notice a lag between the source and the replica because the replication is asynchronous. Network lag can be influenced by many factors, like the size of the workload running on the source server and the latency between data centers. In most cases, replica lag ranges from a few seconds to a few minutes.
90
91
91
92
## Database deployment
92
93
@@ -99,41 +100,41 @@ Occasionally, you need to deploy changes to your database. In such cases, you ca
99
100
During manual database deployment, follow these steps to minimize downtime or reduce the risk of failed deployment:
100
101
101
102
1. Create a copy of a production database on a new database by using [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) or [MySQL Workbench](https://dev.mysql.com/doc/workbench/en/wb-admin-export-import-management.html).
102
-
2. Update the new database with your new schema changes or updates needed for your database.
103
-
3. Put the production database in a read-only state. You should not have write operations on the production database until deployment is completed.
104
-
4. Test your application with the newly updated database from step 1.
105
-
5. Deploy your application changes and make sure the application is now using the new database that has the latest updates.
106
-
6. Keep the old production database so that you can roll back the changes. You can then evaluate to either delete the old production database or export it on Azure Storage if needed.
107
-
108
-
> [!NOTE]
109
-
> If the application is like an e-commerce app and you can't put it in read-only state, deploy the changes directly on the production database after making a backup. Theses change should occur during off-peak hours with low traffic to the app to minimize the impact, because some users might experience failed requests.
110
-
>
103
+
1. Update the new database with your new schema changes or updates needed for your database.
104
+
1. Put the production database in a read-only state. It would be best if you didn't have write operations on the production database until deployment is completed.
105
+
1. Test your application with the newly updated database from step 1.
106
+
1. Deploy your application changes and make sure the application is now using the new database with the latest updates.
107
+
1. Keep the old production database to roll back the changes. You can then evaluate to delete the old production database or export it on Azure Storage if needed.
108
+
109
+
> [!NOTE]
110
+
> If the application is like an e-commerce app and you can't put it in a read-only state, deploy the changes directly on the production database after making a backup. These changes should occur during off-peak hours with low traffic to the app to minimize the impact because some users might experience failed requests.
111
+
>
111
112
> Make sure your application code also handles any failed requests.
112
113
113
114
### Use MySQL native metrics to see if your workload is exceeding in-memory temporary table sizes
114
115
115
-
With a read-heavy workload, queries running against your MySQL server might exceed the in-memory temporary table sizes. A read-heavy workload can cause your server to switch to writing temporary tables to disk, which affects the performance of your application. To determine if your server is writing to disk as a result of exceeding temporary table size, look at the following metrics:
116
+
With a read-heavy workload, queries against your MySQL server might exceed the in-memory temporary table sizes. A read-heavy workload can cause your server to switch to writing temporary tables to disk, affecting your application's performance. To determine if your server is writing to disk as a result of exceeding temporary table size, look at the following metrics:
116
117
117
118
```sql
118
119
show global status like'created_tmp_disk_tables';
119
120
show global status like'created_tmp_tables';
120
121
```
121
122
122
-
The `created_tmp_disk_tables` metric indicates how many tables were created on disk. The `created_tmp_table` metric tells you how many temporary tables have to be formed in memory, given your workload. To determine if running a specific query will use temporary tables, run the [EXPLAIN](https://dev.mysql.com/doc/refman/8.0/en/explain.html) statement on the query. The detail in the `extra` column indicates `Using temporary` if the query will run using temporary tables.
123
+
The `created_tmp_disk_tables` metric indicates how many tables were created on disk. Given your workload, the `created_tmp_table` metric tells you how many temporary tables must be formed in memory. To determine if a specific query uses temporary tables, run the [EXPLAIN](https://dev.mysql.com/doc/refman/8.0/en/explain.html) statement on the query. The detail in the `extra` column indicates `Using temporary` if the query runs using temporary tables.
123
124
124
125
To calculate the percentage of your workload with queries spilling to disks, use your metric values in the following formula:
Ideally, this percentage should be less 25%. If you see that the percentage is 25% or greater, we suggest modifying two server parameters, tmp_table_size and max_heap_table_size.
129
+
Ideally, this percentage should be less than 25%. If the percentage is 25% or greater, we suggest modifying two server parameters, tmp_table_size, and max_heap_table_size.
129
130
130
131
## Database schema and queries
131
132
132
-
Here are few tips to keep in mind when you build your database schema and your queries.
133
+
Here are a few tips to remember when building your database schema and queries.
133
134
134
-
### Use the right datatype for your table columns
135
+
### Use the correct datatype for your table columns
135
136
136
-
Using the right datatype based on the type of data you want to store can optimize storage and reduce errors that can occur because of incorrect datatypes.
137
+
Using the correct datatype based on the type of data you want to store can optimize storage and reduce errors due to incorrect datatypes.
0 commit comments