Componentes y fiabilidad¶

Una instalación de Catena se compone de pocas partes, y cada una tiene su portador de estado y sus garantías. Esta página es el mapa: qué se guarda dónde, qué sobrevive a la pérdida de qué y en qué se apoya la compatibilidad al actualizar. El comportamiento del clúster durante una caída de central se cubre aparte — Autonomía del streamer.

De qué se compone la instalación¶

El servicio catena en la máquina de central — el plano de control y el streamer local en un solo proceso.
PostgreSQL — el almacén de estado de central. El único: central no tiene directorio de estado propio.
Los servicios de los streamers — la emisión; cada uno con su directorio de estado y sus discos de archivo.
El almacén de métricas — integrado, en la memoria del proceso, con un horizonte de unas horas; historia para los gráficos, no un archivo.

Qué vive en PostgreSQL¶

Todo lo que constituye el estado deseado y los registros de la instalación:

las configuraciones de canales y las configs de los streamers;
el registro de streamers — los asientos con la identidad y las claves de las máquinas;
la colocación de canales, el diario de decisiones y las ejecuciones del layouter;
las zonas CDN;
el diario de sesiones cerradas;
el material TLS de central — la cuenta ACME y los certificados emitidos.

La consecuencia es simple: un backup íntegro de la base es una instalación íntegra. Cómo tomarlo y restaurarlo — Backup y restauración.

Qué vive en un streamer¶

El directorio de estado /var/lib/catena de cada máquina:

server.id y el caché de activación — la identidad de licenciamiento de la máquina;
la identidad del streamer en el clúster — la clave con la que se presenta ante central;
el caché del slice de configuración aplicado — lo que da el arranque en caliente sin central;
el diario local de sesiones cerradas hasta que central lo recoge.

El archivo DVR vive en otra parte — en los discos dedicados definidos en la configuración del streamer.

Qué sobrevive a la pérdida de qué¶

Perdido	Qué pasa	Qué hacer
El proceso de central	El aire y la grabación siguen; la gestión y el camino del espectador por central se congelan	Autonomía del streamer; levante el proceso — el clúster se recompone solo
La base PostgreSQL	Como arriba, más se pierde el estado deseado	Restaurar del dump — los streamers reconectan solos
La base, y sin backup	El aire sigue; los streamers quedan huérfanos	Reenganchar cada uno: reinicio de estado y token nuevo
El directorio de estado de un streamer	La máquina pierde su identidad — de licencia y de clúster	Unir la máquina de nuevo; los canales se recolocan
Un disco DVR	Se pierde el archivo de ese disco; el aire no se toca	Los indicadores del disco en el diagnóstico
El almacén de métricas (reinicio del proceso)	Se pierden unas horas de historia de gráficos	Nada — se acumula de nuevo

Garantías de compatibilidad¶

Versiones distintas conviven. El protocolo de intercambio crece solo por adición: los campos desconocidos deben ignorarse por ambos lados, así que central y streamers de versiones vecinas trabajan juntos.
El esquema de la base es compatible en una ventana de dos versiones. Un esquema más nuevo bajo código más viejo es la norma; eso habilita tanto la actualización por etapas como el rollback del binario sin rollback de la base.
El registro es deliberadamente no idempotente. Volver a unir la misma máquina crea un asiento nuevo, y los duplicados por server_id el registro los marca dejando la decisión al operador — vea la lista de streamers.