Uso de una base SQL de datos compatible con My como fuente para AWS DMS

Puede migrar datos de cualquier base de datos SQL compatible con My (MySQL, MariaDB o Amazon Aurora SQL My) mediante Database Migration AWS Service.

Para obtener información sobre las versiones de My SQL que son AWS DMS compatibles como fuente, consulte. Fuentes de AWS DMS

Puede utilizarlo SSL para cifrar las conexiones entre su terminal SQL compatible con My y la instancia de replicación. Para obtener más información sobre el uso SSL con un dispositivo de punto final SQL compatible con My, consulte. Uso de SSL con AWS Database Migration Service

En las siguientes secciones, el término «autogestionado» se aplica a cualquier base de datos que esté instalada de forma local o en Amazon. EC2 El término «AWS gestionado» se aplica a cualquier base de datos de AmazonRDS, Amazon Aurora o Amazon S3.

Para obtener más información sobre cómo trabajar con bases SQL de datos compatibles con My AWS DMS, consulte las siguientes secciones.

Migración de My SQL a My usando SQL AWS DMS

Para una migración heterogénea, en la que se migra de un motor de base de datos distinto de My SQL a una base de SQL datos My, casi siempre AWS DMS es la mejor herramienta de migración que se puede utilizar. Sin embargo, para una migración homogénea, en la que se migra de una base de SQL datos Mi a una base de SQL datos Mi, le recomendamos que utilice un proyecto de migración de datos homogéneos. Las migraciones de datos homogéneas utilizan herramientas de bases de datos nativas para proporcionar un mejor rendimiento y precisión de la migración de datos en comparación con. AWS DMS

Utilice cualquier base de datos SQL compatible con My como fuente para AWS DMS

Antes de empezar a trabajar con una SQL base de datos Mi como fuente AWS DMS, asegúrese de cumplir los siguientes requisitos previos. Estos requisitos previos se aplican a las fuentes autogestionadas o AWS gestionadas.

Debe tener una cuenta AWS DMS que tenga la función de administrador de replicación. El rol necesita los siguientes privilegios:

• REPLICATIONCLIENT— Este privilegio solo es necesario para CDC las tareas. En otras palabras, full-load-only las tareas no requieren este privilegio.

• REPLICATIONSLAVE— Este privilegio solo es necesario para CDC las tareas. En otras palabras, full-load-only las tareas no requieren este privilegio.

• SUPER— Este privilegio solo es necesario en mis SQL versiones anteriores a la 5.6.6.

El AWS DMS usuario también debe tener SELECT privilegios para las tablas de origen designadas para la replicación.

Otorgue los siguientes privilegios si utiliza las evaluaciones previas a la migración SQL específicas de My.

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 una base de datos SQL autogestionada compatible con My como fuente para AWS DMS

Puede utilizar las siguientes bases de datos SQL autogestionadas compatibles con My como fuentes para: AWS DMS

• Edición My Community SQL

• Mi edición SQL estándar

• Mi edición SQL empresarial

• Edición My SQL Cluster Carrier Grade

• MariaDB Community Edition

• MariaDB Enterprise Edition

• Column Store de MariaDB

Para usarloCDC, asegúrese de habilitar el registro binario. Para habilitar el registro binario, se deben configurar los siguientes parámetros en SQL el archivo My my.ini (Windows) o my.cnf (UNIX).

Parámetro	Valor
server_id	Establezca este parámetro con un valor de 1 o superior.
log-bin	Establezca la ruta del archivo de registro binario, como por ejemplo log-bin=E:\MySql_Logs\BinLog. No incluya la extensión del archivo.
binlog_format	Establezca este parámetro en ROW. Recomendamos esta configuración durante la replicación porque, en determinados casos, cuando binlog_format se establece en STATEMENT, puede provocar incoherencias al replicar los datos en el destino. El motor de base de datos también escribe datos similares e incoherentes en el destino cuando binlog_format está establecido en MIXED, ya que el motor de base de datos cambia automáticamente al registro basado en STATEMENT que puede resultar en datos incoherentes de escritura en la base de datos de destino.
expire_logs_days	Establezca este parámetro con un valor de 1 o superior. Para evitar la sobrecarga de espacio en disco, se recomienda que no utilice el valor 0, que es el predeterminado.
binlog_checksum	Establezca este parámetro en NONE la DMS versión 3.4.7 o anterior.
binlog_row_image	Establezca este parámetro en FULL.
log_slave_updates	Establezca este parámetro en TRUE si utiliza una réplica de lectura de My SQL o MariaDB como fuente.

