XTRABACKUP(1) Percona XtraBackup XTRABACKUP(1)

xtrabackup - مستندات ابزار Percona XtraBackup 8.0

فایل اجرایی xtrabackup یک برنامهٔ کامپایل‌شده به زبان C است که با کتابخانه‌های InnoDB و کتابخانه‌های استاندارد کلاینت MySQL پیوند (link) خورده است.

ابزار xtrabackup امکان پشتیبان‌گیری در نقطهٔ زمانی مشخص (point-in-time) را برای جدول‌های InnoDB / XtraDB همراه با تعاریف ساختار (schema)، جدول‌های MyISAM و سایر بخش‌های سرور فراهم می‌کند.

کتابخانه‌های InnoDB قابلیت اعمال لاگ (log) بر روی فایل‌های داده را فراهم می‌سازند. کتابخانه‌های کلاینت MySQL برای پردازش گزینه‌های خط فرمان و فایل پیکربندی استفاده می‌شوند.

این ابزار در یکی از دو حالت --backup یا --prepare اجرا می‌شود که متناظر با دو عملکرد اصلی آن است. برای انجام وظایف مختلف، چندین شیوهٔ متفاوت از این عملکردها وجود دارد و همچنین دو حالت کم‌کاربردتر با نام‌های --stats و --print-param نیز در دسترس هستند.

ابزار xtrabackup از پشتیبان‌گیری‌های افزایشی پشتیبانی می‌کند. در این روش تنها داده‌هایی کپی می‌شوند که پس از آخرین پشتیبان‌گیری کامل تغییر یافته‌اند. شما می‌توانید میان هر نسخهٔ پشتیبان کامل، چندین پشتیبان‌گیری افزایشی انجام دهید؛ بنابراین می‌توانید فرایندی مانند یک بار پشتیبان‌گیری کامل در هفته و پشتیبان‌گیری افزایشی روزانه، یا پشتیبان‌گیری کاملِ روزانه و پشتیبان‌گیری افزایشی ساعتی را تنظیم نمایید.

نکته:

پشتیبان‌گیری‌های افزایشی روی موتور ذخیره‌سازی MyRocks بررسی نمی‌کنند که آیا نسخهٔ کامل یا افزایشی پیشین حاوی فایل‌های یکسان است یا خیر. Percona XtraBackup در هر بار پشتیبان‌گیری، تمامی فایل‌های MyRocks را کپی می‌کند.

علت کارکرد پشتیبان‌گیری‌های افزایشی این است که هر صفحهٔ InnoDB (معمولاً با حجم ۱۶ کیلوبایت) شامل یک شمارهٔ توالی لاگ یا LSN است. مقدار LSN در واقع شمارهٔ نسخهٔ سیستمی کل پایگاه داده است. مقدار LSN هر صفحه مشخص می‌کند که تغییرات آن چقدر جدید است. یک پشتیبان‌گیری افزایشی، هر صفحه‌ای را که LSN آن جدیدتر از LSN آخرین پشتیبان‌گیری افزایشی یا کامل باشد کپی می‌کند. دو الگوریتم برای یافتن مجموعه‌ای از این صفحاتِ نیازمندِ کپی استفاده می‌شود. روش اول، که در تمامی نسخه‌ها و انواع سرورها در دسترس است، بررسی مستقیم LSN صفحات از طریق خواندن تمام صفحات داده است. روش دوم، که در Percona Server for MySQL در دسترس است، فعال‌سازی قابلیت changed page tracking روی سرور است که صفحات را در حین تغییر ثبت می‌کند. این اطلاعات سپس در یک فایل مجزا و فشرده موسوم به فایل bitmap ذخیره می‌شوند. باینری xtrabackup از این فایل استفاده خواهد کرد تا فقط صفحات داده‌ای را که برای پشتیبان افزایشی نیاز دارد بخواند، که این کار به‌طور بالقوه مانع از تعداد زیادی درخواست خواندن می‌شود. در صورتی که فایل باینری xtrabackup فایل bitmap را پیدا کند، الگوریتم دوم به طور پیش‌فرض فعال است. امکان تعیین گزینهٔ --incremental-force-scan نیز وجود دارد تا حتی در صورت وجود داده‌های bitmap، تمامی صفحات خوانده شوند.

پشتیبان‌گیری‌های افزایشی در واقع فایل‌های داده را با فایل‌های دادهٔ نسخهٔ پشتیبان قبلی مقایسه نمی‌کنند. در واقع، چنانچه LSN نسخهٔ قبلی را بدانید، می‌توانید با استفاده از --incremental-lsn بدون نیاز به داشتن نسخهٔ پشتیبان قبلی نیز عملیات پشتیبان‌گیری افزایشی را انجام دهید. پشتیبان‌گیری‌های افزایشی صرفاً صفحات را خوانده و LSN آن‌ها را با LSN آخرین نسخهٔ پشتیبان مقایسه می‌کنند. با این وجود، برای بازیابی تغییرات افزایشی همچنان به یک نسخهٔ پشتیبان کامل نیاز دارید؛ بدون وجود یک نسخهٔ کامل به عنوان پایه، نسخه‌های پشتیبان افزایشی بی‌فایده خواهند بود.

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

$ xtrabackup --backup --target-dir=/data/backups/base --datadir=/var/lib/mysql/

اگر به فایل xtrabackup_checkpoints نگاه کنید، باید محتوایی مشابه مورد زیر مشاهده کنید:

backup_type = full-backuped
from_lsn = 0
to_lsn = 1291135

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

$ xtrabackup --backup --target-dir=/data/backups/inc1 \
--incremental-basedir=/data/backups/base --datadir=/var/lib/mysql/

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

backup_type = incremental
from_lsn = 1291135
to_lsn = 1291340

معنای آن کاملاً روشن است. اکنون می‌توان از این دایرکتوری به عنوان پایه برای یک پشتیبان‌گیری افزایشی دیگر استفاده کرد:

$ xtrabackup --backup --target-dir=/data/backups/inc2 \
--incremental-basedir=/data/backups/inc1 --datadir=/var/lib/mysql/

مرحلهٔ --prepare برای پشتیبان‌های افزایشی همانند پشتیبان‌های عادی نیست. در پشتیبان‌های عادی، دو نوع عملیات برای سازگار ساختن پایگاه داده انجام می‌شود: تراکنش‌های تثبیت‌شده (committed) از فایل گزارش (log file) روی فایل‌های داده بازپخش می‌شوند، و تراکنش‌های تثبیت‌نشده (uncommitted) واگردانی (roll back) می‌شوند. شما باید هنگام آماده‌سازی یک پشتیبان، از واگردانی تراکنش‌های تثبیت‌نشده صرف‌نظر کنید؛ زیرا تراکنش‌هایی که در زمان پشتیبان‌گیری شما تثبیت نشده بودند ممکن است هنوز در جریان باشند، و این احتمال وجود دارد که در پشتیبان افزایشی بعدی تثبیت شوند. برای جلوگیری از مرحلهٔ واگردانی، باید از گزینهٔ --apply-log-only استفاده کنید.

نکته:

اگر برای جلوگیری از مرحلهٔ واگردانی از گزینهٔ --apply-log-only استفاده نکنید، پشتیبان‌های افزایشی شما بلااستفاده خواهند شد. پس از اینکه تراکنش‌ها واگردانی شوند، پشتیبان‌های افزایشی بعدی دیگر قابل اعمال نخواهند بود.

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

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

برای آماده‌سازی پشتیبان پایه، باید --prepare را مانند معمول اجرا کنید، اما از مرحلهٔ واگردانی جلوگیری نمایید:

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

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

101107 20:49:43  InnoDB: Shutdown completed; log sequence number 1291135

شمارهٔ ترتیبی گزارش (log sequence number) باید با مقدار to_lsn پشتیبان پایه که قبلاً دیدید مطابقت داشته باشد.

این پشتیبان در واقع اکنون به همین صورت برای بازیابی امن است، حتی با وجود اینکه از مرحلهٔ واگردانی صرف‌نظر شده است. اگر آن را بازیابی کرده و MySQL را راه‌اندازی کنید، InnoDB تشخیص می‌دهد که مرحلهٔ واگردانی انجام نشده است، و آن را در پس‌زمینه انجام خواهد داد؛ درست مانند روندی که معمولاً برای بازیابی پس از خرابی (crash recovery) در هنگام شروع به کار انجام می‌دهد. این سیستم به شما اعلان خواهد کرد که پایگاه داده به‌طور عادی متوقف (shut down) نشده بود.

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

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

این دستور فایل‌های دلتا را بر روی فایل‌های موجود در /data/backups/base اعمال می‌کند، که زمان آن‌ها را به جلو (roll forward) و به زمان تهیهٔ پشتیبان افزایشی می‌برد. سپس redo log را طبق روال معمول روی نتیجه اعمال می‌کند. داده‌های نهایی در /data/backups/base قرار می‌گیرند، نه در پوشهٔ افزایشی. باید خروجی‌ای مشابه زیر را مشاهده کنید:

incremental backup from 1291135 is enabled.
xtrabackup: cd to /data/backups/base/
xtrabackup: This target seems to be already prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1291340)
Applying /data/backups/inc1/ibdata1.delta ...
Applying /data/backups/inc1/test/table1.ibd.delta ...
.... snip
101107 20:56:30  InnoDB: Shutdown completed; log sequence number 1291340

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

آماده‌سازی دومین پشتیبان افزایشی روندی مشابه دارد: فایل‌های دلتا را روی پشتیبان پایهٔ (اصلاح‌شده) اعمال کنید تا داده‌های آن را در زمان به نقطهٔ تهیهٔ دومین پشتیبان افزایشی به جلو ببرید:

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

نکته:

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

اگر مایلید پس از اعمال دلتاهای مورد نظر به پشتیبان پایه، از دریافت اخطار مبنی بر خاموش نشدن عادی InnoDB جلوگیری کنید، می‌توانید --prepare را یک بار دیگر بدون غیرفعال کردن مرحلهٔ واگردانی اجرا نمایید..SS بازیابی پشتیبان‌های افزایشی

پس از آماده‌سازی پشتیبان‌های افزایشی، دایرکتوری پایه شامل همان داده‌های پشتیبان کامل خواهد بود. برای بازگردانی این پشتیبان، می‌توانید از این دستور استفاده کنید: xtrabackup --copy-back --target-dir=BASE-DIR

ممکن است لازم باشد مالکیت را مطابق با جزئیات ارائه‌شده در restoring_a_backup تغییر دهید.

پشتیبان‌گیری‌های جریانی افزایشی را می‌توان با گزینهٔ جریان‌سازی xbstream انجام داد. در حال حاضر پشتیبان‌ها در قالب سفارشی xbstream بسته‌بندی می‌شوند. با این قابلیت، باید یک پشتیبان BASE (پایه) نیز تهیه کنید. تهیهٔ یک پشتیبان پایه.INDENT 0.0

$ xtrabackup --backup --target-dir=/data/backups

تهیهٔ یک پشتیبان محلی.INDENT 0.0 
$ xtrabackup --backup --incremental-lsn=LSN-number --stream=xbstream --target-dir=./ > incremental.xbstream

استخراج پشتیبان.INDENT 0.0 
$ xbstream -x < incremental.xbstream

تهیهٔ پشتیبان محلی، ارسال جریانی آن به سرور دوردست و استخراج آن.INDENT 0.0 
$ xtrabackup --backup --incremental-lsn=LSN-number --stream=xbstream --target-dir=./
$ ssh user@hostname " cat - | xbstream -x -C > /backup-dir/"

ابزار xtrabackup از تهیهٔ پشتیبان‌های جزئی در زمان فعال بودن گزینهٔ innodb_file_per_table پشتیبانی می‌کند. سه روش برای ایجاد پشتیبان‌های جزئی وجود دارد:

1.
تطبیق نام جدول‌ها با یک عبارت باقاعده (regular expression)
2.
ارائهٔ فهرستی از نام‌های جدول در یک فایل
3.
ارائهٔ فهرستی از پایگاه‌های داده

هشدار:

پشتیبان آماده‌شده را با copy back بازگردانی نکنید.

بازیابی پشتیبان‌های جزئی باید از طریق وارد کردن (import) جدول‌ها انجام شود، نه با استفاده از گزینهٔ --copy-back. اجرای پشتیبان‌گیری افزایشی پس از اجرای یک پشتیبان‌گیری جزئی توصیه نمی‌شود.

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

برای اهداف این صفحهٔ راهنما، فرض می‌کنیم پایگاه داده‌ای به نام test وجود دارد که شامل جدول‌هایی به نام‌های t1 و t2 است.

هشدار:

اگر هر یک از جدول‌های مطابقت‌یافته یا فهرست‌شده در حین پشتیبان‌گیری حذف شوند، xtrabackup با خطا مواجه خواهد شد.

چندین روش برای تعیین این‌که کدام بخش از کل داده‌ها پشتیبان‌گیری شود وجود دارد:

  • استفاده از گزینهٔ --tables برای فهرست کردن نام‌های جدول
  • استفاده از گزینهٔ --tables-file برای فهرست کردن جدول‌ها در یک فایل
  • استفاده از گزینهٔ --databases برای فهرست کردن پایگاه‌های داده
  • استفاده از گزینهٔ --databases-file برای فهرست کردن پایگاه‌های داده

روش اول شامل استفاده از گزینهٔ --tables در xtrabackup است. مقدار این گزینه یک عبارت باقاعده است که با نام کامل پایگاه داده و نام جدول با استفاده از قالب databasename.tablename مطابقت داده می‌شود.

برای پشتیبان‌گیری تنها از جدول‌های موجود در پایگاه دادهٔ test، از دستور زیر استفاده کنید:

$ xtrabackup --backup --datadir=/var/lib/mysql --target-dir=/data/backups/ \
--tables="^test[.].*"

برای پشتیبان‌گیری تنها از جدول test.t1، از دستور زیر استفاده کنید:

$ xtrabackup --backup --datadir=/var/lib/mysql --target-dir=/data/backups/ \
--tables="^test[.]t1"

گزینهٔ --tables-file فایلی را مشخص می‌کند که می‌تواند شامل نام چندین جدول باشد، یک نام جدول در هر خط از فایل. تنها از جدول‌هایی که نام آن‌ها در فایل آمده است پشتیبان‌گیری خواهد شد. نام‌ها دقیقاً و با حساسیت به حروف بزرگ و کوچک (case-sensitive)، بدون هیچ‌گونه تطبیق الگو یا عبارت باقاعده (regular expression) مطابقت داده می‌شوند. نام‌های جدول باید به‌صورت کامل (fully-qualified) و در قالب databasename.tablename باشند.

$ echo "mydatabase.mytable" > /tmp/tables.txt
$ xtrabackup --backup --tables-file=/tmp/tables.txt

گزینهٔ ` --databases` فهرستی جداشده با فاصله از پایگاه‌های داده و جدول‌ها را برای پشتیبان‌گیری در قالب databasename[.tablename] می‌پذیرد. علاوه بر این فهرست، اطمینان حاصل کنید که پایگاه‌های دادهٔ mysql، sys، و

performance_schema را مشخص کرده باشید. این پایگاه‌های داده هنگام بازیابی پایگاه‌های داده با استفاده از xtrabackup --copy-back مورد نیاز هستند.

نکته:

جدول‌هایی که در طول مرحلهٔ --prepare پردازش می‌شوند، حتی اگر صراحتاً توسط پارامتر فهرست نشده باشند، در صورتی که پس از شروع پشتیبان‌گیری ایجاد شده باشند، ممکن است به نسخهٔ پشتیبان افزوده شوند.
$ xtrabackup --databases='mysql sys performance_schema test ...'

