Bancos de dados

O Orbit roda PostgreSQL, MySQL 8.4 e Redis 7.4 ao lado das suas aplicações, cada um com um volume no disco do servidor em /var/lib/rancher/k3s/storage. Bancos PostgreSQL novos rodam no CloudNativePG.

Os dados ficam no disco de um servidor

Se esse servidor for perdido, os dados vão junto, a menos que os backups vão para um armazenamento externo. Os tamanhos de armazenamento são pedidos, não impostos.

Conectando aplicações

• Só aplicações do mesmo ambiente conseguem conectar. O endereço é <nome>.orbit-<projeto>-<ambiente>.svc.cluster.local. O Orbit cria o banco e o usuário com o nome do serviço (- vira _) e uma senha aleatória.
• Conectar numa aplicação adiciona uma referência como DATABASE_URL às variáveis dela. O valor é preenchido no deploy da aplicação, então publique de novo depois de conectar. A página do banco lista as aplicações que o usam.

Conectando do seu computador

Mostrar credenciais na página do banco revela usuário, senha e banco, com dois caminhos:

• Um túnel SSH pelo servidor principal, que mantém o banco privado: rode o comando mostrado e conecte psql, DBeaver ou TablePlus em 127.0.0.1:15432 (13306 para MySQL, 16379 para Redis).
• O endereço público, quando o acesso é público.

Cada revelação fica registrada na Atividade.

Vendo os dados

Ver dados abre as tabelas, com linhas e tamanho estimados, e pagina as linhas delas. No Redis, busca as chaves por padrão e mostra cada valor conforme o tipo.

• Consultas: a aba Consulta roda um comando SQL (um SELECT, WITH, VALUES ou TABLE) numa transação somente leitura. Ela para depois de 15 segundos, devolve até 500 linhas e corta células em 1.000 caracteres. Cada consulta fica registrada na Atividade com o texto.
• Somente leitura é uma proteção, não uma permissão: um comando que escreve é recusado antes de rodar, e a transação pega o resto. Para mudar dados, conecte do seu computador.

Acesso público

Tornar um banco público o publica no IP do servidor, na porta do motor (5432, 3306 ou 6379, ou a próxima livre). Abra essa porta no firewall do seu provedor só para os endereços que precisam, e volte o banco para privado quando não precisarem mais.

Trocando credenciais

O Orbit troca a senha, atualiza todas as aplicações que usam o banco (inclusive as versões guardadas para rollback) e as reinicia, e depois confere que a senha antiga é recusada. Aplicações que leem a senha de outro lugar que não as variáveis do Orbit precisam ser atualizadas à mão.

Upgrades

O Orbit faz backup do banco antes, roda a versão nova e confere que ela tem as mesmas tabelas e linhas (ou chaves).

• No CloudNativePG, o PostgreSQL faz upgrade no lugar com pg_upgrade, e a versão anterior volta se isso falhar.
• No runtime StatefulSet, mais antigo, levar o PostgreSQL para uma versão major nova restaura o backup num volume novo, então demora mais ou menos o mesmo que um restore. Um upgrade que falha sobe a versão anterior de novo com os seus próprios dados.

PostgreSQL no CloudNativePG

O Orbit instala o operador CloudNativePG e o plugin Barman Cloud quando o primeiro banco PostgreSQL é criado. O CloudNativePG traz réplicas em outros servidores e recuperação até um momento.

Movendo um banco antigo: um banco PostgreSQL criado antes do CloudNativePG mostra Mover para o CloudNativePG na sua página. A prévia diz por quanto tempo as escritas pausam, para onde vai o backup, se o servidor tem disco para uma segunda cópia e que o volume atual é mantido.

1. O Orbit faz backup do banco.
2. Ele sobe o cluster ao lado do banco atual.
3. Ele pausa as escritas (as leituras continuam) e copia os dados, conferindo que o cluster tem as mesmas tabelas e linhas.
4. Ele aponta o endereço que as aplicações usam para o cluster e as reinicia, com as mesmas variáveis.

Se uma etapa falhar, o Orbit remove o cluster e o banco antigo volta a aceitar escritas. O volume antigo fica no servidor, congelado e somente leitura, até Remover volume antigo.

MySQL

• Ele precisa de pelo menos 512 MB.
• O usuário da aplicação só alcança o próprio banco. Um root local, cuja senha o Orbit guarda e nunca mostra, faz backups, restores e trocas de senha.
• Um restore primeiro confere que o dump está completo e o carrega num banco de preparação, e só então troca o banco em uso, então um backup quebrado deixa os dados como estavam.

Olhando por dentro

sudo k3s kubectl -n orbit-<projeto>-<ambiente> get clusters.postgresql.cnpg.io,pods,pvc
sudo k3s kubectl -n orbit-<projeto>-<ambiente> exec -it <nome>-1 -c postgres -- sh -c 'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB"'