Utilizar o Amazon DocumentDB como destino para o AWS Database Migration Service

Para obter informações sobre as versões do Amazon DocumentDB (compatíveis com o MongoDB) compatíveis com o AWS DMS, consulte Metas para AWS DMS. É possível utilizar o AWS DMS para migrar os dados para o Amazon DocumentDB (compatível com MongoDB) de qualquer mecanismo de dados de origem compatível com o AWS DMS. O mecanismo pode estar em um serviço gerenciado pela AWS, como o Amazon RDS, o Aurora ou o Amazon S3. Ou o mecanismo pode estar em um banco de dados autogerenciado, como o MongoDB em execução no Amazon EC2 ou on-premises.

É possível utilizar o AWS DMS para replicar dados de origem para bancos de dados, coleções ou documentos do Amazon DocumentDB.

nota

Se o endpoint de origem for o MongoDB ou o Amazon DocumentDB, execute a migração no Modo documento.

O MongoDB armazena dados em um formato JSON binário (BSON). O AWS DMS é compatível com todos os tipos de dados BSON compatíveis com o Amazon DocumentDB. Para obter uma lista desses tipos de dados, consulte APIs, operações e tipos de dados do MongoDB compatíveis no Guia do desenvolvedor do Amazon DocumentDB.

Se o endpoint de origem for um banco de dados relacional, o AWS DMS mapeará os objetos do banco de dados para o Amazon DocumentDB da seguinte maneira:

• Um banco de dados relacional ou esquema de banco de dados, é mapeado para um banco de dados Amazon DocumentDB.

• As tabelas dentro de um banco de dados relacional são mapeadas para coleções no Amazon DocumentDB.

• Os registros em uma tabela relacional são mapeados para documentos no Amazon DocumentDB. Cada documento é construído a partir de dados no registro de origem.

Se o endpoint de origem for o Amazon S3, os objetos resultantes do Amazon DocumentDB corresponderão às regras de mapeamento do AWS DMS para o Amazon S3. Por exemplo, considere o URI a seguir.

s3://mybucket/hr/employee

Neste caso, o AWS DMS mapeia os objetos em mybucket para o Amazon DocumentDB da seguinte maneira:

• A parte de nível superior do URI (hr) é mapeada para um banco de dados Amazon DocumentDB.

• A próxima parte do URI (employee) é mapeada para uma coleção do Amazon DocumentDB.

• Cada objeto em employee é mapeado para um documento no Amazon DocumentDB.

Para obter mais informações sobre as regras de mapeamento do Amazon S3, consulte Utilizar o Amazon S3 como origem do AWS DMS.

Configurações do endpoint do Amazon DocumentDB

Nas versões 3.5.0 e superiores do AWS DMS, é possível melhorar o desempenho da captura de dados de alteração (CDC) para endpoints do Amazon DocumentDB ajustando as configurações da tarefa para threads paralelos e operações em massa. Para fazer isso, especifique o número de threads simultâneos, as filas por thread e o número de registros a serem armazenados em um buffer utilizando as configurações da tarefa ParallelApply*. Por exemplo, suponha que você queira executar uma carga de CDC e aplicar 128 threads em paralelo. Você também quer acessar 64 filas por thread, com 50 registros armazenados por buffer.

Para promover o desempenho da CDC, o AWS DMS é compatível com estas configurações de tarefa:

• ParallelApplyThreads: especifica o número de threads simultâneos que AWS DMS utiliza durante uma carga de CDC para enviar registros de dados para um endpoint de destino do Amazon DocumentDB. O valor padrão é zero (0) e o valor máximo é 32.

• ParallelApplyBufferSize: especifica o número máximo de registros a serem armazenados em cada fila de buffer para que os threads simultâneos enviem para um endpoint de destino do Amazon DocumentDB durante uma carga de CDC. O valor padrão é 100 e o valor máximo é 1.000. Utilize essa opção quando ParallelApplyThreads especificar mais de um thread.

• ParallelApplyQueuesPerThread: especifica o número de filas que cada thread acessa para utilizar registros de dados das filas e gerar uma carga em lote para um endpoint do Amazon DocumentDB durante a CDC. O padrão é 1. O máximo é 512.

Para obter mais detalhes sobre como trabalhar com o Amazon DocumentDB como destino do AWS DMS, consulte as seguintes seções:

nota

