Configurer MySQL sur Compute Engine

Compute Engine propose différents types d'instances et d'options de stockage pour lire et écrire des données à partir de vos bases de données MySQL. Pour garantir 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 charges de travail sur des produits d'infrastructure en tant que service (IaaS) 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 à forte lecture, 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, comme 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. Nous vous recommandons d'utiliser ce guide comme point de départ pour votre déploiement, puis de tester 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 une présentation de ces séries de machines, consultez cet article de blog.Google Cloud Ces familles de machines utilisent Titanium et sont basées sur les dernières générations 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'activité, 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 des performances similaires.

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

  • Contrôlez les événements de maintenance de l'hôte grâce à une notification avancée.
  • Contrôle du turbo monocœur pour une meilleure cohérence 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 les coûts

Pour les charges de travail où votre priorité principale est d'optimiser les coûts, comme 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 Gestion dynamique des ressources de nouvelle génération.

Configurer la taille de votre VM

Pour toute VM que vous utilisez, il est important de choisir la taille de VM adaptée au niveau de performances MySQL que vous souhaitez atteindre.

Si vous recherchez des performances élevées en termes de transactions d'écriture par seconde (TPS), le principal facteur à prendre en compte est votre stockage de blocs. Pour en savoir plus, consultez la section Configurer le stockage par blocs sur cette page.

Si vous recherchez des performances élevées en termes de requêtes de lecture par seconde (QPS), 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 fréquemment consultées et réduire les accès au disque. Pour profiter pleinement de 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 utiliser la majeure partie de la RAM de la VM.

Pour minimiser le coût du dimensionnement de votre VM de cette manière, nous vous recommandons d'utiliser une VM avec un rapport RAM/processeurs virtuels (vCPU) élevé 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 correspond à cet ensemble de travail dans la RAM. Les formes d'instance highmem disposent d'environ 8 Go de RAM par processeur virtuel. Cela vous donne suffisamment de mémoire pour mettre en cache un grand ensemble de travail, tout en conservant suffisamment de processeur pour gérer une charge de requêtes élevée.

Pour les charges de travail avec de grands ensembles de travail, mais de faibles taux de requêtes, vous pouvez optimiser davantage votre coût total en utilisant des types de machines personnalisés avec 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 qu'Hyperdisk Balanced est la solution la mieux adaptée à la grande majorité des charges de travail MySQL. Pour en savoir plus sur Hyperdisk, consultez la documentation Hyperdisk.

Google Cloud Hyperdisk

Hyperdisk équilibré offre les fonctionnalités suivantes :

  • Latence des disques SSD à faible coût
  • 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 touche l'ensemble du secteur
  • Chiffrement de toutes les données Hyperdisk au repos avec des 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 mémoire tampon d'une base de données MySQL est plus grand que son ensemble de travail, il peut, lors d'opérations en régime permanent, répondre à presque toutes les requêtes de lecture à partir du pool de mémoire tampon, sans accéder au disque.

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

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

En dehors des opérations en régime permanent, les événements de maintenance de la base de données peuvent également entraîner des performances de disque plus irrégulières. La fréquence à laquelle cela se produit a tendance à évoluer en fonction de la charge de travail d'écriture de votre base de données. Cela est donc plus probable dans des situations telles que la récupération après un plantage à l'aide de journaux de rétablissement ou un système de sauvegarde qui se copie en lisant toutes les modifications apportées à 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. Utilisez la configuration par défaut. Chaque disque est fourni avec au moins 3 000 entrées/sorties par seconde (IOPS) 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. Si votre cas d'utilisation dépasse cette limite, vous pouvez modifier les performances d'E/S provisionnées à la demande sans arrêter votre charge de travail.
  2. Mesurez votre utilisation existante. Si votre base de données est déjà en cours d'exécution dans un autre environnement, enregistrez ses IOPS et son débit de disque avec une précision d'une minute ou moins. Une fois que vous disposez de données sur une à deux semaines, de sorte que votre ensemble d'échantillons inclue certaines fluctuations de charge et des événements de maintenance normaux, sélectionnez une valeur de centile élevé dans cet ensemble de données et ajoutez une petite marge pour tenir compte de la croissance naturelle ou d'une utilisation inattendue.
  3. Estimez vos besoins, puis modifiez-les ultérieurement. Si vous ne disposez pas de source de données existante, vous devrez peut-être estimer vos besoins en termes de performances au départ, puis les ajuster davantage après le déploiement. Nous vous recommandons de provisionner une valeur plus élevée que celle dont vous pensez avoir besoin au départ, afin que votre charge de travail ne rencontre pas de goulots d'étranglement au niveau des performances. Vous pourrez ensuite réduire les performances provisionnées pour les adapter à 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 obtenir 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 qu'un seul disque Hyperdisk équilibré peut fournir, vous pouvez utiliser l'une des méthodes suivantes pour agréger plusieurs disques Hyperdisk équilibrés :

  • Passer à Hyperdisk Extreme
  • Utilisez un autre mécanisme de redondance logicielle 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 permet d'améliorer les performances des charges de travail de type traitement analytique en ligne (OLAP) qui effectuent des jointures complexes volumineuses qui ne peuvent pas tenir dans la RAM et qui sont déversées sur le disque. Dans de rares cas, les charges de travail MySQL qui nécessitent une latence de stockage extrêmement faible et peuvent tolérer une perte de données peuvent stocker l'ensemble de leur ensemble de données 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é :

  • Miroitez 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 d'Hyperdisk