Si utiliza una réplica de lectura de My SQL o MariaDB como fuente para DMS una tarea de migración mediante el modo Migrar los datos existentes y replicar los cambios en curso, existe la posibilidad de que se pierdan datos. DMSno escribirá una transacción durante la carga completa o en las siguientes CDC condiciones:

• La transacción se había confirmado en la instancia principal antes de que se iniciara la DMS tarea.

• La transacción no se había confirmado en la réplica hasta que se inició la DMS tarea, debido al desfase entre la instancia principal y la réplica.

Cuanto mayor sea el intervalo entre la instancia principal y la réplica, mayor será la posibilidad de que se pierdan datos.

Si la fuente usa el motor de base de datos NDB (agrupado), se deben configurar los siguientes parámetros para que se CDC activen en las tablas que usan ese motor de almacenamiento. Agregue estos cambios en el archivo My SQL my.ini (Windows) o my.cnf (UNIX).

Parámetro	Valor
ndb_log_bin	Establezca este parámetro en ON. Este valor garantiza que los cambios en las tablas en clúster se anotan en los registros binarios.
ndb_log_update_as_write	Establezca este parámetro en OFF. Este valor impide escribir UPDATE sentencias como INSERT sentencias en el registro binario.
ndb_log_updated_only	Establezca este parámetro en OFF. Este valor garantiza que el registro binario contiene la totalidad de la fila y no solo las columnas que se han modificado.

Utilizar una base AWS de datos SQL compatible con My gestionada como fuente de AWS DMS

Puede utilizar las siguientes bases de datos AWS gestionadas y SQL compatibles con My como fuentes para: AWS DMS

• Edición My Community SQL

• MariaDB Community Edition

• Edición SQL compatible con Amazon Aurora My

Cuando utilice una base de datos My SQL -compatible AWS administrada como fuente AWS DMS, asegúrese de cumplir los siguientes requisitos previos: CDC

• Para habilitar los registros binarios RDS para My SQL y RDS para MariaDB, habilite las copias de seguridad automáticas a nivel de instancia. Para habilitar los registros binarios para un SQL clúster Aurora My, cambie la variable binlog_format en el grupo de parámetros.

  Para obtener más información sobre la configuración de copias de seguridad automáticas, consulte Trabajar con copias de seguridad automáticas en la Guía del RDS usuario de Amazon.

  Para obtener más información sobre la configuración del registro binario para una SQL base de datos de Amazon RDS for My, consulte Configuración del formato de registro binario en la Guía del RDS usuario de Amazon.

  Para obtener más información sobre la configuración del registro binario para un SQL clúster de Aurora My, consulte ¿Cómo activo el registro binario para mi SQL clúster de Amazon Aurora My? .

• Si planea usarloCDC, active el registro binario. Para obtener más información sobre la configuración del registro binario para una SQL base de datos de Amazon RDS for My, consulte Configuración del formato de registro binario en la Guía del RDS usuario de Amazon.

• Asegúrese de que los registros binarios estén disponibles para AWS DMS. Dado que las bases AWS de datos SQL compatibles con My gestionadas purgan los registros binarios lo antes posible, debe aumentar el tiempo que los registros permanecen disponibles. Por ejemplo, para incrementar la retención de logs a 24 horas, ejecute el siguiente comando.

  
   call mysql.rds_set_configuration('binlog retention hours', 24);
                      

• Establezca el parámetro binlog_format como "ROW".

  nota

  En My SQL o MariaDBbinlog_format, es un parámetro dinámico, por lo que no es necesario reiniciar para que el nuevo valor surta efecto. Sin embargo, el nuevo valor solo se aplicará a las sesiones nuevas. Si cambia binlog_format a ROW con fines de replicación, la base de datos puede seguir creando registros binarios posteriores con el mismo formato MIXED, si esas sesiones se iniciaron antes de que cambiara el valor. Esto puede AWS DMS impedir que se capturen correctamente todos los cambios en la base de datos de origen. Al cambiar la binlog_format configuración de una base de datos MariaDB o SQL Mi base de datos, asegúrese de reiniciar la base de datos para cerrar todas las sesiones existentes o de reiniciar cualquier aplicación que DML realice operaciones (lenguaje de manipulación de datos). Obligar a la base de datos a reiniciar todas las sesiones después de cambiar el binlog_format parámetro ROW garantizará que la base de datos escriba todos los cambios posteriores en la base de datos de origen con el formato correcto, de modo que AWS DMS pueda capturar esos cambios correctamente.

