Самовосстановление

Arkvory сам перезапускает вышедшую из строя службу и возобновляет прерванную работу без участия оператора. На этой странице перечислено, что перезапускается, сколько длится каждое восстановление и какие проблемы всё равно требуют вашего вмешательства. Один сервер — это не система высокой доступности: перезапуск на короткое время прерывает соединения, а клиенты возобновляют свои передачи.

Что перезапускается само

Каждая служба работает под менеджером служб платформы. API, обработчик и агент резервного копирования завершают свой процесс, когда не могут безопасно продолжать работу. Тогда менеджер служб запускает новый процесс.

Ситуация	Linux (systemd)	Службы Windows	Docker Compose
Сбой, принудительное завершение, нехватка памяти	Перезапуск через 10 с	Перезапуск через 10 с	Движок перезапускает контейнер с нарастающей паузой
Выход без запроса на остановку, в том числе с кодом 0	Перезапуск	Программа запуска превращает выход в код 1, перезапуск через 10 с	Перезапуск
Потеряно владение хранилищем файлов или аренда	Выход с кодом 1, перезапуск	Выход с кодом 1, перезапуск	Выход с кодом 1, перезапуск
Завис основной поток	Сторожевой таймер завершает процесс, перезапуск	То же	То же
База данных недоступна при запуске	Выход с кодом 1, повтор каждые 10 с	Выход с кодом 1, повтор каждые 10 с	Выход с кодом 1, повтор с нарастающей паузой
Компьютер перезагружается	Службы включены в multi-user.target	Автоматически (отложенный запуск)	Вместе с движком контейнеров. Docker Desktop: после входа пользователя
Вы останавливаете службу	Остаётся остановленной до следующей загрузки	Остаётся остановленной до следующей загрузки	После docker compose stop остаётся остановленной

Проверка готовности, которая сама по себе не проходит, службу не перезапускает. Она может не проходить из-за того, что процесс завершает работу перед остановкой или что в каталоге хранилища файлов нет какой-то папки. Перезапуск эти причины не устранил бы.

Службы Windows

Графический установщик и install.ps1 регистрируют Arkvoryapi, Arkvoryworker и Arkvorybackup, которые работают под общей учётной записью NT AUTHORITY\LocalService, и службу базы данных Arkvorydatabase для управляемой базы данных. См. Windows.

• Тип запуска. API, обработчик и агент резервного копирования используют тип «Автоматически (отложенный запуск)». База данных — «Автоматически». Отложенный запуск означает, что службы поднимаются через некоторое время после загрузки, а не в тот же момент.
• Действия при сбое. После сбоя Windows перезапускает службу через 10 секунд. То же действие повторяется при каждом следующем сбое. Счётчик сбоев сбрасывается через час. Действия при сбое применяются и тогда, когда процесс завершается с кодом ошибки.
• Тайм-аут остановки. 120 секунд, чтобы выполняющийся запрос мог завершиться.
• Журналы. Вывод каждой службы попадает в logs\ и ротируется при 20 МиБ с хранением 5 старых файлов.

Показать действия службы при сбое:

sc.exe qfailure Arkvoryapi

Повторный запуск графического установщика восстанавливает типы запуска и действия при сбое. Служба, которую вы остановили сами, остаётся остановленной.

Юниты Linux systemd

Пакеты и install.sh создают arkvory-api, arkvory-worker и arkvory-backup, а также arkvory-database, если база данных управляемая.

• Restart=always с RestartSec=10 перезапускает API, обработчик и агент резервного копирования после любого выхода, который вы не запрашивали, в том числе с кодом 0.
• StartLimitIntervalSec=0 снимает предел попыток перезапуска, поэтому systemd никогда не отказывается от службы, которая постоянно падает. Постоянная неисправность, например неверная настройка, приводит к перезапуску каждые 10 секунд, пока вы её не устраните.
• Юнит базы данных использует Restart=on-failure с теми же 10 секундами.
• TimeoutStopSec=120 даёт останавливающейся службе две минуты.
• Юниты включены для multi-user.target.

systemctl is-enabled arkvory-api arkvory-worker arkvory-backup
systemctl status arkvory-api arkvory-worker arkvory-backup

Для служб, которыми управляет операционная система, поддерживается только systemd. В системе с другой системой инициализации используйте Docker Compose.

Docker Compose

Все службы проекта proanima-arkvory используют restart: unless-stopped. Одноразовые шаги initialize и migrate не перезапускаются.

