Configuración de la replicación de varios orígenes para Amazon Aurora MySQL

Con la replicación de varios orígenes, puede configurar un clúster de base de datos de Amazon Aurora MySQL como una réplica que reciba eventos de registros binarios de más de una base de datos MySQL de origen. Cada origen puede ser una instancia de base de datos de RDS para MySQL, otro clúster de base de datos de Aurora MySQL o una base de datos de MySQL que se ejecute fuera de Amazon RDS.

La replicación de varios orígenes es compatible con los clústeres de base de datos de Aurora MySQL que ejecutan las siguientes versiones de motor:

• Aurora MySQL 8.4.8 y versiones posteriores

Para obtener más información acerca de la replicación de varios orígenes de MySQL, consulte MySQL Multi-Source Replication en la documentación de MySQL.

nota

La replicación de varios orígenes en Aurora MySQL utiliza la instancia de escritura (principal) del clúster de base de datos de Aurora como destino de la replicación. Todos los procedimientos almacenados de replicación deben invocarse mientras se está conectado a la instancia de escritura del clúster.

Casos de uso de la replicación de varios orígenes

Considere el uso de la replicación de varios orígenes en Aurora MySQL en los siguientes casos:

• Consolidación de particiones: aplicaciones que necesitan fusionar o combinar datos de varias particiones alojadas en instancias de base de datos independientes en un único clúster de base de datos de Aurora MySQL.

• Informes consolidados: aplicaciones que necesitan generar informes a partir de datos consolidados de varios orígenes, aprovechando las capacidades de escalado de lectura de Aurora.

• Copias de seguridad a largo plazo: requisitos para crear copias de seguridad consolidadas a largo plazo de los datos que se distribuyen entre varias instancias de base de datos compatibles con MySQL.

• Migración entre motores: consolidación de datos de varias instancias de RDS para MySQL o servidores de MySQL externos en un único clúster de Aurora MySQL durante la migración.

• Agregación de varios inquilinos: consolidación de varias bases de datos de un solo inquilino en un clúster de Aurora de varios inquilinos para optimizar los costos y simplificar la administración.

Requisitos previos para la replicación de varios orígenes

Antes de configurar la replicación de múltiples orígenes en el clúster de base de datos de Aurora MySQL, complete los requisitos previos estándar para la replicación de registros binarios, tal como se describe en Configuración de la replicación de registros binarios para Aurora MySQL. Esto incluye habilitar el registro binario en cada origen, retener los registros binarios, crear un usuario de replicación y crear una copia o un volcado de cada origen. Para la replicación de varios orígenes, repita estos pasos para cada instancia de base de datos de origen.

Además de los requisitos previos estándar, asegúrese de cumplir los siguientes requisitos específicos de la replicación de múltiples orígenes.

• Verificación de la versión y la configuración del clúster de destino de Aurora MySQL

  • El clúster de base de datos de Aurora MySQL debe ejecutar una versión de motor compatible (Aurora MySQL 8.4.8 y posteriores).

  • Habilite la confirmación automática en la instancia de escritura de Aurora MySQL. Establezca el parámetro autocommit en 1 en el grupo de parámetros de clúster de base de datos.

• Configure la conectividad de red para cada origen

  Para cada instancia de base de datos de origen, asegúrese de que la instancia de escritura de Aurora MySQL pueda conectarse al origen en el puerto especificado. Las opciones son:

  • Si tanto el origen como el destino están en la misma VPC, configure el grupo de seguridad en la instancia de base de datos de origen para permitir las conexiones entrantes en el puerto 3306 (o en el puerto personalizado) desde el grupo de seguridad del clúster de Aurora MySQL.

  • Si están en VPC diferentes, configure el emparejamiento de VPC o utilice una puerta de enlace de tránsito. Para obtener más información, consulte Acceso a un clúster de base de datos en una VPC desde una instancia EC2 de otra VPC.

  • Si el origen es externo a AWS, asegúrese de que las rutas de red estén disponibles (por ejemplo, mediante una conexión VPN o a través de ella).

nota

Como la replicación de varios orígenes implica varios orígenes, debe verificar la conectividad con cada origen de forma independiente. Asegúrese de que los grupos de seguridad y el enrutamiento admitan todos los puntos de conexión de origen simultáneamente.

Configuración de canales de replicación de varios orígenes en clústeres de base de datos de Aurora MySQL

La configuración de los canales de replicación de varios orígenes en Aurora MySQL es similar a la configuración de la replicación de un solo origen. Para la replicación de varios orígenes, primero habilite el registro binario en las instancias de origen, importe los datos de los orígenes al clúster de Aurora MySQL y, a continuación, inicie la replicación desde cada origen mediante las coordenadas del registro binario o el posicionamiento automático de GTID.

