Información sobre la replicación en Cloud SQL

La replicación es la capacidad de crear copias de una instancia de Cloud SQL o de una base de datos local y de delegar trabajo en las copias.

Introducción

El motivo principal para usar la réplica es escalar el uso de los datos en una base de datos sin que el rendimiento se vea afectado.

Otros motivos:

  • Migrar datos entre regiones
  • Migrar datos entre plataformas
  • Migrar datos de una base de datos local a Cloud SQL

Además, se puede promocionar una réplica si la instancia original se daña.

Cuando se hace referencia a una instancia de Cloud SQL, la instancia que se replica se denomina instancia principal y las copias se denominan réplicas de lectura. La instancia principal y las réplicas de lectura residen en Cloud SQL.

Cuando se hace referencia a una base de datos local, el escenario de replicación se denomina replicación desde un servidor externo. En este caso, la base de datos que se replica es el servidor de la base de datos de origen. Las copias que residen en Cloud SQL se denominan réplicas de Cloud SQL. También hay una instancia que representa el servidor de la base de datos de origen en Cloud SQL, denominada instancia de representación de origen.

En un escenario de recuperación tras desastres, puedes promocionar una réplica para convertirla en una instancia principal. De esta forma, puedes usarla en lugar de una instancia que se encuentre en una región que esté sufriendo una interrupción. También puedes promover una réplica para sustituir una instancia dañada.

Cloud SQL admite los siguientes tipos de réplicas:

Si usas la aplicación de conectores, puedes obligar a que solo se usen el proxy de autenticación de Cloud SQL o los conectores de lenguaje de Cloud SQL para conectarse a las instancias de Cloud SQL. Con la aplicación de conectores, Cloud SQL rechaza las conexiones directas a la base de datos. No puedes crear réplicas de lectura de una instancia que tenga habilitada la aplicación de conectores. Del mismo modo, si una instancia tiene réplicas de lectura, no puedes habilitar la aplicación de conectores en ella.

También puedes usar Database Migration Service para replicar continuamente datos de un servidor de base de datos de origen a Cloud SQL.

Cloud SQL no admite la replicación entre dos servidores externos. Sin embargo, Cloud SQL admite la replicación basada en el identificador de transacción global (GTID). Los GTIDs identifican de forma única cada transacción en el servidor y en una configuración de replicación. Como cada transacción tiene un identificador único, el servidor MySQL puede hacer un seguimiento de las transacciones que ha ejecutado. Un GTID usa coordenadas absolutas, por lo que la réplica de una instancia de Cloud SQL puede apuntar a su instancia principal y no tienes que especificar un nombre de archivo para el registro binario ni una posición en la instrucción CHANGE MASTER. Hay menos errores con las réplicas y con la recuperación a un momento dado. Debido a estas ventajas, no puedes inhabilitar la replicación basada en GTID en Cloud SQL.

Réplicas de lectura

Usas una réplica de lectura para descargar el trabajo de una instancia de Cloud SQL. La réplica de lectura es una copia exacta de la instancia principal. Los datos y otros cambios de la instancia principal se actualizan casi en tiempo real en la réplica de lectura.

Las réplicas de lectura son de solo lectura, por lo que no puedes escribir en ellas. La réplica de lectura procesa las consultas, las solicitudes de lectura y el tráfico de analíticas, lo que reduce la carga de la instancia principal.

Puedes conectarte a una réplica directamente mediante su nombre de conexión y su dirección IP. Si te conectas a una réplica mediante una dirección IP privada, no es necesario que crees una conexión privada de VPC adicional para la réplica, ya que la conexión se hereda de la instancia principal.

Para obtener información sobre cómo crear una réplica de lectura, consulta el artículo Crear réplicas de lectura. Para obtener información sobre cómo gestionar una réplica de lectura, consulta el artículo Gestionar réplicas de lectura.

Como práctica recomendada, coloca las réplicas de lectura en una zona diferente a la de la instancia principal cuando uses la alta disponibilidad en la instancia principal. De esta forma, las réplicas de lectura siguen funcionando cuando la zona que contiene la instancia principal sufre una interrupción. Consulta la información general sobre la alta disponibilidad para obtener más información.

Seleccionar un tipo de máquina adecuado

