PostgreSQL
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> PostgreSQL

Nâng cấp tự động gần như bằng không thời gian ngừng hoạt động của các cụm PostgreSQL trong đám mây (Phần I)

Tuần trước, tôi đã có mặt tại Nordic PGDay 2018 và tôi đã có một vài cuộc trò chuyện về công cụ mà tôi đã viết, đó là pglupgrade , để tự động hóa các nâng cấp phiên bản chính của PostgreSQL trong thiết lập cụm sao chép. Tôi rất vui vì nó đã được lắng nghe và một số người khác trong các cộng đồng khác nhau nói chuyện tại các buổi gặp mặt và các hội nghị khác về việc nâng cấp thời gian chết gần như bằng 0 bằng cách sử dụng sao chép hợp lý. Do có một bài nói chuyện mà tôi đã thuyết trình tại PGDAY'17 Nga, PGConf.EU 2017 ở Warsaw và cuối cùng là tại FOSDEM PGDay 2018 ở Brussels, tôi nghĩ tốt hơn nên tạo một bài đăng trên blog để giữ cho bài thuyết trình này có sẵn cho những người có thể không tham dự bất kỳ hội nghị nào đã nói ở trên. Nếu bạn muốn trực tiếp tham gia buổi nói chuyện và bỏ qua việc đọc bài đăng trên blog này, đây là liên kết của bạn:Nâng cấp tự động gần như không có thời gian ngừng hoạt động của cụm PostgreSQL trên đám mây

Động lực chính đằng sau việc phát triển công cụ này là đề xuất một giải pháp để giảm thiểu thời gian ngừng hoạt động trong quá trình nâng cấp phiên bản lớn mà không may ảnh hưởng đến hầu hết tất cả những người sử dụng PostgreSQL. Hiện tại, chúng tôi không có công cụ cho phép người dùng PostgreSQL nâng cấp cơ sở dữ liệu của họ mà không cần thời gian chết và đó rõ ràng là một điểm khó khăn đối với nhiều người dùng, đặc biệt là các doanh nghiệp. Và, nếu chúng ta giải quyết vấn đề nâng cấp, chúng ta nên nghĩ đến nhiều hơn một máy chủ (sẽ được gọi là một cụm từ bây giờ), đơn giản vì không còn nhiều người chỉ sử dụng một máy chủ cơ sở dữ liệu nữa. Tình huống phổ biến nhất là thiết lập sao chép luồng vật lý cho các mục đích có tính khả dụng cao hoặc mở rộng quy mô các truy vấn đọc.

Nâng cấp cơ sở dữ liệu

Trước khi đi sâu vào giải pháp, chúng ta hãy thảo luận một chút về cách hoạt động của nâng cấp cơ sở dữ liệu nói chung. Có bốn cách tiếp cận chính để nâng cấp cơ sở dữ liệu:

  1. Cách tiếp cận đầu tiên là để cơ sở dữ liệu giữ nguyên định dạng lưu trữ của chúng hoặc ít nhất là tương thích giữa các phiên bản. Tuy nhiên, điều này khó có thể đảm bảo lâu dài vì các tính năng mới có thể yêu cầu thay đổi về cách dữ liệu được lưu trữ hoặc thêm nhiều thông tin siêu dữ liệu hơn để hoạt động bình thường. Ngoài ra, hiệu suất thường được cải thiện bằng cách tối ưu hóa cấu trúc dữ liệu.
  2. Cách tiếp cận thứ hai là tạo một bản sao hợp lý (kết xuất) của máy chủ cũ và tải nó vào máy chủ mới. Đây là cách tiếp cận truyền thống nhất yêu cầu máy chủ cũ không nhận được bất kỳ bản cập nhật nào trong quá trình này và dẫn đến thời gian ngừng hoạt động kéo dài hàng giờ hoặc thậm chí hàng ngày trên cơ sở dữ liệu lớn.
  3. Tùy chọn thứ ba là chuyển đổi dữ liệu từ định dạng cũ sang định dạng mới. Điều này có thể được thực hiện nhanh chóng trong khi hệ thống mới đang chạy, nhưng sẽ phải chịu hình phạt về hiệu suất mà khó dự đoán vì nó phụ thuộc vào các kiểu truy cập dữ liệu hoặc nó có thể được thực hiện ngoại tuyến trong khi máy chủ ngừng hoạt động, một lần nữa phải chịu kéo dài thời gian ngừng hoạt động (mặc dù thường ngắn hơn phương pháp thứ hai).
  4. Phương pháp thứ tư là sử dụng kết xuất hợp lý để lưu và khôi phục cơ sở dữ liệu trong khi nắm bắt các thay đổi xảy ra trong thời gian chờ đợi và sao chép chúng một cách hợp lý vào cơ sở dữ liệu mới sau khi quá trình khôi phục ban đầu kết thúc. Phương pháp này yêu cầu sự điều phối của một số thành phần nhưng cũng giảm lượng thời gian cơ sở dữ liệu không thể phản hồi các truy vấn.

