Solutions de migration MySQL dans différentes circonstances (recommandé)

1.Pourquoi la migration

MySQL La migration est une tâche de maintenance quotidienne de DBA. La migration, dans son sens originel, n'est rien d'autre que la suppression d'un objet réellement existant pour garantir l'intégrité et la continuité de l'objet. Tout comme sur la douce plage, deux enfants innocents ont déplacé un tas de sable vers d'autres endroits pour construire le château de leur cœur.

Dans l'environnement de production, un travail de migration est requis dans les situations suivantes :

• Espace disque insuffisant. Par exemple, dans certains projets anciens, les modèles sélectionnés ne conviennent pas forcément à la base de données. Au fil du temps, les disques durs risquent de devenir rares

• Des goulots d'étranglement commerciaux se produiront. Par exemple, dans le projet, une seule machine est utilisée pour assurer tous les services de lecture et d'écriture, ce qui augmente la pression sur l'entreprise et la dépasse. Si la pression IO est dans une plage acceptable, une solution de séparation lecture-écriture sera adoptée

• La machine a un goulot d'étranglement ; Les principaux goulots d'étranglement de la machine sont les capacités d'E/S du disque, la mémoire et le processeur. En plus d'optimiser les goulots d'étranglement, la migration est une bonne solution

• transformation de projet. Les bases de données de certains projets s'étendent sur des salles informatiques, et des nœuds peuvent être ajoutés dans différentes salles informatiques, ou des machines peuvent être déplacées d'une salle informatique à une autre. Autre exemple, si différentes entreprises partagent le même serveur, une migration sera effectuée afin de soulager la pression sur le serveur et de faciliter la maintenance.

En un mot, la migration est un dernier recours. Le but de la mise en œuvre du travail de migration est d’assurer le bon fonctionnement et la continuité de l’entreprise.

2. Aperçu du plan de migration MySQL

La migration MySQL n'est rien de plus que de contourner les données, puis de continuer à s'étendre, ce n'est rien de plus qu'une sauvegarde et une restauration dans le but d'assurer la fonctionnement fluide et continu de l’entreprise. Le problème est de savoir comment effectuer une sauvegarde et une restauration rapidement et en toute sécurité.

D'une part, la sauvegarde. Il existe une sauvegarde pour le nœud esclave ou le nœud de secours de chaque nœud maître. Cette sauvegarde peut être une sauvegarde complète ou une sauvegarde incrémentielle. La méthode de sauvegarde en ligne peut consister à utiliser mysqldump, xtrabackup ou mydumper. Pour la sauvegarde de bases de données de petite capacité (moins de 10 Go), nous pouvons utiliser mysqldump. Mais pour les bases de données de grande capacité (niveau centaines de Go ou To), nous ne pouvons pas utiliser la sauvegarde mysqldump. D'une part, des verrous seront générés, d'autre part, cela prendra trop de temps. Dans ce cas, vous pouvez choisir xtrabackup ou copier directement le répertoire de données. Copiez directement la méthode du répertoire de données. Vous pouvez utiliser rsync pour transférer entre différentes machines. La consommation de temps dépend du réseau. En utilisant xtrabackup, le temps est principalement consacré à la sauvegarde et à la transmission réseau. Si vous disposez d'un fichier de sauvegarde de bibliothèque complet ou spécifié, c'est le meilleur moyen d'obtenir la sauvegarde. Si la base de données de secours peut tolérer l'arrêt du service, la copie directe du répertoire de données est la méthode la plus rapide. Si la base de données de secours ne permet pas d'arrêter le service, on peut utiliser xtrabackup (qui ne verrouille pas la table InnoDB), qui est le meilleur compromis pour réaliser la sauvegarde.

Par contre, la récupération. Pour les fichiers de sauvegarde de bases de données de petite capacité (moins de 10 Go), nous pouvons les importer directement. Pour la récupération de bases de données de grande capacité (niveau de centaines de Go ou de To), la récupération n'est pas difficile après avoir transféré les fichiers de sauvegarde sur la machine locale. Pour les méthodes de récupération spécifiques, veuillez vous référer à la section 4.

3. Migration MySQL pratique

Après avoir compris pourquoi nous devons migrer et comment le faire, examinons le fonctionnement de l'environnement de production. Différents scénarios d'application ont des solutions différentes.

Avant de lire le combat réel spécifique, il est supposé que le lecteur a l'accord suivant :

