ALTER kolumna klucza podstawowego od INT do BIGINT w produkcji (MySQL 5.6.19a)

Niektóre tabele INNODB w naszej produkcyjnej bazie danych wkrótce przekroczą limit INT AUTO_INCREMENT wynoszący 2147483647 i musimy je zmienić na BIGINT, w przeciwnym razie zapisy zaczną się nie powieść.

Tabele znajdują się w produkcyjnej bazie danych MySQL 5.6.19a działającej na Amazon RDS.

Jak możemy zrobić ALTER tak, aby nie zakłócać odczytywania produkcji i wstawek, które mają miejsce przez cały czas?

ALTER TABELA MYTABLEZMIANA id idWIELKA NIE NULL AUTO_INCREMENT;

Oto DDL dla tabeli:

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

Jeśli masz wystarczająco dużo miejsca, możesz utworzyć kopię rzeczywistej tabeli i wykonać na tym pracę:

CREATE TABLE new_tbl [AS] SELECT * FROM orig_tbl;

Następnie możesz zmienić kolumnę zgodnie z potrzebami:

ALTER TABLE tbl_name MODIFY COLUMN col_name BIGINT AUTO_INCREMENT;

Po zakończeniu procesu możesz zmienić nazwy tabel:

RENAME TABLE tbl_name TO new_tbl_name, tbl_name2 TO new_tbl_name2;

Następnie upuść oryginalną tabelę i powinieneś uzyskać oczekiwany wynik.

zestaw narzędzi percona to droga, przynajmniej jeśli nie masz bardzo krótkiego czasu. Konwersja objęła nasz stół (500 Gb, konfiguracja master-slave), kiedy testowaliśmy ją nieco ponad 24 godziny, w produkcji zajęło to (z lepszym sprzętem) prawie 1 miesiąc (zabawny sidenote mieliśmy około 30 dni, zanim zabrakło nam identyfikatory, dlatego zaczęliśmy już planować plan B i C, pracując z kopiami zapasowymi offline, usuwając urządzenia podrzędne ...). Opóźnienie było głównie spowodowane oczekiwaniem replikacji na niewolników (dopuszczaliśmy maksymalne opóźnienie 50 sekund). Upewnij się także, aby ograniczyć liczbę jednoczesnych wątków. Mamy ponad 2 mln wkładek dziennie i wiele milionów odczytów.

Pamiętaj również, że po rozpoczęciu tworzenia kowboju nie możesz go zatrzymać (a przynajmniej nie znaleźliśmy żadnego sposobu na jego ponowne uruchomienie) :-(

Dobrze....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) jest zbędny z KLUCZEM PODSTAWOWYM, więc równie dobrze możesz go ZROBIĆ.

INT UNSIGNED doprowadziłby cię do 4 miliardów, wystarczy?

Rozważ zmianę filterna ENUM.

Czy masz 1,75 miliarda wierszy? A może „spaliłeś” dużo identyfikatorów? Jeśli tak, to możemy to naprawić? Na przykład REPLACEi niektóre smaki INSERTpodrzucą identyfikatory. INSERT...ON DUPLICATE KEYzwykle może zastąpić REPLACE. Dwuetapowy proces pozwala uniknąć INSERT IGNOREwypalania identyfikatorów.

Powrót do pytania ...

Sprawdź, czy zmiana schematu pt-online załatwi sprawę: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html