Migração de banco de dados PostgreSQL concluída com 11 segundos de indisponibilidade
(gds.blog.gov.uk)Como migramos nosso banco de dados PostgreSQL
- O GOV.UK Notify está migrando toda a sua infraestrutura para sua própria conta AWS, já que o PaaS atualmente em uso será descontinuado.
- Este artigo explica como o banco de dados PostgreSQL foi migrado com o mínimo possível de indisponibilidade.
Migração do banco de dados
- Eles estavam usando um banco de dados AWS RDS PostgreSQL fornecido pelo PaaS e precisavam migrá-lo para um novo banco de dados em sua própria conta AWS.
- O principal desafio era configurar o novo banco de dados PostgreSQL e fazer com que todos os aplicativos se comunicassem com ele.
Mais informações sobre o banco de dados de origem
- O banco de dados de origem tem cerca de 400 GB, com 130 milhões de linhas, 85 tabelas, 185 índices e 120 chaves estrangeiras.
- Em dias úteis, ocorrem cerca de 1.000 inserções ou atualizações por segundo, e o GOV.UK Notify envia milhões de notificações importantes e sensíveis ao tempo todos os dias.
AWS Database Migration Service
- Eles usaram o AWS Database Migration Service (DMS) para transferir os dados do banco de dados de origem para o banco de dados de destino.
- O DMS copia todos os dados até um determinado momento por meio de uma tarefa de "carga completa" e, no modo de replicação, faz com que todas as novas transações do banco de dados de origem sejam refletidas no banco de dados de destino.
Processo de migração do banco de dados
Configuração da instância DMS
- Eles criaram uma instância DMS na conta AWS de origem e concederam credenciais PostgreSQL com acesso aos bancos de dados de origem e de destino.
Configuração do banco de dados de destino
- Eles criaram uma instância RDS de destino em sua própria conta AWS e atualizaram a versão do PostgreSQL para 15.
- Usaram
pg_dumppara extrair o schema do banco de dados de origem e aplicaram as declarações de tabela no banco de dados de destino.
Carga completa
- Depois de criar as tabelas no banco de dados de destino, iniciaram a tarefa de carga completa do DMS, que foi concluída em cerca de 6 horas.
- Após a conclusão da carga completa, adicionaram os índices e as restrições de chave.
Replicação
- Depois que a tarefa de carga completa terminou, iniciaram a tarefa de replicação contínua do DMS (captura de dados de mudança) para sincronizar os bancos de dados de origem e de destino.
Preparação para a migração do tráfego
- Eles planejaram o processo para fazer com que os aplicativos parassem de se comunicar com o banco de dados de origem e passassem a se comunicar com o banco de dados de destino.
Interrupção do tráfego para o banco de dados de origem
- Usaram um script para interromper todo o tráfego para o banco de dados de origem.
Verificação da replicação
- Confirmaram se o banco de dados de destino estava completamente sincronizado.
Troca suave do tráfego
- Forneceram aos aplicativos, por meio de variáveis de ambiente, a localização, o nome de usuário e a senha necessários para se conectar ao banco de dados, e fizeram a troca rapidamente por meio de uma alteração de DNS.
O que aconteceu no dia da migração
- Executaram com sucesso o script de migração para fazer com que os aplicativos parassem de se comunicar com o banco de dados de origem e passassem a se comunicar com o novo banco de dados de destino.
- Durante a migração, houve uma breve indisponibilidade de cerca de 11 segundos.
Lições aprendidas
- O motivo para usar o DMS foi o bom suporte no GOV.UK PaaS, além de terem podido contar com o suporte da AWS.
- Se fizerem outra migração de banco de dados entre PostgreSQLs no futuro, pretendem dedicar mais tempo para testar outras ferramentas, como o pglogical.
Próximos passos da migração do GOV.UK Notify para a AWS
- Após concluir a migração do banco de dados, eles pretendem migrar os aplicativos para o AWS Elastic Container Service (ECS).
Opinião do GN⁺:
- O ponto mais importante deste artigo é que a equipe do GOV.UK Notify migrou com sucesso seu banco de dados PostgreSQL usando o AWS Database Migration Service (DMS).
- O artigo oferece orientações úteis, com base em um caso real, para profissionais de tecnologia que estejam planejando uma migração de banco de dados.
- Ele traz insights sobre como minimizar a indisponibilidade durante a migração e manter a consistência dos dados, o que pode ajudar outras organizações ou pessoas em situações semelhantes.
1 comentários
Opiniões do Hacker News
Questiona por que o governo usa AWS, argumentando que construir uma nuvem para o setor público ou adotar uma abordagem on-premises poderia reduzir o desperdício de impostos no longo prazo.
Compartilha a experiência de ter realizado com sucesso uma migração de banco de dados com cerca de 20 segundos de downtime usando AWS RDS Blue/Green Deployments.
Menciona várias formas de pausar consultas no PostgreSQL e explica que é possível reduzir o downtime atrasando as queries até que a replicação alcance o estado esperado.
Descreve o processo de migração de um banco de dados PostgreSQL auto-hospedado da versão 12 para a 16 e compartilha que houve cerca de 30 minutos de downtime devido a problemas inesperados.
Afirma que usar o AWS Database Migration Service e trocar a entrada DNS, aceitando 11 segundos de downtime, é uma forma de evitar complexidade.
Aponta que queries de longa duração são inimigas de migrações com baixo downtime e explica a dificuldade de lidar com esse tipo de consulta.
Compartilha o processo de migração do PostgreSQL 14 para o 16 e menciona que, na próxima vez, pretende usar AWS Blue/Green Deployments para evitar downtime.
Explica como usar registros DNS do AWS Route53 para que o script de migração do banco de dados atualize o peso do DNS e espere a expiração de um TTL de 1 segundo.
Faz uma piada dizendo que espera que a Amazon lance um produto chamado 'governo-como-serviço'.
Compartilha a experiência de migrar um dataset de AWS RDS MySQL para RDS PostgreSQL usando AWS DMS e não recomenda o uso da ferramenta de conversão de schema.