Бинарное логирование служит механизмом восстановления данных таблиц реального времени. При включённом бинарном логировании searchd записывает каждую транзакцию в binlog-файл и использует его для восстановления после некорректного завершения работы. При корректном завершении работы данные из RAM-чанов сохраняются на диск, а все binlog-файлы удаляются.
По умолчанию бинарное логирование включено для защиты целостности данных. В системах Linux стандартное расположение файлов binlog.* в Plain режиме находится в /var/lib/manticore/data/. В RT режиме бинарные логи хранятся в каталоге <data_dir>/binlog/, если не указано иное.
Для глобального отключения бинарного логирования установите binlog_path в пустое значение в конфигурации searchd.
Отключение бинарного логирования требует перезапуска демона и повышает риск потери данных при внезапном отключении системы.
- Example
searchd {
...
binlog_path = # disable logging
...Для задания пользовательского пути можно использовать следующую директиву:
- Example
searchd {
...
binlog_path = /var/data
...Для более гибкого управления бинарное логирование можно отключить на уровне таблиц реального времени, установив параметр таблицы binlog в значение 0. Эта опция недоступна для таблиц типа percolate.
- Example
create table a (id bigint, s string attribute) binlog='0';Для существующих RT-таблиц бинарное логирование также можно отключить, изменив параметр binlog.
- Example
alter table FOO binlog='0';Если бинарное логирование было ранее отключено, его можно вновь включить, установив параметр binlog обратно в 1:
- Example
alter table FOO binlog='1';- Зависимость от глобальных настроек: параметры бинарного логирования на уровне таблиц действуют только если бинарное логирование глобально включено в конфигурации searchd (
binlog_pathне должен быть пустым). - Статус бинарного логирования и идентификатор транзакции: изменение статуса бинарного логирования таблицы вызывает немедленный принудительный сброс таблицы. Если выключить бинарное логирование для таблицы, её идентификатор транзакции (TID) меняется на
-1. Это означает, что бинарное логирование не активно и изменения не отслеживаются. Если же включить бинарное логирование для таблицы, её идентификатор транзакции становится неотрицательным числом (ноль или больше). Это указывает, что изменения таблицы теперь записываются. Проверить идентификатор транзакции можно командой:SHOW TABLE <name> STATUS. Значение TID отражает ведется ли запись изменений (неотрицательное число) или нет (-1).
При включённом бинарном логировании каждое изменение RT-таблицы сохраняется в лог-файл. Если система неожиданно выключается, эти логи автоматически используются при следующем запуске для восстановления всех записанных изменений.
Во время обычной работы, когда объём записанных данных достигает определённого предела (устанавливаемого параметром binlog_max_log_size), начинается новый лог-файл. Старые логи сохраняются до тех пор, пока все изменения в них полностью не обработаются и не сохранятся на диск в виде дискового чанка. Если этот предел установлен в 0, лог-файлы сохраняются пока система не будет корректно завершена. По умолчанию ограничений на размер файлов нет.
- Example
searchd {
...
binlog_max_log_size = 16M
....Каждый binlog-файл именуется с ведущими нулями, например binlog.0000, binlog.0001 и так далее, обычно с четырьмя цифрами. Количество цифр в номере файла можно изменить настройкой binlog_filename_digits. Если количество binlog-файлов превысит вместимость текущего количества цифр, количество цифр будет автоматически увеличено.
Важно: для изменения количества цифр необходимо сначала сохранить все данные таблиц и корректно завершить работу системы. Затем удалить старые лог-файлы и перезапустить систему.
- Example
searchd {
...
binlog_filename_digits = 6
...Вы можете выбрать один из двух способов управления бинарными лог-файлами с помощью директивы binlog_common:
- Отдельный файл на каждую таблицу (по умолчанию,
0): каждая таблица сохраняет изменения в собственном лог-файле. Такая конфигурация удобна, если у вас много таблиц, обновляющихся в разное время. Это позволяет обновлять таблицы независимо друг от друга. Также если возникает проблема с лог-файлом одной таблицы, это не влияет на другие. - Один файл для всех таблиц (
1): все таблицы используют один общий бинарный лог-файл. Этот метод упрощает работу с файлами, так как их меньше. Однако при этом файлы могут дольше храниться, если хотя бы одной таблице нужно сохранить обновления. Также данная настройка может замедлять работу при одновременном обновлении многих таблиц, так как все изменения должны записываться в один файл.
- binlog_common
searchd {
...
binlog_common = 1
...Существует четыре различных стратегии сброса бинарного лога, которые регулируются директивой binlog_flush:
0- Данные записываются на диск (сбрасываются) каждую секунду, и Manticore инициирует их защиту на диске (синхронизацию) сразу после сброса. Этот метод самый быстрый, но если сервер или компьютер внезапно выйдут из строя, некоторые недавно записанные данные, которые не были защищены, могут быть потеряны.1- Данные записываются в binlog и синхронизируются сразу после каждой транзакции. Этот метод самый безопасный, так как гарантирует немедленное сохранение каждого изменения, но замедляет запись.2- Данные записываются после каждой транзакции, а синхронизация инициируется каждую секунду. Этот подход предлагает баланс, записывая данные регулярно и быстро. Однако, в случае сбоя компьютера, часть данных, которые находились в процессе защиты, может не успеть сохраниться. Кроме того, синхронизация может занимать больше одной секунды в зависимости от диска.3- Похоже на2, но также гарантирует, что файл binlog синхронизируется перед закрытием из-за превышенияbinlog_max_log_size.
Режим по умолчанию — 2, который записывает данные после каждой транзакции и запускает их синхронизацию каждую секунду, балансируя скорость и безопасность.
- Example
searchd {
...
binlog_flush = 1 # ultimate safety, low write speed
...
}В кластере с использованием Galera важна правильная обработка восстановления узла. Обычно Galera решает проблему рассогласования узла с помощью IST (incremental state transfer — инкрементальная передача состояния), если узел был корректно завершён и его последний номер последовательности (seqno) был правильно сохранён. Однако в случае сбоя, когда seqno не сохранён, Galera инициирует SST (state snapshot transfer — передача снимка состояния), что требует больших ресурсов и может значительно замедлить кластер из-за высокой активности ввода-вывода.
Для решения этой проблемы введена поддержка кластерного binlog. Эта функция расширяет существующую двоичную запись изменений, помогая снизить необходимость SST, позволяя восстанавливающемуся узлу воспроизводить недостающие транзакции из локальных binlog и снова присоединяться к кластеру с корректным seqno.
Кластерный binlog включен по умолчанию для любых операций кластера. Однако его можно отключить, установив переменную окружения:
- binlog_cluster
MANTICORE_REPLICATION_BINLOG=0Эта функция уменьшает время простоя и предотвращает полные передачи данных, сочетая локальную надежность двоичного журнала с возможностями распределённой синхронизации Galera.
При восстановлении после некорректного отключения binlog воспроизводится, и все зарегистрированные транзакции с момента последнего состоявшегося сохранения на диске восстанавливаются. Транзакции снабжены контрольными суммами, поэтому в случае повреждения файла binlog мусорные данные не будут воспроизведены; такая сломанная транзакция будет обнаружена и остановит воспроизведение.
Интенсивные обновления небольшой таблицы RT, полностью помещающейся в RAM-чунк, могут привести к постоянно растущему binlog, который невозможно удалить до чистого завершения работы. Binlog фактически служит в виде дельты, добавляемой к последнему известному хорошему состоянию на диске, и не может быть удалён, пока RAM-чунк не сохранён. Постоянно растущий binlog нежелателен с точки зрения использования диска и времени восстановления после сбоя. Для решения этой проблемы можно настроить searchd на периодический сброс RAM-чунк с помощью директивы rt_flush_period. При включённых периодических сбросах searchd запускает отдельный поток, проверяющий, нужно ли записать RAM-чунк RT таблицы обратно на диск. Как только это происходит, соответствующие binlog могут быть безопасно (и действительно) удалены.
Период сброса RT по умолчанию установлен на 10 часов.
- Example
searchd {
...
rt_flush_period = 3600 # 1 hour
...
}Важно отметить, что rt_flush_period контролирует лишь частоту проверок. Нет гарантий, что конкретный RAM-чунк будет сохранён. Например, бессмысленно регулярно пересохранять большой RAM-чунк, в который было сделано всего несколько обновлений строк. Manticore автоматически принимает решение о необходимости сброса, используя несколько эвристик.
Когда вы используете официальный образ Manticore для Docker, лог сервера отправляется в /dev/stdout, который можно просмотреть с хоста с помощью:
docker logs manticoreЛог запросов можно направить в лог Docker, передав переменную QUERY_LOG_TO_STDOUT=true.
Папка с логами такая же, как и в случае с пакетом для Linux, установлена в /var/log/manticore. При необходимости её можно смонтировать в локальный путь для просмотра или обработки логов.
Manticore Search принимает сигнал USR1 для повторного открытия файлов логов сервера и запросов.
Официальные DEB и RPM пакеты устанавливают файл конфигурации Logrotate для всех файлов в папке логов по умолчанию.
Простая конфигурация logrotate для файлов логов выглядит так:
/var/log/manticore/*.log {
weekly
rotate 10
copytruncate
delaycompress
compress
notifempty
missingok
}mysql> FLUSH LOGS;
Query OK, 0 rows affected (0.01 sec)Кроме того, доступна SQL команда FLUSH LOGS, которая работает так же, как системный сигнал USR1. Она инициирует повторное открытие файлов логов searchd и логов запросов, позволяя вам реализовать ротацию файлов логов. Команда неблокирующая (т.е., возвращает управление немедленно).