Las réplicas de lectura pueden tener un número de vCPUs y una cantidad de memoria diferentes a los de la réplica principal. Debes monitorizar las métricas de tu instancia, como el uso de la CPU y la memoria, para asegurarte de que la instancia réplica tiene el tamaño adecuado para su carga de trabajo, sobre todo si es más pequeña que la instancia principal. Una instancia de réplica que sea demasiado pequeña es más propensa a tener un rendimiento deficiente, como eventos de falta de memoria (OOM) frecuentes.

Capacidad de almacenamiento en réplicas de lectura

Cuando se cambia el tamaño de una instancia principal, también se cambia el tamaño de todas sus réplicas de lectura, si es necesario, para que tengan al menos la misma capacidad de almacenamiento que la instancia principal actualizada.

Réplicas de lectura entre regiones

La replicación entre regiones te permite crear una réplica de lectura en una región diferente a la de la instancia principal. Las réplicas de lectura entre regiones se crean de la misma forma que las réplicas de la misma región.

Réplicas entre regiones:

  • Mejora el rendimiento de lectura haciendo que las réplicas estén disponibles más cerca de la región de tu aplicación.
  • Proporciona una función de recuperación tras desastres adicional para protegerte frente a un fallo regional.
  • Te permite migrar datos de una región a otra.

Consulta Promocionar réplicas para la migración regional o la recuperación tras fallos para obtener más información sobre las réplicas entre regiones.

Réplicas de lectura en cascada

La replicación en cascada te permite crear una réplica de lectura en otra réplica de lectura en la misma región o en otra. Los siguientes casos prácticos muestran cómo usar réplicas en cascada:

  • Recuperación tras fallos: puedes usar una jerarquía en cascada de réplicas de lectura para simular la topología de tu instancia principal y sus réplicas de lectura. Durante una interrupción, la réplica de lectura seleccionada se convierte en principal y las réplicas de lectura de la nueva principal siguen replicándose y están listas para usarse.
  • Mejoras del rendimiento: reduce la carga de la instancia principal descargando el trabajo de replicación en varias réplicas de lectura.
  • Escalar lecturas: puedes tener más réplicas para compartir la carga de lectura.
  • Reducción de costes: puede reducir los costes de red usando una sola réplica en cascada con replicación entre regiones en otras regiones.

Terminología

  • Réplica en cascada: réplica de lectura que puede tener su propia réplica.
  • Niveles: puede crear niveles de réplicas en una jerarquía de réplicas en cascada. Por ejemplo, si añades cuatro réplicas a una instancia, esas cuatro réplicas estarán al mismo nivel.
  • Instancias secundarias: varias réplicas que se replican desde la misma instancia principal. Los elementos del mismo nivel están en el mismo nivel de la jerarquía de réplicas. Una réplica puede tener oficialmente hasta ocho réplicas hermanas.
  • Réplica hoja: réplica de lectura que no tiene ninguna réplica propia. En una jerarquía de replicación multinivel, la réplica de hoja es el último nivel.
  • Promover: acción que convierte una réplica, en cualquier nivel de la jerarquía, en una instancia principal. Cuando se asciende, se conserva la jerarquía de réplicas en cascada de la réplica.

Configurar réplicas en cascada

Las réplicas en cascada te permiten añadir réplicas de lectura a cualquier réplica que ya tengas. Puedes añadir hasta cuatro niveles de réplicas, incluida la instancia principal. Cuando asciendes la réplica de la parte superior de una jerarquía de réplicas en cascada, se convierte en una instancia principal y sus réplicas en cascada siguen replicándose.

Para planificar tu configuración, debes tener un objetivo para lo que van a hacer las réplicas de lectura. En las dos secciones siguientes se describen las configuraciones para la recuperación ante desastres y la replicación multirregional.

Recuperación tras fallos

Para entender cómo te ayudan las réplicas en cascada a recuperarte rápidamente durante una interrupción, considera el siguiente escenario de replicación:

Configuración

Muestra una configuración de réplica en cascada con la réplica en cascada en otra región

interrupción | interrupción del servicio (depending on context)

Muestra una promoción o una réplica durante una interrupción

Promoción

Muestra la nueva instancia con réplicas.

Si quieres usar una instancia de la región B en una configuración de recuperación tras fallos y tienes lo siguiente:

  • Réplicas de la misma región conectadas a la instancia principal (réplica A)
  • Réplicas de otras regiones (réplica en cascada) conectadas a la principal.

