mysqlbinlog - Інтернет у хмарі

ПРОГРАМА:

ІМ'Я

mysqlbinlog - утиліта для обробки двійкових файлів журналу

СИНТАКСИС

mysqlbinlog [параметри] log_file ...

ОПИС

Бінарний журнал сервера складається з файлів, що містять «події», які описують зміни
до вмісту бази даних. Сервер записує ці файли у двійковому форматі. Щоб відобразити їх
вміст у текстовому форматі, використовуйте mysqlbinlog корисність. Ви також можете використовувати mysqlbinlog до
відображати вміст файлів журналу ретрансляції, записаних підпорядкованим сервером у налаштуваннях реплікації
оскільки релейні журнали мають той самий формат, що й двійкові журнали. Двійковий журнал і журнал реле є
обговорюється далі в Розділі 5.2.4, «Двійковий журнал», і Розділі 17.2.2, «Реплікація
Реле та журнали стану».

волати mysqlbinlog подобається це:

оболонка> mysqlbinlog [опції] log_file ...

Наприклад, щоб відобразити вміст двійкового файлу журналу з іменем binlog.000003, скористайтеся цим
команда:

оболонка> mysqlbinlog binlog.0000003

Вихідні дані містять події, що містяться в binlog.000003. Для ведення журналу на основі операторів подія
інформація включає оператор SQL, ідентифікатор сервера, на якому він був виконаний,
мітка часу, коли оператор був виконаний, скільки часу це зайняло тощо. Для
ведення журналу на основі рядків, подія вказує на зміну рядка, а не на оператор SQL. Побачити
Розділ 17.1.2, «Формати реплікації», містить інформацію про режими реєстрації.

Подіям передують коментарі заголовка, які надають додаткову інформацію. Наприклад:

№ на 141
#100309 9:28:36 ідентифікатор сервера 123 end_log_pos 245
Запит thread_id=3350 exec_time=11 error_code=0

У першому рядку наступне число вказує зміщення файлу або початок
позиції події у двійковому файлі журналу.

Другий рядок починається з дати та часу, що вказують, коли розпочався оператор
сервер, на якому виникла подія. Для реплікації ця позначка часу поширюється на підпорядковану
сервери. server id — це значення server_id сервера, на якому виникла подія.
end_log_pos вказує, де починається наступна подія (тобто це кінцева позиція файлу
поточна подія + 1). thread_id вказує, який потік виконав подію. exec_time є
час, витрачений на виконання події на головному сервері. Для раба це різниця
часу закінчення виконання на веденому за мінусом часу початку виконання на головному.
Різниця служить індикатором того, наскільки реплікація відстає від майстра.
error_code вказує на результат виконання події. Нуль означає відсутність помилки
сталося.

примітки
При використанні груп подій файли зміщень подій можуть бути згруповані разом і
коментарі до подій можуть бути згруповані разом. Не плутайте ці згруповані події за
зміщення порожнього файлу.

Вихідні дані з mysqlbinlog можна повторно виконати (наприклад, використовуючи його як вхід до
MySQL), щоб повторити оператори в журналі. Це корисно для відновлювальних операцій після а
збій сервера. Для інших прикладів використання див. обговорення далі в цьому розділі та в
Розділ 7.5, «Відновлення на момент часу (інкрементальне) за допомогою двійкового журналу».

Зазвичай ви використовуєте mysqlbinlog щоб безпосередньо читати двійкові файли журналу та застосовувати їх до
локальний сервер MySQL. Також можна читати двійкові журнали з віддаленого сервера за допомогою
--читання-з-віддаленого-сервера варіант. Щоб читати віддалені двійкові журнали, параметр підключення
можна надати параметри, які вказують, як підключитися до сервера. Ці варіанти є --господар,
--пароль, --порт, --протокол, --розетка та --користувач; вони ігноруються, за винятком випадків, коли ви
також використовуйте --читання-з-віддаленого-сервера варіант.

mysqlbinlog підтримує наступні параметри, які можна вказати в командному рядку або
у групах [mysqlbinlog] та [client] файлу параметрів. Для отримання інформації про варіант
файли, які використовуються програмами MySQL, див. Розділ 4.2.6, «Використання файлів параметрів».

· --допомога, -?

Відобразити довідкове повідомлення та вийти.

· --base64-вихід=значення

Цей параметр визначає, коли події мають відображатися в кодуванні як рядки base-64
за допомогою операторів BINLOG. Опція має такі допустимі значення (не чутливі до регістру):

· AUTO ("автоматичний") або UNSPEC ("невизначений") відображає оператори BINLOG
автоматично, коли це необхідно (тобто для подій опису формату та рядка
події). Якщо ні --base64-вихід надається варіант, ефект такий самий, як
--base64-output=АВТОМАТИЧНО.

примітки
Автоматичне відображення BINLOG є єдиною безпечною поведінкою, якщо ви збираєтеся використовувати
вихід з mysqlbinlog щоб повторно виконати вміст двійкового файлу журналу. Інший варіант
значення призначені лише для налагодження чи тестування, оскільки вони можуть
вивести вихідні дані, які не включають усі події у виконуваній формі.

· НІКОЛИ не призводить до того, що оператори BINLOG не відображаються. mysqlbinlog виходить з an
помилка, якщо знайдено подію рядка, яку необхідно відобразити за допомогою BINLOG.

· DECODE-ROWS вказує на mysqlbinlog які ви маєте намір декодувати події рядка
і відображаються як коментовані оператори SQL, також вказуючи -багатослівний варіант.
Як і NEVER, DECODE-ROWS пригнічує відображення операторів BINLOG, але на відміну від NEVER,
він не завершується з помилкою, якщо знайдена подія рядка.

Для прикладів, які показують ефект від --base64-вихід та -багатослівний на подію рядка
виведення, див. розділ під назвою «ВІДОБРАЖЕННЯ ПОДІЇ РЯДКА MYSQLBINLOG».

· --bind-address=IP-адреса

На комп’ютері з кількома мережевими інтерфейсами використовуйте цей параметр, щоб вибрати який
інтерфейс для підключення до сервера MySQL.

Цей параметр підтримується, починаючи з MySQL 5.6.1.

· --binlog-row-event-max-size=N

┌────────────────────┬─────────────────────────── ───────────────┐
│Командний рядок сформований │ --binlog-row-event-max-size=# │
├────────────────────┼─────────────────────────── ───────────────┤
│ │ Дозволено Цінності │
│ ├──────────────────┬──────────────────────┤
│ │ платформа Біт Розмір │ 64 │
│ ├───────────────────┼───────────────────────┤
│ │ тип │ числові │
│ ├───────────────────┼───────────────────────┤
│ │ дефолт │ 4294967040 │
│ ├───────────────────┼───────────────────────┤
│ │ Мін значення │ 256 │
│ ├───────────────────┼───────────────────────┤
│ │ Макс значення │ 18446744073709547520 │
└────────────────────┴───────────────────┴──────── ───────────────┘
Вкажіть максимальний розмір події двійкового журналу на основі рядків у байтах. Рядки групуються
на події, менші за цей розмір, якщо це можливо. Значення має бути кратним 256.
За замовчуванням встановлено 4 ГБ.

· --character-sets-dir=шлях

Каталог, де встановлені набори символів. Див. Розділ 10.5, «Набір символів
Конфігурація”.

