Gỡ rối nâng cấp PostgreSQL

PostgreSQL 9.6 vừa được phát hành và hầu hết người dùng postgres sẽ bắt đầu tự hỏi mình làm thế nào để nâng cấp lên phiên bản chính mới. Bài đăng này có mục đích hiển thị các quy trình khác nhau để nâng cấp máy chủ PostgreSQL của bạn.

Nâng cấp lên phiên bản chính mới là một nhiệm vụ có tỷ lệ chuẩn bị cao trên tổng thời gian thực hiện. Cụ thể là khi bỏ qua một bản phát hành ở giữa, chẳng hạn như khi bạn chuyển từ phiên bản 9.3 sang phiên bản 9.5.

Bản phát hành điểm

Mặt khác, nâng cấp bản phát hành điểm không cần chuẩn bị nhiều. Nói chung, yêu cầu duy nhất là khởi động lại dịch vụ postgres. Không có thay đổi nào đối với cấu trúc dữ liệu cơ bản, vì vậy không cần phải kết xuất và khôi phục. Trong trường hợp xấu nhất, bạn có thể cần tạo lại một số chỉ mục của mình sau khi hoàn tất nâng cấp bản phát hành điểm.

Điều rất khôn ngoan là luôn cập nhật bản phát hành điểm mới nhất để bạn không vấp phải một lỗi đã biết (và có thể đã được sửa). Điều này có nghĩa là sau khi phiên bản mới nhất ra mắt, hãy lên lịch thời gian để nâng cấp càng sớm càng tốt.

Nâng cấp bản phát hành chính

Khi thực hiện các nhiệm vụ phức tạp như nhiệm vụ này, bạn nên xem xét tất cả các tùy chọn có thể có để đạt được kết quả cuối cùng.

Đối với các bản nâng cấp phát hành lớn, bạn có thể thực hiện ba cách:

• Nâng cấp khôi phục từ một kết xuất hợp lý
• Nâng cấp vật lý
• Nâng cấp trực tuyến

Hãy để tôi giải thích chi tiết từng vấn đề:

1) Khôi phục nâng cấp từ kết xuất hợp lý

Đây là cách đơn giản nhất trong số tất cả các cách có thể để nâng cấp cấu trúc dữ liệu cụm của bạn.

Nói một cách ngắn gọn, quy trình ở đây yêu cầu kết xuất hợp lý bằng cách sử dụng pg_dump từ phiên bản cũ và pg_restore trên một cụm sạch được tạo bằng phiên bản mới được cài đặt.

Các điểm chính có lợi cho việc sử dụng đường dẫn này là:

• Đây là sản phẩm được thử nghiệm nhiều nhất
• Khả năng tương thích quay trở lại phiên bản 7.0 để cuối cùng bạn có thể nâng cấp từ 7.x lên một trong các bản phát hành gần đây

Những lý do tại sao bạn nên tránh sử dụng tùy chọn này:

• Tổng thời gian ngừng hoạt động trên cơ sở dữ liệu lớn có thể là một vấn đề, vì bạn phải dừng ghi kết nối trước khi bắt đầu chạy pg_dump;
• Nếu có nhiều đối tượng lớn trong cơ sở dữ liệu, pg_dump sẽ chậm. Ngay cả khi thực hiện song song. Khôi phục thậm chí còn chậm hơn pg_dump khi nhiều đối tượng lớn được lưu trữ trong cơ sở dữ liệu;
• Nó yêu cầu dung lượng đĩa gấp đôi hoặc xóa cụm cũ trước khi khôi phục;

Trên các máy chủ có nhiều lõi CPU, có thể chạy pg_dump song song bằng cách sử dụng định dạng thư mục. Sau khi hoàn tất, hãy khôi phục song song bằng cách sử dụng công tắc -j trong cả pg_dump và pg_restore. Nhưng bạn không thể bắt đầu quá trình khôi phục cho đến khi toàn bộ kết xuất hoàn tất.

2) Nâng cấp vật lý

