Usando um banco SQL de dados compatível com My como fonte para AWS DMS - AWS Database Migration Service

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

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

Para obter informações sobre as versões do My SQL que oferecem AWS DMS suporte como fonte, consulteFontes para AWS DMS.

Você pode usar SSL para criptografar conexões entre seu endpoint SQL compatível com My e a instância de replicação. Para obter mais informações sobre como usar SSL com um endpoint SQL compatível com My, 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 “AWS gerenciado” se aplica a qualquer banco de dados na AmazonRDS, Amazon Aurora ou Amazon S3.

Para obter detalhes adicionais sobre como trabalhar com bancos SQL de dados compatíveis com My AWS DMS, consulte as seções a seguir.

Migrando de Meu SQL para Meu usando SQL AWS DMS

Para uma migração heterogênea, em que você está migrando de um mecanismo de banco de dados diferente de Meu SQL para um SQL banco de dados Meu, 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 Meu para um SQL banco de dados Meu, recomendamos que você use um projeto de migração de migrações de dados homogêneas. As migrações de dados homogêneas usam ferramentas de banco de dados nativas para fornecer um desempenho e precisão aprimorados na migração de dados em comparação com. SQL AWS DMS

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

Antes de começar a trabalhar com Meu SQL banco de dados 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:

  • REPLICATIONCLIENT— Esse privilégio é necessário somente para CDC tarefas. Em outras palavras, full-load-only as tarefas não exigem esse privilégio.

  • REPLICATIONSLAVE— Esse privilégio é necessário somente para CDC tarefas. Em outras palavras, full-load-only as tarefas não exigem esse privilégio.

  • SUPER— Esse privilégio é necessário somente em Minhas SQL versões anteriores à 5.6.6.

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

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

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 SQL autogerenciado compatível com My como fonte para AWS DMS

Você pode usar os seguintes bancos de dados autogerenciados SQL compatíveis com My como fontes para: AWS DMS

  • Edição My SQL Community

  • Minha edição SQL padrão

  • Edição My SQL Enterprise

  • Edição My SQL Cluster Carrier Grade

  • MariaDB Community Edition

  • MariaDB Enterprise Edition

  • MariaDB Column Store

Para usarCDC, certifique-se de ativar o registro binário. Para ativar o registro binário, os parâmetros a seguir devem ser configurados no arquivo My SQL my.ini (Windows) ou my.cnf (UNIX).

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 NONE para a DMS versão 3.4.7 ou anterior.

binlog_row_image

Defina este parâmetro como FULL.

log_slave_updates

Defina esse parâmetro como TRUE se você estiver usando uma réplica de leitura My SQL ou MariaDB como fonte.

