MySQL-Migrationslösungen unter verschiedenen Umständen (empfohlen)

1. Warum Migration

MySQL Migration ist eine Aufgabe in der täglichen Wartung von DBA. Im ursprünglichen Sinne ist Migration nichts anderes als das Entfernen eines tatsächlich vorhandenen Objekts, um die Integrität und Kontinuität des Objekts sicherzustellen. Genau wie am weichen Strand haben zwei unschuldige Kinder einen Sandhaufen an andere Orte gebracht, um das Schloss ihrer Herzen zu bauen.

In der Produktionsumgebung sind Migrationsarbeiten in den folgenden Situationen erforderlich:

• Unzureichender Speicherplatz. Beispielsweise sind in manchen alten Projekten die ausgewählten Modelle möglicherweise nicht unbedingt für die Datenbank geeignet. Mit der Zeit wird es wahrscheinlich zu Engpässen bei den Festplatten kommen.

• Beispielsweise wird in dem Projekt eine einzige Maschine für alle Lese- und Schreibdienste verwendet, was den geschäftlichen Druck erhöht und zu einer Überforderung führt. Wenn der E/A-Druck innerhalb eines akzeptablen Bereichs liegt, wird eine Lösung zur Lese-/Schreibtrennung eingesetzt.

• Die Maschine weist einen Engpass auf. Die Hauptengpässe der Maschine sind Festplatten-IO-Fähigkeit, Speicher und CPU. Zusätzlich zur Optimierung der Engpässe ist die Migration eine gute Lösung. Die Datenbanken einiger Projekte erstrecken sich über Computerräume, und Knoten können in verschiedenen Computerräumen hinzugefügt werden oder Maschinen können von einem Computerraum in einen anderen verschoben werden. Wenn beispielsweise verschiedene Unternehmen denselben Server gemeinsam nutzen, wird eine Migration durchgeführt, um den Druck auf den Server zu verringern und die Wartung zu erleichtern.

• Mit einem Wort: Migration ist der letzte Ausweg. Der Zweck der Umsetzung der Migrationsarbeiten besteht darin, den reibungslosen und kontinuierlichen Geschäftsbetrieb aufrechtzuerhalten.

2. Überblick über den MySQL-Migrationsplan

MySQL-Migration ist nichts anderes als die Umgehung der Daten und deren weitere Erweiterung, es ist nichts weiter als Sicherung und Wiederherstellung unter der Voraussetzung, dass die Daten sichergestellt werden reibungslosen und kontinuierlichen Geschäftsbetrieb. Das Problem besteht darin, wie Backup und Wiederherstellung schnell und sicher durchgeführt werden können.

Einerseits Backup. Es gibt ein Backup für den Slave-Knoten oder Standby-Knoten jedes Master-Knotens. Bei dieser Sicherung kann es sich um eine vollständige Sicherung oder eine inkrementelle Sicherung handeln. Die Online-Sicherungsmethode kann die Verwendung von mysqldump, xtrabackup oder mydumper sein. Für die Sicherung von Datenbanken mit geringer Kapazität (weniger als 10 GB) können wir mysqldump verwenden. Aber für Datenbanken mit großer Kapazität (Hunderte von GB oder TB) können wir keine mysqldump-Sicherung verwenden. Einerseits werden Sperren generiert, andererseits dauert es zu lange. In diesem Fall können Sie xtrabackup wählen oder das Datenverzeichnis direkt kopieren. Kopieren Sie die Datenverzeichnismethode direkt. Sie können rsync für die Übertragung zwischen verschiedenen Computern verwenden. Der Zeitaufwand hängt vom Netzwerk ab. Der Zeitaufwand bei der Verwendung von xtrabackup liegt hauptsächlich in der Sicherung und Netzwerkübertragung. Wenn Sie über eine vollständige oder eine bestimmte Bibliothekssicherungsdatei verfügen, ist dies die beste Möglichkeit, die Sicherung zu erhalten. Wenn die Standby-Datenbank das Stoppen des Dienstes toleriert, ist das direkte Kopieren des Datenverzeichnisses die schnellste Methode. Wenn die Standby-Datenbank den Dienst nicht stoppen darf, können wir xtrabackup verwenden (das die InnoDB-Tabelle nicht sperrt), was den besten Kompromiss zum Abschließen der Sicherung darstellt.

Andererseits Erholung. Für Sicherungsdateien von Datenbanken mit geringer Kapazität (weniger als 10 GB) können wir sie direkt importieren. Bei der Wiederherstellung von Datenbanken mit großer Kapazität (Hunderte von GB oder TB) ist die Wiederherstellung nicht schwierig, nachdem die Sicherungsdateien auf dem lokalen Computer gespeichert wurden. Spezifische Wiederherstellungsmethoden finden Sie in Abschnitt 4.