Những loại nâng cấp này đã có sẵn kể từ phiên bản 9.0 để thực hiện nâng cấp tại chỗ từ các phiên bản cũ như 8.3. Chúng được gọi là "tại chỗ" vì chúng được thực hiện trên cùng một máy chủ và tốt nhất là trên cùng một thư mục dữ liệu.

Ưu điểm của các loại nâng cấp này:

• Bạn không cần dung lượng cho một bản sao khác của cụm.
• Thời gian ngừng hoạt động thấp hơn nhiều so với việc sử dụng pg_dump.

Có một số nhược điểm:

• Sau khi bạn bắt đầu phiên bản PostgreSQL mới, bạn sẽ không thể quay lại phiên bản cũ nữa (cụm từ đó sẽ chỉ hoạt động với phiên bản mới).
• Số liệu thống kê được đưa về 0 sau khi nâng cấp, vì vậy ngay sau khi bắt đầu phiên bản PostgreSQL mới, phải thực hiện phân tích trên toàn cụm.
• Đã có nhiều lỗi được tìm thấy trong những năm qua liên quan đến pg_upgrade, điều này khiến một số quản trị viên cơ sở dữ liệu không muốn sử dụng phương pháp này để nâng cấp.
• Một số người đã gặp sự cố khi bỏ qua một bản phát hành chính, chẳng hạn như chuyển từ phiên bản 9.2 sang phiên bản 9.4.
• Với các danh mục lớn, nó sẽ hoạt động kém (các cụm có nhiều cơ sở dữ liệu hoặc cơ sở dữ liệu có nhiều nghìn đối tượng).

Bạn cũng có thể chạy pg_upgrade mà không có tùy chọn –link (trong trường hợp này pg_upgrade sẽ tạo bản sao thứ hai trên đĩa của cụm của bạn) để bạn có thể quay lại phiên bản cũ. Nhưng bạn sẽ mất cả hai lợi thế được liệt kê ở trên.

3) Nâng cấp trực tuyến

Quy trình phải tuân theo cho phương pháp này sẽ như sau:

1. Cài đặt cả hai phiên bản để bạn có thể làm cho chúng hoạt động song song. Việc này có thể được thực hiện trên cùng một máy chủ hoặc sử dụng hai máy chủ vật lý.
2. Tạo một bản sao ban đầu và sao chép các thay đổi từ thời điểm bạn bắt đầu sao chép trên nút nguồn (điều này sẽ tương tự như một pg_dump ban đầu).
3. Tiếp tục sao chép các thay đổi một cách hợp lý cho đến khi độ trễ gần bằng không.
4. Đặt lại thông tin kết nối từ máy chủ ứng dụng để kết nối với máy chủ mới.

Loại nâng cấp này đã có sẵn kể từ khi có các giải pháp sao chép dựa trên trình kích hoạt đầu tiên. Nói cách khác, vì tôi đã có Slony.

Các giải pháp sao chép dựa trên trình kích hoạt không quan tâm đến phiên bản bạn có ở bên này hay bên kia, vì nó sao chép các thay đổi bằng cách sử dụng các lệnh SQL được hỗ trợ.

Các công cụ sao chép dựa trên trình kích hoạt được đề xuất, theo thứ tự chúng xuất hiện là:

1. skytools:PgQ + londiste
2. Slony-I

Đây nên là cách ưu tiên để nâng cấp. Hãy xem những lợi ích của việc sử dụng phương pháp này:

• Không có thời gian chết!
• Tuyệt vời để nâng cấp lên phần cứng mới hơn.
• Kiểm tra trực tuyến cụm với phiên bản mới (truy vấn chỉ đọc, nếu không bạn có thể gặp xung đột).
• Giảm đáng kể tất cả các khối bảng và chỉ mục.

Có một số nhược điểm:

• Nó cần gấp đôi dung lượng lưu trữ vì nó phải lưu trữ bản sao thứ hai của dữ liệu của bạn.
• Vì dựa trên trình kích hoạt, hệ thống phải ghi mỗi thay đổi hai lần, điều đó có nghĩa là tôi sẽ có nhiều I / O đĩa hơn trên máy chủ nguồn (phiên bản cũ của cụm).
• Tất cả các bảng phải có khóa chính, do đó, công cụ sao chép có thể cá nhân hóa các bộ giá trị được cập nhật hoặc xóa
• Nó không sao chép các bảng danh mục, vì vậy nó sẽ không sao chép các đối tượng lớn.
• Việc sử dụng cơ bản không bao gồm các thay đổi giản đồ. Nó có thể được thực hiện, nhưng không minh bạch.

