Comment sauvegarder les clusters d'opérateurs MySQL Kubernetes

L'opérateur MySQL d'Oracle pour Kubernetes est un moyen pratique d'automatiser le provisionnement de la base de données MySQL au sein de votre cluster. L'une des principales caractéristiques de l'opérateur est la prise en charge intégrée de la sauvegarde sans intervention qui augmente votre résilience. Les sauvegardes copient votre base de données vers un stockage externe selon un calendrier récurrent.

Cet article vous guidera tout au long de la configuration des sauvegardes vers un service de stockage d'objets compatible Amazon S3. Vous verrez également comment stocker des sauvegardes dans le stockage Oracle Cloud Infrastructure (OCI) ou dans des volumes persistants locaux à l'intérieur de votre cluster.

Préparation d'un cluster de bases de données< /h2>

Installez l'opérateur MySQL dans votre cluster Kubernetes et créez une instance de base de données simple à des fins de test. Copiez le YAML ci-dessous et enregistrez-le dans mysql.yaml :

apiVersion : v1 type : Secretmétadonnées :nom : mysql-root-user stringData : rootHost : "%" rootUser : "root" rootPassword : "P@$$w0rd" — apiVersion : mysql.oracle.com/v2 genre : InnoDBCluster métadonnées : nom : mysql-clusterspec : secretName : mysql-root-user instances : 3 tlsUseSelfSigned : true routeur : instances : 1

Utilisez Kubectl pour appliquer le manifeste :

$ kubectl apply – f mysql.yaml

Attendez quelques minutes pendant que l'opérateur MySQL provisionne vos pods. Utilisez la commande get pods de Kubectl pour vérifier la progression. Vous devriez voir quatre pods en cours d'exécution : une instance de routeur MySQL et trois répliques de serveur MySQL.

$ kubectl get pods NAME READY STATUS RESTARTS AGE mysql-cluster-0 2/2 Running 0 2m mysql-cluster-1 2/2 Running 0 2m mysql-cluster-2 2/2 En cours d'exécution 0 2m mysql-cluster-router-6b68f9b5cb-wbqm5 1/1 En cours d'exécution 0 2m

Définir une planification de sauvegarde

L'opérateur MySQL a besoin de deux composants pour réussir à créer une sauvegarde :

Un programme de sauvegarde qui définit quand la sauvegarde s'exécutera.
Un profil de sauvegarde qui configure l'emplacement de stockage et les options d'exportation MySQL.

Les horaires et les profils sont créés indépendamment les uns des autres. Cela vous permet d'exécuter plusieurs sauvegardes sur différentes planifications en utilisant le même profil.

Chaque planification et profil est associé à un cluster de base de données spécifique. Ils sont créés en tant que ressources imbriquées dans vos objets InnoDBCluster. Chaque base de données que vous créez avec l'opérateur MySQL nécessite sa propre configuration de sauvegarde.

Les planifications de sauvegarde sont définies par le champ spec.backupSchedules de votre base de données. Chaque élément nécessite un champ de planification qui spécifie quand exécuter la sauvegarde à l'aide d'une expression cron. Voici un exemple qui démarre une sauvegarde toutes les heures :

apiVersion : mysql.oracle.com/v2 genre: InnoDBCluster metadata : nom : mysql-cluster spec : secretName : mysql-root-user instances : 3 tlsUseSelfSigned : vrairouteur :instances : 1planifications de sauvegarde : – nom : horaire activé : trueplanning : "0 * * * *" backupProfileName : sauvegarde horaire

Le champ backupProfileName fait référence au profil de sauvegarde à utiliser. Vous le créerez à l'étape suivante.

Création de profils de sauvegarde

Les profils sont définis dans le champ spec.backupProfiles. Chaque profil doit avoir un nom et une propriété dumpInstance qui configure l'opération de sauvegarde.

apiVersion : mysql.oracle. com/v2 type : métadonnées InnoDBCluster : nom : mysql-cluster spec : secretName : mysql-root-user instances : 3 tlsUseSelfSigned : vrairouteur :instances : 1planifications de sauvegarde :– nom : horaire activé : true horaire : "0 * * * *" backupProfileName : sauvegarde horaire backupProfiles : – nom : sauvegarde horaire dumpInstance: stockage : # …

Le stockage de sauvegarde est configuré sur une base par profil dans le champ dumpInstance.storage. Les propriétés que vous devez fournir dépendent du type de stockage que vous utilisez.

S3 Storage

L'opérateur MySQL peut télécharger vos sauvegardes directement vers des fournisseurs de stockage d'objets compatibles S3. Pour utiliser cette méthode, vous devez créer un secret Kubernetes contenant un fichier de configuration aws CLI avec vos informations d'identification.

