Autonomía del streamer¶

Central es el plano de control, no el camino de los medios. Todo lo que un canal hace para el espectador lo hace el propio streamer: captura la fuente, transcodifica, escribe el archivo, sirve el stream. Una caída de central es, por tanto, un incidente de gestión, no de emisión. Esta página cubre qué sigue funcionando exactamente, qué se congela y cómo se rearma el clúster; todo lo descrito está verificado en un clúster vivo.

Qué sigue funcionando¶

El aire. Los canales en los streamers siguen emitiendo: todo lo que un canal hace en su máquina — fuentes, transcodificador, grabación del archivo, pushes, entrega — no depende de central. Los espectadores ya dirigidos a un streamer siguen viendo.
La grabación DVR. El archivo se escribe sin pausas — la ventana sigue creciendo durante todo el tiempo caído de central.
Incluso un reinicio del streamer. Un streamer reiniciado con central inalcanzable levanta sus canales de inmediato — un arranque en caliente desde el caché local del slice de configuración, sin esperar una sola respuesta de central. Simplemente sigue reintentando la sincronización:

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

Qué se congela¶

La gestión. La consola, el API, la lista de canales, las estadísticas, las sesiones — todo el plano de central. Los cambios de configuración no se entregan, el layouter no mueve nada: el clúster queda congelado en su última colocación.
El camino del espectador a través de central. El proxeo de medios y la emisión de redirects pasan por central — los espectadores nuevos que llegan a su dirección no obtienen respuesta. De ahí la regla de producción: dele a los streamers una URL pública de payload — la dependencia del espectador respecto a central se reduce a un solo redirect, y a los ya conectados la caída no los toca en absoluto.
El streamer local. El streamer dentro del proceso de central comparte su suerte: los canales colocados en él caen junto con el proceso. Un argumento más para separar central y la emisión en máquinas distintas en producción.

Cómo se rearma el clúster¶

El streamer reintenta la sincronización con pausa exponencial (tope de alrededor de un minuto), así que cuando central vuelve, el clúster se recompone solo dentro de esa pausa: en el registro el streamer pasa de «Señal perdida» a «En línea», las estadísticas y las sesiones reviven. No hay que reiniciar nada.

Dos casos especiales del regreso de central:

Central restaurado de un backup, con versiones de configuración más viejas que las que el streamer alcanzó a aplicar. El streamer recibe de central una señal explícita, toma el snapshot completo como la verdad y sigue trabajando con él. Un retroceso de versiones no rompe el clúster.
Central volvió con la base vacía — el disco se perdió, no hay backup. El streamer ahora es un desconocido para él, y su log lo dice sin rodeos:

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

El aire sigue — el streamer vive del slice aplicado. Para devolverlo al clúster: detenga el servicio del streamer en la máquina, limpie su directorio de estado (/var/lib/catena — la identidad del streamer vive ahí; no toque el archivo si está en su propio disco), abra la ventana de unión y una la máquina con un token nuevo. El streamer llega al registro como un registro nuevo, y el layouter reparte los canales otra vez. Un token sin el reinicio del estado no ayuda: la identidad guardada es más fuerte.

Qué lo paga¶

La resiliencia no es casual — viene en la construcción:

Toda la comunicación la inicia el streamer. Central no tiene canal de control inverso: el streamer necesita a central para cambiar la configuración, no para trabajar.
El slice aplicado se guarda en el streamer. El caché local de configuración es lo que da el arranque en caliente sin central y la vida bajo la última colocación el tiempo que haga falta.
Central tiene un solo portador de estado — PostgreSQL. No tiene directorio de estado propio: si el backup de la base está intacto, toda la instalación está intacta. Un pg_dump regular es el único backup que necesita el plano de control.