• Afin de protéger la confidentialité, l'adresse IP du serveur et d'autres informations contenues dans ce l'article a été traité ;

• Si le serveur est dans la même salle informatique, utilisez le segment D de l'IP du serveur au lieu de l'IP spécifique, veuillez vous référer au <.>Architecture schéma ;

• Si le serveur est dans différentes salles informatiques, utilisez les segments C et D de l'IP du serveur au lieu du serveur. Veuillez vous référer au schéma d'architecture pour. l'adresse IP spécifique

• La méthode est donnée pour chaque scénario, mais les commandes à exécuter à chaque étape ne seront pas données en détail, car d'une part, cela rendrait l'article trop long ; par contre, je pense que tant que vous connaissez la méthode, La méthode spécifique viendra à vous, et cela ne dépend que du degré de connaissance et de la capacité à obtenir des informations

• ; Veuillez vous référer à la section 5 pour les précautions pendant le combat réel.

3.1 Scénario 1 Migration d'une structure maître et une structure esclave depuis la bibliothèque

En suivant l'idée de facile à difficile, nous commençons par un simple structure. Le projet A était à l’origine une structure maître-esclave. 101 est le nœud maître et 102 est le nœud esclave. En raison des besoins de l'entreprise, 102 a été migré à partir du nœud 103. Le diagramme d'architecture est présenté dans la figure 1. 102 La capacité de données du nœud esclave est trop grande et ne peut pas être sauvegardée à l'aide de mysqldump. Après communication avec R&D, un plan cohérent est formé.

Figure 1 schéma d'architecture de la bibliothèque esclave de migration de structure maître-esclave

La méthode spécifique est la suivante :

• La R&D sera 102 L'activité de lecture est coupée dans la base de données principale ;

• Confirmez l'état 102 de MySQL (regardez principalement la LISTE DES PROCESSUS), observez le trafic de la machine, et après avoir confirmé qu'il est correct, arrêtez le service du nœud esclave 102 ;

• 103 Créez une nouvelle instance MySQL une fois construite, arrêtez le service MySQL et copiez l'intégralité du répertoire de données mv vers d'autres endroits pour la sauvegarde ;

• Déplacez l'intégralité des données mysql de 102 Utilisez rsync pour copier le répertoire vers 103

• Pendant la copie, autorisez 101 pour que 103 ait le autorisation d'extraire le binlog (REPLICATION SLAVE, REPLICATION CLIENT);

• Une fois la copie terminée, modifiez le server_id dans 103 fichier de configuration, veillez à ne pas être cohérent avec celui sur 102 ;

• Démarrez l'instance MySQL en 103, veuillez noter le chemin du fichier de données dans le fichier de configuration et les autorisations du répertoire de données

• Entrez dans l'instance MySQL 103, utilisez SHOW SLAVE STATUS pour vérifier l'état de l'esclave, et vous pouvez voir que Seconds_Behind_Master décrémente

• Après que Seconds_Behind_Master devienne 0, cela signifie la synchronisation ; est terminé. À ce stade, vous pouvez utiliser pt-table-checksum pour vérifier que les données de 101 et 103 sont cohérentes, mais cela prend du temps et a un impact sur le nœud maître. Il peut être utilisé avec le développement Vérifier les données. cohérence ensemble ;

• Communiquer avec R&D En plus de vérifier la cohérence des données, vous devez également vérifier les autorisations du compte pour éviter les erreurs d'accès après le déplacement de l'entreprise

• Après avoir terminé les étapes ci-dessus, vous pouvez vous coordonner avec R&D pour faire passer une partie de l'activité de lecture de 101 à 103 et observer le statut de l'entreprise

• S'il n'y en a pas ; problème avec l'entreprise, prouver que la migration a réussi.

3.2 Scénario 2 : Une structure maître et une structure esclave pour migrer la bibliothèque spécifiée

Après avoir su migrer uniquement la bibliothèque esclave avec un maître et un esclave, puis voyons comment migrer les nœuds maître et esclave en même temps. Étant donné que différentes entreprises accèdent au même serveur en même temps, la pression sur une seule bibliothèque est trop élevée et peu pratique à gérer. Par conséquent, il est prévu de migrer simultanément le nœud maître 101 et le nœud esclave 102 vers les nouvelles machines 103 et 104, 103 agissant en tant que nœud maître et 104 en tant que nœud esclave. Le schéma d'architecture est représenté sur la figure. 2. Cette migration nécessite uniquement la migration des bibliothèques spécifiées. La capacité de ces bibliothèques n'est pas trop grande et peut garantir que les données ne sont pas en temps réel.

