Colonna chiave primaria ALTER da INT a BIGINT in produzione (MySQL 5.6.19a)

Alcune tabelle INNODB nel nostro database di produzione stanno per raggiungere il limite INT AUTO_INCREMENT di 2147483647 e dobbiamo modificarle in BIGINT altrimenti le scritture inizieranno a fallire.

Le tabelle si trovano in un database MySQL 5.6.19 di produzione in esecuzione su Amazon RDS.

Come possiamo fare un ALTER come questo senza interrompere le letture e gli inserimenti di produzione che avvengono continuamente?

ALTER TABLE MYTABLECHANGE id idBIGINT NOT NULL AUTO_INCREMENT;

Ecco DDL per la tabella:

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

Se hai abbastanza spazio, puoi creare una copia della tabella effettiva e fare il lavoro su quello:

CREATE TABLE new_tbl [AS] SELECT * FROM orig_tbl;

Quindi è possibile modificare la colonna come desiderato:

ALTER TABLE tbl_name MODIFY COLUMN col_name BIGINT AUTO_INCREMENT;

Una volta terminato il processo, puoi rinominare le tabelle:

RENAME TABLE tbl_name TO new_tbl_name, tbl_name2 TO new_tbl_name2;

Quindi rilascia la tabella originale e dovresti avere il risultato rilevato.

percona toolkit è la strada da percorrere, almeno se non sei super corto di tempo. La conversione è arrivata sul nostro tavolo (500 GB, configurazione master-slave) quando l'abbiamo testato un po 'più di 24 ore, in produzione ci sono voluti (con hardware migliore) quasi 1 mese (divertente sidenote che avevamo circa 30 giorni prima che saremmo rimasti senza ID, quindi abbiamo già iniziato a pianificare il piano B e C, lavorando con backup offline, rimuovendo gli slave, ...). Il ritardo era principalmente dovuto all'attesa della replica in corso verso gli slave (abbiamo concesso un ritardo massimo di 50 secondi). Assicurati anche di limitare il numero di thread simultanei. Abbiamo oltre 2 milioni di inserti / giorno e molti milioni di letture.

Inoltre, tieni presente che una volta avviata la coverion non puoi fermarla (o almeno non abbiamo trovato alcun modo per riavviarla) :-(

Bene....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) è ridondante con il TASTO PRIMARIO, quindi puoi anche GOCCIARLO.

INT UNSIGNED ti porterebbe a 4 miliardi, basterà?

Valuta di passare filtera un ENUM.

Hai 1,75 miliardi di file? O hai "bruciato" un sacco di ID? Se è così, forse possiamo sistemarlo? Ad esempio REPLACEe alcuni gusti di INSERTwill lanciano id. INSERT...ON DUPLICATE KEYdi solito può sostituire REPLACE. Un processo in 2 passaggi può evitare INSERT IGNOREla masterizzazione di ID.

Torna alla domanda ...

Verifica se pt-online-schema-change farà il trucco: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html