Usando um MySQL-compatible banco de dados como fonte para AWS DMS

Você pode migrar dados de qualquer MySQL-compatible banco de dados (MySQL, MariaDB ou Amazon Aurora MySQL) usando o Database Migration Service. AWS

Para obter informações sobre as versões do MySQL que oferecem AWS DMS suporte como fonte, consulte. Fontes para AWS DMS

Você pode usar SSL para criptografar conexões entre seu MySQL-compatible endpoint e a instância de replicação. Para obter mais informações sobre como usar SSL com um MySQL-compatible endpoint, consulte. Usando SSL com 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 detalhes adicionais sobre como trabalhar com MySQL-compatible bancos de dados AWS DMS, consulte as seções a seguir.

nota

Ao configurar as regras de mapeamento AWS Database Migration Service (AWS DMS), é importante evitar o uso de curingas (%) para nomes de bancos de dados ou esquemas. Em vez disso, você deve especificar explicitamente somente os bancos de dados criados pelo usuário que precisam ser migrados. O uso de um caractere curinga inclui todos os bancos de dados no processo de migração, inclusive bancos dados do sistema que não são necessários na instância de destino. Como o usuário principal do Amazon RDS para MySQL não tem as permissões necessárias para importar dados para os bancos de dados do sistema de destino, a tentativa de migrar esses bancos de dados do sistema falha.

Migrando do MySQL para o MySQL usando AWS DMS

Para uma migração heterogênea, em que você está migrando de um mecanismo de banco de dados diferente do MySQL para um banco de dados MySQL AWS DMS , é quase sempre a melhor ferramenta de migração a ser usada. 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.

Usando qualquer MySQL-compatible banco de dados como fonte para AWS DMS

Antes de começar a trabalhar com um banco de dados MySQL como fonte para AWS DMS, verifique se você tem os seguintes pré-requisitos. Esses pré-requisitos se aplicam a fontes autogerenciadas ou gerenciadas. AWS

Você deve ter uma conta para AWS DMS que tenha a função de administrador de replicação. 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.

  nota

  Para o MariaDB versão 10.5.2+, você pode usar o BINLOG MONITOR — ele substitui o REPLICATION CLIENT.

• 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 AWS DMS usuário também 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 MySQL-specific pré-migração:

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
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only

Se você estiver usando uma fonte do RDS e planeja executar avaliações de MySQL-specific pré-migração, adicione a seguinte permissão:

grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check

Se o parâmetro BatchEnable for true, será necessário conceder:

grant create temporary tables on `<schema>`.* to <dms_user>;

Usando um MySQL-compatible banco de dados autogerenciado como fonte para AWS DMS

Você pode usar os seguintes MySQL-compatible bancos de dados autogerenciados como fontes para 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 or binlog_expire_logs_seconds	O parâmetro expire_logs_days está obsoleto desde o MySQL 8.0 e removido no MySQL 8.4. Para obter mais informações, consulte Variáveis e opções de servidor e status adicionadas, obsoletas ou removidas no MySQL 8.4 desde 8.0. Use o expire_logs_days parâmetro para o MySQL 5.x. Recomendamos que você defina esse parâmetro como 1 ou maior, consulte Opções e variáveis de registro binário. Use o binlog_expire_logs_seconds parâmetro para o MySQL 8.0 e versões posteriores. Recomendamos que você defina esse parâmetro para um valor de 86400 segundos (1 dia) ou mais. Consulte Opções e variáveis de registro binário.
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.

Usando um AWS MySQL-compatible -banco de dados gerenciado como fonte para AWS DMS

Você pode usar os seguintes MySQL-compatible bancos AWS de dados gerenciados como fontes para AWS DMS:

• MySQL Community Edition

• MariaDB Community Edition

• Edição Amazon Aurora MySQL-Compatible

Ao usar um MySQL-compatible banco AWS de dados gerenciado como fonte para AWS DMS, verifique se você tem os seguintes pré-requisitos para o 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.

• Certifique-se de que os registros binários estejam disponíveis para AWS DMS o. Como os MySQL-compatible bancos de dados AWS gerenciados eliminam os registros binários o mais rápido possível, você deve aumentar o tempo em que os registros 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 AWS DMS impedir a captura adequada de 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 seu banco de dados a reiniciar todas as sessões após alterar o binlog_format parâmetro para ROW garantirá que seu banco de dados grave todas as alterações subsequentes no banco de dados de origem usando o formato correto, para que AWS DMS possa capturar essas alterações adequadamente.

• 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.

Para obter mais informações sobre as mudanças de segurança do Aurora MySQL 8.4, consulte Segurança com o Amazon Aurora MySQL e Gerenciamento de senhas com o Amazon Aurora e Secrets Manager no Guia do usuário do Amazon Aurora.