importante

Todos los procedimientos almacenados de replicación de varios orígenes deben invocarse mientras se está conectado a la instancia de escritura del clúster de base de datos de Aurora MySQL. Si se produce una conmutación por error, debe volver a conectarse a la nueva instancia de escritura.

Paso 1: importación de datos de las instancias de base de datos de origen al clúster de Aurora MySQL

Realice los siguientes pasos para cada instancia de base de datos de origen.

1. Determine el archivo de registro binario actual y su posición en la instancia de base de datos de origen.

   Para MySQL 8.4

   SHOW BINARY LOG STATUS;

   Para MySQL 8.0 y versiones anteriores

   SHOW MASTER STATUS;

   Ejemplo de código de salida:

   +----------------------------+----------+
   | File                       | Position |
   +----------------------------+----------+
   | mysql-bin-changelog.000031 |      107 |
   +----------------------------+----------+

   Registre los valores File y Position. Los necesitará en un paso posterior.

2. Copie la base de datos de la instancia de base de datos de origen en el clúster de Aurora MySQL mediante mysqldump.

   mysqldump --databases database_name \
     --single-transaction \
     --compress \
     --order-by-primary \
     -u RDS_user_name \
     -p'RDS_password' \
     --host=source-endpoint.region.rds.amazonaws.com | mysql \
     --host=aurora-cluster-endpoint.cluster-xxxxxx.region.rds.amazonaws.com \
     --port=3306 \
     -u aurora_user_name \
     -p'aurora_password'

   sugerencia

   En el caso de bases de datos grandes, considere la posibilidad de utilizar AWS DMS o crear una instantánea y restaurarla para reducir el tiempo de transferencia de datos.

3. Una vez finalizada la importación de datos, puede volver a habilitar las escrituras en la instancia de base de datos de origen si anteriormente la había configurado como de solo lectura.

Paso 2: inicio de la replicación desde las instancias de base de datos de origen al clúster de Aurora MySQL

Para cada instancia de base de datos de origen, conéctese a la instancia de escritura del clúster de base de datos de Aurora MySQL y ejecute los procedimientos almacenados para configurar e iniciar la replicación en un canal.

Opción A: Uso de la posición del archivo de registro binario

CALL mysql.rds_set_external_source_for_channel(
  'source-endpoint.region.rds.amazonaws.com',
  3306,
  'repl_user',
  'password',
  'mysql-bin-changelog.000031',
  107,
  0,
  'channel_1'
);

CALL mysql.rds_start_replication_for_channel('channel_1');

Opción B: Uso del posicionamiento automático de GTID

Si las instancias de base de datos de origen utilizan la replicación basada en GTID, puede utilizar el posicionamiento automático en lugar de especificar las coordenadas del registro binario:

CALL mysql.rds_set_external_source_with_auto_position_for_channel(
  'source-endpoint.region.rds.amazonaws.com',
  3306,
  'repl_user',
  'password',
  0,
  0,
  'channel_1'
);

CALL mysql.rds_start_replication_for_channel('channel_1');

nota

Cuando utilice el posicionamiento automático de GTID, asegúrese de que los parámetros gtid_mode y enforce_gtid_consistency estén configurados de forma coherente en todas las instancias de origen y en el clúster de Aurora MySQL.

Repita estos pasos para cada instancia de base de datos de origen y especifique un nombre de canal único para cada una (por ejemplo, channel_1, channel_2, channel_3).

Uso de filtros con la replicación de varios orígenes

Puede utilizar filtros de replicación para especificar qué bases de datos y tablas se replican en la réplica de varios orígenes de Aurora MySQL. Para obtener más información sobre los filtros de replicación, consulte Configuración de filtros de replicación con Aurora MySQL. A continuación, se describen las capacidades adicionales de filtrado por canal disponibles con la replicación de varios orígenes.

Con la replicación de varios orígenes, puede configurar los filtros de replicación en dos niveles:

• Filtros globales: se aplican a todos los canales. Se configura mediante el grupo de parámetros del clúster de base de datos de Aurora MySQL (por ejemplo, replicate-do-db, replicate-ignore-db).

• Filtros por canal: se aplican solo a canales específicos e invalidan los filtros globales de ese canal.

Comportamiento de clave

• Debe reiniciar la replicación después de cambiar los filtros por canal.

• Si no se ha configurado ningún filtro específico para el canal, Aurora MySQL aplica los filtros globales para ese canal.

• Si un filtro se aplica globalmente y por canal, solo se aplica el filtro por canal para ese canal.

Supervisión de canales de replicación de varios orígenes

