mysqlbinlog - Интернет в облаке

ПРОГРАММА:

ИМЯ

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

СИНТАКСИС

mysqlbinlog [опции] журнальный файл ...

ОПИСАНИЕ

Бинарный журнал сервера состоит из файлов, содержащих «события», описывающие модификации.
к содержимому базы данных. Сервер записывает эти файлы в двоичном формате. Чтобы показать свои
содержимое в текстовом формате, используйте mysqlbinlog полезность. Вы также можете использовать mysqlbinlog в
отображать содержимое файлов журнала реле, записанных подчиненным сервером в настройке репликации
потому что журналы реле имеют тот же формат, что и двоичные журналы. Двоичный журнал и журнал реле
обсуждается далее в Раздел 5.2.4, «Двоичный журнал» и Раздел 17.2.2, «Репликация
Журналы реле и состояния ».

взывать mysqlbinlog как это:

оболочка> mysqlbinlog [кредита] журнальный файл ...

Например, чтобы отобразить содержимое двоичного файла журнала с именем binlog.000003, используйте это
команда:

оболочка> mysqlbinlog бинлог.0000003

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

Событиям предшествуют комментарии заголовков, которые предоставляют дополнительную информацию. Например:

№ в 141
# 100309 9:28:36 id сервера 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-output =ценностное

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

· AUTO («автоматически») или UNSPEC («не указано») отображает операторы BINLOG
автоматически при необходимости (т. е. для событий описания формата и строки
Мероприятия). Если нет --base64-вывод дается опция, эффект такой же, как
--base64-output = АВТО.

Внимание
Автоматическое отображение BINLOG - единственное безопасное поведение, если вы собираетесь использовать
выход mysqlbinlog для повторного выполнения содержимого двоичного файла журнала. Другой вариант
значения предназначены только для целей отладки или тестирования, потому что они могут
производить вывод, который не включает все события в исполняемой форме.

· НИКОГДА не приводит к тому, что операторы BINLOG не отображаются. mysqlbinlog выходит с
ошибка, если обнаружено событие строки, которое необходимо отобразить с помощью BINLOG.

· DECODE-ROWS указывает на mysqlbinlog что вы собираетесь декодировать события строки
и отображается как закомментированные операторы SQL, также указывая --подробный опцию.
Как и НИКОГДА, DECODE-ROWS подавляет отображение операторов BINLOG, но, в отличие от НИКОГДА,
он не завершается с ошибкой, если обнаружено событие строки.

Для примеров, демонстрирующих эффект --base64-вывод и --подробный событие в строке
вывод см. в разделе «ОТОБРАЖЕНИЕ СОБЫТИЯ MYSQLBINLOG ROW».

· --bind-адрес =айпи адрес

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

Эта опция поддерживается, начиная с MySQL 5.6.1.

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

┌─────────────────────┬───────────────────────────── ──────────────┐
│Командная строка Формат │ --binlog-row-event-max-size = # │
├─────────────────────┼────────────────────────────── ──────────────┤
│ │ Разрешенный Наши ценности │
│ ├────────────────────┬───────────────────────┤
│ │ Платформа Немного Размер │ 64 │
│ ├────────────────────┼───────────────────────┤
│ │ Тип │ числовой │
│ ├────────────────────┼───────────────────────┤
│ │ По умолчанию │ 4294967040 │
│ ├────────────────────┼───────────────────────┤
│ │ Мин. Значение │ 256 │
│ ├────────────────────┼───────────────────────┤
│ │ Max Значение │ 18446744073709547520 │
└─────────────────────────────────────────┴──────── ──────────────
Укажите максимальный размер события двоичного журнала на основе строк в байтах. Строки сгруппированы
по возможности на мероприятия меньшего размера. Значение должно быть кратным 256.
По умолчанию - 4 ГБ.

· --character-sets-dir =путь

Каталог, в котором установлены наборы символов. См. Раздел 10.5, «Набор символов.
Конфигурация ».

· --connection-server-id =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.

· --database =имя_базы_данных, -d имя_базы_данных

Эта опция вызывает mysqlbinlog для вывода записей из двоичного журнала (только локальный журнал)
что происходит пока имя_базы_данных выбрана USE в качестве базы данных по умолчанию.

The --база данных вариант для mysqlbinlog похож на --binlog-do-db вариант для
туздЫ, но может использоваться для указания только одной базы данных. Если --база данных дается несколько
раз используется только последний экземпляр.

Эффект от этой опции зависит от того, ведется ли журнал на основе операторов или на основе строк.
формат используется так же, как эффекты --binlog-do-db зависит от того,
ведение журнала на основе операторов или строк.

На основе заявления каротаж, --база данных вариант работает следующим образом:

· В то время как имя_базы_данных является базой данных по умолчанию, операторы выводятся независимо от того, изменяют ли они
таблицы в имя_базы_данных или другую базу данных.

· Пока не имя_базы_данных выбрана в качестве базы данных по умолчанию, операторы не выводятся,
даже если они изменяют таблицы в имя_базы_данных.

· Есть исключение для CREATE DATABASE, ALTER DATABASE и DROP DATABASE. В
база данных создан, изменено, or сократилось считается по умолчанию
база данных при определении, выводить ли выписку.

Предположим, что двоичный журнал был создан путем выполнения этих операторов с использованием
ведение журнала на основе операторов:

ВСТАВИТЬ test.t1 (i) ЦЕННОСТИ:(100);
ВСТАВИТЬ В db2.t2 (j) ЦЕННОСТИ:(200);
ЕГЭ тест;
ВСТАВИТЬ test.t1 (i) ЦЕННОСТИ:(101);
ВСТАВИТЬ В t1 (i) ЦЕННОСТИ:(102);
ВСТАВИТЬ В db2.t2 (j) ЦЕННОСТИ:(201);
ИСПОЛЬЗОВАТЬ db2;
ВСТАВИТЬ 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 test, но выводит три оператора INSERT после USE db2.

По строкам каротаж. mysqlbinlog выводит только записи, которые изменяют таблицы, принадлежащие
имя_базы_данных. База данных по умолчанию на это не влияет. Предположим, что двоичный журнал просто
описанный был создан с использованием записи в журнал на основе строк, а не записи в журнале на основе операторов.
mysqlbinlog --database = тест выводит только те записи, которые изменяют t1 в тесте
база данных, независимо от того, был ли выдан USE или какова база данных по умолчанию. Если
сервер работает с binlog_format, установленным на MIXED, и вы хотите, чтобы можно было
используют mysqlbinlog с --база данных вариант, вы должны убедиться, что таблицы,
измененные находятся в базе данных, выбранной USE. (В частности, нет кросс-базы данных
следует использовать обновления.)