Para obter uma explicação detalhada do processo de migração, consulte Migração do MongoDB para o Amazon DocumentDB no Guia de migração passo a passo do AWS Database Migration Service.

Mapear dados de uma origem para um destino do Amazon DocumentDB

O AWS DMS lê registros do endpoint de origem e constrói documentos JSON com base nos dados que lê. Para cada documento JSON, o AWS DMS deve determinar um campo _id para atuar como um identificador exclusivo. Ele grava o documento JSON em uma coleção do Amazon DocumentDB, utilizando o campo _id como uma chave primária.

Dados de origem que são uma coluna individual

Se os dados de origem consistirem em uma única coluna, os dados deverão ser de um tipo de string. (Dependendo do mecanismo de origem, os tipos de dados reais podem ser VARCHAR, NVARCHAR, TEXT, LOB, CLOB ou semelhante.) O AWS DMS presume que os dados são um documento JSON válido e replica os dados para o Amazon DocumentDB no estado em que se encontra.

Se o documento JSON resultante contiver um campo chamado _id, o campo será utilizado como o _id exclusivo no Amazon DocumentDB.

Se o JSON não contiver um campo _id, o Amazon DocumentDB gerará um valor de _id automaticamente.

Dados de origem que são várias colunas

Se os dados de origem consistirem em várias colunas, o AWS DMS criará um documento JSON a partir de todas essas colunas. Para determinar o campo _id para o documento, o AWS DMS procederá da seguinte maneira:

• Se uma das colunas for chamada _id, os dados dessa coluna serão utilizados como o _id de destino.

• Se não houver uma coluna _id, mas os dados de origem tiverem uma chave primária ou um índice exclusivo, o AWS DMS usará essa chave ou esse valor de índice como o valor de _id. Os dados da chave primária ou do índice exclusivo também aparece como campos explícitos no documento JSON.

• Se não houver nenhuma coluna _id e nenhuma chave primária ou índice exclusivo, o Amazon DocumentDB gerará um valor de _id automaticamente.

Coagir um tipo de dados no endpoint de destino

O AWS DMS pode modificar as estruturas de dados ao gravar em um endpoint de destino do Amazon DocumentDB. É possível solicitar essas alterações renomeando colunas e tabelas no endpoint de origem ou fornecendo regras de transformação que são aplicadas quando uma tarefa está sendo executada.

Utilizar um documento JSON aninhado (json_ prefix)

Para coagir um tipo de dados, é possível prefixar o nome da coluna de origem com json_ (ou seja, json_columnName) manualmente ou utilizando uma transformação. Nesse caso, a coluna é criada como um documento JSON aninhado dentro do documento de destino, e não como um campo de string.

Por exemplo, suponha que você deseja migrar o documento a seguir de um endpoint de origem do MongoDB.

{
    "_id": "1", 
    "FirstName": "John", 
    "LastName": "Doe",
    "ContactDetails": "{"Home": {"Address": "Boston","Phone": "1111111"},"Work": { "Address": "Boston", "Phone": "2222222222"}}"
}

Se você não coagir nenhum dos tipos de dados de origem, o documento ContactDetails incorporado será migrado como uma string.

{
    "_id": "1", 
    "FirstName": "John", 
    "LastName": "Doe",
    "ContactDetails": "{\"Home\": {\"Address\": \"Boston\",\"Phone\": \"1111111\"},\"Work\": { \"Address\": \"Boston\", \"Phone\": \"2222222222\"}}"
}

No entanto, é possível adicionar uma regra de transformação para coagir ContactDetails para um objeto JSON. Por exemplo, suponha que o nome original da coluna de origem seja ContactDetails. Para forçar o tipo de dados como JSON aninhado, a coluna no endpoint de origem precisa ser renomeada como “json_ContactDetails adicionando o prefixo “*json_*” na origem manualmente ou por meio de regras de transformação. Por exemplo, é possível utilizar a regra de transformação abaixo:

{
    "rules": [
    {
    "rule-type": "transformation",
    "rule-id": "1",
    "rule-name": "1",
    "rule-target": "column",
    "object-locator": {
    "schema-name": "%",
    "table-name": "%",
    "column-name": "ContactDetails"
     },
    "rule-action": "rename",
    "value": "json_ContactDetails",
    "old-value": null
    }
    ]
}
                    

O AWS DMS replica o campo ContactDetails como JSON aninhado, da seguinte forma.

