Classification de sauvegarde
Les méthodes de sauvegarde peuvent être divisées en différents types.
Selon différentes méthodes de sauvegarde, les sauvegardes peuvent être divisées en:
- Sauvegarde à chaud
La sauvegarde à chaud fait référence à la sauvegarde directe pendant le fonctionnement de la base de données et n'a aucun effet sur le fonctionnement de la base de données en cours d'exécution. Cette méthode est appelée Sauvegarde en ligne dans le manuel officiel de MySQL.
- Sauvegarde à froid
La sauvegarde à froid signifie que l'opération de sauvegarde a lieu lorsque la base de données est arrêtée. Ce type de sauvegarde est le plus simple - généralement seuls les fichiers physiques de la base de données concernés doivent être copiés. Cette méthode est appelée Offine Backup dans le manuel officiel de MySQL.
- Sauvegarde à chaud (sauvegarde à chaud)
La sauvegarde WarmBackup est également effectuée pendant l'exécution de la base de données, mais elle affectera le fonctionnement de la base de données actuelle, comme l'ajout d'un verrou de lecture global pour garantir la cohérence des données de sauvegarde.
Selon le contenu des fichiers après la sauvegarde, la sauvegarde peut être divisée en:
- Sauvegarde logique
Dans une base de données MySQL, la sauvegarde logique signifie que le contenu du fichier sauvegardé est lisible, généralement un fichier texte. Le contenu est généralement composé d'une instruction SQL ou des données réelles de la table. L'avantage de ce type de méthode est que vous pouvez observer le contenu du fichier exporté, et il convient généralement aux mises à niveau et aux migrations de bases de données. Mais son inconvénient est que le temps nécessaire à la récupération est souvent plus long.
- Sauvegarde de fichiers bruts
La sauvegarde de fichiers bruts fait référence à la copie des fichiers physiques de la base de données. Il peut s'agir d'une copie dans l'opération de base de données (comme ibbackup, xtrabackup et d'autres outils), ou il peut s'agir d'une copie directe de fichiers de données lorsque la base de données s'arrête de fonctionner. Le temps de récupération de ce type de sauvegarde est souvent beaucoup plus court que celui d'une sauvegarde logique.
Si elle est divisée en fonction du contenu de la base de données de sauvegarde, la sauvegarde peut être divisée en:
- Sauvegarde complète
Une sauvegarde complète fait référence à une sauvegarde complète de la base de données.
- Sauvegarde incrémentielle
La sauvegarde incrémentielle fait référence à la sauvegarde des données modifiées sur la base de la dernière sauvegarde complète.
- Sauvegarde du journal
La sauvegarde du journal se réfère principalement à la sauvegarde du journal binaire de la base de données MySQL. La restauration à un moment donné de la base de données est complétée par la refonte (relecture) du journal binaire d'une sauvegarde complète. Le principe de la réplication de la base de données MySQL (réplication) est asynchrone Le rétablissement du journal binaire est livré et appliqué à la base de données esclave (esclave / veille) en temps réel.
copie
Comment fonctionne la copie
- La réplication (réplication) est une solution haute disponibilité et haute performance fournie par la base de données MySQL, qui est généralement utilisée pour créer des applications à grande échelle. De manière générale, le principe de fonctionnement de la réplication est divisé en 3 étapes suivantes:
1) Le serveur maître (maître) enregistre les modifications de données dans le journal binaire (binlog).
2) Le serveur esclave (esclave) copie le journal binaire du serveur maître dans son propre journal de relais.
3) Refaites le journal dans le journal de relais du serveur et appliquez les modifications à sa propre base de données pour obtenir la cohérence finale des données.
Le principe de fonctionnement de la réplication n'est pas compliqué, il s'agit en fait d'une restauration d'une sauvegarde complète plus une sauvegarde binaire du journal. La différence est que l'opération de restauration de ce journal binaire est essentiellement en cours en temps réel. Il est particulièrement important de noter ici que la réplication n'est pas complètement synchronisée en temps réel, mais asynchrone en temps réel. Il y a un retard d'exécution entre les serveurs maître et esclave. Si la pression sur le serveur maître est importante, cela peut entraîner un délai plus long pour les serveurs maître et esclave. Le principe de fonctionnement de la copie est illustré sur la figure.
Le serveur esclave a 2 threads, l'un est le thread IO, qui est chargé de lire le journal binaire du serveur maître et de l'enregistrer en tant que journal de relais; l'autre est le thread SQL, qui réplique l'exécution du journal de relais.
Architecture de sauvegarde Snapshot + réplication
Supposons que l'application actuelle adopte une architecture de réplication maître-esclave et que le serveur esclave agit comme une sauvegarde. À ce moment, un DBA junior a effectué une opération incorrecte, telle que DROP DATABASE ou DROP TABLE, et le serveur esclave était également en cours d'exécution. Comment l'utilisateur peut-il récupérer à partir du serveur à ce moment?
Par conséquent, une meilleure méthode consiste à prendre un instantané de la partition où se trouve la base de données sur le serveur esclave, afin d'éviter l'impact d'une mauvaise opération sur la réplication. Lorsqu'une erreur se produit sur le serveur principal, il vous suffit de restaurer l'instantané à partir du serveur, puis d'effectuer une restauration à un moment donné en fonction du journal binaire. Par conséquent, la structure de sauvegarde de l'instantané + réplication est illustrée à la figure 8-5.
Il existe d'autres moyens d'ajuster la réplication, comme la réplication différée, ce qui signifie que la synchronisation à partir du serveur est activée par intermittence pour garantir un délai d'environ une heure.
L'optimisation des performances
- Choisissez le bon processeur
L'utilisateur doit d'abord connaître le type d'application de la base de données actuelle. D'une manière générale, il peut être divisé en deux catégories: OLTP (traitement des transactions en ligne) et OLAP (traitement analytique en ligne). Ce sont deux applications de base de données très différentes.
Le moteur de stockage InnoDB est généralement utilisé dans les applications de base de données OLTP. Les caractéristiques de cette application sont les suivantes:
1. Le nombre d'opérations utilisateur simultanées est important
2. Le temps de traitement des transactions est généralement relativement court
3. L'instruction de requête est relativement simple, et l'index est généralement utilisé
4. Il y a moins de requêtes complexes. On
constate que l'application de base de données OLTP elle-même n'a pas besoin de processeur très élevé, car les requêtes complexes peuvent nécessiter des opérations très gourmandes en ressources processeur telles que la comparaison, le tri, et connexion. Ces opérations sont utilisées dans les applications de base de données OLTP. Se produisent moins fréquemment. Par conséquent, on peut dire que OLAP est une opération gourmande en CPU, tandis qu'OLTP est une opération gourmande en E / S.
Dans la version actuelle de la base de données MySQL, une instruction de requête SQL ne peut fonctionner que dans un seul processeur et ne prend pas en charge le traitement multi-processeurs. Les opérations d'application de base de données OLTP sont généralement très simples, de sorte que l'impact sur les applications OLTP n'est pas grand. Cependant, plusieurs processeurs ou processeurs multicœurs sont toujours utiles pour gérer des requêtes simultanées volumineuses.
- L'importance de la mémoire
La taille de la mémoire est le reflet le plus direct des performances de la base de données. Grâce à l'introduction des chapitres précédents, nous avons appris que le moteur de stockage InnoDB met non seulement les données en cache, mais également les index, et les met en cache dans un grand pool de tampons, InnoDB Buffer Pool. Par conséquent, la taille de la mémoire affecte directement les performances de la base de données.
- L'impact des disques durs sur les performances de la base de données
- Configurer le RAID raisonnablement
L'idée de base du RAID (Redundant Array of Independent Disks) est de combiner plusieurs disques durs relativement bon marché en une matrice de disques, de sorte que les performances puissent atteindre ou dépasser celles d'un disque dur coûteux avec une capacité énorme.
- Le choix du système d'exploitation est également important
- L'impact des différents systèmes de fichiers sur la base de données
- Choisir le bon outil d'analyse comparative