· --ідентифікатор-підключення-сервера=server_id

Цей параметр використовується для перевірки сервера MySQL на підтримку BINLOG_DUMP_NON_BLOCK
прапор підключення, який був випадково видалений в MySQL 5.6.5 і відновлений в MySQL
5.6.20 (Помилка № 18000079, Помилка № 71178). Для нормальної роботи це не потрібно.

Ефективні значення за замовчуванням та мінімальні значення для цього параметра залежать від того, чи mysqlbinlog
виконується в режимі блокування або режимі без блокування. Коли mysqlbinlog виконується в режимі блокування
режим, значення за замовчуванням (і мінімальне) дорівнює 1; при запуску в режимі без блокування — за замовчуванням
(і мінімальне) значення 0.

Ця опція була додана в MySQL 5.6.20.

· --база даних=db_name, -d db_name

Цей варіант викликає mysqlbinlog виводити записи з двійкового журналу (лише локальний журнал)
які відбуваються під час db_name було обрано USE як базу даних за замовчуванням.

Команда --база даних варіант для mysqlbinlog схоже на --binlog-do-db варіант для
туздИ, але може використовуватися для визначення лише однієї бази даних. Якщо --база даних дається багаторазово
разів використовується тільки останній екземпляр.

Ефект цієї опції залежить від того, чи ведеться журнал на основі оператора чи на основі рядків
формат використовується так само, як і ефекти --binlog-do-db залежить від того, чи
використовується протоколювання на основі операторів або на основі рядків.

На основі заяв каротаж, --база даних опція працює наступним чином:

· Поки db_name є базою даних за замовчуванням, оператори виводяться незалежно від того, чи змінюються вони
таблиці в db_name або іншу базу даних.

· Хіба що db_name вибрано як базу даних за замовчуванням, оператори не виводяться,
навіть якщо вони змінюють таблиці в db_name.

· Існує виняток для CREATE DATABASE, ALTER DATABASE і DROP DATABASE. The
буття бази даних створений, змінений, or впав вважається за замовчуванням
бази даних під час визначення, чи потрібно виводити оператор.

Припустимо, що двійковий журнал було створено шляхом виконання цих операторів за допомогою
ведення журналу на основі операторів:

INSERT INTO test.t1 (i) ЗНАЧЕННЯ(100);
ВСТАВИТИ В db2.t2 (j) ЗНАЧЕННЯ(200);
ВИКОРИСТАННЯ тесту;
INSERT INTO test.t1 (i) ЗНАЧЕННЯ(101);
ВСТАВИТИ В t1 (i) ЗНАЧЕННЯ(102);
ВСТАВИТИ В db2.t2 (j) ЗНАЧЕННЯ(201);
ВИКОРИСТОВУЙТЕ db2;
INSERT INTO test.t1 (i) ЗНАЧЕННЯ(103);
ВСТАВИТИ В db2.t2 (j) ЗНАЧЕННЯ(202);
ВСТАВИТИ В t2 (j) ЗНАЧЕННЯ(203);

mysqlbinlog --database=тест не виводить перші два інструкції INSERT, оскільки
немає бази даних за замовчуванням. Він виводить три оператори INSERT після USE
test, але не три оператори INSERT після USE db2.

mysqlbinlog --database=db2 не виводить перші два інструкції INSERT, оскільки
немає бази даних за замовчуванням. Він не виводить три наступні оператори INSERT
Тест USE, але виводить три оператори INSERT після USE db2.

На основі рядків каротаж. mysqlbinlog виводить лише записи, які змінюють належність таблиць
db_name. База даних за замовчуванням не впливає на це. Припустимо, що двійковий журнал просто
описане було створено за допомогою ведення журналу на основі рядків, а не протоколювання на основі операторів.
mysqlbinlog --database=тест виводить лише ті записи, які змінюють t1 у тесті
бази даних, незалежно від того, чи було видано USE чи яка база даних за замовчуванням. Якщо
сервер працює з binlog_format, встановленим на MIXED, і ви хочете, щоб це було можливо
використання mysqlbinlog з --база даних варіант, ви повинні переконатися, що таблиці, які є
змінені знаходяться в базі даних, вибраній USE. (Зокрема, відсутність перехресної бази даних
слід використовувати оновлення.)

До MySQL 5.6.10, --база даних параметр не працював належним чином із записом журналу
сервером MySQL з підтримкою GTID. (Помилка № 15912728)

· --debug[=параметри_налагодження], -# [параметри_налагодження]

Напишіть журнал налагодження. Типовий параметри_налагодження рядок d:t:o,ім'я файлу. За замовчуванням
є d:t:o,/tmp/mysqlbinlog.trace.

· --debug-check

Роздрукуйте деяку інформацію про налагодження після завершення роботи програми.

· --debug-info

Друк налагоджувальної інформації та статистики використання пам’яті та ЦП під час роботи програми
виходи.

· --default-auth=підключати

Плагін аутентифікації на стороні клієнта для використання. Див. Розділ 6.3.7, «Підключається
Аутентифікація”.

Ця опція була додана в MySQL 5.6.2.

· --defaults-extra-file=ім'я файлу

Прочитайте цей файл параметрів після глобального файлу параметрів, але (в Unix) перед користувачем
файл параметрів. Якщо файл не існує або недоступний з інших причин, виникає помилка.
ім'я файлу інтерпретується відносно поточного каталогу, якщо вказано як відносний шлях
ім'я, а не повне ім'я шляху.

· --defaults-file=ім'я файлу

Використовуйте лише вказаний файл параметрів. Якщо файл не існує або є іншим
недоступний, виникає помилка. ім'я файлу інтерпретується відносно поточного
каталог, якщо вказано як відносне ім'я шляху, а не повне ім'я шляху.

· --defaults-group-suffix=вул

Читайте не тільки звичайні групи параметрів, а й групи зі звичайними назвами та а
суфікс з вул, Наприклад, mysqlbinlog зазвичай читає [client] і [mysqlbinlog]
групи. Якщо --defaults-group-suffix=_other надається варіант, mysqlbinlog також читає
групи [client_other] і [mysqlbinlog_other].

· --disable-log-bin, -D

Вимкніть двійковий журнал. Це корисно для уникнення нескінченного циклу, якщо ви використовуєте
--до останнього журналу і надсилають вихідні дані на той самий сервер MySQL. Цей варіант
також корисно під час відновлення після збою, щоб уникнути дублювання операторів
увійшли.

Для цього параметра потрібно мати привілей SUPER. Це викликає mysqlbinlog до
включити оператор SET sql_log_bin = 0 до свого виводу, щоб вимкнути двійкове ведення журналу
вихід, що залишився. Оператор SET неефективний, якщо у вас немає SUPER
привілей.

· --exclude-gtids=gtid_set

Не відображати жодну з груп, перелічених у gtid_set. Додано в MySQL 5.6.5.

· --примусово-якщо-відкрито, -F

Читайте двійкові файли журналу, навіть якщо вони відкриті або закриті неправильно.

· --примусово прочитати, -f

При цьому варіанті, якщо mysqlbinlog читає подію двійкового журналу, яку він не розпізнає,
він друкує попередження, ігнорує подію та продовжує. Без цієї опції,
mysqlbinlog зупиняється, якщо читає таку подію.

· --hexdump, -H

