Configurer MySQL sur Compute Engine

Compute Engine propose différents types d'instances et différentes options de stockage pour lire et écrire des données à partir de vos bases de données MySQL. Pour obtenir les meilleures performances et le meilleur coût pour vos charges de travail de base de données, nous vous recommandons d'exécuter vos applications sur des produits IaaS (Infrastructure as a Service) de nouvelle génération.

Les recommandations de configuration suivantes tiennent compte du fait que les charges de travail MySQL sont souvent utilisées dans des systèmes axés sur les lectures, tels que le traitement transactionnel en ligne (OLTP) ou la base de données qui sous-tend une application Web typique. Ils tiennent également compte des choix de configuration courants, tels que l'utilisation de la version 8.0 ou ultérieure de MySQL et du moteur de stockage InnoDB. Pour les charges de travail sensibles aux performances, vous devrez peut-être ajuster vos configurations en conséquence. Nous vous recommandons d'utiliser ce guide comme point de départ pour votre déploiement, puis de tester avec votre charge de travail réelle pour vérifier que votre configuration répond à vos besoins.

Choisir votre machine virtuelle (VM)

Pour les charges de travail MySQL, nous vous recommandons d'utiliser la dernière génération de familles de machines C et N, car elles incluent des formes qui fonctionnent bien pour la plupart des configurations MySQL pratiques. Pour en savoir plus sur ces séries de machines, consultez cet article de blogGoogle Cloud . Ces familles de machines utilisent Titanium et sont basées sur les générations récentes de processeurs Intel, AMD et Axion.

Se concentrer sur les performances

Pour les charges de travail sensibles aux performances, telles que les bases de données MySQL critiques pour l'entreprise, nous vous recommandons les dernières instances C4 et C4A, si elles sont disponibles dans votre région. Si vous n'y avez pas accès, les instances C3 et C3D offrent une approche similaire axée sur les performances.

Ces instances offrent la latence la plus faible et la plus cohérente pour les opérations liées au calcul, et incluent les fonctionnalités utiles suivantes pour les charges de travail axées sur les performances:

  • Contrôle des événements de maintenance de l'hôte avec une notification préalable
  • Contrôle de l'augmentation turbo à un seul cœur pour une meilleure constance des performances
  • Mise en réseau Tier_1 pour une bande passante réseau plus élevée

Si vous utilisez une instance C4A, C3 ou C3D, vous pouvez également utiliser des disques SSD locaux pour répondre à des exigences de performances spécifiques.

Optimiser pour les coûts

Pour les charges de travail pour lesquelles votre priorité est d'optimiser les coûts, telles que les bases de données MySQL avec des niveaux de trafic faibles à moyens ou les bases de données utilisées dans des environnements de test ou de développement, nous vous recommandons d'utiliser les dernières instances N4. Ces instances utilisent la gestion dynamique des ressources de nouvelle génération de Compute Engine pour optimiser votre coût total tout en maintenant des performances solides, sans les garanties solides offertes par les instances C4, C4A, C3 et C3D. Pour en savoir plus, consultez la page Gestion dynamique des ressources de nouvelle génération.

Configurer la taille de votre VM

Pour chaque VM que vous utilisez, il est important de choisir la taille de VM appropriée pour le niveau de performances MySQL que vous recherchez.

Si vous souhaitez obtenir de hautes performances en termes de transactions d'écriture par seconde (TPS), le principal facteur à prendre en compte est votre stockage en blocs. Pour en savoir plus, consultez la section Configurer le stockage en bloc, qui suit sur cette page.

Si vous souhaitez obtenir des performances élevées en termes de requêtes de lecture par seconde (RPS), nous vous recommandons vivement d'utiliser le pool de mémoire tampon basé sur la RAM de MySQL pour mettre en cache les données actives et réduire les accès au disque. Pour maximiser ces avantages, procédez comme suit:

  • Choisissez une taille de VM qui garantit que l'ensemble de travail, ou la quantité totale de données que votre base de données traite à la fois, s'intègre dans le pool de mémoire tampon.
  • Dimensionnez le pool de mémoire tampon pour qu'il utilise la majeure partie de la RAM de la VM.

