MARIADB-BINLOG(1) MariaDB Database System MARIADB-BINLOG(1)

mariadb-binlog - ابزاری برای پردازش فایل‌های لاگ باینری (mariadb-binlog اکنون یک پیوند نمادین به mariadb-binlog است)

mariadb-binlog [options] log_file ...

لاگ باینری سرور شامل فایل‌هایی حاوی “رویدادها” است که تغییرات اعمال‌شده در محتویات پایگاه‌داده را شرح می‌دهند. سرور این فایل‌ها را در قالب باینری می‌نویسد. برای نمایش محتویات آن‌ها در قالب متنی، از ابزار mariadb-binlog استفاده کنید. همچنین می‌توانید از mariadb-binlog برای نمایش محتویات فایل‌های relay log نوشته‌شده توسط سرور کارگزار (slave) در یک ساختار همانندسازی (replication) استفاده کنید، زیرا فایل‌های relay log قالبی یکسان با لاگ‌های باینری دارند.

دستور mariadb-binlog را می‌توان به این صورت فراخوانی کرد:

shell> mariadb-binlog [options] log_file ...

برای نمونه، جهت نمایش محتویات فایل لاگ باینری با نام binlog.000003، از این دستور استفاده کنید:

shell> mariadb-binlog binlog.0000003

خروجی شامل رویدادهای موجود در binlog.000003 است. برای ثبت لاگ مبتنی بر دستور (statement-based logging)، اطلاعات رویداد شامل دستور SQL، شناسه سروری که دستور روی آن اجرا شده، برچسب زمانی اجرای دستور، میزان زمان صرف‌شده و مواردی از این قبیل است. برای ثبت لاگ مبتنی بر ردیف (row-based logging)، رویداد به جای دستور SQL، تغییر ایجادشده در یک ردیف را نشان می‌دهد.

پیش از هر رویداد، کامنت‌های سرایند (header) قرار دارند که اطلاعات تکمیلی ارائه می‌دهند. به عنوان مثال:

# at 141
#100309  9:28:36 server id 123  end_log_pos 245
  Query thread_id=3350  exec_time=11  error_code=0

در سطر نخست، عدد پس از at موقعیت شروع رویداد را در فایل لاگ باینری نشان می‌دهد.

سطر دوم با تاریخ و زمانی آغاز می‌شود که نشان می‌دهد دستور در چه زمانی روی سرور مبدأ رویداد شروع به اجرا کرده است. در فرآیند replication، این برچسب زمانی به سرورهای slave منتقل می‌شود. server id همان مقدار server_id سروری است که رویداد در آن ایجاد شده است. end_log_pos نشان می‌دهد رویداد بعدی از کجا شروع می‌شود (یعنی موقعیت پایان رویداد فعلی + ۱). thread_id مشخص می‌کند کدام نخ (thread) رویداد را اجرا کرده است. exec_time مدت زمان صرف‌شده برای اجرای رویداد در سرور اصلی (master) است. در یک سرور کارگزار (slave)، این مقدار تفاضل زمان پایان اجرا در slave منهای زمان شروع اجرا در master است. این اختلاف به عنوان معیاری برای میزان تأخیر replication نسبت به master عمل می‌کند. error_code نتیجه اجرای رویداد را نشان می‌دهد. مقدار صفر به این معناست که هیچ خطایی رخ نداده است.

خروجی حاصل از mariadb-binlog می‌تواند دوباره اجرا شود (برای مثال، با استفاده از آن به عنوان ورودی برای mariadb) تا دستورات موجود در لاگ دوباره اعمال شوند. این قابلیت برای عملیات بازیابی پس از خرابی ناگهانی سرور (crash) بسیار کاربردی است. برای نمونه‌های دیگرِ نحوه استفاده، به توضیحات بعدی در این بخش مراجعه کنید.

به طور معمول، از mariadb-binlog برای خواندن مستقیم فایل‌های لاگ باینری و اعمال آن‌ها بر روی سرور محلی MariaDB استفاده می‌شود. همچنین خواندن لاگ‌های باینری از یک سرور راه‌دور با استفاده از گزینه --read-from-remote-server امکان‌پذیر است. برای خواندن لاگ‌های باینری راه‌دور، می‌توان گزینه‌های پارامتر اتصال را برای تعیین نحوه اتصال به سرور مشخص کرد. این گزینه‌ها عبارتند از --host، --password، --port، --protocol، --socket و --user؛ این گزینه‌ها نادیده گرفته می‌شوند، مگر این‌که از گزینه --read-from-remote-server نیز استفاده شود.

ابزار mariadb-binlog از گزینه‌های زیر پشتیبانی می‌کند، که می‌توان آن‌ها را در خط فرمان یا در گروه‌های [mariadb-binlog] و [client] فایل‌های تنظیمات مشخص کرد.

•--help, -?

نمایش پیام راهنما و خروج.

•--base64-output=value

این گزینه مشخص می‌کند چه زمانی رویدادها باید با استفاده از دستورات BINLOG به صورت رشته‌های کدگذاری‌شده base-64 نمایش داده شوند. این گزینه مقادیر مجاز زیر را می‌پذیرد (به حروف بزرگ و کوچک حساس نیست):

•AUTO («خودکار») یا UNSPEC («نامشخص») در صورت نیاز دستورات BINLOG را به طور خودکار نمایش می‌دهد (یعنی برای رویدادهای شرح قالب و رویدادهای ردیف). اگر گزینه‌ی --base64-output مشخص نشده باشد، این مقدار پیش‌فرض است.

