Servidores de banco de dados

Por padrão, os bancos de dados de uma aplicação rodam no mesmo servidor que a aplicação. Isso é barato e rápido, mas se esse servidor for perdido, só os backups sobrevivem. Um servidor de banco de dados é um dos seus próprios servidores dedicado só a guardar dados.

Adicione um servidor de banco de dados

Servidores → + Adicionar um servidor de banco de dados. Funciona como adicionar um servidor, com algumas diferenças:

• Ele não recebe proxy web nem ferramentas de build, e nenhuma aplicação é implantada nele.
• As portas dos bancos de dados só ficam abertas para os servidores de aplicação que os usam.
• A página dele lista as aplicações cujos dados ele guarda.

Escolha onde os dados da aplicação ficam

Ao criar uma aplicação, Onde os dados devem ficar? oferece três opções:

• Este servidor: o próprio servidor da aplicação.
• Um servidor de banco de dados: pré-selecionado para produção quando sua equipe já tem um.
• Externo: cole a URL de um serviço gerenciado, como RDS, ElastiCache ou Elastic Cloud.

Para uma aplicação já existente, vá em Configurações → Recursos → Mover dados para um servidor de banco de dados. O card lista o que será copiado e o que começa vazio antes de você clicar no botão. Depois disso:

1. A aplicação é parada.
2. Postgres e MySQL são exportados e restaurados no servidor de banco de dados.
3. Redis, MongoDB, armazenamento de objetos, definições do RabbitMQ e ClickHouse também são copiados. Um Elasticsearch usado só por essa aplicação também é copiado.
4. A aplicação faz o deploy de novo.

Se algum passo falhar, a aplicação volta para os dados antigos, que são apenas lidos e nunca alterados. O Memcached não é copiado, nem um Elasticsearch compartilhado com outra aplicação: nesse caso, reindexe depois da mudança.

Usar um serviço externo, na aba Recursos, troca o banco de dados, o Redis ou o Elasticsearch por uma URL que você fornece. O Railyard testa a URL antes. Se ela não responder, nada muda e sua aplicação não é parada. Você pode copiar os dados depois, e Trazer de volta para o Railyard desfaz a troca.

Protegido por padrão

• Backups. Bancos de dados de aplicações em um servidor de banco de dados recebem um backup a cada 24 horas, e cada um é verificado restaurando-o. Um horário que você definir no card do banco de dados é respeitado.
• Standby (Pro e Team). Também criar um standby, em Adicionar um servidor de banco de dados, cria um segundo servidor de banco de dados do mesmo tamanho. Depois que os dois estão no ar, ele mantém uma cópia viva do Postgres, MySQL e Redis, e qualquer outro motor que você passar a usar depois também é copiado. O Railyard verifica cada standby a cada 5 minutos, mostra o quanto ele está atrasado e te avisa (regras com manutenção de dados marcado) se ele parar de replicar ou ficar mais de 5 minutos atrasado, e de novo quando ele se recupera.
• Failover automático. Se um servidor de banco de dados parar de responder por 3 minutos e o standby também tiver perdido contato com ele, o standby assume: passa a servir os dados nas portas usuais, toda aplicação que usa o servidor de banco de dados faz o deploy de novo apontando para ele, e o point-in-time recovery é religado nele. Você recebe uma notificação listando o que mudou. Desative por servidor em Manutenção → Réplicas de banco de dados.
• Promover manualmente, pela página do primário (Manutenção → Réplicas de banco de dados) ou pela própria página do standby. Faz a mesma troca. Gravações que o servidor antigo recebeu nos últimos segundos podem ser perdidas, então use isso quando o primário tiver sumido de verdade ou quando você aceitar esse risco.
• Transformar em novo standby. Quando o servidor antigo volta, sua página avisa que ele foi substituído e que nenhuma aplicação usa seus dados desatualizados. Transformar em novo standby copia dados atualizados do novo primário, para que a próxima falha também esteja coberta.
• Não replicado: o Elasticsearch e um Redis dedicado por aplicação começam vazios no standby depois de um failover. As aplicações reindexam o Elasticsearch automaticamente depois do deploy.

O plano Free inclui um servidor de banco de dados junto do seu servidor de aplicação. Standbys vêm com o Pro e o Team.

