← شروع آموزش

WIUNIX ACADEMY

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

صفحهٔ 5 از 6؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Ubuntu 26.04 LTSبررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

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

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من11 مقدار قابل‌تغییر
19

قدم بعدی

جابه‌جایی برنامه‌ریزی‌شده را تمرین کنید

نوشتن آزمایشی را متوقف کنید، سلامت replicaها و timeline مشترک را بررسی کنید و مطمئن شوید pg2 نامزد همگام و مجاز است. اگر نقش‌ها فرق دارند، نام‌ها را کورکورانه اجرا نکنید. فرمان تعاملی تأیید می‌خواهد؛ جزئیاتش را بخوانید. رهبر عوض می‌شود و اتصال‌ها قطع می‌شوند. switchover برنامه‌ریزی‌شده آزمون قطع برق، partition یا fencing نیست. برای writable کردن replica ناهماهنگ از failover اجباری استفاده نکنید.

منتظر بمانید خود patronictl نقش pg2 را Sync Standby نشان دهد؛ حالت موقت sync در SQL هنگام bootstrap برای اثبات مجاز بودن نامزد کافی نیست.

Bash

ماشین آزمایشی پایگاه داده؛ Bash با دسترسی مدیر

sudo -u postgres patronictl -c '/srv/academy-pg18/patroni.yml' list
sudo -u postgres patronictl -c '/srv/academy-pg18/patroni.yml' switchover 'academy_pg18' --leader pg1 --candidate pg2
sudo -u postgres patronictl -c '/srv/academy-pg18/patroni.yml' list
از کجا بدانم درست انجام شد؟

pg2 رهبر و pg1 دنبال‌کننده می‌شود؛ پیش از نوشتن، نقش و timeline همه بررسی شود.

20

قدم بعدی

نشان را از رهبر جدید بررسی کنید

پس از تأیید leader بودن روی pg2 اجرا کنید. اتصال را صریحاً دوباره برقرار می‌کنیم؛ endpoint ثابت کلاینت نساخته‌ایم. برنامه برای نتیجهٔ نامعلوم commit به retry آگاه از تراکنش و idempotency نیاز دارد. recovery و نشان اول را بررسی کنید، نشان دوم را بنویسید و با پنل خواندن قبلی هر دو را روی pg1 ببینید.

Bash

ماشین آزمایشی پایگاه داده؛ Bash با دسترسی مدیر

sudo -u postgres psql -h '/srv/academy-pg18/socket' -p 5432 -d academy_replication_probe -X -v ON_ERROR_STOP=1 <<'SQL'
SET statement_timeout = '15s';
SELECT pg_is_in_recovery();
TABLE probe;
INSERT INTO probe VALUES (2, 'after-switchover');
SELECT pg_current_wal_lsn();
SQL
از کجا بدانم درست انجام شد؟

recovery روی pg2 برابر false و هر دو نشان روی pg1 متصل‌شده خواندنی‌اند.

نگهداشت WAL جای بکاپ نیست

slot می‌تواند برای replica قطع‌شده WAL نگه دارد و دیسک را پر کند. سقف 2GB این مثال نگهداشت را محدود می‌کند، اما ممکن است slot عقب‌مانده نامعتبر شود. wal_keep_size حداقل نگهداشت است، نه آرشیو. وضعیت slot، restart_lsn، فضای دیسک، lag و خطای آرشیو را پایش کنید. اگر WAL لازم حذف شده باشد، replica شاید به basebackup تازه در مقصد خالی و تازه نیاز داشته باشد؛ برای پنهان کردن lag، slot یا PGDATA را پاک نکنید. حذف اشتباهی داده هم تکثیر می‌شود. دادهٔ واقعی به base backup جداگانه، آرشیو پیوستهٔ WAL، نگهداشت، رمزنگاری و تمرین restore/PITR در محیط مستقل نیاز دارد؛ این مقاله چنین سامانه‌ای ایجاد نمی‌کند.

21

قدم بعدی

بدون ارتقای replica ناامن عیب‌یابی کنید