До MySQL 5.6.10 --база данных опция не работала правильно с записанным логом
сервером MySQL с поддержкой GTID. (Ошибка # 15912728)

· --debug [=параметры_отладки], -# [параметры_отладки]

Напишите журнал отладки. Типичный параметры_отладки строка d: t: o,file_name. По умолчанию
это d: t: o, / tmp / mysqlbinlog.trace.

· --отладка-проверка

Распечатайте некоторую отладочную информацию при выходе из программы.

· --debug-информация

Распечатать отладочную информацию и статистику использования памяти и ЦП, когда программа
выходы.

· --default-auth =плагин

Плагин аутентификации на стороне клиента, который нужно использовать. См. Раздел 6.3.7, «Подключаемый
Аутентификация".

Эта опция была добавлена ​​в MySQL 5.6.2.

· --defaults-extra-file =file_name

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

· --defaults-file =file_name

Используйте только указанный файл опций. Если файл не существует или иначе
недоступен, возникает ошибка. file_name интерпретируется относительно текущего
каталог, если указан как относительный путь, а не как полное имя пути.

· --defaults-group-суффикс =ул

Читайте не только обычные группы опций, но и группы с обычными названиями и
суффикс ул, Например, mysqlbinlog обычно читает [client] и [mysqlbinlog]
группы. Если --defaults-group-suffix = _другой предоставляется вариант, mysqlbinlog также читает
группы [client_other] и [mysqlbinlog_other].

· --disable-log-bin, -D

Отключите двоичное ведение журнала. Это полезно для предотвращения бесконечного цикла, если вы используете
--to-последний-лог вариант и отправляют вывод на тот же сервер MySQL. Этот вариант
также полезно при восстановлении после сбоя, чтобы избежать дублирования операторов, которые вы
вошли.

Эта опция требует, чтобы у вас была СУПЕР привилегия. Это приводит mysqlbinlog в
включить в свой вывод оператор SET sql_log_bin = 0, чтобы отключить двоичное ведение журнала
оставшийся выход. Оператор SET неэффективен, если у вас нет SUPER
привилегия.

· --exclude-gtids =gtid_set

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

· --force-if-open, -F

Читайте двоичные файлы журнала, даже если они открыты или не были закрыты должным образом.

· - принудительное чтение, -f

С этой опцией, если mysqlbinlog читает событие двоичного журнала, которое не распознает,
он выводит предупреждение, игнорирует событие и продолжает работу. Без этой опции
mysqlbinlog останавливается, если читает такое событие.

· --шестнадцатеричный дамп, -H

Отобразите шестнадцатеричный дамп журнала в комментариях, как описано в разделе, называемом
«MYSQLBINLOG HEX DUMP FORMAT». Шестнадцатеричный вывод может быть полезен для репликации
отладка.

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

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

· --include-gtids =gtid_set

Отображать только группы, перечисленные в gtid_set. Добавлено в MySQL 5.6.5.

· --local-load =путь, -l путь

Подготовьте локальные временные файлы для ЗАГРУЗКИ ДАННЫХ INFILE в указанном каталоге.

Важнo
Эти временные файлы не удаляются автоматически mysqlbinlog или любой другой
Программа MySQL.

· --login-path =имя

Прочтите параметры из указанного пути входа в файл входа .mylogin.cnf. «Путь для входа»
- это группа опций, которая допускает только ограниченный набор опций: кашель, пользователь и
password. Думайте о пути входа в систему как о наборе значений, которые указывают хост сервера и
учетные данные для аутентификации на сервере. Чтобы создать файл пути входа, используйте
mysql_config_editor утилита. Видеть mysql_config_editor(1). Эта опция была добавлена ​​в
MySQL 5.6.6.

· --нет-по умолчанию

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

Исключением является то, что файл .mylogin.cnf, если он существует, читается во всех случаях. Этот
позволяет указывать пароли более безопасным способом, чем в командной строке, даже если
--нет-по умолчанию используется. (.mylogin.cnf создается mysql_config_editor утилита.
Посмотреть mysql_config_editor(1)).

· --offset =N, -o N

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

· --password [=password], -п[password]

Пароль для использования при подключении к серверу. Если вы используете короткую форму выбора
(-p), ты не могу между параметром и паролем должен быть пробел. Если вы опустите
password значение после --пароль or -p опция в командной строке, mysqlbinlog
подсказки для одного.

Указание пароля в командной строке следует считать небезопасным. Видеть
Раздел 6.1.2.1, «Рекомендации конечного пользователя по защите паролем». Вы можете использовать опцию
файл, чтобы не вводить пароль в командной строке.

· --plugin-dir =путь

Каталог, в котором нужно искать плагины. Возможно, потребуется указать эту опцию
если --default-авторизация опция используется для указания плагина аутентификации, но
mysqlbinlog не находит. См. Раздел 6.3.7, «Подключаемая аутентификация».

Эта опция была добавлена ​​в MySQL 5.6.2.

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

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

· --print-по умолчанию

Выведите имя программы и все параметры, которые она получает из файлов параметров.

· --protocol = {TCP | РОЗЕТКА | ТРУБКА | ПАМЯТЬ}

Протокол подключения, используемый для подключения к серверу. Это полезно, когда
другие параметры соединения обычно приводят к использованию протокола, отличного от
тот, который вы хотите. Подробнее о допустимых значениях см. Раздел 4.2.2, «Подключение к
Сервер MySQL ».

· --сырой

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

Эта опция была добавлена ​​в MySQL 5.6.0.

· --read-от-удаленного-мастера =напишите

Чтение двоичных журналов с сервера 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 записывает один двоичный выходной файл для каждого файла журнала
передаются с сервера, записывая их по умолчанию в текущий каталог, используя
те же имена, что и у исходного файла журнала. В этом случае --result-файл значение опции
рассматривается как префикс, изменяющий имена выходных файлов.

· --secure-аутентификация

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

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

· --server-id =id

Отображать только те события, которые созданы сервером с заданным ID сервера.

· --server-id-биты =N

Используйте только первый N биты server_id для идентификации сервера. Если двоичный журнал
был написан туздЫ с установленными битами идентификатора сервера менее 32 и сохраненными пользовательскими данными
в старшем разряде выполняется mysqlbinlog --идентификатор-сервера-биты установить в 32
позволяет видеть эти данные.

Эта опция поддерживается только версиями mysqlbinlog поставляется с MySQL
Кластерный дистрибутив или построенный из источников MySQL Cluster.

· --set-charset =имя_кодировки

Добавить НАБОР ИМЕНИ имя_кодировки оператор для вывода, чтобы указать набор символов для
использоваться для обработки файлов журнала.

· --shared-memory-base-имя =имя

В Windows имя совместно используемой памяти, используемое для подключений с использованием общей памяти к
локальный сервер. Значение по умолчанию - MYSQL. Имя совместно используемой памяти чувствительно к регистру.

Сервер должен быть запущен с --Общая память возможность включить разделяемую память
соединений.

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

Отображать только утверждения, содержащиеся в журнале, без какой-либо дополнительной информации или
события на основе строк. Это только для тестирования и не должно использоваться в продакшене.
систем.

· --skip-gtids [= (истина | ложь)]

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

оболочка> mysqlbinlog --skip-gtids бинлог.000001 > /tmp/dump.sql
оболочка> mysqlbinlog --skip-gtids бинлог.000002 >> /tmp/dump.sql
оболочка> mysql -u корень -p -e "источник /tmp/dump.sql "

В противном случае использование этой опции в производственной среде обычно не рекомендуется.

Эта опция была добавлена ​​в MySQL 5.6.5.

· --socket =путь, -S путь

Для подключений к localhost используется файл сокета Unix или, в Windows, имя
именованный канал для использования.

· --start-datetime =Дата и время

Начните читать двоичный журнал при первом событии с отметкой времени равной или более поздней.
чем Дата и время аргумент. В Дата и время значение относительно местного часового пояса на
машина, на которой ты бежишь mysqlbinlog. Значение должно быть в формате, приемлемом для
типы данных DATETIME или TIMESTAMP. Например:

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

Эта опция полезна для восстановления на определенный момент времени. См. Раздел 7.3, «Пример резервного копирования и
Стратегия восстановления ».

· --start-position =N, -j N

Начните чтение двоичного журнала с первого события, имеющего позицию, равную или большую
чем N. Этот параметр применяется к первому файлу журнала, указанному в командной строке.

Эта опция полезна для восстановления на определенный момент времени. См. Раздел 7.3, «Пример резервного копирования и
Стратегия восстановления ».

· --stop-datetime =Дата и время

Прекратить чтение двоичного журнала при первом событии с отметкой времени равной или более поздней.
чем Дата и время аргумент. Эта опция полезна для восстановления на определенный момент времени. Увидеть
описание --start-дата/время вариант для получения информации о Дата и время значения.

Эта опция полезна для восстановления на определенный момент времени. См. Раздел 7.3, «Пример резервного копирования и
Стратегия восстановления ».

· - стоп-никогда

Эта опция используется с - читать с удаленного сервера. Оно говорит mysqlbinlog оставаться
подключен к серверу. В противном случае mysqlbinlog завершается, когда последний файл журнала был
перенесено с сервера. - стоп-никогда подразумевает --to-последний-лог, так что только первый
Имя файла журнала для передачи необходимо указать в командной строке.

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

Эта опция была добавлена ​​в MySQL 5.6.0.

· --stop-never-slave-server-идентификатор =id

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

Эта опция была добавлена ​​в MySQL 5.6.0.

· --stop-position =N

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

Эта опция полезна для восстановления на определенный момент времени. См. Раздел 7.3, «Пример резервного копирования и
Стратегия восстановления ».

· --to-последний-лог, -t

Не останавливайтесь в конце запрошенного двоичного журнала с сервера MySQL, а лучше
продолжить печать до конца последнего двоичного журнала. Если вы отправите вывод в
тот же сервер MySQL, это может привести к бесконечному циклу. Этот вариант требует
- читать с удаленного сервера.

· --user =user_name, -u user_name

Имя пользователя MySQL для использования при подключении к удаленному серверу.

· --подробный, -v

Восстановите события строки и отобразите их как закомментированные операторы SQL. Если эта опция
заданный дважды, вывод включает комментарии для обозначения типов данных столбца и некоторых
метаданные.

Для примеров, демонстрирующих эффект --base64-вывод и --подробный событие в строке
вывод см. в разделе «ОТОБРАЖЕНИЕ СОБЫТИЯ MYSQLBINLOG ROW».

· --verify-binlog-контрольная сумма, -c

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

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

Вывести информацию о версии и выйти.

До MySQL 5.6.11 mysqlbinlog Показанный номер версии - 3.3. В MySQL 5.6.11
и позже, это 3.4. (Ошибка № 15894381, Ошибка № 67643)

Вы также можете установить следующую переменную, используя --имя_переменной=ценностное синтаксис:

· Open_files_limit

Укажите количество дескрипторов открытых файлов, которые нужно зарезервировать.

Вы можете направить вывод mysqlbinlog в mysql клиент для выполнения событий
содержится в двоичном журнале. Этот метод используется для восстановления после сбоя, когда у вас
старая резервная копия (см. Раздел 7.5, «Моментальное (инкрементное) восстановление с использованием двоичного
Бревно"). Например:

оболочка> mysqlbinlog бинлог.000001 | mysql -u корень -p

Или:

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

Если заявления, представленные mysqlbinlog могут содержать значения BLOB, это может вызвать
проблемы, когда mysql обрабатывает их. В этом случае вызовите mysql с - двоичный режим
опцию.

Вы также можете перенаправить вывод mysqlbinlog вместо этого в текстовый файл, если вам нужно
сначала измените журнал операторов (например, чтобы удалить операторы, которые вы не хотите
выполнить по какой-то причине). После редактирования файла выполните содержащиеся в нем операторы.
используя его в качестве входных данных для mysql программа:

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

После появления mysqlbinlog вызывается с - начальная позиция вариант, он отображает только те
события со смещением в двоичном журнале, большим или равным заданной позиции (
данная позиция должна соответствовать началу одного события). У него также есть варианты остановки и запуска
когда он видит событие с заданной датой и временем. Это позволяет вам выполнять
восстановление на определенный момент времени с помощью --stop-дата-время вариант (чтобы иметь возможность сказать, например,
«Переверните мои базы данных к тому состоянию, в котором они были сегодня, в 10:30»).

Если у вас есть более одного двоичного журнала для выполнения на сервере MySQL, безопасным методом является
обрабатывать их все, используя одно соединение с сервером. Вот пример того, что
демонстрирует, что может быть небезопасный:

оболочка> mysqlbinlog бинлог.000001 | mysql -u корень -p # ОПАСНОСТЬ!!
оболочка> mysqlbinlog бинлог.000002 | mysql -u корень -p # ОПАСНОСТЬ!!

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

Чтобы избежать подобных проблем, используйте одинарной mysql процесс для выполнения содержимого всех
двоичные журналы, которые вы хотите обработать. Вот один из способов сделать это:

оболочка> mysqlbinlog бинлог.000001 бинлог.000002 | mysql -u корень -p

Другой подход - записать все журналы в один файл, а затем обработать файл:

оболочка> mysqlbinlog бинлог.000001 > /tmp/statements.sql
оболочка> mysqlbinlog бинлог.000002 >> /tmp/statements.sql
оболочка> mysql -u корень -p -e "источник /tmp/statements.sql "

mysqlbinlog может производить вывод, который воспроизводит операцию LOAD DATA INFILE без
исходный файл данных. mysqlbinlog копирует данные во временный файл и записывает ЗАГРУЗИТЬ
DATA LOCAL INFILE инструкция, которая ссылается на файл. Расположение каталога по умолчанию
место записи этих файлов зависит от системы. Чтобы явно указать каталог, используйте
--local-load опцию.

Так как mysqlbinlog преобразует операторы LOAD DATA INFILE в LOAD DATA LOCAL INFILE
операторов (то есть добавляет LOCAL), клиент и сервер, которые вы используете для
процесс, операторы должны быть настроены с включенной возможностью LOCAL. Видеть
Раздел 6.1.6, «Проблемы безопасности с ЛОКАЛЬНЫМИ ДАННЫМИ ЗАГРУЗКИ».

Предупреждение
Временные файлы, созданные для операторов LOAD DATA LOCAL: автоматически
удаляются, потому что они необходимы, пока вы не выполните эти операторы. Ты
следует удалить временные файлы самостоятельно после того, как вам больше не нужен журнал операторов.
Файлы находятся в каталоге временных файлов и имеют такие имена, как
исходное_имя_файла - # - #.

МYSQLBINLOG HEX DUMP ФОРМАТ

The --шестнадцатеричный дамп Вариант причины mysqlbinlog для создания шестнадцатеричного дампа содержимого двоичного журнала:

оболочка> mysqlbinlog --шестнадцатеричный дамп мастер-бункер.000001

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

/ *! 40019 SET @@ session.max_insert_delayed_threads = 0 * /;
/ *! 50003 SET @OLD_COMPLETION_TYPE = @@ COMPLETION_TYPE, COMPLETION_TYPE = 0 * /;
№ в 4
# 051024 17:24:13 id сервера 1 end_log_pos 98
# Позиция Временная метка Тип Master ID Размер 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 ... |
# Старт: binlog v 4, server v 5.0.15-debug-log created 051024 17:24:13
# при запуске
ОТКАТ;

Вывод шестнадцатеричного дампа в настоящее время содержит элементы из следующего списка. Этот формат
могут быть изменены. (Для получения дополнительной информации о двоичном формате журнала см. MySQL Внутреннее: The
Двоичный Журнал[1].

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

· Отметка времени: отметка времени события. В показанном примере '9d fc 5c 43' - это
представление "051024 17:24:13" в шестнадцатеричном формате.

· Тип: код типа события. В показанном примере '0f' обозначает
FORMAT_DESCRIPTION_EVENT. В следующей таблице перечислены возможные коды типов.

┌─────┬───────────────────────────┬───────────────── ───────────────────────
│Тип │ Имя │ Смысл │
├─────┼───────────────────────────┼───────────────── ───────────────────────┤
│00 │ UNKNOWN_EVENT │ Это событие не должно
│ │ │ присутствовать в журнале. │
├─────┼───────────────────────────┼───────────────── ───────────────────────┤
│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 │ Используется для ЗАГРУЗКИ ДАННЫХ │
│ │ │ ИНФАЙЛ │
│ │ │ заявления. Это указывает на │
│ │ │ начало │
│ │ │ исполнение такого заявления. А │
│ │ │ временный │
│ │ │ файл создан │
│ │ │ на раб. Используется только в MySQL 4. │
├─────┼───────────────────────────┼───────────────── ───────────────────────┤
│09 │ APPEND_BLOCK_EVENT │ Содержит данные для использования в │
│ │ │ ЗАГРУЗИТЬ ДАННЫЕ │
│ │ │ ИНФАЙЛ │
│ │ │ заявление. Данные хранятся в │
│ │ │ временное │
│ │ │ файл на раб. │
├─────┼───────────────────────────┼───────────────── ───────────────────────┤
│0a │ EXEC_LOAD_EVENT │ Используется для ЗАГРУЗКИ ДАННЫХ │
│ │ │ ИНФАЙЛ │
│ │ │ заявления. Содержимое
│ │ │ временный файл │
│ │ │ хранится в таблице на ведомом устройстве. │
│ │ │ Используется в MySQL 4 │
Только │ │ │. │
├─────┼───────────────────────────┼───────────────── ───────────────────────┤
│0b │ DELETE_FILE_EVENT │ Откат ЗАГРУЗКИ ДАННЫХ │
│ │ │ ИНФАЙЛ │
│ │ │ заявление. Временный файл │
│ │ │ должно быть │
│ │ │ удалил на раб. │
├─────┼───────────────────────────┼───────────────── ───────────────────────┤
│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 │ Используется для ЗАГРУЗКИ ДАННЫХ │
│ │ │ ИНФАЙЛ │
Операторы │ │ │ в MySQL 5 и новее. │
├─────┼───────────────────────────┼───────────────── ───────────────────────┤
│12 │ EXECUTE_LOAD_QUERY_EVENT │ Используется для ЗАГРУЗКИ ДАННЫХ │
│ │ │ ИНФАЙЛ │
Операторы │ │ │ в 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. │
└─────┴───────────────────────────┴───────────────── ───────────────────────

· Идентификатор мастера: идентификатор сервера мастера, создавшего событие.

· Размер: размер события в байтах.

· Master Pos: позиция следующего события в исходном главном файле журнала.

· Флаги: 16 флагов. В настоящее время используются следующие флаги. Остальные зарезервированы для
будущее использование.

┌─────┬──────────────────────────────┬────────────── ─────────────────────────────────────
│Флаг │ Имя │ Смысл │
├─────┼──────────────────────────────┼────────────── ─────────────────────────────────────
│01 │ LOG_EVENT_BINLOG_IN_USE_F Файл журнала правильно │
│ │ │ закрыто. (Используется только в │
│ │ │ FORMAT_DESCRIPTION_EVENT.) │
│ │ │ Если │
│ │ │ это │
│ │ флаг установлен (если │
│ │ │ флаги - это, например, │
│ │ │ '01 │
│ │ │ 00 ') в │
│ │ │ FORMAT_DESCRIPTION_EVENT, │
│ │ │ бревно │
│ │ │ файл │
│ │ │ не был должным образом │
│ │ │ закрыто. Скорее всего │
│ │ │ это │
│ │ │ это из-за мастера │
│ │ │ сбой (например, из-за │
│ │ │ в │
│ │ │ сбой питания). │
├─────┼──────────────────────────────┼────────────── ─────────────────────────────────────
│02 │ │ Зарезервировано для использования в будущем. │
├─────┼──────────────────────────────┼────────────── ─────────────────────────────────────
│04 │ LOG_EVENT_THREAD_SPECIFIC_F │ Устанавливается, если событие зависит от │
│ │ │ соединение, в котором он был выполнен (для │
│ │ │ например, '04 00 '), для │
│ │ │ пример, │
│ │ │, если в событии используется │
│ │ │ временные таблицы. │
├─────┼──────────────────────────────┼────────────── ─────────────────────────────────────
│08 │ LOG_EVENT_SUPPRESS_USE_F │ Устанавливается в некоторых случаях, когда событие │
│ │ │ не зависит от значения по умолчанию │
│ │ │ база данных. │
└─────┴──────────────────────────────┴────────────── ─────────────────────────────────────

МYSQLBINLOG РЯД СОБЫТИЕ ДИСПЛЕЙ

Следующие примеры показывают, как mysqlbinlog отображает события строки, которые определяют данные
модификации. Они соответствуют событиям с WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT,
и коды типа DELETE_ROWS_EVENT. В --base64-output = ДЕКОДИРОВАТЬ-СТРОКИ и --подробный кредита
может использоваться для воздействия на вывод событий строки.

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

СОЗДАТЬ ТАБЛИЦУ t
(
идентификатор INT NOT NULL,
имя ВАРЧАР(20) НЕ NULL,
дата DATE NULL
) ДВИГАТЕЛЬ = InnoDB;
НАЧАТЬ СДЕЛКУ;
INSERT INTO t VALUES (1, 'яблоко', NULL);
ОБНОВЛЕНИЕ t SET name = 'pear', date = '2009-01-01' WHERE id = 1;
УДАЛИТЬ ИЗ t WHERE id = 1;
СОВЕРШИТЬ;

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

оболочка> mysqlbinlog журнальный файл
...
№ в 218
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 258 Write_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA // 8AQAAAAVhcHBsZQ ==
'/ *! * /;
...
№ в 302
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 356 Update_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA //// AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/ *! * /;
...
№ в 400
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 442 Delete_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA // 4AQAAAARwZWFyIbIP
'/ *! * /;

Чтобы увидеть события строки как комментарии в форме операторов «псевдо-SQL», запустите mysqlbinlog
с --подробный or -v вариант. Вывод будет содержать строки, начинающиеся с ###:

оболочка> mysqlbinlog -v журнальный файл
...
№ в 218
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 258 Write_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA // 8AQAAAAVhcHBsZQ ==
'/ *! * /;
### ВСТАВИТЬ В test.t
### НАБОР
### @ 1 = 1
### @ 2 = 'яблоко'
### @ 3 = NULL
...
№ в 302
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 356 Update_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA //// AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/ *! * /;
### ОБНОВЛЕНИЕ test.t
### ГДЕ
### @ 1 = 1
### @ 2 = 'яблоко'
### @ 3 = NULL
### НАБОР
### @ 1 = 1
### @ 2 = 'груша'
### @ 3 = '2009: 01: 01'
...
№ в 400
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 442 Delete_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA // 4AQAAAARwZWFyIbIP
'/ *! * /;
### УДАЛИТЬ ИЗ test.t
### ГДЕ
### @ 1 = 1
### @ 2 = 'груша'
### @ 3 = '2009: 01: 01'

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

оболочка> mysqlbinlog -вв журнальный файл
...
№ в 218
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 258 Write_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA // 8AQAAAAVhcHBsZQ ==
'/ *! * /;
### ВСТАВИТЬ В test.t
### НАБОР
### @ 1 = 1 / * INT meta = 0 обнуляемый = 0 is_null = 0 * /
### @ 2 = 'яблоко' / * ВАРСТРИНГ(20) meta = 20 обнуляемый = 0 is_null = 0 * /
### @ 3 = NULL / * ВАРСТРИНГ(20) meta = 0 обнуляемый = 1 is_null = 1 * /
...
№ в 302
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 356 Update_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA //// AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/ *! * /;
### ОБНОВЛЕНИЕ test.t
### ГДЕ
### @ 1 = 1 / * INT meta = 0 обнуляемый = 0 is_null = 0 * /
### @ 2 = 'яблоко' / * ВАРСТРИНГ(20) meta = 20 обнуляемый = 0 is_null = 0 * /
### @ 3 = NULL / * ВАРСТРИНГ(20) meta = 0 обнуляемый = 1 is_null = 1 * /
### НАБОР
### @ 1 = 1 / * INT meta = 0 обнуляемый = 0 is_null = 0 * /
### @ 2 = 'груша' / * ВАРСТРИНГ(20) meta = 20 обнуляемый = 0 is_null = 0 * /
### @ 3 = '2009: 01: 01' / * DATE meta = 0 обнуляемый = 1 is_null = 0 * /
...
№ в 400
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 442 Delete_rows: идентификатор таблицы 17 флаги: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ =
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA // 4AQAAAARwZWFyIbIP
'/ *! * /;
### УДАЛИТЬ ИЗ test.t
### ГДЕ
### @ 1 = 1 / * INT meta = 0 обнуляемый = 0 is_null = 0 * /
### @ 2 = 'груша' / * ВАРСТРИНГ(20) meta = 20 обнуляемый = 0 is_null = 0 * /
### @ 3 = '2009: 01: 01' / * DATE meta = 0 обнуляемый = 1 is_null = 0 * /

Ты можешь сказать mysqlbinlog для подавления операторов BINLOG для событий строки с помощью
--base64-output = ДЕКОДИРОВАТЬ-СТРОКИ вариант. Это похоже на --base64-output = НИКОГДА но не
выйти с ошибкой, если найдено событие строки. Сочетание --base64-output = ДЕКОДИРОВАТЬ-СТРОКИ
и --подробный предоставляет удобный способ видеть события строк только в виде операторов SQL:

оболочка> mysqlbinlog -v --base64-output = ДЕКОДИРОВАТЬ-СТРОКИ журнальный файл
...
№ в 218
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 258 Write_rows: идентификатор таблицы 17 флаги: STMT_END_F
### ВСТАВИТЬ В test.t
### НАБОР
### @ 1 = 1
### @ 2 = 'яблоко'
### @ 3 = NULL
...
№ в 302
# 080828 15:03:08 идентификатор сервера 1 end_log_pos 356 Update_rows: идентификатор таблицы 17 флаги: STMT_END_F
### ОБНОВЛЕНИЕ test.t
### ГДЕ
### @ 1 = 1
### @ 2 = 'яблоко'
### @ 3 = NULL
### НАБОР
### @ 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, создаваемые --подробный для событий строки гораздо более читабельны, чем
соответствующие операторы BINLOG. Однако они не совсем соответствуют оригиналу.
Операторы SQL, которые сгенерировали события. Применяются следующие ограничения:

· Исходные имена столбцов теряются и заменяются @N, Где N - номер столбца.

· Информация о наборе символов недоступна в двоичном журнале, что влияет на строку
отображение столбцов:

· Нет различий между соответствующей двоичной и недвоичной строкой
типы (BINARY и CHAR, VARBINARY и VARCHAR, BLOB и TEXT). На выходе используется
тип данных STRING для строк фиксированной длины и VARSTRING для строк переменной длины
строки.

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

CHAR(4) НАБОР СИМВОЛОВ latin1
CHAR(2) НАБОР ПЕРСОНАЖЕЙ ucs2

· Из-за формата хранения событий типа UPDATE_ROWS_EVENT, операторы UPDATE
отображаются с предложением WHERE перед предложением SET.

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

Если известно, что двоичный журнал не содержит событий, требующих оператора BINLOG (что
есть, нет событий строки), --base64-output = НИКОГДА опция может использоваться для предотвращения этого заголовка
от написания.

С ПОМОЩЬЮ МYSQLBINLOG К НАЗАД UP BINARY ВХОД FILES

По умолчанию mysqlbinlog читает двоичные файлы журналов и отображает их содержимое в текстовом формате.
Это позволяет вам легче исследовать события в файлах и повторно выполнять их.
(например, используя вывод как ввод для mysql). mysqlbinlog может читать файлы журналов
непосредственно из локальной файловой системы или с помощью - читать с удаленного сервера вариант, это может
подключиться к серверу и запросить содержимое двоичного журнала с этого сервера. mysqlbinlog пишет
вывод текста на стандартный вывод или в файл, названный как значение параметра
--result-file =file_name вариант, если этот вариант предоставляется.

Начиная с MySQL 5.6, mysqlbinlog может читать двоичные файлы журнала и записывать новые файлы, содержащие
то же содержание, то есть в двоичном формате, а не в текстовом формате. Эта возможность позволяет
вы можете легко создать резервную копию двоичного журнала в его исходном формате. mysqlbinlog может сделать статический
резервное копирование, резервное копирование набора файлов журнала и остановка, когда конец последнего файла
достиг. Он также может делать непрерывное («живое») резервное копирование, оставаясь подключенным к серверу.
когда он достигает конца последнего файла журнала и продолжает копировать новые события, как они есть
сгенерировано. В режиме непрерывного резервного копирования mysqlbinlog работает до тех пор, пока соединение не завершится (для
например, когда сервер выходит) или mysqlbinlog прекращается принудительно. Когда связь
заканчивается, mysqlbinlog не ждет и не повторяет попытку подключения, в отличие от ведомой репликации
сервер. Чтобы продолжить резервное копирование в реальном времени после перезапуска сервера, вы также должны
перезапуск mysqlbinlog.

Для резервного копирования двоичного журнала требуется, чтобы вы вызывали mysqlbinlog как минимум с двумя вариантами:

· The - читать с удаленного сервера (или -R) опция сообщает mysqlbinlog подключиться к серверу
и запросить его двоичный журнал. (Это похоже на подключение подчиненного сервера репликации
к своему главному серверу.)

· The --сырой вариант говорит mysqlbinlog для записи сырого (двоичного) вывода, а не текстового вывода.

Наряду с - читать с удаленного сервера, обычно указываются другие параметры: --хозяин
указывает, где работает сервер, и вам также может потребоваться указать параметры подключения
как --Пользователь и --пароль.

Несколько других опций полезны в сочетании с --сырой:

· - стоп-никогда: Оставайтесь на связи с сервером после достижения конца последнего файла журнала
и продолжаем читать новые события.

· --stop-never-slave-server-идентификатор =id: ID сервера, который mysqlbinlog отчеты на сервер
когда - стоп-никогда используется. По умолчанию - 65535. Это можно использовать, чтобы избежать конфликта.
с идентификатором подчиненного сервера или другого mysqlbinlog процесс. См. Раздел под названием
«УКАЗАНИЕ ИДЕНТИФИКАЦИИ СЕРВЕРА MYSQLBINLOG».

· --result-файл: Префикс для имен выходных файлов, как описано ниже.

Для резервного копирования двоичных файлов журнала сервера с помощью mysqlbinlog, вы должны указать имена файлов,
реально существуют на сервере. Если вы не знаете имена, подключитесь к серверу и используйте
оператор SHOW BINARY LOGS, чтобы увидеть текущие имена. Предположим, что утверждение
производит этот вывод:

mysql> ОТКРЫТЬ BINARY ЖУРНАЛЫ;
+ --------------- + ----------- +
| Имя_журнала | Размер_файла |
+ --------------- + ----------- +
| бинлог.000130 | 27459 |
| бинлог.000131 | 13719 |
| бинлог.000132 | 43268 |
+ --------------- + ----------- +

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

· Чтобы сделать статическую резервную копию binlog.000130 через binlog.000132, используйте любой из этих
команды:

mysqlbinlog --read-с-удаленного-сервера --host =имя_хоста --сырой
бинлог.000130 бинлог.000131 бинлог.000132
mysqlbinlog --read-с-удаленного-сервера --host =имя_хоста --сырой
--to-last-log binlog.000130

Первая команда явно указывает имя каждого файла. Второй называет только
первый файл и использует --to-последний-лог прочитать последнее. Разница между этими
командами является то, что если сервер откроет binlog.000133 раньше mysqlbinlog
достигает конца binlog.000132, первая команда его не прочитает, а вторая
команда будет.

· Сделать живую резервную копию, в которой mysqlbinlog начинается с binlog.000130 для копирования существующего
log файлы, а затем остается подключенным для копирования новых событий по мере их генерации сервером:

mysqlbinlog --read-с-удаленного-сервера --host =имя_хоста --сырой
--stop-никогда binlog.000130

Для пользователя - стоп-никогда, указывать не обязательно --to-последний-лог читать до последнего
log, потому что эта опция подразумевается.
Имя выходного файла.PP Без --сырой, mysqlbinlog производит вывод текста и
--result-файл опция, если задана, указывает имя единственного файла, в который выводятся все
написано. С участием --сырой, mysqlbinlog записывает один двоичный выходной файл для каждого файла журнала
перенесено с сервера. По умолчанию, mysqlbinlog записывает файлы в текущий
каталог с теми же именами, что и исходные файлы журнала. Чтобы изменить имена выходных файлов,
использовать --result-файл вариант. В сочетании с --сырой, --result-файл стоимость опциона
рассматривается как префикс, изменяющий имена выходных файлов.

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

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

Используйте mysqlbinlog чтобы сделать непрерывную резервную копию двоичного журнала:

mysqlbinlog --read-с-удаленного-сервера --host =имя_хоста --сырой
--stop-никогда binlog.000999

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

mysqldump --host =имя_хоста --all-databases --events --routines --master-data = 2> дамп_файл

Выполнить mysqldump команда периодически для создания новых снимков по желанию.

Если происходит потеря данных (например, если сервер выходит из строя), используйте самый последний файл дампа, чтобы
восстановить данные:

mysql --host =имя_хоста -u корень -p дамп_файл

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

- ИЗМЕНИТЬ МАСТЕРА НА MASTER_LOG_FILE = 'binlog.001002', MASTER_LOG_POS = 27284;

Если самый последний файл журнала из резервной копии называется binlog.001004, повторно выполните журнал событий.
как это:

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

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

УКАЗАНИЕ МYSQLBINLOG SERVER ID

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

· Укажите явно названный набор файлов: для каждого файла mysqlbinlog соединяет и
выдает команду дампа Binlog. Сервер отправляет файл и отключается. Существует один
соединение на файл.

· Укажите начальный файл и --to-последний-лог: mysqlbinlog подключает и выдает Binlog
команда дампа для всех файлов. Сервер отправляет все файлы и отключается.

· Укажите начальный файл и - стоп-никогда (что подразумевает --to-последний-лог): mysqlbinlog
подключает и выдает команду дампа Binlog для всех файлов. Сервер отправляет все файлы,
но не отключается после отправки последнего.

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

Для пользователя - читать с удаленного сервера и - стоп-никогда, mysqlbinlog подключается с использованием ненулевого
идентификатор сервера, чтобы сервер не отключился после отправки последнего файла журнала. Сервер
По умолчанию ID 65535, но его можно изменить с помощью --stop-never-slave-id-сервера.

Таким образом, для первых двух способов запроса файлов сервер отключается, потому что
mysqlbinlog указывает идентификатор сервера 0. Он не отключается, если - стоп-никогда дано
потому что mysqlbinlog указывает ненулевой идентификатор сервера.

АВТОРСКИЕ ПРАВА

Авторские права © 1997, 2014, Oracle и / или ее дочерние компании. Все права защищены.

Эта документация является бесплатным программным обеспечением; вы можете распространять и / или изменять его только под
условия Стандартной общественной лицензии GNU, опубликованной Free Software Foundation;
версия 2 Лицензии.

Эта документация распространяется в надежде, что она будет полезной, но БЕЗ КАКИХ-ЛИБО
ГАРАНТИЯ; без даже подразумеваемой гарантии ТОВАРНОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОГО
ЦЕЛЬ. Подробнее см. Стандартную общественную лицензию GNU.

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

ПРИМЕЧАНИЯ

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

Использование mysqlbinlog в Интернете с помощью сервисов onworks.net