Відобразити шістнадцятковий дамп журналу в коментарях, як описано в розділі
«ФОРМАТ шістнадцятиричного дампу MYSQLBINLOG». Шістнадцятковий вихід може бути корисним для реплікації
налагодження.

· --host=ім'я_хоста, -h ім'я_хоста

Отримайте двійковий журнал із сервера MySQL на даному хості.

· --include-gtids=gtid_set

Відображати лише групи, перелічені в gtid_set. Додано в MySQL 5.6.5.

· --local-load=шлях, -l шлях

Підготуйте локальні тимчасові файли для LOAD DATA INFILE у вказаному каталозі.

Важливий
Ці тимчасові файли не видаляються автоматично mysqlbinlog або будь-який інший
Програма MySQL.

· --шлях до входу=ім'я

Прочитайте параметри з названого шляху входу у файлі входу .mylogin.cnf. «Шлях входу»
це група параметрів, яка дозволяє лише обмежений набір параметрів: господар, користувач та
пароль. Подумайте про шлях входу як набір значень, які вказують на хост сервера і
облікові дані для аутентифікації на сервері. Щоб створити файл шляху входу, використовуйте
mysql_config_editor корисність. Побачити mysql_config_editor(1). Ця опція була додана в
MySQL 5.6.6.

· --не-за замовчуванням

Не читайте файли опцій. Якщо запуск програми не вдається через читання невідомих параметрів
з файлу параметрів, --не-за замовчуванням можна використовувати, щоб запобігти їх читанню.

Винятком є ​​те, що файл .mylogin.cnf, якщо він існує, читається у всіх випадках. Це
дозволяє вказувати паролі безпечніше, ніж у командному рядку, навіть якщо
--не-за замовчуванням використовується. (.mylogin.cnf створюється mysql_config_editor утиліта
Читати mysql_config_editor(1)).

· --зміщення=N, -o N

Пропустіть першу N записи в журналі.

· --пароль[=пароль], -p[пароль]

Пароль для підключення до сервера. Якщо ви використовуєте коротку форму опції
(-p), ти не може мати пробіл між опцією та паролем. Якщо ви пропустите
пароль значення після --пароль or -p параметр у командному рядку, mysqlbinlog
підказки для одного.

Вказання пароля в командному рядку слід вважати небезпечним. Побачити
Розділ 6.1.2.1, «Інструкції для кінцевих користувачів щодо захисту пароля». Ви можете використовувати варіант
файл, щоб уникнути введення пароля в командному рядку.

· --plugin-dir=шлях

Каталог, у якому шукати плагіни. Можливо, буде потрібно вказати цю опцію
якщо --default-auth Параметр використовується для визначення плагіна аутентифікації, але
mysqlbinlog не знаходить. Див. Розділ 6.3.7, «Підставна автентифікація».

Ця опція була додана в MySQL 5.6.2.

· --порт=номер_порту, -P номер_порту

Номер порту TCP/IP для підключення до віддаленого сервера.

· --print-defaults

Надрукуйте назву програми та всі параметри, які вона отримує з файлів параметрів.

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

Протокол підключення для підключення до сервера. Це корисно, коли
інші параметри підключення зазвичай призводять до використання протоколу, відмінного від протоколу
який ти хочеш. Докладніше про допустимі значення див. у розділі 4.2.2 «Підключення до
сервер MySQL».

· -сирий

За замовчуванням mysqlbinlog читає двійкові файли журналу та записує події у текстовому форматі. The
-сирий опція розповідає mysqlbinlog щоб записати їх у оригінальному двійковому форматі. Його використання
вимагає цього --читання-з-віддаленого-сервера також використовуватися, оскільки файли запитуються
із сервера. mysqlbinlog записує один вихідний файл для кожного файлу, прочитаного з сервера.
Команда -сирий параметр можна використовувати для створення резервної копії двійкового журналу сервера. З
--стоп-ніколи варіант, резервне копіювання є «живим», тому що mysqlbinlog залишається на зв'язку з
сервер. За замовчуванням вихідні файли записуються в поточний каталог із тим самим
імена як вихідні файли журналу. Імена вихідних файлів можна змінити за допомогою
--результат-файл варіант. Для отримання додаткової інформації див. розділ «ВИКОРИСТАННЯ MYSQLBINLOG
ДЛЯ РЕЗЕРВНОГО КОПИРОВАННЯ ДВІЙКОВИХ ФАЙЛОВ ЖУРНАЛ».

Ця опція була додана в MySQL 5.6.0.

· --read-from-remote-master=тип

Читання двійкових журналів із сервера MySQL за допомогою COM_BINLOG_DUMP або COM_BINLOG_DUMP_GTID
команд, встановивши значення параметра на BINLOG-DUMP-NON-GTIDS або
BINLOG-DUMP-GTIDS відповідно. Якщо --read-from-remote-master=BINLOG-DUMP-GTIDS is
в поєднанні з --exclude-gtids, транзакції можна відфільтрувати на головному,
уникнення непотрібного мережевого трафіку.

Дивіться також опис для --читання-з-віддаленого-сервера.

Ця опція була додана в MySQL 5.6.5.

· --читання-з-віддаленого-сервера, -R

Читайте двійковий журнал із сервера MySQL, а не читайте локальний файл журналу. Будь-який
параметри підключення ігноруються, якщо ця опція також не вказана. Ці
варіанти є --господар, --пароль, --порт, --протокол, --розетка та --користувач.

Цей параметр вимагає, щоб віддалений сервер був запущений. Він працює тільки для двійкового журналу
файли на віддаленому сервері, а не файли журналу передачі.

Починаючи з MySQL 5.6.5, цей параметр схожий
--read-from-remote-master=BINLOG-DUMP-NON-GTIDS.

· --result-file=ім'я, -r ім'я

Без того -сирий параметр, цей параметр вказує файл, до якого mysqlbinlog пише
виведення тексту. З -сирий, mysqlbinlog записує один двійковий вихідний файл для кожного файлу журналу
передані з сервера, записуючи їх за замовчуванням у поточний каталог за допомогою
ті самі імена, що й оригінальний файл журналу. У цьому випадку, --результат-файл вартість опціону
розглядається як префікс, який змінює імена вихідних файлів.

· --secure-auth

Не надсилайте паролі на сервер у старому (до 4.1) форматі. Це запобігає з'єднання
за винятком серверів, які використовують новіший формат пароля. Цей параметр увімкнено за допомогою
за замовчуванням; використовувати --skip-secure-auth щоб вимкнути його. Ця опція була додана в MySQL 5.6.17.

примітки
Паролі, які використовують метод хешування до 4.1, менш безпечні, ніж паролі, які
використовувати власний метод хешування паролів, і цього слід уникати. Паролі до версії 4.1
є застарілими, і їх підтримку буде вилучено в майбутньому випуску MySQL. Для
інструкції щодо оновлення облікового запису, див. Розділ 6.3.8.3, «Перехід із попередньої версії 4.1
Хешування пароля та плагін mysql_old_password».

· --ідентифікатор-сервера=id

Відображати лише ті події, створені сервером із заданим ідентифікатором сервера.

· --server-id-bits=N

Використовуйте тільки першу N біти server_id для ідентифікації сервера. Якщо двійковий журнал
був написаний а туздИ з бітами ідентифікатора сервера, встановленими на менше ніж 32, і збереженими даними користувача
у найважливішому біті, біг mysqlbinlog з -- біти ідентифікатора сервера встановлено на 32
дозволяє побачити ці дані.

