Skip to content

Commit ec7e946

Browse files
huypubhuypub
authored
Merge pull request #247328 from MicrosoftDocs/release-arc-data
Arc data August 2023 release -- scheduled release at 3pm of 8/08
2 parents 2b12d3e + bd4fa68 commit ec7e946

12 files changed

+639
-282
lines changed

‎articles/azure-arc/data/backup-controller-database.md

Lines changed: 224 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
2-
title: Backup controller database
3-
description: Explains how to backup the controller database for Azure Arc-enabled data services
2+
title: Back up controller database
3+
description: Explains how to back up the controller database for Azure Arc-enabled data services
44
services: azure-arc
55
ms.service: azure-arc
66
ms.subservice: azure-arc-data
@@ -11,56 +11,248 @@ ms.date: 04/26/2023
1111
ms.topic: how-to
1212
---
1313

14-
# Backup controller database
14+
# Back up and recover controller database
1515

16-
When you deploy Azure Arc data services, the Azure Arc Data Controller is one of the most critical components of the deployment. The data controller:
16+
When you deploy Azure Arc data services, the Azure Arc Data Controller is one of the most critical components that is deployed. The functions of the data controller include:
1717

18-
- Provisions and deprovisions resources
19-
- Orchestrates most of the activities for Azure Arc-enabled SQL Managed Instance
20-
- Captures the billing and usage information of each Arc SQL managed instance.
18+
- Provision, de-provision and update resources
19+
- Orchestrate most of the activities for Azure Arc-enabled SQL Managed Instance such as upgrades, scale out etc.
20+
- Capture the billing and usage information of each Arc SQL managed instance.
2121

22-
All information such as inventory of all the Arc SQL managed instances, billing, usage and the current state of all these SQL managed instances is stored in a database called `controller` under the SQL Server instance that is deployed into the `controldb-0` pod.
22+
In order to perform above functions, the Data controller needs to store an inventory of all the current Arc SQL managed instances, billing, usage and the current state of all these SQL managed instances. All this data is stored in a database called `controller` within the SQL Server instance that is deployed into the `controldb-0` pod.
2323

2424
This article explains how to back up the controller database.
2525

26-
Following steps are needed in order to back up the `controller` database:
26+
## Back up data controller database
2727

28-
1. Retrieve the credentials for the secret
29-
1. Decode the base64 encoded credentials
30-
1. Use the decoded credentials to connect to the SQL instance hosting the controller database, and issue the `BACKUP` command
28+
As part of built-in capabilities, the Data controller database `controller` is automatically backed up every 5 minutes once backups are enabled. To enable backups:
3129

32-
## Retrieve the credentials for the secret
30+
- Create a `backups-controldb` `PersistentVolumeClaim` with a storage class that supports `ReadWriteMany` access:
3331

34-
`controller-db-rw-secret` is the secret that holds the credentials for the `controldb-rw-user` user account that can be used to connect to the SQL instance.
35-
Run the following command to retrieve the secret contents:
36-
37-
```azurecli
38-
kubectl get secret controller-db-rw-secret --namespace [namespace] -o yaml
32+
```yaml
33+
apiVersion: v1
34+
kind: PersistentVolumeClaim
35+
metadata:
36+
name: backups-controldb
37+
namespace: <namespace>
38+
spec:
39+
accessModes:
40+
- ReadWriteMany
41+
resources:
42+
requests:
43+
storage: 15Gi
44+
storageClassName: <storage-class>
3945
```
4046
41-
For example:
47+
- Edit the `DataController` custom resource spec to include a `backups` storage definition:
4248

43-
```azurecli
44-
kubectl get secret controller-db-rw-secret --namespace arcdataservices -o yaml
49+
```yaml
50+
storage:
51+
backups:
52+
accessMode: ReadWriteMany
53+
className: <storage-class>
54+
size: 15Gi
55+
data:
56+
accessMode: ReadWriteOnce
57+
className: managed-premium
58+
size: 15Gi
59+
logs:
60+
accessMode: ReadWriteOnce
61+
className: managed-premium
62+
size: 10Gi
4563
```
4664