Figure 21 Schéma d'architecture de bibliothèque spécifié pour la migration de la structure maître-un-esclave

La méthode spécifique est la suivante :

• 103 et 104 Créez une nouvelle instance et établissez une relation maître-esclave. À ce moment, le nœud maître et les nœuds esclaves sont déchargés

• 102 Pour exporter des données, la bonne méthode est de : configurer les tâches planifiées et exporter pendant les faibles pics d'activité Opération, le choix ici est mysqldump

• 102 Collectez les comptes et les autorisations requis pour la bibliothèque spécifiée

• 102 L'exportation des données est terminée, utilisez rsync Transfer vers 103, effectuez une opération de compression si nécessaire

• 103 importez les données, à ce moment les données seront automatiquement synchronisées avec 104, surveillez ; état du serveur et état MySQL ;

• L'importation 103 est terminée, la synchronisation 104 est terminée, 103 est autorisée selon le compte collecté par 102. Une fois terminé, le R&D sera informé pour vérifier le autorisations de données et de compte ;

• Une fois ce qui précède terminé, la collaboration R&D peut être, migrer l'activité de 101 et 102 vers 103 et 104 et observer le statut de l'entreprise

• S'il n'y a aucun problème avec l'entreprise, la migration est réussie.

3.3 Scénario 3 Migration bilatérale de bibliothèques désignées avec une structure maître et une structure esclave

Voyons ensuite comment migrer bilatéralement des bibliothèques désignées avec une structure maître et une structure esclave. C'est aussi à cause du partage des services que le serveur est soumis à une forte pression et que la gestion est chaotique. Par conséquent, il est prévu de migrer simultanément le nœud maître 101 et le nœud esclave 102 vers les nouvelles machines 103, 104, 105 et 106, qui feront office de nœud maître de 104, et 104 feront office de nœud esclave. de 103, 105 fera office de nœud maître de 106 et 106 fera office de nœud maître de 105. À partir du nœud, le diagramme d'architecture est présenté à la figure 3. Cette migration nécessite uniquement la migration des bibliothèques spécifiées. La capacité de ces bibliothèques n'est pas trop grande et peut garantir que les données ne sont pas en temps réel. Nous pouvons voir que cette migration est très similaire au scénario 2, sauf qu’elle est migrée deux fois.

Figure 3. Migration bilatérale d'une structure maître et d'une structure esclave du diagramme d'architecture de bibliothèque spécifié

La méthode spécifique est la suivante :

• 103 et 104 Créez une nouvelle instance et établissez une relation maître-esclave à ce moment, le nœud maître et les nœuds esclaves sont déchargés

• 102 Exportez les données de bibliothèque spécifiées requises ; par 103. La bonne façon est de configurer les tâches planifiées. Pour effectuer des opérations d'exportation pendant les faibles pics d'activité, mysqldump est sélectionné ici

• 102 Collectez le compte et les autorisations requis pour la bibliothèque spécifiée requise ; par 103 ;

• 102 Exportez les données de bibliothèque spécifiées requises par 103. Utilisez rsync pour transférer vers 103 et effectuez une opération de compression si nécessaire ; 103 importer les données. À ce moment, les données seront automatiquement synchronisées avec 104. Surveiller l'état du serveur et l'état de MySQL ;

• 103 Importation terminée, 104 Synchronisation terminée, 103 autorisée en fonction du compte collecté par 102, une fois terminé, informez R&D pour vérifier les données et les autorisations du compte

• Une fois ce qui précède terminé, collaborez avec R&D pour migrer l'activité de 101 et 102 vers 103 et 104 ; , et observez l'état de l'entreprise ;

• Créez de nouvelles instances de 105 et 106 et construisez une relation maître-esclave, le nœud maître et le nœud esclave ne sont pas chargés en ce moment

• 102 Exportez les données de base de données spécifiées requises par 105. La bonne façon est de configurer les tâches planifiées et de les effectuer pendant les faibles pics d'activité. Pour l'opération d'exportation, mysqldump est sélectionné ici

