Làm thế nào để bạn cập nhật lược đồ cơ sở dữ liệu / cơ sở dữ liệu mà không gây ra thời gian chết?

42

Một số kỹ thuật để cập nhật lược đồ cơ sở dữ liệu / cơ sở dữ liệu của máy chủ sản xuất mà không gây ra bất kỳ thời gian chết nào?

deployment

— Olivier Lalonde
nguồn

1

Câu hỏi hay vì tôi thấy rất nhiều người bỏ qua điều này. Thời gian là tiền bạc và thời gian chết không bao giờ có vẻ tốt cho người dùng cuối, bất kể lý do hợp pháp như thế nào.

— Dan McGrath

@Dan McGrath: giả sử bạn thực sự có thể có thời gian chết, tôi làm việc cho một hệ thống (thông thường) chỉ giảm 4 lần một năm (mất điện quý) và tối đa 15 phút mỗi lần (trong thời gian lưu lượng được xếp hàng). .. thay đổi cơ sở dữ liệu được xem xét kỹ lưỡng :)

— Matthieu M.

2

Đây sẽ là một câu hỏi tuyệt vời cho dba.stackexchange.com , phiên bản beta công khai trong vài giờ.

— Larry Coleman

20

Nói chung, các trang web tôi đã làm việc có loại yêu cầu này đều nằm sau bộ cân bằng tải hoặc có các vị trí chuyển đổi dự phòng riêng biệt. Trong mẫu này, tôi sẽ cho rằng bạn đã có một bộ cân bằng tải, 2 máy chủ web (A & B) và 2 máy chủ cơ sở dữ liệu (M & N - thường là các máy chủ DB được liên kết thông qua logshipping - ít nhất là trong thế giới Máy chủ SQL ).

Máy chủ web A bị ngắt kết nối khỏi bộ cân bằng tải (vì vậy tất cả lưu lượng truy cập đến B).
Nhật ký vận chuyển bị dừng (DB Server M sẽ được cập nhật trước).
Cập nhật máy chủ web A. Trỏ cấu hình lên DB Server M.
Kiểm tra và xác minh rằng bản cập nhật đã hoạt động (thường là mọi người đang truy cập trực tiếp vào địa chỉ IP).
Đặt bộ cân bằng tải để các phiên hiện có tiếp tục chuyển sang B. Các phiên mới chuyển đến A.
Đợi tất cả các phiên trên B hết hạn (có thể là nửa giờ trở lên, thông thường chúng tôi xem lưu lượng truy cập và có thời gian nghỉ 1 giờ theo lịch trình).
Cập nhật B và N
Kiểm tra và xác minh rằng bản cập nhật đã hoạt động.
Thiết lập nhật ký vận chuyển một lần nữa và kiểm tra nó hoạt động.
Đặt bộ cân bằng tải hoạt động bình thường.

Trong một ứng dụng web rất phức tạp, những gì được mô tả là các bước 1-5 có thể mất cả đêm và là bảng tính Excel 50 trang với thời gian và số liên lạc khẩn cấp. Trong các tình huống như vậy, việc cập nhật một nửa hệ thống được lên kế hoạch từ 6 giờ tối đến 6 giờ sáng trong khi hệ thống có sẵn cho người dùng. Xử lý cập nhật cho trang web DR thường được lên kế hoạch cho đêm tiếp theo - chỉ hy vọng không có gì phá vỡ vào ngày đầu tiên.

Trong đó thời gian hoạt động là một yêu cầu, các bản vá được thử nghiệm đầu tiên trên môi trường QA, lý tưởng là phần cứng giống như sản xuất. Nếu họ cho thấy không có sự gián đoạn, sau đó họ có thể được áp dụng trên lịch trình thường xuyên, thường là vào cuối tuần.

— Tangurena
nguồn

7

Làm thế nào để bạn đề xuất hợp nhất dữ liệu mới từ DB M và DB N? Cả hai sẽ có các bản ghi mới, cập nhật và xóa mà cái kia không có.

— Sixty feetersdude

@Tangurena, bạn có thể trả lời nhận xét trên không?

— sino

9

Đối với cơ sở dữ liệu điển hình (ví dụ: Oracle) có thể thay đổi lược đồ cơ sở dữ liệu trong khi vẫn chạy các truy vấn song song. Nó đòi hỏi một số kế hoạch về phía trước mặc dù.