Hyperdisk vous offre également les fonctionnalités suivantes, qui peuvent augmenter 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é ci-dessous.

Disques SSD locaux

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

Pour savoir comment utiliser les disques SSD locaux pour mettre à l'échelle les bases de données MySQL, consultez la section Redimensionnement dynamique des disques 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 de votre VM et l'utilisation des services d'infrastructure, 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 Disques, dans l'onglet 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 des systèmes de fichiers ext4 et XFS de Linux. Toutefois, la plupart des systèmes de fichiers conviennent à l'utilisation avec MySQL.
  • Désactivez les pages énormes 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 du montage du système de fichiers. Cela réduit les frais généraux de 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 pour configurer 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 de MySQL version 8.0 et 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 Mio, ce qui est trop petit 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 à celle de l'ensemble de travail auquel votre application accède dans la base de données. Cela se fait généralement en plusieurs étapes :

    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 s'adapter à cet ensemble de travail.
    3. Configurez la taille du pool de mémoire tampon sur la VM pour qu'elle occupe la majorité de la RAM disponible.

  • Activez le tampon de double écriture. MySQL dispose d'un tampon de double écriture qui permet de se protéger contre les écritures tronquées, un mode de défaillance dans lequel une écriture qui couvre plusieurs blocs sur le disque peut n'être que partiellement validée si une défaillance matérielle ou de l'alimentation 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 la surcharge de performances, spécifiez une valeur pour innodb_flush_method. Pour MySQL version 8.0.14 et les versions ultérieures, définissez la valeur de innodb_flush_method sur O_DIRECT_NO_FSYNC, qui est optimale, mais n'est présente que 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 apportées à 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écalage de réplication et l'objectif de point de récupération (RPO, Recovery Point Objective) les plus faibles possibles entre les bases de données.

  • Lorsque vous utilisez MySQL sur des familles de machines de la série C, activez innodb_numa_interleave. Cela permet au pool de mémoire tampon de MySQL de tirer parti des stratégies d'accès mémoire non uniforme (NUMA).

Quand désactiver le tampon de double écriture

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

Toutefois, pour que la protection contre les écritures partielles d'Hyperdisk soit efficace, vous devez configurer le système de fichiers et les autres couches logicielles intermédiaires entre la base de données et le disque afin d'éviter d'introduire des écritures partielles au-dessus de la couche de disque. La liste suivante fournit des exemples de configurations susceptibles d'introduire des écritures fragmenté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é.
  • Vous stockez vos fichiers MySQL sur un système de fichiers XFS, qui ne prend pas en charge des tailles de blocs suffisamment grandes dans la plupart des configurations du noyau Linux.
  • Stockez vos fichiers MySQL sur une configuration RAID (Redundant Array of Independent Disks) qui provoque le striping de disque, comme mdadm pour Linux ou Espaces de stockage et Espaces de stockage Direct pour Windows.
  • Stockez vos fichiers MySQL sur un gestionnaire de volumes, tel que Logical Volume Manager (LVM) pour Linux ou Espaces de stockage et Espaces de stockage Direct pour Windows.

  • Stockez vos fichiers MySQL sur Hyperdisk avec un disque SSD local configuré comme 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 de sorte qu'elles n'introduisent pas d'écritures fragmentées, nous vous déconseillons de désactiver le tampon de double écriture lorsque vous les utilisez, en raison de la difficulté à valider qu'une configuration donnée est sûre.

(Facultatif) Désactiver le tampon de double écriture

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

  1. Sur le système de fichiers ext4, vous devez activer la fonctionnalité bigalloc et configurer la taille du cluster du système de fichiers sur 16 Kio, ou sur un multiple de 16 Kio qui est une puissance de 2 supérieure. Cela garantit que les écritures de MySQL ne seront pas divisées en IO distinctes par le système de fichiers avant d'être émises sur Hyperdisk. Si vous ne parvenez pas à augmenter la limite ou si vous utilisez une valeur inférieure à 16 Kio, vous ne serez pas protégé contre les écritures partielles. Voici un exemple avec une taille de cluster de 16 Kio, configurée lors 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 celles-ci. Pour la haute disponibilité et la sauvegarde, les facteurs suivants sont les plus importants :

