قابلیت ردیابی معامله در Postgresql 10 با txid_status (…)

یکی از ویژگی های بی سر و صدا به PostgreSQL 10 اضافه شده است ، امکان تعیین وضعیت تعهد هر معامله توسط معامله-ID است.

منطقی است که تعجب کنیم که چرا این را می خواهید ، زیرا می دانید که آیا معامله را مرتکب شده اید ، هنوز در حال انجام است ، یا اینکه شما یا آن را به عقب برگردانید. و می توانید معاملات در حال پیشرفت را درpg_stat_activity.

این امر برای کمک به بازیابی درخواست پس از خرابی بدون نیاز به استفاده از تعهد دو فاز سنگین وزن ، به حالت شناخته شده کمک می کند. این همچنین برای جستجوی Standbys مفید است.

بهبود

تصور کنید که برنامه شما به تازگی ارسال کرده استمرتکب شدنبرای معامله ای که بخشی از سیستم پردازش صف است. قبل از اینکه برنامه پاسخی به درخواست تعهد خود دریافت کند ، اتصال پایگاه داده به دلیل مشکلات شبکه ، خرابی پایگاه داده و غیره شکسته می شود. این امکان وجود دارد که معامله انجام شود ، اما هیچ پاسخی به مشتری نرسید. اما در صورت عدم موفقیت اتصال قبل از دریافت تعهد توسط سرور ، می توان معامله را به صورت خودکار بازگرداند. ما هیچ راهی نداریم که بدانیم سرور در صورت درخواست تعهد دریافت کرده و عمل کرده است یا خیر. بنابراین برنامه نمی داند که آیا می تواند کار صف را به عنوان تکمیل مشخص کند یا اینکه دوباره آن را امتحان کنید.

یک راه حل استفاده از تعهد دو فاز (2pc) است. با استفاده از 2pc ، برنامه قول می دهد که معامله قبل از ارسال یک تعهد نهایی ، در DB مداوم در DB است. این اجازه می دهد تا وضعیت تعهد دو فاز را در آن بررسی کنیدpg_twophaseو از آن برای بازیابی تصادف استفاده کنید.

اما 2pc بسیار سنگین است. این افزودنی های اضافی به پایگاه داده اضافی ، اضافیfsync ()S و غیره

باtxid_status ()پشتیبانی در PostgreSQL 10 ، برنامه اکنون می تواند هنگام شروع معامله نوشتن ، معامله ID را که به معامله اختصاص داده شده است ، ضبط کند. در صورت از دست دادن اتصال خود یا اینکه سرور DB خراب می شود ، می تواند از XID برای جستجوی وضعیت تکمیل معامله استفاده کند. بر اساس نتیجه می تواند تصمیم بگیرد که آیا یک مورد خاص از کار را تکرار کنید یا خیر.

اگر برنامه بخواهد وضعیت معاملاتی را که با تصادفات برنامه نیز قطع شده است ، تعیین کند ، باید شناسه های معامله را در ذخیره سازی مداوم محلی ذخیره کند. به عنوان مثال ، ممکن است به یک پرونده ژورنال نوشتن ساده بنویسد "من قصد دارم مورد صف 42 را در معاملات Postgres 34531 انجام دهم."سپس "من با موفقیت در صف آیتم 42 در معاملات Postgres 34531". در هنگام راه اندازی مجدد ، می تواند از طریق ژورنال نوشتاری خود بخواند ، هر ورودی را که تکمیل نشده بود ، پیدا کنید و از PostgreSQL بپرسید که نتیجه چیست. این به طور موثری یک حل کننده معامله سبک است ، همانطور که در XA استفاده می شود ، بسیار ساده تر است.

