Автономия стримера¶

Central — управляющий контур, а не путь медиа. Всё, что канал делает для зрителя, стример делает сам: забирает источник, транскодирует, пишет архив, отдаёт поток. Поэтому падение central — авария управления, а не эфира. Эта страница — что именно продолжает работать, что замирает и как кластер собирается обратно; всё описанное проверено на живом кластере.

Что продолжает работать¶

• Эфир. Каналы на стримерах вещают дальше: всё, что канал делает на своей машине, — источники, транскодер, запись архива, пуши, раздача — от central не зависит. Зрители, уже направленные на стример, продолжают смотреть.
• Запись DVR. Архив пишется без пауз — окно продолжает расти всё время простоя central.
• Даже рестарт стримера. Стример, перезапущенный при недоступном central, поднимает свои каналы немедленно — тёплым стартом из локального кэша среза конфигурации, не дожидаясь ни одного ответа central. Он просто продолжает ретраить синхронизацию:

WARN  sync failed, retrying   error sending request for url (.../node-api-v4/sync)

Что замирает¶

• Управление. Консоль, API, список каналов, статистика, сессии — весь контур central. Изменения конфигурации не доставляются, лейаутер ничего не переразмещает: кластер заморожен в последней раскладке.
• Зрительский путь через central. Проксирование медиа и выдача редиректов идут через central — новые зрители, приходящие на его адрес, ответа не получают. Отсюда продакшн-правило: задавайте стримерам публичный payload URL — тогда зависимость зрителя от central сжимается до одного редиректа, а уже подключившихся падение central не касается вовсе.
• Локальный стример. Стример внутри процесса central разделяет его судьбу: каналы, размещённые на нём, падают вместе с процессом. Ещё один довод разносить central и вещание по разным машинам в продакшне.

Как кластер собирается обратно¶

Стример ретраит синхронизацию с экспоненциальной паузой (потолок — около минуты), поэтому после возвращения central кластер срастается сам в пределах этой паузы: в реестре стример проходит путь от «Потеря сигнала» до «В эфире», статистика и сессии оживают. Ничего перезапускать не нужно.

Два особых случая возвращения central:

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

ERROR node key rejected; streams keep running from the applied slice, operator action required

Эфир при этом продолжается — стример живёт по применённому срезу. Чтобы вернуть его в кластер: остановите сервис стримера на машине, очистите её state-каталог (/var/lib/catena — идентичность стримера живёт там; архив, лежащий отдельным диском, не трогайте), откройте окно присоединения и присоедините машину новым токеном. Стример придёт в реестр новой записью, и лейаутер разложит каналы заново. Токен без сброса state не помогает: сохранённая идентичность сильнее.

Чем это оплачено¶

Живучесть не случайна — она входит в конструкцию:

• Всю связь инициирует стример. Обратного управляющего канала у central нет: стримеру central нужен, чтобы менять конфигурацию, а не чтобы работать.
• Применённый срез хранится на стримере. Локальный кэш конфигурации — то, что даёт тёплый старт без central и жизнь по последней раскладке любой длительности.
• У central один носитель состояния — PostgreSQL. Своего каталога состояния у него нет: цел бэкап базы — цела вся инсталляция. Регулярный pg_dump — единственный бэкап, который нужен управляющему контуру.