رپلیکیشن PostgreSQL با Patroni؛ quorum، جابه‌جایی و بازیابی امن

این تمرین برای مدیر لینوکسی است که با دسترسی‌های PostgreSQL آشناست: سه نود تازه می‌سازیم، مدیریت پردازه‌های پایگاه داده را به Patroni می‌دهیم و بازپخش WAL و جابه‌جایی برنامه‌ریزی‌شده را بررسی می‌کنیم. سه عضو etcd سرویس جداگانهٔ انتخاب رهبر را می‌سازند. این روش برای مهاجرت درجا روی دیتابیس موجود یا تأیید آمادگی HA تولید نیست.

تنظیمات بالای مطلب را باز کنید، مقدارها را تغییر دهید، اعمال کنید و سپس کپی بگیرید. آدرس نودهای pg1 تا pg3 به‌ترتیب 10.77.18.11، 10.77.18.12 و 10.77.18.13 در شبکهٔ 10.77.18.0/24 است. مبدأ واقعی مدیریت 10.77.18.50/32 است. پورت دیتابیس 5432، API مدیریتی 8008، کلاینت etcd 2379 و ارتباط اعضا 2380 باید متفاوت باشند. ریشهٔ مطلق /srv/academy-pg18 و نام کلاستر academy_pg18 باید مخصوص همین آزمایش و تازه باشند. مسیر دیتابیس موجود، ریشهٔ mount یا پوشهٔ مشترک برنامه را انتخاب نکنید. مسیر واقعی، symlink، مالکیت و listener را جداگانه بررسی کنید. مقدارهای شخصی و پیشرفت آن‌ها در sessionStorage همین تب، زبان، مقاله و محیط می‌مانند؛ پیشرفت پیش‌فرض localStorage است. مقدارها به URL، لینک اشتراک یا سرور فرستاده نمی‌شوند. هیچ رمز یا کلیدی وارد نکنید؛ شخصی‌سازی به معنی آزمون اجرایی آن مقدارها نیست.

PostgreSQL، WAL فیزیکی را از یک primary به دو standby می‌فرستد. نسخهٔ اصلی، معماری، افزونه‌ها و مسیر tablespace باید هماهنگ باشند؛ نسخه‌های فرعی را هم یکسان نگه دارید. Patroni از lease در etcd v3 برای هماهنگی نقش‌ها استفاده می‌کند و خودش داده را تکثیر نمی‌کند. کلاستر سه‌عضوی etcd با دو رأی تصمیم می‌گیرد و خرابی یک عضو را تحمل می‌کند؛ دو عضو هم به دو رأی نیاز دارند و با خرابی یک عضو quorum از دست می‌رود.

سه VM یا میزبان با دامنه‌های خرابی مستقل لازم است. قرار دادن یک رأی‌دهندهٔ etcd روی هر VM دیتابیس، توپولوژی کوچک آزمایش است؛ خرابی hypervisor، دیسک، رک، برق یا شبکهٔ مشترک را پوشش نمی‌دهد. در تولید ممکن است میزبان‌های جداگانه برای DCS لازم باشند. کلاینت هم به endpoint آگاه از نقش و سیاست اتصال مجدد نیاز دارد؛ این راهنما به نود مشخص وصل می‌شود و HAProxy یا IP شناور نمی‌سازد.

در مثال، synchronous_mode و synchronous_mode_strict روشن‌اند و تأیید یک standby لازم است. تأیید commit معمولاً منتظر ثبت WAL روی standby می‌ماند؛ اگر همتای همگام از دست برود، نوشتن تا انتخاب جایگزین مناسب متوقف می‌شود. تأخیر لینک رپلیکیشن بر زمان پاسخ اثر دارد. پارامتر synchronous_standby_names را خارج از کنترل Patroni تغییر ندهید.

حالت ناهمگام دسترسی‌پذیری را با احتمال از دست رفتن داده مبادله می‌کند؛ آستانهٔ lag تضمین صفرشدن اتلاف داده نیست، چون موقعیت WAL رهبر دوره‌ای ثبت می‌شود. حالت همگام سخت‌گیرانه ممکن است نوشتن را متوقف کند. ارتقای اجباری، تغییر synchronous_commit توسط کلاینت، commit لغوشده با نتیجهٔ نامعلوم، خرابی هم‌زمان دیسک‌ها و fencing معیوب همچنان مهم‌اند. RPO یعنی دادهٔ قابل‌قبول برای از دست رفتن و RTO یعنی زمان بازیابی اندازه‌گیری‌شده؛ ttl به‌تنهایی RTO نیست.

نسخه‌های پایدار بررسی‌شده PostgreSQL18.6، Patroni4.1.5 و etcd3.7.2 هستند؛ PostgreSQL19 RC1 انتخاب نشده است. PGDG برای Ubuntu26.10 با نام stonking فقط amd64 را پوشش می‌دهد؛ مسیرهای resolute26.04، noble24.04، trixie13 و bookworm12 هم بررسی شده‌اند. کل این تمرین عمداً برای amd64 است. Python پیش‌فرض این مسیرها به‌ترتیب 3.14، 3.14، 3.12، 3.13 و 3.11 است. در فهرست PGDG مربوط به 26.10 بستهٔ Patroni وجود ندارد؛ بستهٔ Ubuntu نسخهٔ 4.1.4 است. فهرست PGDG چهار مسیر دیگر Patroni4.1.5 دارد. وصله‌های توزیع و candidate امنیتی مهم‌اند؛ classifier بالادستی تضمین پشتیبانی توزیع نیست. از suite سیستم‌عامل دیگر یا باینری PG19 به‌عنوان جایگزین استفاده نکنید.