As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Trabalhando com uma instância de AWS DMS replicação Quando você AWS DMS cria uma instância de AWS DMS replicação, cria-a em uma instância do Amazon EC2 em uma nuvem privada virtual (VPC) baseada no serviço Amazon VPC. Essa instância de replicação é usada para executar a migração do seu banco de dados. Ao utilizar a instância de replicação, é possível obter alta disponibilidade e suporte a failover utilizando uma implantação multi-AZ ao selecionar a opção **Multi-AZ**. Em uma implantação Multi-AZ, provisiona e mantém AWS DMS automaticamente uma réplica em espera síncrona da instância de replicação em uma zona de disponibilidade diferente. A instância de replicação primária é replicada em sincronia pelas Zonas de disponibilidade para a réplica em espera. Essa abordagem fornece redundância de dados, elimina I/O congelamentos e minimiza os picos de latência. ![\[AWS Instância de replicação do Database Migration Service\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-conceptual2.png) AWS DMS usa uma instância de replicação para se conectar ao armazenamento de dados de origem, ler os dados de origem e formatar os dados para consumo pelo armazenamento de dados de destino. A instância de replicação também carrega os dados no armazenamento de dados de destino. A maior parte desse processo ocorre na memória. No entanto, transações grandes podem exigir buffer no disco. Transações armazenadas em cache e arquivos de log também são gravados no disco. Você pode criar uma instância AWS DMS de replicação nas seguintes AWS regiões. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_ReplicationInstance.html) AWS DMS suporta uma AWS região especial chamada AWS GovCloud (US) que foi projetada para permitir que agências e clientes do governo dos EUA movam cargas de trabalho confidenciais para a nuvem. AWS GovCloud (US) aborda os requisitos regulatórios e de conformidade específicos do governo dos EUA. Para obter mais informações sobre AWS GovCloud (US), consulte [O que é AWS GovCloud (EUA)?](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/whatis.html) Veja a seguir mais detalhes sobre instâncias de replicação. **Topics** + [Escolhendo a instância de replicação AWS DMS certa para sua migração](CHAP_ReplicationInstance.Types.md) + [Seleção do melhor tamanho para uma instância de replicação](CHAP_BestPractices.SizingReplicationInstance.md) + [Trabalhar com as versões de mecanismos de replicação](CHAP_ReplicationInstance.EngineVersions.md) + [Instâncias de replicação públicas e privadas](CHAP_ReplicationInstance.PublicPrivate.md) + [Endereçamento IP e tipos de rede](CHAP_ReplicationInstance.IPAddressing.md) + [Configurar uma rede para uma instância de replicação](CHAP_ReplicationInstance.VPC.md) + [Configurar uma chave de criptografia para a instância de replicação](CHAP_ReplicationInstance.EncryptionKey.md) + [Criar uma instância de replicação](CHAP_ReplicationInstance.Creating.md) + [Modificar uma instância de replicação](CHAP_ReplicationInstance.Modifying.md) + [Reinicializar uma instância de replicação](CHAP_ReplicationInstance.Rebooting.md) + [Excluir uma instância de replicação](CHAP_ReplicationInstance.Deleting.md) + [Trabalhando com a janela AWS DMS de manutenção](CHAP_ReplicationInstance.MaintenanceWindow.md) # Escolhendo a instância de replicação AWS DMS certa para sua migração AWS DMS cria a instância de replicação em uma instância do Amazon EC2. AWS DMS atualmente oferece suporte às classes de instância T3, C5, C6i, R5 e R6i do Amazon EC2 para instâncias de replicação: + As instâncias T3 são o tipo de instância de uso geral intermitente de próxima geração. Esse tipo fornece um nível de linha de base de desempenho de CPU com a capacidade de intermitência de uso de CPU a qualquer momento e pelo tempo necessário. As instâncias T3 oferecem recursos equilibrados de computação, de memória e de rede e são projetadas para aplicações com uso moderado de CPU que experimentam picos temporários de uso. As instâncias T3 acumulam créditos de CPU quando uma workload está operando abaixo do limite da linha de base. Cada crédito de CPU ganho oferece à instância T3 a oportunidade de apresentar intermitência de desempenho de um núcleo de CPU completo por um minuto, quando necessário. As instâncias T3 podem apresentar intermitência a qualquer momento pelo tempo que for necessário no modo `unlimited`. Para obter mais informações sobre o modo `unlimited`, consulte [Como trabalhar com o modo ilimitado de instâncias de desempenho expansível](#CHAP_ReplicationInstance.Types.UnlimitedMode). + As instâncias C5 são o tipo de instância de próxima geração que oferece alto desempenho econômico a uma taxa de preço baixo por computação para executar workloads avançadas com uso intensivo de computação. Isso inclui workloads como servidores web de alto desempenho, computação de alta performance (HPC), processamento em lote, veiculação de anúncios, jogos multijogador altamente escaláveis e codificação de vídeo. Outras instâncias C5 de workloads são adequadas para incluir modelagem científica, análise distribuída e inferência de aprendizado de máquina e aprendizado profundo. As instâncias C5 estão disponíveis com uma variedade de processadores da Intel e da AMD. + As instâncias C6i oferecem desempenho de preço de computação até 15% melhor do que as instâncias de quinta geração comparáveis para uma ampla variedade de workloads e criptografia de memória sempre ativa. As instâncias C6i são ideais para workloads com uso intensivo de computação, como processamento em lote, análise distribuída, computação de alta performance (HPC), veiculação de anúncios, jogos multijogador altamente escaláveis e codificação de vídeo. + As instâncias R5 são a próxima geração de tipos de instância otimizada para memória do Amazon EC2. As instâncias R5 são ideais para aplicações com uso intensivo de memória, como bancos de dados de alto desempenho, caches na memória distribuídos em escala de web, bancos de dados na memória de médio porte, análise de big data em tempo real e outras aplicações empresariais. As migrações ou replicações contínuas do uso de sistemas de transações de alto rendimento também AWS DMS podem consumir grandes quantidades de CPU e memória. + As instâncias R6i oferecem desempenho de preço computacional até 15% melhor do que as instâncias de quinta geração comparáveis para uma ampla variedade de workloads e criptografia de memória sempre ativa. As instâncias R6i são certificadas pela SAP e são ideais para diversas workloads, como bancos de dados SQL e noSQL, caches em memória distribuídos na escala da web, como Memcached e Redis OSS, bancos de dados em memória, como SAP HANA, e big data analytics em tempo real, como clusters do Hadoop e Spark. + As instâncias C7i oferecem melhor desempenho computacional em relação a instâncias comparáveis da geração anterior. Para AWS DMS cargas de trabalho, as instâncias C7i são excelentes em acelerar processos de transformação de dados, lidar com conversões de esquemas que exigem muita computação e manter uma taxa de transferência consistente durante tarefas de migração de alto volume. Essas instâncias oferecem um equilíbrio ideal de desempenho computacional que exige desempenho constante da CPU. + As instâncias R7i oferecem melhor desempenho computacional em relação a instâncias comparáveis da geração anterior, bem como alta capacidade de memória para workloads com uso intenso de memória. Para AWS DMS cargas de trabalho, as instâncias R7i são particularmente adequadas para tarefas que envolvem grandes bancos de dados que processam grandes volumes de transações simultâneas de banco de dados, permitindo o tratamento eficiente de cenários de replicação com uso intenso de memória e processos complexos de validação de dados que exigem buffers de memória substanciais. Cada instância de replicação tem uma configuração específica de memória e de vCPU. A tabela a seguir mostra a configuração de cada tipo de instância de replicação. Para obter informações sobre preços, consulte a [página Preços do serviço AWS Database Migration Service](https://aws.amazon.com/dms/pricing/). **Tipos de instância de replicação de uso geral** | Tipo | vCPU | Memória (GiB) | | --- | --- | --- | | dms.t3.micro | 2 | 1 | | dms.t3.small | 2 | 2 | | dms.t3.medium | 2 | 4 | | dms.t3.large | 2 | 8 | **Tipos de instância de replicação otimizada para computação** | Tipo | vCPU | Memória (GiB) | | --- | --- | --- | | dms.c5.large | 2 | 4 | | dms.c5.xlarge | 4 | 8 | | dms.c5.2xlarge | 8 | 16 | | dms.c5.4xlarge | 16 | 32 | | dms.c5.9xlarge | 36 | 72 | | dms.c5.12xlarge | 48 | 96 | | dms.c5.18xlarge | 72 | 144 | | dms.c5.24xlarge | 96 | 192 | | dms.c6i.large | 2 | 4 | | dms.c6i.xlarge | 4 | 8 | | dms.c6i.2xlarge | 8 | 16 | | dms.c6i.4xlarge | 16 | 32 | | dms.c6i.8xlarge | 32 | 64 | | dms.c6i.12xlarge | 48 | 96 | | dms.c6i.16xlarge | 64 | 128 | | dms.c6i.24xlarge | 96 | 192 | | dms.c6i.32xlarge | 128 | 256 | | dms.c7i.large | 2 | 4 | | dms.c7i.xlarge | 4 | 8 | | dms.x7i.2xlarge | 8 | 16 | | dms.x7i.4xlarge | 16 | 32 | | dms.x7i.8xlarge | 32 | 64 | | dms.x7i.12xlarge | 48 | 96 | | dms.x7i.16xlarge | 64 | 128 | | dms.x7i.24xlarge | 96 | 192 | | dms.x7i.48xlarge | 192 | 384 | **Tipos de instância de replicação otimizada para memória** | Tipo | vCPU | Memória (GiB) | | --- | --- | --- | | dms.r5.large | 2 | 16 | | dms.r5.xlarge | 4 | 32 | | dms.r5.2xlarge | 8 | 64 | | dms.r5.4xlarge | 16 | 128 | | dms.r5.8xlarge | 32 | 256 | | dms.r5.12xlarge | 48 | 384 | | dms.r5.16xlarge | 64 | 512 | | dms.r5.24xlarge | 96 | 768 | | dms.r6i.large | 2 | 16 | | dms.r6i.xlarge | 4 | 32 | | dms.r6i.2xlarge | 8 | 64 | | dms.r6i.4xlarge | 16 | 128 | | dms.r6i.8xlarge | 32 | 256 | | dms.r6i.12xlarge | 48 | 384 | | dms.r6i.16xlarge | 64 | 512 | | dms.r6i.24xlarge | 96 | 768 | | dms.r6i.32xlarge | 128 | 1024 | | dms.r7i.large | 2 | 16 | | dms.r7i.xlarge | 4 | 32 | | dms.r7i.2xlarge | 8 | 64 | | dms.r7i.4xlarge | 16 | 128 | | dms.r7i.8xlarge | 32 | 256 | | dms.r7i.12xlarge | 48 | 384 | | dms.r7i.16xlarge | 64 | 512 | | dms.r7i.24xlarge | 96 | 768 | | dms.r7i.48xlarge | 192 | 1536 | As tabelas acima listam todos os tipos de instância de AWS DMS replicação, mas os tipos disponíveis na sua região podem variar. Para ver os tipos de instância de replicação disponíveis na sua região, execute o seguinte comando da [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html): ``` aws dms describe-orderable-replication-instances --region your_region_name ``` **Topics** + [Como decidir a classe de instância a ser usada](#CHAP_ReplicationInstance.Types.Deciding) + [Como trabalhar com o modo ilimitado de instâncias de desempenho expansível](#CHAP_ReplicationInstance.Types.UnlimitedMode) ## Como decidir a classe de instância a ser usada Para ajudar a determinar qual classe de instância de replicação pode funcionar melhor para você, vamos examinar o processo de captura de dados de alteração (CDC) que AWS DMS usa. Vamos supor que você esteja executando uma tarefa de carga completa mais CDC (carga em lote mais replicação contínua). Nesse caso, a tarefa tem seu próprio SQLite repositório para armazenar metadados e outras informações. Antes de AWS DMS iniciar uma carga completa, essas etapas ocorrem: + AWS DMS começa a capturar as alterações das tabelas que está migrando do registro de transações do mecanismo de origem (chamamos essas alterações em *cache*). Assim que a carga máxima é concluída, essas alterações armazenadas em cache são coletadas e aplicadas no destino. Dependendo do volume de alterações em cache, essas alterações podem ser aplicadas diretamente da memória, onde são coletadas primeiro, até um limite definido. Como alternativa, elas podem ser aplicadas no disco, onde as alterações são gravadas quando não podem ser mantidas na memória. + Depois que as alterações em cache são aplicadas, por padrão, AWS DMS inicia um processo de aplicação transacional na instância de destino. Durante a fase de alterações aplicadas em cache e a fase de replicações contínuas, AWS DMS usa dois buffers de fluxo, um para dados de entrada e saída. AWS DMS também usa um componente importante chamado *classificador,* que é outro buffer de memória. Veja a seguir duas utilizações importantes do componente classificador (que também possui outras): + Ele monitora todas as transações e garante que encaminha somente as transações relevantes ao buffer de saída. + Ele garante que as transações são encaminhadas na mesma ordem de confirmação como na origem. Como é possível ver, temos três buffers de memória importantes nessa arquitetura para a CDC no AWS DMS. Se qualquer um desses buffers de memória apresentar pressão de memória, a migração pode ter problemas de desempenho que podem causar falhas. Ao conectar workloads pesadas com um alto número de transações por segundo (TPS) nessa arquitetura, a memória adicional fornecida pelas instâncias R5 e R6i pode ser útil. Use instâncias R5 e R6i para manter o grande número de transações na memória e evitar problemas de pressão de memória durante as replicações contínuas. ## Como trabalhar com o modo ilimitado de instâncias de desempenho expansível Uma instância de desempenho expansível configurada como `unlimited`, como uma instância T3, pode sustentar alta utilização de CPU por qualquer período, sempre que necessário. O preço por hora da instância pode cobrir automaticamente todos os picos de uso da CPU. Isso ocorre se a utilização média de CPU da instância for igual ou menor que a linha de base durante um período contínuo de 24 horas ou durante a vida útil da instância, o que for menor. Na grande maioria das workloads de uso geral, as instâncias configuradas como `unlimited` fornecem um desempenho suficiente sem cobranças adicionais. Se a instância funcionar com maior utilização de CPU por um período prolongado, ela poderá fazer isso por uma taxa adicional uniforme por hora de vCPU. Para obter informações sobre preços de instâncias T3, consulte “Créditos de CPU T3” no [AWS Database Migration Service](https://aws.amazon.com/dms/pricing/). Para ter mais informações sobre o modo `unlimited` para instâncias T3, consulte [Modo ilimitado de instâncias expansíveis](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html) no *Guia do usuário do Amazon EC2*. **Importante** Se você utilizar uma instância `dms.t3.micro` da oferta de [nível gratuito da AWS](https://aws.amazon.com/free/) e utilizá-la no modo `unlimited`, poderão ser aplicadas cobranças. Especificamente, as cobranças poderão ser aplicadas se a sua utilização média durante um período contínuo de 24 horas exceder a utilização de linha de base da instância. Para ter mais informações, consulte [Utilização da linha de base](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#baseline_performance) no *Guia do usuário do Amazon EC2*. As instâncias T3 são executadas como `unlimited` por padrão. Se a média de uso de CPU em um período de 24 horas exceder a linha de base, você incorrerá em cobranças por créditos excedentes. Em alguns casos, é possível executar instâncias spot T3 como `unlimited` e planejar utilizá-las imediatamente e por um curto período. Ao fazer isso sem tempo ocioso para acumular créditos de CPU, serão cobrados créditos excedentes. É recomendável iniciar as instâncias spot T3 no modo padrão para evitar custos mais altos. Para ter mais informações, consulte [Os créditos excedentes podem gerar cobranças](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html#unlimited-mode-surplus-credits), [Instâncias spot T3](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-limits.html#t3-spot-instances) e [Modo padrão de instâncias expansíveis](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) no *Guia do usuário do Amazon EC2*. # Seleção do melhor tamanho para uma instância de replicação A escolha da instância de replicação adequada depende de vários fatores do seu caso de uso. Para ajudar a entender como os recursos da instância de replicação são utilizados, consulte a discussão a seguir. Ela abrange o cenário comum de uma tarefa de carga máxima \$1 CDC. Durante uma tarefa de carga completa, AWS DMS carrega as tabelas individualmente. Por padrão, oito tabelas são carregadas por vez. AWS DMS captura as alterações contínuas na origem durante uma tarefa de carga total para que as alterações possam ser aplicadas posteriormente no endpoint de destino. As alterações são armazenados em cache na memória; se a memória disponível for esgotada, as alterações são armazenadas em cache no disco. Quando uma tarefa de carga completa é concluída para uma tabela, as alterações em cache são aplicadas AWS DMS imediatamente à tabela de destino. Depois que todas as alterações em cache pendentes para uma tabela forem aplicadas, o endpoint de destino está em um estado transacionalmente consistente. Nesse ponto, o destino está sincronizado com o endpoint de origem em relação às últimas alterações em cache. AWS DMS em seguida, inicia a replicação contínua entre a origem e o destino. Para fazer isso, AWS DMS pega as operações de alteração dos registros de transações de origem e as aplica ao destino de maneira transacionalmente consistente. (Esse processo pressupõe que a aplicação otimizada em lote não esteja selecionada). AWS DMS transmite as alterações contínuas pela memória na instância de replicação, se possível. Caso contrário, AWS DMS grava as alterações no disco na instância de replicação até que elas possam ser aplicadas no destino. Você tem algum controle sobre como a instância de replicação manipula o processamento de alterações e como a memória é usada nesse processo. Para obter mais informações sobre como ajustar o processamento de alterações, consulte [Configurações de ajuste de processamento de alterações](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md). ## Fatores a serem considerados Memória e espaço em disco são fatores-chave na seleção de uma instância de replicação apropriada para o seu caso de uso. Veja uma discussão a seguir sobre as características do caso de uso a serem analisadas para escolher uma instância de replicação. + Tamanho do banco de dados e das tabelas O volume de dados ajuda a determinar a configuração da tarefa para otimizar o desempenho da carga máxima. Por exemplo, para dois esquemas de 1 TB, é possível particionar tabelas em quatro tarefas de 500 GB e executá-las em paralelo. O paralelismo possível depende do recurso de CPU disponível na instância de replicação. Por isso, é uma boa ideia compreender o tamanho do banco de dados e das tabelas para otimizar o desempenho da carga máxima. Isso ajuda a determinar o número de tarefas possíveis que você pode ter. + Objetos grandes Os tipos de dados presentes no escopo da migração podem afetar o desempenho. Particularmente, objetos grandes (LOBs) afetam o desempenho e o consumo de memória. Para migrar um valor de LOB, AWS DMS executa um processo de duas etapas. Primeiro, AWS DMS insere a linha no destino sem o valor LOB. Em segundo lugar, AWS DMS atualiza a linha com o valor LOB. Isso tem um impacto na memória, portanto, é importante identificar as colunas de LOB na origem e analisar o tamanho dessas colunas. + Frequência da carga e tamanho das transações A frequência da carga e as transações por segundo (TPS) influenciam o uso da memória. Um grande número de atividades de TPS ou da linguagem de manipulação de dados (DML) resultam em uma alta utilização de memória. Isso ocorre porque o DMS armazena em cache as alterações até que elas sejam aplicadas ao destino. Durante a CDC, isso resulta em troca (gravação no disco físico devido ao estouro de memória), o que provoca latência. + Chaves de tabelas e integridade referencial As informações sobre as chaves de tabela determinam o modo da CDC (aplicação em lote ou aplicação transacional) que você utiliza para migrar os dados. Em geral, a aplicação transacional é mais lenta do que a aplicação em lote. Para transações de longa execução, pode haver muitas mudanças na migração. Quando você usa a aplicação transacional, AWS DMS pode ser necessária mais memória para armazenar as alterações em comparação com a aplicação em lote. Se você migrar tabelas sem chaves primárias, a aplicação em lote falhará e a tarefa do DMS será movida para o modo de aplicação transacional. Quando a integridade referencial está ativa entre as tabelas durante o CDC, AWS DMS usa a aplicação transacional por padrão. Para obter mais informações sobre a aplicação em lote em comparação com a aplicação transacional, consulte [Como posso utilizar o recurso de aplicação em lote do DMS para melhorar o desempenho da replicação de CDC?](https://aws.amazon.com/premiumsupport/knowledge-center/dms-batch-apply-cdc-replication/) Use essas métricas para determinar se é necessário que a instância de replicação seja otimizada para computação ou para memória. ## Problemas comuns É possível enfrentar os seguintes problemas comuns que causam contenção de recursos na instância de replicação durante a migração. Para obter informações sobre as métricas instância de replicação, consulte [Métricas de instâncias de replicação](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.CloudWatch). + Se a memória em uma instância de replicação se tornar insuficiente, isso resultará na gravação dos dados no disco. A leitura de disco pode causar latência, o que pode ser evitado com o dimensionamento da instância de replicação com memória suficiente. + O tamanho do disco atribuído à instância de replicação pode ser menor do que o necessário. O tamanho do disco é utilizado quando os dados na memória transbordam. Ele também é utilizado para armazenar os logs de tarefas. O IOPS máximo também depende disso. + A execução de várias tarefas ou tarefas com alto paralelismo afeta o consumo de CPU da instância de replicação. Isso retarda o processamento das tarefas e resulta em latência. ## Práticas recomendadas Considere estas duas práticas recomendadas mais comuns ao dimensionar uma instância de replicação. Para obter mais informações, consulte [Melhores práticas para AWS Database Migration Service](CHAP_BestPractices.md). 1. Dimensione a workload e compreenda se ela tem consumo intensivo de computação ou de memória. Com base nisso, é possível determinar a classe e o tamanho da instância de replicação: + AWS DMS processos LOBs na memória. Essa operação requer uma boa quantidade de memória. + O número de tarefas e o número de threads afetam o consumo da CPU. Evite utilizar mais de oito `MaxFullLoadSubTasks` durante a operação de carga máxima. 1. Aumente o espaço em disco atribuído à instância de replicação quando tiver uma workload alta durante a carga máxima. Isso permite que a instância de replicação utilize o máximo de IOPS atribuído a ela. As orientações anteriores não abrangem todos os cenários possíveis. É importante considerar os detalhes do seu caso de uso específico ao determinar o tamanho da instância de replicação. Os testes anteriores mostram que a CPU e a memória variam com diferentes workloads. Particularmente, LOBs afetam a memória, e a contagem de tarefas ou o paralelismo afetam a CPU. Depois que a migração estiver em execução, monitore a CPU, a memória liberável, o armazenamento livre e as IOPS da instância de replicação. Com base nos dados coletados, é possível dimensionar a instância de replicação para cima ou para baixo, conforme necessário. # Trabalhar com as versões de mecanismos de replicação O *mecanismo de replicação* é o AWS DMS software principal executado em sua instância de replicação e executa as tarefas de migração que você especificar. AWS lança periodicamente novas versões do software do mecanismo de AWS DMS replicação, com novos recursos e melhorias de desempenho. Cada versão do software do mecanismo de replicação tem seu próprio número de versão, para diferenciá-lo de outras versões. Quando você executa uma nova instância de replicação, ela executa a versão mais recente do AWS DMS mecanismo, a menos que você especifique o contrário. Para obter mais informações, consulte [Trabalhando com uma instância de AWS DMS replicação](CHAP_ReplicationInstance.md). Se você tiver uma instância de replicação em execução no momento, poderá atualizá-la para uma versão mais recente do mecanismo. (AWS DMS não suporta downgrades de versão do motor.) Para obter mais informações sobre versões do mecanismo de replicação, consulte [AWS Notas de versão do DMS](CHAP_ReleaseNotes.md). ## Atualizar a versão do mecanismo utilizando o console Você pode atualizar uma instância AWS DMS de replicação usando o. Console de gerenciamento da AWS **Para atualizar uma instância de replicação utilizando o console** 1. Abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). 1. No painel de navegação, selecione **Replication instances**. 1. Escolha seu mecanismo de replicação e, em seguida, escolha **Modify**. 1. Em **Versão do mecanismo**, escolha o número da versão e escolha **Modificar**. **nota** É recomendável interromper todas as tarefas antes de atualizar a instância de replicação. Se você não interromper a tarefa, a AWS DMS interromperá automaticamente antes da atualização. Ao interromper a tarefa manualmente, será necessário iniciá-la manualmente após a conclusão da atualização. A atualização da instância de replicação pode levar alguns minutos. Quando a instância estiver pronta, seu status mudará para **available**. ## Atualizando a versão do motor usando o AWS CLI Você pode atualizar uma instância de AWS DMS replicação usando o AWS CLI, da seguinte forma. **Para atualizar uma instância de replicação usando o AWS CLI** 1. Determine o nome de recurso da Amazon (ARN) da instância de replicação utilizando o comando a seguir. ``` aws dms describe-replication-instances \ --query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceArn,ReplicationInstanceClass]" ``` No resultado, anote o ARN referente à instância de replicação que você deseja atualizar, por exemplo: `arn:aws:dms:us-east-1:123456789012:rep:6EFQQO6U6EDPRCPKLNPL2SCEEY` 1. Determine quais versões da instância de replicação estão disponíveis utilizando o comando a seguir. ``` aws dms describe-orderable-replication-instances \ --query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]" ``` No resultado, anote o número ou os números de versão do mecanismo disponíveis para a classe de instância de replicação. Você encontra essas informações no resultado da Etapa 1. 1. Atualize uma instância de replicação utilizando o seguinte comando. ``` aws dms modify-replication-instance \ --replication-instance-arn arn \ --engine-version n.n.n ``` *arn*Substitua o anterior pelo ARN real da instância de replicação da etapa anterior. *n.n.n *Substitua pelo número da versão do motor que você deseja, por exemplo: `3.4.5` **nota** A atualização da instância de replicação pode levar alguns minutos. É possível visualizar o status da instância de replicação com o seguinte comando. ``` aws dms describe-replication-instances \ --query "ReplicationInstances[*].[ReplicationInstanceIdentifier,ReplicationInstanceStatus]" ``` Quando a instância de replicação estiver pronta, seu status mudará para **available**. # Instâncias de replicação públicas e privadas É possível especificar se uma instância de replicação tem um endereço IP público ou privado que ela utiliza para se conectar aos bancos de dados de origem e de destino. Uma *instância de replicação privada* tem um endereço IP privado que não pode ser acessado fora da rede de replicação. Utilize uma instância privada quando os bancos de dados de origem e de destino estão na mesma rede conectada à nuvem privada virtual (VPC) da instância de replicação. A rede pode ser conectada à VPC usando uma rede privada virtual (VPN) ou emparelhamento de Direct Connect VPC. Uma conexão de *emparelhamento VPC* é uma conexão de rede entre duas. VPCs Ela permite o roteamento utilizando os endereços IP privados de cada VPC como se estivessem na mesma rede. Para obter mais informações sobre emparelhamento de VPC, consulte [Emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html), no *Guia do usuário da Amazon VPC*. Uma *instância de replicação pública* pode utilizar o grupo de segurança da VPC da instância de replicação e o endereço IP público da instância de replicação ou o endereço IP público do gateway NAT. Essas conexões formam uma rede usada para a migração de dados. # Endereçamento IP e tipos de rede AWS DMS sempre cria sua instância de replicação em uma Amazon Virtual Private Cloud (VPC). Ao criar sua VPC, você pode determinar o endereçamento IP a ser usado: um IPv4 ou IPv6 dois. Em seguida, ao criar ou modificar uma instância de replicação, você pode especificar o uso de um protocolo de IPv4 endereço ou de um protocolo de IPv6 endereço usando o modo de *pilha dupla*. **IPv4 endereços** Ao criar uma VPC, você pode especificar um intervalo de IPv4 endereços para a VPC na forma de um bloco de roteamento entre domínios sem classe (CIDR), como 10.0.0.0/16. Um grupo de sub-redes define o intervalo de endereços IP nesse bloco CIDR. Esses endereços IP podem ser públicos ou privados. Um endereço IPv4 privado é um endereço IP que não é acessível pela internet. É possível utilizar endereços IPv4 privados para a comunicação entre a instância de replicação e os outros recursos, como instâncias do Amazon EC2, na mesma VPC. Cada instância de replicação tem um endereço IP privado para comunicação na VPC. Um endereço IP público é um IPv4 endereço que pode ser acessado pela Internet. É possível utilizar endereços públicos para comunicação entre as instâncias de replicação e os recursos na internet. Você controla se a instância de replicação recebe um endereço IP público. **Modo de pilha dupla e endereços IPv6 ** Quando você tiver recursos que precisam se comunicar com sua instância de replicação IPv6, use o modo de *pilha dupla*. Para usar o modo de pilha dupla, certifique-se de que cada sub-rede no grupo de sub-redes que você associa à instância de replicação tenha um IPv6 bloco CIDR associado a ela. É possível criar um grupo de sub-redes de replicação ou modificar um existente para atender a esse requisito. Cada IPv6 endereço é globalmente exclusivo. O bloco IPv6 CIDR para sua VPC é atribuído automaticamente a partir do pool IPv6 de endereços da Amazon. Você não pode escolher o intervalo. O DMS desativa o acesso ao Gateway da Internet para IPv6 endpoints de instâncias privadas de replicação no modo de pilha dupla. O DMS faz isso para garantir que seus IPv6 endpoints sejam privados e só possam ser acessados de dentro da sua VPC. **Você pode usar o AWS DMS console para criar ou modificar uma instância de replicação e especificar o modo de pilha dupla na seção Tipo de rede.** A imagem a seguir mostra a seção **Tipo de rede** no console. ![\[AWS Tipo de rede do Database Migration Service\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-network-type.png) **Referências** + Para obter mais informações IPv4 e IPv6 endereços, consulte [Endereçamento IP](https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html#vpc-ip-addressing) no Guia do *usuário da Amazon VPC*. + Para obter mais informações sobre como criar uma instância de replicação utilizando o modo de pilha dupla, consulte [Criar uma instância de replicação](CHAP_ReplicationInstance.Creating.md). + Para obter mais informações sobre como modificar uma instância de replicação, consulte [Modificar uma instância de replicação](CHAP_ReplicationInstance.Modifying.md). # Configurar uma rede para uma instância de replicação AWS O DMS sempre cria a instância de replicação em uma VPC baseada na Amazon VPC. Especifique a VPC em que a instância de replicação está localizada. Você pode usar sua VPC padrão para sua conta e AWS região, ou você pode criar uma nova VPC. Verifique se a interface de rede elástica alocada para a VPC da instância de replicação está associada a um grupo de segurança. Além disso, verifique se as regras desse grupo de segurança permitem que todo o tráfego em todas as portas saia da VPC. Essa abordagem permite a comunicação da instância de replicação com os endpoints dos bancos de dados de origem e de destino, desde que as regras de entrada corretas estejam ativadas neles. É recomendável que você utilize as configurações padrão para os endpoints, que permitem a saída em todas as portas para todos os endereços. Os endpoints de origem e de destino acessam a instância de replicação que está dentro do VPC, conectando-se ao VPC ou estando no VPC. Os endpoints do banco de dados devem incluir listas de controle de acesso à rede (ACLs) e regras de grupo de segurança (se aplicável) que permitam o acesso de entrada da instância de replicação. A forma como você configura isso depende da configuração da rede utilizada. É possível utilizar o grupo de segurança da VPC da instância de replicação, o endereço IP público ou privado da instância de replicação ou o endereço IP público do gateway NAT. Essas conexões formam uma rede usada para a migração de dados. **nota** Como um endereço IP pode mudar como resultado de alterações na infraestrutura subjacente, é recomendável utilizar um intervalo de CIDR de VPC ou rotear o tráfego de saída da instância de replicação por meio de um IP elástico associado ao GW NAT. Para obter mais informações sobre a criação de uma VPC, incluindo um bloco CIDR, consulte [Trabalho com VPCs e sub-redes](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) no Guia do usuário da *Amazon Virtual* Private Cloud. Para obter informações sobre endereços IP elásticos, consulte [Endereços IP elásticos](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/elastic-ip-addresses-eip.html) no *Guia do usuário do Amazon Elastic Compute Cloud*. ## Configurações de rede para migração de banco de dados Você pode usar várias configurações de rede diferentes com o AWS Database Migration Service. A seguir, veja configurações comuns de uma rede usada para a migração de banco de dados. **Topics** + [Configuração com todos os componentes de migração de banco de dados em uma VPC](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioAllVPC) + [Configuração com vários VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer) + [Configuração com compartilhado VPCs](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCShared) + [Configuração de uma rede para uma VPC usando Direct Connect ou uma VPN](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioDirect) + [Configuração de uma rede para uma VPC utilizando a internet](#CHAP_ReplicationInstance.VPC.Configurations.ScenarioInternet) + [Configuração com uma instância de banco de dados RDS fora de uma VPC para uma instância de banco de dados em uma VPC usando ClassicLink](#CHAP_ReplicationInstance.VPC.Configurations.ClassicLink) + [Configuração para uma rede conectada aos AWS serviços](#CHAP_ReplicationInstance.VPC.Configurations.networkconnecting) + [Configuração para uma rede conectada a AWS serviços usando VPC endpoints](#CHAP_ReplicationInstance.VPC.Configurations.vpcendpoints) + [Configuração para uma rede que se conecta a AWS serviços usando a Internet](#CHAP_ReplicationInstance.VPC.Configuration.networkconnectingusinginternet) Quando possível, é recomendável criar uma instância de replicação do DMS na mesma região do endpoint de destino e na mesma VPC ou sub-rede do endpoint de destino. ### Configuração com todos os componentes de migração de banco de dados em uma VPC A rede mais simples de migração de banco de dados é para que o endpoint de origem, a instância de replicação e o endpoint de destino estejam no mesmo VPC. Essa configuração será adequada se os endpoints de origem e de destino estiverem em uma instância de banco de dados Amazon RDS ou em uma instância do Amazon EC2. A ilustração a seguir mostra uma configuração em que um banco de dados em uma instância do Amazon EC2 se conecta à instância de replicação, e os dados são migrados para uma instância de banco de dados Amazon RDS. ![\[AWS Exemplo de VPC do Database Migration Service: tudo em um\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-scenarioAllVPC.png) O grupo de segurança da VPC utilizado nessa configuração deve permitir a entrada na porta do banco de dados na instância de replicação. É possível fazer isso de duas maneiras. É possível verificar se o grupo de segurança utilizado pela instância de replicação tem acesso aos endpoints. Ou permitir o intervalo CIDR da VPC, o IP elástico do GW NAT ou o endereço IP privado da instância de replicação, se estiver utilizando um. Mas não é recomendável utilizar o endereço IP privado da instância de replicação, pois isso poderá interromper a replicação se o endereço IP da replicação for alterado. ### Configuração com vários VPCs Se o endpoint de origem e os endpoints de destino estiverem diferentes VPCs, você poderá criar sua instância de replicação em um dos. VPCs Em seguida, você pode vincular os dois VPCs usando o peering de VPC. Uma conexão de emparelhamento de VPC é uma conexão de rede entre duas VPCs que permite o roteamento usando os endereços IP privados de cada VPC como se estivessem na mesma rede. Você pode criar uma conexão de emparelhamento de VPC entre a sua própria VPCs, com uma VPC em outra AWS conta ou com uma VPC em uma região diferente. AWS Para obter mais informações sobre emparelhamento de VPC, consulte [Emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html), no *Guia do usuário da Amazon VPC*. A ilustração a seguir mostra um exemplo de configuração utilizando o emparelhamento de VPCs. Aqui, o banco de dados de origem em uma instância do Amazon EC2 em uma VPC se conecta pelo emparelhamento de VPC a uma VPC. Essa VPC contém a instância de replicação e o banco de dados de destino em uma instância de banco de dados Amazon RDS. ![\[AWS Instância de replicação do Database Migration Service\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-scenarioVPCPeer.png) Para implementar o emparelhamento de VPC, siga as instruções em [Como trabalhar com conexões de emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html) encontradas na documentação do *Amazon Virtual Private Cloud, emparelhamento de VPC*. Verifique se a tabela de rotas de uma VPC contém o bloco CIDR da outra. Por exemplo, se a VPC A estiver utilizando o destino 10.0.0.0/16 e a VPC B estiver utilizando o destino 172.31.0.0, a tabela de rotas da VPC A deverá conter 172.31.0.0, e a tabela de rotas da VPC B deverá conter 10.0.0.0/16. Para obter informações mais detalhadas, consulte [Atualizar as tabelas de rotas para a conexão de emparelhamento da VPC](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) na documentação da *Amazon Virtual Private Cloud, emparelhamento de VPC*. Os grupos de segurança da VPC utilizados nessa configuração devem permitir a entrada na porta do banco de dados da instância de replicação ou permitir a entrada no bloco CIDR da VPC que está sendo emparelhada. ### Configuração com compartilhado VPCs AWS DMS trata as sub-redes que são compartilhadas com uma conta de cliente participante em uma organização da mesma forma que as sub-redes normais na mesma conta. Abaixo está uma descrição de como AWS DMS manipuladores VPCs, sub-redes e como você pode usar o compartilhado. VPCs Você pode configurar sua rede para operar em sub-redes personalizadas ou VPCs criando `ReplicationSubnetGroup` objetos. Ao criar um `ReplicationSubnetGroup`, é possível optar por especificar sub-redes de uma VPC específica na sua conta. A lista de sub-redes que você especificar deve incluir pelo menos duas sub-redes que estejam em zonas de disponibilidade separadas, e todas as sub-redes devem estar na mesma VPC. Ao criar um`ReplicationSubnetGroup`, os clientes especificam apenas sub-redes. AWS DMS determinará a VPC em seu nome, pois cada sub-rede está vinculada a exatamente uma VPC. Ao criar um AWS DMS `ReplicationInstance` ou um AWS DMS `ReplicationConfig`, você pode optar por especificar `ReplicationSubnetGroup` and/or um grupo de segurança de VPC no qual a replicação `ReplicationInstance` ou a replicação sem servidor opera. Se não for especificado, AWS DMS escolhe o padrão do cliente `ReplicationSubnetGroup` (que é AWS DMS criado em seu nome se não for especificado para todas as sub-redes na VPC padrão) e o grupo de segurança da VPC padrão. É possível optar por executar as migrações em uma zona de disponibilidade especificada por você ou em qualquer uma das zonas de disponibilidade em seu `ReplicationSubnetGroup`. Ao AWS DMS tentar criar uma instância de replicação ou iniciar uma replicação sem servidor, isso traduz as zonas de disponibilidade de suas sub-redes em zonas de disponibilidade na conta de serviço principal, para garantir que executemos instâncias na zona de disponibilidade correta, mesmo que os mapeamentos da zona de disponibilidade não sejam idênticos entre as duas contas. Se você utilizar uma VPC compartilhada, precisará garantir que cria os objetos do `ReplicationSubnetGroup` mapeados para as sub-redes que deseja utilizar a partir em uma VPC compartilhada. Ao criar um `ReplicationInstance` ou um `ReplicationConfig`, especifique um `ReplicationSubnetGroup` para a VPC compartilhada e especifique um grupo de segurança de VPC que você criou para a VPC compartilhada com a solicitação Create. Observe o seguinte sobre a utilização de uma VPC compartilhada: + O proprietário da VPC não pode compartilhar um recurso com um participante, mas o participante pode criar um recurso de serviço na sub-rede do proprietário. + O proprietário da VPC não pode acessar um recurso (como uma instância de replicação) criado pelo participante, porque todos os recursos são específicos da conta. No entanto, desde que você crie a instância de replicação na VPC compartilhada, ela poderá acessar os recursos na VPC independentemente da conta proprietária, desde que o endpoint ou a tarefa de replicação tenha as permissões corretas. + Como os recursos são específicos da conta, outros participantes não podem acessar recursos pertencentes a outras contas. Não há permissões que você possa conceder a outras contas para permitir que elas acessem os recursos criados na VPC compartilhada com a sua conta. ### Configuração de uma rede para uma VPC usando Direct Connect ou uma VPN As redes remotas podem se conectar a uma VPC usando várias opções, como AWS Direct Connect ou uma conexão VPN de software ou hardware. Essas opções costumam ser usadas para integrar serviços locais existentes, como monitoramento, autenticação, segurança, dados ou outros sistemas, estendendo uma rede interna para a nuvem AWS . Usar esse tipo de extensão de rede facilita a conexão integrada a recursos hospedados na AWS, como uma VPC. A ilustração a seguir mostra uma configuração em que o endpoint de origem é um banco de dados on-premises em um datacenter corporativo. Ele é conectado utilizando o Direct Connect ou uma VPN a uma VPC que contém a instância de replicação e um banco de dados de destino em uma instância de banco de dados Amazon RDS. ![\[AWS Instância de replicação do Database Migration Service\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-scenarioDirect.png) Nessa configuração, o grupo de segurança da VPC deve incluir uma regra de roteamento que envia o tráfego destinado a um intervalo de CIDR de VPC ou a um endereço IP específico para um host. Esse host deve ser capaz de superar o tráfego da VPC na VPN local. Nesse caso, o host NAT inclui suas próprias configurações de grupo de segurança. Essas configurações devem permitir o tráfego do intervalo CIDR de VPC ou do endereço IP privado ou do grupo de segurança da instância de replicação para a instância do NAT. Mas não é recomendável utilizar o endereço IP privado da instância de replicação, pois isso poderá interromper a replicação se o endereço IP da replicação for alterado. ### Configuração de uma rede para uma VPC utilizando a internet Se você não usa uma VPN ou se conecta Direct Connect a AWS recursos, pode usar a Internet para migrar seu banco de dados. Nesse caso, é possível migrar para uma instância do Amazon EC2 ou para uma instância de banco de dados Amazon RDS. Essa configuração envolve uma instância de replicação pública em um VPC com um gateway da Internet que contém o endpoint de destino e a instância de replicação. ![\[AWS Instância de replicação do Database Migration Service\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-scenarioInternet.png) Para adicionar um gateway da Internet à sua VPC, consulte [Anexar um gateway da Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway), no *Guia do usuário da Amazon VPC*. A tabela de rotas da VPC deve incluir regras de roteamento que enviem tráfego não destinado à VPC por padrão ao gateway da Internet. Nessa configuração, a conexão ao endpoint parecerá vir do endereço IP público da instância de replicação, não do endereço IP privado. Para obter mais informações, consulte [Tabelas de rotas da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html) no *Guia do usuário da Amazon VPC*. ### Configuração com uma instância de banco de dados RDS fora de uma VPC para uma instância de banco de dados em uma VPC usando ClassicLink | | | --- | | Estamos aposentando o EC2-Classic em 15 de agosto de 2022. É recomendável migrar do EC2-Classic para uma VPC. Para ter mais informações, consulte [Migrate from EC2-Classic to a VPC](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-migrate.html) (Migrar do EC2-Classic para uma VPC) no Guia do usuário do Amazon EC2 e o blog [EC2-Classic Networking is Retiring – Here’s How to Prepare](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/) (O EC2-Classic Networking será descontinuado. Veja como se preparar). | Para conectar uma instância de banco de dados Amazon RDS que não esteja em uma VPC a um servidor de replicação do DMS e uma instância de banco de dados em uma VPC, você pode usar com um servidor proxy. ClassicLink ClassicLink permite vincular uma instância de banco de dados EC2-Classic a uma VPC em sua conta, dentro da mesma região. AWS Após criar o link, a instância do banco de dados de origem pode se comunicar com a instância de replicação dentro da VPC utilizando os endereços IP privados. Como a instância de replicação na VPC não pode acessar diretamente a instância de banco de dados de origem na plataforma EC2-Classic ClassicLink usando, você usa um servidor proxy. O servidor de proxy conecta instância de banco de dados de origem à VPC que contém a instância de replicação e a instância de banco de dados de destino. O servidor proxy usa ClassicLink para se conectar à VPC. O encaminhamento de portas no servidor de proxy permite a comunicação entre a instância de banco de dados de origem e a instância de banco de dados de destino na VPC. ![\[AWS Database Migration Service usando ClassicLink\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/datarep-scenarioClassicLink.png) #### Usando ClassicLink com o AWS Database Migration Service Você pode conectar uma instância de banco de dados Amazon RDS que não esteja em uma VPC a um servidor de replicação do DMS e AWS uma instância de banco de dados que estejam em uma VPC. Para fazer isso, você pode usar o Amazon EC2 ClassicLink com um servidor proxy. O procedimento a seguir mostra como usar ClassicLink para essa finalidade. Esse procedimento conecta uma instância de banco de dados de origem do Amazon RDS que não está em uma VPC a uma VPC contendo uma instância de replicação do DMS e AWS uma instância de banco de dados de destino. + Crie uma instância de replicação do AWS DMS em uma VPC. (Todas as instâncias de replicação são criadas em VPCs.) + Associe um grupo de segurança de VPC à instância de replicação e à instância de banco de dados de destino. Quando duas instâncias compartilham um grupo de segurança de VPC, elas podem se comunicar normalmente. + Configure um servidor de proxy em uma instância EC2 clássica. + Crie uma conexão usando ClassicLink entre o servidor proxy e a VPC. + Crie endpoints AWS do DMS para os bancos de dados de origem e destino. + Crie uma tarefa AWS DMS. **Para usar para ClassicLink migrar um banco de dados em uma instância de banco de dados que não esteja em uma VPC para um banco de dados em uma instância de banco de dados em uma VPC** 1. Crie uma instância de replicação do AWS DMS e atribua um grupo de segurança VPC: 1. Faça login no Console de gerenciamento da AWS e abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). Se você estiver conectado como usuário AWS Identity and Access Management (IAM), verifique se você tem as permissões apropriadas para acessar AWS DMS. Para obter mais informações sobre as permissões necessárias para a migração de banco de dados, consulte [Permissões do IAM necessárias para usar AWS DMS](security-iam.md#CHAP_Security.IAMPermissions). 1. Na página **Painel**, selecione **Instância de Replicação**. Siga as instruções da seção [Etapa 1: criar uma instância de replicação usando o console AWS DMS](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.ReplicationInstance) para criar uma instância de replicação. 1. Depois de criar a instância de replicação do AWS DMS, abra o console de serviço do EC2. Escolha **Interfaces de rede** no painel de navegação. 1. Escolha a *DMSNetworkInterface* e, em seguida, escolha **Alterar grupos de segurança** no menu **Ações**. 1. Escolha o grupo de segurança que deseja utilizar para a instância de replicação e a instância de banco de dados de destino. 1. Associe o grupo de segurança da última etapa à instância do banco de dados de destino. 1. Abra o console de serviço do Amazon RDS. No painel de navegação, escolha **Instâncias**. 1. Escolha a instância do banco de dados de destino. Para **Ações de instância**, escolha **Modificar**. 1. Para o parâmetro **Grupo de segurança**, selecione o grupo de segurança utilizado na etapa anterior. 1. Escolha **Continuar** e escolha **Modificar instância de banco de dados**. 1. Etapa 3: Configurar um servidor de proxy em uma instância do EC2 Classic utilizando NGINX. Use um AMI de sua escolha para ativar uma instância EC2 clássica. O exemplo abaixo baseia-se no AMI Ubuntu Server 14.04 LTS (HVM). Para configurar um servidor de proxy em uma instância EC2 clássica 1. Conecte-se à instância EC2 Classic e instale o NGINX utilizando os seguintes comandos: ``` Prompt> sudo apt-get update Prompt> sudo wget http://nginx.org/download/nginx-1.9.12.tar.gz Prompt> sudo tar -xvzf nginx-1.9.12.tar.gz Prompt> cd nginx-1.9.12 Prompt> sudo apt-get install build-essential Prompt> sudo apt-get install libpcre3 libpcre3-dev Prompt> sudo apt-get install zlib1g-dev Prompt> sudo ./configure --with-stream Prompt> sudo make Prompt> sudo make install ``` 1. Edite o arquivo daemon do NGINX, `/etc/init/nginx.conf`, utilizando o código a seguir: ``` # /etc/init/nginx.conf – Upstart file description "nginx http daemon" author "email" start on (filesystem and net-device-up IFACE=lo) stop on runlevel [!2345] env DAEMON=/usr/local/nginx/sbin/nginx env PID=/usr/local/nginx/logs/nginx.pid expect fork respawn respawn limit 10 5 pre-start script $DAEMON -t if [ $? -ne 0 ] then exit $? fi end script exec $DAEMON ``` 1. Crie um arquivo de configuração do NGINX em `/usr/local/nginx/conf/nginx.conf`. No arquivo de configuração, insira o seguinte: ``` # /usr/local/nginx/conf/nginx.conf - NGINX configuration file worker_processes 1; events { worker_connections 1024; } stream { server { listen DB instance port number; proxy_pass DB instance identifier:DB instance port number; } } ``` 1. Na linha de comando, inicie o NGINX utilizando os seguintes comandos: ``` Prompt> sudo initctl reload-configuration Prompt> sudo initctl list | grep nginx Prompt> sudo initctl start nginx ``` 1. Crie uma ClassicLink conexão entre o servidor proxy e a VPC de destino que contenha a instância de banco de dados de destino e a instância de replicação: 1. Abra o console do EC2 e selecione a instância do EC2 Classic que está executando o servidor de proxy. 1. Em **Ações**, escolha e **ClassicLink**, em seguida, escolha **Vincular à VPC**. 1. Selecione o grupo de segurança utilizado anteriormente neste procedimento. 1. Escolha **Vincular à VPC**. 1. Etapa 5: Crie endpoints do AWS DMS usando o procedimento em. [Etapa 2: Especificar endpoints de origem e de destino](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Endpoints) Utilize o nome do host de proxy DNS interno do EC2 como o nome do servidor ao especificar o endpoint de origem. 1. Crie uma tarefa AWS DMS usando o procedimento em[Etapa 3: Criar uma tarefa e migrar os dados](CHAP_GettingStarted.Replication.md#CHAP_GettingStarted.Replication.Tasks). ### Configuração para uma rede conectada aos AWS serviços Para se conectar aos AWS serviços, use uma conexão com a Internet ou endpoints de Nuvem Privada Virtual (VPC). Isso se aplica quando: Seus endpoints de origem ou destino usam AWS serviços como: + AWS Secrets Manager + Amazon Simple Storage Service Seu endpoint de destino é um AWS serviço como: + Amazon S3 + Amazon Kinesis + Amazon DynamoDB + banco de dados de origem + OpenSearch Serviço Amazon + Amazon Athena ### Configuração para uma rede conectada a AWS serviços usando VPC endpoints Os VPC endpoints fornecem conexões seguras entre seus AWS recursos, conectando recursos de VPC a AWS serviços sem exigir acesso à Internet. Seus aplicativos em sub-redes privadas podem acessar AWS serviços enquanto permanecem na AWS rede, melhorando a segurança e reduzindo a latência. Consulte a imagem abaixo: ![\[\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/images/aws_dms_vpc_endpoints.jpg) Para obter mais informações, consulte [Como configurar VPC endpoints AWS DMS como endpoints de origem e destino e](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_VPC_Endpoints.html) [Configurar AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Advanced.Endpoints.secretsmanager.html) o gerenciador de segredos VPC Endpoint. ### Configuração para uma rede que se conecta a AWS serviços usando a Internet Uma instância de replicação precisa de acesso à Internet para se conectar aos AWS recursos durante a migração de dados. Para saber mais sobre sub-redes públicas e privadas em uma VPC, consulte [Exemplo: VPC com servidores em sub-redes privadas e NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-example-private-subnets-nat.html) no Guia do usuário da Amazon Virtual Private Cloud. Você deve testar sua configuração de rede quanto à conectividade com qualquer serviço necessário. ## Criar um grupo de sub-rede de replicação Como parte da rede a ser utilizada para a migração de banco de dados, é necessário especificar as sub-redes na nuvem privada virtual (VPC) que você pretende utilizar. Essa VPC deve se basear no serviço Amazon VPC. Uma *sub-rede* é um intervalo de endereços IP no seu VPC em uma determinada zona de disponibilidade. Essas sub-redes podem ser distribuídas entre as zonas de disponibilidade da AWS região em que sua VPC está localizada. Ao criar uma instância de replicação ou um perfil de instância no console do AWS DMS, você pode usar a sub-rede que você escolher. É possível criar um grupo de sub-redes de replicação para definir as sub-redes que serão utilizadas. Selecione sub-redes em, pelo menos, duas zonas de disponibilidade. **Como criar um grupo de sub-rede de replicação** 1. Faça login no Console de gerenciamento da AWS e abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). Se estiver conectado como um usuário do IAM, verifique se você possui as permissões necessárias para acessar o AWS DMS. Para obter mais informações sobre as permissões necessárias para a migração de banco de dados, consulte [Permissões do IAM necessárias para usar AWS DMS](security-iam.md#CHAP_Security.IAMPermissions). 1. No painel de navegação, escolha **Grupos de sub-redes**. 1. Selecione **Create subnet group (Criar grupo de sub-redes)**. 1. Na página **Editar grupo de sub-redes de replicação**, especifique as informações do grupo de sub-rede de replicação. A tabela a seguir descreve as configurações. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_ReplicationInstance.VPC.html) 1. Selecione **Create subnet group (Criar grupo de sub-redes)**. ## Resolver endpoints de domínio utilizando o DNS Normalmente, uma instância de AWS DMS replicação usa o resolvedor do Sistema de Nomes de Domínio (DNS) em uma instância do Amazon EC2 para resolver endpoints de domínio. Se a resolução de DNS for necessária, você poderá utilizar o Amazon Route 53 Resolver. Para obter mais informações sobre como utilizar o Route 53 DNS Resolver, consulte [Introdução ao Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-getting-started.html). Para obter informações sobre como utilizar seu próprio servidor de nomes on-premises para resolver determinados endpoints utilizando o Amazon Route 53 Resolver, consulte [Utilização do seu próprio servidor de nomes on-premises](CHAP_BestPractices.md#CHAP_BestPractices.Rte53DNSResolver). # Configurar uma chave de criptografia para a instância de replicação AWS O DMS criptografa o armazenamento usado por uma instância de replicação e as informações de conexão do endpoint. Para criptografar o armazenamento usado por uma instância de replicação, o AWS DMS usa um AWS KMS key que é exclusivo para sua conta. AWS Você pode visualizar e gerenciar essa chave KMS com AWS Key Management Service (AWS KMS). É possível utilizar a chave padrão do KMS na sua conta (`aws/dms`) ou criar uma chave personalizada do KMS. Se você tiver uma chave de AWS KMS criptografia existente, também poderá usar essa chave para criptografia. Você pode especificar sua própria chave de criptografia fornecendo um identificador de chave KMS para criptografar seus AWS recursos do DMS. Quando você especifica a sua própria chave de criptografia, a conta de usuário usada para realizar a migração do banco de dados deve ter acesso a ela. Para obter mais informações sobre como criar suas próprias chaves de criptografia e conceder acesso a uma chave de criptografia para os usuários, consulte o *[Guia do desenvolvedor do AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)*. Se você não especificar um identificador de chave KMS, o AWS DMS usará sua chave de criptografia padrão. O KMS cria a chave de criptografia padrão para o AWS DMS da sua AWS conta. Sua AWS conta tem uma chave de criptografia padrão diferente para cada AWS região. Para gerenciar as chaves usadas para criptografar seus recursos AWS DMS, você usa. AWS KMS Você pode AWS KMS encontrá-lo pesquisando Console de gerenciamento da AWS por **KMS** no painel de navegação. AWS KMS combina hardware e software seguros e de alta disponibilidade para fornecer um sistema de gerenciamento de chaves dimensionado para a nuvem. Usando AWS KMS, você pode criar chaves de criptografia e definir as políticas que controlam como essas chaves podem ser usadas. AWS KMS suporta AWS CloudTrail, para que você possa auditar o uso das chaves para verificar se as chaves estão sendo usadas adequadamente. Suas AWS KMS chaves podem ser usadas em combinação com o AWS DMS e outros AWS serviços compatíveis. Os serviços da AWS compatíveis incluem o Amazon RDS, o Amazon S3, o Amazon Elastic Block Store (Amazon EBS) e o Amazon Redshift. Depois de criar seus recursos do AWS DMS com uma chave de criptografia específica, você não pode alterar a chave de criptografia desses recursos. Certifique-se de determinar seus requisitos de chave de criptografia antes de criar seus recursos de AWS DMS. # Criar uma instância de replicação A primeira tarefa na migração de um banco de dados é criar uma instância de replicação. Essa instância de replicação exige armazenamento e capacidade de processamento suficientes para executar as tarefas que você atribui para migrar os dados do banco de dados de origem para o banco de dados de destino. O tamanho necessário dessa instância varia de acordo com a quantidade de dados necessários para migrar e as tarefas que ela deve realizar. Para obter mais informações sobre as instâncias de replicação, consulte [Trabalhando com uma instância de AWS DMS replicação](CHAP_ReplicationInstance.md). **Para criar uma instância de replicação usando o console AWS** 1. Escolha **Instâncias de replicação** no painel de navegação do AWS DMS console e, em seguida, escolha **Criar instância de replicação**. 1. Na página **Criar instância de replicação**, especifique as informações da instância de replicação. A tabela a seguir descreve as configurações que podem ser feitas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html) 1. Selecione a guia **Advanced** para definir valores para configurações de rede e criptografia, se necessários. A tabela a seguir descreve as configurações. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html) 1. Especifique as configurações de **Manutenção**. A tabela a seguir descreve as configurações. Para obter mais informações sobre as configurações de manutenção, consulte [Trabalhando com a janela AWS DMS de manutenção](CHAP_ReplicationInstance.MaintenanceWindow.md). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_ReplicationInstance.Creating.html) 1. Selecione **Create replication instance**. # Modificar uma instância de replicação É possível modificar as configurações de uma instância de replicação para, por exemplo, alterar a classe de instância ou para aumentar o armazenamento. Ao modificar uma instância de replicação, é possível aplicar as alterações imediatamente. Para aplicar as alterações imediatamente, escolha a opção **Aplicar imediatamente** no Console de gerenciamento da AWS. Ou use o `--apply-immediately` parâmetro ao chamar o AWS CLI ou defina o `ApplyImmediately` parâmetro como `true` ao usar a API do DMS. Se você não optar por aplicar as alterações imediatamente, elas serão colocadas na fila de modificações pendentes. Durante a próxima janela de manutenção, todas as alterações pendentes na fila serão aplicadas. **nota** Se você optar por aplicar as alterações imediatamente, todas as alterações na fila de modificações pendentes também serão aplicadas. Se qualquer uma das alterações pendentes exigir tempo de inatividade, escolher **Apply changes immediately** poderá causar um tempo de inatividade inesperado. **Para modificar uma instância de replicação usando o console AWS** 1. Faça login no Console de gerenciamento da AWS e abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). 1. No painel de navegação, selecione **Replication instances**. 1. Escolha a instância de replicação que você deseja modificar. A tabela a seguir descreve as modificações que podem ser feitas. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/dms/latest/userguide/CHAP_ReplicationInstance.Modifying.html) ## Práticas recomendadas ao modificar uma instância de replicação Ao modificar uma instância de replicação, seguir estas práticas recomendadas ajuda a garantir uma atualização bem-sucedida com impacto mínimo nos fluxos de trabalho de migração. Siga as etapas principais abaixo antes, durante e depois das modificações para manter a integridade dos dados e a eficiência operacional em todo o processo. **Cronograma de modificação do plano:** + É possível aplicar as alterações imediatamente ou programá-las para a próxima janela de manutenção. + Agende durante períodos de pouco tráfego para minimizar o impacto. **Etapas anteriores à modificação:** + Interrompa todas as tarefas de replicação ativa. + Verifique se todas as tarefas foram interrompidas com êxito. + Documente as configurações atuais da tarefa. **Durante a modificação:** + Monitore o andamento das modificações. + Aguarde o status “Disponível” antes de continuar. **Etapas posteriores à modificação:** + Reinicie todas as tarefas interrompidas anteriormente. + Confirme se as tarefas estão sendo executadas corretamente. # Reinicializar uma instância de replicação Você pode reinicializar uma instância de AWS DMS replicação para reiniciar o mecanismo de replicação. Uma reinicialização resulta em uma interrupção momentânea da instância de replicação, durante a qual o status da instância é definido como **Rebooting** (Reinicializando). Se a AWS DMS instância estiver configurada para Multi-AZ, a reinicialização poderá ser realizada com um failover. Um AWS DMS evento é criado quando a reinicialização é concluída. Se sua AWS DMS instância for uma implantação Multi-AZ, você poderá forçar um failover planejado de uma zona de AWS disponibilidade para outra ao reinicializar. Quando você força um failover planejado da sua AWS DMS instância, AWS DMS fecha as conexões ativas na instância atual antes de mudar automaticamente para uma instância em espera em outra zona de disponibilidade. A reinicialização com um failover planejado ajuda a simular um evento de failover planejado de uma AWS DMS instância, como ao escalar a classe da instância de replicação. **nota** Após uma reinicialização forçar um failover de uma zona de disponibilidade para outra, a alteração da zona de disponibilidade pode não ser refletida por vários minutos. Esse atraso aparece na Console de gerenciamento da AWS, e nas chamadas para a AWS DMS API AWS CLI e. Se as tarefas de migração estiverem sendo executadas na instância de replicação quando ocorrer uma reinicialização, não ocorrerá nenhuma perda de dados, e o status da tarefa será alterado para um estado de erro. Se as tabelas na tarefa de migração estiverem no meio de um carregamento em massa (fase de carga máxima) e ainda não tiverem sido iniciadas, elas entrarão em um estado de erro. Mas as tabelas concluídas naquele momento permanecem em um estado concluído. Quando ocorre uma reinicialização durante a fase de carga máxima, é recomendável executar uma das etapas abaixo. + Remova as tabelas que estão em um estado concluído e reinicie a tarefa com as tabelas restantes. + Crie uma nova tarefa com as tabelas em estado de erro e com as tabelas pendentes. Se as tabelas na tarefa de migração estiverem na fase de replicação contínua, a tarefa será retomada depois que a reinicialização for concluída. Você não pode reinicializar sua instância AWS DMS de replicação se seu status não estiver no estado **Disponível**. Sua AWS DMS instância pode estar indisponível por vários motivos, como uma modificação solicitada anteriormente ou uma ação na janela de manutenção. O tempo necessário para reinicializar uma instância de AWS DMS replicação geralmente é pequeno (menos de 5 minutos). ## Reinicializando uma instância de replicação usando o console AWS Para reinicializar uma instância de replicação, use o AWS console. **Para reinicializar uma instância de replicação usando o console AWS** 1. Faça login no Console de gerenciamento da AWS e abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). 1. No painel de navegação, selecione **Replication instances**. 1. Escolha a instância de replicação que você deseja reinicializar. 1. Escolha **Reboot**. A caixa de diálogo **Reinicializar instância de replicação** é aberta. 1. Selecione a caixa de diálogo **Reinicializar com failover planejado?** se você tiver configurado a instância de replicação para implantação multi-AZ e desejar fazer failover para outra zona de disponibilidade da AWS . 1. Escolha **Reboot**. ## Reinicializar uma instância de replicação utilizando a CLI Para reinicializar uma instância de replicação, use o AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reboot-replication-instance.html)comando com o seguinte parâmetro: + `--replication-instance-arn` **Example Exemplo de reinicialização simples** O AWS CLI exemplo a seguir reinicia uma instância de replicação. ``` aws dms reboot-replication-instance \ --replication-instance-arn arn of my rep instance ``` **Example Exemplo de reinicialização simples com failover** O AWS CLI exemplo a seguir reinicia uma instância de replicação com failover. ``` aws dms reboot-replication-instance \ --replication-instance-arn arn of my rep instance \ --force-planned-failover ``` ## Reinicializar uma instância de replicação utilizando a API Para reinicializar uma instância de replicação, use a [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)ação da AWS DMS API com os seguintes parâmetros: + `ReplicationInstanceArn = arn of my rep instance` **Example Exemplo de reinicialização simples** O exemplo a seguir reinicializa uma instância de replicação. ``` 1. https://dms.us-west-2.amazonaws.com/ 2. ?Action=RebootReplicationInstance 3. &DBInstanceArn=arn of my rep instance 4. &SignatureMethod=HmacSHA256 5. &SignatureVersion=4 6. &Version=2014-09-01 7. &X-Amz-Algorithm=AWS4-HMAC-SHA256 8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request 9. &X-Amz-Date=20140425T192732Z 10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date 11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3 ``` **Example Exemplo de reinicialização simples com failover** O exemplo de código a seguir reinicia uma instância de replicação e executa o failover em outra zona de AWS disponibilidade. ``` 1. https://dms.us-west-2.amazonaws.com/ 2. ?Action=RebootReplicationInstance 3. &DBInstanceArn=arn of my rep instance 4. &ForcePlannedFailover=true 5. &SignatureMethod=HmacSHA256 6. &SignatureVersion=4 7. &Version=2014-09-01 8. &X-Amz-Algorithm=AWS4-HMAC-SHA256 9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request 10. &X-Amz-Date=20140425T192732Z 11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date 12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3 ``` # Excluir uma instância de replicação Você pode excluir uma instância AWS DMS de replicação quando terminar de usá-la. Se tiver tarefas de migração que usam a instância de replicação, é necessário encerrar e excluir as tarefas antes de excluir a instância de replicação. Se você fechar sua AWS conta, todos os AWS DMS recursos e configurações associados à sua conta serão excluídos após dois dias. Esses recursos incluem todas as instâncias de replicação, configuração de endpoint de origem e de destino, tarefas de replicação e certificados SSL. Se depois de dois dias você decidir usar AWS DMS novamente, você recria os recursos necessários. Se a instância de replicação atender a todos os critérios de exclusão e permanecer no status `DELETING` por um longo período, entre em contato com o suporte para solucionar o problema. ## Excluindo uma instância de replicação usando o console AWS Para excluir uma instância de replicação, use o AWS console. **Para excluir uma instância de replicação usando o console AWS** 1. Faça login no Console de gerenciamento da AWS e abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). 1. No painel de navegação, selecione **Replication instances**. 1. Selecione a instância de replicação que deseja excluir. 1. Escolha **Exluir**. 1. Na caixa de diálogo, escolha **Excluir**. ## Excluir uma instância de replicação utilizando a CLI Para excluir uma instância de replicação, use o AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html](https://docs.aws.amazon.com/cli/latest/reference/dms/delete-replication-instance.html)comando com o seguinte parâmetro: + `--replication-instance-arn` **Example Exemplo de exclusão** O AWS CLI exemplo a seguir exclui uma instância de replicação. ``` aws dms delete-replication-instance \ --replication-instance-arn arn of my rep instance ``` ## Excluir uma instância de replicação utilizando a API Para excluir uma instância de replicação, use a [https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html](https://docs.aws.amazon.com/dms/latest/APIReference/API_DeleteReplicationInstance.html)ação AWS DMS da API com os seguintes parâmetros: + `ReplicationInstanceArn = arn of my rep instance` **Example Exemplo de exclusão** O exemplo de código a seguir exclui uma instância de replicação. ``` 1. https://dms.us-west-2.amazonaws.com/ 2. ?Action=DeleteReplicationInstance 3. &DBInstanceArn=arn of my rep instance 4. &SignatureMethod=HmacSHA256 5. &SignatureVersion=4 6. &Version=2014-09-01 7. &X-Amz-Algorithm=AWS4-HMAC-SHA256 8. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request 9. &X-Amz-Date=20140425T192732Z 10. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date 11. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3 ``` # Trabalhando com a janela AWS DMS de manutenção Cada instância AWS DMS de replicação tem uma janela de manutenção semanal durante a qual todas as alterações disponíveis no sistema são aplicadas. A janela de manutenção pode ser considerada uma oportunidade de controlar quando as modificações e aplicação de patches de software ocorrem. Se AWS DMS determinar que a manutenção é necessária durante uma determinada semana, a manutenção ocorre durante a janela de manutenção de 30 minutos que você escolheu ao criar a instância de replicação. AWS DMS conclui a maior parte da manutenção durante a janela de manutenção de 30 minutos. No entanto, pode ser necessário mais tempo para maiores alterações. ## Efeito da manutenção sobre tarefas de migração existentes Quando uma tarefa de AWS DMS migração está sendo executada em uma instância, os seguintes eventos ocorrem quando um patch é aplicado: + Se as tabelas na tarefa de migração estiverem na fase de replicação de alterações contínua (CDC), o AWS DMS pausará a tarefa por um momento e a retomará após a aplicação do patch. A migração continua do ponto em que foi interrompida quando o patch tiver sido aplicado. + Se AWS DMS estiver migrando uma tabela como parte de uma tarefa de **migrar dados existentes** ou **migrar dados existentes e replicar alterações em andamento**, o DMS interrompe e reinicia a migração para todas as tabelas que estão em fase de carga total enquanto o patch é aplicado. O DMS também interrompe e retoma todas as tabelas que estão na fase de CDC enquanto o patch é aplicado. ## Alterar a definição da janela de manutenção Você pode alterar o período da janela de manutenção usando a Console de gerenciamento da AWS AWS CLI, a ou a AWS DMS API. ### Alterar a definição da janela de manutenção utilizando o console Altere o período da janela de manutenção utilizando o Console de gerenciamento da AWS. **Como alterar a janela de manutenção preferencial utilizando o console** 1. Faça login no Console de gerenciamento da AWS e abra o AWS DMS console em [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/). 1. No painel de navegação, selecione **Replication instances**. 1. Escolha a instância de replicação a ser modificada e escolha **Modify**. 1. Expanda a guia **Manutenção** e escolha uma data e hora para a janela de manutenção. 1. Escolha **Apply changes immediately**. 1. Escolha **Modificar**. ### Alterar a configuração da janela de manutenção utilizando a CLI Para ajustar a janela de manutenção preferida, use o AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)comando com os parâmetros a seguir. + `--replication-instance-identifier` + `--preferred-maintenance-window` **Example** O AWS CLI exemplo a seguir define a janela de manutenção para terças-feiras, das 4h às 4h30. UTC. ``` aws dms modify-replication-instance \ --replication-instance-identifier myrepinstance \ --preferred-maintenance-window Tue:04:00-Tue:04:30 ``` ### Alterar a configuração da janela de manutenção utilizando a API Para ajustar a janela de manutenção preferida, use a [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)ação AWS DMS da API com os parâmetros a seguir. + `ReplicationInstanceIdentifier = myrepinstance` + `PreferredMaintenanceWindow = Tue:04:00-Tue:04:30` **Example** O exemplo de código a seguir define a janela de manutenção para as terças-feiras, das 4h às 4h30. UTC. ``` 1. https://dms.us-west-2.amazonaws.com/ 2. ?Action=ModifyReplicationInstance 3. &DBInstanceIdentifier=myrepinstance 4. &PreferredMaintenanceWindow=Tue:04:00-Tue:04:30 5. &SignatureMethod=HmacSHA256 6. &SignatureVersion=4 7. &Version=2014-09-01 8. &X-Amz-Algorithm=AWS4-HMAC-SHA256 9. &X-Amz-Credential=AKIADQKE4SARGYLE/20140425/us-east-1/dms/aws4_request 10. &X-Amz-Date=20140425T192732Z 11. &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date 12. &X-Amz-Signature=1dc9dd716f4855e9bdf188c70f1cf9f6251b070b68b81103b59ec70c3e7854b3 ```