Bảng thay đổi trên cơ sở dữ liệu sản xuất trực tiếp

Làm thế nào để hầu hết hệ thống cơ sở dữ liệu "phổ biến" (MySQL, Postgres ...) xử lý các bảng thay đổi trên cơ sở dữ liệu sản xuất trực tiếp (như thêm, xóa hoặc thay đổi loại colums)?

Tôi biết cách chính xác là sao lưu mọi thời gian ngừng hoạt động và thực hiện sau đó thực hiện các thay đổi.

Nhưng ... có bất kỳ hệ thống cơ sở dữ liệu hiện tại nào hỗ trợ thực hiện những việc này "trực tuyến" mà không dừng lại không? (có thể chỉ trì hoãn các truy vấn tham chiếu một cột vừa được thay đổi / xóa)

Và điều gì xảy ra khi tôi chỉ làm một ALTER TABLE...cơ sở dữ liệu đang chạy? Có phải mọi thứ dừng lại khi điều này xảy ra? Dữ liệu có thể bị hỏng? v.v.

Một lần nữa, tôi chủ yếu đề cập đến Postgres hoặc MySQL vì đây là những gì tôi gặp phải.

(Và, vâng, bất cứ lúc nào tôi phải làm điều này trước khi tôi thực hiện "đúng cách", sao lưu mọi thứ, lên lịch trình, v.v ... nhưng tôi chỉ muốn biết liệu có thể thực hiện loại này và mọi thứ "nhanh chóng không bẩn "hoặc nếu có bất kỳ hệ thống DB nào thực sự hỗ trợ thay đổi lược đồ" nhanh, sống và bẩn ")

Ai đó chỉ đề xuất Thay đổi lược đồ trực tuyến cho MySQL từ tập lệnh Facebook (có hướng dẫn ở đây và nguồn ở đây ) ... có vẻ như là một cách hay để tự động hóa một bộ các cách "hacky" để thực hiện ... có ai đã từng sử dụng nó trong một cái gì đó tương tự sản xuất?

Khi bạn phát hành một ALTER TABLEPostgreSQL, nó sẽ ACCESS EXCLUSIVEkhóa một khóa chặn mọi thứ bao gồmSELECT . Tuy nhiên, khóa này có thể được tóm tắt khá nếu bảng không yêu cầu viết lại, không mới UNIQUE, CHECKhoặc FOREIGN KEYnhững hạn chế cần phải tốn kém quét toàn bảng để xác minh, vv

Nếu nghi ngờ, bạn thường chỉ có thể thử nó! Tất cả DDL trong PostgreSQL là giao dịch, do đó, việc hủy bỏ ALTER TABLEnếu mất quá nhiều thời gian và bắt đầu giữ các truy vấn khác là khá tốt . Các mức khóa được yêu cầu bởi các lệnh khác nhau được ghi lại trong trang khóa .

Một số hoạt động chậm thông thường có thể được tăng tốc để an toàn để thực hiện mà không có thời gian chết. Ví dụ: nếu bạn có bảng tvà bạn muốn thay đổi cột customercode integer NOT NULLthành textvì khách hàng đã quyết định tất cả các mã khách hàng phải bắt đầu bằng một X, bạn có thể viết:

ALTER TABLE t ALTER COLUMN customercode TYPE text USING ( 'X'||customercode::text );

... nhưng điều đó sẽ khóa toàn bộ bảng để viết lại. Vì vậy, thêm một cột với một DEFAULT. Nó có thể được thực hiện trong một vài bước để tránh khóa dài, nhưng các ứng dụng phải có khả năng đối phó với sự trùng lặp tạm thời:

ALTER TABLE t ADD COLUMN customercode_new text;
BEGIN;
LOCK TABLE t IN EXCLUSIVE MODE;
UPDATE t SET customercode_new = 'X'||customercode::text;
ALTER TABLE t DROP COLUMN customercode;
ALTER TABLE t RENAME COLUMN customercode_new TO customercode;
COMMIT;

Điều này sẽ chỉ ngăn chặn ghi vào ttrong quá trình; tên khóa EXCLUSIVEcó phần lừa đảo ở chỗ nó loại trừ mọi thứ trừSELECT ; các ACCESS EXCLUSIVEchế độ là người duy nhất mà không bao gồm hoàn toàn everyting. Xem các chế độ khóa . Có nguy cơ rằng thao tác này có thể bị bế tắc do nâng cấp khóa theo yêu cầu ALTER TABLE, nhưng tệ nhất là bạn sẽ phải thực hiện lại.

Bạn thậm chí có thể tránh khóa đó và thực hiện toàn bộ hoạt động bằng cách tạo một hàm kích hoạt trên tđó bất cứ khi nào một INSERThoặc UPDATEđi vào, tự động cư trú customercode_newtừ đó customercode.

