Temos um novo capítulo da nossa série "Tech pills sobre Platform Engineering: além do que se encontra na documentação", onde a equipe de Engenharia de Plataformas da Codurance compartilha conhecimentos sobre questões que enfrentamos no nosso dia a dia. No post anterior, falamos sobre a migração do Amazon Linux para o Bottlerocket.
Desta vez, uma das nossas equipas de desenvolvimento foi confrontada com um novo desafio: migrar uma parte da aplicação para uma nova conta AWS.
No seguimento desta migração, haviam vários componentes da arquitetura a endereçar, um deles foi a migração de uma DocumentDB. Um dos fatores críticos desta migração era o elevado ritmo de escrita, que impossibilitou o recurso a uma migração através de snapshots dado que resultaria em perda de dados ou indisponibilidade do serviço, e consequente impacto para o negócio.
Qual foi a solução encontrada? Amazon Data Migration Service (DMS). Seguindo a documentação oficial, a equipa começou por configurar a instância DMS, os respetivos source e target endpoints. Verificada a correta ligação à respetiva origem e destino, foi então possível finalmente criar uma tarefa de migração. De modo a cumprir um dos requisitos para que a DocumentDB de destino estivesse constantemente atualizada, foi configurada a opção “Migrate existing data and replicate ongoing changes”.
Depois de concluída a tarefa de migração, ligamo-nos à DocumentDB de destino e verificámos que as bases de dados estavam presentes, as collections também mas os indexes estavam em falta.
Depois de alguma investigação, deparámo-nos com um documento referindo-se às melhores práticas na utilização do serviço e onde estava referido que nem todos os objetos eram migrados afim de otimizar a performance deste processo.
“AWS DMS creates tables, primary keys, and in some cases unique indexes, but it doesn't create any other objects that aren't required to efficiently migrate the data from the source. For example, it doesn't create secondary indexes, non-primary key constraints, or data defaults.”
To migrate secondary objects from your database, use the database's native tools if you are migrating to the same database engine as your source database.” - Documento referindo-se às melhores práticas.
Qual seria a melhor abordagem para ultrapassar esta situação? Felizmente a AWS disponibilizou uma ferramenta que simplificou este processo, a Amazon DocumentDB Index Tool.
- Exportar os source indexes da MongoDB
- Verificar a compatibilidade desses indexes no destino
- Restaurar os indexes na Amazon DocumentDB de destino, preferencialmente antes de iniciar a tarefa de migração através do serviço DMS.
De modo a estabelecer a ligação tanto à Base de Dados de origem como de destino, recorremos a uma instância AWS Cloud9, que se ligou localmente ao destino e fez uso de um VPC peering para se ligar à origem, numa account diferente. Nesta instância foi necessário instalar mongo shell para que se pudesse estabelecer a ligação a cada uma das DocumentDB.
## Instalar o mongo shell
echo -e "[mongodb-org-4.0] \nname=MongoDB Repository\nbaseurl=https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/4.0/x86_64/\ngpgcheck=1 \nenabled=1 \ngpgkey=https://www.mongodb.org/static/pgp/server-4.0.asc" | sudo tee /etc/yum.repos.d/mongodb-org-4.0.repo
sudo yum install -y mongodb-org-shell
## Descarregar a CA
wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
## Testar a ligação à Base de dados de origem
mongo --ssl --host [SOURCE_HOST]:[SOURCE_PORT] --sslCAFile global-bundle.pem --username administrator --password '[SOURCE_PASSWORD]'
## Testar a ligação à Base de dados de destino
mongo --ssl --host [TARGET_HOST]:[TARGET_PORT] --sslCAFile global-bundle.pem --username administrator --password '[TARGET_PASSWORD]'
Verificada a correta ligação a ambas as DocumentDB, foi necessário instalar a ferramenta de migração de indexes e executar os seguintes comandos.
## Clonar e instalar a ferramenta de migração de dados
git clone https://github.com/awslabs/amazon-documentdb-tools.git
cd amazon-documentdb-tools/index-tool
python3 -m pip install -r requirements.txt
## Criar um diretorio para exportar o index
mkdir -p docdb_index_export
## Copiar o anteriormente descarregado CA
cp -rp /home/ec2-user/environment/global-bundle.pem .
## Descarregar a informação do index da BD origem
python3 migrationtools/documentdb_index_tool.py --dump-indexes --dir docdb_index_export --uri 'mongodb://administrator:[SOURCE_PASSWORD]@[SOURCE_HOST]:[SOURCE_PORT]/?tls=true&tlsCAFile=global-bundle.pem&replicaSet=rs0&retryWrites=false'
## Verificar a compatibilidade do index com a base de dados de destino
python migrationtools/documentdb_index_tool.py --uri 'mongodb://administrator:[TARGET_PASSWORD]@[TARGET_HOST]:[TARGET_PORT]/?ssl=true&tlsCAFile=global-bundle.pem&replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false' --show-issues --dir docdb_index_export --support-2dsphere
## Restaurar o index na BD de destino
python migrationtools/documentdb_index_tool.py --uri 'mongodb://administrator:[TARGET_PASSWORD]@[TARGET_HOST]:[TARGET_PORT]/?ssl=true&tlsCAFile=global-bundle.pem&replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false' --restore-indexes --dir docdb_index_export --support-2dsphere
## Em caso de utilização de carateres especiais, deverá escapa-los
Configuração concluída! Podemos então ligarmo-nos à DocumentDB de destino e verificar que os indexes foram também migrados. Tínhamos então a DocumentDB pronta para receber os dados da migração.
Já alguma vez teve este problema, como é que o resolveste? Sabe mais algum método de como fazer isso?
