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

Modo de foco

Utilizar um banco de dados compatível com MySQL como origem do AWS DMS - AWS Database Migration Service

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

Você pode migrar dados de qualquer banco de dados compatível com MySQL (MySQL, MariaDB ou Amazon Aurora MySQL) usando o Database Migration Service. AWS

Para obter informações sobre as versões do MySQL compatíveis com o AWS DMS como origem, consulte Fontes para 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 Usando SSL com AWS Database Migration Service.

Nas seções a seguir, o termo “autogerenciado” se aplica a qualquer banco de dados instalado localmente ou na 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 bancos de dados compatíveis com MySQL AWS DMS, consulte as seções a seguir.

Tópicos

Migração do MySQL para o MySQL utilizando o AWS DMS
Usando qualquer banco de dados compatível com MySQL como fonte para AWS DMS
Usando um banco de dados autogerenciado compatível com MySQL como fonte para AWS DMS
Usando um banco AWS de dados compatível com MySQL gerenciado como fonte para AWS DMS
Limitações no uso de um banco de dados MySQL como fonte para AWS DMS
Compatibilidade com transações XA
Configurações de endpoint ao usar o MySQL como fonte para 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, 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 banco de dados compatível com MySQL 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, full-load-only as tarefas não exigem esse privilégio.
REPLICATION SLAVE: este privilégio é necessário apenas para tarefas de CDC. Em outras palavras, full-load-only as tarefas não exigem esse 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 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

Usando um banco de dados autogerenciado compatível com MySQL como fonte para 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.

Parameter	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).

Parameter	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 banco AWS de dados compatível com MySQL gerenciado como fonte para AWS DMS

Você pode usar os seguintes bancos de dados compatíveis AWS com MySQL gerenciados como fontes para: AWS DMS

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

Ao usar um banco AWS de dados compatível com MySQL 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 bancos AWS de dados compatíveis com MySQL 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.

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.
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.
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 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 está 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.
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.
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 é usado 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 à compressã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.
- 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.
Devido à limitação interna do MySQL, BINLOGs não AWS DMS pode processar mais do que 4 GB. BINLOGs maiores que 4 GB podem resultar em falhas nas tarefas do DMS ou em outros comportamentos imprevisíveis. Você deve reduzir o tamanho das transações para evitar BINLOGs mais de 4 GB.

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.

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 Example: `--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 Example: `--my-sql-settings '{"ExecuteTimeout": 1500}'`
`ServerTimezone`	Especifica o fuso horário para o banco de dados MySQL de origem. Example: `--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. Example: `--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` Example: `--my-sql-settings '{"CleanSrcMetadataOnMismatch": 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 partitioned-table-related DDL e continua processando outras alterações no log binário. Valor padrão: `false` Example: `--my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'`
`IgnoreOpenXaTransactionsCheck`	Para AWS DMS as versões 3.5.0 e posteriores, 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` Example: `--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 para 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 (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	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.

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

Nesta página

Selecione suas preferências de cookies

Personalizar preferências de cookies

Essenciais

Desempenho

Funcionais

Publicidade

Não foi possível salvar as preferências de cookie

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

Tópicos

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

Usando qualquer banco de dados compatível com MySQL como fonte para AWS DMS

Usando um banco de dados autogerenciado compatível com MySQL como fonte para AWS DMS

Usando um banco AWS de dados compatível com MySQL gerenciado como fonte para AWS DMS

nota

Limitações no uso de um banco de dados MySQL como fonte para AWS DMS

Compatibilidade com transações XA

nota

Configurações de endpoint ao usar o MySQL como fonte para AWS DMS

Tipos de dados de origem do MySQL

nota

Nesta página

Esta página foi útil?

Próximo tópico:

Tópico anterior:

Precisa de ajuda?