PostgreSQL đi kèm với một bộ tính năng tuyệt vời, chưa từng có trong không gianRDBMS mã nguồn mở. Nó hầu hết dễ học và dễ sử dụng, đặc biệt là đối với các nhà phát triển ứng dụng. Tuy nhiên, một số phần, tốt, đơn giản là không dễ dàng. Chúng yêu cầu thiết lập công việc và thực hiện đúng, và thường cũng là nhiệm vụ quan trọng.
Quản lý kết nối
PostgreSQL khởi chạy một quy trình mới, được gọi là quy trình phụ trợ , để xử lý từng kết nối. Điều này trái ngược với các kiến trúc xử lý kết nối dựa trên eventloop / threadpool hiện đại được tìm thấy trong các phần mềm máy chủ tương đương khác.>
Trong hầu hết các triển khai, việc gộp các kết nối là bắt buộc ở một số cấp độ. Ở mức tương tự, điều này có thể được sử dụng ngôn ngữ lập trình / tính năng thư viện của bạn. Ví dụ:sql / DB.SetMaxIdleConnscan được sử dụng để tăng khả năng tái sử dụng kết nối từ trong một ứng dụng Go.
Tuy nhiên, thông thường, bạn sẽ phải sử dụng tổng hợp kết nối của bên thứ ba hoặc tải balancingsolution. Trình đánh cắp kết nối duy trì một nhóm các kết nối không hoạt động đến máy chủ Postgres luồng trực tuyến, được gán và ủy quyền cho các kết nối máy khách đến. Chúng thường phân tích cú pháp SQL do máy khách gửi đến để nhận biết ranh giới giao dịch và các DML sửa đổi dữ liệu để triển khai các tính năng tổng hợp kết nối cấp độ giao dịch và đọc bản sao.
PgBouncer là một trình gộp kết nối nhị phân đơn, nhẹ, phổ biến và thường được chạy cùng với PostgreSQL trong cùng một hệ thống.
PgPool là PgBouncer phiên bản hơn. Ví dụ, nó cũng có thể cân bằng tải và sao chép.
Tuy nhiên, việc gộp kết nối lại mang đến nhiều vấn đề đau đầu cho riêng nó. Thứ nhất, nó là phần chuyển động không điều kiện đã được duy trì trong quá trình triển khai của bạn. Việc thiết lập xác thực cũng là một vấn đề khó khăn nếu bạn có các ứng dụng khách sử dụng các thông tin xác thực hoặc cơ chế xác thực khác nhau.
Bản nâng cấp Zero Downtime
Nâng cấp PostgreSQL giữa các phiên bản nhỏ (13.x -> 13.y) liên quan đến việc cài đặt gói mới và khởi động lại quy trình máy chủ. Mặc dù việc khởi động lại quá trình máy chủ nhất thiết sẽ làm gián đoạn tất cả các máy khách được kết nối, nhưng đó vẫn là một yêu cầu hợp lý, vì thời gian ngừng hoạt động bị ràng buộc với khoảng thời gian khởi động lại dịch vụ.
Tuy nhiên, nâng cấp giữa các phiên bản chính (12.x -> 13.y) là một vấn đề lớn hơn nhiều.
Phương pháp đơn giản nhất, chỉ hoạt động với lượng dữ liệu thấp (hàng chục GB), là kết xuất dữ liệu từ phiên bản cũ và khôi phục nó vào máy chủ phiên bản mới. liên quan đến các tệp nhị phân của cả hai phiên bản củaPostgres.
Trong cả hai trường hợp, cơ sở dữ liệu sẽ ngừng hoạt động trong một khoảng thời gian đáng kể.
Lý tưởng nhất là có thể sao chép sang máy chủ phiên bản mới và quảng bá máy chủ phiên bản mới làm máy chủ chính. Tuy nhiên, không thể thực hiện sao chép trực tuyến sang một máy chủ dự phòng với một phiên bản chính khác.
Hầu hết các giải pháp HA cho Postgres dựa vào sao chép trực tuyến và do đó bạn không thể nâng cấp từng nút trong một cụm.
Kỹ thuật hiện tại sẽ là sử dụng sao chép hợp lý, đồng thời giải quyết các hạn chế của sao chép lôgic và có thể liên quan đến các tính năng hạn chế mà các ứng dụng có thể sử dụng (như DDL) trong giai đoạn nâng cấp.
Tính sẵn sàng cao
PostgreSQL đi kèm với tất cả các tính năng cấp thấp cần thiết để xây dựng HAsolution:sao chép với phản hồi, sao chép theo tầng, sao chép đồng bộ, dự phòng, dự phòng nóng, quảng cáo dự phòng, v.v. Nó không giới thiệu, thực sự cung cấp một giải pháp HA ngoài hộp. Không có khung hoặc công cụ để theo dõi tình trạng và tự động chuyển đổi dự phòng sang chế độ chờ. Không có khái niệm về cụm HA nhiều nút.
Bạn sẽ phải thiết lập và chạy giải pháp của bên thứ ba để tạo các triển khai Postgres có tính khả dụng cao. Mục yêu thích hiện tại làpg_auto_failoverand Patroni. Mặc dù Patroni dựa vào kho lưu trữ cấu hình có sẵn rất nhiều hiện có như ZooKeeper hoặc etcd, pg_auto_failover có thể thực hiện mà không cần một.
Đánh giá, triển khai và thử nghiệm một trong những điều này trong quá trình sản xuất cần có thời gian và hiệu quả. Sách phát theo dõi, cảnh báo và hoạt động phải được thiết lập và duy trì.
Quản lý Bloat
Kiến trúc MVCC của PostgreSQL có nghĩa là không có dữ liệu nào bị ghi đè – việc sửa đổi một hàng chỉ dẫn đến một phiên bản mới của hàng được ghi ra đĩa. Xóa một hàng chỉ có nghĩa là ghi lại rằng hàng đó là ẩn đối với các giao dịch trong tương lai. Khi một phiên bản hàng không thể truy cập được từ bất kỳ giao dịch nào đang diễn ra hoặc trong tương lai, nó sẽ không còn được sử dụng nữa và được gọi là “phình to”. Quá trình thu gom rác thải này được gọi là "chân không".
Bloat là vô hình đối với các ứng dụng và chỉ trở thành vấn đề đau đầu của DBA. tablelevel để đảm bảo kích thước bảng không tăng lên một cách khó quản lý.
Các chỉ mục cũng bị ảnh hưởng bởi hiện tượng phồng lên và tính năng autovacuum không giúp ích được gì ở đây. Việc xóa các hàng và cập nhật các cột được lập chỉ mục dẫn đến các mục chết trong chỉ mục. Khối lượng công việc cập nhật dày đặc với các cột được lập chỉ mục có thể dẫn đến các chỉ mục liên tục phát triển và kém hiệu quả. Không có chân không tương đương cho các chỉ số. Cách giải quyết duy nhất là tạo lại toàn bộ chỉ mục bằng REINDEX hoặc sử dụng VACUUM FULL trên bảng.
Ngoài một giá trị duy nhất trên mỗi bảng (pg_stat_all_tables.n_dead_tup), Postgres không cung cấp gì trong cách ước tính độ phồng trong bảng và không có gì tất cả cho các chỉ mục. Cách thiết thực nhất vẫn là thực hiện một truy vấn trông đáng sợ từ check_postgres.
pgmetrics kết hợp truy vấn từ check_postgres và có thể tạo ra đầu ra định dạng JSON và CSV bao gồm thông tin về kích thước và kích thước cho tất cả các bảng và chỉ mục; có thể được đưa vào các công cụ giám sát hoặc tự động hóa.
pg_repack là một giải pháp thay thế phổ biến choVACUUM FULL - nó có thể thực hiện công việc tương tự nhưng không có khóa. Nếu bạn buộc phải sử dụng VACUUM FULL thường xuyên, thì đó là một công cụ phải điều tra.
zheap là công cụ lưu trữ mới choPostgres đã được phát triển trong nhiều năm, hứa hẹn sẽ giảm tải thông qua các bản cập nhật tại chỗ.
Quản lý kế hoạch truy vấn
Core PostgreSQL chỉ cung cấp hai công cụ thô sơ trong không gian này:
- pg_stat_statements tiện ích mở rộng cho phân tích truy vấn - phần mở rộng này cung cấp tổng và trung bình của thời gian lập kế hoạch và thực thi truy vấn, mức sử dụng đĩa và bộ nhớ
- auto_explain tiện ích mở rộng, có thể in các kế hoạch thực thi truy vấn vào đích đến của nhật kýPostgres
Mặc dù số liệu thống kê được cung cấp bởi pg_stat_statements là vừa đủ để có được bằng cách sử dụng auto_explain buộc các kế hoạch vào các tệp nhật ký và sau đó trích xuất chúng thực sự không hơn gì một vụ hack, đặc biệt là so với các đối thủ cạnh tranh thương mại đối với Postgres, người cung cấp các tính năng quản lý, lịch sử kế hoạch, cơ sở và cơ sở.
Công nghệ hiện tại với Postgres là khai thác các kế hoạch truy vấn tệp nhật ký và lưu trữ chúng ở nơi khác. Nhưng có lẽ vấn đề khó khăn nhất là không thể kết hợp kế hoạch truy vấn với phân tích tương ứng từ pg_stat_statements. Cách pgDash thực hiện là phân tích cú pháp cả văn bản truy vấn SQL từ đầu ra pg_stat_statements vàauto_explain, điều chỉnh cho phù hợp với việc xử lý do pg_stat_statements thực hiện và cố gắng khớp cả hai. Nó yêu cầu một trình phân tích cú pháp SQL PostgreSQL-dialect đầy đủ.
Việc tạo cơ sở dữ liệu, thiết lập các chính sách để lựa chọn kế hoạch, v.v. không thể thực hiện được trong cốt lõi của PostgreSQL hiện tại.
Có một số tiện ích mở rộng về cơ bản là phiên bản cải tiến của pg_stat_statements, nhưng các bước bổ sung liên quan đến việc sử dụng tiện ích mở rộng bên thứ ba khiến nó trở thành thách thức đối với hầu hết mọi người, đặc biệt nếu họ đang sử dụng nhà cung cấp Postgres được quản lý.
Điều chỉnh
PostgreSQL có rất nhiều tùy chọn điều chỉnh, bắt đầu từ việc đặt cấu hình dưới định dạng theo-defaultshared_bufferssetting. Một số dễ hiểu và dễ đặt, chẳng hạn như số lượng nhân công song song cho các hoạt động khác nhau (max_worker_processes, max_parallel_ *, v.v.). Các khu vực khác hơi che khuất (wal_compression, random_page_cost, v.v.) nhưng nhìn chung là có lợi. Tuy nhiên, những thứ gây khó chịu nhất là những thứ cần thông tin có thể định lượng được về khối lượng công việc.
Ví dụ:if work_mem quá thấp, các truy vấn có thể sử dụng các tệp đĩa tạm thời; nếu quá cao và có đủ các truy vấn đồng thời, các quy trình phụ trợ Postgres có thể bị hủy OOM. Vậy làm thế nào để bạn tìm ra con số nào để đặt nó thành?
Thực tế, đặc biệt là với khối lượng công việc OLTP và khối lượng công việc ứng dụng web, không thể dự đoán nhu cầu bộ nhớ cao nhất cho các truy vấn sẽ là bao nhiêu. Đặt cược tốt nhất của bạn là đặt nó một giá trị hợp lý, sau đó theo dõi các truy vấn để xem liệu có bất kỳ truy vấn nào trong số chúng có thể được hưởng lợi từ giá trị cao hơn của work_mem hay không.
Và làm thế nào để bạn làm điều đó? Bạn sẽ cần tải tiện ích mở rộng auto_explain để ghi lại các kế hoạch thực thi truy vấn của từng truy vấn, trích xuất các kế hoạch đó từ tệp nhật ký của Postgres, kiểm tra từng kế hoạch truy vấn để xem liệu nó có sử dụng các hợp nhất bên ngoài dựa trên đĩa hoặc quét đống bitmap với các khối heap bị mất hay không.
Không phải là không thể, chỉ là khó.
