Migrações do MySQL para o MySQL Usar o MySQL como origem Usar o MySQL autogerenciado como uma origem Utilizar o MySQL gerenciado pela AWS como origem Limitações ao MySQL como uma origem Compatibilidade com transações XA Configurações de endpoint Tipos de dados de origem do MySQL

Utilizar um banco de dados compatível com MySQL como origem do AWS DMS

É possível migrar dados de qualquer banco de dados compatível com MySQL (MySQL, MariaDB ou Amazon Aurora MySQL) utilizando o AWS Database Migration Service.

Para obter informações sobre as versões do MySQL compatíveis com o AWS DMS como origem, consulte Origens do AWS DMS.

Você pode usar o SSL para criptografar conexões entre o endpoint compatível com MySQL e a instância de replicação. Para obter mais informações sobre o uso do SSL com um endpoint compatível com MySQL, consulte Usar SSL com o AWS Database Migration Service.

Nas seções a seguir, o termo "autogerenciado" se aplica a qualquer banco de dados instalado on-premises ou no Amazon EC2. O termo "gerenciado pela AWS" se aplica a qualquer banco de dados no Amazon RDS, no Amazon Aurora, ou no Amazon S3.

Para obter mais detalhes sobre a como trabalhar com bancos de dados compatíveis com MySQL e o AWS DMS, consulte as seguintes seções.

Tópicos

Migração do MySQL para o MySQL utilizando o AWS DMS
Utilizar um banco de dados compatível com o MySQL como origem do AWS DMS
Utilizar um banco de dados autogerenciado compatível com o MySQL como origem do AWS DMS
Utilizar um banco de dados compatível com MySQL gerenciado pela AWS como origem do AWS DMS
Limitações ao utilizar um banco de dados MySQL como origem do AWS DMS
Compatibilidade com transações XA
Configurações de endpoint ao utilizar o MySQL como origem do AWS DMS
Tipos de dados de origem do MySQL

Migração do MySQL para o MySQL utilizando o AWS DMS

Para uma migração heterogênea, na qual você está migrando de um mecanismo de banco de dados diferente de MySQL para um banco de dados MySQL, o AWS DMS quase sempre é a melhor ferramenta de migração a ser utilizada. Mas para uma migração homogênea, na qual você está migrando de um banco de dados MySQL para um banco de dados MySQL, é recomendável utilizar um projeto de migração de dados homogênea. As migrações de dados homogêneas utilizam ferramentas de banco de dados nativas para fornecer um desempenho e precisão aprimorados da migração de dados em comparação com o AWS DMS.

Utilizar um banco de dados compatível com o MySQL como origem do AWS DMS

Antes de começar a trabalhar com um banco de dados MySQL como origem para o AWS DMS, confirme se você tem os pré-requisitos a seguir. Esses pré-requisitos se aplicam às origens autogerenciadas ou gerenciadas pela AWS.

Você deve ter uma conta do AWS DMS com o perfil Replication Admin. O perfil precisa dos seguintes privilégios:

REPLICATION CLIENT: este privilégio é necessário apenas para tarefas de CDC. Em outras palavras, as tarefas somente com carga completa não requerem este privilégio.
REPLICATION SLAVE: este privilégio é necessário apenas para tarefas de CDC. Em outras palavras, as tarefas somente com carga completa não requerem este privilégio.
SUPER: este privilégio é necessário somente nas versões do MySQL anteriores à versão 5.6.6.

O usuário do AWS DMS deve ter privilégios SELECT para as tabelas de origem designadas para replicação.

Conceda os seguintes privilégios se você usar avaliações de pré-migração específicas do MySQL.


grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user>  #only for MySQL version 8.0.11 and higher

Utilizar um banco de dados autogerenciado compatível com o MySQL como origem do AWS DMS

É possível utilizar os bancos de dados autogerenciados a seguir, compatíveis com MySQL como origens para o AWS DMS:

MySQL Community Edition
MySQL Standard Edition
MySQL Enterprise Edition
MySQL Cluster Carrier Grade Edition
MariaDB Community Edition
MariaDB Enterprise Edition
MariaDB Column Store

Para utilizar a CDC, ative o registro em log binário. Para habilitar o registro binário, os parâmetros a seguir devem ser configurados nos arquivos my.ini (Windows) ou my.cnf (UNIX) do MySQL.

Parâmetro	Valor
`server_id`	Defina este parâmetro com um valor maior ou igual a 1.
`log-bin`	Defina a rota para o arquivo de log binário, por exemplo `log-bin=E:\MySql_Logs\BinLog`. Não inclua a extensão do arquivo.
`binlog_format`	Defina este parâmetro como `ROW`. Essa configuração é recomendável durante a replicação porque, em certos casos, quando `binlog_format` está definido como `STATEMENT`, ele pode causar inconsistência ao replicar dados para o destino. O mecanismo de banco de dados também grava dados inconsistentes semelhantes no destino quando `binlog_format` está definido como `MIXED`, porque o mecanismo de banco de dados muda automaticamente para o registro em log baseado em `STATEMENT`, o que pode resultar na gravação de dados inconsistentes no banco de dados de destino.
`expire_logs_days`	Defina este parâmetro com um valor maior ou igual a 1. Para evitar o uso excessivo de espaço em disco, recomendamos que você não utilize o valor padrão de 0.
`binlog_checksum`	Defina esse parâmetro como `NONE` para a versão 3.4.7 ou anterior do DMS.
`binlog_row_image`	Defina este parâmetro como `FULL`.
`log_slave_updates`	Defina este parâmetro como `TRUE` se você estiver utilizando uma réplica de leitura do MySQL ou MariaDB como origem.

Se você estiver usando uma réplica de leitura do MySQL ou do MariaDB como origem para uma tarefa de migração do DMS usando o modo Migrar dados existentes e replicar alterações contínuas, há a possibilidade de perda de dados. O DMS não gravará uma transação durante os modos de carga máxima ou CDC nas seguintes condições:

A transação foi confirmada na instância primária antes do início da tarefa no DMS.
A transação não havia sido confirmada com a réplica até a tarefa do DMS já ter sido iniciada, devido ao atraso entre a instância primária e a réplica.

Quanto maior o atraso entre a instância primária e a réplica, maior o potencial de perda de dados.

Se sua origem NDB (cluster) utiliza o mecanismo de banco de dados, os parâmetros a seguir precisarão ser configurados para habilitar CDC em tabelas que utilizam esse mecanismo de armazenamento. Adicione essas alterações no arquivo my.ini do MySQL (Windows) ou my.cnf (UNIX).

Parâmetro	Valor
`ndb_log_bin`	Defina este parâmetro como `ON`. Este valor garante que as alterações em tabelas clusterizadas são registradas no log binário.
`ndb_log_update_as_write`	Defina este parâmetro como `OFF`. Este valor impede o registro de instruções UPDATE como instruções INSERT no log binário.
`ndb_log_updated_only`	Defina este parâmetro como `OFF`. Este valor garante que o log binário contém a linha completa e não apenas as colunas alteradas.

Utilizar um banco de dados compatível com MySQL gerenciado pela AWS como origem do AWS DMS

É possível utilizar os seguintes bancos de dados compatíveis com o MySQL gerenciados pela AWS como origens do AWS DMS:

MySQL Community Edition
MariaDB Community Edition
Amazon Aurora Edição Compatível com MySQL

Ao utilizar um banco de dados compatível com MySQL gerenciado pela AWS como origem do AWS DMS, confirme se tem os seguintes pré-requisitos da CDC:

Para ativar os logs binários para o RDS para MySQL e para o RDS para MariaDB, ative backups automáticos no nível da instância. Para ativar logs binários para um cluster do Aurora MySQL, altere a variável binlog_format no grupo de parâmetros.

Para obter mais informações sobre a configuração de backups automáticos, consulte Trabalhar com backups automáticos no Guia do usuário do Amazon RDS.

