Üretimde INT'den BIGINT'e ALTER birincil anahtar sütunu (MySQL 5.6.19a)

Üretim veritabanımızdaki bazı INNODB tabloları 2147483647 INT AUTO_INCREMENT sınırına ulaşmak üzereler ve bunları BIGINT olarak değiştirmemiz gerekiyor, aksi takdirde yazma işlemleri başarısız olmaya başlayacaktır.

Tablolar Amazon RDS üzerinde çalışan bir üretim MySQL 5.6.19a veritabanındadır.

Her zaman gerçekleşen üretim okumalarını ve uçlarını bozmadan böyle bir ALTER'i nasıl yapabiliriz?

ALTER TABLE MYTABLECHANGE id idBIGINT NULL DEĞİL AUTO_INCREMENT;

İşte tablo için 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

Yeterli alanınız varsa, gerçek tablonun bir kopyasını oluşturabilir ve bunun üzerinde çalışabilirsiniz:

CREATE TABLE new_tbl [AS] SELECT * FROM orig_tbl;

Ardından sütunu istediğiniz gibi değiştirebilirsiniz:

ALTER TABLE tbl_name MODIFY COLUMN col_name BIGINT AUTO_INCREMENT;

İşlem tamamlandıktan sonra tabloları yeniden adlandırabilirsiniz:

RENAME TABLE tbl_name TO new_tbl_name, tbl_name2 TO new_tbl_name2;

Ardından orijinal tabloyu bırakın ve belirtilen sonucu almalısınız.

percona araç kiti, en azından zaman içinde çok kısa değilseniz, gitmenin yoludur. 24 saatten biraz daha fazla test ettiğimizde dönüşüm masamıza (500Gb, master-slave kurulumu) aldı, üretimde neredeyse 1 ay (daha iyi bir donanımla) aldı ve tükenmeden yaklaşık 30 gün geçirdiğimiz komik sidenote bu nedenle, çevrimdışı yedeklemelerle çalışarak, köleleri kaldırarak, ...) B ve C planlarını planlamaya başladık. Gecikme esas olarak kölelere doğru olan çoğaltmanın beklemesiydi (maksimum 50 saniye gecikmeye izin verdik). Ayrıca, eşzamanlı iş parçacığı sayısını da sınırladığınızdan emin olun. Günde 2 milyondan fazla kesici uç ve milyonlarca okuma var.

Ayrıca, kapsama başladıktan sonra onu durduramayacağınızı unutmayın (veya en azından yeniden başlatmak için herhangi bir yol bulamadık) :-(

İyi....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) PRIMARY KEY ile gereksizdir, bu yüzden DAMLA.

INT UNSIGNED sizi 4 milyara çıkarır, bu yeterli olur mu?

Değişen düşünün filterbir etmek ENUM.

1,75 milyar satırınız var mı? Yoksa bir sürü kimliği "yaktınız" mı? Eğer öyleyse, belki bunu düzeltebiliriz? Örneğin REPLACEve INSERTiradelerin belirli tatları kimlikleri atar. INSERT...ON DUPLICATE KEYgenellikle değiştirebilirsiniz REPLACE. 2 adımlı bir işlem INSERT IGNORE, kimliklerin yakılmasını önleyebilir .

Soruya geri dön ...

Pt-online-schema-change'un hile yapıp yapmayacağını görün: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html