Pour minimiser les coûts de dimensionnement de votre VM de cette manière, nous vous recommandons d'utiliser une VM avec un ratio élevé de RAM par rapport aux processeurs virtuels (vCPU), afin d'éviter de payer pour des vCPU que vous n'utilisez pas.

Pour obtenir un équilibre idéal pour la plupart des charges de travail MySQL, déterminez l'ensemble de travail de votre charge de travail, puis choisissez la plus petite forme d'instance highmem qui convient à cet ensemble de travail dans la RAM. Les formes d'instance highmem disposent d'environ 8 Go de RAM par vCPU. Vous disposez ainsi de suffisamment de mémoire pour mettre en cache un grand ensemble de travail, tout en conservant suffisamment de processeurs pour gérer une charge de requêtes élevée.

Pour les charges de travail comportant de grands ensembles de travail, mais des taux de requêtes faibles, en utilisant des instances N4, vous pouvez optimiser davantage vos coûts totaux en utilisant des types de machines personnalisés avec une mémoire étendue pour augmenter encore le ratio RAM/processeur virtuel.

Configurer la bande passante réseau de votre VM

Pour la plupart des cas d'utilisation de MySQL, vous pouvez vous en tenir aux limites de bande passante réseau par défaut pour votre instance. Si cela répond à vos besoins, vous n'avez pas besoin de passer à la mise en réseau Tier_1.

Configurer le stockage de blocs

Google Cloud Hyperdisk est la seule génération de stockage de blocs durable disponible pour les familles de VM Compute Engine récentes. Nous pensons que Hyperdisk Balanced est la meilleure option pour la grande majorité des charges de travail MySQL. Pour en savoir plus sur Hyperdisk, consultez la documentation Hyperdisk.

Google Cloud Hyperdisk

Hyperdisk équilibré propose les fonctionnalités suivantes:

  • Latence de disque dur SSD à faible coût
  • Des configurations hautes performances pour les applications qui en ont besoin
  • Durabilité supérieure à 99,999% pour vous protéger contre le risque de défaillance matérielle et de corruption silencieuse des données, qui est présent dans l'ensemble du secteur
  • Chiffrement de toutes les données Hyperdisk au repos à l'aide de clés de chiffrement gérées par Google ou par le client

Sélectionnez votre niveau de performances

Avec Hyperdisk Balanced, vous sélectionnez votre niveau de performances indépendamment de la taille de stockage du disque. Vous pouvez ainsi optimiser les performances de votre base de données tout en ne payant que les ressources d'entrée/sortie (E/S) dont votre charge de travail a besoin. Si le pool de tampons d'une base de données MySQL est plus volumineux que son ensemble de travail, il peut traiter presque toutes les requêtes de lecture à partir du pool de tampons, sans toucher au disque, lors des opérations à l'état stable.

Pour sélectionner un niveau de performances pour votre volume Hyperdisk, tenez compte de votre charge de travail d'écriture MySQL, en mettant l'accent sur les éléments suivants:

  • Accès aux journaux de redo InnoDB
  • Mises à jour ultérieures des fichiers et des index de données InnoDB

En dehors des opérations à l'état stable, les événements de maintenance de la base de données peuvent également entraîner des performances de disque plus élevées. La fréquence à laquelle cela se produit tend à augmenter avec la charge de travail d'écriture de votre base de données. Elle est donc plus probable dans des situations telles que la récupération post-plantage à l'aide de journaux de relecture ou d'un système de sauvegarde qui se copie en lisant toutes les modifications de la base de données depuis la dernière sauvegarde.

Dimensionner votre disque