102 Collectez les comptes et les autorisations requis pour la bibliothèque spécifiée requise par 105 ;
102 Exporter 105 Les données de bibliothèque spécifiées requises sont terminées, utilisez rsync pour transférer vers 105, et effectuez une opération de compression si nécessaire ;
105 importe les données, et les données seront automatiquement synchronisées avec 106 pour surveiller l'état du serveur et l'état de MySQL ;

• L'importation 105 est terminée, la synchronisation 106 est terminée, 105 est autorisée en fonction du compte collecté par 102, une fois terminé, le R&D sera informé pour vérifier les données et les autorisations du compte

• Une fois ce qui précède terminé, collaborez avec R&D pour migrer les entreprises de 101 et 102 vers 105 et 106, et observez le statut de l'entreprise

• S'il n'y en a pas ; problèmes avec toutes les entreprises, la migration est réussie.
3.4 Scénario 4 : Migration complète de maître-esclave dans une structure un maître-esclave

• Voyons comment complètement migrer maître-esclave dans une structure un maître-esclave. Semblable au scénario deux, mais ici toutes les bibliothèques sont migrées. En raison du goulot d'étranglement des E/S du nœud maître 101, nous prévoyons de migrer le nœud maître 101 et le nœud esclave 102 vers les nouvelles machines 103 et 104 en même temps, 103 agissant en tant que nœud maître et 104 en tant que nœud esclave. Une fois la migration terminée, le nœud maître et le nœud esclave précédents sont abandonnés. Le schéma d'architecture est illustré à la figure 4. Cette migration est une migration complète de base de données de grande capacité et doit être effectuée en temps réel. Cette migration est particulière car la stratégie adoptée consiste à remplacer d'abord la nouvelle base de données esclave, puis à remplacer la nouvelle base de données maître. La méthode est donc un peu plus compliquée.

Figure 41 Schéma d'architecture maître-esclave de migration complète de la structure maître-esclave

La méthode spécifique est la suivante :

R&D Coupez l'activité de lecture de 102 dans la base de données principale

Confirmez l'état de 102 MySQL (voir principalement LISTE DES PROCESSUS, STATUT MAÎTRE), observez le trafic de la machine et après avoir confirmé qu'il l'est. correct, arrêtez le service du nœud esclave 102 ;

• 104 Créez une nouvelle instance MySQL Une fois l'opération terminée, arrêtez le service MySQL et copiez l'intégralité du répertoire de données mv vers d'autres emplacements. sauvegarde. Notez que l'opération ici est 104, qui est le futur De la bibliothèque

• Copiez l'intégralité du répertoire de données mysql de 102 vers 104 en utilisant

• Pendant la copie, autorisez 101 à faire 104 Avoir la permission d'extraire le binlog (REPLICATION SLAVE, REPLICATION CLIENT
);

• Une fois la copie terminée, modifiez le server_id dans le fichier de configuration 104, attention à ne pas être cohérent avec celui du 102

• Démarrez le Instance MySQL en 104, faites attention au fichier de configuration Le chemin du fichier de données et les autorisations du répertoire de données

• Entrez l'instance MySQL 104, utilisez SHOW SLAVE STATUS pour vérifier l'esclave ; status, et vous pouvez voir que Seconds_Behind_Master décrémente

• Après que Seconds_Behind_Master devient 0, cela signifie que la synchronisation est terminée. À ce moment, vous pouvez utiliser pt-table-checksum pour vérifier que le les données de 101 et 104 sont cohérentes, mais cela prend du temps et a un impact sur le nœud maître Cela peut être fait en même temps que le développement

• De plus. pour la vérification de la cohérence des données, les autorisations du compte doivent également être vérifiées pour éviter les erreurs d'accès après la migration de l'entreprise

• Collaborer avec la R&D pour faire passer l'activité de lecture du nœud esclave 102 précédent à 104 ; 🎜>

• Utilisez les données de 102 pour transformer 103 en nœud esclave de 101. La méthode est la même que ci-dessus

• Vient maintenant la clé ; point, nous devons transformer le 104 en bibliothèque d'esclaves du 103

1. 104 STOP SLAVE ;

2. 103 STOP SLAVE IO_THREAD;

3. 103 STOP SLAVE SQL_THREAD, rappelez-vous MASTER_LOG_FILE et MASTER_LOG_POS

4. 104 START SLAVE JUSQU'À MASTER_LOG_FILE et MASTER_LOG_POS ci-dessus ; >