Para obter mais informações sobre como configurar o registro em log binário para um banco de dados Amazon RDS para MySQL, consulte Configuração do formato de registro em log binário no Guia do usuário do Amazon RDS.

Para obter mais informações sobre como configurar o registro em log binário para um cluster do Aurora MySQL, consulte Como faço para ativar o registro em log binário para meu cluster do Amazon Aurora MySQL?.
Se você planejar utilizar a CDC, ative o registro em log binário. Para obter mais informações sobre como configurar o registro em log binário para um banco de dados Amazon RDS para MySQL, consulte Configuração do formato de registro em log binário no Guia do usuário do Amazon RDS.
Verifique se os logs binários estão disponíveis para o AWS DMS. Como os bancos de dados compatíveis com MySQL gerenciados pela AWS purgam os logs binários assim que possível, é necessário aumentar o período em que os logs permanecem disponíveis. Por exemplo, para aumentar a retenção de log para 24 horas, execute o comando a seguir.
```
 call mysql.rds_set_configuration('binlog retention hours', 24);
                    
```
Defina o parâmetro binlog_format como "ROW".

nota
No MySQL ou no MariaDB, binlog_format é um parâmetro dinâmico, portanto, você não precisa reinicializar para que o novo valor entre em vigor. No entanto, o novo valor só se aplicará às novas sessões. Se você alternar ROW como binlog_format para fins de replicação, o banco de dados ainda poderá criar registros em logs binários subsequentes utilizando o formato MIXED, se essas sessões tiverem iniciado antes da alteração do valor. Isso pode impedir que o AWS DMS capture adequadamente todas as alterações no banco de dados de origem. Ao alterar a configuração binlog_format em um banco de dados MariaDB ou MySQL, reinicie o banco de dados para fechar todas as sessões existentes ou reinicie qualquer aplicação executando operações DML (linguagem de manipulação de dados). Forçar o banco de dados a reiniciar todas as sessões após alterar o parâmetro binlog_format como ROW garantirá que o banco de dados grave todas as alterações subsequentes do banco de dados de origem utilizando o formato correto, para que o AWS DMS possa capturar essas alterações de maneira adequada.
Defina o parâmetro binlog_row_image como "Full".
Defina o parâmetro binlog_checksum como "NONE" para a versão 3.4.7 ou anterior do DMS. Para obter mais informações sobre a configuração de parâmetros no Amazon RDS MySQL, consulte Trabalhar com backups automáticos no Guia do usuário do Amazon RDS.
Se estiver utilizando uma réplica de leitura do Amazon RDS MySQL ou do Amazon RDS MariaDB como origem, ative os backups na réplica de leitura e garanta que o parâmetro log_slave_updates esteja definido como TRUE.

Limitações ao utilizar um banco de dados MySQL como origem do AWS DMS

Ao utilizar um banco de dados MySQL como uma origem, considere o seguinte:

A captura de dados de alteração (CDC) não é compatível com o Amazon RDS MySQL 5.5 ou inferior. Para o Amazon RDS MySQL, utilize a versão 5.6, 5.7 ou 8.0 para ativar a CDC. A CDC é compatível com origens do MySQL 5.5 autogerenciado.
Para CDC, CREATE TABLE, ADD COLUMN e DROP COLUMN que alteram o tipo de dados da coluna e renaming a column são compatíveis. No entanto, DROP TABLE, RENAME TABLE e as atualizações feitas em outros atributos, como o valor padrão da coluna, a nulidade da coluna, o conjunto de caracteres e assim por diante, não são compatíveis.
Para tabelas particionadas na origem, quando você definir Modo de preparação de tabela de destino como Descartar tabelas no destino, o AWS DMS criará uma tabela simples sem partições no destino do MySQL. Para migrar tabelas particionadas para uma tabela particionada no destino, pré-crie as tabelas particionadas no banco de dados MySQL de destino.
Não há suporte para utilizar uma instrução ALTER TABLE table_name ADD COLUMN column_name para adicionar colunas ao início (FIRST) ou no meio de uma tabela (AFTER). As colunas são sempre adicionadas ao final da tabela.
A CDC não é compatível quando um nome de tabela contém caracteres maiúsculos e minúsculos, e o mecanismo de origem está hospedado em um sistema operacional com nomes de arquivos que não diferenciam maiúsculas de minúsculas. Um exemplo é o Microsoft Windows ou o OS X que utilizam HFS+.
É possível utilizar a Edição com Tecnologia Sem Servidor v1 compatível com o Aurora MySQL para carga máxima, mas não é possível utilizá-la para CDC. Isso ocorre porque não é possível ativar os pré-requisitos para o MySQL. Para obter mais informações, consulte Grupos de parâmetros e o Aurora Sem Servidor v1.