3. Praktische MySQL-Migration

Nachdem wir verstanden haben, warum wir migrieren müssen und wie es geht, werfen wir einen Blick auf die Funktionsweise der Produktionsumgebung. Unterschiedliche Anwendungsszenarien haben unterschiedliche Lösungen.

Vor dem Lesen des spezifischen tatsächlichen Kampfes wird davon ausgegangen, dass der Leser die folgende Vereinbarung hat:

Zum Schutz der Privatsphäre werden die Server-IP und andere darin enthaltene Informationen angegeben Artikel wurden verarbeitet;

• Wenn sich der Server im selben Computerraum befindet, verwenden Sie das D-Segment der Server-IP anstelle der Server-IP. Weitere Informationen finden Sie im

  Architektur
Diagramm;

• Wenn sich der Server in verschiedenen Computerräumen befindet, verwenden Sie die C- und D-Segmente der Server-IP anstelle des Servers die spezifische IP;

• Die Methode wird für jedes Szenario angegeben, die bei jedem Schritt auszuführenden Befehle werden jedoch nicht im Detail angegeben, da dies einerseits dazu führt, dass der Artikel zu lang wird Andererseits denke ich, solange Sie die Methode kennen, wird die spezifische Methode zu Ihnen kommen, und es hängt nur vom Grad des Wissens und der Fähigkeit ab, Informationen zu erhalten

• Bitte beachten Sie Abschnitt 5 für Vorsichtsmaßnahmen während des tatsächlichen Kampfes.

3.1 Szenario 1 Eine Master- und eine Slave-Strukturmigration aus der Bibliothek

Wir folgen der Idee von einfach bis schwierig und beginnen mit einem einfachen Struktur. Projekt A war ursprünglich eine Master-Slave-Struktur. 101 ist der Master-Knoten und 102 ist der Slave-Knoten. Aufgrund geschäftlicher Anforderungen wurde 102 von Knoten 103 migriert. Das Architekturdiagramm ist in Abbildung 1 dargestellt. 102 Die Datenkapazität des Slave-Knotens ist zu groß und kann nicht mit mysqldump gesichert werden. Nach der Kommunikation mit der Forschung und Entwicklung wird ein konsistenter Plan erstellt.

Abbildung 1 Master-Slave-Strukturmigration, Slave-Bibliotheksarchitekturdiagramm

Die spezifische Methode ist wie folgt:

• F&E wird 102 Das Lesegeschäft wird auf die Hauptdatenbank beschränkt. Bestätigen Sie den 102 MySQL-Status (schauen Sie sich hauptsächlich die PROZESSLISTE an), beobachten Sie den Maschinenverkehr und bestätigen Sie, dass er korrekt ist. Stoppen Sie den Dienst des 102-Slave-Knotens.

• 103 Erstellen Sie eine neue MySQL-Instanz, stoppen Sie den MySQL-Dienst und kopieren Sie das gesamte Datenverzeichnis mv zur Sicherung.

• Verschieben Sie die gesamten MySQL-Daten von 102. Verwenden Sie rsync, um das Verzeichnis nach 103 zu kopieren.

• Autorisieren Sie beim Kopieren 101, damit 103 das hat Berechtigung zum Abrufen von Binlog (REPLICATION SLAVE, REPLICATION CLIENT);

• Ändern Sie nach Abschluss des Kopiervorgangs die Server-ID in 103

  Konfigurationsdatei
. Achten Sie darauf, dass sie nicht konsistent ist mit der auf 102;

• Starten Sie die MySQL-Instanz in 103, beachten Sie bitte den Datendateipfad in der Konfigurationsdatei und die Berechtigungen des Datenverzeichnisses; 🎜>

  Geben Sie die 103 MySQL-Instanz ein, verwenden Sie SHOW SLAVE STATUS, um den Slave-Status zu überprüfen, und Sie können sehen, dass Seconds_Behind_Master dekrementiert wird.

• Nachdem Seconds_Behind_Master 0 wird, bedeutet dies Synchronisierung Zu diesem Zeitpunkt können Sie mit pt-table-checksum überprüfen, ob die Daten von 101 und 103 konsistent sind. Dies ist jedoch zeitaufwändig und hat Auswirkungen auf den Masterknoten. Es kann mit der Entwicklung von Daten überprüft werden Konsistenz zusammen;