Les solutions de haute disponibilité visent généralement des valeurs de RTO et RPO proches de zéro, mais ne protègent que contre les défaillances d'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, tels que les suivants :

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

Configurer la haute disponibilité (HA)

Les fonctionnalités de haute disponibilité utilisent la redondance du stockage et du calcul pour garantir que votre base de données MySQL présente des temps d'arrêt réduits en cas de défaillance ou d'indisponibilité de l'hôte. Les applications clientes peuvent ainsi 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 nœud principal confirme les transactions d'écriture dès qu'elles sont validées localement. Par conséquent, en cas d'indisponibilité du nœud principal, une petite quantité de données récemment écrites peut être perdue lors du basculement, car le RPO est proche de zéro, mais pas tout à fait.
  • Mode semi-synchrone : En mode semi-synchrone, l'instance principale attend pour accuser réception de la transaction qu'un nombre configurable d'instances répliquées aient accusé réception de la transaction. Cela augmente considérablement les chances qu'aucune perte de données ne se produise lors d'un basculement imprévu, car le RPO est effectivement nul.

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

  1. Identifiez une instance défaillante.
  2. Déclenchez le basculement.
  3. Informez les clients que l'instance de basculement est désormais l'instance principale, en utilisant le système de noms de domaine (DNS) ou 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 à l'un des emplacements suivants :

  • La même zone que celle de l'instance principale
  • Une autre zone de la région où se trouve 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 panne zonale, nous vous recommandons la configuration suivante :

  • Placez vos instances principale et de secours 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 semisynchrone, le fait de placer vos instances principale et de basculement dans des zones distinctes peut entraîner une latence élevée pour les commits 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 Google sur la fourniture de services à haute disponibilité à l'aide d'Hyperdisk à haute disponibilité. Lorsque vous configurez Hyperdisk équilibré à haute disponibilité, nous vous recommandons de l'intégrer aux groupes d'instances gérés avec état pour diagnostiquer les problèmes d'état 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 d'échec, 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, vous avez le choix entre de nombreuses méthodologies de sauvegarde, dont certaines agissent 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. Voici quelques exemples :
  • Outils qui gèrent le processus de sauvegarde pour vous,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 Sauvegarde et récupération dans la documentation MySQL.

Pour l'une de ces options, vous devez disposer d'un système de stockage secondaire pour y copier les données de sauvegarde. Nous vous recommandons les outils suivants :

Utiliser Hyperdisk pour créer des instantanés et cloner 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, cloner et capturer une vue ponctuelle 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 d'une couverture de sauvegarde que dans une zone, nous vous recommandons d'utiliser les instantanés Hyperdisk. Les instantanés immédiats capturent les données à un moment précis de manière incrémentielle et peuvent restaurer rapidement les données sur un nouveau volume Hyperdisk grâce au clonage de disque, ce qui permet d'obtenir 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. Ils sont disponibles localement dans la même zone ou région que le disque source. Pour en savoir plus, consultez À 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 toutes les répliques des données, nous vous recommandons d'utiliser les instantanés de disque standard et d'archive d'Hyperdisk. Les instantanés de disque d'archive et standards créent une copie des données du disque à un moment donné et la stockent avec une haute redondance 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 un bon choix si vous pouvez tolérer un RTO plus élevé, car la copie des données du stockage des instantanés vers le stockage des VM peut prendre plus de temps à restaurer. Pour en savoir plus, consultez Créer des instantanés de disque d'archive et standards.

Les instantanés immédiats Hyperdisk, ainsi que ses instantanés d'archive et standards, sont cohérents en cas d'arrêt brutal sur un même disque. Cela signifie que lorsque vous restaurez une base de données MySQL à partir d'un instantané, elle doit exécuter les étapes de récupération InnoDB normales pour rétablir la cohérence de ses journaux et fichiers de données. En fonction de la configuration de votre journal redo InnoDB, cela peut allonger le délai de reprise. 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 dans 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, 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 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. Dans les scénarios à plusieurs disques, une fois que vous avez vidé le cache au niveau de MySQL, exécutez les commandes sync et fsfreeze sur le serveur pour vider 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 précis, 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 sur l'écriture dans la base de données principale, vous pouvez également exécuter la sauvegarde sur une réplique de base de données plutôt que sur la base de données principale.

Étapes suivantes