Compartir a través de

Configuración de la replicación de datos de entrada del servidor flexible de Azure Database for MySQL

  • Artículo

SE APLICA A: Azure Database for MySQL: servidor flexible

En este artículo se describe cómo configurar la replicación de datos de entrada en el servidor flexible de Azure Database for MySQL mediante la configuración de los servidores de origen y de réplica. En este artículo se asume que tiene alguna experiencia previa con servidores y bases de datos MySQL.

Nota

Este artículo contiene referencias al término esclavo, un término que Microsoft ya no usa. Cuando se elimine el término del software, se eliminará también de este artículo.

Para crear una réplica en la instancia de servidor flexible de Azure Database for MySQL, la replicación de datos de entrada sincroniza los datos que proceden de un servidor MySQL de origen local en máquinas virtuales (VM) o en servicios de base de datos en la nube. La replicación de datos de entrada se puede configurar mediante la replicación basada en posición del archivo de registro binario (binlog) O 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.

Revise las limitaciones y los requisitos de la replicación de datos de entrada antes de seguir los pasos de este artículo.

Creación de una instancia del servidor flexible de Azure Database for MySQL para usarla como réplica

  1. Cree una instancia del servidor flexible de Azure Database for MySQL (por ejemplo, replica.mysql.database.azure.com). Consulte Uso de Azure Portal para crear una instancia de servidor flexible de Azure Database for MySQL para la creación del servidor. Este servidor es el servidor de "réplica" para la replicación de datos de entrada.

  2. Cree las mismas cuentas de usuario y los privilegios correspondientes.

    Las cuentas de usuario no se replican desde el servidor de origen al servidor de réplica. Si planea proporcionar a los usuarios acceso al servidor de réplica, debe crear manualmente todas las cuentas y privilegios correspondientes en esta instancia de servidor flexible de Azure Database for MySQL recién creada.

Configuración del servidor MySQL

En los siguientes pasos se prepara y configura el servidor MySQL hospedado en el entorno local, en una máquina virtual o en un servicio de base de datos que se hospeda en otros proveedores de nube para la replicación de datos de entrada. Este servidor es el "origen" de la replicación de datos de entrada.

  1. Revise los requisitos del servidor de origen antes de continuar.

  2. Requisitos de red

    • Asegúrese de que el servidor de origen permite el tráfico entrante y saliente en el puerto 3306 y de que tiene una dirección IP pública, el DNS es accesible públicamente o tiene un nombre de dominio completo (FQDN).

    • Si el acceso privado (integración con red virtual) está en uso, asegúrese de que hay conectividad entre el servidor de origen y la red virtual en la que se hospeda el servidor de réplica.

    • Asegúrese de que proporcionamos conectividad sitio a sitio a sus servidores de origen locales mediante ExpressRoute o VPN. Para más información sobre la creación de una red virtual, consulte la documentación de Virtual Networky, especialmente, los artículos de inicio rápido con detalles paso a paso.

    • Si el acceso privado (integración con red virtual) se usa en el servidor de réplica y el origen es la máquina virtual de Azure, asegúrese de que se establece la conectividad de red virtual a red virtual. Se admite el emparejamiento entre redes virtuales. También puede usar otros métodos de conectividad para comunicarse entre redes virtuales de regiones distintas, como la conexión de red virtual a red virtual. Para más información, consulte Puerta de enlace de VPN de red virtual a red virtual.

    • Asegúrese de que las reglas del grupo de seguridad de red de la red virtual no bloquean el puerto de salida 3306 (que también es de entrada si MySQL se ejecuta en la máquina virtual de Azure). Para más información sobre el filtrado del tráfico con grupos de seguridad de red para redes virtuales, vea el artículo Filtrado del tráfico de red con grupos de seguridad de red.

    • Configure las reglas de firewall del servidor de origen para permitir la dirección IP del servidor de réplica.

  3. Siga los pasos adecuados en función de si quiere usar la posición bin-log o la replicación de datos basada en GTID.

    Compruebe si se ha habilitado el registro binario en el servidor de origen mediante la ejecución del comando siguiente:

    SHOW VARIABLES LIKE 'log_bin';

    Si la variable log_bin se devuelve con el valor "ON", el registro binario está habilitado en el servidor.

    Si se devuelve log_bin con el valor "OFF" y el servidor de origen se ejecuta de forma local o en máquinas virtuales en las que se puede tener acceso al archivo de configuración (my.cnf), puede seguir los siguientes pasos:

    1. Busque el archivo de configuración de MySQL (my.cnf) en el servidor de origen. Por ejemplo: /etc/my.cnf.

    2. Abra el archivo de configuración para editarlo y busque la sección mysqld.

    3. En la sección mysqld, agregue la línea siguiente:

      log-bin=mysql-bin.log

    4. Reinicie el servicio MySQL en el servidor de origen (o reinicie) para que los cambios surtan efecto.

    5. Una vez que se haya reiniciado el servidor, compruebe que el registro binario está habilitado mediante la ejecución de la misma consulta que antes:

      SHOW VARIABLES LIKE 'log_bin';

  4. Establezca la configuración del servidor de origen.

    La replicación de datos de entrada requiere el parámetro lower_case_table_names para ser coherente entre los servidores de origen y de réplica. De manera predeterminada, este parámetro es 1 en el servidor flexible de Azure Database for MySQL.

    SET GLOBAL lower_case_table_names = 1;

  5. Cree un nuevo rol de replicación y configure el permiso.

    Cree una cuenta de usuario en el servidor de origen que está configurado con privilegios de replicación. Esto puede realizarse a través de los comandos SQL o una herramienta como MySQL Workbench. Tenga en cuenta si planea replicar con SSL, ya que necesitará especificarse al crear el usuario. Consulte la documentación de MySQL para entender cómo agregar cuentas de usuario en el servidor de origen.

    En los comandos siguientes, el nuevo rol de replicación creado puede obtener acceso al origen desde cualquier máquina, no solo desde la máquina que hospeda al propio origen. Esto se hace especificando "syncuser@'%'" en el comando create user. Consulte la documentación de MySQL para más información acerca de la especificación de nombres de cuenta.

    Replicación con SSL

    Para requerir SSL a todas las conexiones de usuario, use el comando siguiente para crear un usuario:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;

    Replicación sin SSL

    Si SSL no es necesario para todas las conexiones, use el comando siguiente para crear un usuario:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';

  6. Establezca el servidor de origen en el modo de solo lectura.

    Antes de comenzar a volcar la base de datos, el servidor debe colocarse en modo de solo lectura. En modo de solo lectura, el servidor de origen no podrá procesar ninguna transacción de escritura. Evalúe el impacto para su negocio y la programación de la ventana de solo lectura en un momento de poco tráfico, si es necesario.

    FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;

  7. Obtenga el nombre del archivo de registro binario y el desplazamiento.

    Ejecute el comando show master status para determinar el nombre de archivo de registro binario actual y el desplazamiento.

    show master status;

    Los resultados deberían parecerse a los siguientes. Asegúrese de anotar el nombre del archivo binario, pues se utilizará en pasos posteriores.

    Resultados de estado del maestro