{
    "_id": "1",
    "FirstName": "John",
    "LastName": "Doe",
    "ContactDetails": {
        "Home": {
            "Address": "Boston",
            "Phone": "1111111111"
        },
        "Work": {
            "Address": "Boston",
            "Phone": "2222222222"
        }
    }
}

Utilizar uma matriz JSON (array_ prefix)

Para coagir um tipo de dados, é possível prefixar o nome de uma coluna com array_ (ou seja, array_columnName) manualmente ou utilizando uma transformação. Neste caso, o AWS DMS considera a coluna como uma matriz JSON e a cria como tal no documento de destino.

Suponha que você deseja migrar o documento a seguir de um endpoint de origem do MongoDB.

{
    "_id" : "1",
    "FirstName": "John",
    "LastName": "Doe",

    "ContactAddresses": ["Boston", "New York"],
            
    "ContactPhoneNumbers": ["1111111111", "2222222222"]
}

Se você não coagir nenhum dos tipos de dados de origem, o documento ContactDetails incorporado será migrado como uma string.

{
    "_id": "1",
    "FirstName": "John",
    "LastName": "Doe",

    "ContactAddresses": "[\"Boston\", \"New York\"]",
            
    "ContactPhoneNumbers": "[\"1111111111\", \"2222222222\"]"

}                

No entanto, é possível adicionar regras de transformação para coagir ContactAddress e ContactPhoneNumbers para matrizes JSON, conforme mostrado na tabela a seguir.

Nome original da coluna de origem	Coluna de origem renomeada
ContactAddress	array_ContactAddress
ContactPhoneNumbers	array_ContactPhoneNumbers

O AWS DMS replica ContactAddress e ContactPhoneNumbers da seguinte maneira.

{
    "_id": "1",
    "FirstName": "John",
    "LastName": "Doe",
    "ContactAddresses": [
        "Boston",
        "New York"
    ],
    "ContactPhoneNumbers": [
        "1111111111",
        "2222222222"
    ]
}             

Conectar-se ao Amazon DocumentDB utilizando TLS

Por padrão, um cluster recém-criado do Amazon DocumentDB aceita conexões seguras somente quando o Transport Layer Security (TLS) é utilizado. Quando o TLS está ativado, cada conexão ao Amazon DocumentDB requer uma chave pública.

É possível recuperar a chave pública do Amazon DocumentDB baixando o arquivo rds-combined-ca-bundle.pem de um bucket do Amazon S3 hospedado pela AWS. Para obter mais informações sobre como baixar esse arquivo, consulte Criptografar conexões utilizando TLS no Guia do desenvolvedor do Amazon DocumentDB

Depois de baixar esse arquivo .pem, é possível importar a chave pública que ele contém no AWS DMS conforme descrito a seguir.

AWS Management Console

Para importar o arquivo (.pem) da chave pública

1. Abra o console do AWS DMS em https://console.aws.amazon.com/dms.

2. No painel de navegação, escolha Certificates.

3. Selecione Import certificate (Importar certificado) e faça o seguinte:

   • Para Certificate identifier (Identificador do certificado), insira um nome exclusivo para o certificado, por exemplo docdb-cert.

   • Em Importar arquivo, navegue até o local onde você salvou o arquivo .pem.

   Quando estiver satisfeito com as configurações, selecione Add new CA certificate (Adicionar novo certificado de CA).

AWS CLI

Utilize o comando aws dms import-certificate, conforme mostrado no exemplo a seguir.

aws dms import-certificate \
    --certificate-identifier docdb-cert \
    --certificate-pem file://./rds-combined-ca-bundle.pem

Ao criar um endpoint de destino do AWS DMS, forneça o identificador do certificado (por exemplo, docdb-cert). Além disso, defina o parâmetro do modo SSL como verify-full.

Conexão aos clusters elásticos do Amazon DocumentDB como destino

Nas versões 3.4.7 e superiores do AWS DMS, é possível criar um endpoint de destino do Amazon DocumentDB como um cluster elástico. Se você criar o endpoint de destino como um cluster elástico, precisará anexar um novo certificado SSL ao endpoint do cluster elástico do Amazon DocumentDB porque o certificado SSL existente não funcionará.

Como anexar um novo certificado SSL ao endpoint do cluster elástico do Amazon DocumentDB

