دانشنامهسایرسیستم عاملفناوری اطلاعات

راه اندازی بکاپ Incremental در نرم افزار Percona XtraBackup

Percona XtraBackup یک نرم‌افزار متن‌باز و رایگان برای پشتیبان‌گیری از پایگاه‌داده‌هایی مانند MySQL و MariaDB است. این نرم‌افزار توسط Percona توسعه داده شده و قابلیت‌های پیشرفته‌ای برای پشتیبان‌گیری و بازیابی داده‌ها را فراهم می‌کند.

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

مزایای استفاده از Percona XtraBackup عبارتند از:

  1. سرعت بالا: از آنجا که XtraBackup تنها تغییرات انجام شده را پشتیبان می‌گیرد، فرایند پشتیبان‌گیری سریع‌تر و کم هزینه‌تر است.
  2. عدم تأثیر بر عملکرد سیستم: در طول پشتیبان‌گیری، این نرم‌افزار هیچ تأثیری بر عملکرد دیتابیس اصلی ندارد.
  3. بازیابی سریع: XtraBackup قابلیت بازیابی سریع و مطمئن از پشتیبان‌ها را فراهم می‌کند.
  4. امنیت: با استفاده از XtraBackup، می‌توانید پشتیبان‌های رمزنگاری شده را ایجاد کنید و برای حفاظت از داده‌های حساس خود استفاده کنید.

تفاوت Full Backup با Incremental Backup

Full Backup (پشتیبانی کامل):

در Full Backup، تمام داده‌ها و فایل‌های مورد نیاز در یک سیستم یا یک دستگاه، به صورت کامل، به یک رسانه پشتیبان‌گیری (مانند دیسک یا نوار) انتقال می‌یابند. در این روش، تمام داده‌ها از ابتدا تا پایان پشتیبان‌گیری بازیابی می‌شوند. این نوع پشتیبان‌گیری طولانی مدت و مصرف بیشتری از منابع ذخیره‌سازی می‌کند.

Incremental Backup (پشتیبانی تدریجی):

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

تفاوت اصلی بین Full Backup و Incremental Backup در حجم داده‌ها و زمان بازیابی است. Full Backup حجم بیشتری از منابع ذخیره‌سازی را به خود اختصاص می‌دهد و زمان بازیابی نیز طولانی‌تر است، در حالی که Incremental Backup حجم کمتری از منابع ذخیره‌سازی را مصرف می‌کند و بازیابی سریع‌تری دارد. در صورتی که تعداد Incremental Backupها زیاد شود، بازیابی ممکن است پیچیده شود. بنابراین، انتخاب بین این دو روش باید براساس نیازها و محدودیت‌های هر سیستم یا سازمان خاص تعیین شود.

شما می‌توانید در این راهکار، بین هر نسخه پشتیبان کامل، چندین نسخه پشتیبان از نوع Incremental تهیه کنید. به عنوان مثال، می‌توانید یک بار در هفته یک نسخه پشتیبان کامل و هر روز یک نسخه پشتیبان Incremental بگیرید یا هر روز (در ابتدای روز) یک نسخه پشتیبان کامل و هر ساعت یک نسخه پشتیبان Incremental بگیرید.

 


مهم:

نکته‌ی مهمی که باید به آن توجه نمایید این است که مفهوم بکاپ نوع incremental در Xtrabackup کاملاً متفاوت با سایر نرم‌افزارهای بکاپ است و این شرکت از مفهوم مرسوم برای این استراتژی، پیروی نمی‌کند. درست است که این نرم افزار از نام incremental برای این نوع بکاپ استفاده می‌کند، اما در واقع در استراتژی بکاپ‌گیری خود از روش differential استفاده می‌کند. به این معنی که در هر بار بکاپ نوع incremental، تمام تغییراتی که نسبت به فول بکاپ هست، گرفته می‌شود و نه فقط تغییراتی که نسبت به بکاپ قبلی بوده است.

پس با این توضیح باید متوجه شده باشید که در زمان ریکاوری کردن نیز تنها به بکاپ کامل و آخرین بکاپ incremental نیاز دارید.


 

نحوه عملکرد و بکاپ گیری در دیتابیس با استفاده از روش Incremental چگونه است؟

پشتیبان گیری Incremental از مفهومی به نام LSN یا log sequence number استفاده می‌کند. اما LSN چیست و چگونه کار می‌کند؟

LSN در MySQL یک عنصر کلیدی برای مدیریت و بازیابی داده‌ها است و در پروسه‌های مختلف پایگاه‌داده بسیار مفید است. هر صفحه InnoDB در دیتابیس Mysql دارای یک شماره LSN است. در واقع این سیستم مسئولیت تعیین شماره نسخه (Version number) را برعهده دارد که برای هر صفحه، یک شماره منحصربه‌فرد است. منظور از لاگ (Log) در سیستم LSN، یک پرونده‌ی باینری است که تمام تغییرات اعمال شده بر روی داده‌های جدول‌ها در MySQL را ثبت می‌کند.