نکته
نمایش خودکار BINLOG تنها رفتار امن است چنانچه قصد داشته باشید از خروجی mariadb-binlog برای اجرای مجدد محتویات فایل لاگ باینری استفاده کنید. سایر مقادیر این گزینه صرفاً برای اهداف اشکال‌زدایی یا آزمایشی در نظر گرفته شده‌اند زیرا ممکن است خروجی‌ای تولید کنند که شامل تمام رویدادها در قالب قابل اجرا نباشد..sp .5v
•مقدار NEVER باعث می‌شود دستورهای BINLOG نمایش داده نشوند. اگر رویداد سطری یافت شود که برای نمایش به BINLOG نیاز دارد، mariadb-binlog با خطا خارج می‌شود.
•مقدار DECODE-ROWS به mariadb-binlog مشخص می‌کند که قصد دارید رویدادهای سطر رمزگشایی شده و همراه با مشخص کردن گزینهٔ --verbose به‌صورت دستورهای SQL کامنت‌شده نمایش داده شوند. مانند NEVER، مقدار DECODE-ROWS نمایش دستورهای BINLOG را متوقف می‌کند، اما برعکس NEVER، در صورت یافتن رویداد سطر با خطا خارج نمی‌شود.
گزینهٔ --base64-output می‌تواند به‌صورت --base64-output یا --skip-base64-output (به مفهوم AUTO یا NEVER) داده شود.

برای نمونه‌هایی که تأثیر --base64-output و --verbose را بر خروجی رویداد سطر نشان می‌دهند، بخش “MARIADB-BINLOG ROW EVENT DISPLAY” را ببینید.

•--binlog-row-event-max-size=path

دایرکتوری‌ای که مجموعه‌نویسه‌ها در آن نصب شده‌اند.

•--character-sets-dir=path

دایرکتوری‌ای که مجموعه‌نویسه‌ها در آن نصب شده‌اند.

•--database=db_name, -d db_name

این گزینه باعث می‌شود mariadb-binlog ورودی‌هایی از گزارش دودویی (فقط گزارش محلی) را خروجی دهد که در زمان انتخاب db_name به‌عنوان پایگاه‌دادهٔ پیش‌فرض با دستور USE رخ داده‌اند.

گزینهٔ --database برای mariadb-binlog مشابه گزینهٔ --binlog-do-db برای mariadbd است، اما تنها می‌تواند برای مشخص کردن یک پایگاه‌داده به کار رود. اگر --database چندین بار مشخص شود، تنها آخرین مورد استفاده می‌شود.

اثرات این گزینه به این بستگی دارد که قالب گزارش‌گیری مبتنی بر دستور (statement-based) به کار رفته باشد یا مبتنی بر سطر (row-based)، درست همان‌طور که اثرات --binlog-do-db به استفاده از گزارش‌گیری مبتنی بر دستور یا مبتنی بر سطر وابسته است.

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

•تا زمانی که db_name پایگاه‌دادهٔ پیش‌فرض است، دستورها خروجی داده می‌شوند، چه جدول‌ها را در db_name تغییر دهند چه در یک پایگاه‌دادهٔ دیگر.
•مگر اینکه db_name به‌عنوان پایگاه‌دادهٔ پیش‌فرض انتخاب شده باشد، دستورها در خروجی نشان داده نمی‌شوند، حتی اگر جدول‌ها را در db_name تغییر دهند.
•یک استثنا برای CREATE DATABASE، ALTER DATABASE و DROP DATABASE وجود دارد. هنگام تعیین اینکه آیا دستور در خروجی قرار گیرد یا خیر، پایگاه‌داده‌ای که ایجاد، اصلاح یا حذف می‌شود به‌عنوان پایگاه‌دادهٔ پیش‌فرض در نظر گرفته می‌شود.
فرض کنید گزارش دودویی با اجرای این دستورها با استفاده از گزارش‌گیری مبتنی بر دستور (statement-based logging) ایجاد شده است:
INSERT INTO test.t1 (i) VALUES(100); INSERT INTO db2.t2 (j) VALUES(200); USE test; INSERT INTO test.t1 (i) VALUES(101); INSERT INTO t1 (i) VALUES(102); INSERT INTO db2.t2 (j) VALUES(201); USE db2; INSERT INTO test.t1 (i) VALUES(103); INSERT INTO db2.t2 (j) VALUES(202); INSERT INTO t2 (j) VALUES(203);

دستور mariadb-binlog --database=test دو دستور نخست INSERT را خروجی نمی‌دهد زیرا هیچ پایگاه داده پیش‌فرضی وجود ندارد. این دستور سه دستور INSERT پس از USE test را در خروجی می‌آورد، اما سه دستور INSERT پس از USE db2 را خروجی نمی‌دهد.

دستور mariadb-binlog --database=db2 دو دستور نخست INSERT را خروجی نمی‌دهد زیرا هیچ پایگاه داده پیش‌فرضی وجود ندارد. این دستور سه دستور INSERT پس از USE test را خروجی نمی‌دهد، اما سه دستور INSERT پس از USE db2 را در خروجی می‌آورد.

ثبت وقایع مبتنی بر ردیف (Row-based logging). دستور mariadb-binlog تنها ورودی‌هایی را خروجی می‌دهد که جدول‌های متعلق به db_name را تغییر می‌دهند. پایگاه داده پیش‌فرض هیچ تاثیری بر این موضوع ندارد. فرض کنید گزارش باینری (binary log) شرح داده‌شده، به جای ثبت وقایع مبتنی بر دستور (statement-based logging)، با استفاده از ثبت وقایع مبتنی بر ردیف ایجاد شده باشد. دستور mariadb-binlog --database=test صرف‌نظر از اینکه USE اجرا شده باشد یا پایگاه داده پیش‌فرض چه باشد، تنها آن ورودی‌هایی را خروجی می‌دهد که t1 را در پایگاه داده test تغییر می‌دهند. اگر سروری در حالی در حال اجرا است که binlog_format روی MIXED تنظیم شده و می‌خواهید امکان استفاده از mariadb-binlog با گزینه --database فراهم باشد، باید اطمینان حاصل کنید جدول‌هایی که تغییر می‌یابند در پایگاه داده انتخاب‌شده توسط USE قرار دارند. (به‌ویژه نباید از به‌روزرسانی‌های بین پایگاه‌داده‌ای [cross-database updates] استفاده شود.)


نکته
این گزینه پیش از MySQL 5.1.37 برای mariadb-binlog با ثبت وقایع مبتنی بر ردیف به درستی کار نمی‌کرد.
•--debug[=debug_options], -# [debug_options]