1. Em um navegador, abra https://www.amazontrust.com/repository/SFSRootCAG2.pem e salve o conteúdo em um arquivo .pem com um nome de arquivo exclusivo, por exemplo SFSRootCAG2.pem. Esse é o arquivo de certificado que você precisa importar nas etapas subsequentes.

2. Crie o endpoint do cluster elástico e defina as seguintes opções:

   1. Em Configuração do endpoint, escolha Adicionar novo certificado CA.

   2. Em Identificador de certificado, insira SFSRootCAG2.pem.

   3. Em Importar arquivo de certificado, escolha Escolher arquivo e navegue até o arquivo SFSRootCAG2.pem baixado anteriormente.

   4. Selecione e abra o arquivo SFSRootCAG2.pem baixado.

   5. Escolha Importar certificado.

   6. No menu suspenso Escolher um certificado, escolha SFSRootCAG2.pem.

O novo certificado SSL do arquivo SFSRootCAG2.pem baixado agora está anexado ao endpoint do cluster elástico do Amazon DocumentDB.

Replicação contínua com o Amazon DocumentDB como destino

Se a replicação contínua (captura de dados de alteração, CDC) estiver ativada para o Amazon DocumentDB como destino, as versões 3.5.0 e superior do AWS DMS proporcionarão uma melhoria no desempenho vinte vezes maior do que nas versões anteriores. Em versões anteriores, em que o AWS DMS trata até 250 registros por segundo, AWS DMS agora trata aproximadamente 5000 registros/segundo. O AWS DMS também garante que os documentos no Amazon DocumentDB permaneçam sincronizados com a origem. Quando um registro da origem é criado ou atualizado, o AWS DMS primeiro determina qual registro do Amazon DocumentDB será afetado fazendo o seguinte:

• Se o registro da origem tiver uma coluna chamada _id, o valor dessa coluna determinará o _id correspondente na coleção do Amazon DocumentDB.

• Se não houver uma coluna _id, mas os dados de origem tiverem uma chave primária ou um índice exclusivo, o AWS DMS usará essa chave ou esse valor de índice como o _id da coleção do Amazon DocumentDB.

• Se o registro da origem não tiver uma coluna _id, uma chave primária ou um índice exclusivo, o AWS DMS corresponderá todas as colunas de origem aos campos correspondentes na coleção do Amazon DocumentDB.

Quando um novo registro da origem é criado, o AWS DMS grava um documento correspondente no Amazon DocumentDB. Se um registro da origem existente for atualizado, o AWS DMS atualizará os campos correspondentes no documento de destino no Amazon DocumentDB. Todos os campos que existem no documento de destino, mas não no registro da origem permanecem inalterados.

Quando um registro da origem é excluído, o AWS DMS exclui o documento correspondente do Amazon DocumentDB.

Alterações estruturais (DDL) na origem

Com a replicação contínua, qualquer alteração nas estruturas de dados da origem (como tabelas, colunas e assim por diante) é propagada para seus equivalentes no Amazon DocumentDB. Em bancos de dados relacionais, essas alterações são iniciadas utilizando instruções da linguagem de definição de dados (DDL). É possível ver como o AWS DMS propaga essas alterações para o Amazon DocumentDB na tabela a seguir.

DDL na origem	Efeito no destino do Amazon DocumentDB
CREATE TABLE	Cria uma coleção vazia.
Instrução que renomeia uma tabela (RENAME TABLE, ALTER TABLE...RENAME e semelhante)	Renomeia a coleção.
TRUNCATE TABLE	Remove todos os documentos da coleção, mas somente se HandleSourceTableTruncated for true. Para obter mais informações, consulte Configurações de tarefa para processamento de DDL de processamento de alterações.
DROP TABLE	Exclui a coleção, mas somente se HandleSourceTableDropped for true. Para obter mais informações, consulte Configurações de tarefa para processamento de DDL de processamento de alterações.
Instrução que adiciona uma coluna a uma tabela (ALTER TABLE...ADD e semelhante)	A instrução DDL é ignorada e um aviso é emitido. Quando o primeiro INSERT é realizado na origem, o novo campo é adicionado ao documento de destino.
ALTER TABLE...RENAME COLUMN	A instrução DDL é ignorada e um aviso é emitido. Quando o primeiro INSERT é realizado na origem, o campo recém-nomeado é adicionado ao documento de destino.
ALTER TABLE...DROP COLUMN	A instrução DDL é ignorada e um aviso é emitido.
Instrução que altera o tipo de dados da coluna (ALTER COLUMN...MODIFY e semelhante)	A instrução DDL é ignorada e um aviso é emitido. Quando o primeiro INSERT é realizado na origem com o novo tipo de dados, o documento de destino é criado com um campo desse novo tipo de dados.