Цей параметр підтримується лише версіями mysqlbinlog постачається разом із MySQL
Кластерний розподіл або створений з джерел MySQL Cluster.

· --set-charset=charset_name

Додайте НАБІР ІМЕНІВ charset_name оператор на виводі для визначення набору символів
використовувати для обробки файлів журналів.

· --shared-memory-base-name=ім'я

У Windows — ім’я спільної пам’яті, яке потрібно використовувати для підключень, створених за допомогою спільної пам’яті до
локальний сервер. Значенням за замовчуванням є MYSQL. Ім’я спільної пам’яті чутливе до регістру.

Сервер потрібно запустити з --спільна пам'ять можливість увімкнути спільну пам'ять
сполук.

· --коротка форма, -s

Відображати лише твердження, що містяться в журналі, без будь-якої додаткової інформації або
події на основі рядків. Це лише для тестування і не повинно використовуватися у виробництві
систем.

· --skip-gtids[=(true|false)]

Не відображати жодних GTID у виводі. Це потрібно під час запису у файл дампа
з одного або кількох двійкових журналів, що містять GTID, як показано в цьому прикладі:

оболонка> mysqlbinlog --skip-gtids binlog.000001 > /tmp/dump.sql
оболонка> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
оболонка> MySQL -u корінь -p -e «джерело /tmp/dump.sql"

В іншому випадку використання цієї опції зазвичай не рекомендується у виробництві.

Ця опція була додана в MySQL 5.6.5.

· --socket=шлях, -S шлях

Для підключення до локального хосту використовуйте файл сокета Unix або, у Windows, ім’я
названий канал для використання.

· --start-datetime=дата, час

Почніть читати двійковий журнал з першої події, яка має мітку часу, що дорівнює або пізніше
ніж дата, час аргумент. The дата, час значення відносно місцевого часового поясу ввімкнено
машина, де ви працюєте mysqlbinlog. Значення має бути в прийнятному форматі
типи даних DATETIME або TIMESTAMP. Наприклад:

оболонка> mysqlbinlog --start-datetime="2005-12-25 11:25:56" binlog.000003

Цей параметр корисний для відновлення на момент часу. Див. Розділ 7.3, «Приклад резервного копіювання та
Стратегія відновлення».

· --початкова позиція=N, -j N

Почніть читати двійковий журнал з першої події, яка має позицію, рівну або більшу
ніж N. Цей параметр застосовується до першого файлу журналу, названого в командному рядку.

Цей параметр корисний для відновлення на момент часу. Див. Розділ 7.3, «Приклад резервного копіювання та
Стратегія відновлення».

· --stop-datetime=дата, час

Припиніть читання двійкового журналу під час першої події, що має мітку часу, що дорівнює або пізніше
ніж дата, час аргумент. Цей параметр корисний для відновлення на момент часу. Див
опис --початок-датачас варіант для інформації про дата, час value.

Цей параметр корисний для відновлення на момент часу. Див. Розділ 7.3, «Приклад резервного копіювання та
Стратегія відновлення».

· --стоп-ніколи

Цей параметр використовується з --читання-з-віддаленого-сервера. Це розповідає mysqlbinlog залишатися
підключений до сервера. Інакше mysqlbinlog виходить, коли був останній файл журналу
передано з сервера. --стоп-ніколи мається на увазі --до останнього журналу, тож тільки перше
файл журналу для передачі потрібно назвати в командному рядку.

--стоп-ніколи зазвичай використовується з -сирий для створення живої резервної копії двійкового журналу, але також
можна використовувати без -сирий щоб підтримувати безперервне текстове відображення подій журналу як
сервер генерує їх.

Ця опція була додана в MySQL 5.6.0.

· --stop-never-slave-id-server=id

з --стоп-ніколи, mysqlbinlog повідомляє ідентифікатор сервера 65535, коли він підключається до
сервера. --stop-never-slave-id-сервера явно вказує ідентифікатор сервера для звіту. Це
можна використовувати, щоб уникнути конфлікту з ідентифікатором підпорядкованого або іншого сервера mysqlbinlog
процес. Дивіться розділ «ВКАЗАННЯ ІДЕНТИФІКАЦІЇ СЕРВЕРА MYSQLBINLOG».

Ця опція була додана в MySQL 5.6.0.

· --stop-position=N

Припиніть читання двійкового журналу під час першої події, яка має позицію, рівну або більшу
ніж N. Цей параметр застосовується до останнього файлу журналу, названого в командному рядку.

Цей параметр корисний для відновлення на момент часу. Див. Розділ 7.3, «Приклад резервного копіювання та
Стратегія відновлення».

· --до останнього журналу, -t

Не зупиняйтеся в кінці запитуваного двійкового журналу від сервера MySQL, а радше
продовжуйте друк до кінця останнього двійкового журналу. Якщо ви відправите вихід до
на тому самому сервері MySQL, це може призвести до нескінченного циклу. Цей варіант вимагає
--читання-з-віддаленого-сервера.

· --user=user_name, -u user_name

Ім'я користувача MySQL для підключення до віддаленого сервера.

· -багатослівний, -v

Відновіть події рядка та відобразіть їх як прокоментовані оператори SQL. Якщо цей варіант є
задано двічі, вихідні дані включають коментарі для вказівки типів даних стовпців і деякі
метадані.

Для прикладів, які показують ефект від --base64-вихід та -багатослівний на подію рядка
виведення, див. розділ під назвою «ВІДОБРАЖЕННЯ ПОДІЇ РЯДКА MYSQLBINLOG».

· --verify-binlog-checksum, -c

Перевіряйте контрольні суми у двійкових файлах журналів. Ця опція була додана в MySQL 5.6.1.

· -- версія, -V

Відобразити інформацію про версію та вийти.

До MySQL 5.6.11, mysqlbinlog показаний номер версії 3.3. У MySQL 5.6.11
і пізніше, це 3.4. (Помилка № 15894381, Помилка № 67643)

Ви також можете встановити наступну змінну за допомогою --Var_name=значення синтаксис:

· ліміт відкритих_файлів

Вкажіть кількість відкритих дескрипторів файлів, які потрібно зарезервувати.

Ви можете передати вихід mysqlbinlog в MySQL клієнта для виконання подій
міститься в двійковому журналі. Ця техніка використовується для відновлення після збою, коли у вас є
стару резервну копію (див. Розділ 7.5, «Відновлення на момент (інкрементальне) з використанням двійкового
Журнал»). Наприклад:

оболонка> mysqlbinlog binlog.000001 | MySQL -u корінь -p

Або:

оболонка> mysqlbinlog binlog.[0-9]* | MySQL -u корінь -p

Якщо заяви, вироблені mysqlbinlog може містити значення BLOB, що може спричинити
проблеми, коли MySQL обробляє їх. У цьому випадку виклик MySQL з -- двійковий режим
варіант.

Ви також можете перенаправити вихідні дані mysqlbinlog у текстовий файл, якщо потрібно
спочатку змініть журнал операторів (наприклад, щоб видалити оператори, які ви не хочете
виконати чомусь). Після редагування файлу виконайте інструкції, які він містить
використовуючи його як вхід до MySQL програма:

оболонка> mysqlbinlog binlog.000001 > файл tmp
оболонка> ... редагувати файл tmp ...
оболонка> MySQL -u корінь -p < файл tmp

Коли mysqlbinlog викликається за допомогою --початкове положення параметр, він відображає лише ті
події зі зміщенням у двійковому журналі, більшим або рівним заданій позиції (
дана позиція повинна відповідати початку однієї події). У ньому також є варіанти зупинки та початку
коли він бачить подію з заданою датою та часом. Це дозволяє виконувати
відновлення на момент часу за допомогою --stop-datetime варіант (щоб мати можливість сказати, наприклад,
"перевернути мої бази даних до того, як вони були сьогодні о 10:30").

Якщо у вас є кілька двійкових журналів для виконання на сервері MySQL, безпечним методом є
обробляти їх усі, використовуючи єдине підключення до сервера. Ось приклад, що
демонструє, що може бути небезпечно:

оболонка> mysqlbinlog binlog.000001 | MySQL -u корінь -p # НЕБЕЗПЕКА !!
оболонка> mysqlbinlog binlog.000002 | MySQL -u корінь -p # НЕБЕЗПЕКА !!

Обробка двійкових журналів таким чином з використанням кількох підключень до сервера викликає проблеми
якщо перший файл журналу містить оператор CREATE TEMPORARY TABLE, а другий журнал
містить оператор, який використовує тимчасову таблицю. Коли перший MySQL процес
завершується, сервер скидає тимчасову таблицю. Коли другий MySQL спроби процесу
щоб використовувати таблицю, сервер повідомляє «невідома таблиця».

Щоб уникнути подібних проблем, використовуйте a один MySQL процес для виконання вмісту всіх
двійкові журнали, які потрібно обробити. Ось один із способів зробити це:

оболонка> mysqlbinlog binlog.000001 binlog.000002 | MySQL -u корінь -p

Інший підхід полягає в тому, щоб записати всі журнали в один файл, а потім обробити файл:

оболонка> mysqlbinlog binlog.000001 > /tmp/statements.sql
оболонка> mysqlbinlog binlog.000002 >> /tmp/statements.sql
оболонка> MySQL -u корінь -p -e «джерело /tmp/statements.sql"

mysqlbinlog може виробляти вихід, який відтворює операцію LOAD DATA INFILE без
вихідний файл даних. mysqlbinlog копіює дані в тимчасовий файл і записує LOAD
Оператор DATA LOCAL INFILE, який посилається на файл. Розташування каталогу за замовчуванням
куди записуються ці файли, залежить від системи. Щоб вказати каталог явно, використовуйте
--локальне навантаження варіант.

Тому що mysqlbinlog перетворює оператори LOAD DATA INFILE в LOAD DATA LOCAL INFILE
оператори (тобто він додає LOCAL), як клієнта, так і сервера, який ви використовуєте
обробляти оператори повинні бути налаштовані з увімкненою можливістю LOCAL. Побачити
Розділ 6.1.6, «Проблеми безпеки з LOAD DATA LOCAL».

попередження
Тимчасові файли, створені для операторів LOAD DATA LOCAL НЕ автоматично
видалено, оскільки вони потрібні, поки ви фактично не виконаєте ці оператори. ти
слід видалити тимчасові файли самостійно після того, як вам більше не потрібен журнал заяв.
Файли можна знайти в каталозі тимчасового файлу і мають такі імена, як
оригінальне_ім'я_файлу-#-#.

MYSQLBINLOG HEX DUMP ФОРМАТ

Команда --hexdump варіант причин mysqlbinlog щоб створити шістнадцятковий дамп вмісту двійкового журналу:

оболонка> mysqlbinlog --hexdump master-bin.000001

Шістнадцятковий висновок складається з рядків коментарів, які починаються на #, тому результат може виглядати так
це для попередньої команди:

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
№ на 4
#051024 17:24:13 ідентифікатор сервера 1 end_log_pos 98
# Позиція Тип позначки часу Головний ідентифікатор Розмір Прапори головної пози
# 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...|
# Початок: binlog v 4, server v 5.0.15-debug-log створено 051024 17:24:13
# під час запуску
Відкат;