Puede supervisar canales individuales en una réplica de varios orígenes de Aurora MySQL mediante los siguientes métodos.

Uso de SHOW REPLICA STATUS

Conéctese a la instancia de escritura del clúster de base de datos de Aurora MySQL y ejecute:

-- View status for all channels
SHOW REPLICA STATUS\G

-- View status for a specific channel
SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G

Campos de clave que se deben supervisar:

Campo	Descripción
Replica_IO_Running	Si el subproceso de E/S del canal se está ejecutando
Replica_SQL_Running	Si el subproceso de SQL del canal se está ejecutando
Seconds_Behind_Source	Retraso de replicación en segundos para el canal
Last_IO_Error	Último error de E/S detectado en el canal
Last_SQL_Error	Último error de SQL detectado en el canal
Source_Log_File	El archivo de registro binario actual que se está leyendo desde el origen
Exec_Source_Log_Pos	La posición en el registro binario que ha aplicado el subproceso de SQL

Uso de métricas de CloudWatch

Supervise la métrica ReplicationChannelLag de CloudWatch para cada canal de replicación. Esta métrica proporciona datos sobre el retraso de replicación por canal con un periodo de 60 segundos y está disponible durante 15 días. Para localizar el retraso del canal de replicación, utilice el identificador de instancia del clúster de base de datos de Aurora y el nombre del canal de replicación como dimensiones. Puede configurar alarmas de CloudWatch para recibir notificaciones cuando el retraso supere un umbral específico. Para obtener más información, consulte Supervisión de métricas en un clúster de Amazon Aurora.

Administración de procedimientos almacenados de replicación de varios orígenes

Para obtener información sobre el uso de procedimientos almacenados para configurar y administrar los canales de replicación de varios orígenes, consulte Administración de la replicación de varios orígenes.

Consideraciones y prácticas recomendadas

Para obtener recomendaciones generales de optimización de la replicación, incluido el formato de registro binario, los trabajadores paralelos y binlog mejorado, consulte Optimización de la replicación de registros binarios para Aurora MySQL. Las siguientes consideraciones son específicas de la replicación de varios orígenes.

Planificación de recursos

Cuando se ejecutan varios canales de replicación, el número total de subprocesos de replicación asignados a la réplica es: (replica_parallel_workers + 1 subproceso coordinador) × número de canales. Por ejemplo, con el valor predeterminado de replica_parallel_workers de 4 y 10 canales, Aurora MySQL asigna 50 subprocesos de replicación. Considere la posibilidad de utilizar una clase de instancia de base de datos más grande (como db.r6g.2xlarge o posteriores) en función del rendimiento total del origen y del número de canales. Cada canal recibe el mismo número de trabajadores paralelos. MySQL no admite la configuración de diferentes recuentos de trabajadores paralelos por canal.

Evitar conflictos

La replicación de varios orígenes de MySQL no permite detectar ni resolver conflictos. Debe asegurarse de que los cambios de diferentes orígenes no sean conflictivos. Las estrategias habituales incluyen lo siguiente:

• Cada origen escribe en una base de datos o conjunto de tablas diferente.

• Utilice filtros de replicación (replicate-do-db) para garantizar que cada canal replique solo las bases de datos de las que es responsable.

• Utilice la opción replicate-rewrite-db para reasignar un nombre de esquema del origen a un nombre diferente en la réplica, si es necesario.

Para evitar escrituras conflictivas desde las aplicaciones que se conectan directamente a la réplica de varios orígenes, habilite el modo de solo lectura en el clúster de Aurora MySQL: CALL mysql.rds_set_read_only(1);

Prácticas operativas recomendadas

• Un canal a la vez: realice operaciones de administración (como cambios de configuración, omisión de errores o inicio/detención de la replicación) en un canal a la vez. Evite los cambios simultáneos en varios canales desde conexiones diferentes.

• Supervise el retraso por canal: supervise el retraso de replicación de cada canal mediante la métrica de ReplicationChannelLag CloudWatch.

• Gestión de la conmutación por error de origen: si una instancia de base de datos de origen conmuta por error (por ejemplo, una conmutación por error de Amazon RDS Multi-AZ), es posible que el canal de replicación se detenga y se produzca un error de E/S. Cuando el origen vuelva a estar disponible:

  • Llame a mysql.rds_start_replication_for_channel para reanudar la replicación.

  • Si se produce el error 1236 (no se encuentra el archivo de registro), llame a mysql.rds_next_source_log_for_channel para pasar al siguiente archivo de registro binario.

• Conmutación por error de escritura de Aurora: si la instancia de escritura de Aurora MySQL se conmuta por error a un lector, las configuraciones del canal de replicación se conservan en el almacenamiento compartido del clúster. Una vez finalizada la conmutación por error, los subprocesos de replicación se reinician automáticamente en la nueva instancia de escritura.

