Servidores de base de datos

Por defecto, las bases de datos de una app corren en el mismo servidor que la app. Eso es económico y rápido, pero si ese servidor se pierde, solo sobreviven tus copias de seguridad. Un servidor de base de datos es uno de tus propios servidores que solo almacena datos.

Agrega un servidor de base de datos

Servidores → + Agregar un servidor de base de datos. Funciona como agregar un servidor, con algunas diferencias:

• No tiene proxy web ni herramientas de build, y nunca se despliegan apps en él.
• Sus puertos de datastore solo están abiertos a los servidores de apps que lo usan.
• Su página lista las apps cuyos datos almacena.

Elige dónde viven los datos de una app

Cuando creas una app, ¿Dónde deberían vivir los datos? ofrece tres opciones:

• Este servidor: el propio servidor de la app.
• Un servidor de base de datos: preseleccionado para producción cuando tu equipo tiene uno.
• Externo: pega la URL de un servicio administrado como RDS, ElastiCache o Elastic Cloud.

Para una app existente, ve a Configuración → Recursos → Mover datos a un servidor de base de datos. La tarjeta lista qué se copiará y qué empieza vacío, antes de que presiones el botón. Luego:

1. La app se detiene.
2. Postgres y MySQL se exportan y se restauran en el servidor de base de datos.
3. Redis, MongoDB, almacenamiento de objetos, definiciones de RabbitMQ y ClickHouse también se copian. Un Elasticsearch que solo usa esta app también se copia.
4. La app se vuelve a desplegar.

Si algún paso falla, la app vuelve a sus datos anteriores, que solo se leen y nunca se modifican. Memcached no se copia, y tampoco un Elasticsearch compartido con otra app: reindexa después de la migración.

Usar un servicio externo en la pestaña Recursos cambia la base de datos, Redis o Elasticsearch a una URL que tú proporciones. Railyard primero verifica la URL. Si no es alcanzable, no cambia nada, y tu app no se detiene. Puedes copiar los datos, y Traer de vuelta a Railyard lo revierte.

Protegido por defecto

• Copias de seguridad. Las bases de datos de apps en un servidor de base de datos obtienen una copia de seguridad cada 24 horas, y cada una se verifica restaurándola. Un horario que configures en la tarjeta de la base de datos se respeta.
• Standby (Pro y Team). También crear un standby en Agregar un servidor de base de datos crea un segundo servidor de base de datos del mismo tamaño. Una vez que ambos están activos, mantiene una copia en vivo de Postgres, MySQL y Redis, y un motor que empieces a usar después también se copia. Railyard verifica cada standby cada 5 minutos, muestra qué tan atrás está, y te avisa (reglas con mantenimiento de datos marcado) si deja de seguir o se queda más de 5 minutos atrás, y de nuevo cuando se pone al día.
• Failover automático. Si un servidor de base de datos deja de responder durante 3 minutos y su standby también ha perdido contacto con él, el standby toma el control: sirve los datos en los puertos habituales, cada app que usa el servidor de base de datos se vuelve a desplegar contra él, y la recuperación a un punto en el tiempo se reactiva ahí. Recibes una notificación con lo que se movió. Desactívalo por servidor en Mantenimiento → Réplicas de base de datos.
• Promover manualmente desde la página del primario (Mantenimiento → Réplicas de base de datos) o desde la propia página del standby. Hace el mismo relevo. Las escrituras que el servidor anterior recibió en sus últimos segundos pueden perderse, así que úsalo cuando el primario ya no esté o aceptes esa posibilidad.
• Convertirlo en el nuevo standby. Cuando el servidor anterior vuelve, su página indica que fue reemplazado y que ninguna app usa sus datos desactualizados. Convertirlo en el nuevo standby copia datos frescos desde el nuevo primario, para que la siguiente falla también quede cubierta.
• No se replica: Elasticsearch y un Redis dedicado por app empiezan vacíos en el standby después de un failover. Las apps reindexan Elasticsearch automáticamente después de su redespliegue.

El plan Free incluye un servidor de base de datos junto a tu servidor de app. Los standbys vienen con Pro y Team.

También puedes agregar una réplica de un solo motor a cualquier otro servidor del equipo desde Mantenimiento → Réplicas de base de datos. Una réplica en un servidor de app se mantiene en su propio puerto al promoverla (5433 para Postgres, 3307 para MySQL, 6380 para Redis); apunta las apps hacia ella tú mismo.

