ALTERAR la columna de clave principal de INT a BIGINT en producción (MySQL 5.6.19a)

20

Algunas tablas INNODB en nuestra base de datos de producción están a punto de alcanzar el límite INT AUTO_INCREMENT de 2147483647 y necesitamos modificarlas a BIGINT, de lo contrario las escrituras comenzarán a fallar.

Las tablas están en una base de datos MySQL 5.6.19a de producción que se ejecuta en Amazon RDS.

¿Cómo podemos hacer un ALTER como este sin interrumpir las lecturas e inserciones de producción que están sucediendo todo el tiempo?

ALTER TABLE MYTABLECHANGE id idBIGINT NOT NULL AUTO_INCREMENT;

Aquí está DDL para la tabla:

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
mysql innodb Mark Hansen
fuente

Respuestas:

22

Si tiene suficiente espacio, puede crear una copia de la tabla real y hacer el trabajo sobre eso:

CREATE TABLE new_tbl [AS] SELECT * FROM orig_tbl;

Luego puede cambiar la columna como desee:

ALTER TABLE tbl_name MODIFY COLUMN col_name BIGINT AUTO_INCREMENT;

Una vez que se realiza el proceso, puede cambiar el nombre de las tablas:

RENAME TABLE tbl_name TO new_tbl_name, tbl_name2 TO new_tbl_name2;

Luego suelte la tabla original, y debería tener el resultado esperado.

kriegu
fuente
Utilicé este enfoque porque pude desactivar las escrituras (que son todos modo por lotes) en la tabla mientras hacía la copia. Tomó alrededor de 36 horas.
Mark Hansen
y desea mantener estas tres en una transacción. (bloquear / desbloquear)
Sławomir Lenart
4

Percona Toolkit es el camino a seguir, al menos si no es muy corto en el tiempo. La conversión se hizo cargo de nuestra mesa (500 Gb, configuración maestro-esclavo) cuando la probamos un poco más de 24 horas, en producción tardó (con un mejor hardware) casi 1 mes (nota al margen curiosa que teníamos unos 30 días antes de que nos quedáramos sin ID, por lo tanto, ya comenzamos a planificar los planes B y C, trabajando con copias de seguridad fuera de línea, eliminando esclavos, ...). El retraso se debió principalmente a la espera de que la replicación ocurriera hacia los esclavos (permitimos un retraso máximo de 50 segundos). También asegúrese de limitar el número de hilos concurrentes. Tenemos más de 2 millones de inserciones / día y muchos millones de lecturas.

También tenga en cuenta que una vez que la cobertura ha comenzado, no puede detenerla (o al menos no encontramos ninguna forma de reiniciarla) :-(

Laberinto
fuente
1

Bien....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) es redundante con la CLAVE PRIMARIA, por lo que es mejor que la DEJE caer.

INT UNSIGNED te llevaría a 4 mil millones, ¿será suficiente?

Considere cambiar filtera un ENUM.

¿Tienes 1,75 mil millones de filas? ¿O "quemaste" muchos identificadores? Si es así, ¿tal vez podamos arreglar eso? Por ejemplo REPLACEy ciertos sabores de INSERTarrojarán identificadores. INSERT...ON DUPLICATE KEYPor lo general, puede reemplazar REPLACE. Un proceso de 2 pasos puede evitar INSERT IGNOREla quema de identificadores.

De vuelta a la pregunta ...

Vea si pt-online-schema-change hará el truco: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html

Rick James
fuente
¿Puedo usar la percona con Amazon RDS? Sí, hemos "quemado" muchas ID, la tabla en realidad tiene unos 330 millones de filas.
Mark Hansen
No sé sobre pt y RDS. Si pudieras eliminar la quema, tienes otros ~ 330M de identificación antes de que te quedes sin espacio.
Rick James