Partekatu honen bidez:

Réplicas de lectura en Azure Database for MySQL

  • Artikulua

SE APLICA A: Azure Database for MySQL: servidor único

Importante

El servidor único de Azure Database for MySQL está en proceso de retirada. Es muy recomendable actualizar al servidor flexible de Azure Database for MySQL. Para obtener más información sobre la migración al servidor flexible de Azure Database for MySQL, consulte ¿Qué sucede con el servidor único de Azure Database for MySQL?

La característica de réplica de lectura permite replicar datos de un servidor Azure Database for MySQL en un servidor de solo lectura. Puede crear hasta cinco réplicas desde el servidor de origen. Las réplicas se actualizan asincrónicamente mediante la tecnología de replicación basada en la posición de los archivos de registros binarios nativos (binlog) del motor de MySQL. Para obtener más información acerca de la replicación de binlog, consulte la Introducción a la replicación de binlog de MySQL.

Las réplicas son nuevos servidores que se administran de forma similar a los servidores de Azure Database for MySQL normales. En cada réplica de lectura, se le cobra por el proceso aprovisionado en núcleos virtuales y el almacenamiento aprovisionado en GB/mes.

Para más información sobre los problemas y las características de replicación de MySQL, consulte la documentación de replicación de 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.

Casos en los que utilizar las réplicas de lectura

La finalidad de la característica de réplica de lectura es ayudar a mejorar el rendimiento y la escala de las cargas de trabajo que conllevan un gran número de operaciones de lectura. Las cargas de trabajo de lectura se pueden aislar en las réplicas, mientras que las cargas de trabajo de escritura se pueden dirigir al origen.

Un caso habitual es que las cargas de trabajo de análisis e inteligencia empresarial utilicen la réplica de lectura como origen de datos para los informes.

Dado que las réplicas son de solo lectura, no reducen directamente las cargas de capacidad de escritura en el origen. Esta característica no está destinada a cargas de trabajo intensivas de escritura.

Esta característica de réplica de lectura utiliza la replicación asincrónica de MySQL. La característica no está diseñada para escenarios de replicación sincrónica. Habrá un retraso medible entre el origen y la réplica. Los datos de la réplica se vuelven finalmente coherentes con los datos del origen. Use esta característica con cargas de trabajo que puedan admitir este retraso.

Replicación entre regiones

Puede crear una réplica de lectura en una región distinta a la del servidor de origen. La replicación entre regiones puede ser útil para escenarios como el planeamiento de la recuperación ante desastres o la incorporación de datos más cerca de los usuarios.

Puede tener un servidor de origen en cualquier región de Azure Database for MySQL. Un servidor de origen puede tener una réplica en su región emparejada o en las regiones de réplica universales. En la imagen siguiente se muestran las regiones de réplica disponibles en función de la región de origen.

Regiones de réplica universal

Puede crear una réplica de lectura en cualquiera de las siguientes regiones, con independencia de dónde se encuentre el servidor de origen. Entre las regiones de réplica universales admitidas se incluyen:

Region Disponibilidad de la réplica
Este de Australia ✔️
Sudeste de Australia ✔️
Sur de Brasil ✔️
Centro de Canadá ✔️
Este de Canadá ✔️
Centro de EE. UU. ✔️
Este de EE. UU. ✔️
Este de EE. UU. 2 ✔️
Este de Asia ✔️
Japón Oriental ✔️
Japón Occidental ✔️
Centro de Corea del Sur ✔️
Corea del Sur ✔️
Norte de Europa ✔️
Centro-Norte de EE. UU ✔️
Centro-sur de EE. UU. ✔️
Sudeste de Asia ✔️
Norte de Suiza ✔️
Sur de Reino Unido 2 ✔️
Oeste de Reino Unido ✔️
Centro-Oeste de EE. UU. ✔️
Oeste de EE. UU. ✔️
Oeste de EE. UU. 2 ✔️
Oeste de Europa ✔️
Centro de la India* ✔️
Centro de Francia* ✔️
Norte de Emiratos Árabes Unidos* ✔️
Norte de Sudáfrica* ✔️

Nota:

*Regiones donde Azure Database for MySQL tiene Almacenamiento de uso general v2 en la versión preliminar pública.
*Para estas regiones de Azure, tendrá la opción de crear un servidor en Almacenamiento de uso general v1 y v2. En el caso de los servidores creados con Almacenamiento de uso general v2 en versión preliminar pública, solo podrá crear un servidor de réplica solo en las regiones de Azure que admiten dicha versión.

Regiones emparejadas

Además de las regiones de réplica universales, puede crear una réplica de lectura en la región emparejada de Azure del servidor de origen. Si no conoce el par de la región, puede obtener más información en el artículo sobre regiones emparejadas de Azure.

