Thay đổi cột khóa chính từ INT sang BIGINT trong sản xuất (MySQL 5.6.19a)

Một số bảng INNODB trong cơ sở dữ liệu sản xuất của chúng tôi sắp đạt giới hạn INT AUTO_INCREMENT là 2147483647 và chúng tôi cần thay đổi chúng thành BIGINT nếu không việc ghi sẽ bắt đầu thất bại.

Các bảng nằm trong cơ sở dữ liệu MySQL 5.6.19a sản xuất chạy trên Amazon RDS.

Làm thế nào chúng ta có thể thực hiện THAY ĐỔI như thế này mà không làm gián đoạn quá trình đọc và chèn sản xuất đang diễn ra mọi lúc?

MYTABLETHAY ĐỔI BẢNG THAY ĐỔI id idBIGINT KHÔNG NULL AUTO_INCREMENT;

Đây là DDL cho bảng:

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

Nếu bạn có đủ không gian, bạn có thể tạo một bản sao của bảng thực tế và thực hiện công việc trên đó:

CREATE TABLE new_tbl [AS] SELECT * FROM orig_tbl;

Sau đó, bạn có thể thay đổi cột như mong muốn:

ALTER TABLE tbl_name MODIFY COLUMN col_name BIGINT AUTO_INCREMENT;

Khi quá trình hoàn tất, bạn có thể đổi tên các bảng:

RENAME TABLE tbl_name TO new_tbl_name, tbl_name2 TO new_tbl_name2;

Sau đó thả bảng gốc và bạn sẽ có kết quả được kiểm tra.

bộ công cụ percona là cách để đi, ít nhất là nếu bạn không siêu ngắn về thời gian. Việc chuyển đổi đã diễn ra trên bàn của chúng tôi (500Gb, thiết lập master-Slave) khi chúng tôi thử nghiệm nó hơn một chút trong 24 giờ, trong quá trình sản xuất (với phần cứng tốt hơn) gần 1 tháng (sidenote vui nhộn chúng tôi đã có khoảng 30 ngày trước khi chúng tôi hết id, do đó chúng tôi đã bắt đầu lên kế hoạch cho kế hoạch B và C, làm việc với các bản sao lưu ngoại tuyến, xóa nô lệ, ...). Sự chậm trễ chủ yếu là do sự chờ đợi của sự sao chép xảy ra đối với các nô lệ (chúng tôi cho phép độ trễ thời gian tối đa là 50 giây). Cũng đảm bảo giới hạn số lượng chủ đề đồng thời. Chúng tôi có hơn 2 triệu lượt chèn / ngày và nhiều triệu lượt đọc.

Ngoài ra, hãy lưu ý rằng một khi lớp phủ đã bắt đầu, bạn không thể dừng nó (hoặc ít nhất chúng tôi không tìm cách khởi động lại nó) :-(

Tốt....

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) là dư thừa với KHÓA CHÍNH, vì vậy bạn cũng có thể DỪNG nó.

INT UNSIGNED sẽ giúp bạn kiếm được 4 tỷ, điều đó có đủ không?

Xem xét thay đổi filterthành một ENUM.

Bạn có 1,75 tỷ hàng? Hay bạn đã "đốt cháy" rất nhiều id? Nếu vậy, có lẽ chúng ta có thể khắc phục điều đó? Ví dụ REPLACEvà một số hương vị nhất định của INSERTý chí quăng ids. INSERT...ON DUPLICATE KEYthường có thể thay thế REPLACE. Một quy trình gồm 2 bước có thể tránh INSERT IGNOREviệc đốt id.

Quay lại câu hỏi ...

Xem nếu pt-online-lược đồ thay đổi sẽ thực hiện thủ thuật: http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html