مرحبًا بالجميع،
أتساءل عما إذا كان أي منكم لديه خبرة في استخدام pgpool II بدلاً من pgbouncer مع Discourse، وإذا كان الأمر كذلك، فما هو الانطباع حتى الآن؟
هل تفكرون، يا فريق، في ذلك في مرحلة ما، وإذا كان الأمر كذلك، فما السبب؟
شكرًا لكم،
إسماعيل
لا يدعم pgpool II تجميع المعاملات. وبدون تجميع المعاملات، تكون قيمته محدودة للغاية في الاستضافة واسعة النطاق، كما أنه يضيف تعقيدًا فقط.
في حالة استضافة Discourse بشكل “عادي” (self-hosted)، ستواجه صعوبة في تجاوز 30-60 اتصالًا نشطًا، بينما لن يعاني PostgreSQL من ذلك. لذا، لا حاجة إلى أداة تجميع الاتصالات لإضافة تعقيد إلى إعدادك.
شكرًا جزيلاً لك سام. بالفعل، كما ذكرت، قد لا يكون ذلك منطقيًا لعدد قليل من الاتصالات. أيضًا، مع الأخذ في الاعتبار تجميع المعاملات، هناك فائز واحد فقط في هذه الحالة.
ومع ذلك، إلى حد علمي، لاحظت أن pgbouncer لا يدعم التوفر العالي (HA)، بينما يدعمه pgpool II. ماذا عن وضع pgbouncer “أمام” pgpool للسماح بهذه الميزة؟ ما هي التوصية لنهج التوفر العالي (HA) الذي يناسب Discourse بشكل جيد؟
يوفر Discourse التوفر العالي (HA) بشكل افتراضي باستخدام الإعدادات العالمية.
انظر: GitHub - discourse/rails_failover · GitHub
وابحث في الإعدادات العالمية هنا: discourse/config/discourse_defaults.conf at main · discourse/discourse · GitHub
ستقوم بتكوين pgbouncerين في وضع التوفر العالي / عند الحاجة إلى عدد هائل من الاتصالات.