بازیابی و ثبت وقایع (Logging)

مکانیزم‌های بازیابی و ثبت وقایع، اتمیسیته و دوام تراکنش‌ها را با ثبت تغییرات در یک لاگ تضمین می‌کنند تا پس از خرابی، کارهای انجام شده قابل تکرار (redo) و کارهای ناتمام قابل لغو (undo) باشند.

Definition

بازیابی پایگاه داده فرآیند بازگرداندن پایگاه داده به یک وضعیت سازگار پس از خرابی است، که اطمینان می‌دهد اثرات تراکنش‌های متعهد شده پایدار هستند و تراکنش‌های لغو شده یا در حال اجرا هیچ اثری از خود باقی نمی‌گذارند؛ ثبت وقایع (logging) تکنیکی برای ثبت اقدامات تراکنش در یک لاگ پایدار است تا این امر ممکن شود.

Scope

این موضوع به چگونگی بقای پایگاه داده پس از خرابی‌ها می‌پردازد: پروتکل ثبت وقایع پیش‌نویس (WAL)، اطلاعات لغو و تکرار، نقاط بازرسی (checkpoints) برای محدود کردن کار بازیابی، و الگوریتم استاندارد بازیابی (به ویژه ARIES) با مراحل تحلیل، تکرار و لغو آن. همچنین سیاست‌های مدیریت بافر (steal/no-steal, force/no-force) که الزامات ثبت وقایع را تعیین می‌کنند، مورد بررسی قرار می‌گیرد. این موضوع شامل پروتکل‌های کنترل همزمانی که در طول عملیات عادی و تعهد توزیع شده اجرا می‌شوند، نمی‌شود، زیرا اینها مباحث مرتبط دیگری هستند.

Core questions

• چرا رکورد لاگ باید قبل از داده‌ای که توصیف می‌کند به حافظه پایدار برسد (ثبت وقایع پیش‌نویس)؟
• چگونه لغو (undo) و تکرار (redo) پس از خرابی یک وضعیت سازگار را بازیابی می‌کنند؟
• چگونه سیاست‌های مدیریت بافر (steal/force) الزامات ثبت وقایع را تعیین می‌کنند؟
• نقش نقاط بازرسی (checkpoints) در محدود کردن زمان بازیابی چیست؟
• الگوریتم ARIES چگونه بازیابی را به تحلیل، تکرار و لغو ساختار می‌دهد؟

Key concepts

• ثبت وقایع پیش‌نویس (WAL)
• ثبت وقایع لغو و تکرار
• شماره توالی لاگ
• نقاط بازرسی (checkpoints)
• سیاست‌های steal/no-steal و force/no-force
• رکوردهای لاگ جبرانی
• مراحل تحلیل، تکرار، لغو
• ARIES

Key theories

ثبت وقایع پیش‌نویس

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

بازیابی لغو/تکرار و سیاست‌های بافر

اینکه سیستم به لغو، تکرار یا هر دو نیاز دارد، به سیاست‌های بافر بستگی دارد: یک سیاست steal (نوشتن صفحات نامتعهد به دیسک) به لغو نیاز دارد، و یک سیاست no-force (عدم اجبار صفحات متعهد شده در زمان تعهد) به تکرار نیاز دارد؛ ترکیب رایج steal/no-force به هر دو نیاز دارد.

ARIES

ARIES یک روش بازیابی پرکاربرد است که از ثبت وقایع پیش‌نویس، شماره‌های توالی لاگ، و یک الگوریتم سه مرحله‌ای (تحلیل، تکرار، لغو) با رکوردهای لاگ جبرانی برای پشتیبانی از قفل‌گذاری دقیق و بازگشت‌های جزئی استفاده می‌کند.

Clinical relevance

بازیابی و ثبت وقایع هستند که دوام را واقعی می‌کنند: آنها تضمین می‌کنند که به محض تأیید یک تراکنش توسط سیستم، مانند پرداخت یا سفارش، این واقعیت در برابر از دست دادن برق و خرابی‌ها پایدار می‌ماند، و اینکه خرابی در میانه تراکنش هرگز پایگاه داده را در وضعیت نیمه‌به‌روز شده و ناسازگار رها نمی‌کند.

History

بررسی Härder و Reuter در سال 1983 اصول بازیابی تراکنش‌محور و طبقه‌بندی سیاست بافر را ارائه کرد. ARIES، که توسط C. Mohan و همکارانش در IBM توسعه یافت و در سال 1992 منتشر شد، به الگوریتم استاندارد بازیابی تبدیل شد و ثبت وقایع پیش‌نویس را با شماره‌های توالی لاگ و رکوردهای جبرانی ترکیب کرد تا از قفل‌گذاری با دانه‌بندی دقیق پشتیبانی کند.

Key figures

• C. Mohan
• Jim Gray
• Theo Härder
• Andreas Reuter

Seminal works

• mohan1992
• haerder1983
• gray1992

Frequently asked questions

چرا ثبت وقایع پیش‌نویس ضروری است؟

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

نقاط بازرسی (checkpoints) چه کاری انجام می‌دهند؟

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