Il existe trois stratégies courantes pour dimensionner les limites de performances de votre disque:

  1. Utiliser la configuration par défaut. Chaque disque est fourni avec au moins 3 000 IOPS (entrées/sorties par seconde) et 140 Mio/s de débit. Cela suffit pour les charges de travail MySQL de base et les volumes de démarrage du système d'exploitation (OS). Si votre cas d'utilisation dépasse cette limite, vous pouvez modifier les performances d'E/S provisionnées à la demande sans interrompre votre charge de travail.
  2. Mesurez votre utilisation actuelle. Si votre base de données s'exécute déjà dans un autre environnement, enregistrez ses IOPS et son débit disque avec une granularité d'une minute ou moins. Une fois que vous disposez d'une à deux semaines de données, afin que votre ensemble d'échantillons inclue des fluctuations de charge et des événements de maintenance normaux, sélectionnez une valeur de percentile élevée dans cet ensemble de données, puis ajoutez un petit tampon pour tenir compte de la croissance organique ou d'une utilisation inattendue.
  3. Évaluez vos besoins, puis modifiez-les plus tard. Si vous ne disposez pas d'une source de données existante, vous devrez peut-être estimer vos besoins en performances au départ, puis les ajuster après le déploiement. Nous vous recommandons de provisionner une valeur supérieure à celle dont vous pensez avoir besoin au départ, afin que votre charge de travail ne rencontre pas de goulots d'étranglement de performances, puis de réduire progressivement les performances provisionnées pour qu'elles correspondent à votre charge de travail.

Améliorer les performances de votre disque

Vous pouvez augmenter les performances de chaque disque Hyperdisk Balanced jusqu'à un maximum de 160 000 IOPS et 2 400 MBps de débit. La taille de votre VM permet de déterminer les limites de performances maximales d'Hyperdisk. Par conséquent, si vous souhaitez des performances Hyperdisk très élevées, vous devrez peut-être augmenter le nombre de cœurs de votre VM. Si vos charges de travail les plus exigeantes nécessitent des performances de disque supérieures à celles d'un seul disque Hyperdisk équilibré, vous pouvez utiliser l'une des méthodes suivantes pour associer plusieurs disques Hyperdisk équilibrés:

  • Passer à Hyperdisk Extreme
  • Utilisez un autre mécanisme logiciel de RAID (Redundant Array of Independent Disks), tel que mdadm.

À mesure que vous faites évoluer vos bases de données MySQL, vous pouvez augmenter de manière dynamique la capacité et les performances de vos disques sans temps d'arrêt. Cela améliore les performances des charges de travail de type OLAP (Online Analytical Processing) qui effectuent de grandes jointures complexes qui ne peuvent pas tenir dans la RAM et sont transférées sur le disque. Dans de rares cas, les charges de travail MySQL qui nécessitent une latence de stockage extrêmement faible et qui peuvent tolérer une perte de données peuvent stocker leur ensemble de données complet sur un SSD local. Vous pouvez également utiliser les solutions hybrides suivantes pour améliorer la latence de lecture et limiter la réduction de la durabilit��:

  • Reflétez votre ensemble de données entre un hyperdisque et un SSD local.
  • Utilisez un gestionnaire de volumes pour configurer un SSD local en tant que cache pour les données stockées sur un disque Hyperdisk sous-jacent.

Profiter des fonctionnalités supplémentaires de Hyperdisk

Hyperdisk vous offre également les fonctionnalités suivantes, qui peuvent renforcer ou simplifier les workflows de haute disponibilité et de reprise après sinistre sur site:

Pour en savoir plus sur la configuration de ces fonctionnalités avec MySQL pour Compute Engine, consultez la section Haute disponibilité qui suit sur cette page.

Disques SSD locaux

Certaines familles de machines Compute Engine vous permettent d'utiliser des SSD locaux au lieu d'Hyperdisk. Il ne s'agit pas d'un stockage durable, mais les charges de travail MySQL les utilisent souvent pour stocker des tablespaces temporaires.

Pour en savoir plus sur l'utilisation de disques SSD locaux pour faire évoluer les bases de données MySQL, consultez la section Redimensionnement dynamique des disques, qui suit sur cette page.

Fonctionnalités supplémentaires de Compute Engine

Vous pouvez utiliser les fonctionnalités Compute Engine suivantes pour optimiser votre déploiement MySQL.

Cloud Monitoring

Pour surveiller les performances et l'utilisation des services d'infrastructure de votre VM, utilisez la consoleGoogle Cloud . Sur la page Instances de VM, dans l'onglet Observabilité, vous pouvez surveiller les métriques liées aux performances, telles que l'utilisation du processeur et de la mémoire, la bande passante réseau et les performances provisionnées de vos instances. De même, sur la page Disks (Disques), dans l'onglet Observability (Observabilité), vous pouvez surveiller le débit et les IOPS de vos volumes de disque.