Phương pháp nâng cấp trong PostgreSQL

Nâng cấp PostgreSQL có thể được kết hợp với bốn phương pháp được liệt kê ở trên. Ví dụ:các bản phát hành nhỏ của PostgreSQL, không chứa các tính năng mới mà chỉ có các bản sửa lỗi, không thay đổi định dạng dữ liệu hiện có và phù hợp với cách tiếp cận đầu tiên. Đối với cách tiếp cận thứ hai, PostgreSQL cung cấp các công cụ được gọi là pg_dump và pg_restore để sao lưu và khôi phục hợp lý. Ngoài ra còn có công cụ pg_upgrade (nó là một mô-đun đóng góp và được chuyển đến cây chính trong PostgreSQL 9.5) để thực hiện chuyển đổi ngoại tuyến (các máy chủ không chạy) chuyển đổi thư mục dữ liệu cũ sang thư mục mới, có thể phù hợp với tùy chọn thứ ba. Đối với cách tiếp cận thứ tư, có các giải pháp dựa trên trình kích hoạt của bên thứ ba như Slony để nâng cấp, nhưng chúng có một số lưu ý mà chúng tôi sẽ đề cập sau.

Các phương pháp nâng cấp truyền thống chỉ có thể nâng cấp máy chủ chính trong khi các máy chủ bản sao phải được xây dựng lại sau đó (chuyển đổi ngoại tuyến) . Điều này dẫn đến các vấn đề bổ sung với cả tính khả dụng và dung lượng của cụm, do đó làm tăng hiệu quả thời gian ngừng hoạt động của cơ sở dữ liệu từ quan điểm của cả ứng dụng và người dùng. Sao chép lôgic cho phép sao chép trong khi hệ thống đang hoạt động và nỗ lực thử nghiệm có thể được xử lý trong thời gian chờ đợi (chuyển đổi trực tuyến) .

Có các phương pháp nâng cấp khác nhau áp dụng cho các môi trường khác nhau. Ví dụ: pg_dump cho phép nâng cấp từ rất phiên bản cũ (tức là 7.0) cho các bản phát hành gần đây, vì vậy nếu bạn đang chạy phiên bản cổ của PostgreSQL, thì phương pháp tốt nhất là sử dụng pg_dump / restore (và tốt hơn nên làm điều đó ngay bây giờ!). Nếu PostgreSQL phiên bản của bạn là 8.4 trở lên bạn có thể sử dụng pg_upgrade . Nếu bạn tình cờ sử dụng PostgreSQL 9.4 trở lên điều này có nghĩa là bạn có “Giải mã lôgic” trong lõi và bạn có thể sử dụng pglogical tiện ích mở rộng như một phương tiện nâng cấp. Cuối cùng, nếu bạn đang sử dụng PostgreSQL 10 , bạn sẽ có cơ hội nâng cấp cơ sở dữ liệu của mình lên PostgreSQL 11 trở lên (khi chúng có sẵn) bằng cách sử dụng “Sao chép lôgic” trong lõi (vâng!).