Volcado y restauración del servidor de origen

  1. Determine qué bases de datos y tablas quiere replicar en el servidor flexible de Azure Database for MySQL y realice el volcado de memoria desde el servidor de origen.

    Puede utilizar mysqldump para volcar bases de datos desde el servidor principal. Para más información, consulte Volcado y restauración. No es necesario volcar la biblioteca de MySQL y la biblioteca de prueba.

  2. Establezca el servidor de origen en modo de lectura/escritura.

    Cuando se haya volcado la base de datos, cambie el servidor MySQL de origen de nuevo al modo de lectura/escritura.

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

    Nota:

    Antes de que el servidor se vuelva a establecer en modo de lectura y escritura, puede recuperar la información de GTID mediante la variable global GTID_EXECUTED. Se usará en la fase posterior para establecer GTID en el servidor de réplica.

  3. Restaure el archivo de volcado en el nuevo servidor.

    Restaure el archivo de volcado en el servidor creado en el servidor flexible de Azure Database for MySQL. Consulte Volcado y restauración para saber cómo restaurar un archivo de volcado en un servidor MySQL. Si el archivo de volcado es grande, cárguelo a una máquina virtual en Azure dentro de la misma región que el servidor de réplica. Restáurelo en la instancia de servidor flexible de Azure Database for MySQL desde la máquina virtual.

Nota:

Si quiere evitar establecer la base de datos como de solo lectura al realizar un volcado o una recuperación, puede usar mydumper/myloader.

Establecer GTID en el servidor de réplica

  1. Omita el paso si usa la replicación basada en la posición de bin-log

  2. La información de GTID del archivo de volcado tomado del origen es necesaria para restablecer el historial de GTID del servidor de destino (réplica).

  3. Use esta información de GTID del origen para ejecutar el restablecimiento de GTID en el servidor de réplica usando el siguiente comando de la CLI:

    az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>

Para más detalles consulte Restablecimiento de GTID.