• У контейнера API есть проверка состояния: каждые 10 секунд он запрашивает /health/ready с ключом состояния, а начальный период составляет 20 секунд. Контейнер с плохим состоянием помечается, но Docker его не перезапускает. При запуске обработчик ждёт, пока API станет исправным.
• На остановку контейнерам даётся 120 секунд.
• Движок контейнеров должен запускаться при загрузке. В Linux проверьте systemctl is-enabled docker. Arkvory движок не меняет.
• Docker Desktop в Windows — приложение одного пользователя. Ни один контейнер не работает, пока пользователь не вошёл в систему и Docker Desktop не запустился. Включите параметр Start Docker Desktop when you sign in. Установщик и arkvory status предупреждают, если он выключен. Для сервера, который должен запускаться без входа в систему, используйте нативные службы Windows.

Перезапуск после зависания

Процесс может перестать работать, не завершившись: бесконечный цикл, блокирующий вызов или зависание в нативном коде. Менеджер служб этого не видит, потому что процесс продолжает существовать. Поэтому у API, обработчика и агента резервного копирования есть сторожевой таймер.

1. Основной поток увеличивает счётчик раз в секунду.
2. Второй поток проверяет счётчик раз в секунду.
3. Когда счётчик не менялся ARKVORY_WATCHDOG_SECONDS проверок подряд (по умолчанию 60), сторожевой таймер записывает в стандартный вывод ошибок запись process.stalled с полем stalledSeconds и завершает процесс.
4. Менеджер служб перезапускает процесс, как после сбоя.

Сторожевой таймер считает собственные такты, а не астрономическое время. Когда узел засыпает или виртуальная машина приостановлена, оба потока останавливаются, и после пробуждения зависание не выдумывается. Поэтому зависание обходится в срок до 60 секунд плюс 10 секунд перезапуска.

ARKVORY_WATCHDOG_SECONDS принимает значения от 10 до 3600. Значение 0 выключает сторожевой таймер. Используйте его, только когда отладчик приостанавливает процесс, потому что процесс, остановленный дольше предела, перезапускается. Долгая блокирующая операция тоже считается зависанием. Если сам сторожевой таймер не запускается, служба записывает process.watchdog_failed и продолжает работать без него. У управляемого PostgreSQL сторожевого таймера нет. Его менеджер служб перезапускает после сбоя. См. Переменные окружения.

Потеря сессии базы данных или владения хранилищем файлов

API с помощью сессии базы данных доказывает, что он единственный пишущий процесс для каталога хранилища файлов. Сессия проверяется каждые 2 секунды, а проверка, которая не ответила за 8 секунд, считается потерянной. Обработчик подтверждает свою роль так же. Владение никогда не восстанавливается внутри работающего процесса, потому что его мог перехватить второй процесс.

Когда владение потеряно, например после перезапуска PostgreSQL, процесс:

1. записывает api.ownership_lost или worker.ownership_lost,
2. перестаёт принимать работу и отменяет передачи,
3. завершается с кодом 1.

Менеджер служб запускает новый процесс, который заново проверяет всё с самого начала. Пока база данных недоступна, новый процесс запуститься не может, и API завершается и перезапускается каждые 10 секунд, пока PostgreSQL не ответит. Так и должно быть. Клиенты в это время получают 503 unavailable с Retry-After. Работающий агент резервного копирования не завершается, пока базы данных нет. Он записывает ошибку и повторяет попытку через интервал опроса (по умолчанию 15 секунд).

Что происходит с работой в процессе

Сбой обрывает открытые соединения. Данные, подтверждённые клиенту, сохраняются. Дальнейшее зависит от вида работы.

Работа	После перезапуска
Скачивание	Клиент продолжает запросом диапазона. SDK и клиент командной строки делают это сами
Загрузка по частям	Записанные части остаются на сервере. Клиент спрашивает, какие части есть, и отправляет недостающие. Сессия остаётся открытой 7 дней с момента создания
Загрузка целого файла одним запросом	Клиент отправляет файл заново с первого байта
Завершение загрузки обработчиком	См. ниже
Резервное копирование	См. ниже
Синхронизация зеркала	Обработчик сохраняет позицию после каждого применённого изменения и копирует файл с первой недостающей части. После сбоя он ждёт 2 секунды, удваивая паузу между попытками до 5 минут
Обновление	Установщик сохраняет свою блокировку и журнал. Сам он не продолжает. См. Устранение неполадок