• Establezca el parámetro binlog_row_image como "Full".

• Defina el binlog_checksum parámetro "NONE" para la DMS versión 3.4.7 o anterior. Para obtener más información sobre la configuración de parámetros en Amazon RDS MySQL, consulte Trabajar con copias de seguridad automatizadas en la Guía del RDS usuario de Amazon.

• Si utiliza una réplica de lectura de Amazon RDS My SQL o Amazon RDS MariaDB como fuente, habilite las copias de seguridad en la réplica de lectura y asegúrese de que log_slave_updates el parámetro esté establecido en. TRUE

Limitaciones a la hora de utilizar una SQL base de datos My como fuente para AWS DMS

Cuando utilice una SQL base de datos My como fuente, tenga en cuenta lo siguiente:

• La captura de cambios de datos (CDC) no es compatible con Amazon RDS My SQL 5.5 o versiones anteriores. Para Amazon RDS MySQL, debe usar las versiones 5.6, 5.7 u 8.0 para habilitarloCDC. CDCes compatible con las fuentes autogestionadas de My SQL 5.5.

• ParaCDC, CREATE TABLEADD COLUMN, y DROP COLUMN cambiar el tipo de datos de la columna, y renaming a column son compatibles. Sin embargo, no se admiten DROP TABLE, RENAME TABLE y las actualizaciones realizadas en otros atributos, como el valor predeterminado de la columna, la nulabilidad de la columna, el conjunto de caracteres, etc.

• En el caso de las tablas particionadas de la fuente, al configurar el modo de preparación de tablas de destino en Eliminar tablas de destino, AWS DMS crea una tabla sencilla sin particiones en la sección Mi SQL destino. Para migrar las tablas particionadas a una tabla particionada en el destino, crea previamente las tablas particionadas en la base de datos My de destino. SQL

• No se admite el uso de una ALTER TABLE table_name ADD COLUMN column_name instrucción para añadir columnas al principio (FIRST) o al centro de una tabla (AFTER). Las columnas siempre se añaden al final de la tabla.

• CDCno se admite cuando el nombre de una tabla contiene caracteres en mayúsculas y minúsculas, y el motor de origen está alojado en un sistema operativo con nombres de archivo que no distinguen mayúsculas de minúsculas. Un ejemplo es Microsoft Windows u OS X que usan HFS +.

• Puede usar Aurora My SQL -Compatible Edition Serverless v1 para carga completa, pero no puede usarla para. CDC Esto se debe a que no puede habilitar los requisitos previos de My. SQL Para obtener más información, consulte Grupos de parámetros y Aurora sin servidor v1.

  Aurora My SQL -Compatible Edition Serverless v2 es compatible. CDC

• El INCREMENT atributo AUTO _ de una columna no se migra a una columna de base de datos de destino.

• No se admite la captura de los cambios cuando los registros binarios no se almacenan en almacenamiento de bloques estándar. Por ejemplo, CDC no funciona cuando los registros binarios se almacenan en Amazon S3.

• AWS DMS crea tablas de destino con el motor de almacenamiento InnoDB de forma predeterminada. Si necesita utilizar un motor de almacenamiento distinto de InnoDB, debe crear manualmente la tabla y migrar a ella mediante el modo no hacer nada.

• No puede utilizar las SQL réplicas de Aurora My como fuente, AWS DMS a menos que el modo de tarea de DMS migración sea Migrar los datos existentes (solo a carga completa).

• Si la fuente My SQL -compatible se detiene durante la carga completa, la AWS DMS tarea no se detiene con un error. La tarea finaliza correctamente, pero es posible que el destino no esté sincronizado con el origen. Si esto ocurre, reinicie la tarea o vuelva a cargar las tablas afectadas.

• Los índices creados en una parte del valor de una columna no se migran. Por ejemplo, el índice CREATE INDEX first_ten_chars ON customer (name (10)) no se crea en el destino.