Considerações sobre as fontes do Aurora MySQL 8.4

O Aurora MySQL 8.4 introduz mudanças de segurança que podem afetar a conectividade do endpoint de origem. AWS DMS Analise o seguinte antes de atualizar sua fonte do Aurora MySQL para a versão 8.4.

Aplicação do TLS

O Aurora MySQL 8.4 é definido como ON por padrão, require_secure_transport o que significa que todas as conexões devem usar TLS. Se seu endpoint de AWS DMS origem se conectar ao Aurora MySQL 8.4 e o modo SSL estiver definido como nenhum, as conexões serão rejeitadas. Se o modo SSL do seu endpoint estiver definido como nenhum, você receberá o seguinte erro:. MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON Defina o modo SSL do endpoint como verify-ca ou verify-full. Ambos os modos exigem um certificado CA. Como alternativa, require_secure_transport defina como OFF no grupo de parâmetros do cluster Aurora para permitir conexões não criptografadas.

nota

O Aurora MySQL 8.4 só é compatível com pacotes de criptografia GCM para TLS 1.2. Todas as CBC-mode cifras foram removidas. AWS DMS usa TLS 1.2 para endpoints MySQL e Aurora MySQL e negociará automaticamente uma cifra GCM compatível. Se você tiver configurações de cifras personalizadas, verifique se elas incluem uma das seguintes cifras suportadas: ECDHE-RSA-AES128-GCM-SHA256,,, ou. ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384

nota

AWS DMS não suporta TLS 1.3 para endpoints MySQL. Isso não afeta a conectividade com o Aurora MySQL 8.4, pois o Aurora MySQL 8.4 continua oferecendo suporte ao TLS 1.2.

Autenticação (Aurora MySQL e RDS para MySQL 8.4)

O Aurora MySQL 8.4 substitui o default_authentication_plugin parâmetro por, cujo padrão é. authentication_policy *:caching_sha2_password Os usuários existentes do banco de dados mantêm seu plug-in de autenticação atual após a atualização. Se você criar novos usuários de AWS DMS endpoint após a atualização, eles serão usados caching_sha2_password por padrão, a menos que você authentication_policy defina isso *:mysql_native_password no grupo de parâmetros do cluster.

Redefinição da senha do usuário mestre

Depois de atualizar para o Aurora MySQL 8.4, redefinir a senha do usuário mestre por meio da CLI ou Console de gerenciamento da AWS da rotação do Secrets Manager define o plug-in de autenticação do usuário mestre para o padrão definido pelo parâmetro. authentication_policy Se authentication_policy estiver definido com seu valor padrão (*:caching_sha2_password), o plug-in de autenticação do usuário principal mudará de mysql_native_password para caching_sha2_password na próxima redefinição de senha.

Se seu endpoint de AWS DMS origem usa a conta de usuário principal, verifique a conectividade após qualquer redefinição de senha. Para evitar alterações no plug-in de autenticação, faça o seguinte:

• authentication_policyDefina como *:mysql_native_password em seu grupo de parâmetros do cluster antes de redefinir a senha ou

• Crie um usuário de AWS DMS endpoint dedicado com um plug-in de autenticação especificado explicitamente (recomendado). Por exemplo: CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

Limitações no uso de um banco de dados MySQL como fonte para 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ê define o modo de preparação da tabela Target como Drop tables on target, AWS DMS cria 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.

• O uso de uma ALTER TABLE table_name ADD COLUMN column_name instrução para adicionar colunas no início (FIRST) ou no meio de uma tabela (AFTER) não é compatível com destinos relacionais. As colunas são sempre adicionadas ao final da tabela. Quando o destino é o Amazon S3 ou o Amazon Kinesis Data Streams, é possível adicionar colunas usando FIRST ou AFTER.

• 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+.

• Você pode usar o Aurora MySQL-Compatible Edition Serverless v1 para carga total, mas não 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.

  O Aurora MySQL-Compatible Edition Serverless v2 é compatível 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.

• 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.

• Você não pode usar réplicas do Aurora MySQL como fonte, a AWS DMS menos que seu modo de tarefa de migração do DMS seja Migrar dados existentes — somente com carga total.