Você também pode adicionar uma réplica de um único motor em qualquer outro servidor da equipe, em Manutenção → Réplicas de banco de dados. Uma réplica em um servidor de aplicação mantém sua própria porta quando promovida (5433 para Postgres, 3307 para MySQL, 6380 para Redis); aponte as aplicações para ela manualmente.

Pooler de conexões (PgBouncer)

Existem dois interruptores:

1. Servidor → Manutenção → Pooler de conexões → Ativar. Isso roda o PgBouncer em modo transaction na porta 6432. Prepared statements do Rails continuam funcionando.
2. Aplicação → Recursos → Card do banco de dados → Usar o pooler. A partir do próximo deploy, DATABASE_URL passa a ir pelo pooler e DATABASE_DIRECT_URL mantém o endereço direto.

A etapa de release (migrations) sempre usa o endereço direto, porque locks consultivos não funcionam com pooling em modo transaction. Escolher o pooler para uma aplicação também o inicia no servidor, se ainda não estiver rodando. Você não pode desativar o pooler de um servidor enquanto alguma aplicação o usa.

Upgrades de versão major do Postgres (beta)

Servidor → Manutenção → Versão do Postgres.

1. Verificar compatibilidade. Isso é uma simulação e não muda nada. Verifica as extensões de cada banco de dados contra a nova versão e confirma que há disco livre suficiente, cerca do dobro do tamanho dos dados.
2. Fazer upgrade agora, ou Na próxima janela de manutenção. O Railyard faz backup de todos os bancos antes, e qualquer backup que falhe interrompe o upgrade. Cada banco é copiado para a nova versão e suas tabelas são contadas para confirmar a cópia. Depois, a nova versão assume a mesma porta, então as aplicações mantêm sua DATABASE_URL. Os logins das aplicações ficam pausados durante a cópia.
3. Reverter enquanto a versão antiga é mantida (7 dias por padrão). Qualquer escrita feita depois do upgrade não existe na versão antiga.

Fazer um fork de um banco de dados

Aplicação → Recursos → Card do banco de dados → Fazer fork deste banco (Postgres).

• Destino: um banco novo em qualquer servidor com Postgres gerenciado pelo Railyard, com seu próprio login e senha. Ou substituir os dados de um ambiente de staging ou preview. A produção nunca pode ser destino.
• Origem: uma cópia feita agora, ou o último backup.
• Mascaramento: cole um SQL, por exemplo UPDATE users SET email = 'user' || id || '@example.test', phone = NULL;. Ele roda na cópia antes que qualquer pessoa possa usá-la. Se falhar, a cópia é excluída, então nunca existe um fork sem mascaramento.

Regras de mascaramento por coluna na interface e forks instantâneos com copy-on-write ainda não existem.

Janelas de manutenção

Defina um horário semanal em Equipe → Manutenção, ou por servidor em Configurações → Janela de manutenção de dados. O Railyard avisa as regras com manutenção de dados marcado. Dentro da janela, ele executa os upgrades agendados do Postgres, as atualizações de segurança dos servidores de banco de dados e o VACUUM (ANALYZE). Sem uma janela definida, nada roda por conta própria.

Um Redis dedicado por aplicação

Por padrão, as aplicações compartilham o Redis do servidor, cada uma com seu próprio número de banco. Dar um Redis próprio a esta aplicação, no card do Redis, define um limite de memória e o que acontece quando ele enche (uma política de descarte como allkeys-lru). Suas chaves são copiadas para o novo Redis. Voltar para o Redis compartilhado copia tudo de volta.

API

Método	Caminho	Finalidade
POST	/api/applications/:id/data_move	Mover dados para um servidor de banco de dados (database_server_id)
POST / DELETE	/api/applications/:id/external_datastores	Usar uma URL externa, ou trazer os dados de volta
GET / POST	/api/servers/:id/database_replicas	Listar ou adicionar standbys; POST …/:id/promote promove
POST	/api/servers/:id/standby_rejoin	Transformar um servidor substituído no standby do novo primário
GET / POST / DELETE	/api/servers/:id/connection_pooler	O PgBouncer do servidor
GET / POST	/api/servers/:id/postgres_upgrades	Verificar, agendar, reverter e limpar upgrades
GET / POST / DELETE	/api/applications/:id/database_forks	Forks (source é live ou backup, mask_sql opcional)
GET / PATCH	/api/applications/:id/redis	Redis compartilhado ou dedicado, limite de memória e política

Backups, restaurações e consoles estão em Bancos de dados e backups.