• Kommunizieren Sie mit R&D. Zusätzlich zur Überprüfung der Datenkonsistenz müssen Sie auch die Kontoberechtigungen überprüfen, um Zugriffsfehler zu verhindern, nachdem das Unternehmen zurück migriert wurde
• Nach Abschluss der oben genannten Schritte können Sie sich mit R&D abstimmen, um einen Teil des Lesegeschäfts von 101 auf 103 zu ändern und den Geschäftsstatus zu beobachten

• Wenn nicht Problem mit dem Unternehmen. Beweisen Sie, dass die Migration erfolgreich war.

• 3.2 Szenario 2: Eine Master- und eine Slave-Struktur zur Migration der angegebenen Bibliothek

• Nachdem wir wissen, wie nur die Slave-Bibliothek migriert werden kann Ein Master- und ein Slave-Knoten. Schauen wir uns dann an, wie die Master- und Slave-Knoten gleichzeitig migriert werden. Da verschiedene Unternehmen gleichzeitig auf denselben Server zugreifen, ist der Druck auf eine einzelne Bibliothek zu hoch und die Verwaltung ist unpraktisch. Daher ist geplant, den Master-Knoten 101 und den Slave-Knoten 102 gleichzeitig auf die neuen Maschinen 103 und 104 zu migrieren, wobei 103 als Master-Knoten und 104 als Slave-Knoten fungiert. Das Architekturdiagramm ist in Abbildung dargestellt 2. Diese Migration erfordert nur die Migration bestimmter Bibliotheken. Die Kapazität dieser Bibliotheken ist nicht zu groß und kann sicherstellen, dass die Daten nicht in Echtzeit vorliegen.

Abbildung 21 Diagramm der spezifizierten Bibliotheksarchitektur durch Master-Eins-Slave-Strukturmigration

Die spezifische Methode ist wie folgt:

103 und 104 Erstellen Sie eine neue Instanz und stellen Sie eine Master-Slave-Beziehung her. Zu diesem Zeitpunkt werden der Master-Knoten und die Slave-Knoten entladen Konfigurieren Sie geplante Aufgaben und exportieren Sie sie während geringer Geschäftsspitzen. Die Auswahl ist hier

102. Sammeln Sie die für die angegebene Bibliothek erforderlichen Konten und Berechtigungen

102 Der Datenexport ist abgeschlossen. Verwenden Sie rsync. Übertragen Sie ihn auf 103. Führen Sie bei Bedarf einen Komprimierungsvorgang durch.

• 103 Datenimport. Zu diesem Zeitpunkt werden die Daten automatisch mit 104 synchronisiert Serverstatus und MySQL-Status;

• 103 Import ist abgeschlossen, 104 Synchronisierung ist abgeschlossen, 103 ist gemäß dem von 102 erfassten Konto autorisiert. Nach Abschluss wird die Forschung und Entwicklung benachrichtigt, um dies zu überprüfen Daten und Kontoberechtigungen;

• Nachdem die F&E-Zusammenarbeit abgeschlossen ist, können Sie das Geschäft von 101 und 102 auf 103 und 104 migrieren und den Geschäftsstatus beobachten 🎜>

Wenn es kein Problem mit dem Unternehmen gibt, ist die Migration erfolgreich.

3.3 Szenario 3 Bilaterale Migration designierter Bibliotheken mit einer Master- und einer Slave-Struktur

Als nächstes schauen wir uns an, wie man designierte Bibliotheken bilateral migriert eine Master- und eine Slave-Struktur. Auch aufgrund gemeinsam genutzter Dienste steht der Server unter großem Druck und die Verwaltung ist chaotisch. Daher ist geplant, den Master-Knoten 101 und den Slave-Knoten 102 gleichzeitig auf die neuen Maschinen 103, 104, 105 und 106 zu migrieren. 103 fungiert als Master-Knoten von 104 und 104 fungiert als Slave-Knoten Von 103 fungiert 105 als Masterknoten von 106 und 106 fungiert als Masterknoten von 105. Das Architekturdiagramm des Knotens ist in Abbildung 3 dargestellt. Diese Migration erfordert nur die Migration bestimmter Bibliotheken. Die Kapazität dieser Bibliotheken ist nicht zu groß und kann sicherstellen, dass die Daten nicht in Echtzeit vorliegen. Wir können sehen, dass diese Migration Szenario 2 sehr ähnlich ist, mit der Ausnahme, dass sie zweimal migriert wird.

Abbildung 3. Diagramm zur bilateralen Migration einer bestimmten Bibliotheksarchitektur mit einer Master- und einer Slave-Struktur

Die spezifische Methode ist wie folgt:

