Triển khai không ngừng hoạt động - Lược đồ Db chuyển tiếp

Đạt được triển khai không ngừng hoạt động đã chạm vào cùng một vấn đề nhưng tôi cần một số lời khuyên về một chiến lược mà tôi đang xem xét.

Bối cảnh

Một ứng dụng dựa trên web với Apache / PHP để xử lý phía máy chủ và hệ thống tập tin / DB của MySQL để duy trì.

Chúng tôi hiện đang xây dựng cơ sở hạ tầng. Tất cả các phần cứng mạng sẽ có dự phòng và tất cả các cáp mạng chính sẽ được sử dụng theo cặp ngoại quan để chịu lỗi. Các máy chủ đang được cấu hình là các cặp có tính sẵn sàng cao cho khả năng chịu lỗi phần cứng và sẽ được cân bằng tải cho cả khả năng chịu lỗi của máy ảo và hiệu năng chung.

Mục đích của tôi là chúng tôi có thể áp dụng các bản cập nhật cho ứng dụng mà không mất thời gian. Tôi đã rất đau đớn khi thiết kế cơ sở hạ tầng để đảm bảo rằng tôi có thể cung cấp 100% thời gian hoạt động; sẽ vô cùng thất vọng khi sau đó có 10-15 phút ngừng hoạt động mỗi khi một bản cập nhật được áp dụng. Điều này đặc biệt quan trọng vì chúng tôi dự định sẽ có một chu kỳ phát hành rất nhanh (đôi khi nó có thể đạt tới một hoặc nhiều bản phát hành mỗi ngày.

Cấu trúc mạng

Đây là một bản tóm tắt của mạng:

                      Load Balancer
             |----------------------------|
              /       /         \       \  
             /       /           \       \ 
 | Web Server |  DB Server | Web Server |  DB Server |
 |-------------------------|-------------------------|
 |   Host-1   |   Host-2   |   Host-1   |   Host-2   |
 |-------------------------|-------------------------|
            Node A        \ /        Node B
              |            /            |
              |           / \           |
   |---------------------|   |---------------------|
           Switch 1                  Switch 2

   And onward to VRRP enabled routers and the internet

Lưu ý: Máy chủ DB sử dụng bản sao chính chủ

Chiến lược đề xuất

Để đạt được điều này, tôi hiện đang nghĩ đến việc chia các kịch bản nâng cấp lược đồ DB thành hai phần. Bản nâng cấp sẽ như thế này:

1. Máy chủ Web trên nút A được đưa ra khỏi dòng; lưu lượng truy cập tiếp tục được xử lý bởi máy chủ web trên nút B.
2. Thay đổi lược đồ chuyển tiếp được áp dụng cho các máy chủ DB
3. Web-Server Một cơ sở mã được cập nhật, bộ nhớ cache bị xóa và bất kỳ hành động nâng cấp nào khác được thực hiện.
4. Máy chủ Web A được đưa trực tuyến và máy chủ web B được đưa ra ngoại tuyến.
5. Cơ sở mã B của máy chủ web được cập nhật, bộ nhớ cache bị xóa và mọi hành động nâng cấp khác được thực hiện.
6. Máy chủ web B được đưa trực tuyến.
7. Thay đổi lược đồ cuối cùng được áp dụng cho DB

"Lược đồ chuyển tiếp" sẽ được thiết kế để thiết lập DB tương thích phiên bản chéo. Điều này chủ yếu sẽ sử dụng các chế độ xem bảng mô phỏng lược đồ phiên bản cũ trong khi bản thân bảng sẽ được thay đổi thành lược đồ mới. Điều này cho phép phiên bản cũ tương tác với DB như bình thường. Các tên bảng sẽ bao gồm các số phiên bản lược đồ để đảm bảo rằng sẽ không có bất kỳ sự nhầm lẫn nào về việc viết bảng nào.

'Lược đồ cuối cùng' sẽ loại bỏ khả năng tương thích ngược và dọn dẹp lược đồ.

Câu hỏi

Tóm lại, điều này sẽ làm việc?

cụ thể hơn:

1. Sẽ có vấn đề do tiềm năng viết đồng thời tại điểm cụ thể của thay đổi lược đồ chuyển tiếp? Có cách nào để đảm bảo rằng nhóm các truy vấn sửa đổi bảng và tạo chế độ xem tương thích ngược được thực hiện liên tiếp không? tức là với bất kỳ truy vấn nào khác được giữ trong bộ đệm cho đến khi thay đổi lược đồ được hoàn thành, thường sẽ chỉ là mili giây.

2. Có phương pháp đơn giản nào cung cấp mức độ ổn định này trong khi cũng cho phép cập nhật mà không mất thời gian không? Nó cũng được ưu tiên để tránh chiến lược lược đồ 'tiến hóa' vì tôi không muốn bị khóa trong khả năng tương thích lược đồ ngược.

Có vẻ như những gì bạn đang thực sự tìm kiếm không có nhiều Tính sẵn sàng cao như bạn sẽ cần Tính khả dụng liên tục .

Về cơ bản, kế hoạch của bạn sẽ hoạt động nhưng dường như bạn đã nhận thấy rằng lỗ hổng lớn trong thiết lập của bạn là các thay đổi lược đồ cơ sở dữ liệu trong một bản phát hành có thể dẫn đến thời gian chết hoặc lỗi của nút vẫn có thể hoạt động chính xác. Phương pháp tiếp cận sẵn có liên tục giải quyết điều này bằng cách chủ yếu tạo ra một số môi trường sản xuất.

Sản xuất một

Môi trường này là phiên bản trực tiếp hiện tại của phần mềm đang được người dùng sử dụng. Nó có máy chủ web, máy chủ ứng dụng và máy chủ cơ sở dữ liệu và không gian bảng. Nó hoạt động độc lập với bất kỳ môi trường khác. Load Balancer sở hữu điểm cuối độ phân giải tên miền cho các dịch vụ này hiện đang trỏ đến các máy chủ web này.

Sản xuất hai

Điều này về cơ bản là phát hành môi trường dàn giống hệt với Sản xuất Một. Bạn có thể thực hiện nâng cấp phát hành tại đây và thực hiện các bài kiểm tra về sự tỉnh táo của mình trước khi diễn ra sự kiện trực tiếp. Điều này cũng cho phép bạn thực hiện các thay đổi cơ sở dữ liệu của mình một cách an toàn trên môi trường này. Hiện tại Load Balancer không trỏ đến môi trường này.

Sản xuất DR

Đây là một bản sao khác tại một trung tâm dữ liệu riêng biệt nằm ở một khu vực khác trên thế giới. Điều này cho phép bạn thất bại trong trường hợp xảy ra sự kiện thảm khốc bằng cách thực hiện chuyển đổi DNS tại Load Balancer.

Chưa lên

Sự kiện này về cơ bản là cập nhật bản ghi DNS để chuyển sang Sản xuất hai từ Sản xuất một hoặc ngược lại. Điều này cần một thời gian để truyền bá khắp các máy chủ DNS trên thế giới để bạn có thể chạy cả hai môi trường. Một số người dùng CÓ THỂ đang làm việc trong các phiên hiện có trên phiên bản cũ của phần mềm của bạn. Hầu hết người dùng sẽ thiết lập các phiên mới trên phiên bản nâng cấp của phần mềm của bạn.

Di chuyển dữ liệu

Hạn chế duy nhất ở đây là không phải tất cả dữ liệu trong cửa sổ đó đều có sẵn cho tất cả người dùng tại thời điểm đó. Rõ ràng có dữ liệu người dùng quan trọng trong cơ sở dữ liệu phiên bản trước mà bây giờ cần được di chuyển an toàn sang lược đồ cơ sở dữ liệu mới. Điều này có thể được thực hiện với một kịch bản xuất và di chuyển dữ liệu được thử nghiệm tốt hoặc công việc hàng loạt hoặc quy trình ETL tương tự.

Phần kết luận

Khi bạn đã hoàn thành đầy đủ sự kiện phát hành của mình, Production Two bây giờ là chính của bạn và bạn bắt đầu cài đặt bản phát hành tiếp theo cho Production One cho chu kỳ triển khai tiếp theo.

Hạn chế

Đây là một thiết lập môi trường phức tạp và nó đòi hỏi một lượng lớn tài nguyên hệ thống, thường gấp hai đến ba lần tài nguyên hệ thống để thực hiện thành công. Vận hành theo cách này có thể tốn kém, đặc biệt nếu bạn có hệ thống sử dụng rất nặng.

Chiến lược của bạn là âm thanh. Tôi chỉ đề nghị xem xét mở rộng "Lược đồ chuyển tiếp" thành một bộ "bảng giao dịch" hoàn chỉnh.

Với các bảng giao dịch, các CHỌN (truy vấn) được thực hiện đối với các bảng được chuẩn hóa để đảm bảo tính chính xác. Nhưng tất cả các CHỨNG CHỈ, CẬP NHẬT và XÓA cơ sở dữ liệu luôn được ghi vào các bảng giao dịch không chuẩn hóa.

Sau đó, một quy trình đồng thời, riêng biệt áp dụng những thay đổi đó (có thể sử dụng Quy trình được lưu trữ) cho các bảng được chuẩn hóa theo các quy tắc nghiệp vụ và yêu cầu lược đồ được thiết lập.

Hầu hết thời gian, điều này sẽ gần như ngay lập tức. Nhưng việc tách các hành động cho phép hệ thống điều chỉnh độ trễ cập nhật lược đồ và hoạt động quá mức.

Trong các thay đổi lược đồ trên cơ sở dữ liệu (B), các cập nhật dữ liệu trên cơ sở dữ liệu hoạt động (A) sẽ đi vào các bảng giao dịch của nó và ngay lập tức được áp dụng cho các bảng được chuẩn hóa của nó.

Khi đưa cơ sở dữ liệu (B) sao lưu, các giao dịch từ (A) sẽ được áp dụng cho cơ sở dữ liệu bằng cách viết chúng vào các bảng giao dịch của (B). Khi phần đó được thực hiện, (A) có thể được đưa xuống và các thay đổi lược đồ được áp dụng ở đó. (B) sẽ hoàn thành việc áp dụng các giao dịch từ (A) đồng thời xử lý các giao dịch trực tiếp của nó sẽ xếp hàng giống như (A) đã làm và "giao dịch trực tiếp" sẽ được áp dụng theo cách tương tự khi (A) xuất hiện trở lại.

Một hàng của bảng giao dịch có thể trông giống như ...

| ROWID | TRANSNR | DB | TABLE | SQL STATEMENT
    0        0       A    Name   INSERT INTO Name ...
    1        0       A    Addr   INSERT INTO Addr ...
    2        0       A    Phone  INSERT INTO Phone ...
    3        1       A    Stats   UPDATE Stats SET NrOfUsers=...

Các "bảng" giao dịch thực sự có thể là các hàng trong cơ sở dữ liệu NoQuery riêng biệt hoặc thậm chí các tệp tuần tự, tùy thuộc vào yêu cầu về hiệu suất. Một phần thưởng là việc mã hóa ứng dụng (trang web trong trường hợp này) trở nên đơn giản hơn một chút vì nó chỉ ghi vào các bảng giao dịch.

Ý tưởng tuân theo các nguyên tắc tương tự như sổ sách kế toán kép và vì những lý do tương tự.

Các bảng giao dịch tương tự như một "tạp chí" kế toán. Các bảng được chuẩn hóa hoàn toàn tương tự như một "sổ cái" kế toán với mỗi bảng giống như một "tài khoản" kế toán.

Trong sổ sách kế toán, mỗi giao dịch được hai mục trong tạp chí. Một cho tài khoản sổ cái "ghi nợ", và một cho tài khoản "ghi có".

Trong RDBMS, một "nhật ký" (bảng giao dịch) có một mục nhập cho mỗi bảng được chuẩn hóa sẽ bị thay đổi bởi giao dịch đó.

Cột DB trong hình minh họa bảng ở trên cho biết cơ sở dữ liệu nào bắt nguồn từ giao dịch, do đó cho phép các hàng được xếp hàng từ cơ sở dữ liệu khác được lọc ra và không được áp dụng lại khi cơ sở dữ liệu thứ hai được sao lưu.