Pooler de conexiones (PgBouncer)

Hay dos interruptores:

1. Servidor → Mantenimiento → Pooler de conexiones → Activar. Esto corre PgBouncer en modo transacción en el puerto 6432. Los prepared statements de Rails siguen funcionando.
2. App → Recursos → Tarjeta de base de datos → Usar el pooler. A partir del siguiente despliegue, DATABASE_URL pasa por el pooler y DATABASE_DIRECT_URL conserva la dirección directa.

El paso de release (migraciones) siempre usa la dirección directa, porque los advisory locks no funcionan a través del pooling por transacción. Elegir el pooler para una app también lo inicia en el servidor si no está corriendo. No puedes desactivar el pooler de un servidor mientras una app lo esté usando.

Upgrades de versión mayor de Postgres (beta)

Servidor → Mantenimiento → Versión de Postgres.

1. Verificar compatibilidad. Esto es una simulación y no cambia nada. Verifica las extensiones de cada base de datos contra la nueva versión y se asegura de que haya aproximadamente el doble del tamaño de los datos en disco libre.
2. Actualizar ahora, o En la próxima ventana de mantenimiento. Railyard respalda primero cada base de datos, y cualquier copia de seguridad fallida detiene el upgrade. Cada base de datos se copia a la nueva versión y se cuentan sus tablas para confirmar la copia. Luego, la nueva versión toma el control del mismo puerto, así que las apps conservan su DATABASE_URL. Los inicios de sesión de la app se pausan durante la copia.
3. Revertir mientras se conserva la versión anterior (7 días por defecto). Todo lo escrito después del upgrade no está en la versión anterior.

Haz un fork de una base de datos

App → Recursos → Tarjeta de base de datos → Hacer un fork de esta base de datos (Postgres).

• Hacia: una base de datos nueva en cualquier servidor con Postgres administrado por Railyard, que obtiene su propio login y contraseña. O reemplazar los datos de un entorno de staging o de vista previa. Producción nunca es un destino.
• Desde: una copia en vivo tomada ahora, o la última copia de seguridad.
• Enmascarar: pega SQL, por ejemplo UPDATE users SET email = 'user' || id || '@example.test', phone = NULL;. Se ejecuta en la copia antes de que alguien pueda usarla. Si falla, la copia se elimina, así que nunca hay un fork sin enmascarar.

Las reglas de enmascarado por columna en la interfaz y los forks instantáneos copy-on-write todavía no están implementados.

Ventanas de mantenimiento

Define un horario semanal en Equipo → Mantenimiento, o por servidor en Configuración → Ventana de mantenimiento de datos. Railyard envía avisos a las reglas con mantenimiento de datos marcado. Dentro de la ventana corre los upgrades de Postgres programados, las actualizaciones de seguridad en servidores de base de datos y VACUUM (ANALYZE). Sin una ventana configurada, nada corre por su cuenta.

Un Redis dedicado por app

Por defecto, las apps comparten el Redis del servidor, cada una con su propio número de base de datos. Darle a esta app su propio Redis en la tarjeta de Redis configura un límite de memoria y qué pasa cuando se llena (una política de desalojo como allkeys-lru). Tus llaves se copian al nuevo. Volver al Redis compartido las copia de regreso.

API

Método	Ruta	Propósito
POST	/api/applications/:id/data_move	Mueve datos a un servidor de base de datos (database_server_id)
POST / DELETE	/api/applications/:id/external_datastores	Usa una URL externa, o trae los datos de vuelta
GET / POST	/api/servers/:id/database_replicas	Lista o agrega standbys; POST …/:id/promote promueve
POST	/api/servers/:id/standby_rejoin	Convierte un servidor reemplazado en el standby del nuevo primario
GET / POST / DELETE	/api/servers/:id/connection_pooler	El PgBouncer del servidor
GET / POST	/api/servers/:id/postgres_upgrades	Verifica, programa, revierte y limpia upgrades
GET / POST / DELETE	/api/applications/:id/database_forks	Forks (source es live o backup, mask_sql opcional)
GET / PATCH	/api/applications/:id/redis	Redis compartido o dedicado, límite de memoria y política

Las copias de seguridad, restauraciones y consolas se cubren en Bases de datos y copias de seguridad.