• 103 und 104 Erstellen Sie eine neue Instanz und stellen Sie eine Master-Slave-Beziehung her. Zu diesem Zeitpunkt werden der Master-Knoten und die Slave-Knoten entladen.

• 102 Exportieren Sie die angegebenen Bibliotheksdaten von 103. Um geplante Aufgaben während geringer Geschäftsspitzen durchzuführen, wird hier mysqldump ausgewählt.

• 102 Sammeln Sie das für die angegebene Bibliothek erforderliche Konto und die erforderlichen Berechtigungen von 103;

• 102 Exportieren Sie die angegebenen Bibliotheksdaten, die von 103 benötigt werden. Verwenden Sie rsync, um nach 103 zu übertragen und bei Bedarf einen Komprimierungsvorgang durchzuführen; 103 Importieren Sie die Daten. Zu diesem Zeitpunkt werden die Daten automatisch mit 104 synchronisiert. Serverstatus und MySQL-Status überwachen

• 103 Import abgeschlossen, 104 Synchronisierung abgeschlossen, 103 autorisiert Konto von 102 gesammelt, nach Abschluss R&D benachrichtigen, um Daten und Kontoberechtigungen zu überprüfen

• Nachdem die oben genannten Arbeiten abgeschlossen sind, arbeiten Sie mit R&D zusammen, um das Geschäft von 101 und 102 auf 103 und 104 zu migrieren , und beobachten Sie den Geschäftsstatus;

• Erstellen Sie neue Instanzen von 105 und 106 und bauen Sie eine Master-Slave-Beziehung auf. Der Master-Knoten und der Slave-Knoten sind zu diesem Zeitpunkt leer >

• 102 Exportieren Sie die angegebenen Datenbankdaten, die für 105 erforderlich sind. Der richtige Weg besteht darin, geplante Aufgaben zu konfigurieren und sie während geringer Geschäftsspitzen auszuführen. Für den Exportvorgang wird hier mysqldump ausgewählt; >
  102 Sammeln Sie die Konten und Berechtigungen, die für die angegebene Bibliothek erforderlich sind, bis 105;

• 102 Exportieren 105 Die erforderlichen angegebenen Bibliotheksdaten sind abgeschlossen. Verwenden Sie zum Übertragen rsync 105 und führen Sie bei Bedarf einen Komprimierungsvorgang durch.

• 105 importiert die Daten und die Daten werden automatisch mit 106 synchronisiert, um den Serverstatus und den MySQL-Status zu überwachen ;

• 105 Der Import ist abgeschlossen, 106 die Synchronisierung ist abgeschlossen, 105 ist gemäß dem von 102 erfassten Konto autorisiert. Nach Abschluss wird die Forschung und Entwicklung benachrichtigt, um die Daten und Kontoberechtigungen zu überprüfen
• Nachdem die oben genannten Schritte abgeschlossen sind, arbeiten Sie mit R&D zusammen, um die Geschäfte von 101 und 102 auf 105 und 106 zu migrieren, und beobachten Sie den Geschäftsstatus

• Wenn keine vorhanden sind Probleme bei allen Unternehmen, die Migration ist erfolgreich.

• 3.4 Szenario 4: Vollständige Migration von Master-Slave in einer Ein-Master-Slave-Struktur

• Schauen wir uns an, wie die vollständige Migration durchgeführt wird Master-Slave in einer Ein-Master-Slave-Struktur migrieren Do. Ähnlich wie Szenario zwei, jedoch werden hier alle Bibliotheken migriert. Aufgrund des E/A-Engpasses von Master-Knoten 101 planen wir, Master-Knoten 101 und Slave-Knoten 102 gleichzeitig auf die neuen Maschinen 103 und 104 zu migrieren, wobei 103 als Master-Knoten und 104 als Slave-Knoten fungiert. Nach Abschluss der Migration werden der vorherige Master-Knoten und der Slave-Knoten aufgegeben. Das Architekturdiagramm ist in Abbildung 4 dargestellt. Bei dieser Migration handelt es sich um eine vollständige Datenbankmigration mit großer Kapazität, die in Echtzeit erfolgen muss. Diese Migration ist etwas Besonderes, da die Strategie darin besteht, zuerst die neue Slave-Datenbank und dann die neue Master-Datenbank zu ersetzen. Die Methode ist also etwas komplizierter.

Abbildung 41 Master-Slave-Struktur, vollständige Migration, Master-Slave-Architekturdiagramm

Die spezifische Methode ist wie folgt:

F&E Reduzieren Sie das Lesegeschäft von 102 auf die Hauptdatenbank.

