Postgres chứa một chân trời sự kiện chuyển động, có hiệu lực khoảng 2 tỷ giao dịch trước hoặc sau id giao dịch hiện tại. Các giao dịch lên đến 2 tỷ trước hoặc hơn 2 tỷ sau id giao dịch hiện tại được coi là trong tương lai và do đó sẽ vô hình đối với các giao dịch hiện tại.
Postgres tránh mất dữ liệu nghiêm trọng này bằng cách đánh dấu đặc biệt các hàng cũ để bất kể chúng ở đâu so với id giao dịch hiện tại, chúng sẽ được hiển thị.
Đóng băng là quá trình đánh dấu các bộ dữ liệu trực tiếp cũ (tức là các hàng cơ sở dữ liệu) để chúng không bị vượt qua bởi chân trời sự kiện đang di chuyển mà nếu không sẽ khiến chúng có vẻ như trong tương lai. Điều này trái ngược với việc hút bụi, là việc giải phóng không gian bị tiêu tốn bởi các bộ giá trị cũ đã chết mà không còn hiển thị cho bất kỳ giao dịch nào.
Cả hai quy trình đều được quản lý bằng chân không.
Có một số cài đặt chi phối cách thực hiện đóng băng.
Đầu tiên, vacuum_freeze_min_age điều chỉnh việc một tuple sẽ bị đóng băng hay không trong khi chân không đang xem xét một trang để xem liệu nó có các tuple đã chết có thể được làm sạch hay không. Tuples cũ hơn vacuum_freeze_min_age sẽ bị đóng băng trong trường hợp này. Đặt mức thấp này có nghĩa là sẽ có ít công việc phải làm hơn sau này, nhưng với cái giá phải trả là nỗ lực nhiều hơn cả trong hoạt động của CPU và IO hoặc WAL. Nói chung, bạn có thể muốn tập hợp này có giá trị giao dịch ít nhất là vài giờ. Giả sử bạn đang mong đợi thực hiện tới 2000 giao dịch mỗi giây với tốc độ ổn định. 2000 TPS là 7,2 triệu giao dịch mỗi giờ. Do đó, một thiết lập khá tích cực cho trường hợp này có thể nói là 20m. Cài đặt mặc định là 50m. Tương tự cho vacuum_multixact_freeze_min_age . Lưu ý rằng các bộ đếm transaction_id và multixid là độc lập - bạn cần theo dõi cả hai bộ đếm đó.
Thứ hai, có vacuum_freeze_table_age và vacuum_multixact_freeze_table_age . Các cài đặt này chi phối khi autovacuum sẽ không chỉ xem xét các trang có thể có các hàng chết mà còn bất kỳ trang nào có thể có các hàng không được đóng băng. Giá trị mặc định cho các cài đặt này là 150m. Nếu bạn đã giảm vacuum_freeze_min_age đủ, trong nhiều trường hợp, chân không tích cực hơn này sẽ có rất ít hoặc không có việc gì phải làm. Trong mọi trường hợp, quá trình này không còn bận rộn như trước nữa, vì các phiên bản hiện đại của Postgres (9.6 trở lên) giữ một bản đồ các trang mà tất cả các bộ giá trị đều được đóng băng và chỉ truy cập những trang không bị đóng băng tất cả. Điều đó có nghĩa là đây không còn là quá trình quét toàn bộ bảng.
Cuối cùng là autovacuum_freeze_max_age . Nếu lần cuối cùng bảng được quét hoàn toàn để tìm các hàng không được đóng băng nhiều hơn lần trước nhiều giao dịch này, autovacuum sẽ bắt đầu hút chân không chống bao quanh trên bảng. Mặc định là 200m. Tương tự cho autovacuum_multixact_freeze_max_age trong đó mặc định là 400m. Đây là điều bạn thực sự muốn tránh. Có hai điều có thể được thực hiện. Đầu tiên, việc tăng các cài đặt này lên đến 1 tỷ là rất phổ biến, để tạo cho bạn nhiều khoảng trống hơn, đặc biệt là trên các hệ thống có nhiều người tiêu dùng giao dịch. Bạn có thể kiếm được nhiều tiền hơn nhưng bạn muốn có nhiều không gian giao dịch giữa tuple cũ nhất của mình và chân trời sự kiện. Thứ hai, điều quan trọng là phải giám sát hệ thống của bạn và thực hiện hành động khắc phục trước khi bất kỳ cơ sở dữ liệu nào gặp sự cố này. Biện pháp khắc phục hậu quả này thường bao gồm hút bụi bằng tay.
Một vấn đề có thể xảy ra là nơi bạn có DDL khiến autovacuum bình thường (tức là không chống quấn) tự hủy. Nếu bạn làm đủ điều này thì cuối cùng bạn sẽ bắt buộc phải có chân không chống quấn và bất kỳ DDL nào sau đó sẽ xếp hàng sau quy trình chân không và điều đó sẽ chặn bất kỳ DML nào tiếp theo. Ở giai đoạn này, bảng của bạn không thể đọc được hiệu quả cho đến khi quá trình hút chân không kết thúc. Điều này phụ thuộc vào kiểu sử dụng cơ sở dữ liệu của bạn, nhưng đây không chỉ là một khả năng lý thuyết và việc triển khai Postgres và DBA cần phải tính đến.
Giám sát cụm cơ sở dữ liệu của bạn là rất quan trọng để quản lý điều này. Đặc biệt, bạn cần theo dõi datfrozenxid và datminmxid của mỗi cơ sở dữ liệu trong cụm và nếu những cơ sở dữ liệu này quá cũ, hãy thực hiện hành động khắc phục trước khi yêu cầu chân không chống bao quanh. Thường thì vấn đề là với một hoặc một vài bảng trong cơ sở dữ liệu. Bạn có thể phát hiện ra những vấn đề nào bằng cách kiểm tra relfrozenxid và relminmxid của các bảng trong cơ sở dữ liệu. age() và mxid_age() các chức năng này rất hữu ích để khám phá độ tuổi của bộ đếm id giao dịch và bộ đếm đa oxy tương ứng.
Đóng băng không phải là điều bạn có thể tránh, đây là hoạt động bảo trì thiết yếu trong Postgres cần được quản lý tích cực.