Puedes crear réplicas de lectura en la réplica en cascada de la región B.

En la pestaña Interrupción del servicio, si hay una interrupción en la región A, la réplica en cascada se convierte en una instancia principal. Ya tiene réplicas de lectura, lo que reduce el objetivo de tiempo de recuperación (RTO).

En la pestaña Promocionar, verás que, cuando se promociona una réplica en cascada, sus réplicas también se promocionan y siguen replicándose en ella.

Replicación multirregional

Otro caso práctico de las réplicas en cascada es distribuir la capacidad de lectura a una segunda región de forma rentable. Se pueden crear réplicas en cascada C y D que se repliquen desde la réplica B. Los clientes pueden distribuir las consultas de lectura entre las réplicas B, C y D para reducir la carga de cada réplica. El coste del tráfico de red entre regiones solo se incurre una vez, desde la instancia principal hasta la réplica B. La replicación de B a C y D usa la transferencia de red en la región, que es gratuita.

Puedes crear una jerarquía de hasta cuatro instancias mediante réplicas en cascada para la replicación multirregión:

Principal A → Réplica B → Réplica C y Réplica D

Restricciones

  • No puedes eliminar una réplica que tenga réplicas. Para eliminar la réplica, debes empezar por las réplicas de hoja y avanzar hacia arriba en la jerarquía.
  • No se admite la dependencia de regiones circulares. Para que la réplica de una réplica en cascada esté en la misma región que la instancia principal, la réplica en cascada también debe estar en la misma región.

Réplicas de lectura externas

Las réplicas de lectura externas son instancias de MySQL externas que se replican desde una instancia principal de Cloud SQL. Por ejemplo, una instancia de MySQL que se ejecuta en Compute Engine se considera una instancia externa.

Las réplicas de lectura externas tienen las siguientes restricciones:

  • La instancia principal de la réplica externa no puede ser una réplica de lectura de Cloud SQL.
  • Es posible que no se pueda replicar en una instancia de MySQL alojada en otra plataforma en la nube. Consulta la documentación del otro proveedor. Por ejemplo, es obligatorio definir el campo de configuración replicate-ignore-db y no se admiten proveedores de la nube en los que no se permita. Consulta Configurar réplicas externas para ver otros campos de configuración obligatorios.
  • Si la replicación se interrumpe durante unas horas (por ejemplo, debido a una interrupción de la red o del servidor), la réplica se retrasa con respecto al principal. La réplica se pone al día cuando se vuelve a conectar a la principal y empieza a replicarse de nuevo. Sin embargo, si la replicación se interrumpe durante más tiempo del que se conservan los registros de replicación de Cloud SQL (siete copias de seguridad), debes eliminar la réplica y crear una nueva.
  • Los datos que fluyen de la réplica principal a la externa se cobran como transferencia de datos saliente. Consulta la página de precios de transferencia de datos de tu tipo de instancia de Cloud SQL.

  • Si creas una réplica de lectura externa para una instancia y solo permites que se utilicen el proxy de autenticación de Cloud SQL o los conectores de lenguaje de Cloud SQL para conectarse a una instancia que tenga configurado el acceso privado a servicios, debes añadir los intervalos de subred de la réplica a las redes autorizadas de la instancia principal. Debe configurar todos los intervalos como redes autorizadas de la instancia de Cloud SQL.

    gcloud

    Para definir la autorización de IP de una instancia para permitir el tráfico procedente de intervalos de direcciones IP de una réplica de lectura externa, usa el comando gcloud sql instances patch:

    gcloud sql instances patch \