SDK и клиент командной строки ограниченное число раз повторяют сетевые сбои и ответы 408, 429, 502, 503 и 504. Другим клиентам нужен собственный повтор. См. Передачи.

Задания завершения. Большую загрузку завершает обработчик (SDK и клиент командной строки делают это начиная с 16 ГиБ). Обработчик держит аренду задания 30 секунд и продлевает её каждые 2 секунды. Когда обработчик падает, аренда истекает в течение 30 секунд, и перезапущенный обработчик берёт задание снова. Задание выполняется не более 5 раз. После сбоя оно ждёт 2 секунды, удваивая паузу до 60 секунд. Эти ошибки завершают задание сразу: forbidden, invalid_input, integrity_mismatch и not_found. Задание, исчерпавшее все попытки, получает запись completion.attempts_exhausted. Повторный запрос завершить ту же загрузку снова ставит задание в очередь. Завершение проверяет сохранённые байты, поэтому его безопасно повторять.

Второй обработчик на той же базе данных ждёт в резерве (worker.standby) и каждые 5 секунд проверяет, не исчез ли первый.

Агент резервного копирования. Агент держит аренду 60 секунд (ARKVORY_BACKUP_LEASE_SECONDS) и продлевает её каждые 20 секунд. После сбоя другой агент или перезапущенный берёт аренду, когда она истекает, поэтому копия ждёт до минуты. Прерванное задание выполняется снова с тем же ключом, до 5 раз. Новая копия снимает блокировки умершей. Предупреждение agent_offline появляется после 2 минут без сигнала. Во время обновления установщик сначала останавливает агент, а выполняющаяся копия заканчивается как interrupted и ставится в очередь снова.

Ограничения частоты запросов. Счётчики входа по адресам живут в процессе и сбрасываются при перезапуске. Задержка для учётной записи хранится в базе данных и сохраняется.

Проверки при запуске

Каждый процесс проверяет свою среду, прежде чем начать работу. Неудачная проверка завершает процесс с кодом 1 и одной строкой startup.failed (API) или worker.unavailable (обработчик). В reason названа причина без секретов.

Процесс	Что проверяется
API	У каждой настройки допустимое значение; сообщение называет переменную, но не её значение. Файл ключей читается как JSON размером до 1 МиБ. Встроенный TLS: сертификат и ключ читаются, соответствуют друг другу и не просрочены; возврата к HTTP нет. В каталог хранилища файлов можно писать. База данных отвечает и содержит все миграции этого выпуска и ни одной из более нового. Файл storage-id в каталоге хранилища файлов совпадает с идентичностью, сохранённой в базе данных. Другой пишущий процесс не держит базу данных
Обработчик	Те же настройки, база данных, идентичность хранилища файлов и блокировка единственного обработчика. Второй обработчик ждёт в резерве
Агент резервного копирования	Идентичность хранилища файлов, номер схемы и то, что хранилище копий не пересекается с каталогом хранилища файлов. Отсутствующее или неподключённое хранилище копий не фатально. Агент сообщает об этом как о предупреждении

После обновления установщик ждёт трёх успешных ответов о готовности подряд и работающего обработчика. Затем он ждёт около 90 секунд сигнала агента резервного копирования. Отсутствие агента — лишь предупреждение, оно никогда не откатывает обновление.

Что всё равно требует вас

Самовосстановление покрывает сбои процесса. Участия оператора требуют следующие случаи:

• Постоянная неисправность. Неверная настройка, недоступная база данных, заполненный диск или неверные права заставляют службу перезапускаться каждые 10 секунд без успеха. Прочитайте startup.failed и устраните причину. См. Устранение неполадок.
• Неудавшееся обновление. Прерванное обновление сохраняет блокировку и журнал, пока вы не выполните recover.
• Повреждённые резервные копии. verify_failed и vault_unavailable требуют человека. Агент оставляет хранилище копий без изменений.
• Сертификаты. Arkvory читает обновлённые файлы сертификатов без перезапуска (по умолчанию раз в 300 секунд), но продлевать их должны ваши инструменты.
• Остановленная служба. Служба, которую вы остановили, остаётся остановленной.
• Платформа. Docker должен запускаться при загрузке. Основные версии PostgreSQL, Node.js и операционную систему обновляете вы.
• Потерянный сервер или диск. Автоматического переключения нет. Восстановите данные из резервной копии. См. Резервные копии.

Связанные страницы

• Мониторинг
• Устранение неполадок
• Windows
• Переменные окружения