Datenbank-Server

Standardmäßig laufen die Datenbanken einer App auf demselben Server wie die App. Das ist günstig und schnell, aber wenn dieser Server verloren geht, überleben nur deine Backups. Ein Datenbank-Server ist einer deiner eigenen Server, der nur Daten hält.

Einen Datenbank-Server hinzufügen

Servers → + Add a database server. Es funktioniert wie einen Server hinzufügen, mit ein paar Unterschieden:

• Er bekommt keinen Web-Proxy und keine Build-Tools, und Apps werden nie auf ihn deployt.
• Seine Datastore-Ports sind nur für die App-Server geöffnet, die ihn nutzen.
• Seine Seite listet die Apps, deren Daten er hält.

Wählen, wo die Daten einer App leben

Wenn du eine App erstellst, bietet Where should the data live? drei Optionen:

• This server: der eigene Server der App.
• A database server: für Produktion vorausgewählt, wenn dein Team einen hat.
• External: füge die URL eines Managed-Services wie RDS, ElastiCache oder Elastic Cloud ein.

Für eine bestehende App gehst du zu Settings → Resources → Move data to a database server. Die Karte listet, was kopiert wird und was leer startet, bevor du den Button drückst. Dann:

1. Die App stoppt.
2. Postgres und MySQL werden gedumpt und auf dem Datenbank-Server wiederhergestellt.
3. Redis, MongoDB, Object-Storage, RabbitMQ-Definitionen und ClickHouse werden ebenfalls kopiert. Ein Elasticsearch, das nur von dieser App genutzt wird, wird auch kopiert.
4. Die App deployt neu.

Wenn ein Schritt fehlschlägt, geht die App zurück zu ihren alten Daten, die nur gelesen und nie verändert werden. Memcached wird nicht kopiert, ebenso wenig ein mit einer anderen App geteiltes Elasticsearch: reindexiere nach dem Umzug.

Use an outside service auf dem Resources-Tab schaltet die Datenbank, Redis oder Elasticsearch auf eine URL um, die du angibst. Railyard prüft die URL zuerst. Eine nicht erreichbare ändert nichts, und deine App wird nicht gestoppt. Du kannst die Daten rüberkopieren, und Bring back under Railyard macht es wieder rückgängig.

Standardmäßig geschützt

• Backups. App-Datenbanken auf einem Datenbank-Server bekommen alle 24 Stunden ein Backup, und jedes wird durch Wiederherstellung geprüft. Ein auf der Datenbank-Karte gesetzter Zeitplan wird eingehalten.
• Standby (Pro und Team). Also create a standby bei Add a database server erstellt einen zweiten Datenbank-Server derselben Größe. Sobald beide laufen, hält er eine Live-Kopie von Postgres, MySQL und Redis, und auch eine Engine, die du erst später nutzt, wird kopiert. Railyard prüft jeden Standby alle 5 Minuten, zeigt, wie weit er hinterherhinkt, und benachrichtigt dich (Regeln mit angehaktem data maintenance), wenn er nicht mehr folgt oder mehr als 5 Minuten zurückfällt, und erneut, wenn er aufholt.
• Automatisches Failover. Wenn ein Datenbank-Server 3 Minuten lang nicht antwortet und sein Standby auch den Kontakt zu ihm verloren hat, übernimmt der Standby: er bedient die Daten auf den üblichen Ports, jede App, die den Datenbank-Server nutzt, deployt gegen ihn neu, und Point-in-Time-Recovery schaltet sich dort wieder ein. Du bekommst eine Benachrichtigung, die zeigt, was umgezogen ist. Schalte das pro Server unter Maintenance → Database replicas aus.
• Von Hand hochstufen von der Seite des Primary (Maintenance → Database replicas) oder von der eigenen Seite des Standbys. Es macht dieselbe Übernahme. Schreibzugriffe, die der alte Server in seinen letzten Sekunden erhalten hat, können verloren gehen, nutze es also, wenn der Primary verloren ist oder du das akzeptierst.
• Make it the new standby. Wenn der alte Server zurückkommt, sagt seine Seite, dass er ersetzt wurde und keine App seine veralteten Daten nutzt. Make it the new standby kopiert frische Daten vom neuen Primary, sodass der nächste Ausfall ebenfalls abgedeckt ist.
• Nicht repliziert: Elasticsearch und ein dedizierter Redis pro App starten nach einem Failover leer auf dem Standby. Apps reindexieren Elasticsearch automatisch nach ihrem Redeploy.

Der Free-Plan enthält einen Datenbank-Server neben deinem App-Server. Standbys kommen mit Pro und Team.

Du kannst auch eine Replica einer einzelnen Engine zu jedem anderen Team-Server hinzufügen, von Maintenance → Database replicas. Eine Replica auf einem App-Server bleibt bei einer Hochstufung auf ihrem eigenen Port (5433 für Postgres, 3307 für MySQL, 6380 für Redis); richte Apps selbst darauf aus.

