Skip to content

Commit a3f7925

Browse files
v-regandownerv-regandowner
authored
Merge pull request #234941 from markingmyname/change
[MySQL] Change authors and format changes (Bulk edit)
2 parents 8b69e26 + 315bff8 commit a3f7925

12 files changed

+219
-198
lines changed

‎articles/mariadb/concepts-data-in-replication.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,8 +2,8 @@
22
title: Data-in replication - Azure Database for MariaDB
33
description: Learn about using data-in replication to synchronize from an external server into the Azure Database for MariaDB service.
44
ms.service: mariadb
5-
author: savjani
6-
ms.author: pariks
5+
author: VandhanaMehta
6+
ms.author: vamehta
77
ms.topic: conceptual
88
ms.date: 06/24/2022
99
---

‎articles/mariadb/concepts-query-store.md

Lines changed: 60 additions & 58 deletions
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,14 @@
11
---
22
title: Query Store - Azure Database for MariaDB
3-
description: Learn about the Query Store feature in Azure Database for MariaDB to help you track performance over time.
3+
description: Learn about the Query Store feature in Azure Database for MariaDB to help you track performance over time.
4+
author: code-sidd
5+
ms.author: sisawant
6+
ms.reviewer: maghan
7+
ms.date: 04/18/2023
48
ms.service: mariadb
5-
author: savjani
6-
ms.author: pariks
79
ms.topic: conceptual
8-
ms.date: 06/24/2022
910
---
11+
1012
# Monitor Azure Database for MariaDB performance with Query Store
1113

1214
**Applies to:** Azure Database for MariaDB 10.2
@@ -21,21 +23,21 @@ Query store can be used in many scenarios, including the following:
2123
- Determining the number of times a query was executed in a given time window
2224
- Comparing the average execution time of a query across time windows to see large deltas
2325

24-
## Enabling Query Store
26+
## Enable Query Store
2527

2628
Query Store is an opt-in feature, so it isn't active by default on a server. The query store is enabled or disabled globally for all the databases on a given server and cannot be turned on or off per database.
2729

2830
### Enable Query Store using the Azure portal
2931

3032
1. Sign in to the Azure portal and select your Azure Database for MariaDB server.
31-
2. Select **Server Parameters** in the **Settings** section of the menu.
32-
3. Search for the query_store_capture_mode parameter.
33-
4. Set the value to ALL and **Save**.
33+
1. Select **Server Parameters** in the **Settings** section of the menu.
34+
1. Search for the query_store_capture_mode parameter.
35+
1. Set the value to ALL and **Save**.
3436

3537
To enable wait statistics in your Query Store:
3638

3739
1. Search for the query_store_wait_sampling_capture_mode parameter.
38-
2. Set the value to ALL and **Save**.
40+
1. Set the value to ALL and **Save**.
3941

4042
Allow up to 20 minutes for the first batch of data to persist in the mysql database.
4143

