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
Copy file name to clipboardExpand all lines: articles/aks/configure-azure-cni-static-block-allocation.md
+10-6Lines changed: 10 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,9 +76,9 @@ where N is any positive integer greater than 0
76
76
77
77
Ideal values with no IP wastage would require the max pods value to conform to the above expression.
78
78
79
-
**Example 1:** max_pods = 30, CIDR Blocks allocated per node = 2, Total IPs available for pods = (16 * 2) - 1 = 32 - 1 = 31, IP wastage per node = 31 - 30 = 1 **[Low wastage - Acceptable Case]**
80
-
**Example 2:** max_pods = 31, CIDR Blocks allocated per node = 2, Total IPs available for pods = (16 * 2) - 1 = 32 - 1 = 31, IP wastage per node = 31 - 31 = 0 **[Ideal Case]**
81
-
**Example 3:** max_pods = 32, CIDR Blocks allocated per node = 3, Total IPs available for pods = (16 * 3) - 1 = 48 - 1 = 47, IP wastage per node = 47 - 32 = 15 **[High Wastage - Not Recommended Case]**
79
+
- **Example 1:** max_pods = 30, CIDR Blocks allocated per node = 2, Total IPs available for pods = (16 * 2) - 1 = 32 - 1 = 31, IP wastage per node = 31 - 30 = 1 **[Low wastage - Acceptable Case]**
80
+
- **Example 2:** max_pods = 31, CIDR Blocks allocated per node = 2, Total IPs available for pods = (16 * 2) - 1 = 32 - 1 = 31, IP wastage per node = 31 - 31 = 0 **[Ideal Case]**
81
+
- **Example 3:** max_pods = 32, CIDR Blocks allocated per node = 3, Total IPs available for pods = (16 * 3) - 1 = 48 - 1 = 47, IP wastage per node = 47 - 32 = 15 **[High Wastage - Not Recommended Case]**
82
82
83
83
The planning of IPs for Kubernetes services remain unchanged.
84
84
@@ -87,7 +87,7 @@ The planning of IPs for Kubernetes services remain unchanged.
87
87
88
88
## Deployment parameters
89
89
90
-
The [deployment parameters][azure-cni-deployment-parameters]for configuring basic Azure CNI networking in AKS are all valid, with two exceptions:
90
+
The [deployment parameters][azure-cni-deployment-parameters]for configuring basic Azure CNI networking in AKS are all valid, with two exceptions:
91
91
92
92
- The **vnet subnet id** parameter now refers to the subnet related to the cluster's nodes.
93
93
- The parameter **pod subnet id** is used to specify the subnet whose IP addresses will be statically or dynamically allocated to pods in the node pool.
@@ -204,7 +204,7 @@ az aks nodepool add --cluster-name $clusterName -g $resourceGroup -n newnodepoo
204
204
205
205
-**Can some node pools in a cluster use Dynamic IP allocation while others use the new Static Block allocation?**
206
206
207
-
Yes, different node pools can use different allocation modes. However, once a subnet is used in one allocation mode it can only be used in the same allocation mode across all the node pools it is associated.
207
+
Yes, different node pools can use different allocation modes. However, once a subnet is used in one allocation mode it can only be used in the same allocation mode across all the node pools it is associated.
208
208
209
209
## Next steps
210
210
@@ -221,4 +221,8 @@ Learn more about networking in AKS in the following articles:
Copy file name to clipboardExpand all lines: articles/machine-learning/how-to-secure-workspace-vnet.md
+4-7Lines changed: 4 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -273,6 +273,8 @@ Azure Container Registry can be configured to use a private endpoint. Use the fo
273
273
az ml workspace update --name myworkspace --resource-group myresourcegroup --image-build-compute mycomputecluster
274
274
```
275
275
276
+
You can switch back to serverless compute by executing the same command and referencing the compute as an empty space: `--image-build-compute ' '`.
277
+
276
278
# [Python SDK](#tab/python)
277
279
278
280
The following code snippet demonstrates how to update the workspace to set a build compute using the [Azure Machine Learning SDK](/python/api/overview/azure/ai-ml-readme). Replace `mycomputecluster` with the name of the cluster to use:
@@ -297,7 +299,8 @@ Azure Container Registry can be configured to use a private endpoint. Use the fo
297
299
# Update to use cpu-cluster for image builds
298
300
ws.image_build_compute="cpu-cluster"
299
301
ml_client.workspaces.begin_update(ws)
300
-
# To switch back to using ACR to build (if ACR is not in the VNet):
302
+
303
+
# To switch back to serverless compute:
301
304
# ws.image_build_compute = ''
302
305
# ml_client.workspaces.begin_update(ws)
303
306
```
@@ -311,12 +314,6 @@ Azure Container Registry can be configured to use a private endpoint. Use the fo
311
314
312
315
---
313
316
314
-
> [!TIP]
315
-
> If you have configured your image build compute to use a compute cluster and want to reverse this decision, execute the same command but leave the image-build-compute reference empty:
316
-
> ```azurecli
317
-
> az ml workspace update --name myworkspace --resource-group myresourcegroup --image-build-compute ''
318
-
> ```
319
-
320
317
> [!TIP]
321
318
> When ACR is behind a VNet, you can also [disable public access](../container-registry/container-registry-access-selected-networks.md#disable-public-network-access) to it.
Copy file name to clipboardExpand all lines: articles/mysql/flexible-server/how-to-data-in-replication.md
+59-57Lines changed: 59 additions & 57 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -80,110 +80,112 @@ The following steps prepare and configure the MySQL server hosted on-premises, i
80
80
81
81
1. After the server is restarted, verify that binary logging is enabled by running the same query as before:
82
82
83
-
```sql
84
-
SHOW VARIABLES LIKE 'log_bin';
85
-
```
83
+
```sql
84
+
SHOW VARIABLES LIKE 'log_bin';
85
+
```
86
86
87
87
#### [GTID based replication](#tab/shell)
88
88
89
89
The Master server needs to be started with GTID mode enabled by setting the gtid_mode variable to ON. It's also essential that the enforce_gtid_consistency variable is enabled to make sure that only the statements, which are safe for MySQL GTIDs Replication are logged.
90
90
91
+
```sql
91
92
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
92
-
93
93
SET @@GLOBAL.GTID_MODE = ON;
94
-
94
+
```
95
+
95
96
If the master server is another Azure Database for MySQL flexible server instance, then these server parameters can also be updated from the portal by navigating to server parameter page.
96
97
97
98
98
99
1. Configure the source server settings.
99
100
100
-
Data-in replication requires the parameter `lower_case_table_names` to be consistent between the source and replica servers. This parameter is 1 by default in Azure Database for MySQL flexible server.
101
+
Data-in replication requires the parameter `lower_case_table_names` to be consistent between the source and replica servers. This parameter is 1 by default in Azure Database for MySQL flexible server.
101
102
102
-
```sql
103
-
SET GLOBAL lower_case_table_names = 1;
104
-
```
103
+
```sql
104
+
SET GLOBAL lower_case_table_names = 1;
105
+
```
105
106
106
-
5. Create a new replication role and set up permission.
107
+
1. Create a new replication role and set up permission.
107
108
108
-
Create a user account on the source server that is configured with replication privileges. This can be done through SQL commands or a tool such as MySQL Workbench. Consider whether you plan on replicating with SSL, as this will need to be specified when creating the user. Refer to the MySQL documentation to understand how to [add user accounts](https://dev.mysql.com/doc/refman/5.7/en/user-names.html) on your source server.
109
+
Create a user account on the source server that is configured with replication privileges. This can be done through SQL commands or a tool such as MySQL Workbench. Consider whether you plan on replicating with SSL, as this will need to be specified when creating the user. Refer to the MySQL documentation to understand how to [add user accounts](https://dev.mysql.com/doc/refman/5.7/en/user-names.html) on your source server.
109
110
110
-
In the following commands, the new replication role created can access the source from any machine, not just the machine that hosts the source itself. This is done by specifying "syncuser@'%'" in the create user command. See the MySQL documentation to learn more about [specifying account names](https://dev.mysql.com/doc/refman/5.7/en/account-names.html).
111
+
In the following commands, the new replication role created can access the source from any machine, not just the machine that hosts the source itself. This is done by specifying "syncuser@'%'" in the create user command. See the MySQL documentation to learn more about [specifying account names](https://dev.mysql.com/doc/refman/5.7/en/account-names.html).
111
112
112
-
#### [SQL Command](#tab/command-line)
113
+
#### [SQL Command](#tab/command-line)
113
114
114
-
**Replication with SSL**
115
+
**Replication with SSL**
115
116
116
-
To require SSL for all user connections, use the following command to create a user:
117
+
To require SSL for all user connections, use the following command to create a user:
117
118
118
-
```sql
119
-
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
120
-
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
121
-
```
119
+
```sql
120
+
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
121
+
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
122
+
```
122
123
123
-
**Replication without SSL**
124
+
**Replication without SSL**
124
125
125
-
If SSL isn't required for all connections, use the following command to create a user:
126
+
If SSL isn't required for all connections, use the following command to create a user:
126
127
127
-
```sql
128
-
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
129
-
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
130
-
```
128
+
```sql
129
+
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
130
+
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
131
+
```
131
132
132
-
#### [MySQL Workbench](#tab/mysql-workbench)
133
+
#### [MySQL Workbench](#tab/mysql-workbench)
133
134
134
-
To create the replication role in MySQL Workbench, open the **Users and Privileges** panel from the **Management** panel, and thenselect**Add Account**.
135
+
To create the replication role in MySQL Workbench, open the **Users and Privileges** panel from the **Management** panel, and thenselect**Add Account**.
135
136
136
-
:::image type="content" source="./media/how-to-data-in-replication/users-privileges.png" alt-text="Users and Privileges":::
137
+
:::image type="content" source="./media/how-to-data-in-replication/users-privileges.png" alt-text="Users and Privileges":::
137
138
138
-
Type in the username into the **Login Name** field.
139
+
Type in the username into the **Login Name** field.
Select the **Administrative Roles** panel and thenselect**Replication Slave** from the list of **Global Privileges**. Then select**Apply** to create the replication role.
143
+
Select the **Administrative Roles** panel and thenselect**Replication Slave** from the list of **Global Privileges**. Then select**Apply** to create the replication role.
Before starting to dump out the database, the server needs to be placed in read-only mode. While in read-only mode, the source will be unable to process any write transactions. Evaluate the impact to your business and schedule the read-only window in an off-peak timeif necessary.
149
+
Before starting to dump out the database, the server needs to be placed in read-only mode. While in read-only mode, the source will be unable to process any write transactions. Evaluate the impact to your business and schedule the read-only window in an off-peak timeif necessary.
149
150
150
-
```sql
151
-
FLUSH TABLES WITH READ LOCK;
152
-
SET GLOBAL read_only = ON;
153
-
```
151
+
```sql
152
+
FLUSH TABLES WITH READ LOCK;
153
+
SET GLOBAL read_only = ON;
154
+
```
154
155
155
156
1. Get binary log file name and offset.
156
157
157
158
Run the [`show master status`](https://dev.mysql.com/doc/refman/5.7/en/show-master-status.html) command to determine the current binary log file name and offset.
158
159
159
160
```sql
160
-
show master status;
161
+
show master status;
161
162
```
162
163
163
-
The results should appear similar to the following. Make sure to note the binary file name forusein later steps.
164
+
The results should appear similar to the following. Make sure to note the binary file name forusein later steps.
164
165
165
-
:::image type="content" source="./media/how-to-data-in-replication/master-status.png" alt-text="Master Status Results":::
166
+
:::image type="content" source="./media/how-to-data-in-replication/master-status.png" alt-text="Master Status Results":::
166
167
167
168
---
168
169
169
170
## Dump and restore the source server
170
171
171
172
1. Determine which databases and tables you want to replicate into Azure Database for MySQL flexible server and perform the dump from the source server.
172
173
173
-
You can use mysqldump to dump databases from your primary server. For details, refer to [Dump & Restore](../concepts-migrate-dump-restore.md). It's unnecessary to dump the MySQL library and test library.
174
+
You can use mysqldump to dump databases from your primary server. For details, refer to [Dump & Restore](../concepts-migrate-dump-restore.md). It's unnecessary to dump the MySQL library and test library.
174
175
175
-
2. Set source server to read/write mode.
176
+
1. Set source server to read/write mode.
176
177
177
178
After the database has been dumped, change the source MySQL server back to read/write mode.
178
179
179
180
```sql
180
181
SET GLOBAL read_only = OFF;
181
182
UNLOCK TABLES;
182
183
```
183
-
[!NOTE]
184
-
> Before the server is set back to read/write mode, you can retrieve the GTID information using global variable GTID_EXECUTED. The same will be used at the later stage to set GTID on the replica server
185
184
186
-
3. Restore dump file to new server.
185
+
>[!NOTE]
186
+
> Before the server is set back to read/write mode, you can retrieve the GTID information using global variable GTID_EXECUTED. This will be used at the later stage to set GTID on the replica server.
187
+
188
+
1. Restore dump file to new server.
187
189
188
190
Restore the dump file to the server created in Azure Database for MySQL flexible server. Refer to [Dump & Restore](../concepts-migrate-dump-restore.md) for how to restore a dump file to a MySQL server. If the dump file is large, upload it to a virtual machine in Azure within the same region as your replica server. Restore it to the Azure Database for MySQL flexible server instance from the virtual machine.
189
191
@@ -194,9 +196,9 @@ The results should appear similar to the following. Make sure to note the binary
194
196
195
197
1. Skip the step if using bin-log position-based replication
196
198
197
-
2. GTID information from the dump file taken from the source is required to reset GTID history of the target (replica) server.
199
+
1. GTID information from the dump file taken from the source is required to reset GTID history of the target (replica) server.
198
200
199
-
3. Use this GTID information from the source to execute GTID reset on the replica server using the following CLI command:
201
+
1. Use this GTID information from the source to execute GTID reset on the replica server using the following CLI command:
200
202
201
203
```azurecli-interactive
202
204
az mysql flexible-server gtid reset --resource-group <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>
@@ -215,7 +217,7 @@ For more details refer [GTID Reset](/cli/azure/mysql/flexible-server/gtid).
215
217
216
218
All Data-in replication functions are done by stored procedures. You can find all procedures at [Data-in replication Stored Procedures](../reference-stored-procedures.md). The stored procedures can be run in the MySQL shell or MySQL Workbench.
217
219
218
-
To link two servers and start replication, login to the target replica server in the Azure Database for MySQL service and set the external instance as the source server. This is done by using the `mysql.az_replication_change_master` or `mysql.az_replication_change_master_with_gtid` stored procedure on the Azure Database for MySQL server.
220
+
To link two servers and start replication, login to the target replica server in the Azure Database for MySQL service and set the external instance as the source server. This is done by using the `mysql.az_replication_change_master` or `mysql.az_replication_change_master_with_gtid` stored procedure on the Azure Database for MySQL server.
- master_port: port number on which source server is listening for connections. (3306 is the default port on which MySQL is listening)
232
-
- master_log_file: binary log file name from running `show master status`
233
-
- master_log_pos: binary log position from running `show master status`
234
-
- master_ssl_ca: CA certificate's context. If not using SSL, pass in empty string.
230
+
- master_host: hostname of the source server
231
+
- master_user: username for the source server
232
+
- master_password: password for the source server
233
+
- master_port: port number on which source server is listening for connections. (3306 is the default port on which MySQL is listening)
234
+
- master_log_file: binary log file name from running `show master status`
235
+
- master_log_pos: binary log position from running `show master status`
236
+
- master_ssl_ca: CA certificate's context. If not using SSL, pass in empty string.
235
237
236
238
It's recommended to pass this parameter in as a variable. For more information, visit the following examples.
237
239
@@ -287,9 +289,9 @@ To link two servers and start replication, login to the target replica server in
287
289
show slave status;
288
290
```
289
291
290
-
To know the correct status of replication, refer to replication metrics - **Replica IO Status** and **Replica SQL Status** under monitoring page.
292
+
To know the correct status of replication, refer to replication metrics - **Replica IO Status** and **Replica SQL Status** under monitoring page.
291
293
292
-
If the `Seconds_Behind_Master` is "0", replication is working well. `Seconds_Behind_Master` indicates how late the replica is. If the value isn't "0", it means that the replica is processing updates.
294
+
If the `Seconds_Behind_Master` is "0", replication is working well. `Seconds_Behind_Master` indicates how late the replica is. If the value isn't "0", it means that the replica is processing updates.
293
295
294
296
## Other useful stored procedures for Data-in replication operations
0 commit comments