Ajoutez le contenu suivant à s3-secret.yaml :

apiVersion : v1 type : Secret métadonnées : nom : s3-secret stringData : identifiants : | [default] aws_access_key_id = YOUR_S3_ACCESS_KEY aws_secret_access_key = YOUR_S3_SECRET_KEY

Remplacez vos propres clés d'accès et secrètes S3, puis utilisez Kubectl pour créer la clé secrète :

$ kubectl apply -f s3-secret.yaml secret/s3-secret créé

Ajoutez ensuite les champs suivants à la section storage.s3 de votre profil de sauvegarde :

bucketName – Le nom du compartiment S3 dans lequel télécharger vos sauvegardes.
préfixe– Définissez ceci pour appliquer un préfixe à vos fichiers téléchargés, tels que /my-app/mysql. Le préfixe vous permet de créer des arborescences de dossiers dans votre compartiment.
endpoint – Définissez ceci sur l'URL de votre fournisseur de services lorsque vous utilisez un stockage tiers compatible S3. Vous pouvez omettre ce champ si vous utilisez Amazon S3.
config – Le nom du secret contenant votre fichier d'informations d'identification.
profil– Nom du profil de configuration à utiliser dans le fichier d'informations d'identification. Cela a été défini par défaut dans l'exemple ci-dessus.

Voici un exemple complet :

apiVersion : mysql.oracle.com/v2 type : InnoDBCluster metadata : name : mysql-cluster spec : nomsecret : mysql-root-user instances : 3 tlsUseSelfSigned : vrairouteur :instances : 1 backupSchedules : – nom : horaire activé : truehoraire : "0 * * * *" backupProfileName : hourly-backup backupProfiles : – nom : hourly-backup dumpInstance : stockage : s3 : bucketName : sauvegardespréfixe : /mysql config : s3-secret profile : default

L'application de ce manifeste activera les sauvegardes de base de données toutes les heures sur votre compte S3.

Stockage OCI

L'opérateur prend en charge le stockage d'objets Oracle Cloud Infrastructure (OCI) comme alternative à S3. Il est configuré de manière similaire. Créez d'abord un secret pour vos identifiants OCI :

apiVersion : v1 kind : métadonnées secrètes : nom : oci-secret stringData : empreinte digitale : VOTRE_OCI_FINGERPRINT phrase de passe : VOTRE_OCI_PASSPHRASE clé privée : VOTRE_OCI_RSA_PRIVATE_KEY région : us-ashburn-1 location : VOTRE_OCI_TENANCY utilisateur : YOUR_OCI_USER

Configurez ensuite le profil de sauvegarde avec une strophe storage.ociObjectStorage :

apiVersion : mysql.oracle.com/v2 type : métadonnées InnoDBCluster : nom : mysql-cluster spécification : secretName : instances mysql-root-user : 3 tlsUseSelfSigned : vrairouteur :instances : 1planifications de sauvegarde : – nom : horaire activé : truehoraire : "0 * * * *" backupProfileName : sauvegarde horairebackupProfiles : – nom : hourly-backup dumpInstance : stockage : ociObjectStorage : bucketName : sauvegardes préfixe : /mysql identifiants : oci-secret

Modifiez les champs bucketName et prefix pour définir l'emplacement de téléchargement dans votre compte OCI. Le champ des informations d'identification doit faire référence au secret qui contient vos informations d'identification OCI.

Kubernetes Volume Storage

Les volumes persistants locaux sont une troisième option de stockage. Ceci est moins robuste car vos données de sauvegarde résideront toujours dans votre cluster Kubernetes. Cependant, cela peut être utile pour des sauvegardes ponctuelles et à des fins de test.

Créez d'abord un volume persistant et la demande qui l'accompagne :

apiVersion : v1 type : PersistentVolume metadata : nom : backup-pv spec : storageClassName : capacité standard> : stockage : 10Gi accessModes : – ReadWriteOnce hostPath : chemin : /tmp — apiVersion : v1 genre : PersistentVolumeClaim métadonnées : nom : backup-pvc spec : storageClassName : standard accessModes : – ReadWriteOnce ressources : requêtes : stockage : 10Gi

Cet exemple de manifeste ne convient pas à une utilisation en production. Vous devez sélectionner une classe de stockage et un mode de montage de volume appropriés pour votre distribution Kubernetes.

Configurez ensuite votre profil de sauvegarde pour utiliser votre volume persistant en ajoutant un champ storage.persistentVolumeClaim :