@@ -60,20 +62,20 @@ Or this query for wait statistics:
6062
SELECT * FROM mysql.query_store_wait_stats;
6163
```
6264

63-
## Finding wait queries
65+
## Find wait queries
6466

65-
> [!NOTE]
67+
> [!NOTE]
6668
> Wait statistics should not be enabled during peak workload hours or be turned on indefinitely for sensitive workloads. <br>For workloads running with high CPU utilization or on servers configured with lower vCores, use caution when enabling wait statistics. It should not be turned on indefinitely.
6769
6870
Wait event types combine different wait events into buckets by similarity. Query Store provides the wait event type, specific wait event name, and the query in question. Being able to correlate this wait information with the query runtime statistics means you can gain a deeper understanding of what contributes to query performance characteristics.
6971

7072
Here are some examples of how you can gain more insights into your workload using the wait statistics in Query Store:
7173

7274
| **Observation** | **Action** |
73-
|---|---|
74-
|High Lock waits | Check the query texts for the affected queries and identify the target entities. Look in Query Store for other queries modifying the same entity, which is executed frequently and/or have high duration. After identifying these queries, consider changing the application logic to improve concurrency, or use a less restrictive isolation level. |
75-
|High Buffer IO waits | Find the queries with a high number of physical reads in Query Store. If they match the queries with high IO waits, consider introducing an index on the underlying entity, to do seeks instead of scans. This would minimize the IO overhead of the queries. Check the **Performance Recommendations** for your server in the portal to see if there are index recommendations for this server that would optimize the queries. |
76-
|High Memory waits | Find the top memory consuming queries in Query Store. These queries are probably delaying further progress of the affected queries. Check the **Performance Recommendations** for your server in the portal to see if there are index recommendations that would optimize these queries.|
75+
| --- | --- |
76+
| High Lock waits | Check the query texts for the affected queries and identify the target entities. Look in Query Store for other queries modifying the same entity, which is executed frequently and/or have high duration. After identifying these queries, consider changing the application logic to improve concurrency, or use a less restrictive isolation level. |
77+
| High Buffer IO waits | Find the queries with a high number of physical reads in Query Store. If they match the queries with high IO waits, consider introducing an index on the underlying entity, to do seeks instead of scans. This would minimize the IO overhead of the queries. Check the **Performance Recommendations** for your server in the portal to see if there are index recommendations for this server that would optimize the queries. |
78+
| High Memory waits | Find the top memory consuming queries in Query Store. These queries are probably delaying further progress of the affected queries. Check the **Performance Recommendations** for your server in the portal to see if there are index recommendations that would optimize these queries. |
7779

7880
## Configuration options
7981

@@ -82,7 +84,7 @@ When Query Store is enabled it saves data in 15-minute aggregation windows, up t
8284
The following options are available for configuring Query Store parameters.
8385

8486
| **Parameter** | **Description** | **Default** | **Range** |
85-
|---|---|---|---|
87+
| --- | --- | --- | --- |
8688
| query_store_capture_mode | Turn the query store feature ON/OFF based on the value. Note: If performance_schema is OFF, turning on query_store_capture_mode will turn on performance_schema and a subset of performance schema instruments required for this feature. | ALL | NONE, ALL |
8789
| query_store_capture_interval | The query store capture interval in minutes. Allows specifying the interval in which the query metrics are aggregated | 15 | 5 - 60 |
8890
| query_store_capture_utility_queries | Turning ON or OFF to capture all the utility queries that is executing in the system. | NO | YES, NO |
@@ -91,11 +93,11 @@ The following options are available for configuring Query Store parameters.
9193
The following options apply specifically to wait statistics.
9294

9395
| **Parameter** | **Description** | **Default** | **Range** |
94-
|---|---|---|---|
96+
| --- | --- | --- | --- |
9597
| query_store_wait_sampling_capture_mode | Allows turning ON / OFF the wait statistics. | NONE | NONE, ALL |
9698
| query_store_wait_sampling_frequency | Alters frequency of wait-sampling in seconds. 5 to 300 seconds. | 30 | 5-300 |
9799

98-
> [!NOTE]
100+
> [!NOTE]
99101
> Currently **query_store_capture_mode** supersedes this configuration, meaning both **query_store_capture_mode** and **query_store_wait_sampling_capture_mode** have to be enabled to ALL for wait statistics to work. If **query_store_capture_mode** is turned off, then wait statistics is turned off as well since wait statistics utilizes the performance_schema enabled, and the query_text captured by query store.
100102
101103
Use the [Azure portal](howto-server-parameters.md) to get or set a different value for a parameter.
@@ -111,54 +113,54 @@ Queries are normalized by looking at their structure after removing literals and
111113
This view returns all the data in Query Store. There is one row for each distinct database ID, user ID, and query ID.
112114

113115
| **Name** | **Data Type** | **IS_NULLABLE** | **Description** |
114-
|---|---|---|---|
115-
| `schema_name`| varchar(64) | NO | Name of the schema |
116-
| `query_id`| bigint(20) | NO| Unique ID generated for the specific query, if the same query executes in different schema, a new ID will be generated |
117-
| `timestamp_id` | timestamp| NO| Timestamp in which the query is executed. This is based on the query_store_interval configuration|
118-
| `query_digest_text`| longtext| NO| The normalized query text after removing all the literals|
119-
| `query_sample_text` | longtext| NO| First appearance of the actual query with literals|
120-
| `query_digest_truncated` | bit| YES| Whether the query text has been truncated. Value will be Yes if the query is longer than 1 KB|
121-
| `execution_count` | bigint(20)| NO| The number of times the query got executed for this timestamp ID / during the configured interval period|
122-
| `warning_count` | bigint(20)| NO| Number of warnings this query generated during the internal|
123-
| `error_count` | bigint(20)| NO| Number of errors this query generated during the interval|
124-
| `sum_timer_wait` | double| YES| Total execution time of this query during the interval|
125-
| `avg_timer_wait` | double| YES| Average execution time for this query during the interval|
126-
| `min_timer_wait` | double| YES| Minimum execution time for this query|
127-
| `max_timer_wait` | double| YES| Maximum execution time|
128-
| `sum_lock_time` | bigint(20)| NO| Total amount of time spent for all the locks for this query execution during this time window|
129-
| `sum_rows_affected` | bigint(20)| NO| Number of rows affected|
130-
| `sum_rows_sent` | bigint(20)| NO| Number of rows sent to client|
131-
| `sum_rows_examined` | bigint(20)| NO| Number of rows examined|
132-
| `sum_select_full_join` | bigint(20)| NO| Number of full joins|
133-
| `sum_select_scan` | bigint(20)| NO| Number of select scans |
134-
| `sum_sort_rows` | bigint(20)| NO| Number of rows sorted|
135-
| `sum_no_index_used` | bigint(20)| NO| Number of times when the query didn't use any indexes|
136-
| `sum_no_good_index_used` | bigint(20)| NO| Number of times when the query execution engine didn't use any good indexes|
137-
| `sum_created_tmp_tables` | bigint(20)| NO| Total number of temp tables created|
138-
| `sum_created_tmp_disk_tables` | bigint(20)| NO| Total number of temp tables created in disk (generates I/O)|
139-
| `first_seen` | timestamp| NO| The first occurrence (UTC) of the query during the aggregation window|
140-
| `last_seen` | timestamp| NO| The last occurrence (UTC) of the query during this aggregation window|
116+
| --- | --- | --- | --- |
117+
| `schema_name` | varchar(64) | NO | Name of the schema |
118+
| `query_id` | bigint(20) | NO | Unique ID generated for the specific query, if the same query executes in different schema, a new ID will be generated |
119+
| `timestamp_id` | timestamp | NO | Timestamp in which the query is executed. This is based on the query_store_interval configuration |
120+
| `query_digest_text` | longtext | NO | The normalized query text after removing all the literals |
121+
| `query_sample_text` | longtext | NO | First appearance of the actual query with literals |
122+
| `query_digest_truncated` | bit | YES | Whether the query text has been truncated. Value will be Yes if the query is longer than 1 KB |
123+
| `execution_count` | bigint(20) | NO | The number of times the query got executed for this timestamp ID / during the configured interval period |
124+
| `warning_count` | bigint(20) | NO | Number of warnings this query generated during the internal |
125+
| `error_count` | bigint(20) | NO | Number of errors this query generated during the interval |
126+
| `sum_timer_wait` | double | YES | Total execution time of this query during the interval |
127+
| `avg_timer_wait` | double | YES | Average execution time for this query during the interval |
128+
| `min_timer_wait` | double | YES | Minimum execution time for this query |
129+
| `max_timer_wait` | double | YES | Maximum execution time |
130+
| `sum_lock_time` | bigint(20) | NO | Total amount of time spent for all the locks for this query execution during this time window |
131+
| `sum_rows_affected` | bigint(20) | NO | Number of rows affected |
132+
| `sum_rows_sent` | bigint(20) | NO | Number of rows sent to client |
133+
| `sum_rows_examined` | bigint(20) | NO | Number of rows examined |
134+
| `sum_select_full_join` | bigint(20) | NO | Number of full joins |
135+
| `sum_select_scan` | bigint(20) | NO | Number of select scans |
136+
| `sum_sort_rows` | bigint(20) | NO | Number of rows sorted |
137+
| `sum_no_index_used` | bigint(20) | NO | Number of times when the query didn't use any indexes |
138+
| `sum_no_good_index_used` | bigint(20) | NO | Number of times when the query execution engine didn't use any good indexes |
139+
| `sum_created_tmp_tables` | bigint(20) | NO | Total number of temp tables created |
140+
| `sum_created_tmp_disk_tables` | bigint(20) | NO | Total number of temp tables created in disk (generates I/O) |
141+
| `first_seen` | timestamp | NO | The first occurrence (UTC) of the query during the aggregation window |
142+
| `last_seen` | timestamp | NO | The last occurrence (UTC) of the query during this aggregation window |
141143

142144
### mysql.query_store_wait_stats
143145

144146
This view returns wait events data in Query Store. There's one row for each distinct database ID, user ID, query ID, and event.
145147

146-
| **Name**| **Data Type** | **IS_NULLABLE** | **Description** |
147-
|---|---|---|---|
148-
| `interval_start` | timestamp | NO| Start of the interval (15-minute increment)|
149-
| `interval_end` | timestamp | NO| End of the interval (15-minute increment)|
150-
| `query_id` | bigint(20) | NO| Generated unique ID on the normalized query (from query store)|
151-
| `query_digest_id` | varchar(32) | NO| The normalized query text after removing all the literals (from query store) |
152-
| `query_digest_text` | longtext | NO| First appearance of the actual query with literals (from query store) |
153-
| `event_type` | varchar(32) | NO| Category of the wait event |
154-
| `event_name` | varchar(128) | NO| Name of the wait event |
155-
| `count_star` | bigint(20) | NO| Number of wait events sampled during the interval for the query |
156-
| `sum_timer_wait_ms` | double | NO| Total wait time (in milliseconds) of this query during the interval |
148+
| **Name** | **Data Type** | **IS_NULLABLE** | **Description** |
149+
| --- | --- | --- | --- |
150+
| `interval_start` | timestamp | NO | Start of the interval (15-minute increment) |
151+
| `interval_end` | timestamp | NO | End of the interval (15-minute increment) |
152+
| `query_id` | bigint(20) | NO | Generated unique ID on the normalized query (from query store) |
153+
| `query_digest_id` | varchar(32) | NO | The normalized query text after removing all the literals (from query store) |
154+
| `query_digest_text` | longtext | NO | First appearance of the actual query with literals (from query store) |
155+
| `event_type` | varchar(32) | NO | Category of the wait event |
156+
| `event_name` | varchar(128) | NO | Name of the wait event |
157+
| `count_star` | bigint(20) | NO | Number of wait events sampled during the interval for the query |
158+
| `sum_timer_wait_ms` | double | NO | Total wait time (in milliseconds) of this query during the interval |
157159

158160
### Functions
159161

160-
| **Name**| **Description** |
161-
|---|---|
162+
| **Name** | **Description** |
163+
| --- | --- |
162164
| `mysql.az_purge_querystore_data(TIMESTAMP)` | Purges all query store data before the given time stamp |
163165
| `mysql.az_procedure_purge_querystore_event(TIMESTAMP)` | Purges all wait event data before the given time stamp |
164166
| `mysql.az_procedure_purge_recommendation(TIMESTAMP)` | Purges recommendations whose expiration is before the given time stamp |

‎articles/mariadb/concepts-ssl-connection-security.md

Lines changed: 18 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,22 @@
11
---
22
title: SSL/TLS connectivity - Azure Database for MariaDB
33
description: Information for configuring Azure Database for MariaDB and associated applications to properly use SSL connections
4+
author: shreyaaithal
5+
ms.author: shaithal
6+
ms.reviewer: maghan
7+
ms.date: 04/18/2023
48
ms.service: mariadb
5-
author: savjani
6-
ms.author: pariks
79
ms.topic: conceptual
8-
ms.date: 06/24/2022
910
---
1011

1112
# SSL/TLS connectivity in Azure Database for MariaDB
1213

1314
Azure Database for MariaDB supports connecting your database server to client applications using Secure Sockets Layer (SSL). Enforcing SSL connections between your database server and your client applications helps protect against "man in the middle" attacks by encrypting the data stream between the server and your application.
1415

15-
>[!NOTE]
16+
> [!NOTE]
1617
> Based on the feedback from customers we have extended the root certificate deprecation for our existing Baltimore Root CA till February 15, 2021 (02/15/2021).
1718
18-
> [!IMPORTANT]
19+
> [!IMPORTANT]
1920
> SSL root certificate is set to expire starting February 15, 2021 (02/15/2021). Please update your application to use the [new certificate](https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem). To learn more , see [planned certificate updates](concepts-certificate-rotation.md)
2021
2122
## Default settings
@@ -40,18 +41,18 @@ Azure Database for MariaDB supports encryption for clients connecting to your da
4041

4142
Azure Database for MariaDB provides the ability to enforce the TLS version for the client connections. To enforce the TLS version, use the **Minimum TLS version** option setting. The following values are allowed for this option setting:
4243

43-
| Minimum TLS setting | Client TLS version supported |
44-
|:---------------------------------|-------------------------------------:|
45-
| TLSEnforcementDisabled (default) | No TLS required |
46-
| TLS1_0 | TLS 1.0, TLS 1.1, TLS 1.2 and higher |
47-
| TLS1_1 | TLS 1.1, TLS 1.2 and higher |
48-
| TLS1_2 | TLS version 1.2 and higher |
44+
| Minimum TLS setting | Client TLS version supported |
45+
| :--- | ---: |
46+
| TLSEnforcementDisabled (default) | No TLS required |
47+
| TLS1_0 | TLS 1.0, TLS 1.1, TLS 1.2 and higher |
48+
| TLS1_1 | TLS 1.1, TLS 1.2 and higher |
49+
| TLS1_2 | TLS version 1.2 and higher |
4950

5051
For example, setting the value of Minimum TLS setting version to TLS 1.0 means your server will allow connections from clients using TLS 1.0, 1.1, and 1.2+. Alternatively, setting this to 1.2 means that you only allow connections from clients using TLS 1.2+ and all connections with TLS 1.0 and TLS 1.1 will be rejected.
5152

52-
> [!Note]
53+
> [!NOTE]
5354
> By default, Azure Database for MariaDB does not enforce a minimum TLS version (the setting `TLSEnforcementDisabled`).
54-
>
55+
>
5556
> Once you enforce a minimum TLS version, you cannot later disable minimum version enforcement.
5657
5758
To learn how to set the TLS setting for your Azure Database for MariaDB, refer to [How to configure TLS setting](howto-tls-configurations.md).
@@ -62,10 +63,10 @@ As part of the SSL/TLS communication, the cipher suites are validated and only s
6263

6364
### Cipher suite supported
6465

65-
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
66-
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
67-
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
68-
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
66+
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
67+
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
68+
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
69+
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
6970

7071
## Next steps
7172

0 commit comments

Comments
 (0)