Chúng là một số hạn chế cho sự thay đổi được áp dụng:

nó nên hoạt động với mã hiện có, nghĩa là mã phải xử lý cả phiên bản cũ và mới của lược đồ
không nên chịu tải như vậy trên DB mà các giao dịch sẽ ngừng hoạt động (tôi đang nhìn bạn CREATE INDEX)
không nên mất dữ liệu (bạn không thể bỏ và tạo lại bảng)

Để lược đồ tương thích ngược, bạn thường có thể THÊM hoặc SỬA ĐỔI một cột, bạn chỉ có thể DROP một cái gì đó nếu mã hiện tại không sử dụng nó nữa.

Nếu mã của bạn không thể xử lý thay đổi trong suốt, thì hãy thay đổi mã trước khi thay đổi cơ sở dữ liệu.

Lời khuyên đơn giản về lập kế hoạch chuyển tiếp: luôn luôn rõ ràng các tên cột trong các yêu cầu DB của bạn (không sử dụng SELECT * FROM). Bằng cách này, bạn sẽ không có các cột mới hiển thị trong các yêu cầu cũ.

— Matthieu M
nguồn

1

Trên thực tế, để lập kế hoạch chuyển tiếp và khả năng thích ứng, chọn * từ hoàn toàn tốt hơn so với liệt kê các cột theo cách thủ công. Sử dụng tên cột rõ ràng dẫn đến rất nhiều nợ kỹ thuật trong hầu hết các trường hợp. Nếu mã của bạn bị hỏng từ các cột mới, mã của bạn đã bị hỏng.

— Mẹ ơi.

@Morg.: Không hẳn. Để bảo mật, bạn cần sử dụng các biến liên kết, trong khung mà tôi sử dụng (ít nhất) yêu cầu cung cấp các biến để ghi và cần phải có chính xác nhiều biến như có các cột đầu ra, do đó select *có nghĩa là mã bị hỏng nếu a cột mới được thêm vào (vì thiếu một biến để ghi nó vào). Tất nhiên, đây có thể là kết quả của việc sử dụng ngôn ngữ được gõ mạnh.

— Matthieu M.

Có thực sự, không có bảo mật bổ sung trong việc tránh chọn *. Nó không có gì để làm với các ngôn ngữ gõ mạnh và tất cả mọi thứ để làm với thiết kế rất xấu. Nếu khung của bạn không thể xử lý thay đổi liên tục, thì nó vô dụng. Khi tôi thay đổi một cột, ứng dụng của tôi không bao giờ ngừng hoạt động. Khi bạn làm điều đó phá vỡ. Tôi không nghĩ có câu hỏi nào đáng tin cậy hay an toàn hơn.

— Mẹ ơi.

@Morg.: Tôi không thấy làm thế nào select *đáng tin cậy và an toàn hơn. Nếu bạn đã từng có select one, two from ...thì bạn chỉ sử dụng onevà two; nếu thirdđược thêm vào bảng, thì bạn không có sử dụng cho nó (ở đây), vì vậy không có lý do gì để lấy nó. Và nếu bạn cần sử dụng nó đột ngột, thì bạn sẽ sửa đổi mã, vì vậy bạn cũng có thể sửa đổi truy vấn vào thời điểm này!

— Matthieu M.

@Morg.: Chà, có vẻ như chúng ta đang nói chuyện với nhau, có lẽ vì trải nghiệm của chúng ta khác nhau. Tôi làm việc trên các sản phẩm mà hiệu suất là một thuộc tính tối quan trọng và điều này có nghĩa là selectcần phải chọn lọc nhất có thể (và được bao phủ bởi một chỉ mục) nếu không tôi sẽ nướng (ngay cả trước khi bắt buộc tham gia). Tôi rất tiếc phải nói, nhưng cách tiếp cận mà bạn đang mô tả là một thất bại hoàn toàn trên các sản phẩm đó.

— Matthieu M.

5

Không phải tất cả các hệ thống đều có thể, nó phải được thiết lập theo cách hỗ trợ nó.

Ví dụ: một trong những hệ thống chính của chúng tôi mà tôi đã giúp nâng cấp vài năm trước sẽ có sẵn 24/7. Nó bao gồm nhiều tầng, bao gồm một tầng giao tiếp thuần túy giữa lớp Giao diện người dùng và lớp nghiệp vụ ngoài trang web. Do cách thức lớp giao tiếp được mã hóa, mọi thay đổi trong tương lai đối với lược đồ DB hoặc lớp nghiệp vụ có thể được thực hiện mà không bị ngừng hoạt động thực sự. Trong trường hợp xấu nhất, người dùng sẽ bị tạm dừng 10-30 giây khi các thay đổi có hiệu lực.