--authorized-networks=IP_ADDRESS_RANGE_1/24,IP_ADDRESS_RANGE_2/24

    Sustituye IP_ADDRESS_RANGE_1 y IP_ADDRESS_RANGE_2 por los intervalos de direcciones IP de tu réplica de lectura externa.

    REST

    Antes de usar los datos de la solicitud, haz las siguientes sustituciones:

    • PROJECT_ID: el ID o el número de proyecto del Google Cloud proyecto que contiene la instancia
    • INSTANCE_NAME: el nombre de tu instancia de Cloud SQL
    • IP_ADDRESS_RANGE_1: el primer intervalo de direcciones IP de tu réplica de lectura externa
    • IP_ADDRESS_RANGE_2: el segundo intervalo de direcciones IP de tu réplica de lectura externa

    Método HTTP y URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Cuerpo JSON de la solicitud: 

    {
  "kind": "sql#instance",
  "name": INSTANCE_NAME,
  "project": PROJECT_ID,
  "settings": {
    "ipConfiguration": {
      "authorizedNetworks": [{"kind": "sql#aclEntry", "value": "IP_ADDRESS_RANGE_1/24"}, {"kind": "sql#aclEntry", "value": "IP_ADDRESS_RANGE_2/24"}]},
  "kind": "sql#settings"
  }
}

    Para enviar tu solicitud, despliega una de estas opciones:

    Deberías recibir una respuesta JSON similar a la siguiente:

    {
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Casos prácticos de replicación

Los siguientes casos prácticos se aplican a cada tipo de replicación.

Nombre Principal Réplica Beneficios y casos prácticos Más información
Réplica de lectura Instancia de Cloud SQL Instancia de Cloud SQL
  • Capacidad de lectura adicional
  • Objetivo de Analytics
Réplica de lectura entre regiones Instancia de Cloud SQL Instancia de Cloud SQL
  • Capacidad de lectura adicional
  • Objetivo de Analytics
  • Función adicional de recuperación tras desastres
  • Mejorar el rendimiento de lectura
  • Migrar datos entre regiones
Réplica de lectura externa Instancia de Cloud SQL independiente o principal Instancia de MySQL externa a Cloud SQL
  • Latencia reducida para conexiones externas
  • Objetivo de Analytics
  • Ruta de migración a otras plataformas
Replicación desde un servidor externo Instancia de MySQL externa a Cloud SQL Instancia de Cloud SQL para MySQL
  • Ruta de migración a Cloud SQL
  • Replicación de datos en Google Cloud
  • Objetivo de Analytics

Requisitos previos para crear una réplica de lectura

Para poder crear una réplica de lectura de una instancia principal de Cloud SQL, la instancia debe cumplir los siguientes requisitos:

  • Las copias de seguridad automáticas deben estar habilitadas.
  • El registro binario debe estar habilitado, lo que requiere que la recuperación a un momento dado también lo esté. Más información sobre el impacto de estos registros
  • Se debe haber creado al menos una copia de seguridad después de habilitar el registro binario.

Requisitos adicionales de la réplica externa:

  • La versión de MySQL de la réplica debe ser igual o superior a la versión de MySQL de la instancia principal. Más información
  • Por motivos de seguridad, debes configurar SSL/TLS en tu instancia principal. Más información
.

Impacto de habilitar el almacenamiento de registros binarios

Para habilitar el almacenamiento de registros binarios en la instancia principal y admitir réplicas de lectura, debes habilitar la recuperación a un momento dado. Las consecuencias son las siguientes:

  • Sobrecarga de rendimiento

    Cloud SQL usa la replicación basada en filas con las marcas de MySQL sync_binlog=1 y innodb_support_xa=true. Por lo tanto, se requiere un fsync de disco adicional para cada operación de escritura, lo que reduce el rendimiento.

  • Sobrecarga de almacenamiento

    El almacenamiento de los registros binarios se cobra a la misma tarifa que los datos normales. Los registros binarios se truncan automáticamente hasta la antigüedad de la copia de seguridad automática más antigua. Cloud SQL conserva las siete copias de seguridad automáticas más recientes y todas las copias de seguridad bajo demanda. El tamaño de los registros binarios y, por lo tanto, el importe cobrado, depende de la carga de trabajo. Por ejemplo, una carga de trabajo con muchas operaciones de escritura consume más espacio de registro binario que una carga de trabajo con muchas operaciones de lectura.

    Puedes ver el tamaño de los registros binarios con el comando de MySQL SHOW BINARY LOGS.

    Cuando se crean copias de seguridad, los registros se almacenan en la copia de seguridad junto con los datos.

Almacenamiento de registros binarios en réplicas de lectura

  • El registro binario se admite en instancias de réplica de lectura (solo en MySQL 5.7 y 8.0). Para habilitar el registro binario en una réplica, usa los mismos comandos de la API que en la instancia principal, pero con el nombre de la réplica en lugar del nombre de la instancia principal. Ten en cuenta que los términos enable binary logging y enable point-in-time recovery son intercambiables.

    La durabilidad del registro binario en la instancia réplica (pero no en la principal) se puede definir con la marca sync_binlog, que controla la frecuencia con la que el servidor MySQL sincroniza el registro binario en el disco.

    El almacenamiento de registros binarios se puede habilitar en una réplica aunque las copias de seguridad estén inhabilitadas en la instancia principal.

    Si una réplica que tiene este valor asignado se convierte en un servidor independiente, el ajuste se restablece al valor seguro 1 en el servidor independiente.

Facturación

  • Una réplica de lectura se cobra a la misma tarifa que una instancia estándar de Cloud SQL. No se cobra nada por la replicación de datos.
  • En el caso de las réplicas externas, los datos que fluyen de la réplica principal a la externa se cobran como transferencia de datos. Consulta la página de precios para ver los precios de transferencia de datos de tu tipo de instancia de Cloud SQL.
  • El precio de una réplica de lectura interregional es el mismo que el de crear una instancia de Cloud SQL en la región. Consulta los precios de las instancias de Cloud SQL y selecciona la región adecuada. Además del coste habitual asociado a la instancia, una réplica entre regiones incurre en cargos por transferencia de datos entre regiones por los registros de replicación enviados desde la instancia principal a la réplica, tal como se describe en la sección Precios del tráfico de salida de red.

Referencia rápida de las réplicas de lectura de Cloud SQL

Tema Debate
Copias de seguridad No puedes configurar copias de seguridad en la réplica.
Núcleos y memoria Las réplicas de lectura pueden usar un número de núcleos y una cantidad de memoria diferentes a los de la instancia principal.
Eliminar la instancia principal Para poder eliminar una instancia principal, debes convertir todas sus réplicas de lectura en instancias independientes o eliminarlas.
Eliminar la réplica Cuando eliminas una réplica, no afecta al estado de la instancia principal.
Inhabilitar el almacenamiento de registros binarios Para poder inhabilitar los registros binarios en una instancia principal, debes promover o eliminar todas sus réplicas de lectura.
Conmutación por error Una instancia principal solo puede conmutar por error a una réplica si esta es una réplica de recuperación ante desastres. Las réplicas de lectura no pueden conmutar por error de ninguna forma durante una interrupción.
Alta disponibilidad Las réplicas de lectura te permiten habilitar la alta disponibilidad en las réplicas.
Balanceo de carga Cloud SQL no ofrece equilibrio de carga entre réplicas. Puedes implementar el balanceo de carga en tu instancia de Cloud SQL. También puedes usar el agrupamiento de conexiones para distribuir las consultas entre las réplicas con tu configuración de equilibrio de carga y mejorar el rendimiento.
Ventanas de mantenimiento Las réplicas de lectura comparten ventanas de mantenimiento con la instancia principal. Las réplicas siguen la configuración de mantenimiento de la instancia principal, incluida la ventana de mantenimiento, la reprogramación y el periodo de mantenimiento denegado. Durante el mantenimiento, Cloud SQL actualiza primero todas las réplicas de lectura y, después, la instancia principal.
Varias réplicas de lectura Cloud SQL admite replicaciones en cascada. Por lo tanto, puedes crear hasta 10 réplicas de una sola instancia principal y crear réplicas de esas réplicas, hasta cuatro niveles, incluida la instancia principal.
Replicación paralela Para obtener información sobre cómo usar la replicación en paralelo para mejorar el rendimiento, consulta Configurar la replicación en paralelo.
IP privada Si te conectas a una réplica mediante una dirección IP privada, no es necesario que crees una conexión privada de VPC adicional para la réplica, ya que se hereda de la instancia principal.
Restaurar la instancia principal No puedes restaurar la instancia principal de una réplica mientras la réplica exista. Antes de restaurar una instancia a partir de una copia de seguridad o de realizar una recuperación a un momento dado en ella, debes promocionar o eliminar todas sus réplicas.
Ajustes Los ajustes de MySQL de la instancia principal se propagan a la réplica, incluido el cambio de la contraseña raíz y de la tabla de usuarios. Los cambios en la CPU y la memoria no se propagan a la réplica.
Detener una réplica No puedes stop una réplica. Puedes restart, delete o disable replication en ella, pero no puedes detenerla como harías con una instancia principal.
Actualizar una réplica Las réplicas de lectura pueden experimentar una actualización disruptiva en cualquier momento.
Tablas de usuarios No puedes hacer cambios en la réplica. Todos los cambios de usuario deben realizarse en la instancia principal.

Siguientes pasos