ALTER стовпчик первинного ключа від INT до BIGINT у виробництві (MySQL 5.6.19a)

Деякі таблиці INNODB в нашій виробничій базі збираються досягти межі INT AUTO_INCREMENT 2147483647, і нам потрібно змінити їх на BIGINT, інакше записи почнуть виходити з ладу.

Таблиці знаходяться у виробничій базі даних MySQL 5.6.19a, що працює на Amazon RDS.

Як ми можемо зробити АЛЬТЕР так, не порушуючи зчитування та вставки, які відбуваються постійно?

ALTER TABLE MYTABLECHANGE id idBIGINT NOT NULL AUTO_INCREMENT;

Ось DDL для таблиці:

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

Якщо у вас є достатньо місця, ви можете створити копію фактичної таблиці та виконати роботу над цим:

CREATE TABLE new_tbl [AS] SELECT * FROM orig_tbl;

Потім ви можете змінити стовпець за бажанням:

ALTER TABLE tbl_name MODIFY COLUMN col_name BIGINT AUTO_INCREMENT;

Після завершення процесу можна перейменувати таблиці:

RENAME TABLE tbl_name TO new_tbl_name, tbl_name2 TO new_tbl_name2;

Потім опустіть оригінальну таблицю, і ви повинні мати прогнозований результат.

Інструментарій percona - це шлях, принаймні, якщо ви не надто короткий у часі. Перетворення відбулося на нашому столі (500Gb, майстер-раб-налаштування), коли ми перевірили його трохи більше, ніж за 24 години, у виробництві це зайняло (з кращим обладнанням) майже 1 місяць (кумедний sidenote у нас було близько 30 днів, перш ніж ми закінчилися ID, тому ми вже почали планувати плани B і C, працюючи з автономними резервними копіями, видаляючи раби, ...). Затримка в основному була пов'язана з очікуванням реплікації, що відбувається в бік рабів (ми дозволяли максимум 50 секунд часу). Також не забудьте обмежити кількість одночасних потоків. У нас більше 2 млн вставок / день та багато мільйонів читань.

Також пам’ятайте, що після запуску обкладинки ви не можете її зупинити (або, принаймні, ми не знайшли жодного способу її перезапустити) :-(

Добре....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) є зайвим з ПЕРШИМИ КЛЮЧАМИ, тому ви можете також ДРОПУВАТИ його.

НЕ УПРАВЛЕНО принесе вам 4 мільярди, це буде достатньо?

Подумайте про зміну filterна ENUM.

У вас 1,75 мільярда рядків? Або ти "спалив" багато ід? Якщо так, можливо, ми можемо це виправити? Наприклад, REPLACEпевні аромати INSERTволі підкидають ідентифікатори. INSERT...ON DUPLICATE KEYзазвичай може замінити REPLACE. Двоетапний процес дозволяє уникнути INSERT IGNOREспалювання ідентифікаторів.

Повернутися до питання ...

Перевірте, чи змінить схему pt-online-схеми: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html