Ein MySQL-Migrationsplan und eine praktische Auflistung der Fallstricke

Hintergrund

Da historische Geschäftsdaten in MySQL gespeichert werden, gibt es eine Operationsdatensatztabelle namens video_log. Immer wenn ein Benutzer einen Datensatz erstellt, aktualisiert oder ein Prüfer einen Datensatz überprüft, wird dem entsprechenden video_log ein Protokoll hinzugefügt. Diese Protokolltabelle hat nur Einfügungen. Wie Sie sich vorstellen können, entspricht ein Video mehreren Protokollen. Bei 100.000 Videos pro Tag bedeuten durchschnittlich 5 Protokolle für ein Video 500.000 Protokolle pro Tag, 50 * 30 = 15 Millionen Datensätze pro Monat und 1500 * 12 = 180 Millionen Datensätze pro Jahr. Derzeit sind mehr als 200 Millionen Daten online. Da das Protokoll selbst nicht auf das C-Ende ausgerichtet ist und zur Abfrage von Problemen verwendet wird, kann eine leichte Verzögerung toleriert werden. Da es jedoch mit der Zeit zwangsläufig immer langsamer wird und die Effizienz beeinträchtigt, wurde die Idee einer Transformation vorgeschlagen.

Lösung 1: Alte Daten sichern

Da das Protokoll selbst nicht die kritischsten Daten sind, aber auch eine hohe Echtzeitleistung erfordern (für Echtzeitabfrageprobleme), bestand die ursprüngliche Idee darin, den grundlegenden Kernspeicher unverändert zu lassen und die älteren Daten auszulagern. Schließlich ist die Wahrscheinlichkeit, dass plötzlich Betriebsaufzeichnungen von vor einem Jahr abgefragt werden, sehr gering. Wenn Sie sie plötzlich überprüfen müssen, können Sie offline gehen. In Bezug auf das Design benötigen wir lediglich ein geplantes Skript, um täglich gegen 4 Uhr morgens (außerhalb der Geschäftszeiten) Daten zu extrahieren. Die extrahierten Daten können an einen Offline-Speicher gemeldet werden (im Allgemeinen verfügen Unternehmen über Hive-basierte Data Warehouses usw.), sodass die Online-Videoprotokolldaten nicht weiter wachsen.

Option 2: Tabelle teilen

Auch das Aufteilen von Tabellen ist eine Lösung. Der Vorteil gegenüber Lösung 1 liegt darin, dass alle Daten in Echtzeit abgefragt werden können. Der Nachteil besteht darin, dass der Code angepasst werden muss.

• Bestätigen Sie zunächst den Sharding-Schlüssel. Da video_log an Video gebunden ist, wählen wir natürlich video_id als unseren Sharding-Schlüssel.
• Nachdem wir entschieden haben, wie die Tabellen aufgeteilt werden, müssen wir bestätigen, in wie viele Tabellen sie aufgeteilt werden sollen. Setzen Sie sich zunächst ein kleines Ziel und bleiben Sie drei Jahre lang dabei. Die maximale Datenmenge in jeder Tabelle beträgt 100 Millionen (weil unsere Abfrage einfach ist). Gemäß der obigen Statistik werden wir in drei Jahren ungefähr 3*1,8=540 Millionen haben, also werden wir ungefähr 5,4/1≈6 Tabellen benötigen.

Der nächste Schritt besteht darin, den Code zu transformieren und das Problem des Lesens und Schreibens neuer und alter Daten zu lösen.

• Neue Daten werden direkt in die neue Tabelle eingefügt
• Da die Protokolltabelle nur Einfügevorgänge und keine Aktualisierungs- und Löschvorgänge aufweist, müssen diese Szenarien nicht berücksichtigt werden.
• Da das Protokoll eines Videos nach der Tabellenaufteilung in zwei Tabellen (der alten und der neuen Tabelle) vorhanden ist, werden beide Tabellen vorübergehend überprüft und anschließend zusammengeführt.
• Alte Daten mit der neuen Tabelle synchronisieren
• Offlinecode zum Lesen alter Tabellen

Lösung 3: Migration zu tidb

