O banco de dados reserva e a cópia de relatórios (para a equipe do Kaam360)

Este guia é para a equipe do Kaam360 (o painel da plataforma). Os clientes não precisam dele.

O que é o standby

O site ao vivo guarda os dados em um banco de dados PostgreSQL no servidor. O standby é um segundo PostgreSQL no mesmo servidor que recebe cada mudança no momento em que ela acontece, então fica milissegundos atrás. Se o banco de dados ao vivo quebrar, o site pode ser passado para o standby em cerca de dois minutos, em vez de restaurar o backup da noite anterior. Ele não substitui o backup noturno fora do servidor, que protege contra a perda do servidor inteiro: os dois são necessários.

Tudo é feito com botões no GitHub (Actions, PostgreSQL standby, Run workflow): escolha um modo, digite a mesma palavra na caixa de confirmação, pressione o botão verde. O procedimento escrito está no arquivo deploy/STANDBY.txt.

Veja se ele está saudável

1. Abra o painel da plataforma e olhe a Overview. O cartão Database standby diz Streaming (bom), Behind (atrasado) ou Not connected (não conectado), com quanto está atrasado.
2. A mesma informação está no endereço /health do site, na parte "standby".
3. No GitHub, o modo status imprime uma página completa: o serviço do Windows, o estado do streaming, bytes e segundos de atraso, o tamanho da cópia. Ele não altera nada.
4. Quando o standby fica ausente ou atrasado por dez minutos, a equipe recebe um e-mail (no endereço de suporte em Settings & team, senão para cada administrador da plataforma), repetido no máximo a cada seis horas. O log Activity da plataforma recebe uma linha quando dá errado e quando volta a ficar bem.

Configure ou repare

Rode o modo setup. O site ao vivo não é parado. Ele cria os usuários do banco de dados (senhas guardadas só no servidor), faz uma cópia completa, inicia a cópia como standby, registra o serviço do Windows, bloqueia a porta dele para acessos de fora e avisa o site. Um standby saudável fica como está, então rodar de novo é sempre seguro. Se uma etapa falhar, o script diz qual e por quê, e nada muda no site ao vivo.

Passe para o standby

Rode o modo failover quando o banco de dados ao vivo estiver quebrado e o standby estiver bem. O site mostra uma página de "atualizando" por cerca de dois minutos. O standby se torna o banco de dados ao vivo, o site passa a apontar para ele, e as configurações anteriores são guardadas como appsettings.local.json.before-failover. O script então mostra o que fazer em seguida: usar o site normalmente, guardar a pasta do banco antigo por enquanto e rodar setup quando o servidor estiver calmo para criar um novo standby. Uma cópia promovida nunca volta a ser standby; um novo é feito a partir de uma cópia nova.

Relatórios pesados leem da cópia

Quando o standby está em streaming e menos de alguns minutos atrasado, o construtor de relatórios, os relatórios agendados por e-mail, os downloads em CSV e Excel, o portfólio, os relatórios de projeto e o download completo dos dados leem dele em vez do banco de dados ao vivo, para que um relatório grande nunca deixe lento quem está trabalhando. Esse relatório mostra Data as of (dados de) seguido do horário da mudança mais recente na cópia. Quando a cópia está ausente, inacessível ou mais de alguns minutos atrasada, os relatórios usam o banco de dados ao vivo, sem que ninguém precise fazer nada. Nada é escrito na cópia, e cada relatório vê só os dados da própria organização, exatamente como no banco de dados ao vivo. O endereço /health diz se os relatórios estão sendo servidos pela cópia ("reports").

Remova

Rode o modo remove. Ele para e apaga o standby e o tira das configurações do site. O banco de dados ao vivo não é tocado. O setup pode ser rodado de novo a qualquer momento.