• Se a MySQL-compatible fonte for interrompida durante a carga total, a AWS DMS tarefa 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 é configurada para não replicar LOBs (” SupportLobs "é falso nas configurações da tarefa ou Não incluir colunas LOB é escolhido no console de tarefas). Nesses casos, AWS DMS não migra nenhuma coluna MEDIUMBLOB, LONGBLOB, MEDIUMTEXT e 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.

• Se estiver migrando entre dois clusters do Amazon RDS Aurora MySQL, o endpoint de origem do RDS Aurora MySQL deve ser uma instância, não uma instância de réplica. read/write

• AWS DMS atualmente não oferece suporte à migração de visualizações para o MariaDB.

• AWS DMS não suporta alterações de DDL para tabelas particionadas para MySQL. Para ignorar a suspensão de tabela para alterações de DDL da partição durante a CDC, defina skipTableSuspensionForPartitionDdl como true.

• AWS DMS só suporta transações XA na versão 3.5.0 e superior. As versões anteriores não oferecem suporte a transações XA. AWS DMS não suporta transações XA no MariaDB versão 10.6 ou superior. Para obter mais informações, consulte a seguir. Compatibilidade com transações XA

• AWS DMS não usa GTIDs para replicação, mesmo que os dados de origem os contenham.

• AWS DMS não é compatível com o log binário aprimorado do Aurora MySQL.

• AWS DMS não oferece suporte à compactação de transações de log binário.

• AWS DMS não propaga eventos ON DELETE CASCADE e ON UPDATE CASCADE para bancos de dados MySQL usando 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, não é AWS DMS possível replicar as alterações correspondentes nas tabelas secundárias. Para obter mais informações, consulte Índices, chaves estrangeiras ou atualizações ou exclusões em cascata não migrados.

• AWS DMS não captura alterações nas colunas computadas (VIRTUALeGENERATED ALWAYS). Para trabalhar com essa limitação, faça o seguinte.

  • Pre-create a tabela de destino no banco de dados de destino e crie a AWS DMS tarefa com a configuração de tarefa DO_NOTHING ou TRUNCATE_BEFORE_LOAD carga total.

  • 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.

• Devido à limitação interna do MySQL, AWS DMS pode processar BinLogs com tamanho não superior a 4 GB. Logs binários maiores que 4 GB podem gerar falhas em tarefas do DMS ou outros comportamentos imprevisíveis. Você deve reduzir o tamanho das transações para evitar logs binários maiores que 4 GB.

• AWS DMS não suporta marcações invertidas (`) ou aspas simples (') em nomes de esquemas, tabelas e colunas.

• AWS DMS não migra dados de colunas invisíveis em seu banco de dados de origem. Para incluir essas colunas no escopo da migração, utilize a instrução ALTER TABLE para tornar essas colunas visíveis.

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:

• Certifique-se de que o usuário do AWS DMS endpoint tenha a seguinte permissão:

  grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';

• Defina a configuração do endpoint IgnoreOpenXaTransactionsCheck como false.

nota

AWS DMS não suporta transações XA no MariaDB Source DB versão 10.6 ou superior.

Configurações de endpoint ao usar o MySQL como fonte para 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 usando o AWS DMS console ou usando o create-endpoint comando no AWS CLI, com a sintaxe --my-sql-settings '{"EndpointSetting": "value", ...}' JSON.

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

Name (Nome)	Description
ConnectionTimeout	Utilize esse atributo de conexão adicional (ECA) para definir o tempo limite de conexão do endpoint para a instância do MySQL, em segundos. O valor de padrão é de 10 segundos. Exemplo de ECA:ConnectionTimeout=30.
EventsPollInterval	Especifica com que frequência verificar se há novos registros binários changes/events quando o banco de dados está ocioso. Valor padrão: 5 Valores válidos: 1 a 60 Exemplo: --my-sql-settings '{"EventsPollInterval": 5}' No exemplo, AWS DMS verifica as alterações nos registros binários a cada cinco segundos.
ExecuteTimeout	Para AWS DMS as versões 3.4.7 e superiores, 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 a ser executado imediatamente após a AWS DMS conexão 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"}'
CleanSourceMetadataOnMismatch	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 '{"CleanSourceMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl	AWS DMS não suporta alterações de DDL para tabelas particionadas para MySQL. Para AWS DMS as versões 3.4.6 e superiores, definir isso para true ignorar a suspensão da tabela para alterações de DDL de partição durante o CDC. 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	Para AWS DMS as 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 que são suportados durante o uso AWS DMS e o mapeamento padrão dos tipos de AWS DMS dados.

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 informações adicionais sobre AWS DMS os tipos de dados, consulteTipos de dados do AWS Database Migration Service.

Tipos de dados do MySQL	AWS DMS tipos de dados
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)
DATE	DATE
DATETIME	DATETIME DATETIME sem um valor entre parênteses é replicado sem milissegundos. DATETIME com um valor entre parênteses de 1 a 5 (comoDATETIME(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. O intervalo FLOAT suportado é de -1,79E+308 a -2,23, 0 e 2,23 a 1,79E+308 E-308 E-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	SEQUÊNCIA DE CARACTERES () length Aqui length está o comprimento do valor mais longo no ENUM.
SET	SEQUÊNCIA DE CARACTERES () length Aqui length está 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.