Как читать согласованную версию файлов sphinx при запуске reindex

Question

У меня возникают периодические проблемы с сценарием резервного копирования при попытке создать резервную копию файлов индекса sphinx. Команда резервного копирования более или менее просто tar команда на всех файлах в /var/lib/sphinxsearch/data с несколькими шаблонов исключения (spl, tmp и т.д ...)

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

• Для каждого индекса:
  • получить блокировку на файл .spl (мы надеемся, предотвращая REINDEX запуск одновременно)
  • Добавить связанные файлы (.spa, .spd, .sph, .spi, .spk, .spm, .spp, .sps) замок
  • релиз на .spl фил е

---

Меня беспокоит то, что я не могу найти какую-либо подробную документацию по точно, как предполагается файлы блокировка вести себя в сфинксе. Это будет инструмент, который взаимодействует с параллелизмом сфинкса на низком уровне, и я вижу много потенциальных ошибок (параллелизм меня пугает). Мне интересно, если:

1. Есть ли где-нибудь подробное описание того, как lockfiles работают в сфинксе?
2. Является ли мой план резервного копирования сфинкса даже правильным планом? Я огляделся по сторонам и не нашел ничего лучшего, но кто-то знает лучший способ.

Answer 1

AFAIK 'lockfile' - проверяется только на наличие. Файл существует, searchd активно служит индексу. Файл не существует, индекс безопасен для воссоздания на месте или удаляется и т. Д.

Индексатор отказывается переиндексировать индекс, если файл блокировки существует.

Но если вы укажете --rotate, вместо него будет создана совершенно новая версия индекса (с .new. В имени файла), ему будет все равно, существует ли файл блокировки, потому что он не касается существующего индекса.

и по завершении сигнала к поиску. SearchD затем удалить активный индекс, переименовывать файлы индекс, и служит новые версии (таким образом, чтобы не ПРЕРЫВАЙТЕ сервировки - и он также держит локировки на месте)

---

Так от этого единственного пути для остановки индексатора (при условии, что вы используете --rotate), нужно создать indexname.new.spl - я думаю, что это может сработать - но никогда не пробовали. Я не думаю, что это заметит, если вы что-то придумаете.

Лучше, но более хитроумный способ получения резервных копий с постоянными данными, может быть, перехватить сигнал от индексатора до searchd. Имейте процесс, который слушает sighup от индексатора, если резервная копия находится в процессе паузы, пока она не закончится, а затем отправьте sighup в searchd.

(Но это может занять какую-то работу, чтобы сделать индексатор отправить sighub вашего Intercepter, придется создать конфигурационный файл, с поддельной Pid-файлом. Поэтому его Идентификатор перехватчика не SearchD)

---

Конечно, больший вопрос, если ваши индексы могут быть воссозданы так легко (вы часто их повторяете), зачем им их подпирать? Если потеряно, то можно просто воссоздать.