Connection Pooler (PgBouncer)

Es gibt zwei Schalter:

1. Server → Maintenance → Connection pooler → Turn on. Das lässt PgBouncer im Transaction-Mode auf Port 6432 laufen. Rails’ Prepared Statements funktionieren weiterhin.
2. App → Resources → Database card → Use the pooler. Ab dem nächsten Deploy läuft DATABASE_URL über den Pooler, und DATABASE_DIRECT_URL behält die direkte Adresse.

Der Release-Schritt (Migrationen) nutzt immer die direkte Adresse, weil Advisory Locks durch Transaction-Pooling nicht funktionieren. Die Wahl des Poolers für eine App startet ihn auch auf dem Server, falls er nicht läuft. Du kannst den Pooler eines Servers nicht abschalten, während eine App ihn nutzt.

Postgres-Hauptversions-Upgrades (Beta)

Server → Maintenance → Postgres version.

1. Check compatibility. Das ist ein Dry Run und ändert nichts. Es prüft die Extensions jeder Datenbank gegen die neue Version und stellt sicher, dass etwa das Doppelte der Datengröße an freiem Speicherplatz verfügbar ist.
2. Upgrade now, oder In the next maintenance window. Railyard sichert zuerst jede Datenbank, und jedes fehlgeschlagene Backup stoppt das Upgrade. Jede Datenbank wird in die neue Version kopiert und ihre Tabellen werden gezählt, um die Kopie zu bestätigen. Dann übernimmt die neue Version denselben Port, sodass Apps ihre DATABASE_URL behalten. App-Logins pausieren während der Kopie.
3. Roll back, solange die alte Version aufbewahrt wird (standardmäßig 7 Tage). Alles, was nach dem Upgrade geschrieben wurde, ist nicht in der alten Version.

Eine Datenbank forken

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

• Into: eine neue Datenbank auf jedem Server mit von Railyard verwaltetem Postgres, die ihr eigenes Login und Passwort bekommt. Oder ersetze die Daten einer Staging- oder Preview-Umgebung. Produktion ist nie ein Ziel.
• From: eine jetzt angefertigte Live-Kopie, oder das letzte Backup.
• Mask: füge SQL ein, zum Beispiel UPDATE users SET email = 'user' || id || '@example.test', phone = NULL;. Es läuft auf der Kopie, bevor jemand sie nutzen kann. Falls es fehlschlägt, wird die Kopie gelöscht, sodass es nie einen ungemaskten Fork gibt.

Pro-Spalte-Masking-Regeln in der UI und sofortige Copy-on-Write-Forks sind noch nicht gebaut.

Wartungsfenster

Setze einen wöchentlichen Slot unter Team → Maintenance, oder pro Server unter Settings → Data maintenance window. Railyard sendet eine Benachrichtigung an Regeln mit angehaktem data maintenance. Innerhalb des Fensters führt es geplante Postgres-Upgrades, Sicherheitsupdates auf Datenbank-Servern und VACUUM (ANALYZE) aus. Ohne gesetztes Fenster läuft nichts von selbst.

Ein dediziertes Redis pro App

Standardmäßig teilen sich Apps das Redis des Servers, jede mit ihrer eigenen Datenbanknummer. Give this app its own Redis auf der Redis-Karte setzt ein Memory-Limit und was passiert, wenn es voll ist (eine Eviction-Policy wie allkeys-lru). Deine Keys werden rüberkopiert. Go back to the shared Redis kopiert sie zurück.

API

Method	Path	Zweck
POST	/api/applications/:id/data_move	Daten zu einem Datenbank-Server verschieben (database_server_id)
POST / DELETE	/api/applications/:id/external_datastores	Eine externe URL nutzen, oder die Daten zurückholen
GET / POST	/api/servers/:id/database_replicas	Standbys auflisten oder hinzufügen; POST …/:id/promote stuft hoch
POST	/api/servers/:id/standby_rejoin	Einen ersetzten Server zum Standby des neuen Primary machen
GET / POST / DELETE	/api/servers/:id/connection_pooler	Der PgBouncer des Servers
GET / POST	/api/servers/:id/postgres_upgrades	Upgrades prüfen, planen, zurückrollen und aufräumen
GET / POST / DELETE	/api/applications/:id/database_forks	Forks (source ist live oder backup, optional mask_sql)
GET / PATCH	/api/applications/:id/redis	Geteiltes oder dediziertes Redis, Memory-Limit und Policy

Backups, Restores und Konsolen werden in Datenbanken und Backups behandelt. Für Version, Backup-Zeitplan und Verbindungsdetails einer einzelnen Engine siehe Postgres, Redis, MySQL und MongoDB.