Basculement automatique de Postgres, en auto-hébergement
La plupart des installations « Postgres auto-hébergé » ne sont en fait que Postgres sur un serveur. Si ce serveur tombe, votre base de données tombe aussi, et la reprise consiste à retrouver votre dernière sauvegarde en espérant qu’elle soit assez récente. C’est très bien pour un projet secondaire. Ça ne l’est plus dès qu’une panne de base de données veut dire que votre produit est hors ligne.
Railyard traite ça comme un problème de plateforme, pas comme quelque chose que chaque équipe devrait câbler elle-même avec Patroni, repmgr, ou un script maison qui surveille pg_stat_replication en espérant que ça tienne.
Ce qu’est vraiment un serveur de base de données
Un serveur de base de données est un de vos propres serveurs — un droplet DigitalOcean, une machine Hetzner, peu importe ce que vous avez attaché — qui contient des données et rien d’autre. Il n’a pas de proxy web, pas d’outils de build, et aucune application n’y est jamais déployée. Ses ports ne sont ouverts qu’aux serveurs d’applications qui l’utilisent réellement.
Ajoutez un serveur de secours à la création (plans Pro et Team), et Railyard garde une copie en direct, continuellement à jour, de Postgres, MySQL et Redis sur un second serveur. Vous ne configurez pas la réplication vous-même; elle démarre automatiquement dès que les deux serveurs sont en ligne.
Ce qui se passe quand le serveur principal tombe
Railyard vérifie chaque serveur de secours toutes les 5 minutes et affiche son retard. Si un serveur de base de données cesse de répondre pendant 3 minutes et que son serveur de secours a lui aussi, indépendamment, perdu le contact avec lui — une vérification volontairement à double sens, pour qu’un simple accroc réseau du serveur de secours ne déclenche pas une fausse promotion — le serveur de secours prend le relais :
- Il commence à servir les données sur les ports habituels.
- Chaque application qui utilisait ce serveur de base de données se redéploie contre lui, automatiquement.
- La récupération à un instant précis (point-in-time recovery) se réactive là-bas.
- Vous recevez une notification qui liste exactement ce qui a bougé.
Personne n’a besoin de se connecter en SSH à 3 h du matin pour lancer pg_promote(). Si vous préférez décider vous-même — le serveur principal répond encore partiellement et vous ne faites pas encore confiance à un basculement automatique — Promote by hand fait exactement la même prise de relais, à la demande, depuis la page de l’un ou l’autre serveur.
Ce qui ne survit pas au basculement
Être honnête là-dessus compte plus que la fonctionnalité elle-même. Les écritures que l’ancien serveur principal a prises dans ses toutes dernières secondes avant de tomber peuvent être perdues — c’est le vrai compromis de la réplication asynchrone, et c’est le même compromis que fait toute base Postgres gérée avec un serveur de secours, Railyard y compris. Elasticsearch et un Redis dédié à une application ne sont pas répliqués, donc ils repartent vides sur le nouveau serveur principal (les applications réindexent Elasticsearch automatiquement après leur redéploiement; un simple cache qui se reconstruit est en général invisible pour les utilisateurs).
Quand l’ancien serveur revient en ligne, sa page de tableau de bord indique clairement qu’il a été remplacé et que rien n’utilise plus ses données désormais périmées. Make it the new standby copie des données fraîches depuis le nouveau serveur principal, pour que la prochaine panne soit couverte aussi — la paire se répare elle-même au lieu de rester silencieusement sans protection jusqu’à ce que quelqu’un le remarque.
En quoi c’est différent de « prenez juste RDS »
Ce n’est pas un remplacement pour une base de données gérée si ce que vous voulez vraiment, c’est confier tout le problème à AWS — Railyard permet ça aussi, vous pouvez pointer une application directement vers une URL RDS, ElastiCache ou Elastic Cloud externe. La différence vise le cas bien plus courant : une base Postgres qui tourne sur un serveur qui vous appartient, au prix réel de ce serveur, et qui bascule quand même comme la version gérée. Les équipes qui quittent Heroku Postgres tombent précisément sur ce manque — le basculement géré de Heroku disparaît dès que vous partez, et la plupart des installations auto-hébergées ne le remplacent jamais.
Protégé par défaut veut aussi dire sauvegardé par défaut : chaque base de données d’application sur un serveur de base de données reçoit une sauvegarde quotidienne, et chacune est vérifiée en la restaurant réellement, pas seulement supposée bonne. Voir Serveurs de base de données pour le tableau complet, incluant le pooling de connexions et les mises à niveau Postgres, Mise à l’échelle automatique et basculement pour voir comment ça s’articule avec le basculement au niveau de l’application, ou serveur de base de données contre addon pour savoir exactement quand cette protection s’active par rapport au défaut moins cher.