Se você estiver usando uma réplica de leitura My SQL ou MariaDB como fonte para DMS uma tarefa de migração usando o modo Migrar dados existentes e replicar alterações contínuas, existe a possibilidade de perda de dados. DMSnão gravará uma transação durante a carga total ou CDC sob as seguintes condições:

  • A transação havia sido confirmada na instância primária antes do início da DMS tarefa.

  • A transação não havia sido confirmada com a réplica até o início da DMS tarefa, 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 fonte usa o mecanismo de banco de dados NDB (em cluster), os parâmetros a seguir devem ser configurados para serem ativados CDC em tabelas que usam esse mecanismo de armazenamento. Adicione essas alterações no arquivo My SQL my.ini (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. Esse valor impede a gravação de UPDATE INSERT declarações como instruções 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 SQL compatível com My gerenciado como fonte para AWS DMS

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

  • Edição My SQL Community

  • MariaDB Community Edition

  • Edição compatível com Amazon Aurora My SQL

Ao usar um banco de dados SQL compatível com My AWS-managed como fonte para AWS DMS, verifique se você tem os seguintes pré-requisitos para: CDC

  • Para habilitar registros binários RDS para My SQL e RDS para MariaDB, ative backups automáticos no nível da instância. Para habilitar registros binários para um SQL cluster Aurora My, 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 Como trabalhar com backups automatizados no Guia RDS do usuário da Amazon.

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

    Para obter mais informações sobre como configurar o registro em log binário para um SQL cluster do Aurora My, consulte Como faço para ativar o registro binário no meu cluster Amazon SQL Aurora My? .

  • Se você planeja usarCDC, ative o registro binário. Para obter mais informações sobre como configurar o registro binário para um SQL banco de dados Amazon RDS for My, consulte Configuração do formato de registro binário no Guia RDS do usuário da Amazon.

  • Certifique-se de que os registros binários estejam disponíveis para AWS DMS o. Como os bancos de dados SQL compatíveis com o My AWS-managed 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 My SQL ou no MariaDBbinlog_format, é um parâmetro dinâmico, então 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 binlog_format configuração em um banco de dados MariaDB ou SQL Meu banco de dados, reinicie o banco de dados para fechar todas as sessões existentes ou reinicie qualquer aplicativo DML executando operações (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 binlog_checksum parâmetro "NONE" para a DMS versão 3.4.7 ou anterior. Para obter mais informações sobre a configuração de parâmetros no Amazon RDS MySQL, consulte Como trabalhar com backups automatizados no Guia RDS do usuário da Amazon.

  • Se você estiver usando uma réplica de leitura do Amazon RDS My SQL ou do Amazon RDS MariaDB como fonte, habilite backups na réplica de leitura e garanta que log_slave_updates o parâmetro esteja definido como. TRUE

Limitações no uso de Meu SQL banco de dados como fonte para AWS DMS

Ao usar Meu SQL banco de dados como fonte, considere o seguinte:

  • A captura de dados de alteração (CDC) não é compatível com o Amazon RDS My SQL 5.5 ou inferior. Para o Amazon RDS MySQL, você deve usar a versão 5.6, 5.7 ou 8.0 para habilitar. CDC CDCé compatível com fontes autogerenciadas do My SQL 5.5.

  • ParaCDC, CREATE TABLEADD COLUMN, e DROP COLUMN alterar 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 de destino como Soltar tabelas no destino, AWS DMS cria uma tabela simples sem nenhuma partição em Meu SQL destino. Para migrar tabelas particionadas para uma tabela particionada no destino, pré-crie as tabelas particionadas no Meu banco de dados de destino. SQL

  • Não há suporte para usar 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). As colunas são sempre adicionadas ao final da tabela.

  • CDCnão é suportado 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 arquivo que não diferenciam maiúsculas e minúsculas. Um exemplo é o Microsoft Windows ou OS X usando HFS +.

  • Você pode usar o Aurora My SQL -Compatible Edition Serverless v1 para carga total, mas não pode usá-lo para. CDC Isso ocorre porque você não pode habilitar os pré-requisitos para My. SQL Para obter mais informações, consulte Grupos de parâmetros e o Aurora Sem Servidor v1.

    O Aurora My SQL -Compatible Edition Serverless v2 suporta. CDC

  • O INCREMENT atributo AUTO _ 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, CDC não funciona quando os registros 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 o Aurora My SQL réplicas como fonte, a AWS DMS menos que seu modo de tarefa de DMS migração seja Migrar dados existentes — somente com carga total.

  • Se a fonte SQL compatível com My for interrompida durante o carregamento 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 está configurada para não replicar LOBs (” SupportLobs "é falso nas configurações da tarefa ou Não incluir LOB colunas é escolhido no console de tarefas). Nesses casos, AWS DMS não migra nenhuma LONGTEXT coluna MEDIUMBLOBLONGBLOB,MEDIUMTEXT, e para o destino.

    BLOB, TINYBLOBTEXT, e TINYTEXT as colunas 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 SQL My, o endpoint de origem do RDS Aurora SQL My 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 DDL alterações em tabelas particionadas para MySQL. Para ignorar a suspensão da tabela devido a DDL alterações de partição duranteCDC, skipTableSuspensionForPartitionDdl defina true como.

  • 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 Aurora My SQL aprimorado log binário.

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

  • AWS DMS não propaga UPDATE CASCADE eventos ON DELETE CASCADE e ON para Meus SQL bancos de dados usando o mecanismo de armazenamento InnoDB. Para esses eventos, My SQL não gera eventos de log binário 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.

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 do endpoint ao usar My SQL como fonte para AWS DMS

Você pode usar as configurações do endpoint para configurar seu banco de dados My SQL source de forma semelhante ao uso de atributos de conexão extras. 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 --my-sql-settings '{"EndpointSetting": "value", ...}' JSON sintaxe.

A tabela a seguir mostra as configurações de endpoint que você pode usar com My SQL como fonte.

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 My SQL source, em segundos.

Valor padrão: 60

Example: --my-sql-settings '{"ExecuteTimeout": 1500}'

ServerTimezone

Especifica o fuso horário do Meu SQL banco de dados 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 continua em execução, independentemente de a SQL instrução ser bem-sucedida ou falhar.

Valores válidos: uma ou mais SQL declarações válidas, destacadas 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 uma alteração DDL na tabela pode resultar em informações diferentes 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 DDL alterações em 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 devido a alterações de partição DDL durante. CDC AWS DMS ignora 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 para My SQL

A tabela a seguir mostra os tipos de dados da fonte do Meu SQL banco de dados 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.

Meus tipos SQL de dados

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(6535)

LONGBLOB

BLOB

MEDIUMBLOB

BLOB

TINYBLOB

BYTES(255)

DATE

DATE

DATETIME

DATETIME

DATETIMEsem um valor entre parênteses é replicado sem milissegundos. DATETIMEcom um valor entre parênteses de 1 a 5 (comoDATETIME(5)) é replicado com milissegundos.

Ao replicar uma DATETIME coluna, o tempo permanece o mesmo no destino. Não é convertido emUTC.

TIME

STRING

TIMESTAMP

DATETIME

Ao replicar uma TIMESTAMP coluna, a hora é convertida UTC em no destino.

YEAR

INT2

DOUBLE

REAL8

FLOAT

REAL(DOUBLE)

Se os FLOAT valores não estiverem no intervalo a seguir, use uma transformação para FLOAT mapearSTRING. Para obter mais informações sobre transformações, consulte Regras de transformação e ações.

O FLOAT intervalo suportado é de -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 (length)

Aqui, length está o comprimento do valor mais longo noENUM.

SET

WSTRING (length)

Aqui length está o comprimento total de todos os valores noSET, incluindo vírgulas.

JSON

CLOB

nota

Em alguns casos, você pode especificar os tipos de TIMESTAMP dados DATETIME e com um valor “zero” (ou seja, 0000-00-00). Nesse caso, certifique-se de que o banco de dados de destino na tarefa de replicação ofereça suporte a valores “zero” para os tipos de TIMESTAMP dados DATETIME e. Caso contrário, esses valores serão registrados como nulos no destino.