Limitaciones

Las siguientes limitaciones son específicas de la replicación de varios orígenes de Aurora MySQL. Para obtener información sobre las limitaciones generales de la replicación de varios orígenes de MySQL (como la configuración de trabajadores paralelos por canal), consulte Replicación de varios orígenes de MySQL en la documentación de MySQL.

• La replicación de varios orígenes solo es compatible con Aurora MySQL versión 8.4.8 y posteriores.

• Aurora MySQL admite la configuración de un máximo de 15 canales para una réplica de varios orígenes.

Solución de problemas

Para solucionar problemas generales de replicación, consulte Problemas de reproducción de Amazon Aurora MySQL. A continuación, se muestran notas de solución de problemas específicas para la replicación de varios orígenes.

La configuración del canal no se restaura después de la restauración de la instantánea

Las instantáneas del clúster de base de datos no incluyen las configuraciones de canal de varios orígenes. Después de restaurar desde una instantánea:

• Vuelva a configurar cada canal mediante mysql.rds_set_external_source_for_channel o mysql.rds_set_external_source_with_auto_position_for_channel.

• Si utiliza el posicionamiento automático de GTID, la réplica puede reanudarse automáticamente desde donde lo dejó.

• Si utiliza las posiciones de los archivos de registro binarios, determine la posición actual comparando el registro binario del origen con la última transacción aplicada en el clúster restaurado.

El retraso de replicación aumenta en uno o más canales

• Compruebe las métricas de CPU y E/S de la instancia de escritura. Si la utilización de los recursos es alta, escale verticalmente la clase de instancia.

• Considere la posibilidad de aumentar replica_parallel_workers para mejorar el rendimiento de los subprocesos de SQL.

• Compruebe que no haya transacciones ni operaciones DDL de larga duración en el canal que puedan estar bloqueando el subproceso de SQL.

• Compruebe si hay configuraciones de filtro conflictivas que puedan provocar que la replicación procese y, a continuación, descarte una gran cantidad de eventos.

Ejemplo: configuración completa de varios orígenes con tres orígenes

En el siguiente ejemplo, se muestra la configuración de un clúster de base de datos de Aurora MySQL como una réplica de varios orígenes de tres instancias de origen de RDS para MySQL.

Paso 1: registro de las posiciones de los registros binarios en cada origen

Conéctese a cada origen y registre las coordenadas del registro binario:

-- On source 1 (orders-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000045, Position: 3892

-- On source 2 (inventory-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000012, Position: 1567

-- On source 3 (analytics-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000078, Position: 9421

Paso 2: importación de datos de cada origen

# Import from source 1
mysqldump --databases orders_db --single-transaction --compress \
 -u admin -p --host=orders-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

# Import from source 2
mysqldump --databases inventory_db --single-transaction --compress \
 -u admin -p --host=inventory-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

# Import from source 3
mysqldump --databases analytics_db --single-transaction --compress \
 -u admin -p --host=analytics-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

Paso 3: configuración e inicio de los canales de replicación

Conéctese a la instancia de escritura de Aurora MySQL:

-- Configure channel for source 1 (orders)
CALL mysql.rds_set_external_source_for_channel(
 'orders-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000045', 3892, 0, 'orders_channel'
);

-- Configure channel for source 2 (inventory)
CALL mysql.rds_set_external_source_for_channel(
 'inventory-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000012', 1567, 0, 'inventory_channel'
);

-- Configure channel for source 3 (analytics)
CALL mysql.rds_set_external_source_for_channel(
 'analytics-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000078', 9421, 0, 'analytics_channel'
);

-- Start all channels
CALL mysql.rds_start_replication_for_channel('orders_channel');
CALL mysql.rds_start_replication_for_channel('inventory_channel');
CALL mysql.rds_start_replication_for_channel('analytics_channel');

Paso 4: verificación del estado de la replicación

SHOW REPLICA STATUS\G

Confirme que para cada canal:

• Replica_IO_Running: Yes

• Replica_SQL_Running: Yes

• Seconds_Behind_Source: 0 (o un valor bajo)

Recursos relacionados

• Replicación de varios orígenes de MySQL: documentación de MySQL

• Replicación entre Aurora y MySQL o entre Aurora y otro clúster de base de datos de Aurora (replicación de registro binario): guía del usuario de Aurora

• Optimización de la replicación de registros binarios para Aurora MySQL: guía del usuario de Aurora

• Configuración de filtros de replicación con Aurora MySQL: guía del usuario de Aurora

• Uso de la replicación basada en GTID: guía del usuario de Aurora