среда, 27 ноября 2013 г.

Логи в MySQL

Есть пять видов логов:
Log TypeInformation Written to Log
Error logProblems encountered starting, running, or stopping mysqld
General query logEstablished client connections and statements received from clients. Тоесть сдесь логируется все что запрашивается у mysqld, все запросы, а не только те, которые изменяют состояние базы, как в Binary log.
Binary logStatements that change data (also used for replication). Риплика тоже может писать эти логи, если она находится в составе сложной цепочки реплик, и является мастером для другой реплики.
Relay logData changes received from a replication master server
Slow query logQueries that took more than long_query_time seconds to exe

Binary log

Они по умолчанию храняться в папке дата mysql, их формат mysql-bin.000001, mysql-bin.000002, mysql-bin.XXXXXX. Когда размер подбирается к указанному в настройках лимиту, создается новый файл(файл может быть и больше указанного рамера, по причине, что транзакции не разрываются и если транзакция началась до того, как файл превысил лимит, но новый файл не создается до тех пор, пока транзакция не закомититься).
Все существующие файлы перечисляются в mysql-bin.index, поэтому если приходится удалять эти логи руками нужно не забывать подредактировать в соответствие индексный файл. Но это не хорошая идея, потому что мы можем привести в шок реплику, которая подключена к нашему серверу.

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

PURGE BINARY LOGS TO 'mysql-bin.010';
Или
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';
При этом по смыслу можно понять, что индекс не пересечивается, а продолжается от последнего. Первый пример удаляет все логи с индексами от 1 до 9-ти включительно, а второй, все которые старше указанной даты.
Нужно быть внимательным и не почистить бинарные логи, которые еще могла не подобрать реплика, нужно удалять меньшим диапазоном времени, чем настроена загрузка на реплике.

Бинарные реплики также чистяться командой:

RESET MASTER
Эта команда предназначена для начала работы реплики, они стрирает все бинарные логи и чистит mysql-bin.index и скидывает идекс порядка к mysql-bin.000001. Эта команда для:
-запустили мы мастер и слейв,
-настроили репликацию, выполнили пару изменяющих запросов, увидели эффект на слейве,
-отключили репликацию,
-почистили слейв,
-почистили мастер, выполнили ресет для мастера, да и можно для слейва тоже(RESET SLAVE - чистит Relay log и забывает позицию в выполненных запросах мастера ),
-и снова запустили репликацию.

Формат бинарных логов

Логи пишутся в бинарном формате, а выше над ними в коменрариях есть расшифровка понятная для человека о событии, но не в формате скуель. Такой бинарный инпут майскуель умеет выполнять. Но мы не сможем увидеть эти коментарии просто открыв файл бинарного лога, для этого существует утилита mysqlbinlog  .  Именно аутпут этой утилиты mysql утилита может принять на инпут для выполнения.

shell> mysqlbinlog --start-datetime="2005-12-25 11:25:56" --stop-datetime="2005-12-29 11:25:56" some_remote_binlog.000001 some_remote_binlog.000002 | mysql -u root -p

Тут нужно обратить внимание, что разделять выполнение двух файлов бинарных логов очень опасно, потому что запросы из второго файла могут пользоваться верменными таблицами, которые будут удалены, при разрыве сессии.
shell> mysqlbinlog some_remote_binlog.000001 | mysql -u root -p # DANGER!!
shell> mysqlbinlog some_remote_binlog.000002 | mysql -u root -p # DANGER!!
Если есть необходимость всеже видеть изменения в виде SQL нужно выполнить:
shell> mysqlbinlog  --base64-output=DECODE-ROWS some_remote_binlog.000001
При этом мы теряем возможность выполнить такой аутпут, потому что скуель обвертывается символами коментирования.


Бинарные логи и восстановление упавшей базы
Сценарий следующий:
- база упала;
- мы восстанавливаем ее из сделанного дампа какое-то время назад;
- при этом было бы не плохо восстановить изменения, которые не попали в бекап, но при этом без запросов, которые завалили базу(может таких и не быть, если база упала из-за других причин).
- Для этого мы читаем бинарные логи с помощью mysqlbinlog, и определяем какой диапазон запросов нам нужен (при этом, чтобы быть более точным, нужно/можно испльзовать log_pos метки, а не время);
- выполняем только выбранный диапазон - восстановив состояние базы.
shell> mysqlbinlog --start-position=368315 --stop-position=368400 /var/log/mysql/bin.123456 \
         | mysql -u root -p

Комментариев нет:

Отправить комментарий