Bản sao lôgic để nâng cấp

Đâu là ý tưởng nâng cấp PostgreSQL bằng cách sử dụng sao chép hợp lý đến từ? Rõ ràng, pglogical không tuyên bố công khai mục đích nâng cấp như pg_upgrade hiện ( đây là một lập luận chống lại pglogical tại bữa tiệc hội nghị ), nhưng điều này không có nghĩa là chúng tôi không thể sử dụng công cụ để nâng cấp. Trên thực tế, khi pglogical được thiết kế, việc nâng cấp thời gian chết gần như bằng không được các nhà phát triển tiện ích mở rộng coi là một trong những trường hợp sử dụng dự kiến.

Không giống như sao chép vật lý, nắm bắt các thay đổi đối với dữ liệu thô trên đĩa, sao chép lôgic nắm bắt các thay đổi lôgic đối với các bản ghi riêng lẻ trong cơ sở dữ liệu và sao chép chúng. Các bản ghi lôgic hoạt động trên các bản phát hành chính , do đó, bản sao lôgic có thể được sử dụng để nâng cấp từ bản phát hành này sang bản phát hành khác. Ý tưởng sử dụng sao chép hợp lý làm phương tiện nâng cấp phiên bản còn lâu mới trở nên mới mẻ, các công cụ sao chép dựa trên kích hoạt đã và đang thực hiện nâng cấp theo cách hợp lý bằng cách nắm bắt và gửi các thay đổi thông qua trình kích hoạt (vì trình kích hoạt cũng có thể hoạt động bất kể phiên bản cơ sở dữ liệu nào! ).

Nếu bạn có thể sử dụng các giải pháp sao chép dựa trên trình kích hoạt để nâng cấp thời gian chết tối thiểu thì tại sao bạn lại thích sao chép hợp lý thay thế? Trong cơ chế dựa trên trình kích hoạt, tất cả các thay đổi được ghi lại bằng cách sử dụng trình kích hoạt và được ghi vào bảng hàng đợi. Quy trình này tăng gấp đôi các thao tác ghi, tăng gấp đôi các tệp nhật ký và làm chậm hệ thống vì tất cả các thay đổi phải được ghi hai lần; dẫn đến nhiều I / O đĩa hơn và tải trên máy chủ nguồn. Ngược lại, bản sao lôgic trong lõi (tương tự đối với phần mở rộng pglogical) được xây dựng trên cơ sở giải mã lôgic. Giải mã logic là một cơ chế trích xuất thông tin từ các tệp WAL thành các thay đổi logic (CHÈN / CẬP NHẬT / XÓA). Vì dữ liệu từ cơ chế WAL được sử dụng bằng cách giải mã nhật ký giao dịch, nên không có khuếch đại ghi như trong trường hợp của các giải pháp sao chép dựa trên trình kích hoạt, do đó phương pháp này hoạt động tốt hơn . Do đó, các giải pháp dựa trên giải mã logic chỉ đơn giản là có tác động đến hệ thống thấp hơn so với các giải pháp dựa trên trình kích hoạt.

Kết luận

Trong bài đăng giới thiệu này, tôi muốn đưa ra ý tưởng tại sao chúng ta nên cân nhắc việc sử dụng bản sao hợp lý để đạt được thời gian chết tối thiểu trong quá trình nâng cấp phiên bản lớn. Chúng tôi sẽ tiếp tục với các chi tiết về kiến ​​trúc và cách triển khai của công cụ này trong bài đăng sắp tới.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Chuyển biểu diễn ngày postgres thành chuỗi ISO 8601

  2. Bất kỳ nhược điểm nào của việc sử dụng văn bản kiểu dữ liệu để lưu trữ chuỗi?

  3. Cần chuyển Oracle merge thành truy vấn sang PostgreSQL

  4. Cách cài đặt Haproxy và Keepalived

  5. INITCAP () - Chuyển đổi sang Caps ban đầu trong PostgreSQL