Nếu các thay đổi hoàn toàn là mã thay đổi cho lớp doanh nghiệp, chúng có thể được xếp hàng và 'đạp xe' chỉ với độ trễ mili giây.

Nó có thể làm điều này bởi vì:

Lớp giao tiếp có thể chứa tin nhắn. Điều này cho phép chúng tôi ngừng hoạt động thực tế trên bất kỳ tầng nào khác ngoài Lớp UI mà không cần phải hạ giao diện người dùng.
Lớp nghiệp vụ được xử lý bởi MVDB có tên UniData . Điều này giữ tất cả các mã trong bộ nhớ. Sau khi biên dịch mã, bạn có thể sử dụng lệnh để buộc mã đối tượng mới vào bộ nhớ, thay thế mã cũ.

Các kỹ thuật khác liên quan đến việc nhân rộng các giao dịch sang một tấm gương khác của hệ thống hiện có. Bằng cách áp dụng bản cập nhật cho một, chuyển đổi và phát lại tất cả các giao dịch được thực hiện giữa cập nhật và chuyển đổi. YMMV tùy thuộc vào hệ thống của bạn mặc dù.

— Dan McGrath
nguồn

1

Đây là một quan điểm khác nhau, từ thế giới của các hệ thống cơ sở dữ liệu nhúng và các hệ thống nhúng. Các hệ thống nhúng bao gồm nhiều thiết bị hạ tầng mạng / viễn thông khác nhau và trong lĩnh vực này, họ thường nói về thời gian hoạt động 99,999% (năm 9 giây).

Chúng tôi (McObject) là nhà cung cấp của dòng sản phẩm hệ thống cơ sở dữ liệu nhúng eXtremeDB, bao gồm cả tính sẵn sàng cao của eXtremeDB.

Trước tiên, hãy hiểu rằng "cơ sở dữ liệu nhúng" có nghĩa là hệ thống cơ sở dữ liệu là một thư viện được biên dịch và liên kết với mã ứng dụng của bạn; theo nghĩa đó, nó được "nhúng" vào ứng dụng của bạn.

Với tính khả dụng cao của eXtremeDB, có một phiên bản MASTER của ứng dụng của bạn (có thể là một hoặc một số quy trình) và một hoặc nhiều phiên bản REPLICA của ứng dụng của bạn. Khi một bản sao thiết lập kết nối với chủ, nó sẽ nhận được một bản sao của cơ sở dữ liệu của chủ thông qua một quá trình gọi là "đồng bộ hóa ban đầu". Điều này có thể được thực hiện trong khi ứng dụng chủ tiếp tục công việc của nó. Sau khi đồng bộ hóa, nó nhận được các giao dịch của chủ thông qua nhân rộng. Do đó, một bản sao luôn có dữ liệu hiện tại và có thể tiếp quản (thông qua một quá trình được gọi là failover) trong trường hợp chủ bị lỗi.

Một tính năng của đồng bộ hóa ban đầu được gọi là "tiến hóa lược đồ nhị phân." Nói một cách dễ hiểu, điều này có nghĩa là quá trình điền vào cơ sở dữ liệu của bản sao sẽ chứa các khác biệt giữa lược đồ cơ sở dữ liệu của bản sao và lược đồ cơ sở dữ liệu của chủ.

Trong thực tế, điều này có nghĩa là bạn có thể xây dựng một phiên bản mới hơn của ứng dụng của mình (với các bảng mới / bị hủy, các trường mới / bị giảm / thay đổi, chỉ mục mới / bị hủy), đính kèm phiên bản mới của ứng dụng của bạn với một bản gốc, và sau đó gây ra điều đó bản sao mới hơn để trở thành chủ nhân mới (tức là buộc chuyển đổi dự phòng sang bản sao mới để nó trở thành chủ nhân và chủ cũ tự tắt). Voila, bạn đã di chuyển ứng dụng của mình từ phiên bản N sang N + 1, mà không làm gián đoạn tính khả dụng của hệ thống. Bây giờ bạn có thể tiến hành nâng cấp bản cũ và mọi bản sao khác lên phiên bản N + 1.