Replicación de datos en Azure Database for MySQL con servidor flexible

  • Artículo

SE APLICA A: Azure Database for MySQL: servidor flexible

La replicación de datos de entrada permite sincronizar datos de una instancia externa de MySQL Server con la instancia de Azure Database for MySQL: servidor flexible. El servidor externo puede ser local, de máquinas virtuales, servidor único de Azure Database for MySQL o un servicio de base de datos hospedado por otros proveedores de nube. La replicación de datos de entrada se basa en la posición del archivo de registro binario (binlog) o en la replicación basada en GTID. Para obtener más información acerca de la replicación de binlog, consulte la Replicación de MySQL.

Nota:

La configuración de la replicación de datos de entrada para los servidores habilitados con alta disponibilidad solo se admite a través de la replicación basada en GTID.

Cuándo utilizar la replicación de datos de entrada

Los escenarios principales que se deben tener en cuenta para usar la replicación de datos de entrada son los siguientes:

  • Sincronización de datos híbrida: con la replicación de datos de entrada, se pueden mantener los datos sincronizados entre los servidores locales y el servidor flexible de Azure Database for MySQL. Esta sincronización ayuda a crear aplicaciones híbridas. Este método resulta atractivo cuando se tiene un servidor de base de datos local existente, pero quiere mover los datos a una región más cercana a los usuarios finales.
  • Sincronización de varias nubes: para soluciones de nube complejas, use la replicación de datos de entrada a fin de sincronizar datos entre el servidor flexible de Azure Database for MySQL y distintos proveedores de nube, incluidas las máquinas virtuales y los servicios de base de datos hospedados en dichas nubes.
  • Migración: los clientes pueden migrar en tiempo mínimo con herramientas de código abierto como MyDumper/MyLoader con la replicación de datos de entrada. Con la replicación de datos de entrada es posible realizar una migración total selectiva de la carga de producción desde la base de datos de origen a la de destino.

Para los escenarios de migración, use Azure Database Migration Service (DMS).

Limitaciones y consideraciones

Datos no replicados

La base de datos del sistema mysql del servidor de origen no se replica. Además, los cambios en las cuentas y en los permisos del servidor de origen no se replican. Si crea una cuenta en el servidor de origen y esta cuenta necesita acceder al servidor de réplica, cree manualmente la misma cuenta en el servidor de réplica. Para conocer las tablas de la base de datos del sistema, consulte el manual de MySQL.

La replicación de datos de entrada se admite en servidores habilitados para la alta disponibilidad

La compatibilidad con la replicación de datos de entrada para el servidor habilitado para alta disponibilidad (HA) solo está disponible a través de la replicación basada en GTID.

El procedimiento almacenado para la replicación mediante GTID está disponible en todos los servidores habilitados para la alta disponibilidad con el nombre mysql.az_replication_change_master_with_gtid.

Filtrar

El parámetro replicate_wild_ignore_table crea un filtro de replicación para tablas en el servidor de réplica. Para modificar este parámetro desde Azure Portal, vaya a la instancia de Azure Database for MySQL: servidor flexible usada como réplica y seleccione "Parámetros del servidor" para ver o editar el parámetro replicate_wild_ignore_table.

Requisitos

  • La versión del servidor de origen debe ser, al menos, MySQL 5.7.

  • Nuestra recomendación es tener la misma versión para las versiones de servidor de origen y réplica. Por ejemplo, ambas deben ser MySQL, versión 5.7 o ambas deben ser MySQL, versión 8.0.

  • Nuestra recomendación es tener una clave principal en cada tabla. Si tenemos una tabla sin clave principal, es posible que se produzca una ralentización de la replicación.

  • El servidor de origen debe usar el motor InnoDB de MySQL.

  • El usuario debe tener los permisos correctos para configurar el registro binario y crear usuarios en el servidor de origen.

  • Los archivos de registro binarios del servidor de origen no deben purgarse antes de que la réplica aplique esos cambios. Si el origen es Azure Database for MySQL: servidor flexible, consulte cómo configurar binlog_expire_logs_seconds para el servidor flexible o el servidor único.

  • Si el servidor de origen tiene SSL habilitado, asegúrese de que el certificado de entidad de certificación de SSL proporcionado para el dominio se haya incluido en el procedimiento almacenado mysql.az_replication_change_master. Consulte los ejemplos siguientes y el parámetro master_ssl_ca.

  • Asegúrese de que la máquina que hospeda el servidor de origen permite el tráfico entrante y saliente en el puerto 3306.

  • Con acceso público, asegúrese de que el servidor de origen tenga una dirección IP pública, que se pueda acceder públicamente al DNS y que el servidor de origen tenga un nombre de dominio completo (FQDN). Si tiene un punto de conexión privado y ha deshabilitado el acceso público, no se admite la replicación de datos entrantes

  • Con acceso privado (integración con red virtual), asegúrese de que el nombre del servidor de origen se pueda resolver y sea accesible desde la red virtual donde se ejecuta la instancia de Azure Database for MySQL: servidor flexible. (para más información, visite Resolución de nombres para recursos en redes virtuales de Azure).

Clave principal invisible generada

Para MySQL versión 8.0 y posteriores, las Claves principales invisibles generadas (GIPK) están habilitadas de forma predeterminada para todas las instancias de Azure Database for MySQL: servidor flexible. Los servidores MySQL 8.0+ agregan la columna invisible my_row_id a las tablas y una clave principal de esa columna, donde se crea la tabla InnoDB sin una clave principal explícita. Como se describe a continuación, cuando esta característica está habilitada puede afectar a algunos de los casos de uso de replicación de datos de entrada:

  • La replicación de datos falla con el error de replicación: "ERROR 1068 (42000): Múltiples claves primarias definidas" si el servidor de origen crea una clave primaria en la tabla sin clave primaria. Para la mitigación, ejecute el siguiente comando SQL, omita el error de replicación y reinicie la replicación de entrada de datos.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • La replicación de entrada de datos falla con el error de replicación: "ERROR 1075 (42000): definición de tabla incorrecta; solo puede haber una columna automática y debe definirse como una clave" si el servidor de origen agrega una columna de incremento automático como clave única. Para la mitigación, ejecute el siguiente comando SQL, establezca "sql_generate_invisible_primary_key" en DESACTIVADO, omita el error de replicación y reinicie la replicación de entrada de datos.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • La replicación de entrada de datos falla si el servidor de origen ejecuta cualquier otro SQL que no sea compatible cuando "sql_generate_invisible_primary_key" está ACTIVADO. Por ejemplo, cree una tabla de particiones. En tal caso, la mitigación es establecer "sql_generate_invisible_primary_key" en DESACTIVADO y reiniciar la replicación de entrada de datos.

Pasos siguientes