A Edição com Tecnologia Sem Servidor v2 compatível com o Aurora MySQL pode ser utilizada com CDC.
O atributo AUTO_INCREMENT em uma coluna não é migrado para uma coluna do banco de dados de destino.
A captura de alterações quando os logs binários não estão armazenados em armazenamento de bloco padrão não é compatível. Por exemplo, a CDC não funciona quando os logs binários são armazenados no Amazon S3.
O AWS DMS cria tabelas de destino com o mecanismo de armazenamento InnoDB por padrão. Se precisar utilizar um mecanismo de armazenamento diferente do InnoDB, crie a tabela manualmente e migre-a utilizando o modo Não executar nenhuma ação.
Não é possível utilizar réplicas do Aurora MySQL como origem do AWS DMS, a não ser que o modo da tarefa de migração do DMS seja Migrar dados existentes, somente com carga máxima.
Se a origem compatível com MySQL for interrompida durante a carga máxima, a tarefa do AWS DMS não será interrompida com um erro. A tarefa terminará com êxito, mas o destino poderá estar fora de sincronia com a origem. Se isso acontecer, reinicie a tarefa ou recarregue as tabelas afetadas.
Índices criados em uma parte do valor de uma coluna não são migrados. Por exemplo, o índice CREATE INDEX first_ten_chars ON customer (name(10)) não é criado no destino.
Em alguns casos, a tarefa não está configurada para replicar LOBs ("SupportLobs" é falso nas definições de tarefa ou a opção Não incluir colunas LOB é escolhida no console da tarefa). Nesses casos, o AWS DMS não migra nenhuma coluna MEDIUMBLOB, LONGBLOB, MEDIUMTEXT nem LONGTEXT para o destino.

As colunas BLOB, TINYBLOB, TEXT e TINYTEXT não são afetadas e são migradas para o destino.
Tabelas de dados temporais ou tabelas com versão do sistema não são compatíveis com bancos de dados MariaDB de origem e de destino.
Ao migrar entre dois clusters do Amazon RDS Aurora MySQL, o endpoint de origem do RDS Aurora MySQL deve ser uma instância de leitura/gravação, não uma instância de réplica.
Atualmente, o AWS DMS não é compatível com a migração de visualizações para o MariaDB.
O AWS DMS não é compatível com as alterações de DDL em tabelas particionadas para o MySQL. Para ignorar a suspensão de tabela para alterações de DDL da partição durante a CDC, defina skipTableSuspensionForPartitionDdl como true.
O AWS DMS só é compatível com transações XA na versão 3.5.0 e superior. As versões anteriores não são compatíveis com transações XA. O AWS DMS não é compatível com transações XA no MariaDB versão 10.6. Para obter mais informações, consulte Compatibilidade com transações XA a seguir.
O AWS DMS não utiliza GTIDs para replicação, mesmo que os dados de origem os contenham.
O AWS DMS não é compatível com o log binário aprimorado do Aurora MySQL.
O AWS DMS não é compatível com a compactação de transação de log binário.
O AWS DMS não propaga eventos ON DELETE CASCADE e ON UPDATE CASCADE para bancos de dados MySQL que utilizam o mecanismo de armazenamento InnoDB. Para esses eventos, o MySQL não gera log binário de eventos para refletir as operações em cascata nas tabelas secundárias. Consequentemente, o AWS DMS não pode replicar as alterações correspondentes nas tabelas secundárias. Para ter mais informações, consulte Índices, chaves estrangeiras ou atualizações ou exclusões em cascata não migrados.
O AWS DMS não captura alterações nas colunas computadas (VIRTUAL e GENERATED ALWAYS). Para trabalhar com essa limitação, faça o seguinte.
- Pré-crie a tabela de destino no banco de dados de destino e crie a tarefa AWS DMS com a configuração de tarefa de carga máxima DO_NOTHING ou TRUNCATE_BEFORE_LOAD.
- Adicione uma regra de transformação para remover a coluna computada do escopo da tarefa. Para obter mais informações sobre regras transformação, consulte Regras de transformação e ações.