هر رکورد در لاگ با یک شماره LSN مشخص می‌شود. شماره LSN به صورت ترتیبی به رکوردها اختصاص داده می‌شود، به طوری که رکوردهای جدیدتر شماره LSN بزرگتری دارند. این شماره‌ها به MySQL کمک می‌کنند تا ترتیب اعمال تغییرات را در لاگ تعیین کند و بازیابی و بازسازی داده‌ها را به ترتیب درست انجام دهد. LSN می‌تواند در موارد مختلف مفید باشد، از جمله:

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

۲. تطابق داده‌ها: با استفاده از LSN، می‌توانید داده‌ها را در سرورهای متفاوت با یکدیگر مقایسه کنید. با مقایسه LSN بین دو سرور، می‌توانید بفهمید که آیا داده‌ها هماهنگ هستند یا خیر و آیا همه تغییرات در هر دو سرور به درستی انجام شده است یا خیر.

۳. مدیریت تراکنش‌ها: LSN به صورت فراگیر در رابطه با تراکنش‌ها نیز استفاده می‌شود. با استفاده از LSN، می‌توانید ترتیب اعمال تغییرات در تراکنش‌ها را تعیین کنید و به راحتی بتوانید تراکنش‌ها را پیگیری و مدیریت کنید.

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

نرم‌افزار XtraBackup اینگونه عمل می‌کند که با فعال کردن ویژگی ردیابی صفحات تغییر یافته در Mysql، این صفحات را در یک فایل bitmap ذخیره می‌کند. در واقع شماره LSN این صفحات تغییریافته را در این فایل می‌نویسد. زمانی که فرآیند بکاپ Incremental آغاز می‌شود، فقط لازم است که این فایل خوانده شده و از مسیرهای گفته شده بکاپ‌گیری شود.


مهم:

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

پشتیبان‌گیری‌های Incremental، صفحات را می‌خوانند و LSN خود را با LSN آخرین نسخه پشتیبان مقایسه می‌کنند. برای بازیابی تغییرات Incremental باید یک نسخه پشتیبان کامل (Full backup) داشته باشید. بدون پشتیبان گیری کامل برای عمل به عنوان base، پشتیبان گیری Incremental بی فایده است.


فرآیند پیکربندی XtraBackup برای بکاپ Incremental

برای تهیه نسخه پشتیبان Incremental، همان‌طور که گفته شد، ابتدا با یک نسخه پشتیبان کامل یا همان Full Backup شروع کنید. باینری xtrabackup فایلی به نام xtrabackup_checkpoints را در فهرست هدف پشتیبان می‌نویسد. این فایل حاوی خطی است که to_lsn را نشان می‌دهد که LSN پایگاه داده در انتهای پشتیبان گیری است. بک آپ کامل را با دستور زیر ایجاد کنید:

#xtrabackup –backup –target-dir=/data/backups/base

بعد از موفقیت آمیز بودن فرآیند بکاپ‌گیری، اگر به فایل xtrabackup_checkpoints نگاه کنید، بسته به شماره LSN خود، باید محتوایی مشابه زیر را مشاهده کنید:

backup_type = full-backuped
from_lsn = 0
to_lsn = 1626007
last_lsn = 1626007
compact = 0
recover_binlog_info = 1

اکنون که یک نسخه پشتیبان کامل دارید، می‌توانید بر اساس آن یک بک آپ Incremental تهیه کنید. از دستور زیر استفاده کنید:

#xtrabackup –backup –target-dir=/data/backups/inc1 –incremental-basedir=/data/backups/base

فهرست /data/backups/inc1/ اکنون باید حاوی فایل‌های دلتا باشد، مانند ibdata1.delta و test/table1.ibd.delta. اینها نشان دهنده تغییرات از LSN 1626007 هستند. اگر فایل xtrabackup_checkpoints را در این دایرکتوری بررسی کنید، باید محتوای مشابه زیر را ببینید:

backup_type = incremental
from_lsn = 1626007
to_lsn = 4124244
last_lsn = 4124244
compact = 0
recover_binlog_info = 1

همان‌طور که مشاهده می‌نمایید، from_lsn نقطه شروع بکاپ بوده و to_lsn نقطه پایان این بکاپ Incremental و در واقع نقطه شروع بکاپ Incremental بعدی است. اکنون می‌توان از این دایرکتوری به عنوان پایه پشتیبان گیری Incremental دیگر استفاده کرد:

