PG_REWIND(1) PostgreSQL 18.6 Documentation PG_REWIND(1)

pg_rewind - همگام‌سازی یک دایرکتوری داده PostgreSQL با دایرکتوری داده دیگری که از آن منشعب شده است

pg_rewind [گزینه...] {-D | --target-pgdata} دایرکتوری {--source-pgdata=دایرکتوری | --source-server=connstr}

دستور pg_rewind ابزاری برای همگام‌سازی یک کلاستر PostgreSQL با نسخه دیگری از همان کلاستر، پس از انشعاب خطوط زمانی کلاسترها از یکدیگر است. یک سناریوی معمول این است که یک سرور اصلی (primary) قدیمی پس از وقوع failover، مجدداً به عنوان یک سرور آماده‌به‌خدمت (standby) که از سرور اصلی جدید پیروی می‌کند به مدار بازگردانده شود.

پس از یک عقب‌گرد (rewind) موفقیت‌آمیز، وضعیت دایرکتوری داده مقصد مشابه با یک نسخه پشتیبان پایه (base backup) از دایرکتوری داده مبدأ است. برخلاف تهیه یک پشتیبان پایه جدید یا استفاده از ابزاری مانند rsync، دستور pg_rewind نیازی به مقایسه یا کپی کردن بلوک‌های رابطه (relation) تغییرنیافته در کلاستر ندارد. تنها بلوک‌های تغییریافته از فایل‌های رابطه موجود کپی می‌شوند؛ تمامی فایل‌های دیگر، شامل فایل‌های رابطه جدید، فایل‌های پیکربندی و سگمنت‌های WAL به طور کامل کپی می‌شوند. از این رو، هنگامی که پایگاه داده بزرگ باشد و تنها بخش کوچکی از بلوک‌ها میان کلاسترها تفاوت داشته باشد، عملیات عقب‌گرد به طور چشمگیری سریع‌تر از سایر روش‌ها خواهد بود.

دستور pg_rewind تاریخچه خطوط زمانی کلاسترهای مبدأ و مقصد را بررسی می‌کند تا نقطه انشعاب آن‌ها را تعیین کند، و انتظار دارد فایل‌های WAL را در دایرکتوری pg_wal کلاستر مقصد به طور کامل تا نقطه انشعاب بیابد. نقطه انشعاب می‌تواند در خط زمانی مقصد، خط زمانی مبدأ یا جد مشترک آن‌ها یافت شود. در سناریوی معمول failover که در آن کلاستر مقصد اندکی پس از انشعاب خاموش شده است، این موضوع مشکلی ایجاد نمی‌کند؛ اما اگر کلاستر مقصد پس از انشعاب برای مدت طولانی به کار ادامه داده باشد، ممکن است فایل‌های WAL قدیمی آن دیگر موجود نباشند. در این حالت، می‌توانید آن‌ها را به صورت دستی از آرشیو WAL به دایرکتوری pg_wal کپی کنید، یا pg_rewind را با گزینه -c اجرا نمایید تا به طور خودکار آن‌ها را از آرشیو WAL بازیابی کند. استفاده از pg_rewind به سناریوی failover محدود نمی‌شود؛ برای نمونه، یک سرور standby می‌تواند ارتقا یابد (promote شود)، چند تراکنش نوشتنی انجام دهد و سپس عقب‌گرد داده شود تا مجدداً به یک standby تبدیل گردد.

پس از اجرای pg_rewind، بازپخش (replay) فایل‌های WAL باید کامل شود تا دایرکتوری داده در وضعیتی سازگار قرار گیرد. هنگامی که سرور مقصد مجدداً راه‌اندازی شود، وارد بازیابی از آرشیو (archive recovery) شده و تمامی WALهای تولیدشده در سرور مبدأ را از آخرین چک‌پوینت قبل از نقطه انشعاب بازپخش می‌کند. اگر بخشی از WAL در زمان اجرای pg_rewind دیگر در سرور مبدأ در دسترس نبوده و بنابراین توسط نشست pg_rewind کپی نشده باشد، باید هنگام راه‌اندازی سرور مقصد در دسترس قرار داده شود. این کار را می‌توان با ایجاد یک فایل recovery.signal در دایرکتوری داده مقصد و با پیکربندی یک restore_command مناسب در postgresql.conf انجام داد.