Si usa réplicas entre regiones para planear la recuperación ante desastres, se recomienda que cree la réplica en la región emparejada en lugar de en una de las otras regiones. Las regiones emparejadas evitan actualizaciones simultáneas y priorizan el aislamiento físico y la residencia de datos.

Sin embargo, existen limitaciones que deben considerarse:

  • Disponibilidad regional: Azure Database for MySQL está disponible en el Centro de Francia, Norte de Emiratos Árabes Unidos y Centro de Alemania. Sin embargo, sus regiones emparejadas no están disponibles.

  • Pares unidireccionales: Algunas regiones de Azure se emparejan solo en una dirección. Estas regiones incluyen Oeste de la India, Sur de Brasil y US Gov Virginia. Esto significa que un servidor de origen del Oeste de la India puede crear una réplica en el Sur de la India. Sin embargo, un servidor de origen del Sur de la India no puede crear una réplica en el Oeste de la India. Esto es debido a que la región secundaria del Oeste de la India es Sur de la India, pero la región secundaria de esta última no es Oeste de la India.

Creación de una réplica

Importante

  • La característica de réplica de lectura solo está disponible para servidores de Azure Database for MySQL en los planes de tarifa De uso general u Optimizada para memoria. Asegúrese de que el servidor de origen esté en uno de estos planes de tarifa.
  • Si el servidor de origen no tiene servidores de réplica existentes, es posible que el servidor de origen necesite reiniciarse para prepararse para la replicación en función del almacenamiento usado (v1/v2). Considere la posibilidad de reiniciar el servidor y realizar esta operación durante las horas de menos actividad. Consulte Reinicio del servidor de origen para obtener más detalles.

Cuando se inicia el flujo de trabajo de creación de la réplica, se crea un servidor Azure Database for MySQL en blanco. El nuevo servidor se rellena con los datos que estaban en el servidor de origen. El tiempo de creación depende de la cantidad de datos en el origen y del tiempo transcurrido desde la última copia de seguridad completa semanal. Puede oscilar desde unos minutos hasta varias horas. El servidor de réplica siempre se crea en el mismo grupo de recursos y en la misma suscripción que el servidor de origen. Si desea crear un servidor réplica en otro grupo de recursos o en una suscripción diferente, puede mover el servidor réplica después de la creación.

Cada réplica se habilita para el crecimiento automático del almacenamiento. La característica de crecimiento automático permite a la réplica mantenerse al día con los datos replicados en ella y evitar una interrupción en la replicación causada por errores de almacenamiento insuficiente.

Aprenda a crear una réplica de lectura en Azure Portal.

Conexión a una réplica

Durante la creación, una réplica hereda las reglas de firewall del servidor de origen. Posteriormente, estas reglas son independientes del servidor de origen.

La réplica hereda la cuenta de administrador del servidor de origen. Todas las cuentas de usuario del servidor de origen se replican en las réplicas de lectura. Solo se puede conectar a una réplica de lectura utilizando las cuentas de usuario disponibles en el servidor de origen.

Puede conectarse a la réplica mediante su nombre de host y una cuenta de usuario válida, igual que haría en un servidor Azure Database for MySQL normal. En un servidor denominado myreplica con el nombre de usuario administrador myadmin, puede conectarse a la réplica mediante la CLI de mysql:

mysql -h myreplica.mysql.database.azure.com -u myadmin@myreplica -p

Cuando se le solicite, escriba la contraseña de la cuenta de usuario.

Supervisión de la replicación

Azure Database for MySQL proporciona la métrica de retraso de replicación en segundos en Azure Monitor. Esta métrica está disponible únicamente para las réplicas. Esta métrica se calcula utilizando la métrica seconds_behind_master disponible en el comando SHOW SLAVE STATUS de MySQL. Establezca una alerta que le informe cuando el retraso de replicación alcance un valor que no sea aceptable para la carga de trabajo.

Si ve un mayor retraso en la replicación, consulte Solución de problemas de latencia de replicación para solucionar problemas y comprender las causas posibles.

Detención replicación

Puede detener la replicación entre un servidor de origen y una réplica. Una vez que se ha detenido la replicación entre un servidor de origen y una réplica de lectura, la réplica se convierte en un servidor independiente. Los datos del servidor independiente son los datos que estaban disponibles en la réplica en el momento en que se inició el comando para detener la replicación. El servidor independiente no alcanza al servidor de origen.

Si decide detener la replicación en una réplica, perderá todos los vínculos con su servidor de origen anterior y otras réplicas. No se produce ninguna conmutación por error automatizada entre un origen y su réplica.

Importante

Este servidor independiente no puede volver a convertirse en una réplica. Asegúrese de que la réplica tenga todos los datos que necesita antes de detener la replicación en una réplica de lectura.

Aprenda a detener la replicación en una réplica.

Conmutación por error