#xtrabackup –backup –target-dir=/data/backups/inc2 –incremental-basedir=/data/backups/inc1

این پوشه نیز همچنین حاوی xtrabackup_checkpoints است:

backup_type = incremental
from_lsn = 4124244
to_lsn = 6938371
last_lsn = 7110572
compact = 0
recover_binlog_info = 1

همان‌طور که در فایل بالا مشاهده می‌کنید، برخلاف دفعه قبل، عدد to_lsn و last_lsn با یکدیگر متفاوت هستند. چرا؟ این به این معنی است که در طول فرآیند پشتیبان گیری، مقداری ترافیک روی سرور وجود داشته است.

 

فرآیند Prepare کردن بکاپ Incremental برای ریکاوری

قبل از اینکه این فرآیند را توضیح دهیم، باید بگوییم که prepare– دقیقاً چه کاری انجام می‌دهد.

با اجرای ‘xtrabackup –prepare’ با گزینه ‘target-dir–‘ که به دایرکتوری پشتیبان اشاره دارد، Xtrabackup اقدامات لازم را برای آماده سازی فایل‌های پشتیبان برای بازیابی انجام می‌دهد.

در Xtrabackup، گزینه «prepare–» برای آماده‌سازی یک دایرکتوری پشتیبان برای بازیابی یا همان ریکاوری، استفاده می‌شود. مرحله “آماده سازی” یا Prepare بخشی ضروری از فرآیند پشتیبان گیری و بازیابی است و وظایف زیر را انجام می‌دهد:

۱. تغییرات لازم را در فایل‌های پشتیبان اعمال می‌کند: در طول فرآیند پشتیبان‌گیری، Xtrabackup یک consistent snapshot از فهرست داده‌های MySQL یا Percona Server ایجاد می‌کند. با این حال، این snapshot در حالت “ناقص” است و قبل از استفاده برای بازیابی باید آماده شود. گزینه «prepare–» تغییرات لازم را در فایل‌های پشتیبان اعمال می‌کند تا آن‌ها را کاملاً سازگار و آماده بازیابی کند.

۲. بازگرداندن تراکنش‌های تاییدنشده: اگر در زمان تهیه نسخه پشتیبان، تراکنش‌های در حال انجامی وجود داشته باشد، مرحله «prepare–» آن تراکنش‌های تاییدنشده را به عقب برمی‌گرداند تا ثبات داده‌ها حفظ شود.

۳. فراداده‌های لازم را ایجاد می‌کند و فایل‌های گزارش را آماده می‌کند: Xtrabackup همچنین فایل‌های ابرداده‌ای را که برای بازیابی مورد نیاز هستند، مانند فایل‌های گزارش تراکنش InnoDB (ib_logfile*) و سایر فایل‌های مرتبط را ایجاد و آماده می‌کند.

پس از تکمیل فرآیند آماده سازی، دایرکتوری پشتیبان در حالتی قرار می‌گیرد که می‌توان از آن برای بازیابی پایگاه داده استفاده کرد. فایل‌های آماده‌شده را می‌توان به فهرست داده‌های MySQL یا Percona Server کپی کرد تا پایگاه داده تا نقطه‌ای از زمان تهیه نسخه پشتیبان بازیابی شود.

مرحله xtrabackup –prepare برای پشتیبان گیری Incremental مانند پشتیبان گیری Full backup نیست. در پشتیبان‌گیری کامل، دو نوع عملیات برای سازگار کردن پایگاه داده انجام می‌شود: تراکنش‌های تایید شده از log file در برابر data files بازپخش می‌شوند و تراکنش‌های تایید نشده به عقب بازگردانده می‌شوند (rollback).

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

هنگام تهیه یک نسخه پشتیبان Incremental، باید از بازگشت تراکنش‌های تایید نشده، صرف نظر کنید، زیرا تراکنش‌هایی که در زمان پشتیبان گیری شما انجام نشده بودند ممکن است در حال انجام باشند و این احتمال وجود دارد که در پشتیبان گیری Incremental بعدی commit شده باشند. برای جلوگیری از مرحله rollback باید از گزینه xtrabackup –apply-log-only استفاده کنید.

 


منظور از تراکنش‌های تایید شده و تراکنش‌های تایید نشده چیست؟

در مدل ACID (Atomicity, Consistency, Isolation, Durability) که در پایگاه‌داده‌ها استفاده می‌شود، دو وضعیت اصلی برای تراکنش‌ها وجود دارد: تراکنش‌های تایید شده (committed transactions) و تراکنش‌های تایید نشده (uncommitted transactions).

