Lösung zur Überprüfung des ID-Überlauffehlers bei automatischer Inkrementierung der MySQL-Tabelle

Problem: Der Überlauf der Auto-Increment-ID in einer MySQL-Tabelle führte zu einem Business-Block

Hintergrund:

Eine große Tabelle tb1 der tokudb-Engine speichert Audit-Protokolle von Geschäftsmaschinen. Jeden Tag werden große Mengen an Daten geschrieben. Aus historischen Gründen ist diese Tabelle vom Typ int mit Vorzeichen und kann maximal 2147483647 Zeilen speichern.

Verarbeitungsprozess:

Fügen Sie einen DBLE-Middleware-Agenten hinzu, führen Sie eine Bereichspartitionierung durch und schreiben Sie neue Daten in einen neu hinzugefügten Shard. Gleichzeitig hat das Unternehmen die Verbindung geändert und den Verbindungsmodus dieser Tabelle tb1 auf DBLE geändert. Nachdem der Geschäftscode geändert wurde, stellte sich jedoch heraus, dass einige verbleibende Schreibanforderungen zum Einfügen in TB1 an die alte Tabelle weitergeleitet wurden und einige Tabellen fälschlicherweise an DBLE weitergeleitet wurden. Dies macht die Sache noch komplizierter. Nachdem der Code, der tb1 geschrieben hatte, offline genommen wurde, normalisierte sich der gesamte Geschäftsbetrieb schließlich wieder.

Nachdem ich die Situation geprüft hatte, dachte ich, dass der DBA in diesem Fall bei Problemen mit den Protokolltabellen schnelle und entschlossene Maßnahmen ergreifen sollte, um den Betrieb so schnell wie möglich wiederherzustellen und sich dann mit anderen Problemen zu befassen. Wenn wir so denken, kann das obige Problem leicht gelöst werden. Nur wenige Schritte:

logdb verwenden;

select max(id) from tb1; -- Zeichnet die aktuelle maximale ID als xxxx auf.
create table tb2 LIKE tb1; -- Eine Schattentabelle erstellen alter table tb2 modify column id bigint unsigned not null auto_increment; -- Die neue Tabelle in den Typ bigint unsigned ändern, der 18446744073709551615 Datenzeilen speichern kann.
alter table tb2 auto_increment=xxxx+1; -- Ändert den Startwert des Auto-Increment-Primärschlüssels der neuen Tabelle. rename table tb1 to tb_archive , tb2 to tb1; -- Ändert den Tabellennamen.

Nach diesem Vorgang können Daten in tb1 geschrieben und das Geschäft vorübergehend wiederhergestellt werden. Die verbleibende Arbeit besteht darin, die Daten in der Tabelle tb_archive nach tb1 zu migrieren (Sie können das Tool pt-archiver verwenden, um Daten zu migrieren und es langsam im Hintergrund auszuführen).

Nach einigen Berechnungen dauert das Ausschneiden der Tabelle und die Wiederaufnahme des geschäftlichen Schreibvorgangs höchstens etwa 5 Minuten, und die Auswirkungen auf die verbleibenden migrierten Daten sind relativ gering.

Nachfolgende Optimierungsmaßnahmen:

Fügen Sie eine Überwachung der Auto-Inkrement-ID hinzu, siehe hier https://www.jb51.net/article/184935.htm

Beheben Sie unerwartete Probleme, die bei der Produktion auftreten können, und formulieren Sie entsprechende Notfallpläne.

Dies ist das Ende dieses Artikels zur Fehlerbehebung und Lösung des ID-Überlaufs bei automatischer MySQL-Tabelleninkrementierung. Weitere verwandte Inhalte zum ID-Überlauf bei automatischer MySQL-Tabelleninkrementierung finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!