Pour personnaliser les métriques de performances que vous voyez, utilisez Cloud Monitoring pour créer des requêtes. Vous pouvez sélectionner les métriques de performances spécifiques que vous souhaitez afficher pour vos services d'infrastructure. Pour les métriques spécifiques à MySQL, Compute Engine propose un plug-in de charge de travail MySQL.

Bonnes pratiques pour configurer votre système d'exploitation

  • Utilisez un système de fichiers approprié. Google se concentre sur l'optimisation pour les systèmes de fichiers ext4 et XFS de Linux. Toutefois, la plupart des systèmes de fichiers sont adaptés à MySQL.
  • Désactivez les pages de mémoire de grande taille transparentes (THP) dans la configuration de votre système d'exploitation de base. Pour savoir comment désactiver THP, consultez la documentation THP.
  • Si vous utilisez Linux, utilisez les options relatime et lazytime pour la configuration de l'installation du système de fichiers. Cela réduit les coûts liés aux performances associés à la mise à jour des valeurs atime, mtime et ctime sur les fichiers lorsqu'ils sont lus, modifiés ou que leurs métadonnées sont modifiées.

Bonnes pratiques de configuration de MySQL

Nous vous recommandons d'utiliser les paramètres de configuration suivants pour MySQL.

  • Utilisez une version récente de MySQL. Google se concentre sur l'optimisation pour MySQL 8.0 et les versions ultérieures.

  • Augmentez la taille du pool de mémoire tampon. MySQL utilise son pool de mémoire tampon pour améliorer les performances de lecture en mettant en cache les données dans la RAM, ce qui réduit les accès au disque. Par défaut, la taille du pool de mémoire tampon de MySQL est de 128 Mo, ce qui est trop faible pour la plupart des cas d'utilisation pratiques. Nous vous recommandons d'augmenter la taille de innodb_buffer_pool_size pour qu'elle soit supérieure à la taille du ensemble de travail auquel votre application accède dans la base de données. Cette procédure comprend généralement les étapes suivantes:

    1. Mesurez ou estimez la taille de votre ensemble de travail sur une copie en cours d'exécution de votre instance MySQL.
    2. Choisissez une taille et une forme de machine virtuelle (VM) avec suffisamment de RAM pour accueillir cet ensemble de travail.
    3. Configurez la taille du pool de mémoire tampon sur la VM pour qu'elle occupe la majeure partie de la RAM disponible.

  • Activez le tampon d'écriture en double. MySQL dispose d'un tampon d'écriture double qui permet de se protéger contre les écritures déchirées, un mode de défaillance dans lequel une écriture couvrant plusieurs blocs sur le disque ne peut être validée que partiellement si une défaillance matérielle ou électrique se produit au milieu de l'écriture. Pour bénéficier de cette protection, activez innodb_doublewrite.

  • Définissez la valeur de innodb_flush_log_at_trx_commit sur 1. Cela garantit que les transactions d'écriture sont durables sur le disque lorsqu'elles sont validées.

  • Pour réduire les coûts liés aux performances, spécifiez une valeur pour innodb_flush_method. Pour les versions MySQL 8.0.14 et ultérieures, définissez la valeur de innodb_flush_method sur O_DIRECT_NO_FSYNC, qui est optimale, mais uniquement présente dans ces versions. Pour les versions de MySQL antérieures à la version 8.0.14, définissez la valeur de innodb_flush_method sur O_DIRECT.

  • Dans les scénarios de réplication haute disponibilité, définissez la valeur de sync_binlog de l'instance de base de données principale sur 1. MySQL utilise son journal binaire pour communiquer les modifications de la base de données principale à la base de données secondaire. Cela garantit que les journaux binaires sont validés au moment de la validation de la transaction, avec le délai de réplication et l'objectif de point de récupération (RPO) les plus faibles possibles entre les bases de données.

  • Lorsque vous utilisez MySQL sur les familles de machines de la série C, activez innodb_numa_interleave. Cela garantit que le pool de tampons de MySQL peut tirer parti des stratégies d'accès à la mémoire non uniforme (NUMA).