۱. تراکنش‌های تایید شده (committed transactions): وقتی یک تراکنش در پایگاه‌داده به پایان می‌رسد، و تمام تغییرات آن با موفقیت اعمال شده و در دیسک ثبت می‌شوند، به عنوان یک تراکنش تایید شده در نظر گرفته می‌شود. در این حالت، تراکنش به صورت دائمی و قطعی در پایگاه‌داده ثبت می‌شود و تغییرات اعمال شده قابل دسترسی و قابل بازیابی هستند. تراکنش‌های تایید شده باید برای حفظ داده‌ها و اطمینان از ترمیم‌پذیری (durability)، به طور کامل در دیسک ذخیره شوند.

۲. تراکنش‌های تایید نشده (uncommitted transactions): در صورتی که یک تراکنش در حال اجرا باشد و تغییرات آن هنوز توسط COMMIT تایید نشده باشند، به عنوان یک تراکنش تایید نشده در نظر گرفته می‌شود. در این حالت، تغییرات اعمال شده توسط تراکنش هنوز در پایگاه‌داده قطعی نشده‌اند و ممکن است تغییرات در صورت خطا یا بازنشانی تراکنش، لغو شوند. تراکنش‌های تایید نشده معمولاً به عنوان تراکنش‌های نیمه قطعی یا تراکنش‌های معلق نیز شناخته می‌شوند.

تفاوت اصلی بین این دو وضعیت در این است که تراکنش‌های تایید شده به صورت قطعی و دائمی در دیسک ثبت می‌شوند و قابل بازیابی هستند، در حالی که تراکنش‌های تایید نشده هنوز توسط COMMIT تایید نشده‌اند و ممکن است تغییرات آن‌ها در صورت نیاز لغو شوند.


تا اینجا کار همان‌طور که دیدید، ما سه بکاپ زیر را داریم:

/data/backups/base
/data/backups/inc1
/data/backups/inc2

مرحله prepare را با شروع نسخه پشتیبان full که ایجاد کردید، آغاز می‌کنید و سپس تفاوت‌های Incremental را روی آن اعمال کنید.

#xtrabackup –prepare –apply-log-only –target-dir=/data/backups/base

خروجی دستور بالا، باید با متنی مشابه متن زیر پایان یابد:

InnoDB: Shutdown completed; log sequence number 1626007
۱۶۱۰۱۱ ۱۲:۴۱:۰۴ completed OK!

برای اعمال اولین نسخه پشتیبان Incremental به نسخه پشتیبان full، دستور زیر را اجرا کنید:

#xtrabackup –prepare –apply-log-only –target-dir=/data/backups/base –incremental-dir=/data/backups/inc1

این دستور فایل‌های دلتا را روی فایل‌های موجود در /data/backups/base اعمال می‌کند. شما باید خروجی مشابهی ببینید:

incremental backup from 1626007 is enabled.
xtrabackup: cd to /data/backups/base
xtrabackup: This target seems to be already prepared with –apply-log-only.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(4124244)

xtrabackup: page size for /tmp/backups/inc1/ibdata1.delta is 16384 bytes
Applying /tmp/backups/inc1/ibdata1.delta to ./ibdata1…

۱۶۱۰۱۱ ۱۲:۴۵:۵۶ completed OK!

در هر مرحله شماره LSN را با آنچه در بازرسی قبلی خود از اولین نسخه پشتیبان Incremental دیدید، مطابقت دهید. اکنون اگر فایل‌ها را از /data/backups/base بازیابی یا ریکاور کنید، باید وضعیت پایگاه داده را مطابق آنچه در اولین پشتیبان گیری Incremental انجام دادید، ببینید.

آماده‌سازی دومین پشتیبان Incremental، فرآیند مشابهی دارد با فرآیند قبلی:

#xtrabackup –prepare –target-dir=/data/backups/base –incremental-dir=/data/backups/inc2

xtrabackup –apply-log-only باید هنگام ادغام همه Incrementalها به جز آخرین مورد استفاده شود. به همین دلیل است که خط قبلی حاوی گزینه xtrabackup –apply-log-only نیست. حتی اگر xtrabackup –apply-log-only در آخرین مرحله استفاده شود، پشتیبان‌گیری همچنان انجام خواهد شد، اما در آن صورت سرور مرحله rollback را انجام می‌دهد.

در پایان این مراحل، شما تمام بکاپ‌ها را در بکاپ full اقدام کرده‌اید و اکنون می‌توانید آن را با استفاده از دستورات زیر بازیابی نمایید:

#rsync -avrP /data/backup/ /var/lib/mysql/

البته به جای rsync می‌توانید از دستور زیر نیز استفاده نمایید:

#xtrabackup –copy-back –target-dir=/data/backups/

#chown -R mysql:mysql /var/lib/mysql

در پایان، سرویس دیتابیس را مجددا راه اندازی نموده و از آن لذت ببرید.

نمایش بیشتر

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا