Serveurs de base de données

Par défaut, les bases de données d’une application s’exécutent sur le même serveur que l’application. C’est économique et rapide, mais si ce serveur est perdu, seules vos sauvegardes survivent. Un serveur de base de données est un de vos propres serveurs qui ne contient que des données.

Ajouter un serveur de base de données

Servers → + Add a database server. Il fonctionne comme l’ajout d’un serveur, avec quelques différences :

• Il n’a pas de proxy Web ni d’outils de build, et aucune application n’y est jamais déployée.
• Ses ports de stockage de données ne sont ouverts qu’aux serveurs d’applications qui l’utilisent.
• Sa page liste les applications dont il détient les données.

Choisir où vivent les données d’une application

Quand vous créez une application, Where should the data live? propose trois choix :

• This server : le serveur de l’application elle-même.
• A database server : présélectionné pour la production quand votre équipe en a un.
• External : collez l’adresse d’un service géré comme RDS, ElastiCache ou Elastic Cloud.

Pour une application existante, allez dans Settings → Resources → Move data to a database server. La carte liste ce qui sera copié et ce qui démarre vide avant que vous appuyiez sur le bouton. Ensuite :

1. L’application s’arrête.
2. Postgres et MySQL sont exportés puis restaurés sur le serveur de base de données.
3. Redis, MongoDB, le stockage d’objets, les définitions RabbitMQ et ClickHouse sont copiés aussi. Un Elasticsearch utilisé uniquement par cette application est copié également.
4. L’application est redéployée.

Si une étape échoue, l’application revient à ses anciennes données, qui ne sont que lues et jamais modifiées. Memcached n’est pas copié, ni un Elasticsearch partagé avec une autre application : réindexez après le déplacement.

Use an outside service, sur l’onglet Resources, bascule la base de données, Redis ou Elasticsearch vers une adresse que vous fournissez. Railyard vérifie d’abord l’adresse. Une adresse inaccessible ne change rien, et votre application n’est pas arrêtée. Vous pouvez copier les données vers cette adresse, et Bring back under Railyard fait l’inverse.

Protégé par défaut

• Sauvegardes. Les bases de données d’application sur un serveur de base de données reçoivent une sauvegarde toutes les 24 heures, et chacune est vérifiée par restauration. Un horaire que vous définissez sur la carte de la base de données est respecté.
• Serveur de secours (Pro et Team). Also create a standby sur Add a database server crée un second serveur de base de données de même taille. Une fois les deux en ligne, il garde une copie en direct de Postgres, MySQL et Redis, et un moteur que vous commencez à utiliser plus tard est copié aussi. Railyard vérifie chaque serveur de secours toutes les 5 minutes, affiche son retard et vous alerte (règles avec data maintenance cochée) s’il cesse de suivre ou prend plus de 5 minutes de retard, puis à nouveau quand il rattrape.
• Basculement automatique. Si un serveur de base de données ne répond plus pendant 3 minutes et que son serveur de secours a aussi perdu le contact, le serveur de secours prend le relais : il sert les données sur les ports habituels, chaque application qui utilise le serveur de base de données est redéployée vers lui, et la restauration à un instant précis s’y réactive. Vous recevez une notification qui liste ce qui a été déplacé. Désactivez-le par serveur dans Maintenance → Database replicas.
• Promote à la main depuis la page du serveur principal (Maintenance → Database replicas) ou depuis la page du serveur de secours. Il fait la même prise de relais. Les écritures reçues par l’ancien serveur dans ses dernières secondes peuvent être perdues : utilisez-le quand le serveur principal est perdu, ou si vous l’acceptez.
• Make it the new standby. Quand l’ancien serveur revient, sa page indique qu’il a été remplacé et aucune application n’utilise ses données 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.
• Non répliqués : Elasticsearch et un Redis dédié à une application repartent vides sur le serveur de secours après un basculement. Les applications réindexent Elasticsearch automatiquement après leur redéploiement.

L’offre Free inclut un serveur de base de données à côté de votre serveur d’application. Les serveurs de secours viennent avec Pro et Team.

Vous pouvez aussi ajouter une réplique d’un seul moteur à n’importe quel autre serveur de l’équipe depuis Maintenance → Database replicas. Une réplique sur un serveur d’application reste sur son propre port quand elle est promue (5433 pour Postgres, 3307 pour MySQL, 6380 pour Redis) : pointez-y vos applications vous-même.

Regroupement de connexions (PgBouncer)

Il y a deux interrupteurs :

1. Server → Maintenance → Connection pooler → Turn on. Cela exécute PgBouncer en mode transaction sur le port 6432. Les requêtes préparées de Rails continuent de fonctionner.
2. App → Resources → Database card → Use the pooler. Dès le prochain déploiement, DATABASE_URL passe par le regroupeur de connexions et DATABASE_DIRECT_URL garde l’adresse directe.

L’étape de release (les migrations) utilise toujours l’adresse directe, parce que les verrous consultatifs ne fonctionnent pas à travers un regroupement en mode transaction. Choisir le regroupeur de connexions pour une application le démarre aussi sur le serveur s’il ne tourne pas déjà. Vous ne pouvez pas désactiver le regroupeur de connexions d’un serveur tant qu’une application l’utilise.

Mises à niveau majeures de Postgres (bêta)

Server → Maintenance → Postgres version.

1. Check compatibility. C’est un essai à vide qui ne change rien. Il vérifie les extensions de chaque base de données face à la nouvelle version et s’assure qu’il reste environ deux fois la taille des données en espace disque libre.
2. Upgrade now, ou In the next maintenance window. Railyard sauvegarde d’abord chaque base de données, et une sauvegarde en échec arrête la mise à niveau. Chaque base de données est copiée dans la nouvelle version et ses tables sont comptées pour confirmer la copie. Ensuite, la nouvelle version prend le relais sur le même port, donc les applications gardent leur DATABASE_URL. Les connexions des applications sont mises en pause pendant la copie.
3. Roll back, tant que l’ancienne version est conservée (7 jours par défaut). Tout ce qui a été écrit après la mise à niveau n’est pas présent dans l’ancienne version.

Copier une base de données

App → Resources → Database card → Fork this database (Postgres).

• Into : une nouvelle base de données sur n’importe quel serveur avec Postgres géré par Railyard, qui obtient sa propre connexion et son propre mot de passe. Ou remplacez les données d’un environnement de staging ou d’aperçu. La production n’est jamais une cible.
• From : une copie en direct prise maintenant, ou la dernière sauvegarde.
• Mask : collez du SQL, par exemple UPDATE users SET email = 'user' || id || '@example.test', phone = NULL;. Il s’exécute sur la copie avant que quiconque puisse l’utiliser. S’il échoue, la copie est supprimée, donc il n’y a jamais de copie non masquée.

Les règles de masquage par colonne dans l’interface et les copies instantanées en copie sur écriture ne sont pas encore construites.

Fenêtres de maintenance

Définissez un créneau hebdomadaire sous Team → Maintenance, ou par serveur sous Settings → Data maintenance window. Railyard envoie un avis aux règles où data maintenance est cochée. Dans la fenêtre, il exécute les mises à niveau Postgres planifiées, les mises à jour de sécurité sur les serveurs de base de données et VACUUM (ANALYZE). Sans fenêtre définie, rien ne s’exécute de lui-même.

Un Redis dédié par application

Par défaut, les applications partagent le Redis du serveur, chacune avec son propre numéro de base. Give this app its own Redis, sur la carte Redis, définit une limite de mémoire et ce qui se passe quand elle est atteinte (une politique d’éviction comme allkeys-lru). Vos clés sont copiées au passage. Go back to the shared Redis les copie en sens inverse.

API

Méthode	Chemin	But
POST	/api/applications/:id/data_move	Déplacer les données vers un serveur de base de données (database_server_id)
POST / DELETE	/api/applications/:id/external_datastores	Utiliser une adresse externe, ou faire revenir les données
GET / POST	/api/servers/:id/database_replicas	Lister ou ajouter des serveurs de secours; POST …/:id/promote promeut
POST	/api/servers/:id/standby_rejoin	Faire d’un serveur remplacé le serveur de secours du nouveau serveur principal
GET / POST / DELETE	/api/servers/:id/connection_pooler	Le PgBouncer du serveur
GET / POST	/api/servers/:id/postgres_upgrades	Vérifier, planifier, annuler et nettoyer les mises à niveau
GET / POST / DELETE	/api/applications/:id/database_forks	Copies (source vaut live ou backup, mask_sql facultatif)
GET / PATCH	/api/applications/:id/redis	Redis partagé ou dédié, limite de mémoire et politique

Les sauvegardes, les restaurations et les consoles sont couvertes dans Bases de données et sauvegardes.