No se produce ninguna conmutación por error automatizada entre el origen y los servidores de réplica.

Dado que la replicación es asincrónica, se produce un desfase entre el origen y la réplica. La cantidad de desfase puede verse afectada por muchos factores, como lo pesada que sea la carga de trabajo que se ejecuta en el servidor de origen y la latencia entre los centros de datos. En la mayoría de los casos, el retraso de la réplica oscila entre unos segundos y un par de minutos. Puede realizar un seguimiento del retraso real de la replicación mediante la métrica Replica Lag (Retraso de réplica), que está disponible para cada réplica. Esta métrica muestra el tiempo desde la última transacción reproducida. Se recomienda que observe el retraso de la réplica durante un período de tiempo para identificar el retraso medio. Puede establecer una alerta sobre el retraso de la réplica, para que si se sale del intervalo esperado, puede tomar medidas.

Sugerencia

Si realiza la conmutación por error a la réplica, el retraso en el momento de desvincular la réplica del origen indicará la cantidad de datos perdidos.

Cuando haya decidido que quiere conmutar por error a una réplica, realice estos pasos:

  1. Detenga la replicación en la réplica.
    Este paso es necesario para que el servidor de la réplica pueda aceptar escrituras. Como parte de este proceso, el servidor de réplica se desvinculará del origen. Una vez iniciada la detención de la replicación, el proceso de back-end suele tardar aproximadamente dos minutos en completarse. Consulte la sección Detención de la replicación de este artículo para conocer las implicaciones de esta acción.

  2. Haga que la replicación apunte a la réplica (anterior).
    Cada servidor tiene una cadena de conexión única. Actualice la aplicación para que apunte a la réplica (anterior) en lugar de al origen.

Una vez que la aplicación procesa correctamente las lecturas y las escrituras, ya está completa la conmutación por error. La cantidad de tiempo de inactividad que experimente su aplicación dependerá del momento en que se detecte una incidencia y se realicen los pasos 1 y 2 indicados anteriormente.

Identificador de transacción global (GTID)

El identificador de transacción global (GTID) es un identificador único que se crea con cada transacción confirmada en un servidor de origen y que está desactivado de forma predeterminada en Azure Database for MySQL. GTID se admite en las versiones 5.7 y 8.0, y solo en los servidores que admiten almacenamiento de hasta 16 TB (almacenamiento de uso general v2). Para más información sobre GTID y sobre cómo se usa en la replicación, consulte la documentación de la replicación con GTID de MySQL.

MySQL admite dos tipos de transacciones: Transacciones de GTID (identificadas con GTID) y transacciones anónimas (no tienen ningún GTID asignado)

Los siguientes parámetros de servidor se pueden usar para configurar GTID:

Parámetros de servidor Descripción Valor predeterminado Valores
gtid_mode Indica si se usan GTID para identificar transacciones. Los cambios de modo se deben realizar exclusivamente paso a paso y en orden ascendente (p. ej., OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) OFF OFF: tanto las transacciones nuevas como las de replicación deben ser anónimas
OFF_PERMISSIVE: las transacciones nuevas son anónimas. Las transacciones replicadas pueden ser transacciones de GTID o anónimas.
ON_PERMISSIVE: las transacciones nuevas son transacciones de GTID. Las transacciones replicadas pueden ser transacciones de GTID o anónimas.
ON: tanto las transacciones nuevas como las replicadas deben ser transacciones de GTID.
enforce_gtid_consistency Aplica la coherencia de GTID, ya que solo permite que se ejecuten las instrucciones que se pueden registrar de una manera transaccionalmente segura. Este valor debe establecerse en ON antes de habilitar la replicación de GTID. OFF OFF: a todas las transacciones se les permite infringir la coherencia de GTID.
ON: no se permite a ninguna transacción infringir la coherencia de GTID.
WARN: a todas las transacciones se les permite infringir la coherencia de GTID, pero se genera una advertencia.

Nota

  • Una vez habilitado GTID, no se puede volver a desactivar. Si necesita desactivar GTID, póngase en contacto con el servicio de soporte técnico.

  • Si desea cambiar los GTID de un valor a otro, solo puede hacerlo un paso cada vez en orden ascendente de modos. Por ejemplo, si gtid_mode está establecido en OFF_PERMISSIVE, es posible cambiar a ON_PERMISSIVE, pero no a ON.

  • Para mantener la coherencia de la replicación, no se puede actualizar en el caso de un servidor maestro o de réplica.

  • Se recomienda establecer enforce_gtid_consistency en ON antes de establecer gtid_mode=ON.

Para habilitar GTID y configurar el comportamiento de la coherencia, actualice los parámetros de servidor gtid_mode y enforce_gtid_consistency mediante Azure Portal, la CLI de Azure o PowerShell.