Шістнадцятковий дамп на даний момент містить елементи з наступного списку. Цей формат є
підлягає зміні. (Для отримання додаткової інформації про формат двійкового журналу див MySQL Внутрішні органи: Команда
двійковий Ввійти[1].

· Позиція: Позиція байтів у файлі журналу.

· Позначка часу: мітка часу події. У наведеному прикладі '9d fc 5c 43' є
відображення '051024 17:24:13' в шістнадцятковому форматі.

· Тип: код типу події. У наведеному прикладі '0f' вказує на a
FORMAT_DESCRIPTION_EVENT. У наступній таблиці перелічено можливі коди типів.

┌─────┬───────────────────────────┬─────────────── ────────────────────────┐
│тип │ ІМ'Я │ Сенс │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│00 │ НЕВІДНА_ПОДІЯ │ Ця подія ніколи не повинна │
│ │ │ бути присутнім у журналі. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│01 │ START_EVENT_V3 │ Це вказує на початок │
│ │ │ файлу журналу, написаного │
│ │ │ MySQL 4 або раніше. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│02 │ QUERY_EVENT │ Найпоширеніший тип │
│ │ │ події. Вони містять │
│ │ │ оператори, виконані на │
│ │ │ │
│ │ │ майстер. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│03 │ STOP_EVENT │ Вказує, що господар має │
│ │ │ зупинився. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│04 │ ROTATE_EVENT │ Написано, коли майстер │
│ │ │ перемикається на новий файл журналу. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│05 │ INTVAR_EVENT │ Використовується для AUTO_INCREMENT │
│ │ │ або коли │
│ │ │ LAST_INSERT_ID() │
│ │ │ функція │
│ │ │ використовується у заяві. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│06 │ LOAD_EVENT │ Використовується для ЗАВАНТАЖЕННЯ ДАНИХ │
│ │ │ INFILE в MySQL │
│ │ │ 3.23. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│07 │ SLAVE_EVENT │ Зарезервовано для майбутнього використання. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│08 │ CREATE_FILE_EVENT │ Використовується для ЗАВАНТАЖЕННЯ ДАНИХ │
│ │ │ INFILE │
│ │ │ твердження. Це вказує на │
│ │ │ початок │
│ │ │ виконання такої заяви. А │
│ │ │ тимчасовий │
│ │ │ створюється файл │
│ │ │ на раба. Використовується лише в MySQL 4. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│09 │ APPEND_BLOCK_EVENT │ Містить дані для використання в │
│ │ │ ЗАВАНТАЖУВАТИ ДАНІ │
│ │ │ INFILE │
│ │ │ заяву. Дані зберігаються в │
│ │ │ тимчасовий │
│ │ │ файл на веденому. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│0a │ EXEC_LOAD_EVENT │ Використовується для ЗАВАНТАЖЕННЯ ДАНИХ │
│ │ │ INFILE │
│ │ │ твердження. Вміст │
│ │ │ тимчасовий файл │
│ │ │ зберігається в таблиці на веденому. │
│ │ │ Використовується в MySQL 4 │
тільки │ │ │. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│0b │ DELETE_FILE_EVENT │ Відкат ЗАВАНТАЖЕННЯ ДАНИХ │
│ │ │ INFILE │
│ │ │ заява. Тимчасовий файл │
│ │ │ має бути │
│ │ │ видалено на веденому. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│0c │ NEW_LOAD_EVENT │ Використовується для ЗАВАНТАЖЕННЯ ДАНИХ │
│ │ │ INFILE в MySQL │
│ │ │ 4 і раніше. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│0d │ RAND_EVENT │ Використовується для надсилання інформації про │
│ │ │ випадкові значення, якщо │
│ │ │ функція RAND() │
│ │ │ є │
│ │ │ використовується в │
│ │ │ заяву. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│0e │ USER_VAR_EVENT │ Використовується для реплікації змінних користувача. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│0f │ FORMAT_DESCRIPTION_EVENT │ Це вказує на початок журналу │
│ │ │ файл, написаний MySQL 5 або новішої версії. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│10 │ XID_EVENT │ Подія, що вказує на вчинення XA │
│ │ │ транзакція. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│11 │ BEGIN_LOAD_QUERY_EVENT │ Використовується для ЗАВАНТАЖЕННЯ ДАНИХ │
│ │ │ INFILE │
│ │ │ оператори в MySQL 5 і новіших версій. │
├─────┼───────────────────────────┼─────────────── ───────────────────────┤
│12 │ EXECUTE_LOAD_QUERY_EVENT │ Використовується для ЗАВАНТАЖЕННЯ ДАНИХ │
│ │ │ 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 │ Інцидент_ПОДІЯ │ Щось незвичайне │
│ │ │ сталося. Додано в MySQL 5.1.18. │
└─────┴───────────────────────────┴─────────────── ────────────────────────┘

· Master ID: ідентифікатор сервера головного, який створив подію.

· Розмір: Розмір події в байтах.

· Master Pos: позиція наступної події в оригінальному файлі головного журналу.

· Прапори: 16 прапорів. Наразі використовуються наступні прапори. Інші зарезервовані для
майбутнє використання.

┌─────┬──────────────────────────────┬──────────── ────────────────────────────────────┐
│Прапор │ ІМ'Я │ Сенс │
├─────┼──────────────────────────────┼──────────── ────────────────────────────────────┤
│01 │ LOG_EVENT_BINLOG_IN_USE_F │ Файл журналу правильний │
│ │ │ закритий. (Використовується тільки в │
│ │ │ FORMAT_DESCRIPTION_ПОДІЯ.) │
│ │ │ Якщо │
│ │ │ це │
│ │ │ встановлено (якщо │
│ │ │ прапори — це, наприклад, │
│ │ │ '01 │
│ │ │ 00') в │
│ │ │ FORMAT_DESCRIPTION_ПОДІЯ, │
│ │ │ колода │
│ │ │ файл │
│ │ │ не було належним чином │
│ │ │ закритий. Швидше за все │
│ │ │ це │
│ │ │ це через майстра │
│ │ │ аварії (наприклад, через │
│ │ │ до │
│ │ │ збій живлення). │
├─────┼──────────────────────────────┼──────────── ────────────────────────────────────┤
│02 │ │ Зарезервовано для використання в майбутньому. │
├─────┼──────────────────────────────┼──────────── ────────────────────────────────────┤
│04 │ LOG_EVENT_THREAD_SPECIFIC_F │ Встановити, якщо подія залежить від │
│ │ │ з’єднання виконано в (для │
│ │ │ наприклад, '04 00'), для │
│ │ │ приклад, │
│ │ │, якщо в події використовується │
│ │ │ тимчасові таблиці. │
├─────┼──────────────────────────────┼──────────── ────────────────────────────────────┤
│08 │ LOG_EVENT_SUPPRESS_USE_F │ Встановлюється за деяких обставин, коли подія │
│ │ │ не залежить від значення за замовчуванням │
│ │ │ база даних. │
└─────┴─────────────────────────────┴───────────── ────────────────────────────────────┘

MYSQLBINLOG ROW EVENT DISPLAY

Наведені нижче приклади ілюструють, як mysqlbinlog відображає події рядка, які вказують дані
модифікації. Вони відповідають подіям з WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT,
та коди типів DELETE_ROWS_EVENT. The --base64-output=DECODE-ROWS та -багатослівний опції
може використовуватися для впливу на виведення подій рядка.

Припустимо, що сервер використовує двійкове ведення журналу на основі рядків і ви виконуєте файл
наступна послідовність висловлювань:

СТВОРИТИ ТАБЛИЦЮ t
(
id INT NOT NULL,
ім'я ВАРЧАР(20) НЕ НУЛЬ,
дата DATE NULL
) ДВИГУН = InnoDB;
ПОЧАТИ транзакцію;
INSERT INTO t VALUES(1, 'apple', NULL);
UPDATE t SET name = 'pear', date = '2009-01-01' WHERE id = 1;
ВИДАЛИТИ З t, ДЕ id = 1;
COMMIT;

За замовчуванням mysqlbinlog відображає події рядка, закодовані як рядки base-64 за допомогою BINLOG
заяви. Опускаючи сторонні рядки, вихід для подій рядка, створених
попередня послідовність операторів виглядає так:

оболонка> mysqlbinlog log_file
...
№ на 218
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 258 Write_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
...
№ на 302
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 356 Update_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAAAEA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
...
№ на 400
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 442 Delete_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAAAEAA//4AQAAAARwZWFyIbIP
'/*!*/;

Щоб побачити події рядка як коментарі у вигляді операторів «псевдо-SQL», запустіть mysqlbinlog
з -багатослівний or -v варіант. Вихід міститиме рядки, які починаються з ###:

оболонка> mysqlbinlog -v log_file
...
№ на 218
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 258 Write_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
### INSERT INTO test.t
### НАБІР
### @1=1
### @2='яблуко'
### @3=НУЛЬ
...
№ на 302
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 356 Update_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAAAEA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
### ОНОВЛЕННЯ test.t
### ДЕ
### @1=1
### @2='яблуко'
### @3=НУЛЬ
### НАБІР
### @1=1
### @2='груша'
### @3='2009:01:01'
...
№ на 400
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 442 Delete_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAAAEAA//4AQAAAARwZWFyIbIP
'/*!*/;
### ВИДАЛИТИ З test.t
### ДЕ
### @1=1
### @2='груша'
### @3='2009:01:01'

Вказувати -багатослівний or -v двічі, щоб також відобразити типи даних і деякі метадані для кожного
колонка. Вихідні дані будуть містити додатковий коментар після кожної зміни стовпця:

оболонка> mysqlbinlog -вв log_file
...
№ на 218
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 258 Write_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
### INSERT INTO test.t
### НАБІР
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='яблуко' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
...
№ на 302
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 356 Update_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAAAEA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
### ОНОВЛЕННЯ test.t
### ДЕ
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='яблуко' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
### НАБІР
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='груша' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */
...
№ на 400
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 442 Delete_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAAAEAA//4AQAAAARwZWFyIbIP
'/*!*/;
### ВИДАЛИТИ З test.t
### ДЕ
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='груша' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */

Ви можете сказати mysqlbinlog щоб придушити оператори BINLOG для подій рядка за допомогою
--base64-output=DECODE-ROWS варіант. Це схоже на --base64-output=НІКОЛИ але не робить
вийти з помилкою, якщо знайдено подію рядка. Поєднання з --base64-output=DECODE-ROWS
та -багатослівний забезпечує зручний спосіб перегляду подій рядка лише як операторів SQL:

оболонка> mysqlbinlog -v --base64-output=DECODE-ROWS log_file
...
№ на 218
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 258 Write_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
### INSERT INTO test.t
### НАБІР
### @1=1
### @2='яблуко'
### @3=НУЛЬ
...
№ на 302
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 356 Update_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
### ОНОВЛЕННЯ test.t
### ДЕ
### @1=1
### @2='яблуко'
### @3=НУЛЬ
### НАБІР
### @1=1
### @2='груша'
### @3='2009:01:01'
...
№ на 400
#080828 15:03:08 ідентифікатор сервера 1 end_log_pos 442 Delete_rows: ідентифікатор таблиці 17 прапори: STMT_END_F
### ВИДАЛИТИ З test.t
### ДЕ
### @1=1
### @2='груша'
### @3='2009:01:01'

примітки
Ви не повинні придушувати оператори BINLOG, якщо ви маєте намір повторно виконати mysqlbinlog
вихід.

Операції SQL, створені за допомогою -багатослівний для row події набагато легше читаються, ніж
відповідні заяви BINLOG. Однак вони не зовсім відповідають оригіналу
Операції SQL, які генерували події. Застосовуються такі обмеження:

· Оригінальні назви стовпців втрачено та замінено на @N, Де N є номером стовпця.

· Інформація про набір символів недоступна в двійковому журналі, що впливає на рядок
відображення стовпців:

· Немає різниці між відповідним двійковим і небінарним рядком
типи (BINARY і CHAR, VARBINARY і VARCHAR, BLOB і TEXT). Вихід використовує a
тип даних STRING для рядків фіксованої довжини і VARSTRING для рядків змінної довжини
струни.

· Для багатобайтових наборів символів максимальна кількість байтів на символ не є
присутній у двійковому журналі, тому довжина типів рядків відображається в байтах
а не в символах. Наприклад, STRING(4) буде використано як тип даних
для значень із будь-якого з цих типів стовпців:

CHAR(4) НАбір символів latin1
CHAR(2) НАбір символів ucs2

· Через формат зберігання подій типу UPDATE_ROWS_EVENT, оператори UPDATE
відображаються з реченням WHERE перед реченням SET.

Для належної інтерпретації подій рядка потрібна інформація з опису формату
подія на початку двійкового журналу. Тому що mysqlbinlog не знає наперед
чи решта журналу містить події рядка, за замовчуванням він відображає формат
опис події з використанням оператора BINLOG у початковій частині виводу.

Якщо відомо, що двійковий журнал не містить подій, що вимагають оператора BINLOG (це
є, немає подій рядка), the --base64-output=НІКОЛИ параметр можна використовувати, щоб запобігти цьому заголовку
від написаного.

ВИКОРИСТАННЯ MYSQLBINLOG TO НАЗАД UP BINARY ВХІД ФАЙЛИ

За замовчуванням mysqlbinlog читає двійкові файли журналу та відображає їх вміст у текстовому форматі.
Це дає змогу легше переглядати події у файлах і виконувати їх повторно
(наприклад, використовуючи вихід як вхід до MySQL). mysqlbinlog може читати файли журналів
безпосередньо з локальної файлової системи, або за допомогою --читання-з-віддаленого-сервера варіант, можна
підключитися до сервера та запитати вміст двійкового журналу з цього сервера. mysqlbinlog пише
виведення тексту на його стандартний вихід або у файл, названий як значення
--result-file=ім'я файлу варіант, якщо такий варіант надано.

Станом на MySQL 5.6, mysqlbinlog може читати двійкові файли журналу та записувати нові файли, що містять файли
той самий вміст, тобто у двійковому форматі, а не в текстовому. Ця можливість дозволяє
Ви можете легко створити резервну копію двійкового журналу в оригінальному форматі. mysqlbinlog може зробити статичність
резервне копіювання, створення резервної копії набору файлів журналів і зупинка, коли закінчиться останній файл
досягнуто. Він також може робити безперервне ("живе") резервне копіювання, залишаючись підключеним до сервера
коли він досягає кінця останнього файлу журналу і продовжує копіювати нові події як вони є
згенеровано. У режимі безперервного резервного копіювання, mysqlbinlog працює до завершення з’єднання (для
наприклад, коли сервер завершує роботу) або mysqlbinlog примусово припинено. При з'єднанні
закінчується, mysqlbinlog не чекає і не повторює з'єднання, на відміну від підпорядкованої реплікації
сервер. Щоб продовжити резервне копіювання в реальному часі після перезавантаження сервера, ви також повинні
перезапуск mysqlbinlog.

Для резервного копіювання двійкового журналу потрібно викликати mysqlbinlog як мінімум з двома варіантами:

· --читання-з-віддаленого-сервера (Або -R) опція розповідає mysqlbinlog для підключення до сервера
і запитати його двійковий журнал. (Це схоже на підключення підпорядкованого сервера реплікації
на головний сервер.)

· -сирий опція розповідає mysqlbinlog записувати необроблений (двійковий) вихід, а не текстовий.

Разом з --читання-з-віддаленого-сервера, зазвичай вказуються інші параметри: --господар
вказує, де працює сервер, а також може знадобитися вказати параметри підключення
такий як --користувач та --пароль.

Кілька інших варіантів корисні разом з -сирий:

· --стоп-ніколи: Залишайтеся на зв'язку з сервером після досягнення кінця останнього файлу журналу
і продовжуйте читати нові події.

· --stop-never-slave-id-server=id: ідентифікатор сервера mysqlbinlog звітує на сервер
коли --стоп-ніколи використовується. За замовчуванням – 65535. Це можна використовувати, щоб уникнути конфлікту
з ідентифікатором підпорядкованого сервера чи іншого mysqlbinlog процес. Дивіться розділ під назвою
«ВКАЗАННЯ ІДЕНТИФІКАЦІЇ СЕРВЕРА MYSQLBINLOG».

· --результат-файл: префікс для імен вихідних файлів, як описано далі.

Щоб створити резервну копію файлів двійкового журналу сервера за допомогою mysqlbinlog, ви повинні вказати імена файлів, які
фактично існують на сервері. Якщо ви не знаєте імен, підключіться до сервера і використовуйте
оператор SHOW BINARY LOGS, щоб побачити поточні імена. Припустимо, що твердження
виробляє цей результат:

mysql> ШОУ BINARY КОЛОДИ;
+--------------+-----------+
| Ім'я_журналу | Розмір_файлу |
+--------------+-----------+
| binlog.000130 | 27459 |
| binlog.000131 | 13719 |
| binlog.000132 | 43268 |
+--------------+-----------+

Маючи цю інформацію, ви можете скористатися mysqlbinlog щоб створити резервну копію двійкового журналу до поточного
каталог таким чином (введіть кожну команду в одному рядку):

· Щоб створити статичну резервну копію від binlog.000130 до binlog.000132, скористайтеся одним із цих
команди:

mysqlbinlog --read-from-remote-server --host=ім'я_хоста -сирий
binlog.000130 binlog.000131 binlog.000132
mysqlbinlog --read-from-remote-server --host=ім'я_хоста -сирий
--to-last-log binlog.000130

Перша команда вказує кожне ім'я файлу явно. Другий називає тільки
перший файл і використання --до останнього журналу щоб прочитати останнє. Різниця між цими
команди полягає в тому, що якщо сервер відкриває binlog.000133 раніше mysqlbinlog
досягне кінця binlog.000132, перша команда не прочитає його, а друга
команда буде.

· Зробити живу резервну копію, в якій mysqlbinlog починається з binlog.000130 для копіювання існуючого
файли журналів, а потім залишається на зв’язку для копіювання нових подій, коли сервер їх генерує:

mysqlbinlog --read-from-remote-server --host=ім'я_хоста -сирий
--stop-never binlog.000130

з --стоп-ніколи, уточнювати не потрібно --до останнього журналу читати до останнього
файл журналу, оскільки ця опція мається на увазі.
Іменування вихідного файлу.PP Без -сирий, mysqlbinlog виводить текст і
--результат-файл Параметр, якщо він заданий, визначає ім’я окремого файлу, до якого виводяться всі дані
написано. З -сирий, mysqlbinlog записує один двійковий вихідний файл для кожного файлу журналу
передано з сервера. За замовчуванням, mysqlbinlog записує файли в поточний
каталог з тими ж іменами, що й оригінальні файли журналу. Щоб змінити імена вихідних файлів,
використовувати --результат-файл варіант. В поєднанні з -сирий, --результат-файл значення опціону
розглядається як префікс, який змінює імена вихідних файлів.

Припустимо, що на даний момент сервер має двійкові файли журналу з іменем binlog.000999 і вище. Якщо ви
використання mysqlbinlog -сирий для резервного копіювання файлів, --результат-файл Параметр створює вихідний файл
назви, як показано в наступній таблиці. Ви можете записати файли в певний каталог за допомогою
початок --результат-файл значення із шляхом до каталогу. Якщо --результат-файл значення
складається лише з імені каталогу, значення має закінчуватися роздільником імені шляху
характер. Вихідні файли перезаписуються, якщо вони існують.

┌─────────────────────┬────────────────────────── ─┐
│--результат-файл Варіант │ Вихід філе імен │
├─────────────────────┼────────────────────────── ─┤
│--result-file=x │ xbinlog.000999 і вище │
├─────────────────────┼────────────────────────── ─┤
│--result-file=/ tmp / │ /tmp/binlog.000999 і вище │
├─────────────────────┼────────────────────────── ─┤
│--result-file=/tmp/x │ /tmp/xbinlog.000999 і вище │
└─────────────────────┴────────────────────────── ─┘
Приклад: mysqldump + mysqlbinlog для резервного копіювання та відновлення.PP У наступному прикладі описано
простий сценарій, який показує, як користуватися mysqldump та mysqlbinlog разом для резервного копіювання a
дані сервера та двійковий журнал, а також як використовувати резервну копію для відновлення сервера у разі втрати даних
відбувається. У прикладі передбачається, що сервер працює на хості ім'я_хоста і його перший
двійковий файл журналу має назву binlog.000999. Введіть кожну команду в одному рядку.

Скористайтесь mysqlbinlog щоб зробити безперервну резервну копію двійкового журналу:

mysqlbinlog --read-from-remote-server --host=ім'я_хоста -сирий
--stop-never binlog.000999

Скористайтесь mysqldump щоб створити файл дампа як знімок даних сервера. Використовуйте
--усі бази даних, --події та -- рутини створити резервну копію всіх даних, і --master-data=2 до
включити поточні двійкові координати журналу у файл дампа.

mysqldump --host=ім'я_хоста --all-databases --events --routines --master-data=2> dump_file

Виконайте mysqldump періодично створювати нові знімки за бажанням.

Якщо сталася втрата даних (наприклад, у разі аварійного завершення роботи сервера), використовуйте найновіший файл дампу
відновити дані:

mysql --host=ім'я_хоста -u корінь -п dump_file

Потім використовуйте резервну копію двійкового журналу, щоб повторно виконати події, які були записані після
координати, зазначені у файлі дампа. Припустимо, що координати у файлі виглядають так
це:

-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.001002', MASTER_LOG_POS=27284;

Якщо останній створений файл журналу має ім’я binlog.001004, повторно виконайте події журналу
подобається це:

mysqlbinlog --start-position=27284 binlog.001002 binlog.001003 binlog.001004
| mysql --host=ім'я_хоста -u корінь -п

Можливо, вам буде простіше скопіювати файли резервної копії (файл дампа та двійкові файли журналу) до файлу
сервера, щоб полегшити виконання операції відновлення, або якщо MySQL не дозволяє
віддалений root-доступ.

УКАЗАННЯ THE MYSQLBINLOG SERVER ID

При виклику з --читання-з-віддаленого-сервера варіант mysqlbinlog підключається до MySQL
server, вказує ідентифікатор сервера, щоб ідентифікувати себе, і запитує двійкові файли журналу з
сервер. Ви можете використовувати mysqlbinlog запитувати файли журналів із сервера кількома способами:

· Вкажіть явно названий набір файлів: для кожного файлу, mysqlbinlog з'єднує і
видає команду дампу Binlog. Сервер надсилає файл і відключається. Є один
підключення на файл.

· Вкажіть початковий файл і --до останнього журналу: mysqlbinlog підключає та видає Binlog
команда dump для всіх файлів. Сервер надсилає всі файли та відключається.

· Вкажіть початковий файл і --стоп-ніколи (що передбачає --до останнього журналу): mysqlbinlog
підключає та видає команду дампу Binlog для всіх файлів. Сервер надсилає всі файли,
але не відключається після надсилання останнього.

з --читання-з-віддаленого-сервера тільки mysqlbinlog підключається за допомогою ідентифікатора сервера 0, який
повідомляє серверу про відключення після надсилання останнього запитаного файлу журналу.

з --читання-з-віддаленого-сервера та --стоп-ніколи, mysqlbinlog з’єднується за допомогою відмінного від нуля
Ідентифікатор сервера, тому сервер не відключається після надсилання останнього файлу журналу. Сервер
Ідентифікатор за замовчуванням 65535, але його можна змінити за допомогою --stop-never-slave-id-сервера.

Таким чином, для перших двох способів запиту файлів сервер відключається через те, що
mysqlbinlog вказує ідентифікатор сервера 0. Він не відключається, якщо --стоп-ніколи дається
оскільки mysqlbinlog визначає ненульовий ідентифікатор сервера.

АВТОРСЬКЕ

Авторське право © 1997, 2014, Oracle та/або її філії. Всі права захищені.

Ця документація є безкоштовним програмним забезпеченням; ви можете розповсюджувати його та/або змінювати лише під
умови Загальної публічної ліцензії GNU, опубліковані Фондом вільного програмного забезпечення;
версія 2 Ліцензії.

Ця документація поширюється в надії, що вона буде корисною, але БЕЗ НІЯКОГО
ГАРАНТІЯ; навіть без неявної гарантії про придатність до продажу або придатність для певної
МЕТА. Дивіться Загальну публічну ліцензію GNU для більш детальної інформації.

Ви повинні були отримати копію Загальної публічної ліцензії GNU разом із програмою;
якщо ні, напишіть до Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301 США або див http://www.gnu.org/licenses/.

ПРИМІТКИ

1. Внутрішня частина MySQL: двійковий журнал
http://dev.mysql.com/doc/internals/en/binary-log.html

Використовуйте mysqlbinlog онлайн за допомогою служб onworks.net