Quand désactiver le tampon de double écriture

Le tampon d'écriture double de MySQL, qui protège contre les écritures déchirées, présente un surcoût de performances pouvant atteindre 25% pour les transactions d'écriture MySQL, ce qui peut potentiellement avoir un impact sur la latence des transactions. Google Cloud Hyperdisk offre également une protection contre les écritures déchirées. Par conséquent, si vous utilisez MySQL pour écrire directement sur un système de fichiers ext4 exécuté sur Hyperdisk, vous pouvez désactiver en toute sécurité le tampon d'écriture en double.

Toutefois, pour que la protection contre les écritures déchirées d'Hyperdisk soit efficace, vous devez configurer le système de fichiers et d'autres couches logicielles intermédiaires entre la base de données et le disque afin d'éviter d'introduire des écritures déchirées au-dessus de la couche de disque. La liste suivante fournit des exemples de configurations susceptibles d'introduire des écritures déchirées au-dessus de la couche Hyperdisk:

  • Exécuter votre instance MySQL dans des conteneurs, tels que Google Kubernetes Engine ou Kubernetes auto-hébergé.
  • Stocker vos fichiers MySQL sur un système de fichiers XFS, qui n'est pas compatible avec des tailles de bloc suffisamment importantes dans la plupart des configurations du noyau Linux.
  • Stocker vos fichiers MySQL sur une configuration RAID (Redundant Array of Independent Disks) qui provoque le striping de disque, comme mdadm pour Linux ou Storage Spaces et Storage Spaces Direct pour Windows.
  • Stocker vos fichiers MySQL sur un gestionnaire de volumes, tel que le gestionnaire de volumes logiques (LVM) pour Linux ou Storage Spaces et Storage Spaces Direct pour Windows.

  • Stocker vos fichiers MySQL sur un hyperdisque avec un disque SSD local configuré en tant que cache, par exemple en utilisant lvmcache, dm-cache ou bcache pour Linux ou Storage Spaces pour Windows.

  • Exécuter votre instance MySQL dans une VM à l'aide de la virtualisation imbriquée.

Bien que vous puissiez configurer les configurations précédentes pour qu'elles n'introduisent pas d'écritures déchirées, nous vous déconseillons de désactiver le tampon d'écriture en double lorsque vous les utilisez, car il est difficile de vérifier qu'une configuration donnée est sécurisée.

(Facultatif) Désactiver le tampon d'écriture en double

Pour désactiver le tampon d'écriture en double, procédez comme suit:

  1. Sur le système de fichiers ext4, vous devez activer la fonctionnalité bigalloc et configurer la taille de cluster du système de fichiers sur 16 Ko, ou une puissance de 2 supérieure à 16 Ko. Cela garantit que les écritures de MySQL ne seront pas divisées en I/O distinctes par le système de fichiers avant d'être émises vers Hyperdisk. Ne pas augmenter la limite ou utiliser une valeur inférieure à 16 Ko ne protège pas contre les écritures déchirées. Par exemple, avec une taille de cluster de 16 Ko, cette valeur est configurée au moment de la création du système de fichiers:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. Désactivez innodb_doublewrite et définissez innodb_flush_method sur O_DIRECT ou O_DIRECT_NO_FSYNC (selon votre version de MySQL, comme décrit ci-dessus).

Configurer la haute disponibilité (HA) et une solution de sauvegarde

Nous vous recommandons vivement de protéger toutes vos charges de travail MySQL critiques en configurant des solutions de haute disponibilité (HA) et de sauvegarde. Pour la haute disponibilité et la sauvegarde, les facteurs suivants sont les plus importants:

Les solutions de haute disponibilité ciblent généralement un RTO et un RPO proches de zéro, mais ne protègent que contre les défaillances de l'infrastructure. Les solutions de sauvegarde ciblent des périodes de RTO et de RPO plus longues, mais couvrent un plus grand nombre de scénarios de défaillance, par exemple:

  • Suppression accidentelle de données
  • Attaques de rançongiciels
  • Catastrophes naturelles

Configurer la haute disponibilité (HA)