47-
## Decode the base64 encoded credentials
65+
The `.bak` files for the `controller` database are stored on the `backups` volume of the `controldb` pod at `/var/opt/backups/mssql`.
4866

49-
The contents of the yaml file of the secret `controller-db-rw-secret` contain a `password` and `username`. You can use any base64 decoder tool to decode the contents of the `password`.
67+
## Recover controller database
5068

51-
## Back up the database
69+
There are two types of recovery possible:
5270

53-
With the decoded credentials, run the following command to issue a T-SQL `BACKUP` command to back up the controller database.
71+
1. `controller` is corrupted and you just need to restore the database
72+
1. the entire storage that contains the `controller` data and log files is corrupted/gone and you need to recover
5473

55-
```azurecli
56-
kubectl exec controldb-0 -n contosons -c mssql-server -- /opt/mssql-tools/bin/sqlcmd -S localhost -U controldb-rw-user -P "<password>" -Q "BACKUP DATABASE [controller] TO DISK = N'/var/opt/controller.bak' WITH NOFORMAT, NOINIT, NAME = N'Controldb-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM"
57-
```
74+
### Corrupted controller database scenario
75+
76+
In this scenario, all the pods are up and running, you are able to connect to the `controldb` SQL Server, and there may be a corruption with the `controller` database. You just need to restore the database from a backup.
77+
78+
Follow these steps to restore the controller database from a backup, if the SQL Server is still up and running on the `controldb` pod, and you are able to connect to it:
79+
80+
1. Verify connectivity to SQL Server pod hosting the `controller` database.
81+
82+
- First, retrieve the credentials for the secret. `controller-system-secret` is the secret that holds the credentials for the `system` user account that can be used to connect to the SQL instance.
83+
Run the following command to retrieve the secret contents:
84+
85+
```console
86+
kubectl get secret controller-system-secret --namespace [namespace] -o yaml
87+
```
88+
89+
For example:
90+
91+
```console
92+
kubectl get secret controller-system-secret --namespace arcdataservices -o yaml
93+
```
94+
95+
- Decode the base64 encoded credentials. The contents of the yaml file of the secret `controller-system-secret` contain a `password` and `username`. You can use any base64 decoder tool to decode the contents of the `password`.
96+
- Verify connectivity: With the decoded credentials, run a command such as `SELECT @@SERVERNAME` to verify connectivity to the SQL Server.
97+
98+
```powershell
99+
kubectl exec controldb-0 -n <namespace> -c mssql-server -- /opt/mssql-tools/bin/sqlcmd -S localhost -U system -P "<password>" -Q "SELECT @@SERVERNAME"
100+
```
101+
102+
```powershell
103+
kubectl exec controldb-0 -n contosons -c mssql-server -- /opt/mssql-tools/bin/sqlcmd -S localhost -U system -P "<password>" -Q "SELECT @@SERVERNAME"
104+
```
105+
106+
1. Scale the controller ReplicaSet down to 0 replicas as follows:
107+
108+
```console
109+
kubectl scale --replicas=0 rs/control -n <namespace>`
110+
```
111+
112+
For example:
113+
114+
```console
115+
kubectl scale --replicas=0 rs/control -n arcdataservices
116+
```
117+
118+
1. Connect to the `controldb` SQL Server as `system` as described in step 1.
119+
120+
1. Delete the corrupted controller database using T-SQL:
121+
122+
```sql
123+
DROP DATABASE controller
124+
```
125+
126+
1. Restore the database from backup - after the corrupted `controllerdb` is dropped. For example:
127+
128+
```sql
129+
RESTORE DATABASE test FROM DISK = '/var/opt/backups/mssql/<controller backup file>.bak'
130+
WITH MOVE 'controller' to '/var/opt/mssql/data/controller.mdf
131+
,MOVE 'controller' to '/var/opt/mssql/data/controller_log.ldf'
132+
,RECOVERY;
133+
GO
134+
```
135+
136+
1. Scale the controller ReplicaSet back up to 1 replica.
137+
138+
```console
139+
kubectl scale --replicas=1 rs/control -n <namespace>
140+
```
141+
142+
For example:
143+
144+
```console
145+
kubectl scale --replicas=1 rs/control -n arcdataservices
146+
```
147+
148+
### Corrupted storage scenario
149+
150+
In this scenario, the storage hosting the Data controller data and log files, has corruption and a new storage was provisioned and you need to restore the controller database.
151+
152+
Follow these steps to restore the controller database from a backup with new storage for the `controldb` StatefulSet:
153+
154+
1. Ensure that you have a backup of the last known good state of the `controller` database
155+
156+
2. Scale the controller ReplicaSet down to 0 replicas as follows:
157+
158+
```console
159+
kubectl scale --replicas=0 rs/control -n <namespace>
160+
```
161+
162+
For example:
163+
164+
```console
165+
kubectl scale --replicas=0 rs/control -n arcdataservices
166+
``
167+
3. Scale the `controldb` StatefulSet down to 0 replicas, as follows:
168+
169+
```console
170+
kubectl scale --replicas=0 sts/controldb -n <namespace>
171+
```
172+
173+
For example:
174+
175+
```console
176+
kubectl scale --replicas=0 sts/controldb -n arcdataservices`
177+
```
178+
179+
4. Create a kubernetes secret named `controller-sa-secret` with the following YAML:
180+
181+
```yml
182+
apiVersion: v1
183+
kind: Secret
184+
metadata:
185+
name: controller-sa-secret
186+
namespace: <namespace>
187+
type: Opaque
188+
data:
189+
password: <base64 encoded password>
190+
```
191+
192+
5. Edit the `controldb` StatefulSet to include a `controller-sa-secret` volume and corresponding volume mount (`/var/run/secrets/mounts/credentials/mssql-sa-password`) in the `mssql-server` container, by using `kubectl edit sts controldb -n <namespace>` command.
193+
194+
6. Create new data (`data-controldb`) and logs (`logs-controldb`) persistent volume claims for the `controldb` pod as follows:
195+
196+
```yml
197+
apiVersion: v1
198+
kind: PersistentVolumeClaim
199+
metadata:
200+
name: data-controldb
201+
namespace: <namespace>
202+
spec:
203+
accessModes:
204+
- ReadWriteOnce
205+
resources:
206+
requests:
207+
storage: 15Gi
208+
storageClassName: <storage class>
209+
210+
---
211+
apiVersion: v1
212+
kind: PersistentVolumeClaim
213+
metadata:
214+
name: logs-controldb
215+
namespace: <namespace>
216+
spec:
217+
accessModes:
218+
- ReadWriteOnce
219+
resources:
220+
requests:
221+
storage: 10Gi
222+
storageClassName: <storage class>
223+
```
224+
225+
7. Scale the `controldb` StatefulSet back to 1 replica using:
226+
227+
```console
228+
kubectl scale --replicas=1 sts/controldb -n <namespace>
229+
```
230+
231+
8. Connect to the `controldb` SQL server as `sa` using the password in the `controller-sa-secret` secret created earlier.
232+
233+
9. Create a `system` login with sysadmin role using the password in the `controller-system-secret` kubernetes secret as follows:
234+
235+
```sql
236+
CREATE LOGIN [system] WITH PASSWORD = '<password-from-secret>'
237+
ALTER SERVER ROLE sysadmin ADD MEMBER [system]
238+
```
239+
240+
10. Restore the backup using the `RESTORE` command as follows:
241+
242+
```sql
243+
RESTORE DATABASE [controller] FROM DISK = N'/var/opt/backups/mssql/<controller backup file>.bak' WITH FILE = 1
244+
```
245+
246+
11. Create a `controldb-rw-user` login using the password in the `controller-db-rw-secret` secret `CREATE LOGIN [controldb-rw-user] WITH PASSWORD = '<password-from-secret>'` and associate it with the existing `controldb-rw-user` user in the controller DB `ALTER USER [controldb-rw-user] WITH LOGIN = [controldb-rw-user]`.
247+
248+
12. Disable the `sa` login using TSQL - `ALTER LOGIN [sa] DISABLE`.
249+
250+
13. Edit the `controldb` StatefulSet to remove the `controller-sa-secret` volume and corresponding volume mount.
58251

59-
Once the backup is created, you can move the `controller.bak` file to a remote storage for any recovery purposes.
252+
14. Delete the `controller-sa-secret` secret.
60253

61-
> [!TIP]
62-
> Back up the controller database before and after any custom resource changes such as creating or deleting an Arc-enabled SQL Managed Instance.
254+
16. Scale the controller ReplicaSet back up to 1 replica using the `kubectl scale` command.
63255

64256
## Next steps
65257

66-
[Azure Data Studio dashboards](azure-data-studio-dashboards.md)
258+
[Azure Data Studio dashboards](azure-data-studio-dashboards.md)

‎articles/azure-arc/data/includes/azure-arc-data-preview-release.md

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -5,9 +5,10 @@ ms.service: azure-arc
55
ms.topic: include
66
ms.date: 05/02/2023
77
---
8-
<!--
8+
99
At this time, a test or preview build is not available for the next release.
10-
-->
10+
11+
<!--
1112
1213
Aug 2023 preview release is now available.
1314
@@ -44,6 +45,4 @@ Aug 2023 preview release is now available.
4445
- Support for configuring and managing Azure Failover groups between two Arc enabled SQL managed instances using Azure portal.
4546
- Upgraded OpenSearch and OpenSearch Dashboards from 2.7.0 to 2.8.0
4647
47-
48-
49-
48+
-->

‎articles/azure-arc/data/includes/failover-group-prerequisites.md

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
---
2+
author: MikeRayMSFT
3+
ms.author: mikeray
4+
ms.service: azure-arc
5+
ms.subservice: azure-arc-data-sqlmi
6+
ms.topic: include
7+
ms.date: 08/01/2023
8+
---
9+
10+
11+
## Prerequisites
12+
13+
The following prerequisites must be met before setting up failover groups between two Azure Arc-enabled SQL managed instances:
14+
15+
- An Azure Arc data controller and an Arc enabled SQL managed instance provisioned at the primary site with `--license-type` as one of `BasePrice` or `LicenseIncluded`.
16+
- An Azure Arc data controller and an Arc enabled SQL managed instance provisioned at the secondary site with identical configuration as the primary in terms of:
17+
- CPU
18+
- Memory
19+
- Storage
20+
- Service tier
21+
- Collation
22+
- Other instance settings
23+
- The instance at the secondary site requires `--license-type` as `DisasterRecovery`. This instance needs to be new, without any user objects.
24+
25+
> [!NOTE]
26+
> - It is important to specify the `--license-type` **during** the Azure Arc-enabled SQL MI creation. This will allow the DR instance to be seeded from the primary instance in the primary data center. Updating this property post deployment will not have the same effect.
27+
28+
## Deployment process
29+
30+
To set up an Azure failover group between two Azure Arc-enabled SQL managed instances, complete the following steps:
31+
32+
1. Create custom resource for distributed availability group at the primary site
33+
1. Create custom resource for distributed availability group at the secondary site
34+
1. Copy the binary data from the mirroring certificates
35+
1. Set up the distributed availability group between the primary and secondary sites
36+
either in `sync` mode or `async` mode
37+
38+
The following image shows a properly configured distributed availability group:
39+
40+
![Diagram showing a properly configured distributed availability group.](..\media\business-continuity\distributed-availability-group.png)
41+
42+
## Synchronization modes
43+
44+
Failover groups in Azure Arc data services support two synchronization modes - `sync` and `async`. The synchronization mode directly impacts how the data is synchronized between the Azure Arc-enabled SQL managed instances, and potentially the performance on the primary managed instance.
45+
46+
If primary and secondary sites are within a few miles of each other, use `sync` mode. Otherwise use `async` mode to avoid any performance impact on the primary site.

0 commit comments

Comments
 (0)