احتمالاً تعجب می کنید که چرا برنامه فقط ورود به "صف آیتم 42 تکمیل شده" را به یک جدول در Postgres همراه با کارهایی که توسط صف انجام شده است ، نمی نویسد. غالباً ، این فقط می تواند این کار را انجام دهد و سپس جدول را پرس و جو کنید تا دریابید که آیا یک مورد تکمیل شده در صورتی که مطمئن نیست یا خیر. اما در بعضی موارد ، برنامه کنترل کامل بر طرحواره ندارد. یا کارهایی که انجام می دهد ، خود خود را به مجله خود در پایگاه داده وام نمی دهد - به ویژه هنگامی که تعداد زیادی از XACT های حساس به عملکرد کوچک است و برنامه نمی خواهد بار بیشتری را به DB اضافه کند.

standbys querying

txid_status ()همچنین می تواند برای پرس و جو از آماده به کار و دریابید که آیا آن را تا یک معامله خاص دوباره پخش می شود یا خیر. یک برنامه ممکن است بخواهد تا زمانی که دوباره به یک نقطه خاص بازگردد ، نمایش داده شدگان را به تعویق بیندازد ، و می تواند با حلقه زدن این کار را انجام دهدtxid_status ().

در حال حاضر بیشتر برنامه ها برای پرس و جو کافی استpg_current_wal_insert_lsn ()(بودpg_current_xlog_insert_location ()در 9. 6 و بالاتر) پس از یک معامله مهم. سپس صبر کنید تا حالت آماده به کار از آن نقطه گذشته باشد قبل از اینکه دوباره آماده کار برای نمایش داده شود. انتظار می تواند در سمت اصلی با نظارت انجام شودPG_STAT_REPLICATION، یا در سمت آماده به کار توسط پرس و جوpg_last_wal_replay_lsn(بودpg_last_xlog_replay_location).

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

بنابراین توسط خود خود ،txid_status ()برای قوام آماده به کار هیجان انگیز نیست. ولی…

کار آینده

من می خواهم اضافه کنمTXID_WAIT_FOR_COMMIT (BIGINT)عملکردی که تا زمانی که XID عرضه شده انجام شود ، مسدود می شود. در تعهد ، باز می گردد ، و اگر XACT سقط شود ، در عوض خطا است. این امر به برنامه ها اجازه می دهد با پیشوند تمام نمایش داده های خود با یک پرس و جوهای مداوم در حالت ایستاده خود دست یابندtxid_wait_for_commitدر آخرین XID متعهد استاد.

من همچنین می خواهم به PostgreSQL آموزش دهم تا هنگام اختصاص به طور خودکار معاملات ID را به مشتری ارسال کند ، بنابراین مشتری آن را همراه با پاسخ به اولین بیانیه نوشتن در یک معامله دریافت می کند. این امر می تواند استفاده از برنامه از قابلیت ردیابی معامله را هم برای بازیابی و هم برای قوام آماده به کار ساده کند.

در حال حاضر ، PostgreSQL به محض اختصاص ، شناسه تراکنش را به مشتری ارسال نمی کند ، بنابراین برنامه در حال حاضر باید از آن استفاده کندtxid_current ()برای درخواست آناین می تواند یک سفر دور را اضافه کند ، اما با بسته بندی می توانید از شر آن خلاص شویدtxid_current ()باشماشروعپرس و جو - ارسالشروع؛txid_current () ؛برای خواندن/نوشتن معاملات. شما باید از تماس خودداری کنیدtxid_current ()برای معاملات فقط خواندنی ، از آنجا که نرخ استفاده از شناسه های معامله را افزایش می دهید و به بار کاری اضافه می کنیدخلاء.

به همین ترتیب ، PostgreSQL باید LSN یک تعهد را به همراه پاسخ تأیید تعهد ارسال کند. این امر به سیستم های جمع آوری و غیره اجازه می دهد تا نمایش داده شدگان را به طور هوشمندانه فقط به حالت ایستاده درآورد ، یا منتظر بمانید تا آنها را تا یک نقطه خاص دوباره پخش کنند.