PgBouncer در حالت تراکنشی؛ بررسی سازگاری برنامه و صف اتصال

این مرحله با مسئول مجاز تغییر تنظیمات روی میزبان PgBouncer انجام می‌شود. اگر نسخهٔ قبلی از قبل وجود دارد، متوقف شوید تا روی شواهد قبلی ننویسید. قطعهٔ بعدی نمونهٔ مقدارهاست، نه فایلی برای جایگزینی کل تنظیمات.

در یک نمونهٔ اختصاصیِ آزمایش می‌توانید تنظیم سراسری را بررسی کنید. اگر نمونه مشترک است، تغییر pool_mode می‌تواند مسیرهای بدون تنظیم اختصاصی را هم درگیر کند؛ آن را بدون تعیین دامنه اعمال نکنید. حساب، TLS، listener و تنظیمات نامرتبط را حفظ کنید و مجوز فایل را برای آسان‌شدن ویرایش عوض نکنید.

test ! -e '/etc/pgbouncer/pgbouncer.ini.before-transaction' || exit 1
(umask 077; cp --no-preserve=mode -- '/etc/pgbouncer/pgbouncer.ini' '/etc/pgbouncer/pgbouncer.ini.before-transaction') || exit 1
nano '/etc/pgbouncer/pgbouncer.ini'

با اتصال مدیریتی موجود RELOAD را درخواست کنید و سپس تنظیمات و poolها را ببینید. موفقیت RELOAD به معنی تازه‌شدن چرخهٔ همهٔ connectionهای برنامه نیست. اگر برنامه نیاز به بستن و ساختن دوبارهٔ pool خود دارد، این کار را فقط در محیط آزمایش و از مسیر معمول همان برنامه انجام دهید.

خطای تنظیمات در لاگ خصوصی PgBouncer را پیش از آزمون درایور برطرف کنید؛ مشاهدهٔ فایل روی دیسک، شاهد اعمال‌شدن تغییر نیست.

/usr/lib/postgresql/18/bin/psql -X -v ON_ERROR_STOP=1 'service=academy_pool_admin' -c 'RELOAD;' -c 'SHOW CONFIG;' -c 'SHOW DATABASES;' -c 'SHOW POOLS;'

این نمونه با Psycopg 3.2 یا جدیدتر، PgBouncer 1.22 یا جدیدتر و libpq 17 یا جدیدتر در کلاینت آماده اجرا می‌شود. ابتدا نسخهٔ واقعی را چاپ می‌کند؛ با ترکیب قدیمی‌تر ادامه ندهید. کد فقط یک عبارت خواندنی و پارامتردار را چند بار آماده و اجرا می‌کند و شناسهٔ پردازش سمت سرور را می‌گیرد.

ثابت‌ماندن PID در بار کم خطا نیست؛ ممکن است همان اتصال دوباره آزاد شده باشد. موفقیت این نمونه نیز سازگاری کل برنامه را ثابت نمی‌کند. تراکنش‌های هم‌زمان، نوع پارامترها، تغییر schema، بازیافت اتصال و مسیر خطای برنامه را جدا بسنجید. اجرای PREPARE در psql جای آزمون پروتکلِ درایور را نمی‌گیرد.

python3 - <<'PY'
import psycopg
from psycopg import pq
print("Psycopg", psycopg.__version__, "libpq", pq.version())
assert pq.version() >= 170000, "This recipe requires libpq17+"
with psycopg.connect(service='academy_pool_app', autocommit=True) as c:
    for n in range(20):
        with c.transaction():
            row = c.execute('SELECT pg_backend_pid(), %s::integer + 1', (n,), prepare=True).fetchone()
            assert row[1] == n + 1
            print(row)
PY

این نماها را هنگام بار کاری شبیه شرایط عادی برنامهٔ آزمایش بخوانید. اگر cl_waiting بالا می‌رود و اتصال‌های سمت سرور مشغول‌اند، تقاضا از ظرفیت فعلی خدمت‌دهی بیشتر است. ابتدا تراکنش طولانی و اشباع دیتابیس را پیدا کنید؛ زیادکردن pool پاسخ خودکار نیست.

نرخ و مدت انتظار را در یک بازه مقایسه کنید. تعداد کلاینت یا یک تصویر لحظه‌ای، به‌تنهایی میزان کار مفید را نشان نمی‌دهد. تغییر نوع نتیجهٔ کوئری پس از DDL نیز می‌تواند نیازمند هماهنگی با برنامه و تازه‌کردن اتصال‌های آن باشد.

/usr/lib/postgresql/18/bin/psql -X 'service=academy_pool_admin' -c 'SHOW POOLS;' -c 'SHOW STATS;' -c 'SHOW CLIENTS;' -c 'SHOW SERVERS;'