Die Nachteile von Option 2 liegen auf der Hand. Was tun nach 3 Jahren? Den Zähler weiter demontieren? Ich habe das Gefühl, dass da immer eine historische Schuld ist. Wir haben uns also für tidb entschieden, eine verteilte Datenbank. Sobald wir eine Verbindung zu tidb hergestellt haben, müssen wir uns keine Gedanken mehr über das Sharding von Tabellen machen. Tidb erledigt das alles für uns und erweitert die Knotenkapazität selbstständig. Da es verteilt ist, ist der Primärschlüssel von tidb ungeordnet, was sehr wichtig ist.
Der gesamte Prozess lässt sich grob in die folgenden 4 Schritte unterteilen:

1. Zuerst doppelt schreiben (die MySQL-ID aufzeichnen, wenn mit dem doppelten Schreiben begonnen wird. Die Daten vor dieser ID müssen alte Daten sein)
2. Alte Daten synchronisieren (unterscheidet sich durch die im ersten Schritt erfasste ID)
3. Auslesen (Synchronisation alter Daten abgeschlossen)
4. Doppeltes Schreiben

Konzentrieren wir uns auf die Fallstricke bei der Synchronisierung alter Daten.

Die Migration zu tidb scheint einfach, aber im Job-Skript sind tatsächlich einige Fallstricke versteckt.

• Sie müssen überlegen, was zu tun ist, wenn der Job mittendrin unterbrochen wird und Sie ihn neu starten müssen. Abgesehen vom Zeitaufwand für die erneute Ausführung der Daten werden die synchronisierten Daten bei der erneuten Ausführung dupliziert, und Sie müssen auch das Problem doppelter Daten berücksichtigen. Um das Problem doppelter Daten zu lösen, können Sie der alten Tabelle ein neues Feld hinzufügen, um anzugeben, ob sie synchronisiert wurde. Aktualisieren Sie das Feld jedes Mal, wenn die Synchronisierung abgeschlossen ist. Nachteile: Die Online-Daten sind groß, das Hinzufügen eines Feldes ist nicht sicher und kann zu einer Online-Überlastung führen.
• Da das Hinzufügen eines Felds keine gute Idee ist, verwenden Sie die vorhandene Primärschlüssel-ID als Einschränkung und synchronisieren Sie die Primärschlüssel-ID. Auf diese Weise wird, selbst wenn das Skript neu gestartet und von Anfang an ausgeführt wird, ein Fehler gemeldet und es wird übersprungen, weil derselbe Primärschlüssel eingefügt wurde. Es scheint perfekt, aber TIDB ist verteilt und die Primärschlüssel-ID ist nicht kontinuierlich, sodass diese Situation auftreten kann. Wenn normale Geschäftsdaten in tidb eingefügt werden, werden die von tidb zugewiesene Primärschlüssel-ID und die mit MySQL synchronisierte Primärschlüssel-ID wiederholt. In diesem Fall schlägt der letzte Eintrag definitiv fehl, unabhängig davon, wer ihn einfügt.

Endgültige Synchronisierungsskriptlösung

Unter Berücksichtigung der Datenduplizierung, der Effizienz des Jobneustarts und der Effizienz der gesamten Synchronisierung habe ich grob den folgenden Plan erstellt:

1. Verbessern Sie die Effizienz, indem Sie Aufgaben in Stapel aufteilen: Teilen Sie zunächst die alten Daten entsprechend der Verarbeitungskapazität und der erwarteten Fertigstellungszeit in Stapel auf. Es gibt ungefähr 10 Stapel. 10 Jobs führen unterschiedliche Datenstapel aus, ohne sich gegenseitig zu stören, und jedes Mal werden 100 Elemente in Stapeln aktualisiert.
2. Den Status aufzeichnen und nach dem Neustart automatisch zum Haltepunkt wiederherstellen: Nach jeder Datensynchronisierung wird die aktuelle Synchronisationsposition aufgezeichnet (Redis zeichnet die aktuelle ID auf). Auch wenn es neu gestartet wird, kann die vorherige Aktualisierungsposition von Redis abgerufen und dann aktualisiert werden.
3. Vermeiden Sie Primärschlüsselkonflikte: Synchronisieren Sie alle Felder außer dem Primärschlüssel (synchronisieren Sie den Primärschlüssel nicht).

Abschließend wurde die Datenmigration durch die vier Umschaltschritte von Lösung 3 + effizientes Synchronisierungsskript reibungslos abgeschlossen.

Zusammenfassen

Dies ist das Ende dieses Artikels über MySQL-Migrationslösungen und Fallstricke. Weitere relevante MySQL-Migrationslösungen und Fallstricke finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder lesen Sie die folgenden verwandten Artikel weiter. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!