apiVersion : mysql.oracle.com/v2 type : Métadonnées InnoDBCluster : nom : mysql-cluster spécification : secretName : instances mysql-root-user : 3 tlsUseSelfSigned : true routeur : instances : 1planifications de sauvegarde : – nom : horaire activé : vraihoraire : "0 * * * *" backupProfileName : sauvegarde horaire backupProfiles : – name : hourly-backup dumpInstance : stockage : persistentVolumeClaim : claimName : backup-pvc

La demande de volume persistant créée précédemment est référencée par le champ claimName. L'opérateur MySQL va maintenant déposer les données de sauvegarde dans le volume.

Définition des options de sauvegarde

Les sauvegardes sont créées à l'aide de l'utilitaire dumpInstance de MySQL Shell. Par défaut, cela exporte un vidage complet de votre serveur. Le format écrit des fichiers de structure et de données fragmentées pour chaque table. La sortie est compressée avec zstd.

Vous pouvez transmettre des options à dumpInstance via le champ dumpOptions dans un profil de sauvegarde d'opérateur MySQL :

apiVersion : mysql.oracle.com/v2 type : InnoDBCluster metadata : name : mysql-cluster spec : # … backupProfiles : – nom : sauvegarde horaire dumpInstance : dumpOptions : segmentation : falsecompression : gzipstockage : # …

Cet exemple désactive la sortie fragmentée, crée un fichier de données par table et passe à la compression gzip au lieu de zstd. Vous pouvez trouver une référence complète pour les options disponibles dans la documentation MySQL.

Restauration d'une sauvegarde

L'opérateur MySQL peut initialiser de nouveaux clusters de bases de données à l'aide de fichiers précédemment créés à partir de dumpInstance. Cela vous permet de restaurer vos sauvegardes directement dans votre cluster Kubernetes. Il est utile dans les situations de récupération ou lorsque vous migrez une base de données existante vers Kubernetes.

L'initialisation de la base de données est contrôlée par le champ spec.initDB sur vos objets InnoDBCluster. Dans cette strophe, utilisez l'objet dump.storage pour référencer l'emplacement de sauvegarde que vous avez utilisé précédemment. Le format correspond au champ dumpInstance.storage équivalent dans les objets de profil de sauvegarde.

apiVersion : v1 genre : métadonnées secrètes: nom : s3-secret stringData : identifiants : | [default] aws_access_key_id = VOTRE_S3_ACCESS_KEY aws_secret_access_key = VOTRE_S3_SECRET_KEY — apiVersion : mysql.oracle.com/v2 type : InnoDBCluster métadonnées : nom : mysql-cluster-recovered spec : secretName : mysql-root-user instances : 3 tlsUseSelfSigned : truerouteur :instances : 1 initDB : vidage : stockage : s3 : bucketName : sauvegardes préfixe : /mysql/mysql20221031220000 config : s3-secretprofil : par défaut

L'application de ce fichier YAML créera un nouveau cluster de base de données initialisé avec la sortie dumpInstance dans le compartiment S3 spécifié. Le champ de préfixe doit contenir le chemin d'accès complet aux fichiers de vidage dans le compartiment. Les sauvegardes créées par l'opérateur seront automatiquement stockées dans des dossiers horodatés ; vous devrez indiquer lequel récupérer en définissant le préfixe. Si vous restaurez à partir d'un volume persistant, utilisez le champ de chemin au lieu du préfixe.

Résumé

L'opérateur MySQL d'Oracle automatise la gestion de la base de données MySQL au sein des clusters Kubernetes. Dans cet article, vous avez appris à configurer le système de sauvegarde de l'opérateur pour stocker des vidages de base de données complets dans un volume persistant ou un bucket de stockage d'objets.

L'utilisation de Kubernetes pour mettre à l'échelle horizontalement MySQL ajoute de la résilience, mais les sauvegardes externes sont toujours essentielles au cas où votre cluster serait compromis ou si des données étaient accidentellement supprimées. L'opérateur MySQL peut restaurer une nouvelle instance de base de données à partir de votre sauvegarde si vous en avez besoin, simplifiant ainsi la procédure de récupération après sinistre.

LIRE LA SUITE

› Qu'est-ce qu'un microphone supercardioïde ?

&rsaquo ; Comment compter les cases à cocher dans Microsoft Excel

› La fonctionnalité SOS satellite de l'iPhone 14 arrive en novembre

&rsaquo ; Comment masquer les bobines sur Facebook

&rsaquo ; Comment désactiver les notifications sur iPhone

› Une petite ville demande à la startup de “Veuillez éteindre ce moteur de fusée”