La base de datos de reserva y la copia para informes (para el equipo de Kaam360)

Esta guía es para el equipo de Kaam360 (el panel de plataforma). Los clientes no la necesitan.

Qué es la reserva

El sitio en vivo guarda sus datos en una base de datos PostgreSQL en el servidor. La reserva (standby) es un segundo PostgreSQL en el mismo servidor que recibe cada cambio en el momento en que ocurre, así que va milisegundos por detrás. Si la base de datos en vivo se rompe, el sitio puede cambiarse a la reserva en unos dos minutos en lugar de restaurar la copia de seguridad de anoche. No sustituye a la copia de seguridad externa nocturna, que protege contra la pérdida de todo el servidor: hacen falta las dos.

Todo se hace con botones en GitHub (Actions, PostgreSQL standby, Run workflow): elija un modo, escriba la misma palabra en la casilla de confirmación y pulse el botón verde. El procedimiento escrito está en el archivo deploy/STANDBY.txt.

Ver si está sana

1. Abra el panel de plataforma y mire Overview. La tarjeta Database standby dice Streaming (bien), Behind (atrasada) o Not connected (no conectada), con cuánto va por detrás.
2. La misma información está en la dirección /health del sitio, en la parte "standby".
3. En GitHub, el modo status imprime una página completa: el servicio de Windows, el estado de la transmisión, bytes y segundos de retraso, el tamaño de la copia. No cambia nada.
4. Cuando la reserva lleva diez minutos ausente o atrasada, el equipo recibe un correo (a la dirección de soporte en Settings & team, o si no a todos los administradores de plataforma), repetido como mucho cada seis horas. El registro Activity de la plataforma recibe una línea cuando algo va mal y cuando vuelve a estar bien.

Configurarla o repararla

Ejecute el modo setup. El sitio en vivo no se detiene. Crea los usuarios de la base de datos (las contraseñas se guardan solo en el servidor), toma una copia completa, arranca la copia como reserva, registra el servicio de Windows, bloquea su puerto desde fuera e informa al sitio. Una reserva sana se deja como está, así que volver a ejecutarlo siempre es seguro. Si un paso falla, el script dice cuál y por qué, y nada cambia en el sitio en vivo.

Cambiar a la reserva

Ejecute el modo failover cuando la base de datos en vivo esté rota y la reserva esté bien. El sitio muestra una página de "actualizando" durante unos dos minutos. La reserva pasa a ser la base de datos en vivo, el sitio se dirige a ella y los ajustes anteriores se conservan como appsettings.local.json.before-failover. El script imprime después qué hacer: usar el sitio con normalidad, conservar por ahora la carpeta de la base de datos antigua y ejecutar setup cuando el servidor esté tranquilo para crear una nueva reserva. Una copia promovida nunca vuelve a ser reserva; se crea una nueva a partir de una copia fresca.

Los informes pesados leen de la copia

Cuando la reserva transmite y va menos de unos minutos por detrás, el constructor de informes, los correos de informes programados, las descargas CSV y Excel, la cartera, los informes de proyecto y la descarga completa de datos leen de ella en lugar de la base de datos en vivo, para que un informe grande nunca frene a las personas que trabajan. Ese informe muestra Datos a las seguido de la hora del cambio más reciente en la copia. Cuando la copia falta, no responde o va más de unos minutos por detrás, los informes usan la base de datos en vivo sin que nadie tenga que hacer nada. Nunca se escribe en la copia, y cada informe ve solo los datos de su propia organización, exactamente igual que en la base de datos en vivo. La dirección /health dice si los informes se sirven desde la copia ("reports").

Quitarla

Ejecute el modo remove. Detiene y borra la reserva y la quita de los ajustes del sitio. La base de datos en vivo no se toca. Setup puede ejecutarse de nuevo en cualquier momento.