دستور pg_rewind نیاز دارد که در سرور مقصد یا گزینه wal_log_hints در فایل postgresql.conf فعال باشد، یا چک‌سام‌های داده (data checksums) هنگام مقداردهی اولیه کلاستر با initdb فعال شده باشند (که حالت پیش‌فرض است). همچنین full_page_writes باید روی on تنظیم شده باشد، هرچند که به صورت پیش‌فرض فعال است.


هشدار: بروز خطا در حین عقب‌گرد (Failures While Rewinding)

اگر pg_rewind در حین پردازش با شکست مواجه شود، پوشه داده مقصد احتمالاً در وضعیتی نخواهد بود که بتوان آن را بازیابی کرد. در چنین حالتی، تهیه یک نسخه پشتیبان تازه و جدید توصیه می‌شود.

از آنجا که pg_rewind فایل‌های پیکربندی را به طور کامل از مبدأ کپی می‌کند، ممکن است لازم باشد پیش از راه‌اندازی مجدد سرور مقصد، پیکربندی مورد استفاده برای بازیابی تصحیح شود؛ به ویژه اگر مقصد مجدداً به عنوان یک standby برای مبدأ معرفی شود. اگر سرور را پس از پایان عملیات عقب‌گرد اما بدون پیکربندی بازیابی راه‌اندازی کنید، ممکن است مقصد دوباره از سرور اصلی منشعب گردد.

دستور pg_rewind در صورتی که فایل‌هایی را بیابد که نتواند مستقیماً روی آن‌ها بنویسد، بلافاصله متوقف خواهد شد. این اتفاق می‌تواند به عنوان مثال هنگامی رخ دهد که سرور مبدأ و مقصد از یک نگاشت فایلی یکسان برای کلیدها و گواهی‌های فقط‌خواندنی SSL استفاده کنند. اگر چنین فایل‌هایی در سرور مقصد وجود دارند، توصیه می‌شود قبل از اجرای pg_rewind آن‌ها را حذف کنید. پس از انجام عقب‌گرد، ممکن است برخی از این فایل‌ها از مبدأ کپی شده باشند که در این صورت شاید لازم باشد داده‌های کپی‌شده حذف گردند و مجموعه پیوندهای استفاده‌شده قبل از عقب‌گرد بازگردانده شوند.

دستور pg_rewind آرگومان‌های خط فرمان زیر را می‌پذیرد:

-D directory
--target-pgdata=directory

این گزینه دایرکتوری داده مقصد را که باید با مبدأ همگام‌سازی شود مشخص می‌کند. سرور مقصد باید قبل از اجرای pg_rewind به صورت تمیز خاموش شده باشد.

--source-pgdata=directory

مسیر سیستم فایلی دایرکتوری داده سرور مبدأ را برای همگام‌سازی مقصد با آن مشخص می‌کند. این گزینه نیازمند خاموش بودن تمیز سرور مبدأ است.

--source-server=connstr

یک رشته اتصال libpq را برای اتصال به سرور مبدأ PostgreSQL جهت همگام‌سازی مقصد با آن مشخص می‌کند. این اتصال باید یک اتصال عادی (غیر-replication) با نقشی باشد که دارای مجوزهای کافی جهت اجرای توابع استفاده‌شده توسط pg_rewind در سرور مبدأ باشد (برای جزئیات به بخش نکات مراجعه کنید) یا یک نقش مدیر ارشد (superuser) باشد. این گزینه نیازمند در حال اجرا بودن سرور مبدأ و پذیرش اتصالات است.

-R
--write-recovery-conf

