Hai tháng trước khi PostgreSQL 14 kết thúc hỗ trợ: Luyện tập khôi phục trước khi nâng cấp
Có những đội ngũ đã lên lịch nâng cấp phiên bản cơ sở dữ liệu nhưng lại không biết sẽ mất bao lâu để quay trở lại nếu thất bại. Nếu đang vận hành PostgreSQL 14, kết quả bạn cần lúc này không phải là một cái tên phiên bản mới, mà là một kế hoạch chuyển đổi có khả năng khôi phục. Tính đến ngày 14 tháng 9 năm 2026, chỉ còn khoảng hai tháng nữa là đến ngày kết thúc hỗ trợ chính thức.
Sự thật đã xác nhận: Hỗ trợ cộng đồng khác với hợp đồng lưu trữ
Chính sách phiên bản chính thức của PostgreSQL hỗ trợ các phiên bản lớn trong 5 năm, và công bố ngày phát hành cuối cùng của phiên bản 14 là ngày 12 tháng 11 năm 2026. Đây là lịch trình hỗ trợ của cộng đồng. Khung thời gian nâng cấp, hỗ trợ mở rộng riêng và chi phí của các dịch vụ quản lý (managed services) cần được kiểm tra riêng trong tài liệu và hợp đồng của nhà cung cấp tương ứng.
Bạn cũng cần phân biệt giữa các bản cập nhật phụ (minor update) và nâng cấp phiên bản lớn (major upgrade) trong cùng một nhánh. Việc áp dụng bản sửa lỗi mới nhất của 14 không thể thay thế cho việc chuyển sang phiên bản 15 trở lên. Ngược lại, việc liên tục trì hoãn áp dụng các bản sửa lỗi cần thiết cho phiên bản hiện tại chỉ vì lý do đã có kế hoạch chuyển đổi lớn cũng là điều không phù hợp.
Kết quả đầu ra đầu tiên: Danh sách phụ thuộc quan trọng hơn dung lượng dữ liệu
Từ phần này trở đi là các đề xuất vận hành thực tế, không phải chính sách hỗ trợ chính thức. Trước tiên, hãy ghi lại trên một trang duy nhất: phiên bản DB của từng dịch vụ, các mô-đun mở rộng (extension) cùng phiên bản, driver kết nối, tác vụ xử lý hàng loạt (batch job), vị trí lưu trữ bản sao lưu và cấu hình nhân bản (replication). Đừng chọn phiên bản đích chỉ vì nó mới nhất, mà hãy kiểm tra đồng thời phạm vi hỗ trợ của môi trường lưu trữ thực tế và các mô-đun mở rộng.
Giả định rằng cơ sở dữ liệu nhỏ thì sẽ chuyển đổi nhanh là chưa đủ. Nếu các tiện ích mở rộng hoặc truy vấn được sử dụng trên các luồng quan trọng về mặt kinh doanh—chẳng hạn như truy vấn đầu tiên sau khi đăng nhập hoặc cập nhật trạng thái thanh toán—bị thay đổi, quá trình chuyển đổi vẫn có thể thất bại dù thời gian sao chép dữ liệu rất ngắn. Mục đích của danh sách này là tìm ra những phần phụ thuộc không có người chịu trách nhiệm.
Kết quả đầu ra thứ hai: Kết quả phục hồi thay vì thông báo sao lưu thành công
Hãy khôi phục bản sao lưu gần nhất vào một môi trường cô lập và chạy các luồng đọc/ghi đại diện của ứng dụng. Trong bài diễn tập này, trước tiên bạn phải kiểm tra đích kết nối để đảm bảo không gửi lệnh ghi tới DB vận hành thực tế. Bản khôi phục chứa dữ liệu thật phải được xử lý trong phạm vi kiểm soát truy cập hiện có.
Việc tách biệt thời điểm bắt đầu sao lưu, thời điểm hoàn tất khôi phục và thời điểm hoàn tất kiểm tra sẽ giúp bạn không nhầm lẫn giữa thời gian lấy tệp về với thời gian dịch vụ có thể ghi trở lại. Thay vì chỉ chạy thử thành công trên một mẫu dữ liệu nhỏ nhanh giả tạo, hãy đo thời gian bằng bản khôi phục gần với kích thước thực tế khi vận hành, đồng thời ghi nhận cả các hạn chế về chi phí và dung lượng lưu trữ.
Vượt qua kiểm tra pg_upgrade không thay thế cho việc xác thực dịch vụ
Tài liệu chính thức của pg_upgrade giải thích rằng bạn có thể sử dụng tùy chọn --check để thực hiện kiểm tra tính tương thích trước khi nâng cấp thực tế. Tính tương thích của các mô-đun bên ngoài phải được kiểm tra riêng, và bạn cũng cần các thư viện chia sẻ (shared library) phù hợp với máy chủ mới. Đừng hiểu nhầm rằng chỉ cần lệnh kiểm tra thành công là toàn bộ truy vấn và hiệu năng của ứng dụng đã được xác thực.
Đặc biệt, phương thức --link có hạn chế là bạn không thể tiếp tục sử dụng cụm máy chủ cũ sau khi đã khởi động cụm máy chủ mới. Nếu chọn phương thức này chỉ vì tốc độ, lộ trình khôi phục dự kiến có thể biến mất. Bạn phải diễn tập dưới các điều kiện giống hệt như phương thức chuyển đổi thực tế và xác định rõ thời điểm cần quay lại dựa trên khôi phục sao lưu.
Tiêu chí cần quyết định trước khi nối lại việc ghi dữ liệu
Hãy viết sẵn các tiêu chí thành công để không phải thỏa thuận gấp gáp ngay trong ngày chuyển đổi. Ví dụ: hoàn tất đọc/ghi các API cốt lõi, tiếp tục các tác vụ hàng loạt mà không bị xử lý trùng lặp, khớp số liệu tổng hợp nghiệp vụ trên các bảng chính và xác nhận trạng thái nhân bản có thể được gắn với từng người phụ trách cụ thể. Đây không phải là một ví dụ nhằm áp đặt cùng một giá trị tiêu chuẩn cho mọi dịch vụ.
Nếu quay lại bản sao lưu trước sau khi đã bắt đầu ghi dữ liệu vào DB mới, việc bảo toàn các thay đổi phát sinh trong khoảng thời gian đó cũng sẽ trở thành vấn đề. Đừng xem quy trình chỉ đơn giản là bật lại máy chủ cũ tương đương với quy trình khôi phục không làm mất dữ liệu. Mức độ mất mát và thời gian gián đoạn có thể chấp nhận được phải do người chịu trách nhiệm dịch vụ thống nhất.
Việc cần làm trong tuần này và các ý kiến phản biện
Nếu khó chuyển đổi tất cả DB cùng một lúc, hãy đo thời gian khôi phục, xác thực và quay lui với một dịch vụ có ít phụ thuộc nhất, sau đó dùng kết quả này làm dữ liệu đầu vào cho kế hoạch của các dịch vụ khác. Việc tập hợp người phụ trách, ngày dự kiến chuyển đổi và tiêu chí dừng khi xác thực thất bại vào một tài liệu duy nhất sẽ biến dự án từ chỗ chỉ có lịch trình thành các công việc khả thi.
Ý kiến cho rằng việc phát triển sản phẩm trước mắt cấp bách hơn là điều hoàn toàn có thể hiểu được. Tuy nhiên, nếu tiếp tục duy trì tình trạng không biết cách khôi phục cho đến sát hạn chót, thời gian kiểm tra mà bạn có thể lựa chọn sẽ bị thu hẹp lại. Bài viết này không nhằm khẳng định sự cải thiện hiệu năng của một phiên bản cụ thể hay đại diện cho ý kiến của toàn bộ cộng đồng. Đây là đề xuất vận hành tập trung vào sự chuẩn bị để xử lý khi chuyển đổi thất bại hơn là tốc độ áp dụng các tính năng mới nhất.