این دستور pg_resetxlog است که می تواند در ارائه دهنده هاست رایگان OnWorks با استفاده از یکی از چندین ایستگاه کاری آنلاین رایگان ما مانند Ubuntu Online، Fedora Online، شبیه ساز آنلاین ویندوز یا شبیه ساز آنلاین MAC OS اجرا شود.
برنامه:
نام
pg_resetxlog - تنظیم مجدد گزارش پیش از نوشتن و سایر اطلاعات کنترلی یک PostgreSQL
خوشه پایگاه داده
خلاصه
pg_resetxlog [-c xid,xid] [-f] [-n] [-o گرم] [-x xid] [-e xid_epoch] [-m mxid,mxid]
[-O mxoff] [-l xlogfile] {[-D] datadir}
شرح
pg_resetxlog گزارش پیش ثبت نام (WAL) را پاک می کند و به صورت اختیاری برخی از کنترل های دیگر را بازنشانی می کند
اطلاعات ذخیره شده در فایل pg_control. اگر اینها گاهی اوقات به این تابع نیاز است
فایل ها خراب شده اند باید فقط به عنوان آخرین راه حل استفاده شود، زمانی که سرور این کار را انجام دهد
به دلیل چنین فسادی شروع نشود.
پس از اجرای این دستور، باید امکان راه اندازی سرور وجود داشته باشد، اما در نظر داشته باشید
که پایگاه داده ممکن است حاوی داده های متناقض به دلیل تراکنش های ناقص باشد.
شما باید بلافاصله داده های خود را تخلیه کنید، اجرا کنید initdbو بارگیری مجدد کنید. پس از بارگذاری مجدد، بررسی کنید
ناهماهنگی و تعمیر در صورت نیاز.
این ابزار فقط توسط کاربری که سرور را نصب کرده است قابل اجرا است، زیرا به آن نیاز دارد
دسترسی خواندن/نوشتن به فهرست داده ها به دلایل ایمنی، باید داده ها را مشخص کنید
دایرکتوری در خط فرمان pg_resetxlog از متغیر محیطی استفاده نمی کند PGDATA.
If pg_resetxlog شکایت می کند که نمی تواند داده های معتبری را برای pg_control تعیین کند، شما می توانید
آن را مجبور کنید به هر حال با مشخص کردن آن ادامه دهد -f (اجبار) گزینه. در این مورد قابل قبول است
مقادیر جایگزین داده های از دست رفته می شوند. بیشتر زمینه ها را می توان انتظار داشت
مطابقت دارند، اما ممکن است برای OID بعدی، شناسه تراکنش بعدی و به کمک دستی نیاز باشد
epoch، شناسه و افست چند تراکنش بعدی، و فیلدهای آدرس شروع WAL. این زمینه ها
را می توان با استفاده از گزینه های مورد بحث در زیر تنظیم کرد. اگر قادر به تشخیص صحیح نیستید
مقادیر برای همه این فیلدها، -f هنوز هم می توان استفاده کرد، اما پایگاه داده بازیابی شده باید باشد
حتی بیشتر از حد معمول با شک و تردید رفتار شود: تخلیه فوری و بارگیری مجدد ضروری است.
Do نه هر گونه عملیات تغییر داده را در پایگاه داده قبل از تخلیه، به عنوان هر یک، اجرا کنید
اقدام به احتمال زیاد فساد را بدتر می کند.
La -o, -x, -e, -m, -O, -c و -l گزینه ها به OID بعدی، شناسه تراکنش بعدی، بعدی اجازه می دهند
دوره شناسه تراکنش، شناسه چند تراکنش بعدی و قدیمی، افست چند تراکنش بعدی،
قدیمی ترین و جدیدترین شناسه تراکنش که می توان زمان تعهد را برای آنها بازیابی کرد و WAL
مقادیر آدرس شروع به صورت دستی تنظیم شوند. اینها فقط زمانی مورد نیاز هستند pg_resetxlog is
قادر به تعیین مقادیر مناسب با خواندن pg_control نیست. ارزش های ایمن می تواند باشد
به شرح زیر تعیین می شود:
· یک مقدار مطمئن برای شناسه تراکنش بعدی (-x) را می توان با جستجو برای تعیین کرد
از نظر عددی بزرگترین نام فایل در دایرکتوری pg_clog زیر فهرست داده ها،
یک اضافه کنید و سپس در 1048576 ضرب کنید. توجه داشته باشید که نام فایل ها در
هگزادسیمال معمولاً ساده ترین کار است که مقدار گزینه را به صورت هگزادسیمال نیز مشخص کنید. برای
به عنوان مثال، اگر 0011 بزرگترین ورودی در pg_clog باشد، -x 0x1200000 کار خواهد کرد (پنج
صفرهای دنباله دار ضریب مناسب را ارائه می کنند).
· یک مقدار مطمئن برای شناسه چند تراکنش بعدی (بخش اول از -m) را می توان توسط
به دنبال عددی بزرگترین نام فایل در دایرکتوری pg_multixact/offsets
در زیر دایرکتوری داده، یک را اضافه کنید و سپس در 65536 ضرب کنید. برعکس، یک
مقدار امن برای قدیمی ترین شناسه چند تراکنش (بخش دوم از -m) را می توان توسط
به دنبال کوچکترین نام فایل از نظر عددی در همان فهرست و ضرب می شود
توسط 65536. همانطور که در بالا، نام فایل ها به صورت هگزادسیمال هستند، بنابراین ساده ترین راه برای انجام این کار است.
این است که مقدار گزینه را به صورت هگزادسیمال مشخص کنید و چهار صفر را اضافه کنید.
· یک مقدار مطمئن برای آفست چند تراکنش بعدی (-O) را می توان با نگاه کردن مشخص کرد
برای عددی بزرگترین نام فایل در دایرکتوری pg_multixact/members در زیر
دایرکتوری داده، اضافه کردن یک، و سپس ضرب در 52352. همانطور که در بالا، نام فایل ها
هگزادسیمال هستند. هیچ دستور العمل ساده ای مانند موارد فوق در پیوست وجود ندارد
صفر
· یک مقدار امن برای قدیمی ترین شناسه تراکنش که می توان زمان تعهد را برای آن بازیابی کرد
(بخش اول از -c) را می توان با جستجوی کوچکترین نام فایل از نظر عددی تعیین کرد
در دایرکتوری pg_commit_ts زیر فهرست داده ها. برعکس، یک ارزش امن برای
جدیدترین شناسه تراکنش که می توان زمان تعهد را برای آن بازیابی کرد (بخش دوم
-c) را می توان با جستجوی عددی بزرگترین نام فایل در همان تعیین کرد
فهرست راهنما. همانطور که در بالا، نام فایل ها به صورت هگزادسیمال هستند.
· آدرس شروع WAL (-l) باید بزرگتر از هر نام فایل بخش WAL باشد
در حال حاضر در دایرکتوری pg_xlog زیر دایرکتوری داده وجود دارد. این اسامی هستند
همچنین به صورت هگزادسیمال و دارای سه قسمت هستند. بخش اول «شناسه تایم لاین» و
معمولا باید به همین شکل نگه داشته شود. به عنوان مثال، اگر 00000001000000320000004A
بزرگترین ورودی در pg_xlog، از -l 00000001000000320000004B یا بالاتر استفاده کنید.
توجه داشته باشید:
pg_resetxlog خودش به فایل های pg_xlog نگاه می کند و یک پیش فرض را انتخاب می کند -l محیط
فراتر از آخرین نام فایل موجود بنابراین، تنظیم دستی از -l فقط باید
اگر از فایلهای بخش WAL که در حال حاضر در آنها وجود ندارند، آگاه هستید، مورد نیاز است
pg_xlog، مانند ورودیهای یک آرشیو آفلاین؛ یا اگر محتویات pg_xlog داشته باشد
به طور کامل گم شده است
· هیچ راه نسبتاً آسانی برای تعیین OID بعدی که فراتر از بزرگترین باشد وجود ندارد
در پایگاه داده، اما خوشبختانه انجام صحیح تنظیمات OID بعدی حیاتی نیست.
· دوره شناسه تراکنش در واقع در هیچ کجای پایگاه داده به جز در ذخیره نمی شود
فیلدی که توسط pg_resetxlog، بنابراین هر مقداری تا آنجا که پایگاه داده کار می کند
خودش نگران است برای اطمینان از تکرار، ممکن است لازم باشد این مقدار را تنظیم کنید
سیستم هایی مانند Slony-I و Skytools به درستی کار می کنند - اگر چنین است، یک مقدار مناسب
باید از وضعیت پایگاه داده تکراری پایین دستی قابل دستیابی باشد.
La -n (بدون عملیات) گزینه دستور می دهد pg_resetxlog برای چاپ مقادیر بازسازی شده از
pg_control و مقادیر در حال تغییر هستند و سپس بدون تغییر چیزی از آن خارج شوید. این
عمدتا یک ابزار اشکال زدایی است، اما می تواند به عنوان یک بررسی عقلانی قبل از اجازه دادن مفید باشد
pg_resetxlog برای ادامه واقعی
La -V و - نسخه گزینه ها نسخه pg_resetxlog را چاپ کرده و از آن خارج شوید. گزینه ها -? و
--کمک آرگومان های پشتیبانی شده را نشان دهید و از آن خارج شوید.
NOTES
این دستور نباید زمانی که سرور در حال اجراست استفاده شود. pg_resetxlog امتناع خواهد کرد
اگر فایل قفل سرور را در فهرست داده ها پیدا کرد، راه اندازی شود. اگر سرور خراب شد
ممکن است یک فایل قفل باقی مانده باشد. در این صورت می توانید فایل قفل را حذف کنید
اجازه دادن pg_resetxlog برای اجرا اما قبل از انجام این کار، دوچندان مطمئن شوید که وجود ندارد
فرآیند سرور هنوز زنده است.
با استفاده از خدمات onworks.net از pg_resetxlog به صورت آنلاین استفاده کنید