Compatibilidade com transações XA

Uma transação de arquitetura estendida (XA) é uma transação que pode ser utilizada para agrupar uma série de operações de vários recursos transacionais em uma única transação global confiável. Uma transação XA utiliza um protocolo de confirmação de duas fases. Em geral, a captura de alterações enquanto há transações XA abertas pode resultar em perda de dados. Se o banco de dados não utilizar transações XA, é possível ignorar essa permissão e a configuração IgnoreOpenXaTransactionsCheck utilizando o valor padrão TRUE. Para começar a replicar a partir de uma origem que possui transações XA, faça o seguinte:

Verifique se o usuário do endpoint do AWS DMS tem as seguintes permissões:
```
grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';
```
Defina a configuração do endpoint IgnoreOpenXaTransactionsCheck como false.

nota

O AWS DMS não é compatível com transações XA na versão 10.6 do banco de dados MariaDB de origem.

Configurações de endpoint ao utilizar o MySQL como origem do AWS DMS

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

A tabela a seguir mostra as configurações de endpoint que é possível utilizar com o MySQL como origem.

Nome	Descrição
`EventsPollInterval`	Especifica a frequência com que se deve verificar o log binário para ver se há alterações/eventos novos quando o banco de dados está inativo. Valor padrão: 5 Valores válidos: 1 a 60 Exemplo: `--my-sql-settings '{"EventsPollInterval": 5}'` No exemplo, o AWS DMS verifica se há alterações nos logs binários a cada cinco segundos.
`ExecuteTimeout`	Nas versões 3.4.7 e superiores do AWS DMS, define o tempo limite da instrução do cliente para um endpoint de origem do MySQL, em segundos. Valor padrão: 60 Exemplo: `--my-sql-settings '{"ExecuteTimeout": 1500}'`
`ServerTimezone`	Especifica o fuso horário para o banco de dados MySQL de origem. Exemplo: `--my-sql-settings '{"ServerTimezone": "US/Pacific"}'`
`AfterConnectScript`	Especifica um script para ser executado imediatamente após a conexão do AWS DMS com o endpoint. A tarefa de migração continuará em execução, independentemente se a instrução SQL for bem-sucedida ou não. Valores válidos: uma ou mais instruções SQL válidas, separadas por ponto e vírgula. Exemplo: `--my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'`
`CleanSrcMetadataOnMismatch`	Limpa e recria as informações dos metadados da tabela na instância de replicação quando ocorre uma incompatibilidade. Por exemplo, em uma situação em que a execução de um DDL alternativo na tabela pode resultar em diferentes informações sobre a tabela armazenada em cache na instância de replicação. Booliano. Valor padrão: `false` Exemplo: `--my-sql-settings '{"CleanSrcMetadataOnMismatch": false}'`
`skipTableSuspensionForPartitionDdl`	O AWS DMS não é compatível com as alterações de DDL em tabelas particionadas para o MySQL. No AWS DMS versões 3.4.6 e superiores, a definição disso como `true` ignora a suspensão da tabela das alterações de DDL da partição durante a CDC. O AWS DMS ignora o DDL relacionado à tabela particionada e continua processando outras alterações no log binário. Valor padrão: `false` Exemplo: `--my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'`
`IgnoreOpenXaTransactionsCheck`	No AWS DMS versões 3.5.0 e superiores, especifica se as tarefas devem ignorar as transações XA abertas ao iniciar. Defina isso como `false` se a origem tiver transações XA. Valor padrão: `true` Exemplo: `--my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'`