104 STOP SLAVE à nouveau ;
104 RESET SLAVE ALL effacer les informations de configuration de l'esclave
103 SHOW. MASTER STATUS, rappelez-vous MASTER_LOG_FILE et MASTER_LOG_POS ;
103 autorise 104 à accéder au binlog
104 CHANGE MASTER EN 103 ;
104 Redémarrez MySQL, car après RESET SLAVE ALL, vérifiez le SLAVE STATUS, le Master_Server_Id est toujours 101, pas 103 ;
104 Après le redémarrage de MySQL, SLAVE redémarrer automatiquement. À ce moment, vérifiez si IO_THREAD et SQL_THREAD sont OUI
103 START SLAVE ;

12. En regardant l'état de 103 et 104 à l'heure actuelle, vous pouvez constater que 104 était le nœud esclave de 101, mais qu'il est maintenant devenu le nœud esclave de 103.

Avant la migration d'entreprise, rompez la relation de synchronisation entre 103 et 101

• Après avoir terminé les étapes ci-dessus, vous peut coordonner la R&D, en ramenant les activités de lecture et d'écriture du 101 au 102 et les activités de lecture au 104. Il convient de noter que 101 et 103 peuvent être écrits à ce moment-là. Vous devez vous assurer que 101 passe à 103 sans écrire. Vous pouvez utiliser FLUSH TABLES WITH READ LOCK pour verrouiller 101, puis passer à 103. Notez que l'entreprise doit être exécutée pendant les heures creuses, n'oubliez pas

• Une fois le changement terminé, observez l'état de l'entreprise ; S'il n'y a aucun problème avec l'entreprise, prouvez le succès de la migration.
3.5 Scénario 5 Migration entre salles informatiques à structure double primaire

• Voyons comment effectuer une migration croisée de structure à double primaire Migration de salle informatique. Pour des raisons de reprise après sinistre, un certain projet utilise une salle multi-machines et adopte une structure à double maître, qui peut être écrite des deux côtés. En raison de problèmes d'espace disque, la machine située à l'emplacement A doit être remplacée. Il est prévu de migrer simultanément le nœud maître 1.101 et le nœud esclave 1.102 vers les nouvelles machines 1.103 et 1.104, la 1.103 faisant office de nœud maître et la 1.104 faisant office de nœud esclave. 2.101 et 2.102 à l'emplacement B restent inchangés, mais une fois la migration terminée, 1.103 et 2.101 deviennent doubles maîtres l'un de l'autre. Le schéma d'architecture est présenté à la figure 5. Comme il s'agit d'une structure à double maître, les deux côtés écrivent en même temps. Si vous souhaitez remplacer le nœud maître, un nœud doit cesser de servir.

Figure 5 Schéma d'architecture de migration entre salles de machines à structure double primaire

La méthode spécifique est la suivante :

1.103 et 1.104 nouvelles instances, établissez une relation maître-esclave à ce moment, le nœud maître et le nœud esclave sont sans charge

Confirmez l'état de MySQL 1.102 (regardez principalement le PROCESS LIST), et faites attention à ce que le MASTER STATUS ne change plus. Observez le trafic de la machine. Après avoir confirmé qu'il est correct, arrêtez le service du nœud esclave 1.102

• 1.103 Créez une nouvelle instance MySQL une fois terminée, arrêtez le service MySQL et sauvegardez l'intégralité du répertoire de données mv vers d'autres endroits ;

• Copiez l'intégralité du répertoire de données MySQL de 1.102 à 1.103 en utilisant rsync ;

• Pendant la copie. , autorisez 1.101 pour que 1.103 puisse extraire Obtenez les autorisations de binlog (REPLICATION SLAVE, REPLICATION CLIENT);

• Une fois la copie terminée, modifiez le server_id dans le fichier de configuration 1.103, soyez prudent pour ne pas être cohérent avec celui de la 1.102 ;

• Démarrez l'instance MySQL en 1.103, faites attention au chemin du fichier de données dans le fichier de configuration et aux autorisations du répertoire de données

• Entrez dans l'instance MySQL 1.103, utilisez SHOW SLAVE STATUS pour vérifier l'état de l'esclave, vous pouvez voir que Seconds_Behind_Master décrémente

• Après que Seconds_Behind_Master devienne 0, cela signifie que la synchronisation est terminée. À ce stade, vous pouvez utiliser pt-table-checksum pour vérifier que les données de 1.101 et 1.103 sont cohérentes, mais cela prend du temps et a un impact sur le nœud maître. avec le développement ;