Si GTID está habilitado en un servidor de origen (gtid_mode = ON), las réplicas recién creadas también tendrán GTID habilitado y usarán la replicación de GTID. Para garantizar la coherencia de la replicación, gtid_mode no se puede cambiar una vez que se crean los servidores maestros o de réplica con GTID habilitado.

Consideraciones y limitaciones

Planes de tarifa

Actualmente, las réplicas de lectura solo están disponibles en los planes de tarifa de uso general y optimizados para memoria.

Nota

El costo de ejecutar el servidor de réplica se basa en la región en la que se ejecuta el servidor de réplica.

Reinicio del servidor de origen

El parámetro log_bin estará desactivado de forma predeterminada en el servidor que tenga un almacenamiento de uso general (v1). El valor se desactivará al crear la primera réplica de lectura. Si un servidor de origen no tiene ningún servidor de réplica de lectura existente, ese servidor se reiniciará primero a fin de prepararse para la replicación. Considere la posibilidad de reiniciar el servidor y realizar esta operación durante las horas de menos actividad.

El parámetro log_bin estará activado de manera predeterminada en el servidor de origen que tenga un almacenamiento de uso general (v2), y no es necesario reiniciarlo cuando se agrega una réplica de lectura.

Nuevas réplicas

Las réplicas de lectura se crean como nuevos servidores Azure Database for MySQL. Un servidor no puede volver a convertirse en una réplica. No se puede crear una réplica de otra réplica de lectura.

Configuración de réplicas

Las réplicas se crean con la misma configuración de servidor que el origen. Después de crear una réplica, se pueden cambiar varios valores independientemente del servidor de origen: generación de proceso, núcleos virtuales, almacenamiento y período de retención de copias de seguridad. El plan de tarifa también se puede cambiar de forma independiente, excepto si es con origen o destino en el nivel Básico.

Importante

Antes de actualizar la configuración de un servidor de origen con nuevos valores, actualice la configuración de las réplicas a valores iguales o mayores. Esta acción garantiza que la réplica puede hacer frente a los cambios realizados en el servidor de origen.

Las reglas de firewall y la configuración de parámetros se heredan del servidor de origen y van a la réplica cuando esta se crea. Después, las reglas de la réplica son independientes.

Réplicas detenidas

Si detiene la replicación entre un servidor de origen y una réplica de lectura, la réplica detenida se convierte en un servidor independiente que acepta operaciones de lectura y escritura. Este servidor independiente no puede volver a convertirse en una réplica.

Servidores independientes y de origen eliminados

Al eliminar un servidor de origen, la replicación se detiene en todas las réplicas de lectura. Estas réplicas se convierten automáticamente en servidores independientes y pueden aceptar operaciones de lectura y de escritura. El propio servidor de origen se elimina.

Cuentas de usuario

Los usuarios del servidor de origen se replican en las réplicas de lectura. Solo se puede conectar a una réplica de lectura utilizando las cuentas de usuario disponibles en el servidor de origen.

Parámetros del servidor

Para evitar que los datos dejen de estar sincronizados y evitar posibles pérdidas o daños en los datos, se bloquean algunos parámetros del servidor para que no se actualicen mientras se usan réplicas de lectura.

Los siguientes parámetros de servidor están bloqueados tanto en el servidor de origen como en los de réplica:

El parámetro event_scheduler está bloqueado en los servidores de réplica.

Para actualizar uno de los parámetros anteriores en el servidor de origen, elimine los servidores de réplica, actualice el valor del parámetro en el origen y vuelva a crear las réplicas.

GTID

GTID se admite en:

  • Las versiones 5.7 y 8.0 de MySQL.
  • Servidores que admiten almacenamiento de hasta 16 TB. Consulte el artículo sobre el plan de tarifa para ver la lista completa de las regiones que admiten el almacenamiento de 16 TB.

GTID está desactivado de forma predeterminada, Una vez habilitado GTID, no se puede volver a desactivar. Si tiene que desactivar GTID, póngase en contacto con el servicio de soporte técnico.

Si GTID está habilitado en un servidor de origen, las réplicas recién creadas también tendrán GTID habilitado y usarán la replicación de GTID. Para que la replicación se realice de forma consistente, no puede actualizar gtid_mode en los servidores de origen ni de réplica.

Otros

  • No permite crear réplicas de réplicas.
  • Las tablas en memoria pueden provocar que las réplicas dejen de sincronizarse. Esto es una limitación de la tecnología de replicación de MySQL. Puede obtener más información en la documentación de referencia de MySQL.
  • Asegúrese de que las tablas del servidor de origen tienen claves principales. La falta de claves principales puede generar una latencia en la replicación entre el origen y las réplicas.
  • Consulte la lista completa de las limitaciones de la replicación de MySQL en la documentación de MySQL.

Pasos siguientes