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

20

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

Таблицы находятся в рабочей базе данных MySQL 5.6.19a, работающей на Amazon RDS.

Как мы можем сделать ALTER, как это, не прерывая производственные операции чтения и вставки, которые происходят все время?

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
mysql innodb Марк Хансен
источник

Ответы:

22

Если у вас достаточно места, вы можете создать копию фактической таблицы и выполнить работу над этим:

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;

Затем отбросьте исходную таблицу, и вы получите ожидаемый результат.

kriegu
источник
Я использовал этот подход, потому что я мог отключить записи (которые все являются пакетным режимом) в таблицу при выполнении копирования. Заняло около 36 часов.
Марк Хансен
и вы хотите сохранить эти три в одной транзакции. (блокировка / разблокировка)
Славомир Ленарт
4

Percona Toolkit - это путь, по крайней мере, если вы не слишком коротки во времени. Преобразование потребовалось на нашем столе (500 Гб, настройка «главный-подчиненный»), когда мы протестировали его чуть более чем за 24 часа, в производстве это заняло (с лучшим аппаратным обеспечением) почти 1 месяц (забавный sidenote, у нас было около 30 дней, прежде чем у нас закончились идентификаторы, поэтому мы уже начали планировать планы B и C, работая с автономными резервными копиями, удаляя подчиненных, ...). Задержка произошла в основном из-за ожидания репликации, ведущей к подчиненным устройствам (мы допустили максимальную задержку в 50 секунд). Также убедитесь, что ограничено количество одновременных потоков. У нас более 2 миллионов вкладок в день и много миллионов операций чтения.

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

Лабиринт
источник
1

Что ж....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) избыточен с ПЕРВИЧНЫМ КЛЮЧОМ, так что вы можете также УДАЛИТЬ его.

INT UNSIGNED даст вам 4 миллиарда, этого будет достаточно?

Рассмотреть вопрос о переходе filterна ENUM.

У вас есть 1,75 миллиарда строк? Или ты "сжег" много идентификаторов? Если так, может быть, мы можем это исправить? Например REPLACEи определенные ароматы INSERTволи бросают идентификаторы. INSERT...ON DUPLICATE KEYобычно можно заменить REPLACE. Двухэтапный процесс может избежать INSERT IGNOREзаписи идентификаторов.

Вернуться к вопросу ...

Посмотрите, поможет ли pt-online-schema-change: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html

Рик Джеймс
источник
Могу ли я использовать Percona с Amazon RDS? Да, мы «сожгли» множество идентификаторов, таблица содержит около 330 миллионов строк.
Марк Хансен
Я не знаю о Pt & RDS. Если бы вы могли устранить горение, у вас есть еще ~ 330M идентификаторов, прежде чем вы выйдете из комнаты.
Рик Джеймс