Comment activer le journal des requêtes lentes de MySQL
Agence web » Actualités du digital » Comment sauvegarder les clusters d’opérateurs MySQL Kubernetes

Comment sauvegarder les clusters d’opérateurs MySQL Kubernetes

ParTremplin Numérique Publié le

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 sur un stockage externe selon un calendrier récurrent.

Cet article vous guidera dans 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 des volumes persistants locaux à l’intérieur de votre cluster.

Préparation d’un cluster de bases de données

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
kind: Secret
metadata:
  name: mysql-root-user
stringData:
  rootHost: "%"
  rootUser: "root"
  rootPassword: "P@$$w0rd"
 
---

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1

Utilisez Kubectl pour appliquer le fichier manifeste :

$ kubectl apply -f mysql.yaml

Attendez quelques minutes pendant que l’opérateur MySQL provisionne vos pods. Utilisez Kubectl get pods commande 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     Running   0          2m
mysql-cluster-router-6b68f9b5cb-wbqm5   1/1     Running   0          2m

Définition d’une planification de sauvegarde

L’opérateur MySQL nécessite deux composants pour réussir à créer une sauvegarde :

  • UN calendrier 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. Elles sont créées en tant que ressources imbriquées dans votre InnoDBCluster objets. 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 les paramètres de votre base de données spec.backupSchedules champ. Chaque élément nécessite un schedule champ 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
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
   backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup

La backupProfileName Le champ fait référence au profil de sauvegarde à utiliser. Vous allez le créer à l’étape suivante.

Création de profils de sauvegarde

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

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          # ...

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

Stockage S3

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 qui contient un aws Fichier de configuration CLI avec vos informations d’identification.

Ajoutez le contenu suivant à s3-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: s3-secret
stringData:
  credentials: |
    [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 created

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

  • bucketName – Le nom du compartiment S3 dans lequel télécharger vos sauvegardes.
  • prefix – 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.
  • profile – Le nom du profil de configuration à utiliser dans le fichier d’informations d’identification. Celui-ci était fixé à default dans l’exemple ci-dessus.

Voici un exemple complet :

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          s3:
            bucketName: backups
            prefix: /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 informations d’identification OCI :

apiVersion: v1
kind: Secret
metadata:
  name: oci-secret
stringData:
  fingerprint: YOUR_OCI_FINGERPRINT
  passphrase: YOUR_OCI_PASSPHRASE
  privatekey: YOUR_OCI_RSA_PRIVATE_KEY
  region: us-ashburn-1
  tenancy: YOUR_OCI_TENANCY
  user: YOUR_OCI_USER

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

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          ociObjectStorage:
            bucketName: backups
            prefix: /mysql
            credentials: oci-secret

Modifier le bucketName et prefix champs pour définir l’emplacement de téléchargement dans votre compte OCI. La credentials Le champ doit faire référence au secret qui contient vos informations d’identification OCI.

Stockage de volumes Kubernetes

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

Créez d’abord un volume persistant et la revendication qui l’accompagne :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: backup-pv
spec:
  storageClassName: standard
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /tmp
 
---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: backup-pvc
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 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 storage.persistentVolumeClaim champ:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  backupSchedules:
    - name: hourly
      enabled: true
      schedule: "0 * * * *"
      backupProfileName: hourly-backup
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        storage:
          persistentVolumeClaim:
            claimName: backup-pvc

La demande de volume persistant créée précédemment est référencée par le claimName champ. 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 MySQL Shell dumpInstance utilitaire. 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 dumpOptions champ dans un profil de sauvegarde d’opérateur MySQL :

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster
spec:
  # ...
  backupProfiles:
    - name: hourly-backup
      dumpInstance:
        dumpOptions:
          chunking: false
          compression: gzip
        storage:
          # ...

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 créés précédemment à 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 spec.initDB champ sur votre InnoDBCluster objets. Dans cette strophe, utilisez le dump.storage objet pour référencer l’emplacement de sauvegarde que vous avez utilisé précédemment. Le format correspond à l’équivalent dumpInstance.storage champ dans les objets de profil de sauvegarde.

apiVersion: v1
kind: Secret
metadata:
  name: s3-secret
stringData:
  credentials: |
    [default]
    aws_access_key_id = YOUR_S3_ACCESS_KEY
    aws_secret_access_key = YOUR_S3_SECRET_KEY

---

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: mysql-cluster-recovered
spec:
  secretName: mysql-root-user
  instances: 3
  tlsUseSelfSigned: true
  router:
    instances: 1
  initDB:
    dump:
      storage:
        s3:
          bucketName: backups
          prefix: /mysql/mysql20221031220000
          config: s3-secret
          profile: default

L’application de ce fichier YAML créera un nouveau cluster de base de données initialisé avec le dumpInstance sortie dans le compartiment S3 spécifié. La prefix Le champ 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 path terrain au lieu de prefix.

Sommaire

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 compartiment 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 seraient 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.

★★★★★

Tremplin Numérique

La rédaction de Tremplin Numérique, agence web française. Nos auteurs vous fournissent quotidiennement et gratuitement les dernières actualités tech et digital, en France et dans le monde.