یک لاگ اشکال‌زدایی می‌نویسد. یک رشته معمول برای debug_options به صورت 'd:t:o,file_name' است. مقدار پیش‌فرض 'd:t:o,/tmp/mariadb-binlog.trace' است.

•--debug-check

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

•--debug-info

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

•--defaults-extra-file=name

این فایل را پس از خوانده شدن فایل‌های سراسری (global) می‌خواند.

•--defaults-file=name

گزینه‌های پیش‌فرض را تنها از فایل داده‌شده می‌خواند.

•--default-auth=name

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

•--disable-log-bin, -D.sp غیرفعال‌سازی ثبت وقایع باینری (binary logging). این ویژگی برای جلوگیری از ایجاد یک حلقهٔ بی‌پایان در صورتی که از گزینهٔ --to-last-log استفاده کرده و خروجی را به همان سرور MariaDB ارسال می‌کنید، مفید است. همچنین این گزینه هنگام بازیابی پس از خرابی (crash) به منظور جلوگیری از تکرار دستوراتی که ثبت کرده‌اید، سودمند است.

این گزینه نیازمند داشتن امتیاز SUPER است. این امر باعث می‌شود که mariadb-binlog دستور SET sql_log_bin = 0 را در خروجی خود بگنجاند تا ثبت وقایع باینری برای باقی‌ماندهٔ خروجی غیرفعال گردد. دستور SET بی‌اثر خواهد بود مگر اینکه امتیاز SUPER را داشته باشید.

•--flashback, -B

پشتیبانی از حالت بازگشت به عقب (flashback mode).

•--force-if-open

اجبار در صورتی که binlog به درستی بسته نشده باشد. به‌طور پیش‌فرض فعال است؛ برای غیرفعال‌سازی از --skip-force-if-open استفاده کنید.

•--force-read, -f

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

•--hexdump, -H

نمایش رونوشت شانزده‌شانزدهی (hex dump) لاگ در کامنت‌ها، همان‌طور که در بخش “MARIADB-BINLOG HEX DUMP FORMAT” شرح داده شده است. این خروجی هگز می‌تواند برای اشکال‌زدایی همانندسازی (replication) مفید باشد.

•--host=host_name, -h host_name

دریافت لاگ باینری از سرور MariaDB روی میزبان (host) مشخص‌شده.

•--local-load=path, -l path

آماده‌سازی فایل‌های موقت محلی برای LOAD DATA INFILE در دایرکتوری مشخص‌شده.

•--no-defaults

عدم خواندن گزینه‌های پیش‌فرض از هیچ فایل تنظیماتی (option file).

•--offset=N, -o N

نادیده گرفتن نخستین N مدخل در لاگ.

•--open-files-limit=NUM

تنظیم متغیر open_files_limit، که برای رزرو توصیف‌کننده‌های فایل (file descriptors) برای mariadb-binlog استفاده می‌شود.

•--password[=password], -p[password].sp گذرواژه مورد استفاده هنگام اتصال به سرور. اگر از شکل کوتاه گزینه (-p) استفاده می‌کنید، نباید بین گزینه و گذرواژه فاصله بگذارید. اگر مقدار password را پس از گزینهٔ --password یا -p در خط فرمان وارد نکنید، mariadb-binlog آن را از شما درخواست می‌کند.

مشخص کردن گذرواژه در خط فرمان باید ناامن تلقی شود. می‌توانید از یک فایل گزینه استفاده کنید تا از ارائه گذرواژه در خط فرمان خودداری شود.

•--plugin-dir=dir_name

دایرکتوری افزونه‌های سمت کلاینت.

•--print-defaults

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

•--port=port_num, -P port_num

شماره پورت TCP/IP مورد استفاده برای اتصال به سرور راه‌دور، یا 0 برای پیش‌فرض، به ترتیب اولویت: my.cnf، $MYSQL_TCP_PORT، /etc/services، پیش‌فرض توکار (3306). اگر در خط فرمان بدون سایر ویژگی‌های اتصال مشخص شود، --protocol=tcp را اجباری می‌کند.

•--protocol={TCP|SOCKET|PIPE|MEMORY}

پروتکل اتصال مورد استفاده برای اتصال به سرور. این گزینه زمانی مفید است که سایر پارامترهای اتصال معمولاً باعث شوند پروتکلی به غیر از پروتکل مورد نظر شما استفاده شود.

•--raw

نیازمند -R است. خروجی دادن داده‌های خام binlog به‌جای دستورهای SQL. نام‌گذاری فایل‌های خروجی بر اساس لاگ‌های سرور انجام می‌شود.

•--read-from-remote-server, -R

خواندن لاگ باینری از یک سرور MariaDB به‌جای خواندن یک فایل لاگ محلی. هر گزینه از پارامترهای اتصال نادیده گرفته می‌شود مگر اینکه این گزینه نیز داده شده باشد. این گزینه‌ها عبارتند از --host، --password، --port، --protocol، --socket و --user.

این گزینه نیازمند در حال اجرا بودن سرور راه‌دور است. این گزینه تنها برای فایل‌های لاگ باینری روی سرور راه‌دور کار می‌کند، نه فایل‌های relay log.

•--result-file=name, -r name

هدایت خروجی به فایل مشخص‌شده. همراه با --raw این یک پیشوند برای نام‌های فایل است.

•--rewrite-db=name, -r name