Limitações da utilização do Amazon DocumentDB como destino

As seguintes limitações se aplicam ao utilizar o Amazon DocumentDB como destino do AWS DMS:

• No Amazon DocumentDB, os nomes de coleção não podem conter o caractere cifrão ($). Além disso, os nomes do banco de dados não podem conter caracteres Unicode.

• O AWS DMS não é compatível com a mesclagem de várias tabelas de origem em uma única coleção do Amazon DocumentDB.

• Quando o AWS DMS processa as alterações de uma tabela de origem que não tem uma chave primária, qualquer colunas LOB na tabela é ignorada.

• Se a opção Alterar tabela estiver ativada, e o AWS DMS encontrar uma coluna de origem chamada "_id", essa coluna aparecerá como "__id" (dois sublinhados) na tabela de alteração.

• Se você escolher o Oracle como o endpoint de origem, a origem do Oracle deverá ter o registro em log suplementar total ativado. Caso contrário, se houver colunas na origem que não foram alteradas, os dados serão carregados no Amazon DocumentDB como valores nulos.

• A configuração de TargetTablePrepMode:TRUNCATE_BEFORE_LOAD da tarefa de replicação não é compatível para utilização com um endpoint de destino do DocumentDB.

Utilizar configurações de endpoint com o Amazon DocumentDB como destino

É possível utilizar as configurações de endpoint para configurar o destino do Amazon DocumentDB de forma semelhante à utilização de atributos de conexão adicional. Você especifica as configurações ao criar o endpoint de destino utilizando o console do AWS DMS ou o comando create-endpoint na AWS CLI, com a sintaxe --doc-db-settings '{"EndpointSetting": "value", ...}' do JSON.

A tabela a seguir mostra as configurações do endpoint que é possível utilizar com o Amazon DocumentDB como destino.

Nome do atributo	Valores válidos	Valor padrão e descrição
replicateShardCollections	booleano true false	Quando true, essa configuração de endpoint tem os seguintes efeitos e impõe as seguintes limitações: O AWS DMS tem permissão para replicar dados para coleções de fragmentos de destino. Essa configuração só será aplicável se o endpoint do DocumentDB de destino for um cluster elástico. Defina TargetTablePrepMode como DO_NOTHING. O AWS DMS define automaticamente useUpdateLookup como false durante a migração.

Tipos de dados de destino do Amazon DocumentDB

Na tabela a seguir, é possível encontrar os tipos de dados de destino do Amazon DocumentDB compatíveis ao utilizar o AWS DMS e o mapeamento padrão dos tipos de dados do AWS DMS. Para obter mais informações sobre os tipos de dados do AWS DMS, consulte Tipos de dados do AWS Database Migration Service.

Tipo de dados do AWS DMS	Tipo de dados do Amazon DocumentDB
BOOLEAN	Booleano
BYTES	Dados binários
DATE	Data
TIME	String (UTF8)
DATETIME	Data
INT1	Inteiro de 32 bits
INT2	Inteiro de 32 bits
INT4	Inteiro de 32 bits
INT8	Inteiro de 64 bits
NUMERIC	String (UTF8)
REAL4	Double
REAL8	Double
STRING	Se os dados forem reconhecidos como JSON, o AWS DMS os migrará para o Amazon DocumentDB como um documento. Caso contrário, os dados serão mapeados como String (UTF8).
UINT1	Inteiro de 32 bits
UINT2	Inteiro de 32 bits
UINT4	Inteiro de 64 bits
UINT8	String (UTF8)
WSTRING	Se os dados forem reconhecidos como JSON, o AWS DMS os migrará para o Amazon DocumentDB como um documento. Caso contrário, os dados serão mapeados como String (UTF8).
BLOB	Binário
CLOB	Se os dados forem reconhecidos como JSON, o AWS DMS os migrará para o Amazon DocumentDB como um documento. Caso contrário, os dados serão mapeados como String (UTF8).
NCLOB	Se os dados forem reconhecidos como JSON, o AWS DMS os migrará para o Amazon DocumentDB como um documento. Caso contrário, os dados serão mapeados como String (UTF8).