Бинарное логирование служит механизмом восстановления данных таблиц реального времени. Когда бинарные логи включены, 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не должен быть пустым). - Статус бинарного логирования и информация о ID транзакции: изменение статуса бинарного логирования таблицы вызывает немедленный сброс таблицы. Если вы отключаете бинарное логирование для таблицы, её ID транзакции (TID) меняется на
-1. Это означает, что бинарное логирование не активно и изменения не отслеживаются. Напротив, если вы включаете бинарное логирование для таблицы, её ID транзакции становится неотрицательным числом (ноль или больше). Это означает, что изменения таблицы теперь записываются. Вы можете проверить ID транзакции с помощью команды:SHOW TABLE <name> STATUS. ID транзакции отражает, записываются ли изменения таблицы (неотрицательное число) или нет (-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, контролируемые директивой binlog_flush:
0- данные записываются на диск (сбрасываются) каждую секунду, и Manticore инициирует их защиту на диске (syncing) сразу после сброса. Этот метод самый быстрый, но если сервер или компьютер внезапно упадет, некоторые недавно записанные данные, которые еще не были защищены, могут быть потеряны.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 будет поддерживать отдельный поток, который проверяет, нужно ли записывать 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 и журнала запросов, что позволяет реализовать вращение файлов журнала. Команда не блокирующая (т.е. возвращается сразу).