• En algunos casos, la tarea está configurada para no replicarse LOBs (SupportLobs«" es falso en la configuración de la tarea o se selecciona No incluir LOB columnas en la consola de tareas). En estos casos, AWS DMS no migra ninguna LONGTEXT columna MEDIUMBLOB LONGBLOBMEDIUMTEXT,, ni al destino.

  BLOB, TINYBLOBTEXT, y TINYTEXT las columnas no se ven afectadas y se migran al destino.

• Tablas o sistemas de datos temporales: las tablas de versión no son compatibles con las bases de datos de origen y destino de MariaDB.

• Si migra entre dos SQL clústeres My de Amazon RDS Aurora, el punto final de SQL origen RDS Aurora My debe ser una instancia de lectura y escritura, no una instancia de réplica.

• AWS DMS actualmente no admite la migración de vistas para MariaDB.

• AWS DMS no admite DDL cambios en las tablas particionadas de My. SQL Para omitir la suspensión de la tabla por DDL cambios de partición durante un cambioCDC, skipTableSuspensionForPartitionDdl configúrelo entrue.

• AWS DMS solo admite transacciones XA en la versión 3.5.0 y superior. Las versiones anteriores no admiten transacciones XA. AWS DMS no admite transacciones XA en la versión 10.6 de MariaDB. Para obtener más información, consulte Compatibilidad con transacciones XA a continuación.

• AWS DMS no se utiliza GTIDs para la replicación, incluso si los datos de origen los contienen.

• AWS DMS no es compatible con el registro binario SQL mejorado Aurora My.

• AWS DMS no admite la compresión de transacciones de registros binarios.

• AWS DMS no propaga los UPDATE CASCADE eventos ON DELETE CASCADE y ON para mis SQL bases de datos mediante el motor de almacenamiento InnoDB. Para estos eventos, My SQL no genera eventos binlog que reflejen las operaciones en cascada en las tablas secundarias. Por lo tanto, no AWS DMS puede replicar los cambios correspondientes en las tablas secundarias. Para obtener más información, consulte Los índices, las claves externas o las actualizaciones o eliminaciones en cascada no se migran.

• AWS DMS no captura los cambios en las columnas calculadas (VIRTUALyGENERATED ALWAYS). Para evitar esta limitación, haga lo siguiente:

  • Cree previamente la tabla de destino en la base de datos de destino y cree la tarea de AWS DMS con la configuración de tareas de carga completa DO_NOTHING o TRUNCATE_BEFORE_LOAD.

  • Agregue una regla de transformación para eliminar la columna calculada del ámbito de la tarea. Para obtener información sobre las reglas de transformación, consulte Reglas y acciones de transformación.

Compatibilidad con transacciones XA

Una transacción de arquitectura ampliada (XA) es una transacción que se puede usar para agrupar una serie de operaciones de varios recursos transaccionales en una sola transacción global fiable. Una transacción XA utiliza un protocolo de confirmación en dos fases. En general, la captura de cambios mientras hay transacciones XA abiertas puede provocar la pérdida de datos. Si la base de datos no utiliza transacciones XA, puede ignorar este permiso y la configuración IgnoreOpenXaTransactionsCheck mediante el uso del valor TRUE predeterminado. Para empezar a replicar desde un origen que tiene transacciones XA, haga lo siguiente:

• Asegúrese de que el usuario del AWS DMS punto final tenga el siguiente permiso:

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

• Establezca la configuración del punto de conexión IgnoreOpenXaTransactionsCheck en false.

nota

AWS DMS no admite transacciones XA en MariaDB Source DB versión 10.6.

Configuración de punto final cuando se utiliza My SQL como fuente para AWS DMS

Puede utilizar los ajustes de punto final para configurar su base de datos de SQL origen de forma similar a como se utilizan atributos de conexión adicionales. Los ajustes se especifican al crear el punto final de origen mediante la AWS DMS consola o mediante el create-endpoint comando del AWS CLI, con la --my-sql-settings '{"EndpointSetting": "value", ...}' JSON sintaxis.

En la siguiente tabla se muestran los ajustes de punto final que puede utilizar con My SQL como fuente.

Nombre	Descripción
EventsPollInterval	Especifica la frecuencia con la que se va a consultar el registro binario para comprobar si hay cambios o eventos nuevos cuando la base de datos está inactiva. Valor predeterminado: 5 Valores válidos: 1-60 Ejemplo: --my-sql-settings '{"EventsPollInterval": 5}' En el ejemplo, AWS DMS comprueba los cambios en los registros binarios cada cinco segundos.
ExecuteTimeout	Para AWS DMS las versiones 3.4.7 y posteriores, establece el tiempo de espera de la sentencia del cliente para un punto final de My SQL Source, en segundos. Valor predeterminado: 60 Ejemplo: --my-sql-settings '{"ExecuteTimeout": 1500}'
ServerTimezone	Especifica la zona horaria de la base de datos My SQL de origen. Ejemplo: --my-sql-settings '{"ServerTimezone": "US/Pacific"}'
AfterConnectScript	Especifica un script que se ejecutará inmediatamente después de AWS DMS conectarse al punto final. La tarea de migración continúa ejecutándose independientemente de si la SQL sentencia se ejecuta correctamente o no. Valores válidos: una o más SQL sentencias válidas, separadas por punto y coma. Ejemplo: --my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'
CleanSrcMetadataOnMismatch	Limpia y vuelve a crear la información de metadatos de la tabla en la instancia de replicación cuando se produce una discordancia. Por ejemplo, en una situación en la que ejecutar una modificación DDL en la tabla podría generar información diferente sobre la tabla almacenada en caché en la instancia de replicación. Booleano. Valor predeterminado: false Ejemplo: --my-sql-settings '{"CleanSrcMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl	AWS DMS no admite DDL cambios en las tablas particionadas de My. SQL En las AWS DMS versiones 3.4.6 y posteriores, si se establece esta opción, se true omite la suspensión de la tabla cuando se produzcan cambios de particiónDDL. CDC AWS DMS ignora partitioned-table-related DDL y continúa procesando más cambios en el registro binario. Valor predeterminado: false Ejemplo: --my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'
IgnoreOpenXaTransactionsCheck	Para AWS DMS las versiones 3.5.0 y posteriores, especifica si las tareas deben ignorar las transacciones XA abiertas al iniciarse. Configúrelo en false si el origen tiene transacciones XA. Valor predeterminado: true Ejemplo: --my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'

Tipos de datos de origen para My SQL

En la siguiente tabla se muestran los tipos de SQL datos de origen de mi base de datos que se admiten cuando se utiliza AWS DMS y la asignación predeterminada a partir de AWS DMS los tipos de datos.

Para obtener más información sobre cómo ver el tipo de datos que se asigna en el destino, consulte la sección del punto de enlace de destino que esté utilizando.

Para obtener información adicional sobre AWS DMS los tipos de datos, consulteTipos de datos de AWS Database Migration Service.

Mis tipos SQL de datos	AWS DMS tipos de datos
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(65535)
LONGBLOB	BLOB
MEDIUMBLOB	BLOB
TINYBLOB	BYTES(255)
DATE	DATE
DATETIME	DATETIME DATETIMEsin un valor entre paréntesis se replica sin milisegundos. DATETIMEcon un valor entre paréntesis de 1 a 5 (por ejemploDATETIME(5)) se replica en milisegundos. Al replicar una DATETIME columna, el tiempo sigue siendo el mismo en el objetivo. No se convierte en. UTC
TIME	STRING
TIMESTAMP	DATETIME Al replicar una TIMESTAMP columna, la hora se convierte UTC en la hora objetivo.
YEAR	INT2
DOUBLE	REAL8
FLOAT	REAL(DOUBLE) Si los FLOAT valores no están en el rango siguiente, utilice una transformación FLOAT para STRING mapearlos. Para obtener más información sobre transformaciones, consulte Reglas y acciones de transformación. El FLOAT rango admitido es de -1,79E+308 a -2,23E-308, 0 y de 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) Aquí, length es la longitud del valor más largo deENUM.
SET	WSTRING (length) Aquí, length es la longitud total de todos los valores deSET, incluidas las comas.
JSON	CLOB

nota

En algunos casos, puede especificar los tipos de TIMESTAMP datos DATETIME y con un valor «cero» (es decir, 0000-00-00). Si es así, asegúrese de que la base de datos de destino de la tarea de replicación admita valores «cero» para los tipos de datos DATETIME yTIMESTAMP. De lo contrario, estos valores se registran con un valor NULL en el destino.