Sauvegarder et récupérer la base de données du contrôleur
Lorsque vous déployez des services de données Azure Arc, le contrôleur de données Azure Arc est l’un des composants les plus critiques déployés. Les fonctions du contrôleur de données sont les suivantes :
- Provisionner, déprovisionner et mettre à jour des ressources
- Orchestrer la plupart des activités pour l’instance SQL Managed Instance activée par Azure Arc, telles que les mises à niveau, le scale-out, etc.
- Capturer les informations de facturation et d’utilisation de chaque instance gérée SQL Arc.
Pour effectuer les fonctions ci-dessus, le contrôleur de données doit stocker un inventaire de toutes les instances gérées SQL Arc actuelles, la facturation, l’utilisation et l’état actuel de toutes ces instances gérées SQL. Toutes ces données sont stockées dans une base de données appelée controller
dans l’instance SQL déployée dans le pod controldb-0
.
Cet article explique comment sauvegarder la base de données du contrôleur.
Sauvegarder la base de données du contrôleur de données
Dans le cadre des fonctionnalités intégrées, la base de données du contrôleur de données controller
est automatiquement sauvegardée toutes les 5 minutes une fois les sauvegardes activées. Pour activer les sauvegardes :
- Créez un
backups-controldb
PersistentVolumeClaim
avec une classe de stockage qui prend en charge l’accèsReadWriteMany
:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: backups-controldb
namespace: <namespace>
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 15Gi
storageClassName: <storage-class>
- Modifiez la spécification de ressource personnalisée
DataController
pour inclure une définition de stockagebackups
:
storage:
backups:
accessMode: ReadWriteMany
className: <storage-class>
size: 15Gi
data:
accessMode: ReadWriteOnce
className: managed-premium
size: 15Gi
logs:
accessMode: ReadWriteOnce
className: managed-premium
size: 10Gi
Les fichiers .bak
de la base de données controller
sont stockés sur le volume backups
du pod controldb
localisé dans /var/opt/backups/mssql
.
Récupérer la base de données du contrôleur
Deux types de récupération sont possibles :
controller
est endommagé et vous devez simplement restaurer la base de données- le stockage entier qui contient les données et les fichiers journaux
controller
est endommagé/a disparu et vous devez récupérer
Scénario de base de données du contrôleur endommagé
Dans ce scénario, tous les pods sont en cours d’exécution, vous pouvez vous connecter au SQL Server controldb
, et il peut y avoir une altération de la base de données controller
. Vous devez simplement restaurer la base de données à partir d’une sauvegarde.
Procédez comme suit pour restaurer la base de données du contrôleur à partir d’une sauvegarde, si SQL Server est toujours opérationnel sur le pod controldb
et que vous pouvez vous y connecter :
Vérifiez la connectivité au pod SQL Server hébergeant la base de données
controller
.Récupérez d’abord les informations d’identification du secret.
controller-system-secret
est le secret qui contient les informations d’identification du compte d’utilisateursystem
qui peut être utilisé pour se connecter à l’instance SQL. Exécutez la commande suivante pour récupérer le contenu du secret :kubectl get secret controller-system-secret --namespace [namespace] -o yaml
Par exemple :
kubectl get secret controller-system-secret --namespace arcdataservices -o yaml
Décodez les informations d’identification encodées en base64. Le contenu du fichier yaml du secret
controller-system-secret
contient unpassword
et unusername
. Vous pouvez utiliser n’importe quel outil de décodeur base64 pour décoder le contenu dupassword
.Vérifier la connectivité : avec les informations d’identification décodées, exécutez une commande telle que
SELECT @@SERVERNAME
pour vérifier la connectivité à SQL Server.kubectl exec controldb-0 -n <namespace> -c mssql-server -- /opt/mssql-tools/bin/sqlcmd -S localhost -U system -P "<password>" -Q "SELECT @@SERVERNAME"
kubectl exec controldb-0 -n contosons -c mssql-server -- /opt/mssql-tools/bin/sqlcmd -S localhost -U system -P "<password>" -Q "SELECT @@SERVERNAME"
Effectuez un scale-down du ReplicaSet du contrôleur jusqu’à 0 réplica comme suit :
kubectl scale --replicas=0 rs/control -n <namespace>`
Par exemple :
kubectl scale --replicas=0 rs/control -n arcdataservices
Connectez-vous au SQL Server
controldb
en tant quesystem
comme décrit à l’étape 1.Supprimez la base de données du contrôleur endommagé à l’aide de T-SQL :
DROP DATABASE controller
Restaurez la base de données à partir de la sauvegarde : une fois la
controllerdb
endommagée supprimée. Par exemple :RESTORE DATABASE test FROM DISK = '/var/opt/backups/mssql/<controller backup file>.bak' WITH MOVE 'controller' to '/var/opt/mssql/data/controller.mdf ,MOVE 'controller' to '/var/opt/mssql/data/controller_log.ldf' ,RECOVERY; GO
Remettez à l’échelle le ReplicaSet du contrôleur vers 1 réplica comme suit :
kubectl scale --replicas=1 rs/control -n <namespace>
Par exemple :
kubectl scale --replicas=1 rs/control -n arcdataservices
Scénario de stockage endommagé
Dans ce scénario, le stockage hébergeant les fichiers journaux et les données du contrôleur de données est endommagé, un nouveau stockage a été provisionné et vous devez restaurer la base de données du contrôleur.
Procédez comme suit pour restaurer la base de données du contrôleur à partir d’une sauvegarde avec un nouveau stockage pour le StatefulSet controldb
:
Vérifiez que vous disposez d’une sauvegarde du dernier état correct connu de la base de données
controller
Effectuez un scale-down du ReplicaSet du contrôleur jusqu’à 0 réplica comme suit :
kubectl scale --replicas=0 rs/control -n <namespace>
Par exemple :
kubectl scale --replicas=0 rs/control -n arcdataservices
Effectuez un scale-down du StatefulSet
controldb
jusqu’à 0 réplica, comme suit :kubectl scale --replicas=0 sts/controldb -n <namespace>
Par exemple :
kubectl scale --replicas=0 sts/controldb -n arcdataservices`
Créez un secret Kubernetes nommé
controller-sa-secret
avec le YAML suivant :apiVersion: v1 kind: Secret metadata: name: controller-sa-secret namespace: <namespace> type: Opaque data: password: <base64 encoded password>
Modifiez le StatefulSet
controldb
pour inclure un volumecontroller-sa-secret
et le montage de volume correspondant (/var/run/secrets/mounts/credentials/mssql-sa-password
) dans le conteneurmssql-server
, à l’aide de la commandekubectl edit sts controldb -n <namespace>
.Créez des données (
data-controldb
) et des journaux (logs-controldb
) des revendications de volume persistant pour le podcontroldb
comme suit :apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data-controldb namespace: <namespace> spec: accessModes: - ReadWriteOnce resources: requests: storage: 15Gi storageClassName: <storage class> --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: logs-controldb namespace: <namespace> spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: <storage class>
Remettez à l’échelle le
controldb
StatefulSet vers 1 réplica à l’aide de :kubectl scale --replicas=1 sts/controldb -n <namespace>
Connectez-vous au serveur SQL
controldb
en tant quesa
à l’aide du mot de passe du secretcontroller-sa-secret
créé précédemment.Créez une connexion
system
avec un rôle sysadmin à l’aide du mot de passe dans le secret Kubernetescontroller-system-secret
comme suit :CREATE LOGIN [system] WITH PASSWORD = '<password-from-secret>' ALTER SERVER ROLE sysadmin ADD MEMBER [system]
Restaurez la sauvegarde à l’aide de la commande
RESTORE
comme suit :
RESTORE DATABASE [controller] FROM DISK = N'/var/opt/backups/mssql/<controller backup file>.bak' WITH FILE = 1
Créez une connexion
controldb-rw-user
à l’aide du mot de passe dans le secretcontroller-db-rw-secret
CREATE LOGIN [controldb-rw-user] WITH PASSWORD = '<password-from-secret>'
et associez-le à l’utilisateurcontroldb-rw-user
existant dans la base de données du contrôleurALTER USER [controldb-rw-user] WITH LOGIN = [controldb-rw-user]
.Désactivez la connexion
sa
à l’aide de TSQL -ALTER LOGIN [sa] DISABLE
.Modifiez le StatefulSet
controldb
pour supprimer le volumecontroller-sa-secret
et le montage de volume correspondant.Supprimez le secret
controller-sa-secret
.Remettez à l’échelle le ReplicaSet du contrôleur vers 1 réplica à l’aide de la commande
kubectl scale
.