Tipos de dados de origem do MySQL

A tabela a seguir mostra os tipos de dados de origem do banco de dados MySQL com suporte no AWS DMS e o mapeamento padrão relativo aos tipos de dados do AWS DMS.

Para obter informações sobre como visualizar o tipo de dados mapeado no destino, consulte a seção relativa ao endpoint de destino que você está usando.

Para obter mais informações sobre os tipos de dados do AWS DMS, consulte Tipos de dados do AWS Database Migration Service.

Tipos de dados do MySQL	Tipos de dados do AWS DMS
INT	INT4
BIGINT	INT8
MEDIUMINT	INT4
TINYINT	INT1
SMALLINT	INT2
UNSIGNED TINYINT	UINT1
UNSIGNED SMALLINT	UINT2
UNSIGNED MEDIUMINT	UINT4
UNSIGNED INT	UINT4
UNSIGNED BIGINT	UINT8
DECIMAL(10)	NUMERIC (10,0)
BINARY	BYTES(1)
BIT	BOOLEAN
BIT(64)	BYTES(8)
BLOB	BYTES(65.535)
LONGBLOB	BLOB
MEDIUMBLOB	BLOB
TINYBLOB	BYTES(255)
DATA	DATA
DATETIME	DATETIME DATETIME sem um valor entre parênteses é replicado sem milissegundos. DATETIME com um valor entre parênteses de 1 a 5 (como`DATETIME(5)`) é replicado com milissegundos. Ao replicar uma coluna DATETIME, a hora permanece a mesma no destino. Não é convertida em UTC.
TIME	STRING
TIMESTAMP	DATETIME Ao replicar uma coluna TIMESTAMP, a hora é convertida em UTC no destino.
YEAR	INT2
DOUBLE	REAL8
FLOAT	REAL(DOUBLE) Se os valores FLOAT não estiverem no intervalo a seguir, utilize uma transformação para mapear FLOAT para STRING. Para obter mais informações sobre transformações, consulte Regras de transformação e ações. Os intervalos compatíveis com FLOAT são -1.79E+308 a -2.23E-308, 0 e 2.23E-308 a 1.79E+308
VARCHAR (45)	WSTRING (45)
VARCHAR (2000)	WSTRING (2000)
VARCHAR (4000)	WSTRING (4000)
VARBINARY (4000)	BYTES (4000)
VARBINARY (2000)	BYTES (2000)
CHAR	WSTRING
TEXT	WSTRING
LONGTEXT	NCLOB
MEDIUMTEXT	NCLOB
TINYTEXT	WSTRING(255)
GEOMETRY	BLOB
POINT	BLOB
LINESTRING	BLOB
POLYGON	BLOB
MULTIPOINT	BLOB
MULTILINESTRING	BLOB
MULTIPOLYGON	BLOB
GEOMETRYCOLLECTION	BLOB
ENUM	WSTRING (`tamanho`) Aqui, `tamanho` é o tamanho do valor mais longo em ENUM.
SET	WSTRING (`tamanho`) Aqui, `tamanho` é o tamanho total de todos os valores no SET, incluindo vírgulas.
JSON	CLOB

nota

Em alguns casos, é possível especificar os tipos de dados DATETIME e TIMESTAMP com um valor “zero” (ou seja, 0000-00-00). Nesse caso, verifique se o banco de dados de destino na tarefa de replicação é compatível com valores “zero” para os tipos de dados DATETIME e TIMESTAMP. Caso contrário, esses valores serão registrados como nulos no destino.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Usar o PostgreSQL como origem

Utilizar o SAP ASE como origem