ایجاد فایل standby.signal و افزودن تنظیمات اتصال به postgresql.auto.conf در دایرکتوری خروجی. مقدار dbname تنها در صورتی ثبت خواهد شد که به طور صریح در رشته اتصال یا متغیر محیطی مشخص شده باشد. استفاده از --source-server همراه با این گزینه الزامی است.

-n
--dry-run

انجام تمامی مراحل بدون اعمال هرگونه تغییر واقعی در دایرکتوری مقصد.

-N
--no-sync

به طور پیش‌فرض، pg_rewind منتظر می‌ماند تا تمامی فایل‌ها با امنیت کامل روی دیسک نوشته شوند. این گزینه باعث می‌شود که pg_rewind بدون انتظار بازگردد، که سرعت کار را افزایش می‌دهد، اما به این معنی است که کرش بعدی سیستم‌عامل می‌تواند موجب خرابی دایرکتوری داده شود. به طور کلی، این گزینه برای آزمودن مفید است اما نباید در یک نصب عملیاتی استفاده شود.

-P
--progress

فعال‌سازی گزارش پیشرفت. فعال کردن این گزینه، گزارش پیشرفت تقریبی را در حین کپی کردن داده‌ها از کلاستر مبدأ نمایش می‌دهد.

-c
--restore-target-wal

استفاده از restore_command تعریف‌شده در پیکربندی کلاستر مقصد جهت بازیابی فایل‌های WAL از آرشیو WAL در صورتی که این فایل‌ها دیگر در دایرکتوری pg_wal موجود نباشند.

--config-file=filename

استفاده از فایل پیکربندی اصلی مشخص‌شده برای کلاستر مقصد. این گزینه بر عملکرد pg_rewind زمانی اثر می‌گذارد که به صورت داخلی از دستور postgres برای عملیات عقب‌گرد روی این کلاستر استفاده می‌کند (هنگام دریافت restore_command با گزینه -c/--restore-target-wal و زمان اجبار به تکمیل بازیابی پس از خرابی).

--debug

چاپ خروجی تفصیلی اشکال‌زدایی که بیشتر برای توسعه‌دهندگان در هنگام خطایابی pg_rewind مفید است.

--no-ensure-shutdown

دستور pg_rewind نیاز دارد که سرور مقصد قبل از عقب‌گرد به صورت تمیز خاموش شده باشد. به طور پیش‌فرض، اگر سرور مقصد به صورت تمیز خاموش نشده باشد، pg_rewind ابتدا سرور مقصد را در حالت تک‌کاربره (single-user) راه‌اندازی می‌کند تا بازیابی پس از خرابی (crash recovery) را کامل کند، و سپس آن را متوقف می‌سازد. با ارسال این گزینه، pg_rewind از این مرحله صرف‌نظر کرده و در صورتی که سرور به صورت تمیز خاموش نشده باشد بلافاصله با خطا خارج می‌شود. در این حالت انتظار می‌رود کاربران خودشان این وضعیت را مدیریت کنند.

--sync-method=method

هنگامی که روی fsync تنظیم شود (که حالت پیش‌فرض است)، pg_rewind به صورت بازگشتی تمام فایل‌های موجود در دایرکتوری داده را باز کرده و همگام‌سازی می‌کند. جستجوی فایل‌ها از پیوندهای نمادین دایرکتوری WAL و هر tablespace پیکربندی‌شده پیروی خواهد کرد.

در لینوکس، می‌توان به جای آن از syncfs استفاده کرد تا از سیستم‌عامل خواسته شود کل سیستم‌های فایلی حاوی دایرکتوری داده، فایل‌های WAL و هر tablespace را همگام‌سازی کند. برای اطلاعات درباره نکاتی که هنگام استفاده از syncfs باید به آن‌ها توجه داشت، به recovery_init_sync_method مراجعه کنید.

این گزینه هنگامی که --no-sync استفاده شود هیچ اثری ندارد.

-V
--version

نمایش اطلاعات نسخه و خروج.

-?
--help

نمایش راهنما و خروج.