Bestätigen Sie den 102-MySQL-Status (siehe hauptsächlich PROZESSLISTE, MASTERSTATUS), beobachten Sie den Maschinenverkehr und bestätigen Sie, dass dies der Fall ist richtig, stoppen Sie den Dienst des 102-Slave-Knotens ;

• 104 Erstellen Sie nach Abschluss den MySQL-Dienst und kopieren Sie das gesamte Datenverzeichnis mv an andere Orte Beachten Sie, dass die Operation hier 104 ist, was die Zukunft ist.

• Kopieren Sie das gesamte MySQL-Datenverzeichnis von 102 mit rsync; 🎜>

  Autorisieren Sie beim Kopieren 101, um 104 die Berechtigung zum Abrufen von Binlog zu erhalten (REPLICATION SLAVE, REPLICATION CLIENT);

• Ändern Sie nach Abschluss des Kopiervorgangs die server_id in der 104-Konfigurationsdatei. Achten Sie darauf, dass sie nicht mit der in 102 übereinstimmt.

• Starten Sie die MySQL-Instanz in 104, achten Sie auf den Datendateipfad in und die Berechtigungen des Datenverzeichnisses

• Geben Sie die 104 MySQL-Instanz ein und verwenden Sie SHOW SLAVE STATUS, um den Slave zu überprüfen Status, und Sie können sehen, dass Seconds_Behind_Master abnimmt;

• Nachdem Seconds_Behind_Master 0 wird, bedeutet dies, dass die Synchronisierung abgeschlossen ist. Zu diesem Zeitpunkt können Sie pt-table-checksum verwenden, um zu überprüfen, ob Die Daten von 101 und 104 sind konsistent, aber es ist zeitaufwändig und hat Auswirkungen auf den Masterknoten. Es kann zusammen mit der Entwicklung durchgeführt werden.

• Zusätzlich Zur Überprüfung der Datenkonsistenz müssen auch Kontoberechtigungen überprüft werden, um Zugriffsfehler nach der Geschäftsmigration zu verhindern.

• Arbeiten Sie mit R&D zusammen, um das Lesegeschäft des vorherigen 102-Slave-Knotens auf 104 umzustellen 🎜>

• Verwenden Sie die Daten von 102, um 103 in den Slave-Knoten von 101 zu ändern. Die Methode ist die gleiche wie oben;

• Jetzt kommt der Schlüssel Punkt, wir müssen 104 in die Slave-Bibliothek von 103 umwandeln;

1. 104 STOP SLAVE ;

2. 103 STOP SLAVE IO_THREAD;

3. 103 STOP SLAVE SQL_THREAD, merken MASTER_LOG_FILE und MASTER_LOG_POS;

4. 104 START SLAVE BIS zu den oben genannten MASTER_LOG_FILE und MASTER_LOG_POS;

5. 104 SLAVE erneut STOPPEN

6. 104 SLAVE ALLES zurücksetzen Slave-Konfigurationsinformationen löschen

7. 103 ZEIGEN MASTER STATUS, merken Sie sich, dass MASTER_LOG_FILE und MASTER_LOG_POS 104 zum Zugriff auf Binlog autorisieren; >
   104 MySQL neu starten, denn nach RESET SLAVE ALL überprüfen Sie den SLAVE-STATUS, die Master_Server_Id ist immer noch 101, nicht 103;

8. 104 Nach dem Neustart von MySQL wird SLAVE dies tun Überprüfen Sie zu diesem Zeitpunkt, ob IO_THREAD und SQL_THREAD YES sind 104 Zu diesem Zeitpunkt können Sie feststellen, dass 104 früher der Slave-Knoten von 101 war, jetzt aber zum Slave-Knoten von 103 geworden ist.
10. Unterbrechen Sie vor der Geschäftsmigration die Synchronisierungsbeziehung zwischen 103 und 101;

11. Nach Abschluss der oben genannten Schritte können Sie kann die F&E-Koordination übernehmen und das Lese- und Schreibgeschäft von 101 wieder auf 102 und das Lesegeschäft auf 104 umstellen. Es ist zu beachten, dass zu diesem Zeitpunkt sowohl 101 als auch 103 geschrieben werden können. Sie müssen sicherstellen, dass 101 zu 103 wechselt, ohne zu schreiben. Sie können FLUSH TABLES WITH READ LOCK verwenden, um 101 zu sperren und dann zu 103 zu wechseln. Beachten Sie, dass das Geschäft außerhalb der Hauptverkehrszeiten ausgeführt werden muss. Denken Sie daran:

12. Beobachten Sie nach Abschluss der Umstellung den Geschäftsstatus Wenn es keine Probleme mit dem Unternehmen gibt, beweisen Sie den Migrationserfolg.

13. 3.5 Szenario 5 Cross-Computerraum-Migration mit Dual-Primärstruktur

Lassen Sie uns einen Blick darauf werfen, wie eine Cross-Computerraum-Migration mit Dual-Primärstruktur durchgeführt wird. Computerraummigration. Aus Gründen der Notfallwiederherstellung verwendet ein bestimmtes Projekt einen maschinenübergreifenden Raum und übernimmt eine Dual-Master-Struktur, die auf beiden Seiten geschrieben werden kann. Aufgrund von Speicherplatzproblemen muss die Maschine an Standort A ersetzt werden. Es ist geplant, den Master-Knoten 1.101 und den Slave-Knoten 1.102 gleichzeitig auf die neuen Maschinen 1.103 und 1.104 zu migrieren, wobei 1.103 als Master-Knoten und 1.104 als Slave-Knoten fungiert. 2.101 und 2.102 an Standort B bleiben unverändert, aber nach Abschluss der Migration werden 1.103 und 2.101 gegenseitige Doppelmaster. Das Architekturdiagramm ist in Abbildung 5 dargestellt. Da es sich um eine Dual-Master-Struktur handelt, schreiben beide Seiten gleichzeitig. Wenn Sie den Master-Knoten ersetzen möchten, muss ein Knoten die Bereitstellung einstellen.

• Abbildung 5 Diagramm der maschinenraumübergreifenden Migrationsarchitektur mit Dual-Primärstruktur
• Die spezifische Methode ist wie folgt:

• 1.103 und 1.104 neue Instanzen: Stellen Sie eine Master-Slave-Beziehung her. Zu diesem Zeitpunkt sind der Master-Knoten und der Slave-Knoten nicht geladen PROZESSLISTE) und achten Sie darauf, dass sich der MASTERSTATUS nicht mehr ändert. Beobachten Sie den Maschinenverkehr, nachdem Sie bestätigt haben, dass er korrekt ist. Stoppen Sie den Dienst des 1.102-Slave-Knotens. 1.103 Erstellen Sie nach Abschluss den MySQL-Dienst Sichern Sie das gesamte Datenverzeichnis mv an anderen Orten. ;

• Kopieren Sie das gesamte MySQL-Datenverzeichnis von 1.102 nach 1.103 mit rsync;

Während des Kopierens , autorisieren Sie 1.101, damit 1.103 die Berechtigungen von binlog abrufen kann (REPLICATION SLAVE, REPLICATION CLIENT);

Ändern Sie nach Abschluss des Kopiervorgangs die server_id in der 1.103-Konfigurationsdatei. Seien Sie vorsichtig um nicht mit der Version 1.102 übereinzustimmen;

Starten Sie die MySQL-Instanz in 1.103, achten Sie auf den Datendateipfad in der Konfigurationsdatei und die Berechtigungen des Datenverzeichnisses

Geben Sie die MySQL-Instanz 1.103 ein und verwenden Sie SHOW SLAVE STATUS, um den Slave-Status zu überprüfen. Sie können sehen, dass Seconds_Behind_Master dekrementiert wird.

Nachdem Seconds_Behind_Master 0 wird, Dies bedeutet, dass die Synchronisierung abgeschlossen ist. Zu diesem Zeitpunkt können Sie mit pt-table-checksum überprüfen, ob die Daten von 1.101 und 1.103 konsistent sind. Dies ist jedoch zeitaufwändig und hat Auswirkungen auf den Masterknoten zusammen mit der Entwicklung;

Wir verwenden die gleiche Methode, um 1.104 in eine Slave-Bibliothek von 1.103 umzuwandeln

Zusätzlich zu Überprüfung der Datenkonsistenz und Kontoberechtigungen müssen ebenfalls überprüft werden, um Zugriffsfehler nach der Geschäftsmigration zu verhindern.

Zu diesem Zeitpunkt müssen wir 1.103 in die Slave-Bibliothek umwandeln von 2.101. Beziehen Sie sich für spezifische Methoden bitte auf Szenario 4; >

Nach Abschluss der oben genannten Schritte können Sie sich mit der Forschung und Entwicklung abstimmen, um 1.101 zu lesen und zu schreiben. Das Geschäft wird auf 1.103 reduziert, und das Lesegeschäft von 1.102 wird auf 1.104 reduziert. Beobachten Sie den Geschäftsstatus;

Wenn es keine Probleme mit dem Geschäft gibt, ist die Migration erfolgreich.