Les fonctionnalités de haute disponibilité utilisent la redondance de stockage et de calcul pour s'assurer que votre base de données MySQL réduit les temps d'arrêt en cas de défaillance ou d'indisponibilité de l'hôte, ce qui permet aux applications clientes d'accéder à ses données même lorsqu'une instance ou une zone est indisponible.

MySQL permet la réplication dans les modes suivants:

  • Mode asynchrone En mode asynchrone, le principal confirme les transactions d'écriture dès qu'elles sont validées localement. Par conséquent, en cas d'indisponibilité du principal, une petite quantité de données écrites récemment peut être perdue lors du basculement, car la RPO est proche de zéro, mais pas tout à fait.
  • Mode semi-synchrone En mode semi-synchrone, l'instance principale attend de confirmer la transaction jusqu'à ce qu'un nombre configurable d'instances dupliquées ait confirmé la réception de la transaction. Cela augmente considérablement la probabilité qu'aucune perte de données ne se produise lors d'un basculement non planifié, car le RPO est effectivement nul.

Pour les deux modes, le RTO est déterminé par la rapidité avec laquelle les vérifications d'état effectuent les opérations suivantes:

  1. Identifiez une instance défaillante.
  2. Déclenchez le basculement.
  3. Notifiez aux clients que l'instance de basculement est désormais la principale, à l'aide du système de noms de domaine (DNS) ou d'un autre moyen d'identifier le serveur de base de données.

Dans les deux modes de réplication, vous devez disposer d'une instance de basculement vers laquelle effectuer la réplication. Vous pouvez trouver cette instance dans l'un des emplacements suivants:

  • Dans la même zone que l'instance principale
  • Une zone différente de celle de l'instance principale
  • dans une région différente de celle de l'instance principale ;

Pour maintenir une haute disponibilité même en cas de pannes zonales, nous vous recommandons la configuration suivante:

  • Placez vos instances principale et de basculement dans des zones différentes,qu'elles se trouvent ou non dans la même région.
  • Utilisez la réplication asynchrone. En effet, si vous utilisez la réplication semi-synchrone, placer vos instances principales et de basculement dans des zones distinctes peut entraîner une latence élevée pour les validations de transactions d'écriture.
  • Si vous avez besoin d'un RPO nul, utilisez Hyperdisk équilibré à haute disponibilité, qui vous permet de répliquer de manière synchrone un disque sur deux zones de la même région. Pour en savoir plus, consultez le guide de Google sur la fourniture de services à haute disponibilité à l'aide de la haute disponibilité Hyperdisk. Lorsque vous configurez la haute disponibilité équilibrée Hyperdisk, nous vous recommandons d'intégrer des groupes d'instances gérés avec état pour diagnostiquer les problèmes de santé des instances et automatiser les actions de récupération.

Configurer un plan de sauvegarde et de résilience des données

Les plans de sauvegarde et de résilience des données permettent d'éviter la perte de données en cas de défaillance, comme la suppression accidentelle de données, les attaques par rançongiciel et les catastrophes naturelles. Vous pouvez également les utiliser comme stockage à froid pour répondre aux exigences de conformité et d'audit. Pour MySQL, il existe de nombreuses méthodologies de sauvegarde, certaines opérant au niveau de la base de données et d'autres au niveau du volume de stockage. Lorsque vous sélectionnez une méthodologie, vous devez principalement tenir compte de vos exigences en termes de RTO et de RPO.

Sauvegarder au niveau de la base de données

Pour les sauvegardes au niveau de la base de données, envisagez d'utiliser les options suivantes fournies par MySQL:

  • Sauvegardes incrémentielles basées sur la journalisation binaire,qui créent des vidages de données logiques. Exemples :
  • Outils qui gèrent le processus de sauvegarde à votre place,tels que MySQL Enterprise Backup.

Pour en savoir plus sur les options de sauvegarde au niveau de la base de données de MySQL, consultez la section Sauvegarde et récupération dans la documentation MySQL.

Pour chacune de ces options, vous devez disposer d'un système de stockage secondaire dans lequel copier les données de sauvegarde. Nous vous recommandons d'utiliser les outils suivants:

