it-swarm.com.de

ALTER Primärschlüsselspalte von INT nach BIGINT in der Produktion (MySQL 5.6.19a)

Einige INNODB-Tabellen in unserer Produktionsdatenbank erreichen bald das INT AUTO_INCREMENT-Limit von 2147483647 und müssen in BIGINT geändert werden, da sonst die Schreibvorgänge fehlschlagen.

Die Tabellen befinden sich in einer MySQL 5.6.19a-Produktionsdatenbank, die unter Amazon RDS ausgeführt wird.

Wie können wir einen solchen ALTER durchführen, ohne die ständig stattfindenden Produktionslesevorgänge und Einfügungen zu stören?

ALTER TABLE MYTABLE CHANGE idid BIGINT NOT NULL AUTO_INCREMENT;

Hier ist DDL für die Tabelle:

CREATE TABLE `MYTABLE` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `siteId` int(11) NOT NULL,
  `filter` varchar(10) NOT NULL DEFAULT 'ALL',
  `date` varchar(10) NOT NULL,
  `cards` varchar(250) NOT NULL,
  `apples` varchar(45) NOT NULL,
  `carrots` varchar(45) NOT NULL,
  `corn` varchar(45) NOT NULL,
  `peas` varchar(45) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique` (`siteId`,`filter`,`date`,`cards`),
  KEY `date_k` (`date`),
  KEY `cards_k` (`cards`),
  KEY `apples_k` (`apples`),
  KEY `siteId_k` (`siteId`)
) ENGINE=InnoDB AUTO_INCREMENT=1748961482 DEFAULT CHARSET=utf8
20
Mark Hansen

Wenn Sie über genügend Speicherplatz verfügen, können Sie eine Kopie der tatsächlichen Tabelle erstellen und die folgenden Arbeiten ausführen:

CREATE TABLE new_tbl [AS] SELECT * FROM orig_tbl;

Dann können Sie die Spalte wie gewünscht ändern:

ALTER TABLE tbl_name MODIFY COLUMN col_name BIGINT AUTO_INCREMENT;

Sobald der Vorgang abgeschlossen ist, können Sie die Tabellen umbenennen:

RENAME TABLE tbl_name TO new_tbl_name, tbl_name2 TO new_tbl_name2;

Lassen Sie dann die ursprüngliche Tabelle fallen, und Sie sollten das erwartete Ergebnis haben.

22
kriegu

das percona Toolkit ist der richtige Weg, zumindest wenn Sie nicht sehr wenig Zeit haben. Die Konvertierung dauerte auf unserem Tisch (500 GB, Master-Slave-Setup), als wir sie etwas länger als 24 Stunden testeten. In der Produktion dauerte es (mit besserer Hardware) fast 1 Monat (lustige Nebenbemerkung, die wir ungefähr 30 Tage hatten, bevor uns die Zeit ausgegangen war) IDs, daher haben wir bereits begonnen, Plan B und C zu planen, mit Offline-Backups zu arbeiten, Slaves zu entfernen, ...). Die Verzögerung war hauptsächlich auf das Warten der Replikation in Richtung der Slaves zurückzuführen (wir erlaubten eine maximale Verzögerung von 50 Sekunden). Stellen Sie außerdem sicher, dass die Anzahl der gleichzeitigen Threads begrenzt ist. Wir haben mehr als 2 Millionen Beilagen pro Tag und viele Millionen Lesevorgänge.

Beachten Sie auch, dass Sie die Coversion nach dem Start nicht mehr stoppen können (oder zumindest keine Möglichkeit gefunden haben, sie neu zu starten) :-(

4
Maze

Gut....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) ist mit dem PRIMARY KEY redundant, Sie können ihn also auch fallen lassen.

INT UNSIGNED würde Sie auf 4 Milliarden bringen, wird das ausreichen?

Ändern Sie filter in ENUM.

Haben Sie 1,75 Milliarden Zeilen? Oder haben Sie viele Ausweise "verbrannt"? Wenn ja, können wir das vielleicht beheben? Zum Beispiel werfen REPLACE und bestimmte Varianten von INSERT IDs. INSERT...ON DUPLICATE KEY Kann normalerweise REPLACE ersetzen. Ein zweistufiger Prozess kann das Brennen von IDs durch INSERT IGNORE Vermeiden.

Zurück zur Frage ...

Überprüfen Sie, ob pt-online-schema-change den Trick ausführt: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html

1
Rick James