Modo de mantenimiento de solo lectura: servir lecturas mientras las escrituras están pausadas

Qué es

Un modo de mantenimiento de solo lectura es un estado deliberado del servicio en el que las lecturas se completan con éxito y toda vía de escritura devuelve un rechazo temporal y claramente etiquetado. Se aplica en dos capas: la aplicación comprueba un indicador antes de cualquier escritura y muestra un aviso, y la base de datos rechaza las escrituras como respaldo. La documentación de PostgreSQL describe default_transaction_read_only, que controla el estado de solo lectura predeterminado de cada nueva transacción, e indica que una transacción SQL de solo lectura no puede modificar tablas no temporales. En HTTP, RFC 9110 define el 503 (Service Unavailable) para un servidor temporalmente incapaz de atender solicitudes, incluido el mantenimiento programado, e indica que Retry-After enviado con un 503 señala cuánto tiempo se espera que el servicio permanezca no disponible para el cliente.

Por qué importa

La mayor parte del mantenimiento afecta a las escrituras: trasladar el almacenamiento, promover una réplica, ejecutar una migración larga. Las lecturas suelen funcionar bien durante todo el proceso. Una página de interrupción total para un traslado de almacenamiento de dos horas desperdicia disponibilidad que sí estaba disponible, mientras que un fallo sin etiquetar («algo salió mal») durante ese mismo traslado genera carga de soporte y reintentos a ciegas.

Cómo aplicarlo

• Añadir un único interruptor (indicador de configuración, feature toggle o variable de entorno) que la aplicación lea al inicio de cada vía de escritura. El interruptor es la autoridad; el ajuste de la base de datos es la red de seguridad.
• Devolver un rechazo coherente: HTTP 503 con Retry-After y un cuerpo legible por máquina que nombre el mantenimiento, junto con un aviso visible en la interfaz. Los clientes bien comportados esperan entonces; los trabajos en cola deberían pausarse en lugar de fallar.
• Establecer default_transaction_read_only = on, o dirigir la aplicación a una réplica de lectura, durante la ventana de mantenimiento, de modo que una vía de escritura olvidada falle en la base de datos en lugar de corromper la migración.
• Pausar explícitamente los escritores en segundo plano: programadores, consumidores de colas, receptores de webhooks que persisten datos.
• Ensayar en el entorno de staging: activar el interruptor, ejecutar las pruebas de escritura y esperar 503, desactivarlo de nuevo y esperar éxito. Cronometrar ambas conmutaciones.
• Anunciar la ventana en la página de estado con el efecto esperado («se puede navegar pero no guardar»).

Trampas

Escrituras ocultas dentro de lecturas (marcas de tiempo de última visita, contadores de vistas, renovaciones de sesión) que fallan y rompen el renderizado de la página. Cachés que almacenaron las respuestas de error del modo. Olvidar revertir el ajuste de la base de datos tras la ventana, razón por la cual el interruptor vive en un único lugar y la lista de verificación termina con «verificar las escrituras».

Mantener la ventana fuera de los health checks y los presupuestos de error

Un 503 en las vías de escritura es correcto para los clientes y engañoso para todo lo que observa el servicio. Antes del primer ensayo, hacer tres cambios junto con el interruptor: los endpoints de salud usados por los balanceadores de carga y los orquestadores no deben ejercitar una vía de escritura, o deben tratar el estado de solo lectura como saludable, para que las instancias permanezcan en rotación; los rechazos de mantenimiento llevan un marcador (un encabezado de respuesta o un cuerpo de tipo de problema distinto) que el SLO de tasa de error y las reglas de alertas excluyen, y que los paneles muestran como su propia serie; y Retry-After se fija según la ventana restante esperada en lugar de unos pocos segundos, de modo que los clientes que reintentan esperen en lugar de sondear repetidamente. Verificar los tres puntos en staging observando el estado de destino del balanceador de carga y el panel de tasa de error durante el ensayo, no solo las respuestas HTTP.