Nâng cấp Postgres không gián đoạn

Chuẩn bị cho việc nâng cấp Postgres

• Đánh giá rủi ro: Lập danh sách các rủi ro có thể phát sinh trong quá trình nâng cấp và sắp xếp theo mức độ quan trọng.
• Tìm phương án xử lý rủi ro: Xem xét các giải pháp có thể loại bỏ hoàn toàn rủi ro hoặc phân tán chúng theo thời gian.
• Cập nhật danh sách rủi ro: Cập nhật danh sách khi phát hiện rủi ro mới trong quá trình thực hiện dự án.

Về giám sát và chỉ số

• Giám sát hệ thống: Sử dụng các công cụ toàn diện để theo dõi tình trạng của cơ sở dữ liệu và hệ thống.
• Theo dõi các chỉ số cốt lõi: Giám sát các chỉ số quan trọng như transaction ID, mức sử dụng CPU, session chờ, độ trễ truy vấn, độ trễ phản hồi API, v.v.

Các tùy chọn nâng cấp Postgres

Nâng cấp tại chỗ (không phù hợp với nâng cấp zero-downtime)

• Giới hạn của nâng cấp tại chỗ: Khi chạy trên AWS RDS, cần khởi động lại cơ sở dữ liệu và thời gian thực hiện phụ thuộc vào lượng dữ liệu.

Nâng cấp dựa trên replication

• Chọn nâng cấp dựa trên replication: Có các giai đoạn migration dần dần, có thể kiểm thử cơ sở dữ liệu mới với workload và dữ liệu thực tế, đồng thời nắm quyền kiểm soát tốt hơn đối với quá trình nâng cấp.
• Thiết lập cơ sở dữ liệu nguồn và đích: Thiết lập replication slot, đặt wal_level thành logical.

Chọn cách replication bảng

Replication các bảng "nhỏ"

• Replication bảng nhỏ: Có thể replication bằng cách add đơn giản và làm mới subscription.

Bảng lớn chỉ append

• Replication bảng chỉ append: Đặt tùy chọn copy_data thành false để chỉ replication các thay đổi trong tương lai, sau đó backfill dữ liệu cũ từ bản sao lưu.

Bảng lớn có nhiều cập nhật

• Replication bảng lớn có nhiều cập nhật: Giảm kích thước bảng, chạy VACUUM, và cân nhắc partitioning bảng.

Kiểm tra trạng thái replication bảng

• Giám sát trạng thái replication: Kiểm tra trạng thái replication qua bảng hệ thống pg_subscription_rel, và khuyến nghị replication từng bảng một.

Dừng replication

• Cách dừng replication: Khi cần, có thể dừng replication bảng và rollback bằng cách làm mới subscription.

Lưu ý về việc chuyển replication slot

• Vấn đề khi chuyển replication slot: LSN của replication slot là duy nhất cho cơ sở dữ liệu gốc nên không thể sao chép trực tiếp sang cơ sở dữ liệu mới.

Hoàn tất migration

• Xác minh tính nhất quán của bảng: Kiểm tra số lượng hàng giữa hai cơ sở dữ liệu có khớp nhau hay không, và nếu cần thì xác minh tính nhất quán dữ liệu bằng lấy mẫu ngẫu nhiên.

Thay đổi ở cấp độ ứng dụng

• Thay đổi kết nối cơ sở dữ liệu: Điều chỉnh ứng dụng để kết nối tới cơ sở dữ liệu mới và xây dựng chiến lược chuyển lưu lượng.

Bổ sung về sequence

• Đồng bộ sequence: Giá trị sequence không được đồng bộ trong quá trình replication, vì vậy cần đặt giá trị sequence thủ công.

Checklist kiểm tra cuối cùng

• Kiểm tra cuối cùng: Tính nhất quán của bảng, trạng thái subscription, sự khớp của schema, kích thước cơ sở dữ liệu, thêm replica, tái tạo index, kiểm thử hiệu năng, đánh giá rủi ro, và diễn tập trong môi trường staging.

Chuyển đổi cuối cùng

• Thực hiện chuyển đổi cuối cùng: Replication bảng vào buổi tối, diễn tập nhiều lần trong môi trường staging, sau đó kiểm tra cuối và chuyển cờ.

Ý kiến của GN⁺

