เปลี่ยนคอลัมน์คีย์หลักจาก INT ถึง BIGINT ในการผลิต (MySQL 5.6.19a)

ตาราง INNODB บางส่วนในฐานข้อมูลการผลิตของเรากำลังจะถึงขีด จำกัด INT AUTO_INCREMENT ที่ 2147483647 และเราจำเป็นต้องเปลี่ยนเป็น BIGINT มิฉะนั้นการเขียนจะเริ่มล้มเหลว

ตารางอยู่ในฐานข้อมูล MySQL 5.6.19a ที่ใช้งานจริงบน Amazon RDS

เราจะแก้ไขเช่นนี้ได้อย่างไรโดยไม่กระทบกับการอ่านและการแทรกที่เกิดขึ้นตลอดเวลา?

เปลี่ยนตารางMYTABLEเปลี่ยนid idBIGINT ไม่ใช่ 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, การตั้งค่า master-slave) เมื่อเราทดสอบมันมากกว่า 24 ชั่วโมงในการผลิตใช้เวลา (ด้วยฮาร์ดแวร์ที่ดีขึ้น) เกือบ 1 เดือน (ตลก sidenote เรามีประมาณ 30 วันก่อนที่เราจะหมด รหัสดังนั้นเราจึงเริ่มวางแผนสำหรับแผน B และ C แล้วทำงานกับการสำรองข้อมูลออฟไลน์ลบทาส ... ) ความล่าช้าส่วนใหญ่เกิดจากการรอการจำลองที่เกิดขึ้นต่อทาส (เราอนุญาตให้เกิดการหน่วงเวลาสูงสุด 50 วินาที) ตรวจสอบให้แน่ใจว่าได้ จำกัด จำนวนเธรดที่เกิดขึ้นพร้อมกันด้วย เรามีเม็ดมีดมากกว่า 2 ล้านต่อวันและมีผู้อ่านอีกหลายล้านคน

โปรดทราบด้วยว่าเมื่อการเริ่มต้น coversion คุณไม่สามารถหยุดมันได้ (หรืออย่างน้อยเราก็ไม่พบวิธีที่จะรีสตาร์ท) :-(

ดี....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) มีการซ้ำซ้อนกับคีย์หลักดังนั้นคุณจึงสามารถวางมันได้

INT ที่ไม่ได้ลงชื่อจะได้รับคุณถึง 4 พันล้านคนนั่นจะเพียงพอหรือไม่

พิจารณาเปลี่ยนไปยังfilterENUM

คุณมี 1.75 พันล้านแถว? หรือคุณ "เผา" รหัสจำนวนมากหรือไม่ ถ้าเป็นเช่นนั้นบางทีเราสามารถแก้ไขได้หรือไม่ ตัวอย่างเช่นREPLACEและรสชาติที่แน่นอนของการINSERTโยนรหัส INSERT...ON DUPLICATE KEYสามารถแทนที่REPLACEได้ กระบวนการ 2 ขั้นตอนสามารถหลีกเลี่ยงINSERT IGNOREการเผาไหม้รหัส

กลับไปที่คำถาม ...

ดูว่า pt-online-schema-change จะทำเคล็ดลับหรือไม่: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html