Một biên giới mới với pglogical

Kể từ PostgreSQL 9.4, chúng tôi có giải mã logic các bản ghi giao dịch. Điều này có nghĩa là bây giờ chúng ta có thể giải mã các giao dịch từ WAL và thao tác đầu ra.

Một thế giới hoàn toàn mới về các khả năng đã xuất hiện trong lĩnh vực nhân bản. Các trình kích hoạt không còn cần thiết để thực hiện sao chép hợp lý!

Về cơ bản, điều này có nghĩa là bạn không cần phải lưu một bản sao riêng của tất cả các lần chèn, cập nhật và xóa bằng trình kích hoạt nữa. Bạn chỉ có thể lấy các thao tác xử lý dữ liệu đó từ nhật ký giao dịch bằng cách giải mã nó. Sau đó, đó là công cụ bạn đang sử dụng phải thao tác đầu ra và gửi nó đến nút hạ lưu đã đăng ký. Trong trường hợp này, công cụ đó là pglogical.

Vậy, tất cả điều này có nghĩa là gì?

Chà, nếu bạn đang sử dụng phiên bản 9.4 hoặc 9.5 của PostgreSQL và bạn muốn nâng cấp lên 9.6, bạn có thể thực hiện nâng cấp trực tuyến như nâng cấp chi tiết ở trên, nhưng sử dụng pglogical thay vì một trong các giải pháp sao chép dựa trên trình kích hoạt.

Tôi sẽ không đi sâu vào chi tiết vì có các blog khác về chủ đề cụ thể này, như blog này được viết bởi Petr Jelinek:gói PGLogical 1.1 cho PostgreSQL 9.6beta1

Kết luận

Tùy thuộc vào lược đồ cơ sở dữ liệu của bạn, kích thước dữ liệu, thời gian ngừng hoạt động có thể xảy ra, phiên bản cài đặt PostgreSQL hiện tại, bạn có thể chọn một tùy chọn hơn một tùy chọn khác hoặc bất kỳ tùy chọn nào phù hợp nhất.

• Nếu cơ sở dữ liệu của bạn nhỏ và có một cửa sổ bảo trì phù hợp mà bạn có thể sử dụng, bạn có thể chọn chạy pg_dump và pg_restore. Tùy thuộc vào kích thước của tập dữ liệu, có thời điểm tùy chọn này không còn khả thi nữa.
• Nếu bạn có một cơ sở dữ liệu lớn (hàng trăm GB hoặc thậm chí hàng TB dữ liệu), bạn sẽ phải tìm kiếm các tùy chọn khác như nâng cấp tại chỗ với pg_upgrade hoặc nâng cấp trực tuyến.
  • Nếu nâng cấp từ phiên bản 8.3 trở lên lên bất kỳ phiên bản 9.x nào, bạn có thể sử dụng pg_upgrade.
  • Đối với các phiên bản cũ hơn 8.3, bạn sẽ phải chọn một trong các giải pháp sao chép hợp lý như londiste hoặc slony.
  • Nếu trên cơ sở dữ liệu 9.4 hoặc 9.5, tốt hơn hết bạn nên sử dụng pglogical.

Luôn nhớ rằng để sao chép hợp lý, các bảng phải có Khóa chính.

Với pglogical, quy tắc đó không quá nghiêm ngặt:Bạn có thể sao chép các bảng chỉ chèn. Nhưng để cập nhật và xóa, vẫn bắt buộc phải có Khóa chính hoặc NHẬN DẠNG PHIẾU trên bảng.

Nếu bạn đang cần trợ giúp để nâng cấp cơ sở dữ liệu PostgreSQL của mình, bạn có thể kiểm tra dịch vụ nâng cấp
2ndQuadrant.