• Tầm quan trọng: Knock đã thực hiện thành công quy trình phức tạp để nâng cấp từ Postgres 11.9 lên 15.3 mà không có downtime. Đây là một cột mốc quan trọng về quản trị cơ sở dữ liệu và tính sẵn sàng của dịch vụ.
• Điểm thú vị: Cách tiếp cận nâng cấp dựa trên replication cho phép các quản trị viên cơ sở dữ liệu chuyển đổi mượt mà sang cơ sở dữ liệu mới, điều này có thể thu hút nhiều sự quan tâm từ cộng đồng kỹ thuật.
• Điểm hay: Quy trình nâng cấp của Knock cho thấy một ví dụ điển hình về cách vượt qua thách thức kỹ thuật phức tạp thông qua quản lý rủi ro có hệ thống và giải quyết vấn đề.

[GN⁺]

Ý kiến Hacker News

• Có một cách tốt hơn là sao chép các bảng dung lượng lớn.

  • Có thể tạo một bản sao logic bằng cách tạo replication slot, lấy snapshot, khôi phục snapshot sang instance mới, tiến LSN và bắt đầu replication.
  • Bài viết của Instacart có giải thích quy trình này.
  • Bài viết có thể có một vài lỗi nhỏ, nhưng cách này đã được dùng thành công nhiều lần để nâng cấp các instance cỡ TB.

• Cách tiếp cận được trình bày ở đây khá thú vị và được tài liệu hóa tốt, nhưng không đồng ý với câu "khách hàng hiện đại kỳ vọng khả dụng 100%".

  • Theo kinh nghiệm ở vị trí khách hàng lẫn nhà cung cấp, tính nhất quán quan trọng hơn khả dụng rất nhiều.
  • Khi một vendor thông báo downtime, điều đó tạo cảm giác yên tâm vì họ đang xử lý dữ liệu một cách cẩn trọng.

• AWS hiện đã hỗ trợ triển khai blue-green.

• Đã viết một công cụ tự động hóa phần lớn các vấn đề này.

  • Công cụ được chia sẻ trên GitHub và có thể được mở rộng thông qua phản hồi hoặc ý tưởng đóng góp.

• Đang di chuyển tại hava.io từ AWS RDS PostgreSQL 11.13 lên 15.5.

  • Đã chọn cách replication một chiều bằng pglogical.
  • Cách này không nhanh, nhưng có thể mất vài ngày để sao chép dần cơ sở dữ liệu sang instance mới.
  • Nó cho phép linh hoạt hơn trong việc thay đổi loại và kích thước storage.

• Có người đặt câu hỏi về nhận định rằng bất kỳ downtime nào cũng không thể chấp nhận được đối với dịch vụ Knock.

  • Hệ thống phức tạp thì sẽ có sự cố và downtime.
  • 15 phút downtime được thông báo trước không phải là vấn đề với phần lớn doanh nghiệp SaaS.
  • Đầu tư thời gian kỹ thuật vào phát triển sản phẩm hoặc cải thiện tốc độ của đội ngũ phát triển có thể mang lại sự hài lòng lớn hơn cho người dùng.
  • Trong database migration, khối lượng công việc giữa việc tạo migration "ít downtime" và "zero downtime" chênh lệch rất lớn.

• Có người ngạc nhiên vì không thể khởi tạo replication từ backup.

  • Làm vậy lẽ ra có thể giảm bớt sự phiền toái của việc stream nội dung DB ổn định hiện có sang server mới.
  • Dù nói là "zero downtime", thực tế vẫn có vài giây downtime khi chuyển sang server mới.
  • Thiếu chi tiết về cách duy trì tính nhất quán.
  • Không thấy nhắc tới phương án rollback; khi thực hiện một lần chuyển đổi dữ liệu quy mô lớn thì luôn cần có kế hoạch quay lại bước trước.

• Có người hỏi liệu có ai quan tâm đến một công cụ all-in-one chỉ cần nhập database credential là có thể cập nhật Postgres với zero downtime hay không.

• Phần nói về việc dùng sequence khá thú vị.

  • Thay vì sequence, họ chủ yếu dùng UUID tuần tự hoặc thuật toán HiLo.

• Có người đùa rằng các vấn đề trong hệ thống phân tán có thể được giải quyết bằng một lệnh sleep(1000) phù hợp.

  • Postgres không phải là hệ thống quá thân thiện với DBA, nhưng đã tốt hơn trước đây nhiều.