Ngoài ra còn có các công cụ tích hợp như CREATE INDEX CONCURRENTLYvà ALTER TABLE ... ADD table_constraint_using_indexđược thiết kế để cho phép các DBA giảm thời lượng khóa độc quyền bằng cách thực hiện công việc chậm hơn theo cách thân thiện đồng thời.

Công pg_reorgcụ này hoặc công cụ kế thừa của nó pg_repackcũng có thể được sử dụng cho một số hoạt động tái cấu trúc bảng.

Percona đã đưa ra công cụ riêng để thực hiện các thay đổi lược đồ trực tuyến

Công cụ này được gọi là pt-online-giản đồ-thay đổi

Nó liên quan đến kích hoạt, vì vậy xin vui lòng đọc tài liệu cẩn thận.

Theo Tài liệu, các hoạt động chính được thực hiện là

• Kiểm tra vệ sinh
• Chunk
• Thay đổi lược đồ trực tuyến
  • Tạo và thay đổi bảng tạm thời
  • Nắm bắt các thay đổi từ bảng này sang bảng tạm thời
  • Sao chép các hàng từ bảng vào bảng tạm thời
  • Đồng bộ hóa bảng và bảng tạm thời
  • Hoán đổi / đổi tên bảng và bảng tạm thời
  • Dọn dẹp

Tắt hệ thống và thực hiện tất cả các thay đổi cùng một lúc có thể rất rủi ro. Nếu có sự cố xảy ra và thường xuyên xảy ra, không có cách nào dễ dàng quay lại.

Là một nhà phát triển Agile, đôi khi tôi cần phải cấu trúc lại các bảng mà không có bất kỳ thời gian chết nào, vì các bảng đó đang được sửa đổi và đọc từ đó.

Cách tiếp cận sau đây có rủi ro thấp, vì thay đổi được thực hiện trong một số bước có rủi ro thấp rất dễ quay trở lại:

• Đảm bảo rằng tất cả các mô-đun truy cập vào bảng được bao phủ tốt bằng các kiểm tra tự động.
• Tạo một bảng mới. Thay đổi tất cả các quy trình sửa đổi bảng cũ, để chúng sửa đổi cả bảng cũ và bảng mới.
• Di chuyển dữ liệu hiện có vào cấu trúc mới. Thực hiện theo lô nhỏ, để nó không ảnh hưởng nghiêm trọng đến hiệu suất tổng thể trên máy chủ.
• Xác minh rằng việc di chuyển dữ liệu đã thành công.
• Chuyển hướng một số quy trình chọn từ bảng cũ sang bảng mới. Sử dụng các kiểm tra tự động để đảm bảo rằng các mô-đun thay đổi vẫn đúng. Hãy chắc chắn rằng hiệu suất của họ là chấp nhận được. Triển khai các thủ tục thay đổi.
• Lặp lại bước trước cho đến khi tất cả các báo cáo sử dụng bảng mới.
• Thay đổi các quy trình sửa đổi các bảng để chúng chỉ truy cập vào bảng mới.
• Lưu trữ bảng cũ và loại bỏ nó khỏi hệ thống.

Chúng tôi đã sử dụng phương pháp này nhiều lần để thay đổi các bảng sản xuất trực tiếp lớn mà không có thời gian chết, không có vấn đề gì cả.

Có, nhiều cơ sở dữ liệu hiện đại sẽ cho phép bạn chỉ cần thêm một cột hoặc thay đổi các đặc điểm của một cột, như thêm hoặc xóa nullable.

Nếu bạn đánh rơi một cột, dữ liệu sẽ bị mất, nhưng không có nhiều nỗi sợ tham nhũng.

Công cụ Percona sử dụng các trình kích hoạt để hỗ trợ việc thay đổi và nó không hoạt động tốt nếu bảng của bạn đã có các kích hoạt hiện có. Cuối cùng tôi đã phải viết một cái thực sự xử lý tốt các kích hoạt hiện có, vì chúng cực kỳ quan trọng đối với cơ sở dữ liệu của chúng tôi https://github.com/StirlingMarketinggroup/smg-live-alter

Để giải quyết câu hỏi về những gì xảy ra với một ALTER TABLEtuyên bố, nó phụ thuộc vào mức độ thay đổi của bạn. Trong các trường hợp cụ thể, nếu bạn thêm một cột mới, ít nhất là trong MS SQL Server, công cụ sẽ tạo một bản sao tạm thời của bảng, trong khi nó tạo định nghĩa bảng mới, sau đó chèn dữ liệu vào đó. Trong thời gian thay đổi, bảng sẽ không thể truy cập được đối với người dùng.

Một ví dụ về các hoạt động cụ thể cho máy chủ MSSQL có tại đây: http://support.microsoft.com/kb/956176/en-us

Tôi sẽ giả định rằng các RMDB khác có các phương thức tương tự, mặc dù việc triển khai chính xác sẽ là thứ bạn sẽ phải xác minh với tài liệu của nhà cung cấp.