View a markdown version of this page

Usando um MySQL-compatible banco de dados como alvo para AWS Database Migration Service - AWS Database Migration Service
Pré-requisitos para o MySQL como destinoDestinos do Aurora MySQL 8.4Limitações no MySQL como destinoConfigurações de endpointTipos de dados de destino do MySQL

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

Usando um MySQL-compatible banco de dados como alvo para AWS Database Migration Service

Você pode migrar dados para qualquer MySQL-compatible banco de dados usando AWS DMS, de qualquer um dos mecanismos de dados de origem que oferecem AWS DMS suporte. Se você estiver migrando para um MySQL-compatible banco de dados local, é AWS DMS necessário que seu mecanismo de origem resida AWS no ecossistema. O mecanismo pode estar em um serviço AWS gerenciado, como Amazon RDS, Amazon Aurora ou Amazon S3. Ou o mecanismo pode estar em um banco de dados autogerenciado no Amazon EC2.

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

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

Você pode usar os seguintes MySQL-compatible bancos de dados como destinos 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

  • Amazon Aurora MySQL

nota

Independentemente do mecanismo de armazenamento de origem (MyISAM, MEMORY e assim por diante) AWS DMS , cria MySQL-compatible uma tabela de destino como uma tabela InnoDB por padrão.

Se precisar de uma tabela em um mecanismo de armazenamento diferente do InnoDB, você pode criar manualmente a tabela no MySQL-compatible destino e migrar a tabela usando a opção Não fazer nada. Para obter mais informações, consulte Full-load configurações de tarefas.

Para obter detalhes adicionais sobre como trabalhar com um MySQL-compatible banco de dados como destino AWS DMS, consulte as seções a seguir.

Usando qualquer MySQL-compatible banco de dados como alvo para AWS Database Migration Service

Antes de começar a trabalhar com um MySQL-compatible banco de dados como destino para AWS DMS, verifique se você preencheu os seguintes pré-requisitos:

  • Forneça uma conta de usuário AWS DMS que tenha read/write privilégios no MySQL-compatible banco de dados. Para criar os privilégios necessários, execute os seguintes comandos.

    
CREATE USER '<user acct>'@'%' IDENTIFIED BY '<user password>';
GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT, CREATE TEMPORARY TABLES  ON <schema>.* TO 
'<user acct>'@'%';
GRANT ALL PRIVILEGES ON awsdms_control.* TO '<user acct>'@'%';

  • Durante a fase de migração de carga máxima, você precisa desativar as chaves externas nas suas tabelas de destino. Para desativar as verificações de chave estrangeira em um MySQL-compatible banco de dados durante um carregamento completo, você pode adicionar o seguinte comando à seção Atributos de conexão extras do AWS DMS console do seu endpoint de destino.

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  • Defina o parâmetro local_infile = 1 do banco de dados para permitir que o AWS DMS carregue dados no banco de dados de destino.

  • 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

Considerações sobre os destinos do Aurora MySQL 8.4

O Aurora MySQL 8.4 introduz mudanças de segurança que podem afetar a conectividade do endpoint de destino. AWS DMS Analise o seguinte antes de atualizar seu destino 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 destino 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 o endpoint de AWS DMS destino usar 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';

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. Para obter informações sobre os problemas conhecidos do plug-in de autenticação, consulte o Plug-in de autenticação no Guia do usuário do Amazon RDS.

Limitações no uso MySQL-compatible de um banco de dados como destino para AWS Database Migration Service

Ao usar um banco de dados MySQL como destino, AWS DMS não oferece suporte ao seguinte:

  • As instruções da linguagem de definição de dados (DDL) TRUNCATE PARTITION, DROP TABLE e RENAME TABLE.

  • Uso de uma declaração ALTER TABLE table_name ADD COLUMN column_name para adicionar colunas ao início ou meio de uma tabela.

  • Ao carregar dados para um MySQL-compatible destino em uma tarefa de carregamento total, AWS DMS não relata erros causados por restrições nos registros de tarefas, o que pode causar erros de chave duplicados ou incompatibilidades com o número de registros. Isso é causado pela forma como o MySQL trata dados locais com o comando LOAD DATA. Faça o seguinte durante a fase de carga máxima:

    • Desativar restrições

    • Use a AWS DMS validação para garantir que os dados sejam consistentes.

  • Quando você atualiza o valor de uma coluna para o valor existente, os MySQL-compatible bancos de dados retornam um 0 rows affected aviso. Embora esse comportamento não seja tecnicamente um erro, ele é diferente de como a situação é controlada por outros mecanismos de banco de dados. Por exemplo, o Oracle executa uma atualização de uma linha. Para MySQL-compatible bancos de dados, AWS DMS gera uma entrada na tabela de controle awsdms_apply_exceptions e registra o seguinte aviso.

    
Some changes from the source database had no impact when applied to
the target database. See awsdms_apply_exceptions table for details.

  • O Aurora Sem Servidor está disponível como destino para o Amazon Aurora versão 2, compatível com o MySQL versão 5.7. (Selecione o Aurora Sem Servidor versão 2.07.1 para poder utilizar o Aurora Sem Servidor compatível com o MySQL 5.7.) Para ter mais informações sobre o Aurora Sem Servidor, consulte Usar o Aurora Serverless v2 no Guia do usuário do Amazon Aurora.

  • AWS DMS não suporta o uso de um endpoint de leitura para o Aurora ou o Amazon RDS, a menos que as instâncias estejam no modo gravável, ou seja, read_only os parâmetros innodb_read_only e estejam definidos como ou. 0 OFF Para obter mais informações sobre como utilizar o Amazon RDS e o Aurora como destinos, consulte:

  • Ao replicar o tipo de dados TIME, a parte fracionária do valor de tempo não é replicada.

  • Ao replicar o tipo de dados TIME com o atributo de conexão adicional loadUsingCSV=false, o valor do tempo é limitado ao intervalo [00:00:00, 23:59:59].

