PostgreSQL Tính sẵn sàng cao / Khả năng mở rộng bằng HAProxy và PGBouncer

Tôi có nhiều máy chủ PostgreSQL cho một ứng dụng web. Thông thường, một chủ và nhiều nô lệ ở chế độ chờ nóng (sao chép phát trực tuyến không đồng bộ).

Tôi sử dụng PGBouncer để tổng hợp kết nối: một phiên bản được cài đặt trên mỗi máy chủ PG (cổng 6432) kết nối với cơ sở dữ liệu trên localhost. Tôi sử dụng chế độ nhóm giao dịch.

Để cân bằng tải các kết nối chỉ đọc của tôi trên các nô lệ, tôi sử dụng HAProxy (v1.5) với một conf ít nhiều như thế này:

listen pgsql_pool 0.0.0.0:10001
        mode tcp
        option pgsql-check user ha
        balance roundrobin
        server master 10.0.0.1:6432 check backup
        server slave1 10.0.0.2:6432 check
        server slave2 10.0.0.3:6432 check
        server slave3 10.0.0.4:6432 check

Vì vậy, ứng dụng web của tôi kết nối với haproxy (cổng 10001), kết nối cân bằng tải đó trên nhiều pgbouncer được định cấu hình trên mỗi nô lệ PG.

Đây là một biểu đồ đại diện cho kiến ​​trúc hiện tại của tôi:

Điều này hoạt động khá tốt như thế này, nhưng tôi nhận ra rằng một số thực hiện điều này hoàn toàn khác: ứng dụng web kết nối với một cá thể PGBouncer duy nhất kết nối với HAproxy để cân bằng tải trên nhiều máy chủ PG:

Cách tiếp cận tốt nhất là gì? Cái đầu tiên (cái hiện tại của tôi) hay cái thứ hai? Có bất kỳ lợi thế của một giải pháp so với giải pháp khác?

Cảm ơn

Cấu hình hiện tại của bạn về HAProxy -> PGBouncer -> PGServer chấp thuận là tốt hơn. Và điều đó chỉ hoạt động. Đây là lý do: HAProxy chuyển hướng kết nối đến các máy chủ khác nhau. điều này dẫn đến thay đổi địa chỉ MAC trong kết nối cơ sở dữ liệu. Vì vậy, nếu PGBouncer cao hơn HAProxy, mỗi lần kết nối trong nhóm bị vô hiệu do thay đổi địa chỉ MAC.

pgbouncer duy trì các kết nối trong một hồ bơi với một máy chủ postgres. Thời gian thiết lập kết nối TCP có ý nghĩa trong môi trường âm lượng lớn.

Các khách hàng thực hiện một số lượng lớn yêu cầu DB sẽ phải thiết lập kết nối với PGBouncer từ xa cho mỗi yêu cầu. Điều này tốn kém hơn so với việc chạy PGBouncer cục bộ (vì vậy ứng dụng kết nối với pgbouncer cục bộ) và pgBouncer duy trì một nhóm kết nối với máy chủ PG từ xa.

Vì vậy, IMO, PGBouncer -> HAProxy -> PGServer dường như tốt hơn, HAProxy -> PGBouncer -> PGServer, đặc biệt khi PGBouncer là cục bộ của ứng dụng khách.

Tôi phải không đồng ý với câu trả lời do donatello cung cấp.

Bạn thấy, nếu ứng dụng của bạn không quản lý các kết nối DB bằng cách sử dụng một nhóm cục bộ, nó sẽ tạo ra một kết nối mới mỗi lần nó cần truy vấn DB; điều đó xảy ra giống hệt nhau khi sử dụng PGBouncer, vì vậy bạn sẽ có một sự cải thiện rất tốt bằng cách sử dụng nó.

Khi PGBouncer đang quản lý các kết nối PostgreSQL bằng cách gộp chúng, thời gian ứng dụng của bạn dành để mở một kết nối giảm đáng kể, so với khi kết nối được mở trực tiếp tới DB. Đó là bởi vì PG khá chậm để kiểm tra và xác minh thông tin đăng nhập và mọi thứ mỗi khi kết nối được yêu cầu.

Vì vậy, cách tiếp cận Ứng dụng -> HAProxy -> [PGBouncer -> PostgreQuery] là cách tốt hơn, bởi vì PGBouncer tiết kiệm thời gian kết nối với PG. Chế độ gộp là quan trọng để tính đến là tốt. Bạn phải nhận thức được cách ứng dụng của bạn hoạt động. Có phải hầu hết là giao dịch? Hoặc, có phải là thực thi nhiều hơn các câu SQL nhỏ với độ đồng thời cao? Tất cả những thông số có ảnh hưởng đến hiệu suất.