• Nous utilisons la même méthode pour transformer 1.104 en une bibliothèque esclave de

• Communiquer avec R&D ; vérification de la cohérence des données, les autorisations du compte doivent également être vérifiées afin d'éviter les erreurs d'accès après la migration de l'entreprise

• À l'heure actuelle, ce que nous devons faire est de transformer la 1.103 en bibliothèque esclave ; de 2.101. Pour des méthodes spécifiques, veuillez vous référer au scénario quatre

• Il convient de noter que la configuration des nombres impairs et pairs de 1.103 doit être cohérente avec 1.101 ; >

Après avoir terminé les étapes ci-dessus, vous pouvez vous coordonner avec R&D pour lire et écrire 1.101. L'activité est réduite à 1.103 et l'activité lue de 1.102 est réduite à 1.104. Observez le statut de l'entreprise ;
S'il n'y a aucun problème avec l'entreprise, la migration est réussie.

3.6 Scénario 6 Migration multi-instance entre salles informatiques

Regardons ensuite la preuve de migration multi-instance entre salles informatiques . Pour la relation d'instance de chaque machine, on peut se référer à la figure 6. Le but de cette migration est d'effectuer une réparation des données. Créez les instances 7938 et 7939 sur 2.117 pour remplacer les instances précédentes par des données anormales. Pour des raisons commerciales, certaines bibliothèques ne sont écrites qu'à l'emplacement A, et certaines bibliothèques ne sont écrites qu'à l'emplacement B, il existe donc une situation de filtrage synchrone.

Figure 6 Schéma d'architecture de migration multi-instance entre salle des machines
La méthode spécifique est la suivante :

1.113 Utilisez innobackupex pour les instances 7936. Pour effectuer une sauvegarde des données, veuillez noter que vous devez spécifier la base de données et ajouter le paramètre slave-info
Une fois la sauvegarde terminée, copiez le fichier compressé dans ; 2.117 ;
2.117 Créer le répertoire de données et les répertoires associés impliqués dans le fichier de configuration
2.117 Utiliser innobackupex pour restaurer les journaux ;

• 2.117 Utilisez innobackupex pour copier les données

• 2.117 Modifiez le fichier de configuration, faites attention aux paramètres suivants : replique-ignore-db, innodb_file_per_table = 1 , read_only = 1, server_id;

• 2.117 Modifier les autorisations du répertoire de données ;

• 1.112 autorisation, de sorte que 2.117 ait l'autorisation d'extraire le binlog ( ESCLAVE DE RÉPLICATION, CLIENT DE RÉPLICATION);

• 2.117 CHANGER MASTE EN 1.112, LOG FILE et LOG POS font référence à xtrabackup_slave_info

• 2.117 DÉMARRER ESCLAVE, vérifiez l'état de l'esclave ;

• 2.117 pour construire 7939 sur La méthode est similaire, mais le fichier de configuration doit spécifier replicate-wild-do-table

• Travailler avec le développement pour vérifier la cohérence des données et vérifier les autorisations du compte afin d'éviter les erreurs d'accès après la migration de l'entreprise ;

• Après avoir terminé les étapes ci-dessus, vous pouvez vous coordonner avec R&D pour migrer le correspondant business vers l’instance 7938 et l’instance 7939 de 2.117. Observez le statut de l'entreprise ;

• S'il n'y a aucun problème avec l'entreprise, la migration est réussie.

• Quatre notes

Après avoir présenté les solutions de migration pour différents scénarios, vous devez prêter attention aux points suivants :

Migration de base de données, Si

event
• est impliqué, n'oubliez pas d'activer le paramètre event_scheduler sur le nœud maître
  Quel que soit le scénario de migration, vous devez toujours ; faites attention à l'état du serveur, tel que l'espace disque et la gigue du réseau. De plus, une surveillance continue de l'entreprise est également essentielle

• CHANGER LE FICHIER LOG DE MASTER TO et le LOG POS. ne pas faire d'erreurs. Si vous spécifiez les mauvaises, les conséquences seront Les données sont incohérentes ou la relation maître-esclave ne parvient pas à être établie

• Ne pas exécuter le script dans le Répertoire $HOME, n'oubliez pas de le faire dans le répertoire data ;

• Le travail de migration peut être effectué. Utilisez des scripts pour automatiser, mais ne soyez pas voué à l'échec. Tout script doit être testé. ;