Nota:

El restablecimiento de GTID no se puede realizar en un servidor habilitado para copia de seguridad con redundancia geográfica. Deshabilite la redundancia geográfica para realizar el restablecimiento de GTID en el servidor. Puede volver a habilitar la opción de redundancia geográfica después del restablecimiento de GTID. La acción de restablecimiento de GTID invalida todas las copias de seguridad disponibles y, por lo tanto, una vez habilitada la redundancia geográfica de nuevo, puede tardar un día antes de que se pueda realizar la restauración geográfica en el servidor

  1. Establezca el servidor de origen.

    Todas las funciones de la replicación de datos de entrada se realizan mediante los procedimientos almacenados. Puede encontrar todos los procedimientos en Procedimientos almacenados de replicación de datos de entrada. Los procedimientos almacenados se pueden ejecutar en el shell de MySQL o en MySQL Workbench.

    Para vincular dos servidores e iniciar la replicación, inicie sesión en el servidor de réplica de destino en el servicio Azure Database for MySQL y establezca la instancia externa como servidor de origen. Esto se realiza mediante el procedimiento almacenado mysql.az_replication_change_master o mysql.az_replication_change_master_with_gtid en el servidor Azure Database for MySQL.

    CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');

    CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>,'<master_ssl_ca>');
    • master_host: nombre de host del servidor de origen
    • master_user: nombre de usuario para el servidor de origen
    • master_password: contraseña para el servidor de origen
    • master_port: número de puerto en el que el servidor de origen escucha las conexiones (3306 es el puerto predeterminado en el que escucha MySQL).
    • master_log_file: nombre del archivo de registro binario procedente de la ejecución de show master status
    • master_log_pos: posición del registro binario procedente de la ejecución de show master status
    • master_ssl_ca: contexto del certificado de entidad de certificación. Si no usa SSL, pase una cadena vacía.

    Se recomienda pasar este parámetro como una variable. Para obtener más información, visite los ejemplos siguientes:

    Nota

    • Si el servidor de origen se hospeda en una máquina virtual de Azure, establezca la opción "Permitir el acceso a servicios de Azure" en "Activado" para permitir que los servidores de origen y de réplica se comuniquen entre sí. Esta configuración se puede cambiar desde las opciones de seguridad de conexión. Para más información, consulte Administración de reglas de firewall mediante el portal.
    • Si usó mydumper/myloader para realizar un volcado de la base de datos, puede obtener master_log_file y master_log_pos del archivo /backup/metadata.

    Ejemplos

    Replicación con SSL

    La variable @cert se crea mediante la ejecución de los siguientes comandos de MySQL:

    SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE'`S CONTEXT HERE
-----END CERTIFICATE-----'

    La replicación con SSL se configura entre un servidor de origen hospedado en el dominio "companya.com" y un servidor de réplica hospedado en el servidor flexible de Azure Database for MySQL. Este procedimiento almacenado se ejecuta en la réplica.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @cert);

    Replicación sin SSL

    La replicación sin SSL se configura entre un servidor de origen hospedado en el dominio "companya.com" y un servidor de réplica hospedado en el servidor flexible de Azure Database for MySQL. Este procedimiento almacenado se ejecuta en la réplica.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');

  2. Inicie la replicación.

    Llame al procedimiento almacenado mysql.az_replication_start para iniciar la replicación.

    CALL mysql.az_replication_start;

  3. Compruebe el estado de replicación.

    Llame al comando show slave status en el servidor de réplica para ver el estado de replicación.

    show slave status;

    Para conocer el estado correcto de la replicación, consulte las métricas de replicación: Estado de E/S de réplica y Estado de SQL de réplica en la página de supervisión.

    Si Seconds_Behind_Master es "0", la replicación funciona bien. Seconds_Behind_Master indica el tiempo de retraso de la réplica. Si el valor no es "0", significa que la réplica procesa actualizaciones.

Otros procedimientos almacenados útiles para las operaciones de la replicación de datos de entrada

Detención replicación

Para detener la replicación entre el servidor de origen y de réplica, use el siguiente procedimiento almacenado:

CALL mysql.az_replication_stop;

Eliminación de la relación de replicación

Para eliminar la relación entre el servidor de origen y de réplica, use el siguiente procedimiento almacenado:

CALL mysql.az_replication_remove_master;

Omisión de error de replicación

Para omitir un error de replicación y permitir que continúe la replicación, use el siguiente procedimiento almacenado:

CALL mysql.az_replication_skip_counter;

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

Mostrar los resultados del registro binario

Pasos siguientes