Utiliser Hyperdisk pour créer des instantanés et des clones au niveau du stockage

Pour les sauvegardes au niveau du stockage, nous vous recommandons d'utiliser les produits Hyperdisk pour créer des instantanés, des clones et d'autres vues ponctuelles de votre base de données MySQL. Le RPO de cette approche dépend de la fréquence à laquelle vous prenez des instantanés de votre base de données, et le RTO dépend de la solution spécifique que vous utilisez.

Si la récupération rapide est importante pour vous et que vous n'avez besoin que d'une couverture de sauvegarde dans une zone, nous vous recommandons d'utiliser les instantanés instantanés d'Hyperdisk. Les instantanés immédiats capturent les données de manière incrémentielle à un moment spécifique et peuvent les restaurer rapidement sur un nouveau volume Hyperdisk via le clonage de disque, ce qui offre un RTO de quelques minutes. Ils vous permettent de récupérer des données lorsque le contenu d'un disque a été écrasé, supprimé ou corrompu, et qu'il est disponible en local dans la même zone ou région que le disque source. Pour en savoir plus, consultez la section À propos des instantanés immédiats.

Pour les scénarios de reprise après sinistre, dans lesquels les données doivent être stockées avec une redondance plus élevée que le disque d'origine et dans un emplacement distinct pour s'assurer qu'un seul sinistre n'affecte pas tous les réplicas des données, nous vous recommandons d'utiliser les archives et les instantanés de disque standards d'Hyperdisk. Les instantanés d'archive et les instantanés de disque standards créent une copie des données du disque à un moment donné et les stockent avec une redondance élevée dans un format immuable. Lorsque vous créez plusieurs instantanés d'un disque, par exemple avec une programmation d'instantanés, Hyperdisk ne stocke que les modifications incrémentielles. Les instantanés de disque d'archive et standards sont adaptés si vous pouvez tolérer un RTO plus élevé, car la copie des données du stockage d'instantanés vers le stockage de la VM peut entraîner une restauration plus longue. Pour en savoir plus, consultez la section Créer des instantanés d'archive et des instantanés de disque standards.

Les instantanés instantanés, d'archive et standards d'Hyperdisk sont tous compatibles avec les plantages sur un seul disque. Cela signifie que lorsque vous effectuez une restauration à partir d'un instantané, votre base de données MySQL doit exécuter les étapes de récupération InnoDB normales pour rétablir ses journaux et ses fichiers de données à un état cohérent. En fonction de la configuration de votre journal de relecture InnoDB, cela peut prolonger le RTO. Les modèles suivants peuvent compliquer davantage vos efforts pour créer un instantané de base de données cohérent:

  • Vos fichiers de base de données MySQL sont répartis sur plusieurs volumes.
  • Vous utilisez des utilitaires RAID logiciels Linux, tels que mdadm.
  • Vous avez séparé les emplacements de stockage configurés de MySQL sur des systèmes de fichiers sur différents disques.

Pour créer un instantané qui ne nécessite pas de récupération après une restauration d'instantané, procédez comme suit:

  1. Verrouillez temporairement l'accès en écriture à la base de données MySQL.
  2. Videz tous les tampons en cours d'exécution sur le disque à l'aide des commandes LOCK INSTANCE FOR BACKUP et FLUSH TABLES WITH READ LOCK.
  3. Lancez les opérations d'instantané.

  4. Pour les scénarios multidisques, après avoir effacé au niveau de MySQL, exécutez les commandes sync et fsfreeze sur le serveur pour effacer toutes les écritures en cours sur le disque et suspendre les nouvelles écritures entrantes au niveau du système de fichiers.

Une fois que vous avez capturé l'instantané initial de votre base de données, vous n'avez plus besoin de verrouiller votre disque, car Hyperdisk capture rapidement la vue à un moment donné, puis peut traiter de manière asynchrone toutes les étapes de copie de stockage ultérieures. Si vous avez besoin de ces étapes pour la cohérence des instantanés et que vous souhaitez supprimer cet impact en écriture sur la base de données principale, vous pouvez également exécuter une sauvegarde sur un réplica de base de données plutôt que sur la base de données principale.

Étape suivante