Beispiel für die Migration einer MySQL-Online-Protokollbibliothek

Ich möchte Ihnen von einem aktuellen Fall erzählen. Eine Spielprotokollbibliothek auf dem Online-Alibaba-Cloud-RDS hatte kürzlich einige Probleme. Mit der steigenden Anzahl der Spieler wurde die Datenmenge in der Online-Protokollbibliothek immer größer. Die neueste Protokollbibliothek hat eine Größe von 50 GB erreicht und die Zeit für Online-Änderungen ist sehr lang.

Der Grund, warum dies nicht früher entdeckt wurde, war, dass die Protokollbibliothek zuvor nicht geändert worden war. Mit zunehmender Geschäftstätigkeit war es jedoch erforderlich, einige Spielattribute hinzuzufügen und die vorherige Protokollbibliothek zu ändern. Aufgrund des langen Wartungsfensters zögerten sowohl die Geschäftspartei als auch der DBA, dies zu tun, und eine Protokolloptimierung stand unmittelbar bevor.

Schauen wir uns zunächst die Protokollbibliothek an:

1. Die Protokollbibliothek enthält 5 große Tabellen mit einem Datenvolumen von über 50 Millionen.

2. Das monatliche Datenvolumen dieser fünf Tabellen beträgt vor dem Öffnen der Daten etwa 20 Millionen und wird nach dem Öffnen der Daten noch höher sein.

3. Die Indexgröße zweier Tabellen hat die Datendateigröße überschritten

Wir haben die Geschäfts- und Betriebsseite nach ihren Anforderungen an diese Tabellen gefragt. Diese lauten wie folgt:

1. Bewahren Sie die Daten der letzten drei Monate auf. Die restlichen Daten können weitergegeben werden, um eine Beeinträchtigung der Leistung des Online-Geschäfts zu vermeiden.

Daten von vor 2 bis 3 Monaten sollten in eine lokale Datenbank übertragen werden, die Abfragen unterstützt. Die Abfragegeschwindigkeit sollte nicht zu langsam sein, Abfragegeschwindigkeiten von Minuten sind akzeptabel.

3. Während des Migrationsprozesses kann die Protokollbibliothek einen Verlust von Tabellendaten für einige Minuten tolerieren und stellt keine hohen Anforderungen an die Echtzeitsynchronisierung von Daten.

4. Die Online-Protokollbibliothek muss Statistiken wie Benutzeraktivitäten unterstützen

5. Sie möchten kein Sharding von Datenbanken und Tabellen durchführen. In den letzten Monaten wurden viele SQL-Operationen abgefragt. Zwischen den Tabellen besteht eine gewisse Kopplung. Das Aufteilen der Tabellen ist für verwandte Operationen nicht förderlich.

Basierend auf der obigen Analyse und in Kombination mit der tatsächlichen Situation sieht der anfängliche Plan wie folgt aus:

1. Benennen Sie die Tabelle in der Online-Datenbank game_log um und erstellen Sie dann die Originaltabelle neu. Dieser Vorgang ist nicht kontinuierlich und kann einige Sekunden an Daten verlieren. Die spezifischen Vorgänge sind wie folgt:

#Der erste Schritt besteht darin, die Tabelle game_log.table in game_log_bak.table umzubenennen;

#Der zweite Schritt besteht darin, die Tabellenstruktur abzurufen. Wichtig ist der Wert von auto_increment.
#Stellen Sie sicher, dass beim Importieren von Daten innerhalb von drei Monaten keine Konflikte auftretenshow create table game_log_bak.table\G

#Der dritte Schritt besteht darin, die Tabellenstruktur des zweiten Schritts in der game_log-Bibliothek neu zu erstellen

2. Übertragen Sie die Daten in der umbenannten Bibliothek game_log_bak in die lokale Offlinedatenbank, die die Infobright-Speicher-Engine verwendet, um eine schnelle Abfrage von Offlinedaten zu unterstützen.

3. Sichern und bereinigen Sie die Daten in der Online-Tabelle, die älter als 3 Monate sind (ca. 40 G), und importieren Sie die Daten innerhalb von 3 Monaten (ca. 10 G) in der Online-Datenbank game_log_bak erneut in die Datenbank game_log. Die Struktur wird:

4. Löschen Sie die Bibliothek game_log_bak und erstellen Sie eine schreibgeschützte Slave-Bibliothek, um die Informationen der Bibliothek game_log in Echtzeit mit der Master-Bibliothek zu synchronisieren. Gehen Sie dazu wie folgt vor:

5. Synchronisieren Sie Daten von einem lokalen schreibgeschützten Slave, beispielsweise der lokalen Infobright-Datenbank. Die Synchronisierungsmethode kann mit dem Tool dataX wie folgt ausgewählt werden:

6. Richten Sie geplante Aufgaben ein, um abgelaufene Online-Daten in einem bestimmten Zeitraum zu bereinigen, um sicherzustellen, dass nur die Daten der letzten drei Monate online gespeichert bleiben, wodurch der Festplattenspeicherplatz von RDS nicht belastet wird.

Derzeit gibt es bei dieser Methode mehrere Probleme:

1. Bereinigen Sie regelmäßig Online-Daten. Der von diesen Daten belegte Tabellenspeicherplatz kann nicht sofort wiederhergestellt werden, was zu Fragmentierungsproblemen in der Datentabelle führen kann.

2. Wenn der Umfang des Spiels in Zukunft zunimmt, kann es immer noch Probleme mit diesem Problem geben. Zu diesem Zeitpunkt können Sie den Bereinigungszyklus der Protokolltabelle entsprechend anpassen. Wenn die Datenmenge zu groß ist, können Sie andere Lösungen in Betracht ziehen, um damit umzugehen.

Rückblickend gibt es noch einige Probleme beim Entwurf der Tabelle. Die Protokolltabelle sollte nur Flussdaten aufzeichnen und verwandte Abfragen vermeiden. Mit anderen Worten, Sie können das Datenvolumen im Voraus bewerten und dann vierteljährliche oder monatliche Tabellen verwenden, um eine so große Anzahl von Protokollen zu verarbeiten. Dies kann beim Bereinigen und Warten viel praktischer sein.

Oben sind die Details des MySQL Online-Log-Bibliotheksmigrationsbeispiels aufgeführt. Weitere Informationen zur MySQL Online-Log-Bibliotheksmigration finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!