Autonomia do streamer¶

O central é o plano de controle, não o caminho da mídia. Tudo o que um canal faz para o espectador o próprio streamer faz: captura a fonte, transcodifica, grava o arquivo, serve o stream. Uma queda do central é, portanto, um incidente de gestão, não de transmissão. Esta página cobre o que exatamente continua funcionando, o que congela e como o cluster se remonta; tudo o descrito foi verificado num cluster vivo.

O que continua funcionando¶

O ar. Os canais nos streamers seguem transmitindo: tudo o que um canal faz na sua máquina — fontes, transcodificador, gravação do arquivo, pushes, entrega — não depende do central. Espectadores já direcionados a um streamer continuam assistindo.
A gravação DVR. O arquivo é gravado sem pausas — a janela segue crescendo durante todo o tempo de queda do central.
Até um reinício do streamer. Um streamer reiniciado com o central inalcançável levanta seus canais imediatamente — uma partida a quente do cache local do slice de configuração, sem esperar uma única resposta do central. Ele simplesmente segue repetindo a sincronização:

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

O que congela¶

A gestão. O console, a API, a lista de canais, as estatísticas, as sessões — todo o plano do central. Mudanças de configuração não são entregues, o layouter não move nada: o cluster fica congelado na última alocação.
O caminho do espectador através do central. O proxy de mídia e a emissão de redirects passam pelo central — espectadores novos que chegam ao endereço dele não obtêm resposta. Daí a regra de produção: dê aos streamers uma URL pública de payload — a dependência do espectador em relação ao central encolhe a um único redirect, e os já conectados a queda não toca de jeito nenhum.
O streamer local. O streamer dentro do processo do central compartilha a sorte dele: canais alocados nele caem junto com o processo. Mais um argumento para separar o central e a transmissão em máquinas diferentes em produção.

Como o cluster se remonta¶

O streamer repete a sincronização com pausa exponencial (teto de cerca de um minuto), então quando o central volta, o cluster se recompõe sozinho dentro dessa pausa: no registro o streamer vai de «Sinal perdido» a «Online», estatísticas e sessões revivem. Nada precisa ser reiniciado.

Dois casos especiais do retorno do central:

Central restaurado de um backup, com versões de configuração mais velhas do que o streamer chegou a aplicar. O streamer recebe do central um sinal explícito, toma o snapshot completo como a verdade e segue trabalhando com ele. Um retrocesso de versões não rasga o cluster.
Central voltou com o banco vazio — o disco se perdeu, não há backup. O streamer agora é um desconhecido para ele, e o log diz isso na cara:

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

O ar continua — o streamer vive do slice aplicado. Para devolvê-lo ao cluster: pare o serviço do streamer na máquina, limpe o diretório de estado (/var/lib/catena — a identidade do streamer mora lá; não toque no arquivo se ele está em disco próprio), abra a janela de adesão e junte a máquina com um token novo. O streamer chega ao registro como um registro novo, e o layouter distribui os canais de novo. Token sem o reset do estado não ajuda: a identidade guardada é mais forte.

O que paga por isso¶

A resiliência não é acidental — está na construção:

Toda a comunicação é iniciada pelo streamer. O central não tem canal de controle reverso: o streamer precisa do central para mudar a configuração, não para trabalhar.
O slice aplicado é guardado no streamer. O cache local de configuração é o que dá a partida a quente sem central e a vida sob a última alocação por quanto tempo for preciso.
O central tem um único portador de estado — PostgreSQL. Ele não tem diretório de estado próprio: se o backup do banco está intacto, a instalação inteira está intacta. Um pg_dump regular é o único backup de que o plano de controle precisa.