روی VM دچار مشکل اجرا کنید. permission denied در etcd یعنی CN خالی گواهی gateway، نام کاربری و رمز حفاظت‌شده، نقش auth و prefix دقیق را بررسی کنید؛ خطای اتصال یعنی مسیر، SAN، انقضا و ساعت را ببینید. اگر به دلیل از دست رفتن اکثریت رهبر ندارید، quorum را برگردانید؛ DCS جایگزین مقداردهی نکنید و replica عقب‌مانده را اجباری ارتقا ندهید. نوشتن متوقف‌شده ممکن است رفتار درست strict mode باشد؛ همتای همگام و دیسک را بررسی کنید. نبود WAL لازم با ساخت مجدد بررسی‌شده حل می‌شود، نه trust یا خاموش کردن TLS. bootstrap.dcs فقط بار اول اعمال می‌شود؛ تغییر بعدی باید با بازبینی پیکربندی پویا و patronictl edit-config انجام شود.

Bash

ماشین آزمایشی پایگاه داده؛ Bash با دسترسی مدیر

sudo systemctl status academy-pg-patroni.service academy-pg-etcd.service --no-pager
sudo journalctl -u academy-pg-patroni.service -u academy-pg-etcd.service -n 80 --no-pager
sudo -u postgres patronictl -c '/srv/academy-pg18/patroni.yml' list
sudo -u postgres patronictl -c '/srv/academy-pg18/patroni.yml' show-config
sudo -u postgres psql -h '/srv/academy-pg18/socket' -p 5432 -d postgres -X -c "SELECT pg_is_in_recovery();"
sudo -u postgres psql -h '/srv/academy-pg18/socket' -p 5432 -d postgres -X -c "SELECT name,setting,pending_restart FROM pg_settings WHERE name IN ('synchronous_commit','synchronous_standby_names','max_slot_wal_keep_size');"
sudo df -h '/srv/academy-pg18'
sudo openssl x509 -in '/srv/academy-pg18/tls/api.crt' -noout -dates -ext subjectAltName
از کجا بدانم درست انجام شد؟

دلیل مربوط به نقش، timeline، quorum، TLS یا نگهداشت مشخص می‌شود؛ ارتقای ناامن انجام نشده است.

failover به fencing بیرون از این آزمایش نیاز دارد

منقضی شدن lease به‌تنهایی VM مکث‌کرده یا primary گیرکرده را متوقف نمی‌کند. پیش از تولید باید ثابت شود نویسندهٔ قبلی پیش از قبول تراکنش روی نویسندهٔ جدید واقعاً جدا یا reset شده است. حالت required در Patroni در نبود watchdog قابل‌فعال‌سازی، رهبری را نمی‌پذیرد؛ اما watchdog نرم‌افزاری همان کرنل معادل قطع برق مستقل نیست. ttl، loop_wait، retry_timeout، pause و حاشیهٔ زمانی watchdog را با هم بررسی کنید. کشتن تنها Patroni آزمون fencing نیست؛ PostgreSQL ممکن است زنده بماند. نتیجهٔ واقعی partition، توقف، اتلاف داده، اتصال مجدد و بازیابی را ثبت کنید. watchdog این تمرین خاموش است و هیچ پذیرش failover خودکار تولید یا تضمین صفرشدن اتلاف داده ندارد.

پیش از اتصال مجدد، دادهٔ واگرا را حفظ کنید

برای primary قبلی، ابتدا نوشتن کلاینت را قطع و snapshot یا کپی خصوصی از دیتای متوقف و WAL لازم نگه دارید. timeline مرجع با شواهد کلاستر سالم و تصمیم بازیابی کسب‌وکار تعیین می‌شود. pg_rewind مقصد را تغییر می‌دهد و ممکن است تراکنش‌های واگرا را دور بریزد؛ checksum یا wal_log_hints، WAL لازم و full_page_writes نیاز دارد. در این آزمایش checksum از ابتدا فعال است. دو گزینهٔ حذف data خاموش می‌مانند تا خطا داده را بی‌صدا پاک نکند. reinit، حذف prefix در DCS، initdb دوباره یا بازنویسی مقصد پر را اجرا نکنید. اگر rewind امن نیست، اصل را حفظ کنید و restore یا clone را در مقصد خالی جداگانه و بررسی‌شده انجام دهید. نود ابتدا standby برگردد، نشان‌ها و LSN بررسی شوند و بعد شاید switchover دیگری انجام شود؛ failback بازنویسی خودکار primary قدیمی نیست.

همهٔ آموزش‌های آکادمی ↗