Configurações de endpoint ao usar um MySQL-compatible banco de dados como destino para AWS DMS

Você pode usar as configurações do endpoint para configurar seu banco de dados de MySQL-compatible destino de forma semelhante ao uso de atributos de conexão extras. Você especifica as configurações ao criar o endpoint de destino 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 endpoints que é possível utilizar com o MySQL como destino.

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.

TargetDbType

Especifica o destino para onde devem migrar as tabelas de origem, seja para um único banco de dados ou vários. Se você especificarSPECIFIC_DATABASE, precisará especificar o nome do banco de dados, AWS CLI seja ao usar Console de gerenciamento da AWS o.

Valor padrão: MULTIPLE_DATABASES

Valores válidos: {SPECIFIC_DATABASE, MULTIPLE_DATABASES}

Exemplo: --my-sql-settings '{"TargetDbType": "MULTIPLE_DATABASES"}'

ParallelLoadThreads

Melhora o desempenho ao carregar dados no banco de dados de MySQL-compatible destino. Especifica quantos segmentos usar para carregar os dados no banco de dados de MySQL-compatible destino. Configurar um grande número de threads pode ter um efeito adverso no desempenho do banco de dados, pois cada thread requer uma conexão separada.

Valor padrão: 1

Valores válidos: 1 a 5

Exemplo: --my-sql-settings '{"ParallelLoadThreads": 1}'

AfterConnectScript

Especifica um script para ser executado imediatamente após a conexão do AWS DMS com o endpoint.

Por exemplo, você pode especificar que o MySQL-compatible destino deve traduzir as instruções recebidas no conjunto de caracteres latin1, que é o conjunto de caracteres padrão compilado do banco de dados. Esse parâmetro geralmente melhora o desempenho ao converter de clientes UTF8.

Exemplo: --my-sql-settings '{"AfterConnectScript": "SET character_set_connection='latin1'"}'

MaxFileSize

Especifica o tamanho máximo (em KB) de qualquer arquivo.csv usado para transferir dados para um banco de dados. MySQL-compatible

Valor padrão: 32768 KB (32 MB)

Valores válidos: 1 a 1.048.576

--my-sql-settings '{"MaxFileSize": 512}'

Você também pode usar atributos de conexão extras para configurar seu banco de dados de MySQL-compatible destino.

A tabela a seguir mostra os atributos de conexão adicionais que podem ser utilizados com o MySQL como origem.

Name (Nome) Description

Initstmt=SET FOREIGN_KEY_CHECKS=0;

Desabilita as verificações de chaves estrangeiras.

Exemplo: --extra-connection-attributes "Initstmt=SET FOREIGN_KEY_CHECKS=0;"

Initstmt=SET time_zone

Especifica o fuso horário do MySQL-compatible banco de dados de destino.

Valor padrão: UTC

Valores válidos: os nomes dos fusos horários disponíveis no banco de dados MySQL de destino.

Exemplo: --extra-connection-attributes "Initstmt=SET time_zone=US/Pacific;"

Como alternativa, é possível utilizar o parâmetro AfterConnectScript do comando --my-sql-settings para desativar as verificações de chave estrangeira e especificar o fuso horário do banco de dados.

Tipos de dados de destino do MySQL

A tabela a seguir mostra os tipos de dados de destino 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 adicionais sobre AWS DMS os tipos de dados, consulteTipos de dados do AWS Database Migration Service.

AWS DMS tipos de dados

Tipos de dados do MySQL

BOOLEAN

BOOLEAN

BYTES

Se o tamanho for de 1 a 65.535, utilize VARBINARY (tamanho).

Se o tamanho for de 65.536 a 2.147.483.647, utilize LONGLOB.

DATE

DATE

TIME

TIME

TIMESTAMP

“Se a escala for => 0 e =< 6, use: DATETIME (escala)

Se a escala for => 7 e =< 9, use: VARCHAR (37)”

INT1

TINYINT

INT2

SMALLINT

INT4

INTEGER

INT8

BIGINT

NUMERIC

DECIMAL (p,s)

REAL4

FLOAT

REAL8

DOUBLE PRECISION

STRING

Se o tamanho for de 1 a 21.845, utilize VARCHAR (tamanho).

Se o tamanho for de 21.846 a 2.147.483.647, utilize LONGTEXT.

UINT1

UNSIGNED TINYINT

UINT2

UNSIGNED SMALLINT

UINT4

UNSIGNED INTEGER

UINT8

UNSIGNED BIGINT

WSTRING

Se o tamanho for de 1 a 32.767, utilize VARCHAR (tamanho).

Se o tamanho for de 32.768 a 2.147.483.647, utilize LONGTEXT.

BLOB

Se o tamanho for de 1 a 65.535, utilize BLOB.

Se o tamanho for de 65.536 a 2.147.483.647, utilize LONGBLOB.

Se o tamanho for 0, utilize LONGBLOB (suporte pleno ao tipo LOB).

NCLOB

Se o tamanho for de 1 a 65.535, use TEXT.

Se o tamanho for de 65.536 a 2.147.483.647, utilize LONGTEXT com ucs2 para CHARACTER SET.

Se o tamanho for 0, utilize LONGTEXT (suporte pleno ao tipo LOB) e ucs2 para CHARACTER SET.

CLOB

Se o tamanho for de 1 a 65.535, use TEXT.

Se o tamanho for de 65.536 a 2147483647, utilize LONGTEXT.

Se o tamanho for 0, utilize LONGTEXT (suporte pleno ao tipo LOB).