Есть пять видов логов:
Все существующие файлы перечисляются в mysql-bin.index, поэтому если приходится удалять эти логи руками нужно не забывать подредактировать в соответствие индексный файл. Но это не хорошая идея, потому что мы можем привести в шок реплику, которая подключена к нашему серверу.
Эти файлы удаляются по истечению указанного времени или с помощью команды:
Нужно быть внимательным и не почистить бинарные логи, которые еще могла не подобрать реплика, нужно удалять меньшим диапазоном времени, чем настроена загрузка на реплике.
Бинарные реплики также чистяться командой:
-запустили мы мастер и слейв,
-настроили репликацию, выполнили пару изменяющих запросов, увидели эффект на слейве,
-отключили репликацию,
-почистили слейв,
-почистили мастер, выполнили ресет для мастера, да и можно для слейва тоже(RESET SLAVE - чистит Relay log и забывает позицию в выполненных запросах мастера ),
-и снова запустили репликацию.
Тут нужно обратить внимание, что разделять выполнение двух файлов бинарных логов очень опасно, потому что запросы из второго файла могут пользоваться верменными таблицами, которые будут удалены, при разрыве сессии.
Бинарные логи и восстановление упавшей базы
Сценарий следующий:
- база упала;
- мы восстанавливаем ее из сделанного дампа какое-то время назад;
- при этом было бы не плохо восстановить изменения, которые не попали в бекап, но при этом без запросов, которые завалили базу(может таких и не быть, если база упала из-за других причин).
- Для этого мы читаем бинарные логи с помощью mysqlbinlog, и определяем какой диапазон запросов нам нужен (при этом, чтобы быть более точным, нужно/можно испльзовать log_pos метки, а не время);
- выполняем только выбранный диапазон - восстановив состояние базы.
| Log Type | Information Written to Log |
|---|---|
| Error log | Problems encountered starting, running, or stopping mysqld |
| General query log | Established client connections and statements received from clients. Тоесть сдесь логируется все что запрашивается у mysqld, все запросы, а не только те, которые изменяют состояние базы, как в Binary log. |
| Binary log | Statements that change data (also used for replication). Риплика тоже может писать эти логи, если она находится в составе сложной цепочки реплик, и является мастером для другой реплики. |
| Relay log | Data changes received from a replication master server |
| Slow query log | Queries 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
Комментариев нет:
Отправить комментарий