گزینهٔ --databases-file فایلی را مشخص می‌کند که می‌تواند شامل چندین پایگاه داده و جدول در قالب databasename[.tablename] باشد، یک نام عنصر در هر خط از فایل. نام‌ها به‌صورت دقیق و با حساسیت به حروف بزرگ و کوچک (case-sensitive)، بدون هیچ‌گونه تطبیق الگو یا عبارت باقاعده مطابقت داده می‌شوند.

نکته:

جدول‌هایی که در طول مرحلهٔ --prepare پردازش می‌شوند، حتی اگر صراحتاً توسط پارامتر فهرست نشده باشند، در صورتی که پس از شروع پشتیبان‌گیری ایجاد شده باشند، ممکن است به نسخهٔ پشتیبان افزوده شوند.

این رویه مشابه بازیابی جدول‌های مجزا است: لاگ‌ها را اعمال کرده و از گزینهٔ --export استفاده کنید:

$ xtrabackup --prepare --export --target-dir=/path/to/partial/backup

هنگامی که از گزینهٔ --prepare روی یک پشتیبان جزئی استفاده می‌کنید، هشدارهایی مبنی بر عدم وجود جدول‌ها مشاهده خواهید کرد. این به این دلیل است که این جدول‌ها در data dictionary درون InnoDB وجود دارند، اما فایل‌های .ibd متناظر با آن‌ها موجود نیستند؛ زیرا در دایرکتوری پشتیبان کپی نشده بودند. این جدول‌ها از data dictionary حذف خواهند شد و هنگامی که نسخهٔ پشتیبان را بازیابی و InnoDB را راه‌اندازی کنید، دیگر وجود نخواهند داشت و باعث چاپ هیچ‌گونه خطا یا هشداری در فایل لاگ نخواهند شد.

Could not find any file associated with the tablespace ID: 5

Use --innodb-directories to find the tablespace files. If that fails then use --innodb-force-recovery=1 to ignore this and to permanently lose all changes to the missing tablespace(s).

بازیابی باید با بازگردانی جدول‌های مجزا در پشتیبان جزئی به کارساز انجام شود.

همچنین می‌توان این کار را با رونوشت (copy back) نسخهٔ پشتیبان آماده‌شده به یک datadir «پاک» (در این حالت، اطمینان حاصل کنید که پایگاه دادهٔ mysql گنجانده شده باشد) که پشتیبان را به آن منتقل می‌کنید، انجام داد. یک پایگاه دادهٔ سیستمی را می‌توان با دستور زیر ایجاد کرد:

$ sudo mysql --initialize --user=mysql

پس از راه‌اندازی کارساز، ممکن است هشدارهایی از mysql دربارهٔ tablespaceهای مفقود مشاهده کنید:

2021-07-19T12:42:11.077200Z 1 [Warning] [MY-012351] [InnoDB] Tablespace 4, name 'test1/t1', file './d2/test1.ibd' is missing!
2021-07-19T12:42:11.077300Z 1 [Warning] [MY-012351] [InnoDB] Tablespace 4, name 'test1/t1', file './d2/test1.ibd' is missing!

به منظور پاک‌سازی پایگاه دادهٔ یتیم از data dictionary، باید دایرکتوری پایگاه دادهٔ مفقود را به‌صورت دستی ایجاد کرده و سپس این پایگاه داده را با دستور DROP از کارساز حذف کنید.

نمونه‌ای از ایجاد پایگاه دادهٔ مفقود:

$ mkdir /var/lib/mysql/test1/d2

نمونه‌ای از حذف پایگاه داده از کارساز:

mysql> DROP DATABASE d2;
Query OK, 2 rows affected (0.5 sec)

باینری xtrabackup می‌تواند فایل‌های دادهٔ InnoDB را در حالت فقط-خواندنی (read-only) تحلیل کند تا آمارهایی را دربارهٔ آن‌ها ارائه دهد. برای این کار، باید از گزینهٔ --stats استفاده کنید. می‌توانید این گزینه را با گزینهٔ --tables ترکیب کنید تا فایل‌های مورد بررسی را محدود نمایید. این ابزار همچنین از گزینهٔ --use-memory استفاده می‌کند.

می‌توانید تحلیل را روی یک کارساز (سرور) در حال اجرا انجام دهید، البته با مقداری احتمال بروز خطا به دلیل تغییر داده‌ها در حین تحلیل. یا می‌توانید یک نسخهٔ پشتیبان از پایگاه داده را تحلیل کنید. در هر صورت، برای استفاده از قابلیت آمارها، به یک نسخهٔ پاک از پایگاه داده شامل فایل‌های گزارش وقایع (log) با اندازهٔ درست نیاز دارید؛ بنابراین برای استفاده از این قابلیت روی یک نسخهٔ پشتیبان، باید آن را دو بار با --prepare اجرا کنید.

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

<INDEX STATISTICS>
  table: test/table1, index: PRIMARY, space id: 12, root page 3
  estimated statistics in dictionary:
    key vals: 25265338, leaf pages 497839, size pages 498304
  real statistics:
     level 2 pages: pages=1, data=5395 bytes, data/pages=32%
     level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
        leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%

این خروجی را می‌توان به شرح زیر تفسیر کرد:

  • سطر نخست به‌سادگی نام جدول، شاخص (index) و شناسه‌های داخلی آن را نشان می‌دهد. اگر شاخصی با نام GEN_CLUST_INDEX مشاهده کردید، آن شاخص خوشه‌ای (clustered index) جدول است که به صورت خودکار ایجاد شده، زیرا شما صراحتاً یک PRIMARY KEY ایجاد نکرده‌اید.
  • آمارهای تخمینی در اطلاعات فرهنگ داده‌ها (dictionary)، مشابه داده‌هایی است که از طریق ANALYZE TABLE در داخل InnoDB جمع‌آوری می‌شود تا به عنوان آمارهای تخمینی چندگانگی (cardinality) ذخیره شده و به بهینه‌ساز پرس‌وجو (query optimizer) تحویل داده شوند.
  • اطلاعات آمارهای واقعی حاصل پویش صفحه‌های داده و محاسبهٔ اطلاعات دقیق دربارهٔ شاخص است.
  • خروجی The level <X> pages: به این معنی است که آن سطر، اطلاعات مربوط به صفحات موجود در آن سطح از درخت شاخص را نمایش می‌دهد. هرچه <X> بزرگ‌تر باشد، فاصلهٔ آن از صفحات برگ (leaf pages) که در سطح ۰ هستند بیشتر است. سطر نخست، صفحهٔ ریشه (root page) است.
  • خروجی leaf pages مسلماً صفحات برگ را نشان می‌دهد. داده‌های جدول در این مکان ذخیره می‌شوند.
  • خروجی external pages: (نشان داده‌نشده) صفحات خارجی بزرگی را نشان می‌دهد که مقادیری را نگه می‌دارند که برای جا شدن در خود سطر بیش از حد طولانی هستند؛ مانند مقادیر طولانی BLOB و TEXT.
  • مقدار recs تعداد واقعی رکوردها (سطرها) در صفحات برگ است.
  • مقدار pages تعداد کل صفحات است.
  • مقدار data اندازهٔ کل داده‌ها در صفحات، به بایت است.
  • مقدار data/pages به صورت (data / (pages * PAGE_SIZE)) * 100% محاسبه می‌شود. این مقدار به دلیل فضای رزرو شده برای سرصفحه‌ها و پانویس‌های صفحه (page headers و footers)، هرگز به ۱۰۰٪ نخواهد رسید.

یک نمونه با جزئیات بیشتر در یک مطلب وبلاگ MySQL Performance منتشر شده است.

می‌توان از اسکریپت زیر برای خلاصه‌سازی و جدول‌بندی خروجی اطلاعات آماری استفاده کرد:

tabulate-xtrabackup-stats.pl
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';
my $script_version = "0.1";
my $PG_SIZE = 16_384; # InnoDB defaults to 16k pages, change if needed.
my ($cur_idx, $cur_tbl);
my (%idx_stats, %tbl_stats);
my ($max_tbl_len, $max_idx_len) = (0, 0);
while ( my $line = <> ) {
   if ( my ($t, $i) = $line =~ m/table: (.*), index: (.*), space id:/ ) {
      $t =~ s!/!.!;
      $cur_tbl = $t;
      $cur_idx = $i;
      if ( length($i) > $max_idx_len ) {
         $max_idx_len = length($i);
      }
      if ( length($t) > $max_tbl_len ) {
         $max_tbl_len = length($t);
      }
   }
   elsif ( my ($kv, $lp, $sp) = $line =~ m/key vals: (\d+), \D*(\d+), \D*(\d+)/ ) {
      @{$idx_stats{$cur_tbl}->{$cur_idx}}{qw(est_kv est_lp est_sp)} = ($kv, $lp, $sp);
      $tbl_stats{$cur_tbl}->{est_kv} += $kv;
      $tbl_stats{$cur_tbl}->{est_lp} += $lp;
      $tbl_stats{$cur_tbl}->{est_sp} += $sp;
   }
   elsif ( my ($l, $pages, $bytes) = $line =~ m/(?:level (\d+)|leaf) pages:.*pages=(\d+), data=(\d+) bytes/ ) {
      $l ||= 0;
      $idx_stats{$cur_tbl}->{$cur_idx}->{real_pages} += $pages;
      $idx_stats{$cur_tbl}->{$cur_idx}->{real_bytes} += $bytes;
      $tbl_stats{$cur_tbl}->{real_pages} += $pages;
      $tbl_stats{$cur_tbl}->{real_bytes} += $bytes;
   }
}
my $hdr_fmt = "%${max_tbl_len}s %${max_idx_len}s %9s %10s %10s\n";
my @headers = qw(TABLE INDEX TOT_PAGES FREE_PAGES PCT_FULL);
printf $hdr_fmt, @headers;
my $row_fmt = "%${max_tbl_len}s %${max_idx_len}s %9d %10d %9.1f%%\n";
foreach my $t ( sort keys %tbl_stats ) {
   my $tbl = $tbl_stats{$t};
   printf $row_fmt, $t, "", $tbl->{est_sp}, $tbl->{est_sp} - $tbl->{real_pages},
      $tbl->{real_bytes} / ($tbl->{real_pages} * $PG_SIZE) * 100;
   foreach my $i ( sort keys %{$idx_stats{$t}} ) {
      my $idx = $idx_stats{$t}->{$i};
      printf $row_fmt, $t, $i, $idx->{est_sp}, $idx->{est_sp} - $idx->{real_pages},
         $idx->{real_bytes} / ($idx->{real_pages} * $PG_SIZE) * 100;
   }
}
نمونهٔ خروجی اسکریپت

خروجی اسکریپت Perl بالا، هنگامی که بر روی نمونهٔ نشان‌داده‌شده در مطلب وبلاگ پیش‌تر ذکر شده اجرا شود، به صورت زیر خواهد بود:

          TABLE           INDEX TOT_PAGES FREE_PAGES   PCT_FULL
art.link_out104                    832383      38561      86.8%
art.link_out104         PRIMARY    498304         49      91.9%
art.link_out104       domain_id     49600       6230      76.9%
art.link_out104     domain_id_2     26495       3339      89.1%
art.link_out104 from_message_id     28160        142      96.3%
art.link_out104    from_site_id     38848       4874      79.4%
art.link_out104   revert_domain    153984      19276      71.4%
art.link_out104    site_message     36992       4651      83.4%

ستون‌ها عبارتند از جدول و شاخص، و به دنبال آن‌ها تعداد کل صفحات در آن شاخص، تعداد صفحاتی که در عمل توسط داده‌ها اشغال نشده‌اند، و تعداد بایت‌های داده‌های واقعی به صورت درصدی از کل اندازهٔ صفحات داده‌های واقعی. سطر نخست در خروجی بالا که ستون INDEX در آن خالی است، خلاصه‌ای از کل جدول می‌باشد..SS کار با لاگ‌های باینری (Binary Logs)

فایل اجرایی xtrabackup با log_status table یکپارچه می‌شود. این یکپارچگی به xtrabackup امکان می‌دهد موقعیت لاگ باینری متناظر با پشتیبان را چاپ کند، تا بتوانید از این موقعیت لاگ باینری برای راه‌اندازی یک نسخهٔ بدل (replica) جدید یا انجام بازیابی در نقطهٔ زمانی مشخص (point-in-time recovery) استفاده کنید.

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

خروجی در طول مرحلهٔ پشتیبان‌گیری مشابه موارد زیر است:

210715 14:14:59 Backup created in directory '/backup/'
MySQL binlog position: filename 'binlog.000002', position '156'
. . .
210715 14:15:00 completed OK!

نکته:

از نسخهٔ Percona XtraBackup 8.0.26-18.0 به بعد، xtrabackup دیگر فایل xtrabackup_binlog_pos_innodb را ایجاد نمی‌کند. این تغییر به این دلیل است که MySQL و Percona Server دیگر اطلاعات لاگ باینری را در بخش سیستم تراکنش سراسری ibdata به‌روزرسانی نمی‌کنند. شما باید بدون در نظر گرفتن موتور ذخیره‌سازیِ (storage engine) مورد استفاده، به xtrabackup_binlog_info اتکا کنید.

برای انجام یک بازیابی در نقطهٔ زمانی مشخص از یک پشتیبان xtrabackup، باید پشتیبان را آماده‌سازی (prepare) و بازیابی (restore) کنید، و سپس لاگ‌های باینری را از نقطهٔ نشان داده‌شده در فایل xtrabackup_binlog_info بازپخش (replay) نمایید.

دستورالعمل دقیق‌تر در اینجا یافت می‌شود.

برای راه‌اندازی یک replica جدید، باید پشتیبان را آماده‌سازی کرده و آن را در دایرکتوری داده‌های (data directory) نسخهٔ بدل رپلیکیشن جدید خود بازیابی کنید. اگر از نسخهٔ 8.0.22 یا قدیمی‌تر استفاده می‌کنید، در دستور CHANGE MASTER TO خود، از نام فایل لاگ باینری و موقعیت نشان‌داده‌شده در فایل xtrabackup_binlog_info برای آغاز رپلیکیشن استفاده کنید.

اگر از نسخهٔ 8.0.23 یا جدیدتر استفاده می‌کنید، از CHANGE_REPLICATION_SOURCE_TO و گزینه‌های مناسب آن استفاده کنید. دستور CHANGE_MASTER_TO منسوخ شده است.

دستورالعمل با جزئیات بیشتر در ../howtos/setting_up_replication یافت می‌شود.

نرم‌افزار Percona XtraBackup می‌تواند جدولی را که در فایل .ibd اختصاصی خودش قرار دارد صادر (export) کند. با Percona XtraBackup، می‌توانید جدول‌های جداگانه را از هر پایگاه‌دادهٔ InnoDB صادر کرده و آن‌ها را به Percona Server for MySQL دارای XtraDB یا MySQL 8.0 وارد (import) کنید. مبدأ لزوماً نیازی نیست XtraDB یا MySQL 8.0 باشد، اما مقصد باید چنین باشد. این روش فقط بر روی فایل‌های .ibd تکی کار می‌کند.

مثال زیر جدول زیر را صادر و وارد می‌کند:

CREATE TABLE export_test (
a int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

جدول در حالت innodb_file_per_table ایجاد شده است، بنابراین پس از گرفتن پشتیبان به شیوهٔ معمول با گزینهٔ --backup، فایل .ibd در دایرکتوری مقصد وجود دارد:

$ find /data/backups/mysql/ -name export_test.*
/data/backups/mysql/test/export_test.ibd

هنگامی که پشتیبان را آماده‌سازی (prepare) می‌کنید، گزینهٔ --export را به دستور اضافه نمایید. در اینجا یک مثال آورده شده است:

$ xtrabackup --prepare --export --target-dir=/data/backups/mysql/

نکته:

اگر یک جدول فضای جدول (tablespace) رمزنگاری‌شدهٔ InnoDB را بازیابی می‌کنید، فایل دسته‌کلید (keyring) را اضافه نمایید: 
$ xtrabackup --prepare --export --target-dir=/tmp/table \
--keyring-file-data=/var/lib/mysql-keyring/keyring

اکنون باید یک فایل .exp در دایرکتوری مقصد مشاهده کنید:

$ find /data/backups/mysql/ -name export_test.*
/data/backups/mysql/test/export_test.exp
/data/backups/mysql/test/export_test.ibd
/data/backups/mysql/test/export_test.cfg

این سه فایل تنها فایل‌های لازم برای وارد کردن جدول به سروری هستند که Percona Server for MySQL همراه با XtraDB یا MySQL 8.0 را اجرا می‌کند. در صورتی که سرور از InnoDB Tablespace Encryption استفاده کند، یک فایل اضافی .cfp شامل کلید انتقال و کلید رمزنگاری‌شدهٔ tablespace نیز اضافه می‌شود.

نکته:

فایل فرادادهٔ (metadata) .cfg حاوی یک نسخهٔ تخلیه از دیکشنری (dictionary dump) InnoDB در قالبی ویژه است. این قالب با قالب .exp که در XtraDB برای همین منظور استفاده می‌شود متفاوت است. فایل .cfg` برای وارد کردن یک tablespace به MySQL 8.0 یا Percona Server for MySQL 8.0 لازم نیست.

فضای جدول (tablespace) با موفقیت وارد می‌شود حتی اگر جدول متعلق به سرور دیگری باشد، اما در صورتی که فایل .cfg متناظر در همان دایرکتوری قرار داشته باشد، InnoDB یک اعتبارسنجی طرحواره (schema validation) انجام می‌دهد.

در سرور مقصد که Percona Server for MySQL با XtraDB و گزینهٔ فعال‌شدهٔ innodb_import_table_from_xtrabackup یا MySQL 8.0 را اجرا می‌کند، جدولی با همان ساختار ایجاد کرده و سپس مراحل زیر را انجام دهید:

1.
دستور ALTER TABLE test.export_test DISCARD TABLESPACE; را اجرا کنید. اگر خطای زیر را مشاهده کردید، گزینهٔ innodb_file_per_table را فعال کرده و جدول را دوباره ایجاد کنید.
خطا (Error)

ERROR 1030 (HY000): Got error -1 from storage engine

2.
فایل‌های برون‌ریزی‌شده را در زیردایرکتوری test/ دایرکتوری داده‌های (data directory) سرور مقصد کپی کنید
3.
دستور ALTER TABLE test.export_test IMPORT TABLESPACE; را اجرا کنید.

جدول وارد شده است و می‌توانید برای دیدن داده‌های واردشده یک دستور SELECT اجرا کنید.

ابزار Percona XtraBackup یک دامپ ذخیره‌شده از buffer pool را در نسخهٔ پشتیبان قرار می‌دهد تا زمان گرم‌شدن (warm up) را کاهش دهد. این ابزار وضعیت buffer pool را پس از راه‌اندازی مجدد از فایل ib_buffer_pool بازیابی می‌کند. Percona XtraBackup فایل ib_buffer_pool را شناسایی کرده و به‌طور خودکار از آن نسخهٔ پشتیبان تهیه می‌کند. [تصویر]

اگر گزینهٔ بازیابی بافر در my.cnf فعال باشد، buffer pool پس از بازیابی نسخهٔ پشتیبان در وضعیت گرم (warm) خواهد بود.

همچنین ببینید (SEE ALSO):

مستندات MySQL: ذخیره و بازیابی وضعیت Buffer Pool
https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html

ابزار Percona XtraBackup از حالت جریانی (streaming) پشتیبانی می‌کند. حالت جریانی به‌جای کپی کردن فایل‌ها در دایرکتوری پشتیبان، نسخهٔ پشتیبان را با قالب xbstream به STDOUT ارسال می‌کند.

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

برای استفاده از ویژگی جریان، باید از گزینهٔ --stream استفاده کنید که قالب جریان (xbstream) و محل ذخیرهٔ فایل‌های موقت را مشخص می‌کند:

$ xtrabackup --stream=xbstream --target-dir=/tmp

ابزار xtrabackup از xbstream برای ارسال جریانی همهٔ فایل‌های داده به STDOUT در قالب ویژهٔ xbstream استفاده می‌کند. پس از اتمام جریان همهٔ فایل‌های داده به STDOUT، فرایند xtrabackup را متوقف کرده و فایل لاگ ذخیره‌شده را نیز به‌صورت جریانی ارسال می‌کند.

همچنین ببینید (SEE ALSO):

اطلاعات بیشتر دربارهٔ xbstream
xbstream_binary

هنگامی که فشرده‌سازی فعال باشد، xtrabackup داده‌های خروجی را، به‌استثنای فایل‌های متا و فایل‌های غیر InnoDB که فشرده نمی‌شوند، با استفاده از الگوریتم فشرده‌سازی مشخص‌شده فشرده می‌کند. تنها الگوریتمی که در حال حاضر پشتیبانی می‌شود quicklz است. فایل‌های حاصل دارای قالب آرشیو qpress هستند؛ یعنی هر فایل *.qp تولیدشده توسط xtrabackup اساساً یک آرشیو تک‌فایلی qpress است و می‌تواند توسط ابزار بایگانی فایل qpress file archiver که در مخازن نرم‌افزاری Percona موجود است استخراج شده و از حالت فشرده خارج شود.

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

عملیات دستور
ارسال جریانی نسخهٔ پشتیبان به یک آرشیو با نام backup.xbstream xtrabackup --backup --stream=xbstream --target-dir=./ > backup.xbstream
ارسال جریانی نسخهٔ پشتیبان به یک آرشیو فشرده‌شده با نام backup.xbstream xtrabackup --backup --stream=xbstream --compress --target-dir=./ > backup.xbstream
رمزگذاری نسخهٔ پشتیبان $ xtrabackup --backup --stream=xbstream ./ > backup.xbstream gzip - | openssl des3 -salt -k "password" > backup.xbstream.gz.des3
استخراج نسخهٔ پشتیبان در دایرکتوری جاری xbstream -x < backup.xbstream
ارسال مستقیم نسخهٔ پشتیبانِ فشرده‌شده به میزبان دیگر و استخراج آن xtrabackup --backup --compress --stream=xbstream --target-dir=./ | ssh user@otherhost "xbstream -x"
ارسال نسخهٔ پشتیبان به سروری دیگر با استفاده از netcat. در میزبان مقصد: 0.0 3.5 $ nc -l 9999 | cat - > /data/backups/backup.xbstream 168u 168u در میزبان مبدأ: 0.0 3.5 $ xtrabackup --backup --stream=xbstream ./ | nc desthost 9999 168u 168u


ارسال نسخهٔ پشتیبان به سروری دیگر با یک دستور یکپارچه (one-liner): $ ssh user@desthost "( nc -l 9999 > /data/backups/backup.xbstream & )" && xtrabackup --backup --stream=xbstream ./ | nc desthost 9999
محدود کردن نرخ تبادل داده به 10MB/sec با استفاده از ابزار pipe viewer [1] $ xtrabackup --backup --stream=xbstream ./ | pv -q -L10m ssh user@desthost "cat - > /data/backups/backup.xbstream"
محاسبهٔ جمع کنترلی (checksum) نسخهٔ پشتیبان در حین ارسال جریانی: در میزبان مقصد: 0.0 3.5 $ nc -l 9999 | tee >(sha1sum > destination_checksum) > /data/backups/backup.xbstream 168u 168u در میزبان مبدأ: 0.0 3.5 $ xtrabackup --backup --stream=xbstream ./ | tee >(sha1sum > source_checksum) | nc desthost 9999 168u 168u مقایسهٔ جمع‌های کنترلی در میزبان مبدأ: 0.0 3.5 $ cat source_checksum 65e4f916a49c1f216e0887ce54cf59bf3934dbad - 168u 168u مقایسهٔ جمع‌های کنترلی در میزبان مقصد: 0.0 3.5 $ cat destination_checksum 65e4f916a49c1f216e0887ce54cf59bf3934dbad - 168u 168u




فشرده‌سازی موازی همراه با کپی موازی نسخهٔ پشتیبان xtrabackup --backup --compress --compress-threads=8 --stream=xbstream --parallel=4 --target-dir=./ > backup.xbstream
"پاورقی‌ها (FOOTNOTES)"
[1] 5
نصب از وبگاه رسمی یا از بسته توزیع (apt install pv)
توجه داشته باشید که نسخه پشتیبان جاری‌شده (streamed) پیش از بازیابی باید آماده‌سازی شود. حالت جاری‌سازی نسخه پشتیبان را آماده‌سازی نمی‌کند.
رمزنگاری نسخه‌های پشتیبان
Percona XtraBackup از رمزنگاری و رمزگشایی نسخه‌های پشتیبان محلی و جاری با گزینه xbstream پشتیبانی می‌کند که لایه حفاظتی دیگری می‌افزاید. رمزنگاری با استفاده از کتابخانه libgcrypt از GnuPG پیاده‌سازی شده است.
ایجاد نسخه‌های پشتیبان رمزنگاری‌شده
برای ایجاد یک نسخه پشتیبان رمزنگاری‌شده، گزینه‌های زیر باید مشخص شوند (گزینه‌های --encrypt-key و --encrypt-key-file ناسازگار با یکدیگرند، یعنی تنها یکی از آن‌ها باید مشخص شود):
0.0
• 2
--encrypt
• 2
:option:` --encrypt-key`
• 2
:option:` --encrypt-key-file`
168u
هر دو گزینه --encrypt-key و --encrypt-key-file می‌توانند برای مشخص کردن کلید رمزنگاری استفاده شوند. کلید رمزنگاری را می‌توان با دستوری مانند openssl rand -base64 32 تولید کرد.
نمونه خروجی این دستور باید شبیه به این باشد:
0.0
3.5
U2FsdGVkX19VPN7VM+lwNI0fePhjgnhgqmDBqbF3Bvs=

168u
168u
سپس از این مقدار می‌توان به عنوان کلید رمزنگاری استفاده کرد.
گزینه --encrypt-key
نمونه دستور xtrabackup با استفاده از --encrypt-key باید شبیه به این باشد:
0.0
3.5
$ xtrabackup --backup --encrypt=AES256 --encrypt-key="U2FsdGVkX19VPN7VM+lwNI0fePhjgnhgqmDBqbF3Bvs=" --target-dir=/data/backup

168u
168u
گزینه --encrypt-key-file
از گزینه --encrypt-key-file به صورت زیر استفاده کنید:
0.0
3.5
$ xtrabackup --backup --encrypt=AES256 --encrypt-key-file=/data/backups/keyfile --target-dir=/data/backup

168u
168u
نکته:
0.0
3.5
بسته به ویرایشگر متنی که برای ساخت KEYFILE استفاده می‌کنید، ویرایشگر ممکن است نویسه CRLF (انتهای خط) را به طور خودکار درج کند. این امر موجب افزایش اندازه کلید شده و در نتیجه آن را نامعتبر می‌سازد. روش پیشنهادی برای ایجاد فایل استفاده از خط فرمان است: echo -n "U2FsdGVkX19VPN7VM+lwNI0fePhjgnhgqmDBqbF3Bvs=" > /data/backups/keyfile.
168u
168u
بهینه‌سازی فرایند رمزنگاری
دو گزینه جدید برای نسخه‌های پشتیبان رمزنگاری‌شده در دسترس است که می‌توانند برای سرعت بخشیدن به فرایند رمزنگاری استفاده شوند. این گزینه‌ها --encrypt-threads و --encrypt-chunk-size هستند. با استفاده از گزینه --encrypt-threads می‌توان چندین رشته (thread) را برای استفاده در رمزنگاری به صورت موازی مشخص کرد. از گزینه --encrypt-chunk-size می‌توان برای مشخص کردن اندازه (به بایت) بافر کاری رمزنگاری برای هر رشته رمزنگاری استفاده کرد (پیش‌فرض 64K است).
رمزگشایی نسخه‌های پشتیبان رمزنگاری‌شده
نسخه‌های پشتیبان را می‌توان با xbcrypt رمزگشایی کرد. دستور تک‌خطی زیر می‌تواند برای رمزگشایی کل پوشه استفاده شود:
0.0
3.5
$ for i in `find . -iname "*\.xbcrypt"`; do xbcrypt -d --encrypt-key-file=/root/secret_key --encrypt-algo=AES256 < $i > $(dirname $i)/$(basename $i .xbcrypt) && rm $i; done

168u
168u
گزینه --decrypt در Percona XtraBackup پیاده‌سازی شده است که می‌تواند برای رمزگشایی نسخه‌های پشتیبان استفاده شود:
0.0
3.5
$ xtrabackup --decrypt=AES256 --encrypt-key="U2FsdGVkX19VPN7VM+lwNI0fePhjgnhgqmDBqbF3Bvs=" --target-dir=/data/backup/

168u
168u
Percona XtraBackup فایل‌های رمزنگاری‌شده را به طور خودکار حذف نمی‌کند. برای پاکسازی دایرکتوری پشتیبان، کاربران باید فایل‌های *.xbcrypt را حذف کنند.
نکته:
0.0
3.5
می‌توان از --parallel همراه با گزینه --decrypt برای رمزگشایی هم‌زمان چندین فایل استفاده کرد.
168u
168u
هنگامی که فایل‌ها رمزگشایی شدند، نسخه پشتیبان را می‌توان آماده‌سازی کرد..SS آماده‌سازی پشتیبان‌های رمزنگاری‌شده
پس از رمزگشایی نسخه‌های پشتیبان، می‌توان آن‌ها را همانند نسخه‌های پشتیبان کامل و استاندارد با گزینهٔ --prepare آماده‌سازی کرد:
0.0
3.5
$ xtrabackup --prepare --target-dir=/data/backup/

168u
168u
بازگردانی پشتیبان‌های رمزنگاری‌شده
xtrabackup گزینهٔ --copy-back را برای بازگردانی یک پشتیبان به datadir سرور ارائه می‌دهد:
0.0
3.5
$ xtrabackup --copy-back --target-dir=/data/backup/

168u
168u
این دستور تمام فایل‌های مرتبط با داده را به datadir سرور (که توسط فایل پیکربندی my.cnf سرور تعیین می‌شود) بازمی‌گرداند. برای اطمینان از پیام موفقیت، آخرین خط خروجی را بررسی کنید:
0.0
3.5
150318 11:08:13 xtrabackup: completed OK!

168u
168u
همچنین ببینید:
0.0
3.5
0.0
مستندات GnuPG: کتابخانهٔ libgcrypt
http://www.gnupg.org/documentation/manuals/gcrypt
168u
168u
168u
گزینهٔ FLUSH TABLES WITH READ LOCK
گزینهٔ FLUSH TABLES WITH READ LOCK با اعمال یک قفل خواندن سراسری کارهای زیر را انجام می‌دهد:
0.0
• 2
بستن همهٔ جدول‌های باز
• 2
قفل کردن همهٔ جدول‌ها برای تمام پایگاه‌های داده
168u
قفل را با UNLOCK TABLES آزاد کنید.
نکته:
0.0
3.5
FLUSH TABLES WITH READ LOCK مانع درج سطرها در جدول‌های گزارش نمی‌شود.
168u
168u
جهت اطمینان از سازگاری پشتیبان‌ها، قبل از تهیهٔ پشتیبان از فایل‌های غیر InnoDB از گزینهٔ FLUSH TABLES WITH READ LOCK استفاده کنید. این گزینه تأثیری بر پرس‌وجوهای طولانی‌مدت ندارد.
پرس‌وجوهای طولانی‌مدت در صورت فعال بودن FLUSH TABLES WITH READ LOCK می‌توانند سرور را تا پایان اجرای خود در حالت فقط‌خواندنی قرار دهند. پایان دادن اجباری به FLUSH TABLES WITH READ LOCK در صورتی که پایگاه داده در یکی از وضعیت‌های Waiting for table flush یا Waiting for master to send event باشد کمکی نمی‌کند. برای بازگشت به عملکرد عادی، باید هر پرس‌وجوی طولانی‌مدت را متوقف کنید.
نکته:
0.0
3.5
تمامی موارد شرح داده شده در این بخش هنگام استفاده از قفل‌های پشتیبان‌گیری بی‌استفاده هستند. Percona XtraBackup در صورت وجود، از Backup locks به عنوان جایگزینی سبک برای FLUSH TABLES WITH READ LOCK استفاده خواهد کرد. این ویژگی در Percona Server for MySQL نسخهٔ 5.6 به بالا موجود است. Percona XtraBackup به‌طور خودکار از این قابلیت برای رونویسی داده‌های غیر InnoDB استفاده می‌کند تا از مسدود شدن پرس‌وجوهای DML که جدول‌های InnoDB را اصلاح می‌کنند، جلوگیری شود.
168u
168u
به منظور جلوگیری از رخ دادن این مسئله، دو راهکار پیاده‌سازی شده است:
0.0
• 2
xtrabackup منتظر زمان مناسبی برای صدور قفل سراسری می‌ماند
• 2
xtrabackup همهٔ پرس‌وجوها یا فقط پرس‌وجوهای SELECT را که مانع دریافت قفل سراسری می‌شوند، متوقف می‌کند
168u
انتظار برای پایان پرس‌وجوها
شما باید زمانی قفل سراسری را صادر کنید که هیچ پرس‌وجوی طولانی‌ای در حال اجرا نباشد. منتظر ماندن برای صدور قفل سراسری برای مدت زمانی طولانی، روش مناسبی نیست. این انتظار می‌تواند زمان مورد نیاز برای انجام پشتیبان‌گیری را افزایش دهد. گزینهٔ --ftwrl-wait-timeout می‌تواند زمان انتظار را محدود کند. اگر نتواند در این زمان قفل را صادر کند، xtrabackup گزینه را متوقف کرده، با یک پیام خطا خارج می‌شود و پشتیبان‌گیری انجام نخواهد شد.
مقدار پیش‌فرض این گزینه صفر (0) است که این گزینه را غیرفعال می‌کند.
احتمال دیگر، تعیین نوع پرس‌وجویی است که باید منتظر آن ماند. در این حالت از --ftwrl-wait-query-type استفاده می‌شود. مقدارهای ممکن all و update هستند. زمانی که از all استفاده می‌شود، xtrabackup قبل از اجرای FLUSH TABLES WITH READ LOCK منتظر می‌ماند تا تمام پرس‌وجوهای طولانی‌مدت (با زمان اجرای بیشتر از مقدار تعیین‌شده توسط --ftwrl-wait-threshold) پایان یابند. زمانی که از update استفاده می‌شود، xtrabackup منتظر پایان پرس‌وجوهای UPDATE/ALTER/REPLACE/INSERT می‌ماند.
پیش‌بینی زمان لازم برای تکمیل یک پرس‌وجوی خاص دشوار است. فرض بر این است که پرس‌وجوهای طولانی‌مدت در زمان مناسب به پایان نخواهند رسید. سایر پرس‌وجوها که زمان کوتاهی اجرا می‌شوند، سریع پایان می‌یابند. xtrabackup از مقدار گزینهٔ --ftwrl-wait-threshold برای مشخص کردن پرس‌وجوهای طولانی‌مدت که قفل سراسری را مسدود می‌کنند، استفاده می‌کند. برای استفاده از این گزینه، کاربر xtrabackup باید دسترسی‌های PROCESS و SUPER را داشته باشد.
متوقف کردن پرس‌وجوهای مسدودکننده
راهکار دوم، متوقف کردن تمام پرس‌وجوهایی است که مانع دریافت قفل سراسری می‌شوند. در این حالت، تمام پرس‌وجوهایی که اجرای آن‌ها بیشتر از FLUSH TABLES WITH READ LOCK طول بکشد، مسدودکننده‌های بالقوه هستند. اگرچه می‌توان تمام پرس‌وجوها را متوقف کرد، اما با استفاده از گزینهٔ --kill-long-queries-timeout می‌توان زمان بیشتری را برای پایان یافتن پرس‌وجوهای کوتاه‌مدت تعیین نمود. این گزینه زمان تکمیل پرس‌وجوها را مشخص می‌کند؛ پس از رسیدن به این مقدار، تمام پرس‌وجوهای در حال اجرا متوقف خواهند شد. مقدار پیش‌فرض صفر است که این ویژگی را خاموش می‌کند.
گزینهٔ --kill-long-query-type می‌تواند برای مشخص کردن همه یا تنها پرس‌وجوهای SELECT که مانع دریافت قفل سراسری می‌شوند، استفاده شود. برای استفاده از این گزینه، کاربر xtrabackup باید از دسترسی‌های PROCESS و SUPER برخوردار باشد..SS خلاصه گزینه‌ها
0.0
• 2
--ftwrl-wait-timeout (به ثانیه) - چه مدت برای یک لحظه مناسب صبر شود. مقدار پیش‌فرض 0 است، یعنی صبر نشود.
• 2
--ftwrl-wait-query-type - کدام پرس‌وجوهای طولانی‌مدت باید پیش از اجرای FLUSH TABLES WITH READ LOCK به پایان برسند. مقدار پیش‌فرض all است.
• 2
--ftwrl-wait-threshold (به ثانیه) - یک پرس‌وجو چه مدت باید در حال اجرا باشد تا طولانی‌مدت و مسدودکننده احتمالی قفل سراسری در نظر گرفته شود.
• 2
--kill-long-queries-timeout (به ثانیه) - پس از صدور دستور FLUSH TABLES WITH READ LOCK چه مقدار زمان پیش از شروع به بستن پرس‌وجوها، برای اتمام به آن‌ها داده شود. مقدار پیش‌فرض 0 است، یعنی بسته نشوند.
• 2
--kill-long-query-type - پس از اتمام زمان kill-long-queries-timeout، کدام پرس‌وجوها باید کشته و متوقف شوند.
168u
مثال
اجرای xtrabackup با گزینه‌های زیر باعث می‌شود xtrabackup بیش از ۳ دقیقه برای اتمام تمام پرس‌وجوهایی که بیش از ۴۰ ثانیه در حال اجرا بوده‌اند، منتظر نماند.
0.0
3.5
$ xtrabackup --backup --ftwrl-wait-threshold=40 \
--ftwrl-wait-query-type=all --ftwrl-wait-timeout=180 \
--kill-long-queries-timeout=20 --kill-long-query-type=all \
--target-dir=/data/backups/

168u
168u
پس از صدور FLUSH TABLES WITH READ LOCK، دستور xtrabackup به مدت ۲۰ ثانیه برای اخذ قفل منتظر می‌ماند. اگر پس از ۲۰ ثانیه قفل همچنان اخذ نشده باشد، تمام پرس‌وجوهایی را که طولانی‌تر از FLUSH TABLES WITH READ LOCK در حال اجرا بوده‌اند، متوقف خواهد کرد.
شتاب‌بخشی به فرآیند پشتیبان‌گیری
کپی با گزینه‌های --parallel و --compress-threads
هنگام تهیه پشتیبان محلی یا جریانی با گزینه xbstream، با استفاده از گزینه --parallel می‌توان چندین فایل را به طور هم‌زمان کپی کرد. این گزینه تعداد ریسه‌های (threads) ایجاد شده توسط xtrabackup را برای کپی فایل‌های داده تعیین می‌کند.
برای بهره‌گیری از این گزینه، یا باید گزینه فضاهای جدول چندگانه فعال باشد (innodb_file_per_table) یا اینکه فضای جدول مشترک با گزینه innodb_data_file_path در چندین فایل ibdata ذخیره شده باشد. داشتن چندین فایل برای پایگاه داده (یا تقسیم یکی به چند فایل) تأثیر قابل اندازه‌گیری بر کارایی ندارد.
از آنجا که این ویژگی در سطح فایل پیاده‌سازی شده است، انتقال هم‌زمان فایل‌ها گاهی اوقات به دلیل هم‌پوشانی تعداد بیشتری از درخواست‌های خواندن تصادفی هنگام پشتیبان‌گیری از فایل‌های داده‌ای به شدت تکه‌تکه‌شده (fragmented)، می‌تواند نرخ ورودی/خروجی (I/O throughput) را افزایش دهد. همچنین برای دستیابی به حداکثر کارایی، باید بهینه‌سازی سیستم‌فایل را نیز در نظر بگیرید (مانند بررسی تکه‌تکه‌شدگی فایل‌ها).
اگر داده‌ها در یک تک‌فایل ذخیره شده باشند، این گزینه هیچ اثری نخواهد داشت.
برای استفاده از این ویژگی، کافی است این گزینه را به پشتیبان‌گیری محلی اضافه کنید؛ برای نمونه:
0.0
3.5
$ xtrabackup --backup --parallel=4 --target-dir=/path/to/backup

168u
168u
با استفاده از xbstream در پشتیبان‌گیری‌های جریانی، می‌توانید علاوه بر این، فرآیند فشرده‌سازی را نیز با گزینه --compress-threads تسریع کنید. این گزینه تعداد ریسه‌های ایجاد شده توسط xtrabackup را برای فشرده‌سازی موازی داده‌ها مشخص می‌کند. مقدار پیش‌فرض این گزینه 1 است.
برای استفاده از این ویژگی، کافی است این گزینه را به پشتیبان‌گیری محلی اضافه کنید؛ برای نمونه:
0.0
3.5
$ xtrabackup --backup --stream=xbstream --compress --compress-threads=4 --target-dir=./ > backup.xbstream

168u
168u
پیش از اعمال لاگ‌ها، فایل‌های فشرده‌شده باید از حالت فشرده خارج شوند.
گزینه --rsync
به منظور افزایش سرعت فرآیند پشتیبان‌گیری و به حداقل رساندن مدت زمانی که FLUSH TABLES WITH READ LOCK عملیات نوشتن را مسدود می‌کند، باید از گزینه --rsync استفاده شود. هنگامی که این گزینه مشخص شود، xtrabackup برای کپی کردن تمام فایل‌های غیر InnoDB به جای اجرای یک cp جداگانه برای هر فایل، از rsync استفاده می‌کند که می‌تواند در سرورهایی با تعداد زیادی پایگاه داده یا جدول بسیار سریع‌تر باشد. xtrabackup دستور rsync را دو بار فراخوانی می‌کند؛ یک بار پیش از FLUSH TABLES WITH READ LOCK و یک بار در حین آن، تا مدت زمان نگه‌داشتن قفل خواندن به حداقل برسد. در طول دومین فراخوانی rsync، تنها تغییرات داده‌های غیرتراکنشی (در صورت وجود) از زمان اولین فراخوانی انجام‌شده پیش از FLUSH TABLES WITH READ LOCK همگام‌سازی می‌شوند. توجه داشته باشید که Percona XtraBackup در صورت وجود، از Backup locks به عنوان جایگزینی سبک برای FLUSH TABLES WITH READ LOCK استفاده خواهد کرد. این ویژگی در Percona Server for MySQL نگارش 5.6 به بالا موجود است. Percona XtraBackup به طور خودکار از این سازوکار برای کپی داده‌های غیر InnoDB استفاده می‌کند تا از مسدود شدن پرس‌وجوهای DML که جداول InnoDB را تغییر می‌دهند، جلوگیری شود.
نکته:
0.0
3.5
این گزینه نمی‌تواند همراه با گزینه --stream استفاده شود.
168u
بازیابی تا یک لحظه مشخص در تاریخچه پایگاه داده با استفاده از
xtrabackup و لاگ‌های باینری سرور امکان‌پذیر است.
توجه داشته باشید که لاگ باینری حاوی عملیاتی است که پایگاه داده را از
نقطه‌ای در گذشته تغییر داده‌اند. شما به یک datadir کامل به عنوان پایه نیاز دارید،
و سپس می‌توانید مجموعه‌ای از عملیات را از لاگ باینری اعمال کنید تا داده‌ها با وضعیت آن
در نقطه زمانی مورد نظرتان تطابق یابند.
0.0
3.5
$ xtrabackup --backup --target-dir=/path/to/backup
$ xtrabackup --prepare --target-dir=/path/to/backup

168u
168u
برای جزئیات بیشتر درباره این مراحل، creating_a_backup و preparing_a_backup را ببینید.
اکنون فرض کنید مدتی گذشته است و می‌خواهید پایگاه داده را به یک نقطه زمانی خاص در گذشته بازیابی کنید،
با در نظر گرفتن این محدودیت که تصویر لحظه‌ای (snapshot) در چه نقطه‌ای گرفته شده است.
برای آگاهی از وضعیت لاگ باینری در سرور، پرس‌وجوهای زیر را اجرا کنید:
0.0
3.5
mysql> SHOW BINARY LOGS;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 126 |
| mysql-bin.000002 | 1306 |
| mysql-bin.000003 | 126 |
| mysql-bin.000004 | 497 |
+------------------+-----------+

168u
168u
و
0.0
3.5
mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 | 497 | | |
+------------------+----------+--------------+------------------+

168u
168u
پرس‌وجوی نخست به شما می‌گوید چه فایل‌هایی حاوی لاگ باینری هستند و پرس‌وجوی دوم نشان می‌دهد
در حال حاضر کدام فایل برای ثبت تغییرات استفاده می‌شود و موقعیت جاری درون آن کجاست.
این فایل‌ها معمولاً در datadir ذخیره می‌شوند (مگر اینکه هنگام راه‌اندازی سرور،
مسیر دیگری با گزینه --log-bin= مشخص شده باشد).
برای یافتن موقعیتِ تصویر لحظه‌ای گرفته‌شده، فایل
xtrabackup_binlog_info را در دایرکتوری پشتیبان مشاهده کنید:
0.0
3.5
$ cat /path/to/backup/xtrabackup_binlog_info
mysql-bin.000003 57

168u
168u
این فایل مشخص می‌کند که در لحظه تهیه پشتیبان، کدام فایل برای لاگ باینری
استفاده می‌شده و در چه موقعیتی بوده است. هنگام بازیابی پشتیبان، آن موقعیت
مبنای اثر خواهد بود:
0.0
3.5
$ xtrabackup --copy-back --target-dir=/path/to/backup

168u
168u
از آنجا که فرایند بازیابی بر فایل‌های لاگ باینری تاثیری نمی‌گذارد (ممکن است نیاز باشد
دسترسی‌های فایل را تنظیم کنید، به restoring_a_backup مراجعه کنید)، گام بعدی
استخراج پرس‌وجوها از لاگ باینری با استفاده از mysqlbinlog با شروع از
موقعیت تصویر لحظه‌ای و هدایت آن به یک فایل است:
0.0
3.5
$ mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 > mybinlog.sql

168u
168u
توجه داشته باشید که اگر مانند این مثال چندین فایل برای لاگ باینری دارید،
باید پرس‌وجوها را مانند بالا در یک پردازش واحد استخراج کنید.
فایل حاوی پرس‌وجوها را بررسی کنید تا مشخص شود کدام موقعیت یا تاریخ
با نقطه زمانی مورد نظرتان مطابقت دارد. پس از تعیین، آن را به سرور پایپ کنید.
با فرض اینکه این نقطه 11-12-25 01:00:00 باشد:
0.0
3.5
$ mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 --stop-datetime="11-12-25 01:00:00" | mysql -u root -p

محدودیت‌ها
168u
168u
و پایگاه داده تا همان نقطه زمانی به جلو اعمال خواهد شد (rolled forward)..SS پشتیبان‌گیری در محیط‌های همانندسازی (Replication)
گزینه‌های ویژه‌ای برای پشتیبان‌گیری از یک رپلیکای همانندسازی وجود دارد.
گزینهٔ --slave-info
این گزینه هنگام پشتیبان‌گیری از یک کارگزار رپلیکا کاربرد دارد. این گزینه موقعیت binary log و نام کارگزار مبدأ (source) را چاپ می‌کند. همچنین این اطلاعات را در قالب یک عبارت CHANGE MASTER در فایل xtrabackup_slave_info می‌نویسد.
این گزینه برای راه‌اندازی یک رپلیکای جدید برای این مبدأ سودمند است. می‌توانید کارگزار رپلیکا را با این نسخهٔ پشتیبان آغاز کرده و دستور ذخیره‌شده در فایل xtrabackup_slave_info را اجرا کنید. جزئیات بیشتر دربارهٔ این روند در replication_howto یافت می‌شود.
گزینهٔ --safe-slave-backup
به منظور اطمینان از یک وضعیت همانندسازی سازگار، این گزینه ریسهٔ (thread) SQL همانندسازی را متوقف کرده و پیش از آغاز پشتیبان‌گیری منتظر می‌ماند تا مقدار Slave_open_temp_tables در دستور SHOW STATUS صفر شود. اگر هیچ جدول موقت بازی وجود نداشته باشد، پشتیبان‌گیری انجام می‌شود؛ در غیر این صورت ریسهٔ SQL راه‌اندازی و دوباره متوقف خواهد شد تا زمانی که هیچ جدول موقت بازی باقی نماند. چنانچه مقدار Slave_open_temp_tables پس از گذشت مدت‌زمان --safe-slave-backup-timeout ثانیه (پیش‌فرض ۳۰۰ ثانیه) صفر نشود، پشتیبان‌گیری با شکست مواجه خواهد شد. با پایان یافتن پشتیبان‌گیری، ریسهٔ SQL همانندسازی مجدداً راه‌اندازی می‌شود.
استفاده از این گزینه هنگام تهیهٔ نسخهٔ پشتیبان از یک کارگزار رپلیکا همواره توصیه می‌شود.
هشدار:
0.0
3.5
پیش از استفاده از یک رپلیکا به عنوان مبدأ برای پشتیبان‌گیری، اطمینان حاصل کنید که رپلیکای شما یک رونوشت دقیق از مبدأ است. ابزاری مناسب برای اعتبارسنجی یک رپلیکا، pt-table-checksum است.
168u
168u
ذخیرهٔ تاریخچهٔ پشتیبان‌گیری روی کارگزار
Percona XtraBackup از ذخیرهٔ تاریخچهٔ نسخه‌های پشتیبان بر روی کارگزار پشتیبانی می‌کند. این قابلیت در Percona XtraBackup 2.2 پیاده‌سازی شده است. ذخیرهٔ تاریخچهٔ پشتیبان‌گیری روی کارگزار برای ارائهٔ اطلاعات بیشتر به کاربران دربارهٔ پشتیبان‌هایی که در حال تهیه هستند پیاده‌سازی شده است. اطلاعات تاریخچهٔ پشتیبان‌گیری در جدول PERCONA_SCHEMA.XTRABACKUP_HISTORY ذخیره خواهد شد.
برای استفاده از این قابلیت، گزینه‌های زیر در دسترس هستند:
0.0
• 2
--history =<name> : این گزینه قابلیت تاریخچه را فعال کرده و به کاربر امکان می‌دهد نامی برای سری پشتیبان مشخص کند که در رکورد تاریخچه ثبت خواهد شد.
• 2
--incremental-history-name =<name> : این گزینه امکان تهیهٔ پشتیبان افزایشی بر اساس نام یک سری مشخص در تاریخچه را فراهم می‌سازد. xtrabackup جدول تاریخچه را به دنبال جدیدترین نسخهٔ پشتیبان (با بیشترین مقدار to_lsn) در آن سری جستجو کرده و از مقدار to_lsn به عنوان LSN آغازین استفاده می‌کند. این گزینه با گزینه‌های --incremental-history-uuid، --incremental-basedir و --incremental-lsn مانعة‌الجمع است. اگر LSN معتبری یافت نشود (سری با این نام وجود نداشته باشد)، xtrabackup با خطا مواجه خواهد شد.
• 2
--incremental-history-uuid =<uuid> : امکان تهیهٔ پشتیبان افزایشی را بر اساس رکورد مشخصی از تاریخچه که با UUID شناسایی می‌شود فراهم می‌آورد. xtrabackup جدول تاریخچه را به دنبال رکوردی مطابق با این UUID جستجو کرده و از مقدار to_lsn به عنوان LSN آغازین استفاده می‌کند. این گزینه با گزینه‌های --incremental-basedir، --incremental-lsn و --incremental-history-name مانعة‌الجمع است. اگر هیچ LSN معتبری یافت نشود (رکوردی با آن UUID وجود نداشته باشد یا مقدار to_lsn موجود نباشد)، xtrabackup با یک خطا خاتمه می‌یابد.
168u
نکته:
0.0
3.5
پشتیبانی که در حال حاضر در دست اقدام است، در جدول xtrabackup_history درون مجموعه پشتیبان حاصل وجود نخواهد داشت، زیرا رکورد مربوطه تا پس از تکمیل فرآیند پشتیبان‌گیری به آن جدول افزوده نخواهد شد.
168u
168u
اگر می‌خواهید در صورت بروز رویدادی فاجعه‌بار به تاریخچهٔ پشتیبان خارج از مجموعه پشتیبان خود دسترسی داشته باشید، باید پس از اتمام کار xtrabackup، یک mysqldump، پشتیبان جزئی یا دستور SELECT * روی جدول تاریخچه اجرا کرده و نتایج را همراه با مجموعه پشتیبان خود ذخیره نمایید.
برای مجوزهای لازم، pxb.privilege را ببینید.
جدول PERCONA_SCHEMA.XTRABACKUP_HISTORY
این جدول حاوی اطلاعات مربوط به نسخه‌های پشتیبان پیشین کارگزار است. اطلاعات پشتیبان‌ها تنها در صورتی در این جدول ثبت خواهد شد که پشتیبان‌گیری با گزینهٔ --history انجام شده باشد.
center;
|l|l|.
نام ستون توضیحات
uuid شناسهٔ یکتای نسخهٔ پشتیبان
name نام ارائه‌شده توسط کاربر برای سری پشتیبان. ممکن است چندین مدخل با نام یکسان برای شناسایی پشتیبان‌های مرتبط در یک سری وجود داشته باشد.
tool_name نام ابزار استفاده‌شده برای گرفتن نسخهٔ پشتیبان
tool_command خط فرمان دقیق داده‌شده به ابزار به طوری که --password و --encryption_key در آن مبهم‌سازی شده‌اند
tool_version نسخهٔ ابزار استفاده‌شده برای گرفتن نسخهٔ پشتیبان
ibbackup_version نسخهٔ باینری xtrabackup استفاده‌شده برای گرفتن نسخهٔ پشتیبان
server_version نسخهٔ کارگزاری که نسخهٔ پشتیبان روی آن گرفته شده است
start_time زمان در آغاز پشتیبان‌گیری
end_time زمان در پایان پشتیبان‌گیری
lock_time مدت‌زمان (به ثانیه) صرف‌شده برای فراخوانی و نگه‌داشتن قفل‌ها برای FLUSH TABLES WITH READ LOCK
binlog_pos فایل binlog و موقعیت آن در پایان FLUSH TABLES WITH READ LOCK
innodb_from_lsn مقدار LSN در آغاز پشتیبان‌گیری که می‌تواند برای تعیین پشتیبان‌های قبلی استفاده شود
innodb_to_lsn مقدار LSN در پایان پشتیبان‌گیری که می‌تواند به عنوان LSN آغازین برای پشتیبان افزایشی بعدی استفاده شود
partial آیا این یک پشتیبان جزئی است؛ اگر N باشد به این معناست که یک پشتیبان کامل است
incremental آیا این یک پشتیبان افزایشی است
format توضیح قالب نتیجه (xbstream)
compact آیا این یک پشتیبان فشرده (compact) است
compressed آیا این یک پشتیبان فشرده‌شده (compressed) است
encrypted آیا این یک پشتیبان رمزنگاری‌شده است
گزینهٔ --history برای مؤثر بودن باید تنها در خط فرمان مشخص شود و نه درون یک فایل پیکربندی.
•
گزینه‌های --incremental-history-name و --incremental-history-uuid برای مؤثر بودن باید تنها در خط فرمان مشخص شوند و نه درون یک فایل پیکربندی.

این صفحه شامل نکاتی دربارهٔ جنبه‌های داخلی گوناگون عملکرد ابزار xtrabackup است.

ابزار xtrabackup فایل‌های دادهٔ مبدأ را در حالت خواندن-نوشتن (read-write) باز می‌کند، هرچند که فایل‌ها را تغییر نمی‌دهد. این بدان معناست که باید xtrabackup را با کاربری اجرا کنید که مجوز نوشتن روی فایل‌های داده را دارد. دلیل باز کردن فایل‌ها در حالت خواندن-نوشتن این است که xtrabackup از کتابخانه‌های تعبیه‌شدهٔ InnoDB برای باز کردن و خواندن فایل‌ها استفاده می‌کند، و InnoDB آن‌ها را در حالت خواندن-نوشتن باز می‌کند زیرا معمولاً فرض را بر این می‌گذارد که قرار است در آن‌ها بنویسد.

از آنجا که xtrabackup حجم زیادی از داده‌ها را از سامانهٔ فایل می‌خواند، در صورت امکان از posix_fadvise() استفاده می‌کند تا به سیستم‌عامل دستور دهد بلوک‌هایی را که از دیسک می‌خواند در حافظهٔ موقت (کَش) ذخیره نکند. بدون این راهنمایی، سیستم‌عامل ترجیح می‌دهد بلوک‌ها را کَش کند، با این فرض که احتمالاً xtrabackup دوباره به آن‌ها نیاز خواهد داشت، در حالی که چنین نیست. کَش کردن فایل‌هایی با این حجم زیاد می‌تواند بر حافظهٔ مجازی سیستم‌عامل فشار وارد کند و باعث سوآپ (swap out) شدن سایر فرایندها، مانند کارساز پایگاه داده، شود. ابزار xtrabackup با ارائهٔ این راهنمایی روی هر دو فایل مبدأ و مقصد، از این مسئله جلوگیری می‌کند:

posix_fadvise(file, 0, 0, POSIX_FADV_DONTNEED)

علاوه بر این، xtrabackup از سیستم‌عامل می‌خواهد تا بهینه‌سازی‌های پیش‌خوانی (read-ahead) تهاجمی‌تری را روی فایل‌های مبدأ انجام دهد:

posix_fadvise(file, 0, 0, POSIX_FADV_SEQUENTIAL)

هنگام رونویسی فایل‌های داده به پوشهٔ مقصد، xtrabackup در هر نوبت ۱ مگابایت داده را می‌خواند و می‌نویسد. این مقدار قابل پیکربندی نیست. هنگام رونویسی فایل گزارش (log)، ابزار xtrabackup در هر نوبت ۵۱۲ بایت را می‌خواند و می‌نویسد. این مقدار نیز قابل پیکربندی نیست و با رفتار InnoDB مطابقت دارد (یک راهکار جایگزین در Percona Server for MySQL وجود دارد زیرا گزینه‌ای برای تنظیم innodb_log_block_size در XtraDB دارد، و در آن صورت Percona XtraBackup با این تنظیم مطابقت خواهد داشت).

پس از خواندن از فایل‌ها، xtrabackup روی بافر ۱ مگابایتی، صفحه به صفحه پیمایش می‌کند و خرابی صفحه را در هر صفحه با تابع buf_page_is_corrupted() مربوط به InnoDB بررسی می‌کند. اگر صفحه خراب باشد، آن را دوباره می‌خواند و برای هر صفحه تا ۱۰ بار تلاش مجدد می‌کند. این بررسی را برای بافر doublewrite نادیده می‌گیرد.

باینری xtrabackup پس از پشتیبان‌گیری در صورتی که خطایی رخ نداده باشد، با مقدار سنتی موفقیت 0 خارج می‌شود. اگر در حین پشتیبان‌گیری خطایی رخ دهد، مقدار خروج 1 خواهد بود.

در موارد خاصی، مقدار خروج ممکن است چیزی به جز 0 یا 1 باشد که ناشی از کد مدیریت گزینه‌های خط فرمان گنجانده‌شده از کتابخانه‌های MySQL است. به عنوان مثال، یک گزینهٔ ناشناخته در خط فرمان باعث ایجاد کد خروج 255 خواهد شد.

این صفحه تمام گزینه‌های خط فرمان باینری xtrabackup را مستند می‌کند.

شما xtrabackup را در یکی از حالت‌های زیر فراخوانی می‌کنید:

  • حالت --backup برای تهیهٔ نسخهٔ پشتیبان در یک پوشهٔ مقصد
  • حالت --prepare برای بازیابی داده‌ها از یک نسخهٔ پشتیبان (ایجادشده در حالت --backup)
  • حالت --copy-back برای رونویسی داده‌ها از نسخهٔ پشتیبان به مکانی که داده‌های اصلی را دربرداشت؛ برای انتقال داده‌ها به جای رونویسی، از حالت جایگزین --move-back استفاده کنید.
  • حالت --stats برای پیمایش فایل‌های دادهٔ مشخص‌شده و چاپ آمار شاخص‌ها.

هنگامی که قصد دارید xtrabackup را در هر یک از این حالت‌ها اجرا کنید، از نحو دستوری زیر استفاده کنید:

$ xtrabackup [--defaults-file=#] --backup|--prepare|--copy-back|--stats [OPTIONS]

برای مثال، حالت --prepare به صورت زیر اعمال می‌شود:

$ xtrabackup --prepare --target-dir=/data/backup/mysql/

برای همهٔ حالت‌ها، گزینه‌های پیش‌فرض از گروه‌های پیکربندی xtrabackup و mysqld از فایل‌های زیر و به ترتیب داده‌شده خوانده می‌شوند:

1.
/etc/my.cnf
2.
/etc/mysql/my.cnf
3.
/usr/etc/my.cnf
4.
~/.my.cnf.

به عنوان نخستین پارامتر برای xtrabackup (به جای --defaults-file)، می‌توانید یکی از موارد زیر را ارائه دهید:

  • --print-defaults تا xtrabackup فهرست آرگومان‌ها را چاپ کرده و خارج شود.
  • --no-defaults برای جلوگیری از خواندن گزینه‌ها از هر فایلی به جز فایل لاگین.
  • --defaults-file برای خواندن گزینه‌های پیش‌فرض از فایل داده‌شده.
  • --defaults-extra-file برای خواندن فایل اضافی مشخص‌شده پس از خوانده شدن فایل‌های سراسری.
  • --defaults-group-suffix برای خواندن گروه‌های پیکربندی با پسوند داده‌شده. نام گروه مؤثر از الحاق گروه‌های پیکربندی پیش‌فرض (xtrabackup و mysqld) به پسوند داده‌شده ساخته می‌شود.
  • --login-path برای خواندن مسیر داده‌شده از فایل لاگین.
گزینه‌های InnoDB

گروه بزرگی از گزینه‌های InnoDB وجود دارند که معمولاً از فایل پیکربندی my.cnf خوانده می‌شوند تا xtrabackup موتور تعبیه‌شدهٔ InnoDB خود را با همان پیکربندی کارساز فعلی شما راه‌اندازی کند. معمولاً نیازی نیست آن‌ها را به صراحت مشخص کنید. این گزینه‌ها در InnoDB و XtraDB رفتار یکسانی دارند. برای اطلاعات بیشتر --innodb-miscellaneous را ببینید..SS "گزینه‌ها (Options)"

این گزینه باعث می‌شود که هنگام آماده‌سازی پشتیبان، فقط مرحله redo انجام شود. این امر برای پشتیبان‌گیری‌های افزایشی بسیار مهم است.
تهیه یک نسخه پشتیبان و قرار دادن آن در --target-dir. بخش ایجاد پشتیبان را ببینید.
--backup-lock-timeout
مدت زمان مهلت انتظار (timeout) به ثانیه برای تلاش‌های دریافت قفل‌های فراداده (metadata locks).
--backup-lock-retry-count
تعداد دفعات تلاش برای دریافت قفل‌های فراداده (metadata locks).
--backup-locks
این گزینه کنترل می‌کند که آیا در مرحله پشتیبان‌گیری به جای FLUSH TABLES WITH READ LOCK باید از قفل‌های پشتیبان‌گیری استفاده شود یا خیر. این گزینه در صورتی که قفل‌های پشتیبان‌گیری توسط سرور پشتیبانی نشوند، هیچ تاثیری ندارد. این گزینه به طور پیش‌فرض فعال است؛ برای غیرفعال کردن از --no-backup-locks استفاده کنید.
این گزینه بررسی می‌کند که آیا Percona XtraBackup تمام دسترسی‌های لازم را دارد یا خیر. اگر دسترسی مفقود برای عملیات فعلی لازم باشد، برنامه خاتمه یافته و یک پیام خطا چاپ می‌کند. اگر دسترسی مفقود برای عملیات فعلی لازم نباشد، اما ممکن است برای برخی عملیات دیگر XtraBackup ضروری باشد، فرآیند متوقف نمی‌شود و یک هشدار چاپ می‌شود.
xtrabackup: Error: missing required privilege LOCK TABLES on *.*
xtrabackup: Warning: missing required privilege REPLICATION CLIENT on *.*
فایل‌ها را باز نگه ندارد. زمانی که xtrabackup یک tablespace را باز می‌کند، معمولاً دستگیره فایل (file handle) آن را باز نگه می‌دارد تا عملیات DDL را به درستی مدیریت کند. با این حال، اگر تعداد tablespaceها بسیار زیاد باشد و در هیچ محدودیتی نگنجد، این گزینه وجود دارد که دستگیره‌های فایل پس از اتمام دسترسی بسته شوند. Percona XtraBackup ممکن است با فعال بودن این گزینه نسخه‌های پشتیبان ناسازگار (inconsistent) تولید کند. با مسئولیت خودتان استفاده کنید.
این گزینه به xtrabackup می‌گوید تا تمام داده‌های خروجی، از جمله فایل گزارش تراکنش (transaction log) و فایل‌های فراداده را با استفاده از الگوریتم فشرده‌سازی quicklz یا lz4 فشرده کند. به طور پیش‌فرض quicklz انتخاب شده است.

هنگام استفاده از --compress=quicklz یا --compress، فایل‌های حاصل دارای قالب آرشیو qpress هستند؛ به این معنا که هر فایل *.qp تولید شده توسط xtrabackup اساساً یک آرشیو تک‌فایلی qpress است و می‌تواند توسط بایگان فایل qpress استخراج و از حالت فشرده خارج شود.

گزینه --compress=lz4 فایل‌های *.lz4 تولید می‌کند. می‌توانید محتویات این فایل‌ها را با استفاده از برنامه‌ای مانند lz4 استخراج کنید.

همچنین ببینید:

http://www.quicklz.com
https://lz4.github.io/lz4
--compress-chunk-size=#
اندازه بافر(های) کاری برای ریسه‌های فشرده‌سازی بر حسب بایت. مقدار پیش‌فرض 64K است.
--compress-threads=#
این گزینه تعداد ریسه‌های کاری (worker threads) مورد استفاده توسط xtrabackup را برای فشرده‌سازی موازی داده‌ها مشخص می‌کند. مقدار پیش‌فرض این گزینه 1 است. فشرده‌سازی موازی (--compress-threads) می‌تواند همراه با کپی موازی فایل‌ها (--parallel) استفاده شود. برای مثال، --parallel=4 --compress --compress-threads=2 تعداد ۴ ریسه I/O ایجاد می‌کند که داده‌ها را خوانده و به ۲ ریسه فشرده‌سازی هدایت (pipe) می‌کنند.
کپی تمام فایل‌های یک نسخه پشتیبان قبلی از دایرکتوری پشتیبان به مکان‌های اصلی آن‌ها. این گزینه فایل‌های موجود را بازنویسی نخواهد کرد مگر اینکه گزینه --force-non-empty-directories مشخص شده باشد.
ایجاد فایل تخلیه حافظه (core dump) در صورت دریافت سیگنال‌های مهلک (fatal signals).
این گزینه فهرستی از پایگاه‌های داده و جدول‌هایی را که باید از آن‌ها پشتیبان‌گیری شود مشخص می‌کند. این گزینه فهرستی به صورت "databasename1[.table_name1] databasename2[.table_name2] . . ." می‌پذیرد.
مستثنی کردن پایگاه‌های داده بر اساس نام. عملکرد آن همانند --databases است، اما نام‌های منطبق از پشتیبان‌گیری مستثنی می‌شوند. توجه داشته باشید که این گزینه نسبت به --databases اولویت بالاتری دارد.
این گزینه مسیر فایلی را مشخص می‌کند که حاوی فهرست پایگاه‌های داده و جدول‌های مورد نظر برای پشتیبان‌گیری است. این فایل می‌تواند شامل عناصر فهرست به صورت databasename1[.table_name1]، در هر سطر یک عنصر باشد.
دایرکتوری مبدا برای پشتیبان‌گیری. این مقدار باید همان datadir سرور MySQL شما باشد، بنابراین در صورت وجود my.cnf باید از آن خوانده شود؛ در غیر این صورت باید آن را در خط فرمان مشخص کنید.

هنگامی که با گزینه --copy-back یا --move-back ترکیب شود، --datadir به دایرکتوری مقصد اشاره دارد.

پس از اتصال به سرور، جهت انجام پشتیبان‌گیری به دسترسی‌های READ و EXECUTE در سطح سیستم‌فایل در datadir سرور نیاز خواهید داشت.

این یک گزینه مخصوص اشکال‌زدایی است که توسط مجموعه آزمون xtrabackup استفاده می‌شود.
نقطه همگام‌سازی اشکال‌زدایی (debug sync point). این گزینه فقط توسط مجموعه آزمون xtrabackup استفاده می‌شود.
تمام فایل‌های دارای پسوند .qp را در یک پشتیبان که قبلاً با گزینه --compress تهیه شده است، از حالت فشرده خارج می‌کند. گزینه --parallel اجازه می‌دهد چندین فایل به طور هم‌زمان فشرده‌زدایی شوند. برای خارج کردن از حالت فشرده، ابزار qpress حتماً باید نصب شده و در مسیر اجرایی (PATH) در دسترس باشد. Percona XtraBackup به طور خودکار فایل‌های فشرده را حذف نمی‌کند. برای پاک‌سازی دایرکتوری پشتیبان، کاربران باید از گزینه --remove-original استفاده کنند.

گزینه --decompress ممکن است با xbstream برای خارج کردن تک‌تک فایل‌های qpress از حالت فشرده استفاده شود.

اگر از الگوریتم فشرده‌سازی lz4 برای فشرده‌سازی فایل‌ها استفاده کرده‌اید (--compress=lz4)، پارامتر --decompress را متناسب با آن تغییر دهید: --decompress=lz4.

--decompress-threads=#
وادار کردن xbstream به استفاده از تعداد مشخص‌شده‌ای از ریسه‌ها برای خارج کردن از حالت فشرده.
رمزگشایی تمام فایل‌های دارای پسوند .xbcrypt در یک پشتیبان که قبلاً با گزینه --encrypt تهیه شده است. گزینه --parallel اجازه می‌دهد چندین فایل به طور هم‌زمان رمزگشایی شوند. Percona XtraBackup فایل‌های رمزگذاری‌شده را به طور خودکار حذف نمی‌کند. برای پاک‌سازی دایرکتوری پشتیبان، کاربران باید از گزینه --remove-original استفاده کنند.
--defaults-extra-file=[MY.CNF] این فایل پس از خواندن فایل‌های سراسری خوانده می‌شود. باید به عنوان نخستین گزینه در خط فرمان مشخص شود.
تنها گزینه‌های پیش‌فرض را از فایل مشخص‌شده بخواند. باید به عنوان نخستین گزینه در خط فرمان مشخص شود. باید یک فایل واقعی باشد؛ نمی‌تواند یک پیوند نمادین باشد.
این گزینه گروهی را که باید از فایل پیکربندی خوانده شود تعیین می‌کند. در صورت استفاده از گزینه --defaults-group، این مورد توسط xtrabackup استفاده می‌شود. برای استقرارهای mysqld_multi مورد نیاز است.
گروه‌ها را همچنین با ترکیب concat(group, suffix) می‌خواند.
این گزینه کنترل می‌کند که آیا تخلیه (dump) جدیدی از محتویات buffer pool انجام شود یا خیر.

با تعیین --dump-innodb-buffer-pool، ابزار xtrabackup در آغاز فرایند پشتیبان‌گیری درخواستی را به سرور ارسال می‌کند تا تخلیه buffer pool را آغاز کند (کامل شدن آن مدتی زمان می‌برد و در پس‌زمینه انجام می‌شود)، مشروط بر اینکه متغیر وضعیت innodb_buffer_pool_dump_status گزارش دهد که تخلیه قبلی کامل شده است.

$ xtrabackup --backup --dump-innodb-buffer-pool --target-dir=/home/user/backup

به‌طور پیش‌فرض، این گزینه روی OFF تنظیم شده است.

اگر innodb_buffer_pool_dump_status گزارش دهد که عملیات تخلیه buffer pool در حال اجرا است، xtrabackup با استفاده از مقدار تعیین‌شده در --dump-innodb-buffer-pool-timeout منتظر تکمیل آن می‌ماند.

فایل ib_buffer_pool شناسه‌های tablespace ID و page ID را جهت بارگذاری و گرم کردن سریع‌تر buffer pool ذخیره می‌کند.

همچنین ببینید:

مستندات MySQL: ذخیره و بازیابی وضعیت Buffer Pool
https://dev.mysql.com/doc/refman/5.7/en/innodb-preload-buffer-pool.html
این گزینه تعداد ثانیه‌هایی را مشخص می‌کند که xtrabackup باید مقدار innodb_buffer_pool_dump_status را پایش کند تا مشخص شود آیا تخلیه buffer pool کامل شده است یا خیر.

این گزینه در ترکیب با --dump-innodb-buffer-pool استفاده می‌شود. به‌طور پیش‌فرض، روی 10 ثانیه تنظیم شده است.

این گزینه درصد صفحاتی از buffer pool را که اخیراً استفاده شده‌اند، برای تخلیه مشخص می‌کند.

این گزینه در صورتی مؤثر است که گزینه --dump-innodb-buffer-pool روی ON تنظیم شده باشد. اگر این گزینه دارای مقدار باشد، xtrabackup متغیر سیستمی innodb_buffer_pool_dump_pct در MySQL را تنظیم می‌کند. به محض کامل شدن تخلیه buffer pool یا متوقف شدن آن (ببینید: --dump-innodb-buffer-pool-timeout)، مقدار متغیر سیستمی MySQL به حالت اولیه بازیابی می‌شود.

همچنین ببینید:

تغییر مهلت زمانی (timeout) برای تخلیه buffer pool
--dump-innodb-buffer-pool-timeout
مستندات MySQL: متغیر سیستمی innodb_buffer_pool_dump_pct
https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_buffer_pool_dump_pct
این گزینه به xtrabackup دستور می‌دهد تا نسخه‌های پشتیبان فایل‌های داده InnoDB را با استفاده از الگوریتم مشخص‌شده در ENCRYPTION_ALGORITHM رمزنگاری کند. الگوریتم‌های پشتیبانی‌شده کنونی عبارتند از: AES128، AES192 و AES256
یک کلید رمزنگاری با طول مناسب برای استفاده. استفاده از این گزینه در شرایطی که دسترسی کنترل‌نشده به سیستم وجود دارد توصیه نمی‌شود، زیرا خط فرمان و در نتیجه کلید رمزنگاری ممکن است به عنوان بخشی از اطلاعات فرایند قابل مشاهده باشد.
نام فایلی که کلید خام با طول مناسب می‌تواند از آن خوانده شود. این فایل باید یک فایل باینری (یا متنی) ساده باشد که دقیقاً حاوی کلید مورد استفاده است.

این مقدار مستقیماً به فرایند فرزند xtrabackup منتقل می‌شود. برای جزئیات بیشتر به مستندات xtrabackup مراجعه کنید.

این گزینه تعداد رشته‌های کاری (worker threads) را که برای رمزنگاری/رمزگشایی موازی استفاده خواهند شد مشخص می‌کند. برای جزئیات بیشتر به مستندات xtrabackup مراجعه کنید.
این گزینه اندازه بافر کاری داخلی را برای هر رشته رمزنگاری، بر حسب بایت مشخص می‌کند. این مقدار مستقیماً به فرایند فرزند xtrabackup منتقل می‌شود. برای جزئیات بیشتر به مستندات xtrabackup مراجعه کنید.
ایجاد فایل‌های لازم برای برون‌بری جدول‌ها. به بخش «بازیابی جدول‌های منفرد» مراجعه کنید.
(برای --backup): یک نسخه اضافی از فایل‌های xtrabackup_checkpoints و xtrabackup_info را در این دایرکتوری ذخیره می‌کند.
در صورت تعیین، گزینه‌های --copy-back و --move-back فایل‌ها را به دایرکتوری‌های غیرخالی انتقال می‌دهند. هیچ فایل موجودی رونویسی نخواهد شد. اگر فایل‌هایی که قرار است از دایرکتوری پشتیبان کپی/منتقل شوند از پیش در دایرکتوری مقصد وجود داشته باشند، عملیات همچنان با خطا مواجه خواهد شد.
این گزینه مدت زمانی را بر حسب ثانیه مشخص می‌کند که xtrabackup باید پیش از اجرای FLUSH TABLES WITH READ LOCK، منتظر پرس‌وجوهایی بماند که ممکن است مانع اجرای آن شوند. اگر پس از پایان این مهلت همچنان چنین پرس‌وجوهایی وجود داشته باشند، xtrabackup با یک خطا خاتمه می‌یابد. مقدار پیش‌فرض 0 است که در این حالت، منتظر اتمام پرس‌وجوها نمانده و بلافاصله FLUSH TABLES WITH READ LOCK را آغاز می‌کند. در صورت پشتیبانی، xtrabackup به‌طور خودکار از Backup Locks به عنوان یک جایگزین سبک‌تر برای FLUSH TABLES WITH READ LOCK جهت کپی داده‌های غیر InnoDB استفاده می‌کند تا از مسدود شدن پرس‌وجوهای DML که جدول‌های InnoDB را تغییر می‌دهند، جلوگیری شود.
این گزینه آستانه زمان اجرای پرس‌وجو را مشخص می‌کند که توسط xtrabackup برای تشخیص پرس‌وجوهای طولانی‌مدت در صورت غیرصفر بودن مقدار --ftwrl-wait-timeout به کار می‌رود. تا زمانی که چنین پرس‌وجوهای طولانی‌مدتی در حال اجرا باشند، دستور FLUSH TABLES WITH READ LOCK آغاز نخواهد شد. در صورتی که --ftwrl-wait-timeout برابر با 0 باشد، این گزینه هیچ اثری ندارد. مقدار پیش‌فرض 60 ثانیه است. در صورت پشتیبانی، xtrabackup به‌طور خودکار از Backup Locks به عنوان یک جایگزین سبک‌تر به جای FLUSH TABLES WITH READ LOCK برای کپی داده‌های غیر InnoDB استفاده می‌کند تا از مسدود شدن پرس‌وجوهای DML که جدول‌های InnoDB را تغییر می‌دهند جلوگیری شود.
این گزینه مشخص می‌کند کدام نوع از پرس‌وجوها مجاز هستند پیش از اعمال قفل سراسری توسط xtrabackup کامل شوند. مقدار پیش‌فرض all است.
این گزینه فایل xtrabackup_galera_info را ایجاد می‌کند که حاوی وضعیت گره محلی در زمان پشتیبان‌گیری است. این گزینه باید هنگام تهیه پشتیبان از Percona XtraDB Cluster استفاده شود. زمانی که از قفل‌های پشتیبان (backup locks) برای ایجاد نسخه پشتیبان استفاده شود، این گزینه هیچ اثری ندارد.
--generate-new-master-key تولید یک کلید اصلی جدید هنگام انجام copy-back.
برنامهٔ xtrabackup در طول prepare و copy-back نیاز به دسترسی به همان فایل keyring یا سرور vault دارد، اما نباید به این که کلیدهای سرور پاک‌سازی شده‌اند یا خیر وابسته باشد.

گزینهٔ --generate-transition-key یک کلید گذار (transition key) ایجاد کرده و به keyring اضافه می‌کند تا در صورتی که کلید اصلی استفاده‌شده برای رمزنگاری به دلیل چرخش و پاک‌سازی یافت نشد، xtrabackup از آن استفاده کند.

دریافت کلید عمومی سرور

همچنین ببینید:

مستندات MySQL: گزینهٔ --get-server-public-key
https://dev.mysql.com/doc/refman/5.7/en/connection-options.html#option_general_get-server-public-key
هنگام اجرا با این گزینه یا بدون هیچ گزینه‌ای، xtrabackup اطلاعاتی دربارهٔ نحوهٔ اجرای برنامه در خط فرمان به همراه تمامی گزینه‌ها و متغیرهای پشتیبانی‌شده و در صورت لزوم، مقادیر پیش‌فرض آن‌ها را نمایش می‌دهد.
این گزینه رهگیری تاریخچهٔ پشتیبان‌گیری را در جدول PERCONA_SCHEMA.xtrabackup_history فعال می‌کند. می‌توان یک نام اختیاری برای سری تاریخچه مشخص کرد که همراه با رکورد تاریخچه برای پشتیبان در حال تهیه، ثبت خواهد شد.
این گزینه یک آرگومان رشته‌ای می‌پذیرد که میزبان مورد استفاده هنگام اتصال به سرور پایگاه داده از طریق TCP/IP را مشخص می‌کند. این مقدار بدون تغییر به فرایند فرزند mysql ارسال می‌شود. برای جزئیات به mysql --help مراجعه کنید.
این گزینه به xtrabackup دستور می‌دهد تا یک پشتیبان افزایشی ایجاد کند. این گزینه به فرایند فرزند xtrabackup ارسال می‌شود. وقتی این گزینه مشخص شود، می‌توان یکی از گزینه‌های --incremental-lsn یا --incremental-basedir را نیز تعیین کرد. اگر هیچ‌یک از این گزینه‌ها داده نشود، گزینهٔ --incremental-basedir به‌طور پیش‌فرض به xtrabackup ارسال شده و روی اولین دایرکتوری دارای برچسب زمانی در دایرکتوری پایهٔ پشتیبان‌گیری تنظیم می‌شود.

همچنین ببینید:

اطلاعات بیشتر دربارهٔ پشتیبان‌گیری‌های افزایشی
بخش xb_incremental را ببینید
--incremental-basedir=DIRECTORY
هنگام ایجاد یک پشتیبان افزایشی، این همان دایرکتوری شامل پشتیبان کاملی است که مجموعه دادهٔ پایه برای پشتیبان‌های افزایشی محسوب می‌شود.
--incremental-dir=DIRECTORY
هنگام آماده‌سازی (prepare) یک پشتیبان افزایشی، این دایرکتوری محلی است که پشتیبان افزایشی با پشتیبان کامل در آن ترکیب می‌شود تا یک پشتیبان کامل جدید ساخته شود.
--incremental-force-scan
هنگام ایجاد یک پشتیبان افزایشی، پویش کامل (full scan) صفحات داده در نمونه‌ای که از آن پشتیبان گرفته می‌شود را اجبار می‌کند، حتی اگر داده‌های بیت‌مپ صفحات تغییریافته به‌طور کامل در دسترس باشد.
--incremental-history-name=name
این گزینه نام سریِ پشتیبان ذخیره‌شده در رکورد تاریخچهٔ PERCONA_SCHEMA.xtrabackup_history را برای پایه‌گذاری پشتیبان افزایشی بر روی آن مشخص می‌کند. xtrabackup در جدول تاریخچه به جستجوی تازه‌ترین (بالاترین innodb_to_lsn) پشتیبان موفق در این سری می‌پردازد و مقدار to_lsn را به عنوان lsn شروع برای پشتیبان افزایشی استفاده می‌کند. این گزینه با --incremental-history-uuid، --incremental-basedir و --incremental-lsn مانعة‌الجمع است. اگر هیچ lsn معتبری یافت نشود (سری با این نام وجود نداشته باشد، یا پشتیبان موفقی با این نام یافت نشود)، xtrabackup با خطا خارج می‌شود. این گزینه به همراه گزینهٔ --incremental استفاده می‌شود.
--incremental-history-uuid=name
این گزینه UUID رکورد تاریخچهٔ خاص ذخیره‌شده در PERCONA_SCHEMA.xtrabackup_history را برای پایه‌گذاری پشتیبان افزایشی مشخص می‌کند. این گزینه با --incremental-history-name، --incremental-basedir و --incremental-lsn مانعة‌الجمع است. اگر هیچ lsn معتبری یافت نشود (هیچ رکورد موفقی با آن UUID وجود نداشته باشد)، xtrabackup با خطا خارج می‌شود. این گزینه به همراه گزینهٔ --incremental استفاده می‌شود.
--incremental-lsn=LSN
هنگام ایجاد یک پشتیبان افزایشی، می‌توانید به جای مشخص کردن --incremental-basedir، شماره توالی لاگ (LSN) را مشخص کنید. برای پایگاه‌های دادهٔ ایجاد شده در نسخهٔ 5.1 و بالاتر، LSN را به صورت یک عدد صحیح ۶۴ بیتی مشخص کنید. توجه: اگر مقدار اشتباهی برای LSN مشخص شود (یک خطای کاربری که Percona XtraBackup قادر به تشخیص آن نیست)، پشتیبان غیرقابل استفاده خواهد شد. دقت کنید!
این گزینه برای سازگاری با گزینه‌های MySQL نادیده گرفته می‌شود.
گروه بزرگی از گزینه‌های InnoDB وجود دارد که معمولاً از فایل پیکربندی my.cnf خوانده می‌شوند تا xtrabackup موتور درون‌سازی‌شدهٔ InnoDB خود را با همان پیکربندی سرور فعلی شما راه‌اندازی کند. معمولاً نیازی به مشخص کردن صریح این گزینه‌ها ندارید. این گزینه‌ها در InnoDB و XtraDB رفتار یکسانی دارند:
  • --innodb-adaptive-hash-index
  • --innodb-additional-mem-pool-size
  • --innodb-autoextend-increment
  • --innodb-buffer-pool-size
  • --innodb-buffer-pool-filename
  • --innodb-checksum-algorithm
  • --innodb-checksums
  • --innodb-data-file-path
  • --innodb-data-home-dir
  • --innodb-directories
  • --innodb-doublewrite-file
  • --innodb-doublewrite
  • --innodb-extra-undoslots
  • --innodb-fast-checksum
  • --innodb-file-io-threads
  • --innodb-file-per-table
  • --innodb-flush-log-at-trx-commit
  • --innodb-flush-method
  • --innodb-io-capacity
  • --innodb-lock-wait-timeout
  • --innodb-log-block-size
  • --innodb-log-buffer-size
  • --innodb-log-checksums
  • --innodb-log-files-in-group
  • --innodb-log-file-size
  • --innodb-log-group-home-dir
  • --innodb-max-dirty-pages-pct.IP • 2 --innodb-open-files
  • --innodb-page-size
  • --innodb-read-io-threads
  • --innodb-redo-log-encrypt
  • --innodb-undo-directory
  • --innodb-undo-log-encrypt
  • --innodb-undo-tablespaces`
  • --innodb-use-native-aio
  • --innodb-write-io-threads
مسیر فایل keyring. این گزینه را همراه با --xtrabackup-plugin-dir به کار ببرید.
این گزینه تعداد ثانیه‌هایی را مشخص می‌کند که xtrabackup بین آغاز FLUSH TABLES WITH READ LOCK و کُشتن آن پرس‌وجوهایی که آن را مسدود می‌کنند، منتظر می‌ماند. پیش‌فرض 0 ثانیه است، به این معنی که xtrabackup تلاشی برای متوقف ساختن هیچ پرس‌وجویی نخواهد کرد. جهت استفاده از این گزینه، کاربر xtrabackup باید دارای مجوزهای PROCESS و SUPER باشد. در صورت پشتیبانی، xtrabackup به‌طور خودکار از Backup Locks به‌عنوان جایگزینی سبک برای FLUSH TABLES WITH READ LOCK جهت کپی داده‌های غیر InnoDB استفاده می‌کند تا از مسدود شدن پرس‌وجوهای DML که جداول InnoDB را تغییر می‌دهند، جلوگیری شود.
این گزینه مشخص می‌کند کدام نوع از پرس‌وجوها باید برای رفع انسداد قفل سراسری (global lock) کشته شوند. پیش‌فرض "select" است.
در صورت پشتیبانی توسط سرور، دستور LOCK TABLES FOR BACKUP (و در غیر این صورت LOCK INSTANCE FOR BACKUP) را در ابتدای پشتیبان‌گیری صادر می‌کند تا تمام عملیات‌های DDL مسدود شوند.

نکته:

پیش از Percona XtraBackup 8.0.22-15.0، استفاده از safe-slave-backup رشته رونوشت SQL را پس از پشتیبان‌گیری از جداول InnoDB و پیش از پشتیبان‌گیری از جداول غیر InnoDB متوقف می‌کرد.

از نسخه Percona XtraBackup 8.0.22-15.0 به بعد، استفاده از گزینه safe-slave-backup رشته رونوشت SQL را پیش از کپی کردن فایل‌های InnoDB متوقف می‌کند.

قفل کردن DDL برای هر جدول پیش از شروع کپی کردن آن توسط xtrabackup و تا زمان تکمیل پشتیبان‌گیری.

نکته:

از نسخه Percona XtraBackup 8.0.15 به بعد، گزینه --lock-ddl-per-table منسوخ شده است. به جای آن از گزینه --lock-ddl استفاده کنید.
اگر LOCK TABLES FOR BACKUP یا LOCK INSTANCE FOR BACKUP در مدت‌زمان تعیین‌شده پاسخ ندهد، فرایند پشتیبان‌گیری را متوقف می‌کند.
این گزینه برای MySQL نادیده گرفته می‌شود.
--log-bin
نام پایه برای توالی لاگ‌ها.
--log-bin-index=name
فایلی که نام فایل‌های گزارش باینری (binary log) را نگه می‌دارد.
--log-copy-interval=#
این گزینه بازه زمانی بین بررسی‌های انجام‌شده توسط رشته رونوشت لاگ را بر حسب میلی‌ثانیه مشخص می‌کند (پیش‌فرض ۱ ثانیه است).
مسیر مشخص‌شده را از فایل ورود (login file) می‌خواند.
انتقال تمام فایل‌های موجود در یک پشتیبان از قبل ایجاد شده از دایرکتوری پشتیبان به مکان‌های اصلی‌شان. از آنجا که این گزینه فایل‌های پشتیبان را حذف می‌کند، باید با احتیاط کامل استفاده شود.
گزینه --backup-locks را که به‌طور پیش‌فرض فعال است، صراحتاً غیرفعال می‌کند.
گزینه‌های پیش‌فرض فقط از فایل ورود (login file) خوانده می‌شوند.
از این گزینه برای غیرفعال کردن قفل جدول با FLUSH TABLES WITH READ LOCK استفاده کنید. تنها در صورتی از آن استفاده کنید که تمام جداول شما InnoDB باشند و شما به موقعیت لاگ باینری پشتیبان اهمیتی ندهید. در صورتی که هرگونه عبارت DDL در حال اجرا باشد یا هرگونه به‌روزرسانی روی جداول غیر InnoDB انجام شود (شامل جداول سیستمی MyISAM در پایگاه داده mysql)، نباید از این گزینه استفاده کرد، زیرا در غیر این صورت می‌تواند منجر به یک پشتیبان ناسازگار شود. در صورت پشتیبانی، xtrabackup به‌طور خودکار از Backup Locks به‌عنوان جایگزینی سبک برای FLUSH TABLES WITH READ LOCK جهت کپی داده‌های غیر InnoDB استفاده می‌کند تا از مسدود شدن پرس‌وجوهای DML که جداول InnoDB را تغییر می‌دهند جلوگیری شود. اگر به این دلیل قصد استفاده از این گزینه را دارید که پشتیبان‌گیری‌هایتان در دریافت قفل شکست می‌خورند، ممکن است به دلیل این باشد که رویدادهای replication ورودی مانع از موفقیت قفل می‌شوند. لطفاً با استفاده از --safe-slave-backup سعی کنید رشته replicaی replication را موقتاً متوقف کنید؛ این ممکن است به موفقیت پشتیبان‌گیری کمک کند و نیازی به استفاده از این گزینه نداشته باشید.
در Percona XtraBackup 8.0.21 پیاده‌سازی شده است.

گزینه --no-server-version-check بررسی نسخه سرور را غیرفعال می‌کند.

رفتار پیش‌فرض، بررسی‌ای را اجرا می‌کند که نسخه سیستم مبدأ را با نسخه Percona XtraBackup مقایسه می‌کند. اگر نسخه سیستم مبدأ بالاتر از نسخه XtraBackup باشد، پشتیبان‌گیری با پیامی لغو می‌شود.

افزودن این گزینه این بررسی را لغو (override) می‌کند و پشتیبان‌گیری ادامه می‌یابد، اما ممکن است مشکلاتی در پشتیبان وجود داشته باشد.

برای اطلاعات بیشتر بخش مقایسه (comparison) را ببینید.

این گزینه بررسی نسخه را غیرفعال می‌کند. اگر این گزینه را تعیین نکنید، هنگام اجرای xtrabackup در حالت --backup، بررسی خودکار نسخه به‌طور ضمنی فعال خواهد شد. برای غیرفعال کردن بررسی نسخه، باید هنگام فراخوانی xtrabackup صراحتاً گزینه --no-version-check را مشخص کنید.

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

  • نوع و نسخه MySQL
  • نام سیستم‌عامل
  • نسخه Percona Toolkit
  • نسخه Perl

هر بخش از اطلاعات دارای یک شناسه یکتا است. این مقدار، یک درهم‌سازی (هش) MD5 است که Percona Toolkit برای دریافت آمار درباره نحوه استفاده از آن بهره می‌برد. این شناسه یک UUID تصادفی است؛ هیچ اطلاعاتی از کلاینت جمع‌آوری یا ذخیره نمی‌شود.

حداکثر تعداد توصیف‌کننده‌های فایل (file descriptors) برای رزرو با ()setrlimit.
این گزینه تعداد رشته‌ها (threads) را برای کپی هم‌زمان چندین فایل داده هنگام ایجاد پشتیبان مشخص می‌کند. مقدار پیش‌فرض 1 است (یعنی بدون انتقال هم‌زمان). در Percona XtraBackup 2.3.10 و جدیدتر، این گزینه را می‌توان همراه با گزینه --copy-back برای کپی موازی فایل‌های داده کاربر به کار برد (لاگ‌های redo و فضاهای جدول سیستمی در رشته اصلی کپی می‌شوند).
این گزینه گذرواژه مورد استفاده هنگام اتصال به پایگاه داده را مشخص می‌کند. یک آرگومان رشته‌ای می‌پذیرد. برای جزئیات به mysql --help مراجعه کنید.
--plugin-load فهرست افزونه‌هایی که باید بارگذاری شوند.
این گزینه یک آرگومان رشته‌ای می‌پذیرد که درگاه مورد استفاده هنگام اتصال به سرور پایگاه داده از طریق TCP/IP را مشخص می‌کند. این مقدار بدون تغییر به فرآیند فرزند mysql منتقل می‌شود. برای جزئیات بیشتر به mysql --help مراجعه کنید.
باعث می‌شود xtrabackup روی پشتیبان ایجادشده با --backup بازیابی (recovery) انجام دهد تا آماده استفاده شود. به بخش آماده‌سازی پشتیبان (preparing a backup) مراجعه کنید.
فهرست آرگومان‌های برنامه را چاپ کرده و خارج می‌شود. باید به عنوان نخستین گزینه در خط فرمان مشخص شود.
باعث می‌شود xtrabackup پارامترهایی را چاپ کند که می‌توان از آن‌ها برای کپی کردن فایل‌های داده به مکان‌های اصلی‌شان به منظور بازیابی (restore) استفاده کرد.
اندازه بافر خواندن فایل داده (datafile) را تنظیم می‌کند؛ مقدار ارائه‌شده با اندازه صفحه (page size) همگام و تنظیم می‌شود. مقدار پیش‌فرض 10Mb است.
اندیس‌ها را در یک پشتیبان فشرده بازسازی می‌کند. این گزینه تنها زمانی اثر دارد که گزینه‌های --prepare و --rebuild-threads مشخص شده باشند.
از تعداد مشخصی از نخ‌ها (threads) برای بازسازی اندیس‌ها در یک پشتیبان فشرده استفاده می‌کند. این گزینه تنها همراه با گزینه‌های --prepare و --rebuild-indexes موثر است.
در Percona XtraBackup نسخه 2.4.6 پیاده‌سازی شده است؛ در صورت تعیین این گزینه، فایل‌های .qp، .xbcrypt و .qp.xbcrypt پس از رمزگشایی و خروج از حالت فشرده‌سازی حذف خواهند شد.
دایرکتوری داده‌های RocksDB.
دایرکتوری WAL برای RocksDB.
هنگام اتمام پشتیبان‌گیری، نقطه بازرسی (checkpoint) نباید بیش از این تعداد ثانیه قدیمی باشد.
پشتیبان‌گیری را تکمیل می‌کند حتی اگر شرط طول عمر نقطه بازرسی پس از این تعداد checkpoint برآورده نشده باشد.
برگرداندن اجباری (rollback) تراکنش‌های آماده‌شده‌ی (prepared) در InnoDB.
از ابزار rsync برای بهینه‌سازی انتقال محلی فایل‌ها استفاده می‌کند. با تعیین این گزینه، xtrabackup به جای اجرای یک فرآیند جداگانه cp برای هر فایل، از rsync برای رونوشت تمامی فایل‌های غیر InnoDB استفاده می‌کند که برای سرورهایی با تعداد زیادی پایگاه داده یا جدول می‌تواند بسیار سریع‌تر باشد. این گزینه نمی‌تواند همراه با --stream استفاده شود.
با تعیین این گزینه، xtrabackup دقیقاً پیش از اجرای FLUSH TABLES WITH READ LOCK نخ SQL رونوشت (replica) را متوقف کرده و برای شروع پشتیبان‌گیری منتظر می‌ماند تا Slave_open_temp_tables در دستور SHOW STATUS صفر شود. اگر هیچ جدول موقت بازی وجود نداشته باشد، پشتیبان‌گیری انجام می‌شود؛ در غیر این صورت نخ SQL به طور متناوب اجرا و متوقف می‌شود تا زمانی که هیچ جدول موقت بازی باقی نماند. چنانچه پس از گذشت --safe-slave-backup-timeout ثانیه مقدار Slave_open_temp_tables صفر نشود، پشتیبان‌گیری با شکست مواجه خواهد شد. با پایان پشتیبان‌گیری، نخ SQL همانندسازی مجدداً اجرا می‌شود. این گزینه به منظور مدیریت همانندسازی جدول‌های موقت پیاده‌سازی شده و در Row-Based-Replication نیازی به آن نیست.
مدت زمانی بر حسب ثانیه که --safe-slave-backup باید منتظر بماند تا مقدار Slave_open_temp_tables به صفر برسد. مقدار پیش‌فرض ۳۰۰ ثانیه است.
در صورت استفاده کلاینت از پروتکل قدیمی (پیش از 4.1.1)، اتصال آن را به سرور رد می‌کند. (به‌طور پیش‌فرض فعال است؛ برای غیرفعال کردن از --skip-secure-auth استفاده کنید.)
شناسه نمونه سروری که از آن پشتیبان‌گیری می‌شود.
مسیر فایل کلید عمومی RSA سرور در قالب PEM.

همچنین ببینید:

مستندات MySQL: گزینه --server-public-key-path
https://dev.mysql.com/doc/refman/8.0/en/connection-options.html#option_general_server-public-key-path
به --tables-compatibility-check مراجعه کنید.
این گزینه هنگام پشتیبان‌گیری از یک سرور رونوشت (replica) در سازوکار همانندسازی کاربرد دارد. این گزینه موقعیت binary log سرور مبدا را چاپ می‌کند. همچنین مختصات binary log را در قالب یک دستور CHANGE MASTER در فایل xtrabackup_slave_info ذخیره می‌کند. با راه‌اندازی یک سرور رونوشت بر اساس این پشتیبان و اجرای دستور CHANGE MASTER با استفاده از موقعیت binary log ذخیره‌شده در فایل xtrabackup_slave_info، می‌توان یک نسخه رونوشت جدید برای این مبدا راه‌اندازی کرد.
این گزینه یک آرگومان رشته‌ای می‌پذیرد که سوکت مورد استفاده برای اتصال به سرور پایگاه داده محلی از طریق یک UNIX domain socket را مشخص می‌کند. این مقدار بدون تغییر به فرآیند فرزند mysql منتقل می‌شود. برای جزئیات بیشتر به mysql --help مراجعه کنید.
فعال‌سازی اتصال امن. اطلاعات بیشتر در مستندات سرور MySQL ذیل گزینه --ssl در دسترس است.
--ssl-ca
مسیر فایلی که شامل فهرست CAهای معتبر SSL است. اطلاعات بیشتر در مستندات سرور MySQL ذیل گزینه --ssl-ca در دسترس است.
--ssl-capath
مسیر دایرکتوری حاوی گواهی‌های مرجع صدور گواهی (CA) معتبر SSL در قالب PEM. اطلاعات بیشتر در مستندات سرور MySQL ذیل گزینه --ssl-capath در دسترس است.
--ssl-cert
مسیر فایلی که شامل گواهی X509 در قالب PEM است. اطلاعات بیشتر در مستندات سرور MySQL ذیل گزینه --ssl-cert در دسترس است.
--ssl-cipher
فهرست رمزنگاری‌های (ciphers) مجاز جهت استفاده برای رمزنگاری ارتباط. اطلاعات بیشتر در مستندات سرور MySQL ذیل گزینه --ssl-cipher در دسترس است.
--ssl-crl
مسیر فایلی که شامل فهرست‌های ابطال گواهی (CRL) است. اطلاعات بیشتر در مستندات سرور MySQL ذیل گزینه --ssl-crl در دسترس است.
--ssl-crlpath مسیر دایرکتوری حاوی فایل‌های فهرست ابطال گواهی (certificate revocation list). اطلاعات بیشتر را می‌توان در مستندات سرور MySQL برای --ssl-crlpath یافت.
--ssl-fips-mode
حالت SSL FIPS (تنها برای OpenSSL اعمال می‌شود)؛ مقادیر مجاز عبارت‌اند از: OFF، ON و STRICT.
--ssl-key
مسیر فایلی که حاوی کلید X509 در قالب PEM است. اطلاعات بیشتر را می‌توان در مستندات سرور MySQL برای --ssl-key یافت.
--ssl-mode
وضعیت امنیتی اتصال به سرور. اطلاعات بیشتر را می‌توان در مستندات سرور MySQL برای --ssl-mode یافت.
--ssl-verify-server-cert
بررسی مقدار Common Name گواهی سرور در برابر نام میزبان (host name) استفاده‌شده هنگام اتصال به سرور. اطلاعات بیشتر را می‌توان در مستندات سرور MySQL برای --ssl-verify-server-cert یافت.
باعث می‌شود xtrabackup فایل‌های داده مشخص‌شده را پیمایش کرده و آمارهای نمایه (index statistics) را چاپ کند.
ارسال جریانی (stream) تمامی فایل‌های پشتیبان به خروجی استاندارد در قالب مشخص‌شده. در حال حاضر، این گزینه تنها از قالب xbstream پشتیبانی می‌کند.
اگر این گزینه مشخص شود، در صورت ارسال پارامترهای نامعتبر، xtrabackup با خطا متوقف می‌شود.
یک عبارت باقاعده که نام کامل جدول در قالب databasename.tablename با آن مطابقت داده می‌شود. در صورت تطابق نام، از جدول پشتیبان‌گیری می‌شود. به بخش پشتیبان‌گیری‌های جزئی (partial backups) مراجعه کنید.
هشدار سازگاری موتور را فعال می‌کند. مقدار پیش‌فرض ON است. برای غیرفعال کردن هشدار سازگاری موتور از --skip-tables-compatibility-check استفاده کنید.
فیلتر کردن نام جدول‌ها با استفاده از عبارت باقاعده (regexp). عملکردی مشابه --tables دارد، اما نام‌های منطبق از پشتیبان‌گیری استثنا می‌شوند. توجه داشته باشید که اولویت این گزینه بالاتر از --tables است.
فایلی حاوی یک نام جدول در هر سطر، در قالب databasename.tablename. پشتیبان‌گیری به جدول‌های مشخص‌شده محدود خواهد شد.
این گزینه دایرکتوری مقصد را برای پشتیبان‌گیری مشخص می‌کند. اگر دایرکتوری وجود نداشته باشد، xtrabackup آن را ایجاد می‌کند. اگر دایرکتوری وجود داشته و خالی باشد، xtrabackup با موفقیت انجام خواهد شد. با این حال، xtrabackup فایل‌های موجود را بازنویسی نخواهد کرد؛ بلکه با خطای سیستم‌عامل ۱۷، file exists با شکست مواجه می‌شود.

اگر این گزینه یک مسیر نسبی باشد، نسبت به دایرکتوری کاری فعلی که xtrabackup از آن اجرا شده است تفسیر می‌شود.

برای انجام پشتیبان‌گیری، در سطح سیستم‌فایل به مجوزهای READ، WRITE و EXECUTE برای دایرکتوری تعیین‌شده به‌عنوان مقدار --target-dir نیاز دارید.

دایرکتوری محل قرارگیری فایل‌های tablespace موقت؛ این مسیر می‌تواند مطلق باشد.
این گزینه تعداد تکه‌های (chunks) کپی‌شده در هر ثانیه را محدود می‌کند. اندازه هر تکه 10 MB است. برای محدود کردن پهنای باند به 10 MB/s، گزینه را روی 1 تنظیم کنید: --throttle=1.

همچنین ببینید:

اطلاعات بیشتر درباره نحوه محدودسازی نرخ پشتیبان‌گیری
throttling_backups
رمزنگار (cipher) مورد استفاده برای TLS v1.3.
نسخه TLS مورد استفاده؛ مقادیر مجاز عبارت‌اند از: TLSv1، TLSv1.1، TLSv1.2، TLSv1.3.
دایرکتوری مورد استفاده برای ذخیره فایل‌های موقت در طول پشتیبان‌گیری را مشخص می‌کند.
این گزینه برای امکان‌پذیر ساختن پردازش پشتیبان‌گیری بدون دسترسی به سرور keyring vault استفاده می‌شود. در این حالت، xtrabackup کلید رمزگذاری AES را از عبارت عبور مشخص‌شده مشتق کرده و از آن برای رمزگذاری کلیدهای tablespaceهای در حال پشتیبان‌گیری استفاده می‌کند.

اگر --transition-key فاقد هرگونه مقداری باشد، xtrabackup آن را درخواست خواهد کرد. همان عبارت عبور باید برای دستور --prepare نیز مشخص شود.

این گزینه بر میزان حافظه اختصاص‌یافته برای آماده‌سازی پشتیبان با --prepare، یا تحلیل آمارها با --stats تأثیر می‌گذارد. هدف آن مشابه innodb_buffer_pool_size است. این گزینه کارکرد مشابه گزینه هم‌نام در ابزار InnoDB Hot Backup شرکت Oracle ندارد. مقدار پیش‌فرض 100MB است، و در صورت داشتن حافظه در دسترس کافی، مقدار 1GB تا 2GB مقدار توصیه‌شده مناسبی است. مضارب با ذکر واحد پشتیبانی می‌شوند (مانند 1MB، 1M، 1GB، 1G).
این گزینه نام‌کاربری MySQL مورد استفاده هنگام اتصال به سرور را، در صورتی که کاربر فعلی نباشد، مشخص می‌کند. این گزینه یک آرگومان رشته‌ای می‌پذیرد. برای جزئیات به mysql --help مراجعه کنید.
نگاه کنید به --version
این گزینه نسخه xtrabackup را چاپ کرده و خارج می‌شود.
مسیر مطلق به دایرکتوری حاوی پلاگین keyring.

همچنین ببینید:

مستندات Percona Server for MySQL: پلاگین keyring_vault با Data at Rest Encryption
https://www.percona.com/doc/percona-server/LATEST/management/data_at_rest_encryption.html#keyring-vault-plugin
مستندات MySQL: استفاده از پلاگین مبتنی بر فایل keyring_file
https://dev.mysql.com/doc/refman/5.7/en/keyring-file-plugin.html
Percona LLC و/یا شرکت‌های وابسته به آن

2009-2022، Percona LLC و/یا شرکت‌های وابسته به آن

June 15, 2026 8.0