3.6 Szenario 6 Multi-Instanz-übergreifende Computerraummigration

Als nächstes schauen wir uns den Beweis der multi-instanzübergreifenden computerraumübergreifenden Migration an . Für die Instanzbeziehung jeder Maschine können wir uns auf Abbildung 6 beziehen. Der Zweck dieser Migration besteht darin, eine Datenreparatur durchzuführen. Erstellen Sie die Instanzen 7938 und 7939 auf 2.117, um die vorherigen Instanzen durch abnormale Daten zu ersetzen. Aus geschäftlichen Gründen werden einige Bibliotheken nur an Standort A geschrieben, und einige Bibliotheken werden nur an Standort B geschrieben, sodass eine Situation der synchronen Filterung vorliegt.

Abbildung 6 Architekturdiagramm für die maschinenraumübergreifende Migration mehrerer Instanzen

Die spezifische Methode lautet wie folgt:

1.113 Verwenden Sie innobackupex für 7936-Instanzen. Um eine Datensicherung durchzuführen, beachten Sie bitte, dass Sie die Datenbank angeben und den Slave-Info-Parameter hinzufügen müssen.

Nachdem die Sicherung abgeschlossen ist, kopieren Sie die komprimierte Datei nach 2.117;
2.117 Erstellen Sie das Datenverzeichnis und die zugehörigen Verzeichnisse in der Konfigurationsdatei
2.117 Verwenden Sie innobackupex, um Protokolle wiederherzustellen;

• 2.117 Verwenden Sie innobackupex, um Daten zu kopieren.

• 2.117 Ändern Sie die Konfigurationsdatei und achten Sie auf die folgenden Parameter: Replicate-ignore-db, innodb_file_per_table = 1 , read_only = 1, server_id;

• 2.117 Datenverzeichnisberechtigungen ändern;

• 1.112 Berechtigung zum Abrufen von Binlog ( REPLIKATIONS-SLAVE, REPLICATION CLIENT); Überprüfen Sie den Slave-Status;

• 2.117 zum Erstellen von 7939. Die Methode ist ähnlich, aber in der Konfigurationsdatei muss „replication-wild-do-table“ angegeben werden >
Arbeiten Sie mit der Entwicklung zusammen, um die Datenkonsistenz zu überprüfen und Kontoberechtigungen zu überprüfen, um Zugriffsfehler nach der Geschäftsmigration zu verhindern. ;
Nach Abschluss der oben genannten Schritte können Sie sich mit der Forschung und Entwicklung abstimmen, um die entsprechende Migration durchzuführen Geschäft zur 7938-Instanz und 7939-Instanz von 2.117. Beobachten Sie den Geschäftsstatus;
Wenn es keine Probleme mit dem Geschäft gibt, ist die Migration erfolgreich.
Vier Hinweise

• Nachdem Sie die Migrationslösungen für verschiedene Szenarien vorgestellt haben, müssen Sie auf die folgenden Punkte achten:

• Datenbankmigration: Wenn

  Ereignis
beteiligt ist, denken Sie daran, den Parameter „event_scheduler“ auf dem Masterknoten zu aktivieren.
Unabhängig vom Migrationsszenario müssen Sie dies immer tun Achten Sie auch auf den Serverstatus, z. B. den Speicherplatz und den Netzwerk-Jitter Wenn Sie keine Fehler machen, sind die Daten inkonsistent oder die Master-Slave-Beziehung kann nicht hergestellt werden.
Führen Sie das Skript nicht aus $HOME-Verzeichnis, denken Sie daran, dies im Datenverzeichnis zu tun;

Die Migrationsarbeit kann mithilfe von Skripten automatisiert werden, aber seien Sie nicht selbstzerstörerisch. Jedes Skript muss getestet werden ;

• Überlegen Sie zweimal, bevor Sie einen Befehl ausführen, und verstehen Sie die Bedeutung der Parameter jedes Befehls ;

In einer Umgebung mit mehreren Instanzen , verwenden Sie mysqladmin, um MySQL zu schließen.
Denken Sie an die Datenbank read_only = 1 plus, dadurch werden viele Probleme vermieden 🎜>
• Die server_id jeder Maschine muss konsistent sein, sonst treten Synchronisierungsausnahmen auf

• Replikat-ignore-db und Replikat-Wild-Do-Tabelle korrekt konfigurieren; >

• Denken Sie daran, innodb_file_per_table für die neu erstellte Instanz auf 1 zu setzen. Da dieser Parameter in der vorherigen Instanz 0 war, war ibdata1 zu groß und die Sicherung und Übertragung dauerte viel

• Wenn Sie gzip zum Komprimieren von Daten verwenden, beachten Sie bitte, dass gzip nach Abschluss der Komprimierung die Quelldatei löscht Alle Vorgänge müssen auf dem Slave-Knoten oder Standby-Knoten ausgeführt werden. Wenn der Vorgang auf dem Primärknoten ausgeführt wird, ist der Primärknoten wahrscheinlich ausgefallen.

• xtrabackup-Sicherung sperrt die InnoDB-Tabelle nicht , sperrt aber die MyISAM-Tabelle. Denken Sie daher vor dem Betrieb daran, zu überprüfen, ob die aktuelle Datenbanktabelle die MyISAM-Speicher-Engine verwendet. Wenn ja, verarbeiten Sie sie entweder separat oder ändern Sie die Engine der Tabelle.

• Fünf Tipps

Bei der tatsächlichen MySQL-Migration können die folgenden Techniken verwendet werden:

Jede Migrations-LOG-DATEI in „relay_master_log_file“. (der Name des Binlog-Protokolls auf dem Master, das synchronisiert wird) hat Vorrang, und der LOG POS unterliegt exec_master_log_pos (dem POS-Punkt des aktuellen Binlog-Protokolls, das synchronisiert wird); Verwenden Sie rsync zum Kopieren von Daten, was mit „expect“ kombiniert werden kann. Die Verwendung von „nohup“ ist absolut eine wunderbare Kombination.

• Sie können gzip zur Komprimierung verwenden, während Sie innobackupex zum Sichern von Daten verwenden;

• Bei Verwendung von innobackupex zum Sichern von Daten können Sie den Parameter –slave-info hinzufügen, um die Slave-Datenbank zu vereinfachen.

• Bei Verwendung von innobackupex für Um Daten zu sichern, können Sie den Parameter –throttle hinzufügen, um IO zu begrenzen und die Auswirkungen auf das Unternehmen zu reduzieren. Sie können auch den Parameter –parallel=n hinzufügen, um die Sicherung zu beschleunigen. Beachten Sie jedoch, dass der Parameter –parallel bei Verwendung der TAR-Stream-Komprimierung ungültig ist.

• Für die Datensicherung und Wiederherstellung können Sie eine To-Do-Liste erstellen, einen Prozess zeichnen und die Befehle vorbereiten, die im Voraus ausgeführt werden müssen.

• Eine gute Möglichkeit, einen Ordner schnell lokal zu kopieren, ist um rsync zu verwenden, plus die folgenden Parameter: -avhW –no-compress –progress

• Um Daten schnell zwischen verschiedenen Partitionen zu kopieren, können Sie dd verwenden. Oder verwenden Sie eine zuverlässigere Methode: Sichern Sie es auf der Festplatte und legen Sie es dann auf dem Server ab. An anderen Orten gibt es noch etwas Besseres, die direkte

  Expresszustellung
Festplatte.
Sechs Zusammenfassung

• Dieser Artikel beginnt damit, warum wir migrieren müssen, spricht dann über den Migrationsplan, erklärt dann die tatsächliche Migration in verschiedenen Szenarien und gibt schließlich die Notizen. Angelegenheiten und praktische Fähigkeiten. Zusammenfassend gibt es die folgenden Punkte: Erstens besteht der Zweck der Migration darin, einen reibungslosen und kontinuierlichen Geschäftsablauf zu gewährleisten.

  Zweitens besteht der Kern der Migration darin, wie die Master-Slave-Synchronisierung fortgesetzt werden kann. Wir müssen dies auf verschiedenen Servern tun und Lösungen zwischen verschiedenen Unternehmen finden.
Drittens müssen beim Geschäftswechsel die Reihenfolge der Lese- und Schreibtrennung auf verschiedenen Maschinen und die Notwendigkeit der Master-Slave-Beziehung berücksichtigt werden zu berücksichtigen; die Auswirkungen maschinenübergreifender Raumaufrufe auf das Unternehmen müssen berücksichtigt werden.

Leser können während des Migrationsprozesses auf die in diesem Artikel bereitgestellten Ideen zurückgreifen. Wie jedoch sichergestellt werden kann, dass jeder Vorgang ordnungsgemäß ausgeführt wird, erfordert sorgfältige Überlegungen, bevor Sie fortfahren.

Nebenbei: „Das Wichtigste, um zu beweisen, dass man fähig ist, ist, alles unter Kontrolle zu halten.“

Das obige ist der detaillierte Inhalt vonMySQL-Migrationslösungen unter verschiedenen Umständen (empfohlen). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!