هنگامی که از گزینه --source-server استفاده شود، pg_rewind همچنین از متغیرهای محیطی پشتیبانی‌شده توسط libpq استفاده می‌کند (به بخش ۳۲.۱۵ مراجعه کنید).

متغیر محیطی PG_COLOR مشخص می‌کند که آیا در پیام‌های تشخیصی از رنگ استفاده شود یا خیر. مقادیر ممکن عبارتند از always، auto و never.

هنگام اجرای pg_rewind با استفاده از یک کلاستر برخط به عنوان مبدأ، می‌توان به جای مدیر ارشد (superuser) از نقشی با مجوزهای کافی جهت اجرای توابع مورد استفاده توسط pg_rewind در کلاستر مبدأ استفاده کرد. در اینجا نحوه ایجاد چنین نقشی با نام rewind_user آورده شده است:

CREATE USER rewind_user LOGIN;
GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;

ایده اصلی این است که تمامی تغییرات در سطح سیستم فایل از کلاستر مبدأ به کلاستر مقصد کپی شوند:

1.پیمایش لاگ WAL کلاستر مقصد، با شروع از آخرین چک‌پوینت قبل از نقطه‌ای که در آن تاریخچه خط زمانی کلاستر مبدأ از کلاستر مقصد منشعب شده است. برای هر رکورد WAL، هر بلوک داده‌ای که دستکاری شده است ثبت می‌شود. این کار فهرستی از تمامی بلوک‌های داده‌ای ارائه می‌دهد که پس از انشعاب کلاستر مبدأ، در کلاستر مقصد تغییر یافته‌اند. اگر برخی از فایل‌های WAL دیگر در دسترس نیستند، تلاش کنید pg_rewind را با گزینه -c مجدداً اجرا نمایید تا فایل‌های مفقود در آرشیو WAL جستجو شوند.
2.کپی کردن تمامی آن بلوک‌های تغییریافته از کلاستر مبدأ به کلاستر مقصد، چه با استفاده از دسترسی مستقیم به سیستم فایل (--source-pgdata) و چه از طریق SQL (--source-server). فایل‌های رابطه اکنون در وضعیتی معادل با لحظه آخرین چک‌پوینت تکمیل‌شده پیش از نقطه‌ای هستند که در آن خطوط زمانی WAL مبدأ و مقصد منشعب شدند، به علاوه وضعیت فعلی در مبدأ برای هر بلوکی که پس از آن انشعاب در مقصد تغییر یافته است.
3.کپی کردن تمامی فایل‌های دیگر، از جمله فایل‌های رابطه جدید، سگمنت‌های WAL، pg_xact و فایل‌های پیکربندی از کلاستر مبدأ به کلاستر مقصد. مشابه با پشتیبان‌های پایه، محتویات دایرکتوری‌های pg_dynshmem/، pg_notify/، pg_replslot/، pg_serial/، pg_snapshots/، pg_stat_tmp/ و pg_subtrans/ از داده‌های کپی‌شده از کلاستر مبدأ حذف می‌شوند. فایل‌های backup_label، tablespace_map، pg_internal.init، postmaster.opts، postmaster.pid و .DS_Store و همچنین هر فایل یا دایرکتوری که با pgsql_tmp شروع شود، نادیده گرفته می‌شوند.
4.ایجاد یک فایل backup_label برای آغاز بازپخش WAL در چک‌پوینت ایجادشده هنگام failover و پیکربندی فایل pg_control با یک حداقل LSN سازگاری که هنگام عقب‌گرد از یک مبدأ زنده به عنوان نتیجه pg_current_wal_insert_lsn() یا هنگام عقب‌گرد از یک مبدأ متوقف‌شده به عنوان LSN آخرین چک‌پوینت تعریف می‌شود.
5.هنگام راه‌اندازی مقصد، PostgreSQL تمامی WALهای مورد نیاز را بازپخش می‌کند، که در نتیجه دایرکتوری داده در وضعیتی سازگار قرار می‌گیرد.
2026 PostgreSQL 18.6