| PG_REWIND(1) | PostgreSQL 18.6 Documentation | PG_REWIND(1) |
نام (NAME)
pg_rewind - همگامسازی یک دایرکتوری داده PostgreSQL با دایرکتوری داده دیگری که از آن منشعب شده است
خلاصه دستور (SYNOPSIS)
pg_rewind [گزینه...] {-D | --target-pgdata} دایرکتوری {--source-pgdata=دایرکتوری | --source-server=connstr}
توضیحات (DESCRIPTION)
دستور 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 آنها را حذف کنید. پس از انجام عقبگرد، ممکن است برخی از این فایلها از مبدأ کپی شده باشند که در این صورت شاید لازم باشد دادههای کپیشده حذف گردند و مجموعه پیوندهای استفادهشده قبل از عقبگرد بازگردانده شوند.
گزینهها (OPTIONS)
دستور pg_rewind آرگومانهای خط فرمان زیر را میپذیرد:
-D directory
--target-pgdata=directory
--source-pgdata=directory
--source-server=connstr
-R
--write-recovery-conf
-n
--dry-run
-N
--no-sync
-P
--progress
-c
--restore-target-wal
--config-file=filename
--debug
--no-ensure-shutdown
--sync-method=method
در لینوکس، میتوان به جای آن از syncfs استفاده کرد تا از سیستمعامل خواسته شود کل سیستمهای فایلی حاوی دایرکتوری داده، فایلهای WAL و هر tablespace را همگامسازی کند. برای اطلاعات درباره نکاتی که هنگام استفاده از syncfs باید به آنها توجه داشت، به recovery_init_sync_method مراجعه کنید.
این گزینه هنگامی که --no-sync استفاده شود هیچ اثری ندارد.
-V
--version
-?
--help
محیط (ENVIRONMENT)
هنگامی که از گزینه --source-server استفاده شود، pg_rewind همچنین از متغیرهای محیطی پشتیبانیشده توسط libpq استفاده میکند (به بخش ۳۲.۱۵ مراجعه کنید).
متغیر محیطی PG_COLOR مشخص میکند که آیا در پیامهای تشخیصی از رنگ استفاده شود یا خیر. مقادیر ممکن عبارتند از always، auto و never.
نکات (NOTES)
هنگام اجرای 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;
نحوه کارکرد (How It Works)
ایده اصلی این است که تمامی تغییرات در سطح سیستم فایل از کلاستر مبدأ به کلاستر مقصد کپی شوند:
| 2026 | PostgreSQL 18.6 |