Tính năng Hot Standby mới trong PostgreSQL 9.0 sắp tới cho phép chạy các truy vấn đối với các nút chờ mà trước đó không làm gì khác ngoài việc thực hiện quy trình khôi phục. Hai kỳ vọng phổ biến mà tôi đã nghe thấy từ những người dùng dự đoán tính năng này là nó sẽ cho phép phân phối các truy vấn ngắn trên cả hai nút hoặc cho phép chạy các báo cáo dài ở chế độ chờ mà không cần sử dụng tài nguyên trên nút chính. Cả hai điều này đều có thể thực hiện ngay bây giờ, nhưng trừ khi bạn hiểu được những đánh đổi liên quan đến cách hoạt động của Chế độ chờ nóng, có thể có một số hành vi không lường trước được ở đây.
Truy vấn dài hạn tiêu chuẩn
Một trong những vấn đề truyền thống trong cơ sở dữ liệu sử dụng MVCC, như PostgreSQL, là truy vấn chạy dài phải giữ cho tài nguyên mở – được gọi là ảnh chụp nhanh trong triển khai Postgres hiện tại – để ngăn cơ sở dữ liệu xóa dữ liệu mà truy vấn cần vận hành. Ví dụ:chỉ vì một ứng dụng khách khác đã xóa một hàng và cam kết, nếu một truy vấn đang chạy cần hàng đó hoàn thành, bạn chưa thể thực sự xóa sạch các khối đĩa vật lý liên quan đến hàng đó. Bạn phải đợi cho đến khi không có truy vấn mở nào mong đợi hàng đó hiển thị vẫn còn ở xung quanh.
Hạn chế ở chế độ chờ nóng
Nếu bạn có một truy vấn dài mà bạn muốn Chế độ chờ nóng thực thi, có một số loại điều tồi tệ có thể xảy ra khi quá trình khôi phục đang áp dụng các bản cập nhật. Những điều này được mô tả chi tiết trong Tài liệu về chế độ chờ nóng. Một số điều tồi tệ này sẽ khiến các truy vấn đang chạy ở chế độ chờ bị hủy vì những lý do có thể không rõ ràng trực quan:
- Bản cập nhật HOT hoặc bản cập nhật liên quan đến VACUUM đến để xóa nội dung nào đó mà truy vấn mong muốn hiển thị
- Xóa cây B xuất hiện
- Có vấn đề về khóa giữa truy vấn bạn đang chạy và những khóa nào cần thiết để xử lý bản cập nhật.
Tình huống khóa rất khó xử lý, nhưng không có khả năng xảy ra trong thực tế trong thời gian dài như vậy nếu bạn chỉ chạy các truy vấn chỉ đọc ở chế độ chờ, vì các truy vấn đó sẽ được tách biệt thông qua MVCC. Hai người còn lại không khó để đụng độ. Điều cơ bản cần hiểu là bất kỳ CẬP NHẬT hoặc XÓA trên bản chính có thể dẫn đến làm gián đoạn bất kỳ truy vấn nào ở chế độ chờ; không quan trọng nếu các thay đổi thậm chí liên quan đến những gì truy vấn đang thực hiện.
Tốt, nhanh, rẻ:chọn hai
Về cơ bản, có ba điều mọi người có thể muốn ưu tiên:
- Tránh giới hạn chính:Cho phép xid và các ảnh chụp nhanh liên quan tiến lên không bị giới hạn trên chính, để VACUUM và quá trình dọn dẹp tương tự không bị cản trở bởi những gì chế độ chờ đang thực hiện
- Truy vấn không giới hạn:Chạy các truy vấn ở chế độ chờ trong bất kỳ khoảng thời gian tùy ý nào
- Khôi phục hiện tại:Luôn cập nhật quá trình khôi phục ở chế độ chờ với những gì đang xảy ra trên thiết bị chính, cho phép xử lý lỗi nhanh chóng cho HA
Trong bất kỳ tình huống nào với Chế độ chờ nóng, theo nghĩa đen là không thể có cả ba chế độ này cùng một lúc. Bạn chỉ có thể chọn sự đánh đổi của mình. Các thông số có thể điều chỉnh có sẵn đã cho phép bạn tối ưu hóa một số cách:
- Việc tắt tất cả các cài đặt trì hoãn / trì hoãn này sẽ tối ưu hóa khả năng khôi phục luôn hiện tại, nhưng sau đó bạn sẽ phát hiện ra các truy vấn có nhiều khả năng bị hủy hơn bạn mong đợi.
- max_standby_delay tối ưu hóa cho các truy vấn dài hơn, với chi phí duy trì khôi phục hiện tại. Điều này sẽ làm trì hoãn việc áp dụng các bản cập nhật cho chế độ chờ khi một bản cập nhật sẽ gây ra sự cố (HOT, VACUUM, xóa cây B, v.v.) xuất hiện.
- uum_defer_cleanup_age và một số hack ảnh chụp nhanh có thể giới thiệu một số giới hạn tổng thể để cải thiện hai vấn đề còn lại, nhưng với giao diện người dùng yếu để làm điều đó. uum_defer_cleanup_age tính bằng đơn vị ID giao dịch. Bạn cần có một số ý tưởng về lượng xid khuấy động trung bình trên hệ thống của bạn trên mỗi đơn vị thời gian để biến cách mọi người nghĩ về vấn đề này (“hoãn ít nhất 1 giờ để báo cáo của tôi sẽ chạy”) thành cài đặt cho giá trị này. tỷ lệ tiêu thụ xid không phải là một điều phổ biến hoặc thậm chí hợp lý để đo lường / dự đoán. Ngoài ra, bạn có thể mở ảnh chụp nhanh trên tệp chính trước khi bắt đầu truy vấn chạy dài ở chế độ chờ. dblink được đề xuất trong tài liệu Chế độ chờ nóng như một cách để thực hiện điều đó. Về mặt lý thuyết, một daemon ở chế độ chờ có thể được viết trong vùng đất của người dùng, sống trên vùng đất chính, cũng để giải quyết vấn đề này (Simon có một thiết kế cơ bản cho một daemon). Về cơ bản, bạn bắt đầu một loạt các quy trình mà mỗi quy trình thu được một ảnh chụp nhanh và sau đó ngủ trong một khoảng thời gian trước khi phát hành nó. Bằng cách giãn cách khoảng thời gian mà mỗi chúng ngủ trong thời gian bạn có thể đảm bảo các ảnh chụp nhanh xid không bao giờ tiến về phía trước quá nhanh trên bản chính. Nghe có vẻ rõ ràng đây sẽ là một vụ hack khủng khiếp như thế nào.
Cải tiến tiềm năng
Điều duy nhất trong số này bạn thực sự có thể làm một cách rõ ràng là thắt chặt và cải thiện giao diện người dùng cho giới hạn chính. Điều đó biến điều này thành vấn đề truyền thống đã có trong cơ sở dữ liệu:một truy vấn chạy dài sẽ mở một ảnh chụp nhanh (hoặc ít nhất là giới hạn việc nâng cao các ID giao dịch liên quan đến khả năng hiển thị) trên bản chính, ngăn không cho bản chính xóa những thứ cần thiết cho truy vấn đó. hoàn thành. Bạn có thể coi đây là một công cụ tự động điều chỉnh chân không_defer_cleanup_age.
Câu hỏi đặt ra là làm thế nào để tạo ra tính năng chính tôn trọng nhu cầu của các truy vấn chạy dài ở chế độ chờ . Điều này có thể thực hiện được nếu chia sẻ thêm thông tin về các yêu cầu khả năng hiển thị giao dịch của chế độ chờ. Thực hiện kiểu trao đổi đó thực sự sẽ là điều gì đó thích hợp hơn để chia sẻ việc triển khai Streaming Replication mới. Cách cung cấp máy chủ Hot Standby đơn giản không cung cấp bất kỳ phản hồi nào về máy chủ phù hợp để trao đổi dữ liệu này, bên cạnh các cách tiếp cận như hack dblink đã được đề cập.
Với việc PostgreSQL 9.0 vừa đạt bản phát hành alpha thứ tư, có thể Vẫn còn thời gian để xem một số cải tiến trong lĩnh vực này trước khi phát hành 9.0. Thật tuyệt khi thấy Hot Standby và Streaming Replication thực sự được tích hợp với nhau theo cách hoàn thành những việc mà cả hai đều không hoàn toàn có khả năng tự làm trước khi mã hóa trên bản phát hành này hoàn toàn bị đóng băng.
