Mode maintenance en lecture seule : servir les lectures pendant que les écritures sont suspendues

Ce que c'est

Un mode maintenance en lecture seule est un état de service délibéré dans lequel les lectures réussissent et chaque chemin d'écriture renvoie un refus temporaire et clairement identifié. Il est appliqué à deux niveaux : l'application vérifie un indicateur avant toute écriture et affiche une bannière, et la base de données rejette les écritures en filet de sécurité. La documentation de PostgreSQL décrit default_transaction_read_only, qui contrôle le statut de lecture seule par défaut de chaque nouvelle transaction, et précise qu'une transaction SQL en lecture seule ne peut pas modifier des tables non temporaires. Pour HTTP, la RFC 9110 définit le code 503 (Service Unavailable) pour un serveur temporairement incapable de traiter des requêtes, y compris pour une maintenance planifiée, et précise que Retry-After, envoyé avec un 503, indique combien de temps le service devrait rester indisponible pour le client.

Pourquoi c'est important

La plupart des opérations de maintenance touchent aux écritures : déplacer un stockage, promouvoir une réplique, exécuter une migration longue. Les lectures fonctionnent souvent tout du long. Une page d'indisponibilité totale pour un déplacement de stockage de deux heures gaspille une disponibilité qui aurait pu être offerte, alors qu'un échec non étiqueté (« une erreur s'est produite ») pendant le même déplacement génère de la charge de support et des tentatives aveugles.

Comment l'appliquer

• Ajouter un seul interrupteur (indicateur de configuration, bascule de fonctionnalité ou variable d'environnement) que l'application lit en tête de chaque chemin d'écriture. L'interrupteur fait autorité ; le réglage de la base de données est le filet de sécurité.
• Renvoyer un refus cohérent : HTTP 503 avec Retry-After et un corps lisible par machine nommant la maintenance, plus une bannière visible dans l'interface. Les clients bien élevés attendent alors ; les tâches en file d'attente devraient se mettre en pause plutôt qu'échouer.
• Régler default_transaction_read_only = on, ou diriger l'application vers une réplique en lecture, pendant la fenêtre, afin qu'un chemin d'écriture oublié échoue au niveau de la base de données plutôt que de corrompre la migration.
• Mettre en pause explicitement les écrivains en arrière-plan : ordonnanceurs, consommateurs de files d'attente, récepteurs de webhooks qui persistent des données.
• Simuler en environnement de préproduction : basculer l'interrupteur, exécuter les tests d'écriture et s'attendre à des 503, le rebasculer et s'attendre à des succès. Chronométrer les deux bascules.
• Annoncer la fenêtre sur la page de statut avec l'effet attendu (« vous pouvez consulter mais pas enregistrer »).

Pièges

Des écritures cachées à l'intérieur de lectures (horodatages de dernière visite, compteurs de vues, rafraîchissements de session) qui échouent et cassent le rendu de la page. Des caches qui ont stocké les réponses d'erreur du mode. Oublier de revenir sur le réglage de la base de données après la fenêtre, ce pourquoi l'interrupteur vit en un seul endroit et la liste de contrôle se termine par « vérifier les écritures ».

Tenir la fenêtre à l'écart des contrôles de santé et des budgets d'erreur

Un 503 sur les chemins d'écriture est correct pour les clients et trompeur pour tout ce qui surveille le service. Avant la première simulation, apporter trois changements avec l'interrupteur : les points de contrôle de santé utilisés par les répartiteurs de charge et les orchestrateurs ne doivent pas emprunter un chemin d'écriture, ou doivent traiter l'état de lecture seule comme sain, afin que les instances restent dans la rotation ; les refus de maintenance portent un marqueur (un en-tête de réponse ou un corps de type de problème distinct) que le SLO de taux d'erreur et les règles d'alerte excluent, et que les tableaux de bord affichent comme leur propre série ; et Retry-After est réglé sur la fenêtre restante attendue plutôt que sur quelques secondes, afin que les clients qui réessaient attendent plutôt que d'interroger en boucle. Vérifier les trois points en préproduction en observant l'état des cibles du répartiteur de charge et le panneau de taux d'erreur pendant la simulation, pas seulement les réponses HTTP.