Estou procurando uma maneira de configurar a replicação contínua de dados entre um Microsoft SQL Server local para o AWS RDS PostgreSQL. A tabela de origem é atualizada uma vez a cada 24 horas . O desafio aqui é que eu não tenho nenhum controle sobre o banco de dados de origem (on-prem). Tudo o que tenho é um usuário de banco de dados que posso usar para consultar o banco de dados. Em poucas palavras, estou procurando os seguintes requisitos:
- A máquina de origem não deve ser modificada de forma alguma (ou seja, aplicando configurações à máquina de origem)
- Barato (não requer um servidor de migração para funcionar 24 horas por dia, 7 dias por semana) e fácil de gerenciar (configure uma vez e esqueça)
- Idealmente, a solução deve migrar apenas as alterações feitas na tabela de banco de dados de origem, como adicionar/remover registros. Em outras palavras, evite esvaziar a tabela de destino e preenchê-la novamente com os registros da tabela de origem (é isso que o AWS DMS " Full-Load " faria)
Eu estava analisando a replicação contínua do AWS DMS, mas ela exige alterações na máquina de origem, então tive que descartar essa solução (consulte Usar um banco de dados do Microsoft SQL Server como origem para o AWS DMS ). Além disso, essa solução exigiria uma " Instância de replicação " para ser executada 24 horas por dia, 7 dias por semana.
Há mais alguma coisa que eu deveria estar olhando que satisfaça os requisitos acima? Ou minha única opção seria ir com a migração "Full-Load" do AWS DMS, que seria uma solução potencialmente cara, desde a frequência de atualizações na tabela do banco de dados de origem?
Agradeço qualquer opinião sobre o problema, por favor.
Este é um processo de pensamento muito rudimentar sobre uma coisa que você poderia fazer (e tenho certeza de que há maneiras de ajustar essa ideia, que continuarei atualizando conforme penso nelas), mas você pode aproveitar algumas das coisas que o MS SQL Server e AWS oferecem para atender a maioria das suas necessidades.
Em ordem de eventos, estas são as etapas que você pode seguir:
Aumente a escala de um Microsoft SQL Server adicional possivelmente usando o SQL Server Express Edition : esse servidor abrigará um trabalho que manipulará a extração dos dados do seu MS SQL Server primário e a comparação com sua instância do AWS PostgreSQL, para gerar as alterações.
Existem muitas limitações com o SQL Server Express Edition, então você terá que ler sobre ele, mas é uma edição gratuita do Microsoft SQL Server, então ele marca a caixa de seleção barata se você puder aproveitá-la. Se você não puder, uma alternativa um tanto barata seria usar o SQL Server Standard Edition em um servidor de dois núcleos. Certifique-se de instalar o componente Integration Services durante a instalação do SQL Server (independentemente da edição escolhida).
Você pode optar por dimensionar isso na AWS, uma VM ou como achar melhor. (Na AWS, você pode criar um trabalho que ative e desative esse servidor conforme necessário.)
Crie um projeto do SQL Server Integration Services : isso será compilado em um pacote SSIS que ficará no servidor de trabalho do servidor acima. No projeto SSIS, você poderá se conectar ao Microsoft SQL Server primário, extrair os dados da tabela de origem e, em seguida, extrair a cópia de destino da tabela em sua instância do AWS PostgreSQL e comparar os dois conjuntos de dados para mudanças. Como você implementa seu comparador depende de você, mas uma coisa no Microsoft SQL Server que pode ser útil é uma função chamada HASHBYTES(). Você pode fazer o hash de toda a linha e comparar o hash com as linhas com hash da instância do AWS PostgreSQL. (Não tenho certeza se há uma função equivalente no PostgreSQL, mas se não houver, você pode importar os dados da tabela do PostgreSQL para o servidor de tarefas do MS SQL primeiro e depois comparar os dois conjuntos de dados com HASHBYTES.) as linhas resultantes que foram alteradas para um destino. Infelizmente, não acho que você poderá enviá-los diretamente para sua instância do AWS PostgreSQL, portanto, a próxima etapa será uma etapa intermediária.
Adicione uma etapa ao seu projeto SSIS para gerar as linhas que foram alteradas para outra tabela de preparo em seu servidor de trabalho ou para um arquivo bruto como um CSV. (Isso cabe a você decidir como implementar, pois uma tabela de preparo significa que você precisará aproveitar um processo mais complexo na AWS para extrair os dados. Acho que um CSV é a rota mais simples, você só precisa garantir você configura um compartilhamento de arquivo para o arquivo a ser salvo.)
Implante o projeto SSIS como um pacote em seu servidor de trabalho Microsoft SQL. Em seguida, use o SQL Agent para agendar um trabalho executado diariamente para executar o pacote SSIS.
Crie um bucket do S3 (ou solução de armazenamento alternativa da AWS) em sua nuvem AWS para onde o arquivo bruto da etapa 3 será copiado.
Crie um trabalho agendado que migrará seu arquivo bruto da etapa 3 para o bucket do S3 na etapa 5. Novamente, isso depende de você e pode ser realizado de várias maneiras, como nos exemplos a seguir:
Aproveite o SDK da AWS ou os serviços alternativos que eles fornecem para criar um trabalho da AWS que carrega os dados do arquivo que você importou para o bucket do S3 em sua instância do PostgreSQL. Eu recomendaria importá-lo para uma tabela de teste separada no PostgreSQL primeiro (mas isso depende de você como você acaba implementando-o). (Você pode rolar a etapa 6 para o mesmo trabalho criado para esta etapa.) Consulte este documento da AWS para obter mais informações: Importar dados para o PostgreSQL no Amazon RDS
Após importar os dados acima para uma tabela de teste no PostgreSQL, você pode (no mesmo trabalho ou em um novo trabalho), excluir da sua tabela de destino os registros com as mesmas chaves primárias dos registros em sua tabela de teste. Em seguida, insira os registros de sua tabela de preparo na tabela de destino. (Embora isso esteja tecnicamente fazendo um DELETE / INSERT nos registros que foram atualizados, ainda é melhor do que truncar a tabela inteira e inserir tudo, então acho que deve ser suficiente sua exigência de não fazer um carregamento completo.)
Implementar esse processo vai ser muito trabalhoso (mais do que foi necessário para ler :), então você pode considerar apenas pagar uma empresa parceira da AWS para implementar uma solução para você se for muito tempo para implementar, mas isso cabe a você decidir.
Uma outra coisa que pode ser útil estar ciente no Microsoft SQL Server é o Change Data Capture (CDC) . Este é um processo no SQL Server que registra as alterações nas tabelas (basicamente mantém uma tabela de log de transações de cada tabela em seu banco de dados). Pode ser útil em conjunto ou no lugar do SSIS e é o principal componente do Microsoft SQL Server que o DMS pronto para uso da AWS usa para migrar dados do SQL Server.
Outro componente semelhante no Microsoft SQL Server é chamado de Tabelas Temporais , que possui funcionalidade semelhante ao Change Data Capture (mas provavelmente é menos usado).
Se você tiver alguma dúvida, ficarei feliz em elaborar qualquer uma das etapas da minha solução aproximada acima.