• Réfléchissez à deux fois avant d'exécuter une commande, et comprenez la signification des paramètres de chaque commande ;

• Dans un environnement multi-instance. , utilisez mysqladmin pour fermer MySQL. Ne fermez pas l'instance que vous utilisez

• N'oubliez pas de la supprimer de la base de données read_only = 1 plus, cela évitera de nombreux problèmes ; 🎜>
• Le server_id de chaque machine doit être cohérent, sinon des exceptions de synchronisation se produiront

• Configurez correctement la réplique-ignore-db et la réplique-wild-do-table ; ;

• N'oubliez pas de définir innodb_file_per_table sur 1 pour l'instance nouvellement créée, car ce paramètre était 0 dans l'instance précédente, ibdata1 était trop volumineux et la sauvegarde et la transmission prenaient beaucoup de temps. de temps ;

• Lorsque vous utilisez gzip pour compresser des données, veuillez noter qu'une fois la compression terminée, gzip supprimera le fichier source

• Toutes les opérations doivent être effectuées sur le nœud esclave ou le nœud de secours. Opération, s'il est effectué sur le nœud principal, le nœud principal est susceptible d'être en panne

• la sauvegarde xtrabackup ne verrouillera pas la table InnoDB ; , mais verrouillera la table MyISAM. Par conséquent, avant d'opérer, n'oubliez pas de vérifier si la table de base de données actuelle utilise le moteur de stockage MyISAM. Si tel est le cas, traitez-la séparément ou modifiez le moteur de la table.

Cinq conseils

Dans la migration MySQL réelle, les techniques suivantes peuvent être utilisées :

• Toute migration LOG FILE vers relay_master_log_file (le nom du journal binlog sur le maître en cours de synchronisation) prévaudra, et le LOG POS sera soumis à exec_master_log_pos (le point POS du journal binlog actuel en cours de synchronisation

• ) ; Utilisez rsync pour copier des données, qui peuvent être combinées avec expect , utiliser nohup est absolument une combinaison merveilleuse

• Vous pouvez utiliser gzip pour la compression tout en utilisant innobackupex pour sauvegarder les données ;

• Lors de l'utilisation d'innobackupex pour sauvegarder des données Pour les données, vous pouvez ajouter le paramètre –slave-info pour faciliter la base de données esclave

• Lors de l'utilisation d'innobackupex pour ; sauvegardez les données, vous pouvez ajouter le paramètre –throttle pour limiter les E/S et réduire l'impact sur l'entreprise. Vous pouvez également ajouter le paramètre –parallel=n pour accélérer la sauvegarde, mais il convient de noter que lors de l'utilisation de la compression du flux tar, le paramètre –parallel n'est pas valide

• Pour la sauvegarde des données ; et la récupération, vous pouvez créer une liste de tâches, dessiner un processus et préparer les commandes qui doivent être exécutées à l'avance

• Un bon moyen de copier rapidement un dossier localement ; pour utiliser rsync, plus Les paramètres suivants : -avhW –no-compress –progress

• Pour copier rapidement des données entre différentes partitions, vous pouvez utiliser dd. Ou utilisez une méthode plus fiable, sauvegardez sur le disque dur, puis placez-le sur le serveur. Il y a quelque chose d'encore mieux ailleurs, la livraison expressdirecte sur disque dur.

Six résumés

Cet article commence par pourquoi nous devons migrer, puis parle du plan de migration, puis explique la migration réelle dans différents scénarios et donne enfin les notes. Questions et compétences pratiques. Pour résumer, il y a les points suivants :

Premièrement, le but de la migration est de permettre à l'entreprise de fonctionner de manière fluide et continue.
Deuxièmement, le cœur de la migration est de savoir comment poursuivre la synchronisation maître-esclave ; Nous devons le faire sur différents serveurs et trouver des solutions entre différentes entreprises ;
Troisièmement, le changement d'entreprise doit prendre en compte les problèmes d'autorisation entre différents serveurs MySQL ; être pris en compte ; l'impact des appels entre salles de machines sur l'entreprise doit être pris en compte.

Les lecteurs peuvent se référer aux idées fournies dans cet article pendant le processus de migration. Mais comment garantir que chaque opération se déroule correctement nécessite une réflexion approfondie avant de continuer.

En passant, "La chose la plus importante pour prouver que vous êtes capable est de tout garder sous votre contrôle."

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!