اعمال به‌روزرسانی‌ها روی پایگاه داده‌ای با نامی متفاوت از نام اصلی. مثال: rewrite-db='from->to'. برای رویدادهایی که به صورت دستورها در binlog ثبت شده‌اند، بازنویسی پایگاه داده شامل تغییر پایگاه داده پیش‌فرض یک دستور از db1 به db2 است. هیچ تحلیل یا بازنویسی دستوری از هیچ نوعی صورت نمی‌گیرد؛ یعنی اگر کسی به صراحت "db1.tbl" را در دستور مشخص کند، آن مورد به "db2.tbl" تغییر نخواهد کرد. رویدادهای مبتنی بر سطر (Row-based events) به درستی بازنویسی می‌شوند تا از نام جدید پایگاه داده استفاده کنند. پالایش (برای مثال با --database=name) پس از انجام بازنویسی‌های پایگاه داده انجام می‌شود. اگر از این گزینه در خط فرمان استفاده می‌کنید و ">" برای مفسر فرمان شما معنای خاصی دارد، مقدار را درون علامت نقل‌قول قرار دهید (مانند --rewrite-db="oldname->newname".

•--server-id=id

تنها رویدادهایی را نمایش می‌دهد که توسط سروری با شناسه سرور (server ID) داده‌شده ایجاد شده‌اند.

•--set-charset=charset_name

یک عبارت SET NAMES charset_name را به خروجی اضافه می‌کند تا مجموعه‌نویسهٔ مورد استفاده برای پردازش فایل‌های گزارش را مشخص کند.

•--short-form، -s

تنها دستورات موجود در گزارش را بدون اطلاعات اضافی و بدون رویدادهای مبتنی بر سطر (row-based events) نمایش می‌دهد. این گزینه صرفاً برای آزمایش است و نباید در سامانه‌های عملیاتی استفاده شود. اگر می‌خواهید از تولید خروجی base64 جلوگیری کنید، در عوض استفاده از --base64-output=never را مد نظر قرار دهید.

•--socket=path، -S path

برای اتصال‌ها به localhost، فایل سوکت یونیکس مورد استفاده، یا در Windows، نام لولهٔ نام‌گذاری‌شده (named pipe) را مشخص می‌کند. در صورتی که بدون سایر مشخصات اتصال در خط فرمان تعیین شود، گزینهٔ --protocol=socket را اجبار می‌کند؛ در Windows، گزینهٔ --protocol=pipe را اجبار می‌کند.

•--start-datetime=datetime

خواندن گزارش دودویی را از نخستین رویدادی آغاز می‌کند که برچسب زمانی آن برابر یا پس از آرگومان datetime باشد. مقدار datetime نسبت به منطقهٔ زمانی محلی ماشینی است که mariadb-binlog را در آن اجرا می‌کنید. این مقدار باید در قالبی باشد که برای انواع دادهٔ DATETIME یا TIMESTAMP پذیرفته می‌شود. برای نمونه:

shell> mariadb-binlog --start-datetime="2014-12-25 11:25:56" binlog.000003

این گزینه برای بازیابی در نقطهٔ زمانی (point-in-time recovery) مفید است.

•--start-position=N، -j N

خواندن گزارش دودویی را از N آغاز می‌کند. نوع می‌تواند یک عدد صحیح مثبت یا فهرستی از GTID باشد. هنگام استفاده از عدد صحیح مثبت، مقدار تعیین‌شده تنها بر نخستین binlog ارائه‌شده در خط فرمان اعمال می‌شود و اولین رویدادی که موقعیتی برابر یا بزرگ‌تر از N داشته باشد چاپ می‌شود. در حالت GTID، می‌توان چندین GTID را به‌صورت فهرستی جداشده با کاما ارسال کرد که هرکدام باید یک شناسهٔ دامنه (domain id) یکتا داشته باشند. این فهرست وضعیت gtid binlog را نشان می‌دهد که کلاینت (یک کارگزار «slave» دیگر) از آن آگاه است. بنابراین، هر GTID انحصاری است؛ تنها رویدادهای پس از یک شمارهٔ دنباله مشخص چاپ می‌شوند تا به کاربران اجازه دهد رویدادهای پس از وضعیت فعلی خود را دریافت کنند.

این گزینه برای بازیابی در نقطهٔ زمانی (point-in-time recovery) مفید است.

•--gtid-strict-mode

گزارش binlog را بر اساس مشخصات gtid-strict-mode پردازش می‌کند. موقعیت‌های شروع (start) و پایان (stop) بررسی می‌شوند تا شرط مقایسه‌ای start < stop برقرار باشد. شماره‌های دنباله در هر دامنهٔ gtid باید یک دنبالهٔ یکنواخت صعودی را تشکیل دهند.

•--stop-datetime=datetime

خواندن گزارش دودویی را در نخستین رویدادی متوقف می‌کند که برچسب زمانی آن برابر یا پس از آرگومان datetime باشد. این گزینه برای بازیابی در نقطهٔ زمانی (point-in-time recovery) مفید است. برای اطلاعات بیشتر دربارهٔ مقدار datetime، توضیحات مربوط به گزینهٔ --start-datetime را مشاهده کنید.

این گزینه برای بازیابی در نقطهٔ زمانی (point-in-time recovery) مفید است.

•--stop-never

به جای توقف در انتهای آخرین گزارش، منتظر دریافت داده‌های بیشتر از کارگزار می‌ماند. این گزینه مستلزم --to-last-log است.

•--stop-never-slave-server-id

شناسهٔ server_id مربوط به کارگزار slave که برای --read-from-remote-server --stop-never به کار می‌رود.

•--stop-position=N

خواندن لاگ باینری را در نخستین رویدادی که موقعیت آن برابر یا بزرگ‌تر از N باشد متوقف می‌کند. نوع می‌تواند یک عدد صحیح مثبت یا فهرستی از GTID باشد. هنگام استفاده از یک عدد صحیح مثبت، این مقدار تنها برای آخرین فایل لاگ مشخص‌شده در خط فرمان اعمال می‌شود. در حالت GTID، چندین GTID می‌توانند به‌صورت یک فهرست جداشده با کاما ارسال شوند، که هرکدام باید یک domain id یکتا داشته باشند. هر GTID شامل‌شونده (inclusive) است؛ تنها رویدادها تا شماره‌های توالی داده‌شده چاپ می‌شوند.

این گزینه برای بازیابی نقطه در زمان (point-in-time recovery) مفید است.

•--table, -T

ورودی‌های مربوط به فقط همین جدول را فهرست می‌کند (تنها برای لاگ محلی).

• --to-last-log, -t

در پایان لاگ باینریِ درخواست‌شده از کارساز MariaDB متوقف نمی‌شود، بلکه به چاپ کردن تا انتهای آخرین لاگ باینری ادامه می‌دهد. اگر خروجی را به همان کارساز MariaDB ارسال کنید، ممکن است منجر به یک حلقهٔ بی‌پایان شود، بنابراین این گزینه نیازمند --read-from-remote-server است.

•--user=user_name, -u user_name

نام‌کاربری MariaDB جهت استفاده هنگام اتصال به یک کارساز دوردست.

•--verbose, -v

رویدادهای سطر (row events) را بازسازی کرده و آن‌ها را به‌صورت دستورهای کامنت‌شدهٔ SQL نمایش می‌دهد. اگر این گزینه دو بار داده شود، خروجی شامل کامنت‌هایی برای نشان دادن نوع‌داده‌های ستون و برخی فراداده‌ها (metadata) خواهد بود. اگر این گزینه سه بار داده شود، خروجی شامل هشدارهای تشخیصی دربارهٔ یکپارچگی رویداد پیش از خروج از برنامه خواهد بود.

برای مثال‌هایی که تأثیر --base64-output و --verbose را بر روی خروجی رویداد سطر نشان می‌دهند، بخش “MARIADB-BINLOG ROW EVENT DISPLAY” را ببینید.

•--version, -V

اطلاعات نسخه را نمایش داده و خارج می‌شود.

همچنین می‌توانید متغیر زیر را با استفاده از ساختار --var_name=value تنظیم کنید:

•open_files_limit

تعداد توصیف‌کننده‌های فایل (file descriptors) باز را برای رزرو مشخص می‌کند.

می‌توانید خروجی mariadb-binlog را به کلاینت mariadb هدایت کنید (pipe) تا رویدادهای موجود در لاگ باینری را اجرا کند. این روش برای بازیابی پس از خرابی (crash) هنگامی که یک پشتیبان قدیمی دارید استفاده می‌شود. برای نمونه:

shell> mariadb-binlog binlog.000001 | mariadb -u root -p

یا:

shell> mariadb-binlog binlog.[0-9]* | mariadb -u root -p

همچنین اگر نیاز دارید ابتدا لاگ دستورها را ویرایش کنید (برای نمونه، جهت حذف دستورهایی که به دلایلی نمی‌خواهید اجرا شوند)، می‌توانید خروجی mariadb-binlog را به یک فایل متنی بازهدایت کنید. پس از ویرایش فایل، با استفاده از آن به عنوان ورودی برنامهٔ mariadb دستورهای موجود در آن را اجرا کنید:

shell> mariadb-binlog binlog.000001 > tmpfile
shell> ... edit tmpfile ...
shell> mariadb -u root -p < tmpfile

هنگامی که mariadb-binlog با گزینهٔ --start-position فراخوانی شود، تنها رویدادهایی را با آفست در لاگ باینری بزرگ‌تر یا برابر با موقعیت داده‌شده نمایش می‌دهد (موقعیت داده‌شده باید با شروع یک رویداد مطابقت داشته باشد). این ابزار همچنین گزینه‌هایی برای توقف و شروع هنگام دیدن رویدادی با تاریخ و زمان معین دارد. این امر شما را قادر می‌سازد با استفاده از گزینهٔ --stop-datetime بازیابی نقطه در زمان (point-in-time recovery) انجام دهید (تا بتوانید برای مثال بگویید: “پایگاه‌های داده‌ام را به وضعیتی که امروز ساعت ۱۰:۳۰ صبح بودند بازگردان”)..PP اگر بیش از یک لاگ باینری (binary log) برای اجرا روی سرور MariaDB دارید، روش امن این است که همهٔ آن‌ها را با استفاده از یک اتصال واحد به سرور پردازش کنید. در اینجا مثالی آمده است که نشان می‌دهد چه کاری ممکن است ناامن باشد:

shell> mariadb-binlog binlog.000001 | mariadb -u root -p # DANGER!!
shell> mariadb-binlog binlog.000002 | mariadb -u root -p # DANGER!!

پردازش لاگ‌های باینری به این روش با استفاده از اتصال‌های مجزا به سرور، در صورتی که نخستین فایل لاگ حاوی یک دستور CREATE TEMPORARY TABLE باشد و لاگ دوم حاوی دستوری باشد که از این جدول موقت استفاده می‌کند، باعث بروز مشکل می‌شود. هنگامی که نخستین فرآیند mariadb پایان می‌یابد، سرور جدول موقت را حذف می‌کند. با تلاش دومین فرآیند mariadb برای استفاده از این جدول، سرور خطای “unknown table.” را گزارش می‌دهد.

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

shell> mariadb-binlog binlog.000001 binlog.000002 | mariadb -u root -p

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

shell> mariadb-binlog binlog.000001 >  /tmp/statements.sql
shell> mariadb-binlog binlog.000002 >> /tmp/statements.sql
shell> mariadb -u root -p -e "source /tmp/statements.sql"

دستور mariadb-binlog می‌تواند خروجی‌ای تولید کند که یک عملیات LOAD DATA INFILE را بدون نیاز به فایل دادهٔ اصلی بازتولید نماید. mariadb-binlog داده‌ها را در یک فایل موقت کپی کرده و یک دستور LOAD DATA LOCAL INFILE می‌نویسد که به آن فایل ارجاع دارد. مکان پیش‌فرض دایرکتوری‌ای که این فایل‌ها در آن نوشته می‌شوند مختص هر سیستم است. برای مشخص کردن صریح یک دایرکتوری، از گزینهٔ --local-load استفاده کنید.

از آنجا که mariadb-binlog دستورهای LOAD DATA INFILE را به دستورهای LOAD DATA LOCAL INFILE تبدیل می‌کند (یعنی LOCAL را اضافه می‌کند)، هم کلاینت و هم سروری که برای پردازش این دستورها به کار می‌گیرید باید به‌گونه‌ای پیکربندی شده باشند که قابلیت LOCAL در آن‌ها فعال باشد.


هشدار

فایل‌های موقت ایجادشده برای دستورهای LOAD DATA LOCAL به‌طور خودکار حذف نمی‌شوند زیرا تا زمانی که این دستورها را واقعاً اجرا نکنید، به آن‌ها نیاز است. پس از اینکه دیگر به لاگ دستورها نیازی نداشتید، باید فایل‌های موقت را خودتان حذف کنید. این فایل‌ها در دایرکتوری فایل‌های موقت قرار دارند و نام‌هایی مانند original_file_name-#-# دارند.

گزینهٔ --hexdump باعث می‌شود که mariadb-binlog یک دامپ هگز از محتویات لاگ باینری تولید کند:

shell> mariadb-binlog --hexdump master-bin.000001

خروجی هگز شامل خطوط توضیحی است که با # آغاز می‌شوند، بنابراین خروجی برای دستور پیشین ممکن است به این صورت باشد:

/*!40019 SET @@session.max_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#051024 17:24:13 server id 1  end_log_pos 98
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags
# 00000004 9d fc 5c 43   0f   01 00 00 00   5e 00 00 00   62 00 00 00   00 00
# 00000017 04 00 35 2e 30 2e 31 35  2d 64 65 62 75 67 2d 6c |..5.0.15.debug.l|
# 00000027 6f 67 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |og..............|
# 00000037 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
# 00000047 00 00 00 00 9d fc 5c 43  13 38 0d 00 08 00 12 00 |.......C.8......|
# 00000057 04 04 04 04 12 00 00 4b  00 04 1a                |.......K...|
#       Start: binlog v 4, server v 5.0.15-debug-log created 051024 17:24:13
#       at startup
ROLLBACK;

خروجی دامپ هگز در حال حاضر شامل موارد فهرست زیر است. این قالب ممکن است تغییر کند. (برای اطلاعات بیشتر دربارهٔ قالب لاگ باینری، ببینید: http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log.)

•Position: موقعیت بایتی در فایل لاگ.
•Timestamp: برچسب زمانی رویداد. در مثال نمایش‌داده‌شده، '9d fc 5c 43' نمایش '051024 17:24:13' در قالب شانزده‌شانزدهی (هگزادسیمال) است.
•Type: کد نوع رویداد. در مثال نمایش‌داده‌شده، '0f' نشان‌دهندهٔ یک FORMAT_DESCRIPTION_EVENT است. جدول زیر کدهای نوع ممکن را فهرست می‌کند.
نوع نام مفهوم
00 UNKNOWN_EVENT این رویداد هرگز نباید در لاگ وجود داشته باشد.
01 START_EVENT_V3 نشان‌دهندهٔ آغاز یک فایل لاگ نوشته‌شده توسط MySQL 4 یا پیش از آن است.
02 QUERY_EVENT رایج‌ترین نوع رویدادها. این‌ها حاوی دستورهای اجراشده روی master هستند.
03 STOP_EVENT نشان می‌دهد که سرور master متوقف شده است.
04 ROTATE_EVENT زمانی نوشته می‌شود که سرور master به یک فایل لاگ جدید منتقل شود.
05 INTVAR_EVENT برای مقادیر AUTO_INCREMENT یا هنگامی که از تابع LAST_INSERT_ID() در دستور استفاده شده باشد، به کار می‌رود.
06 LOAD_EVENT برای LOAD DATA INFILE در MySQL 3.23 استفاده می‌شود.
07 SLAVE_EVENT برای استفاده در آینده رزرو شده است.
08 CREATE_FILE_EVENT برای دستورهای LOAD DATA INFILE استفاده می‌شود. این رویداد آغاز اجرای چنین دستوری را نشان می‌دهد. یک فایل موقت روی slave ایجاد می‌شود. تنها در MySQL 4 استفاده می‌شود.
09 APPEND_BLOCK_EVENT حاوی داده‌ها برای استفاده در یک دستور LOAD DATA INFILE است. این داده‌ها در فایل موقت روی slave ذخیره می‌شوند.
0a EXEC_LOAD_EVENT برای دستورهای LOAD DATA INFILE استفاده می‌شود. محتویات فایل موقت در جدول روی slave ذخیره می‌شود. تنها در MySQL 4 استفاده می‌شود.
0b DELETE_FILE_EVENT بازگردانی (Rollback) یک دستور LOAD DATA INFILE. فایل موقت باید روی slave حذف شود.
0c NEW_LOAD_EVENT برای LOAD DATA INFILE در MySQL 4 و پیش از آن استفاده می‌شود.
0d RAND_EVENT برای ارسال اطلاعات دربارهٔ مقادیر تصادفی در صورتی که تابع RAND() در دستور استفاده شده باشد، به کار می‌رود.
0e USER_VAR_EVENT برای همانندسازی متغیرهای کاربر استفاده می‌شود.
0f FORMAT_DESCRIPTION_EVENT نشان‌دهندهٔ آغاز یک فایل لاگ نوشته‌شده توسط MySQL 5 یا جدیدتر است.
10 XID_EVENT رویدادی که نشان‌دهندهٔ ثبت قطعی (commit) یک تراکنش XA است.
11 BEGIN_LOAD_QUERY_EVENT برای دستورهای LOAD DATA INFILE در MySQL 5 و جدیدتر استفاده می‌شود.
12 EXECUTE_LOAD_QUERY_EVENT برای دستورهای LOAD DATA INFILE در MySQL 5 و جدیدتر استفاده می‌شود.
13 TABLE_MAP_EVENT اطلاعاتی دربارهٔ تعریف یک جدول. در MySQL 5.1.5 و جدیدتر استفاده می‌شود.
14 PRE_GA_WRITE_ROWS_EVENT داده‌های سطر برای یک جدول منفرد که باید ایجاد شود. در MySQL 5.1.5 تا 5.1.17 استفاده شده است.
15 PRE_GA_UPDATE_ROWS_EVENT داده‌های سطر برای یک جدول منفرد که باید به‌روزرسانی شود. در MySQL 5.1.5 تا 5.1.17 استفاده شده است.
16 PRE_GA_DELETE_ROWS_EVENT داده‌های سطر برای یک جدول منفرد که باید حذف شود. در MySQL 5.1.5 تا 5.1.17 استفاده شده است.
17 WRITE_ROWS_EVENT داده‌های سطر برای یک جدول منفرد که باید ایجاد شود. در MySQL 5.1.18 و جدیدتر استفاده می‌شود.
18 UPDATE_ROWS_EVENT داده‌های سطر برای یک جدول منفرد که باید به‌روزرسانی شود. در MySQL 5.1.18 و جدیدتر استفاده می‌شود.
19 DELETE_ROWS_EVENT داده‌های سطر برای یک جدول منفرد که باید حذف شود. در MySQL 5.1.18 و جدیدتر استفاده می‌شود.
1a INCIDENT_EVENT رویدادی غیرعادی رخ داده است. در MySQL 5.1.18 افزوده شد. .TE 4 • Master ID: شناسه سرور (server ID) سرور master که رویداد را ایجاد کرده است. 4 • Size: اندازه رویداد بر حسب بایت. 4 • Master Pos: موقعیت رویداد بعدی در فایل گزارش (log file) اصلی سرور master. 4 • Flags: ۱۶ پرچم. در حال حاضر، پرچم‌های زیر استفاده می‌شوند. بقیه برای استفاده در آینده رزرو شده‌اند. allbox tab(:); l l lx. T{ پرچم
نام
T} مفهوم
01 LOG_EVENT_BINLOG_IN_USE_F فایل لاگ به‌درستی بسته شده است. (تنها در FORMAT_DESCRIPTION_EVENT استفاده می‌شود.) اگر این پرچم تنظیم شده باشد (اگر پرچم‌ها، برای نمونه، '01 00' باشند) در یک FORMAT_DESCRIPTION_EVENT، فایل لاگ به‌درستی بسته نشده است. به‌احتمال بسیار زیاد این امر به دلیل کرش سرور master (برای نمونه به دلیل قطعی برق) رخ داده است.
02   برای استفاده در آینده رزرو شده است.
04 LOG_EVENT_THREAD_SPECIFIC_F تنظیم می‌شود اگر رویداد وابسته به اتصالی باشد که در آن اجرا شده است (برای نمونه، '04 00')؛ برای مثال، اگر رویداد از جدول‌های موقت (temporary tables) استفاده کند.
08 LOG_EVENT_SUPPRESS_USE_F در برخی شرایط هنگامی که رویداد وابسته به پایگاه‌داده پیش‌فرض نباشد، تنظیم می‌شود. 
مثال‌های زیر نشان می‌دهند که چگونه
mariadb-binlog
رویدادهای سطری (row events) را که مشخص‌کننده تغییرات داده‌ها هستند نمایش می‌دهد. این رویدادها متناظر با کدهای نوع
WRITE_ROWS_EVENT،
UPDATE_ROWS_EVENT
و
DELETE_ROWS_EVENT
هستند. گزینه‌های
--base64-output=DECODE-ROWS
و
--verbose
می‌توانند برای تغییر نحوه خروجی رویدادهای سطری استفاده شوند.
فرض کنید سرور از ثبت لاگ دودویی مبتنی بر سطر (row-based binary logging) استفاده می‌کند و شما توالی دستورهای زیر را اجرا می‌کنید:
CREATE TABLE t
(
  id   INT NOT NULL,
  name VARCHAR(20) NOT NULL,
  date DATE NULL
) ENGINE = InnoDB;
START TRANSACTION;
INSERT INTO t VALUES(1, 'apple', NULL);
UPDATE t SET name = 'pear', date = '2009-01-01' WHERE id = 1;
DELETE FROM t WHERE id = 1;
COMMIT;

به طور پیش‌فرض، mariadb-binlog رویدادهای سطری را با استفاده از دستورهای BINLOG به صورت رشته‌های کدگذاری‌شده base-64 نمایش می‌دهد. با صرف‌نظر از خطوط اضافی، خروجی رویدادهای سطری تولیدشده توسط توالی دستورهای پیشین به این شکل خواهد بود:

shell> mariadb-binlog log_file
...
# at 218
#080828 15:03:08 server id 1  end_log_pos 258 	Write_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ=='/*!*/;
...
# at 302
#080828 15:03:08 server id 1  end_log_pos 356 	Update_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP'/*!*/;
...
# at 400
#080828 15:03:08 server id 1  end_log_pos 442 	Delete_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP'/*!*/;

برای دیدن رویدادهای سطری به عنوان یادداشت در قالب دستورهای “شبه‌اس‌کیوال (pseudo-SQL)”، دستور mariadb-binlog را همراه با گزینه --verbose یا -v اجرا کنید. خروجی شامل خطوطی خواهد بود که با ### آغاز می‌شوند:

shell> mariadb-binlog -v log_file
...
# at 218
#080828 15:03:08 server id 1  end_log_pos 258 	Write_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ=='/*!*/;
### INSERT INTO test.t
### SET
###   @1=1
###   @2='apple'
###   @3=NULL
...
# at 302
#080828 15:03:08 server id 1  end_log_pos 356 	Update_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP'/*!*/;
### UPDATE test.t
### WHERE
###   @1=1
###   @2='apple'
###   @3=NULL
### SET
###   @1=1
###   @2='pear'
###   @3='2009:01:01'
...
# at 400
#080828 15:03:08 server id 1  end_log_pos 442 	Delete_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP'/*!*/;
### DELETE FROM test.t
### WHERE
###   @1=1
###   @2='pear'
###   @3='2009:01:01'

گزینه --verbose یا -v را دو بار مشخص کنید تا انواع داده‌ها و مقداری فراداده نیز برای هر ستون نمایش داده شود. خروجی شامل یک یادداشت اضافی در ادامه تغییرات هر ستون خواهد بود:

shell> mariadb-binlog -vv log_file
...
# at 218
#080828 15:03:08 server id 1  end_log_pos 258 	Write_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ=='/*!*/;
### INSERT INTO test.t
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='apple' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
###   @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
...
# at 302
#080828 15:03:08 server id 1  end_log_pos 356 	Update_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP'/*!*/;
### UPDATE test.t
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='apple' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
###   @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='pear' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
###   @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */
...
# at 400
#080828 15:03:08 server id 1  end_log_pos 442 	Delete_rows: table id 17 flags: STMT_END_F
BINLOG 'fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP'/*!*/;
### DELETE FROM test.t
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='pear' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
###   @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */

می‌توانید با استفاده از گزینه --base64-output=DECODE-ROWS به mariadb-binlog بگویید که از نمایش دستورهای BINLOG برای رویدادهای سطری صرف‌نظر کند. این کار شبیه به --base64-output=NEVER است، اما در صورتی که یک رویداد سطری یافت شود، با خطا خارج نمی‌شود. ترکیب --base64-output=DECODE-ROWS و --verbose روشی مناسب برای دیدن رویدادهای سطری صرفاً به صورت دستورهای SQL فراهم می‌کند:.sp

shell> mariadb-binlog -v --base64-output=DECODE-ROWS log_file
...
# at 218
#080828 15:03:08 server id 1  end_log_pos 258 	Write_rows: table id 17 flags: STMT_END_F
### INSERT INTO test.t
### SET
###   @1=1
###   @2='apple'
###   @3=NULL
...
# at 302
#080828 15:03:08 server id 1  end_log_pos 356 	Update_rows: table id 17 flags: STMT_END_F
### UPDATE test.t
### WHERE
###   @1=1
###   @2='apple'
###   @3=NULL
### SET
###   @1=1
###   @2='pear'
###   @3='2009:01:01'
...
# at 400
#080828 15:03:08 server id 1  end_log_pos 442 	Delete_rows: table id 17 flags: STMT_END_F
### DELETE FROM test.t
### WHERE
###   @1=1
###   @2='pear'
###   @3='2009:01:01'

نکته

اگر قصد اجرای مجدد خروجی mariadb-binlog را دارید، نباید دستورات BINLOG را سرکوب کنید.

دستورات SQL تولیدشده توسط --verbose برای رویدادهای سطری بسیار خواناتر از دستورات متناظر BINLOG هستند. با این حال، آن‌ها دقیقاً با دستورات اصلی SQL که رویدادها را ایجاد کرده‌اند مطابقت ندارند. محدودیت‌های زیر اعمال می‌شوند:

•نام‌های اصلی ستون‌ها از بین می‌روند و با @N جایگزین می‌شوند، که در آن N شماره ستون است.
•اطلاعات مجموعه نویسه‌ها در لاگ دودویی در دسترس نیست، که این امر بر نمایش ستون‌های رشته‌ای تأثیر می‌گذارد:
•هیچ تمایزی میان انواع رشته‌های باینری و غیرباینری متناظر قائل نمی‌شود (BINARY و CHAR، VARBINARY و VARCHAR، BLOB و TEXT). خروجی از نوع داده STRING برای رشته‌های با طول ثابت و VARSTRING برای رشته‌های با طول متغیر استفاده می‌کند.
•برای مجموعه‌های نویسه چندبایتی، حداکثر تعداد بایت‌ها به ازای هر نویسه در لاگ دودویی وجود ندارد؛ بنابراین طول انواع رشته‌ای به جای تعداد نویسه‌ها، بر حسب بایت نمایش داده می‌شود. برای مثال، STRING(4) به عنوان نوع داده برای مقادیر حاصل از هر یک از این انواع ستون استفاده خواهد شد: 
CHAR(4) CHARACTER SET latin1
CHAR(2) CHARACTER SET ucs2
•به دلیل قالب ذخیره‌سازی رویدادهای از نوع UPDATE_ROWS_EVENT، دستورات UPDATE به گونه‌ای نمایش داده می‌شوند که بند WHERE پیش از بند SET قرار می‌گیرد.

تفسیر صحیح رویدادهای سطری نیازمند اطلاعات رویداد توصیف قالب (format description event) در ابتدای لاگ دودویی است. از آنجا که mariadb-binlog از پیش نمی‌داند که آیا ادامه لاگ حاوی رویدادهای سطری است یا خیر، به طور پیش‌فرض رویداد توصیف قالب را با استفاده از یک دستور BINLOG در بخش ابتدایی خروجی نمایش می‌دهد.

اگر مشخص باشد که لاگ دودویی حاوی هیچ رویدادی که به دستور BINLOG نیاز داشته باشد نیست (یعنی هیچ رویداد سطری وجود ندارد)، گزینه --base64-output=NEVER می‌تواند برای جلوگیری از نوشتن این سرآیند به کار رود..SH "کپی‌رایت و تکثیر (COPYRIGHT)"

کپی‌رایت 2007-2008 MySQL AB، 2008-2010 Sun Microsystems, Inc.، 2010-2025 MariaDB Foundation

این مستندات یک نرم‌افزار آزاد است؛ شما می‌توانید آن را تنها تحت شرایط مجوز عمومی همگانی گنو (GNU General Public License) همان‌گونه که توسط بنیاد نرم‌افزارهای آزاد (Free Software Foundation) منتشر شده است، بازتوزیع کرده و/یا تغییر دهید؛ نسخهٔ ۲ این مجوز.

این مستندات به این امید توزیع شده است که مفید باشد، اما بدون هیچ‌گونه ضمانتی؛ حتی بدون ضمانت ضمنی قابلیت فروش یا تناسب برای یک هدف خاص. برای جزئیات بیشتر به مجوز عمومی همگانی گنو (GNU General Public License) مراجعه کنید.

شما باید به همراه این برنامه نسخه‌ای از GNU General Public License را دریافت کرده باشید؛ در غیر این صورت، به آدرس Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1335 USA نامه بنویسید یا به http://www.gnu.org/licenses مراجعه کنید.

1.
Bug#42941
http://bugs.mysql.com/bug.php?id=42941

برای اطلاعات بیشتر، لطفاً به مستندات MariaDB مراجعه کنید که به‌صورت برخط در https://mariadb.com/docs در دسترس است.

بنیاد MariaDB Foundation (http://www.mariadb.org).

5 March 2025 MariaDB 11.8