Configurar MySQL en Compute Engine

Compute Engine ofrece una gran variedad de tipos de instancias y opciones de almacenamiento para leer y escribir datos de tus bases de datos MySQL. Para asegurarte de que tu base de datos tiene el mejor rendimiento y coste para tus cargas de trabajo, te recomendamos que la ejecutes en productos de infraestructura como servicio (IaaS) de generaciones más recientes.

Las siguientes recomendaciones de configuración tienen en cuenta que las cargas de trabajo de MySQL se suelen usar en sistemas con muchas lecturas, como el procesamiento de transacciones online (OLTP) o la base de datos que respalda una aplicación web típica. También tienen en cuenta las opciones de configuración habituales, como usar la versión 8.0 o una posterior de MySQL y usar el motor de almacenamiento InnoDB. En el caso de las cargas de trabajo sensibles al rendimiento, es posible que tengas que ajustar las configuraciones. Te recomendamos que uses esta guía como punto de partida para tu implementación y que, después, hagas pruebas con tu carga de trabajo real para comprobar que tu configuración satisface tus necesidades.

Elige tu máquina virtual

En el caso de las cargas de trabajo de MySQL, recomendamos usar la última generación de familias de máquinas C y N, ya que incluyen configuraciones que funcionan bien en la mayoría de las configuraciones prácticas de MySQL. Para obtener una introducción a estas series de máquinas, consulta la siguiente Google Cloud entrada de blog. Estas familias de máquinas usan Titanium y se basan en generaciones recientes de procesadores Intel, AMD y Axion.

Céntrate en el rendimiento

Para las cargas de trabajo sensibles al rendimiento, como las bases de datos MySQL críticas para la empresa, te recomendamos las instancias C4 y C4A más recientes si están disponibles en tu región. Si no puedes acceder a ellas, las instancias C3 y C3D ofrecen un enfoque similar en el rendimiento.

Estas instancias ofrecen la latencia más baja y constante para las operaciones dependientes de la computación, e incluyen las siguientes funciones útiles para las cargas de trabajo centradas en el rendimiento:

  • Control de los eventos de mantenimiento del anfitrión con notificaciones anticipadas
  • Control del turbo de un solo núcleo para ofrecer un rendimiento más constante
  • Redes de nivel 1 para obtener más ancho de banda de red

Si usas una instancia C4A, C3 o C3D, también puedes usar unidades de estado sólido locales (SSD locales) para cumplir requisitos de rendimiento específicos.

Optimizar los costes

En cargas de trabajo en las que la prioridad principal sea optimizar los costes, como las bases de datos MySQL con niveles de tráfico de bajos a medios o las bases de datos que se usan en entornos de pruebas o desarrollo, te recomendamos que utilices las instancias N4 más recientes. Estas instancias usan la gestión dinámica de recursos de nueva generación de Compute Engine para optimizar el coste total y mantener un rendimiento sólido, sin las garantías que ofrecen C4, C4A, C3 y C3D. Para obtener más información, consulta Gestión dinámica de recursos de nueva generación.

Configurar el tamaño de una máquina virtual

Es importante que elijas el tamaño de VM adecuado para el nivel de rendimiento de MySQL que quieras conseguir.

Si quieres conseguir un alto rendimiento de transacciones de escritura por segundo (TPS), el factor principal que debes tener en cuenta es el almacenamiento en bloques. Para obtener más información, consulta la sección Configurar el almacenamiento en bloque, que se muestra más abajo en esta página.

Si quieres conseguir un rendimiento alto de consultas de lectura por segundo (CPS), te recomendamos que uses el espacio de almacenamiento intermedio basado en RAM de MySQL para almacenar en caché los datos activos y reducir los accesos al disco. Para maximizar estas ventajas, sigue estos pasos:

  • Elige un tamaño de VM que asegure que el conjunto de trabajo, o la cantidad total de datos que tu base de datos procesa a la vez, quepa en el grupo de búferes.
  • Ajusta el tamaño del grupo de búferes para que use la mayor parte de la RAM de la VM.

Para minimizar el coste de dimensionar tu VM de esta forma, te recomendamos que uses una VM con una proporción alta de RAM por CPU virtual (vCPU) para evitar pagar por vCPUs que no utilices.

Para conseguir un equilibrio ideal en la mayoría de las cargas de trabajo de MySQL, determina el conjunto de trabajo de tu carga de trabajo y, a continuación, elige el highmem tipo de instancia más pequeño que se ajuste a ese conjunto de trabajo en la RAM. Los tipos de instancias highmem tienen unos 8 GB de RAM por vCPU. De esta forma, tendrás suficiente memoria para almacenar en caché un conjunto de trabajo grande y, al mismo tiempo, suficiente CPU para gestionar una carga de consultas alta.

En el caso de las cargas de trabajo con conjuntos de trabajo grandes, pero con tasas de consultas bajas, puedes optimizar aún más el coste total si usas instancias N4 con tipos de máquinas personalizadas y memoria ampliada para aumentar la proporción de RAM por vCPU.

Configurar el ancho de banda de la red de una máquina virtual

En la mayoría de los casos prácticos de MySQL, puedes mantener los límites de ancho de banda de red predeterminados de tu instancia. Si esta opción se adapta a tus necesidades, no tienes que cambiar a la red Tier_1.

Configurar el almacenamiento en bloques

Google Cloud Hyperdisk es la única generación de almacenamiento en bloques duradero disponible para las familias de máquinas virtuales de Compute Engine recientes. Creemos que Hyperdisk Balanced es la opción más adecuada para la gran mayoría de las cargas de trabajo de MySQL. Para obtener más información sobre Hyperdisk, consulta la documentación de Hyperdisk.

Google Cloud Hyperdisk

Hyperdisk Balanced ofrece las siguientes funciones:

  • Latencia de unidad de estado sólido (SSD) a bajo coste
  • Configuraciones de alto rendimiento para las aplicaciones que lo necesiten
  • Durabilidad superior al 99,999% para protegerse frente al riesgo de fallos de hardware y corrupción de datos silenciosa en todo el sector
  • Cifrado de todos los datos de Hyperdisk en reposo con claves de cifrado gestionadas por Google o por el cliente

Seleccionar tu nivel de rendimiento

Con Hyperdisk Balanced, puedes seleccionar el nivel de rendimiento independientemente del tamaño del almacenamiento del disco, por lo que puedes optimizar el rendimiento de tu base de datos y pagar solo por los recursos de entrada/salida (E/S) que necesite tu carga de trabajo. Si el tamaño del grupo de búferes de una base de datos MySQL es mayor que su conjunto de trabajo, durante las operaciones en estado estable, puede atender casi todas las consultas de lectura desde el grupo de búferes, sin acceder al disco.

Para seleccionar un nivel de rendimiento para tu volumen de Hyperdisk, ten en cuenta tu carga de trabajo de escritura de MySQL, con especial énfasis en lo siguiente:

  • Acceso a los InnoDBregistros de rehacer
  • Actualizaciones posteriores de los archivos de datos e índices de InnoDB

Además de las operaciones en estado estable, los eventos de mantenimiento de la base de datos también pueden provocar picos en el rendimiento del disco. La frecuencia con la que se produce esta situación suele aumentar en función de la carga de trabajo de escritura de tu base de datos, por lo que es más probable que se produzca en situaciones como la recuperación tras un fallo mediante registros de rehacer o un sistema de copias de seguridad que se copia a sí mismo leyendo todos los cambios de la base de datos desde la última copia de seguridad.

Tamaño del disco

Hay tres estrategias habituales para determinar los límites de rendimiento de los discos:

  1. Usa la configuración predeterminada. Cada disco tiene al menos 3000 operaciones de entrada/salida por segundo (IOPS) y un rendimiento de 140 MiBps. Esto es suficiente para las cargas de trabajo básicas de MySQL y los volúmenes de arranque del sistema operativo. Si tu caso práctico supera este límite, puedes modificar el rendimiento de E/S aprovisionado bajo demanda sin detener tu carga de trabajo.
  2. Mide tu uso actual. Si tu base de datos ya se está ejecutando en otro entorno, registra sus IOPS y su rendimiento de disco con una granularidad de un minuto o menos. Cuando tenga datos de una o dos semanas, de forma que su conjunto de muestra incluya algunas fluctuaciones en la carga y eventos de mantenimiento normales, seleccione un valor de percentil alto de ese conjunto de datos y añada un pequeño margen para tener en cuenta el crecimiento orgánico o el uso inesperado.
  3. Calcula tus necesidades y modifícalas más adelante. Si no tienes una fuente de datos, es posible que tengas que estimar tus necesidades de rendimiento al principio y, después, ajustarlas más tras la implementación. Te recomendamos que proporciones un valor superior al que creas que vas a necesitar al principio para que tu carga de trabajo no tenga cuellos de botella en el rendimiento y, después, reduzcas el rendimiento aprovisionado para que se ajuste a tu carga de trabajo.

Aumentar el rendimiento del disco

Puedes aumentar el rendimiento de cada disco Hyperdisk Balanced hasta un máximo de 160.000 IOPS y 2400 MBps de capacidad de procesamiento. El tamaño de tu VM ayuda a determinar los límites de rendimiento máximo de Hyperdisk, por lo que, si quieres que Hyperdisk tenga un rendimiento muy alto, puede que tengas que aumentar el número de núcleos de tu VM. Si tus cargas de trabajo más exigentes necesitan un rendimiento de disco superior al que puede proporcionar un solo disco Hyperdisk Balanced, puedes usar uno de los siguientes métodos para combinar varios discos Hyperdisk Balanced:

  • Actualizar a Hyperdisk Extreme
  • Usa otro mecanismo de matriz redundante de discos independientes (RAID) de software, como mdadm.

A medida que escales tus bases de datos MySQL, podrás aumentar de forma dinámica la capacidad y el rendimiento de tus discos sin que haya periodos de inactividad. Esto ayuda al rendimiento de las cargas de trabajo de procesamiento analítico online (OLAP) que realizan combinaciones complejas de gran tamaño que no caben en la RAM y se almacenan en el disco. En casos excepcionales, las cargas de trabajo de MySQL que requieren una latencia de almacenamiento extremadamente baja y pueden tolerar la pérdida de datos pueden almacenar su conjunto de datos completo en SSD local. También puedes usar las siguientes soluciones híbridas para mejorar la latencia de lectura y limitar las reducciones de durabilidad:

  • Replica tu conjunto de datos entre un hiperdisco y un SSD local.
  • Usa un gestor de volúmenes para configurar un SSD local como caché de los datos almacenados en un hiperdisco subyacente.

Aprovechar las funciones adicionales de Hyperdisk

Hyperdisk también te ofrece las siguientes funciones, que pueden aumentar o simplificar los flujos de trabajo de alta disponibilidad y recuperación tras fallos locales:

Para obtener más información sobre cómo configurar estas funciones con MySQL para Compute Engine, consulta la sección Alta disponibilidad que se muestra más abajo en esta página.

SSD locales

Algunas familias de máquinas de Compute Engine te permiten usar SSDs locales en lugar de Hyperdisk. No se trata de un almacenamiento duradero, pero las cargas de trabajo de MySQL suelen usarlos para almacenar espacios de tablas temporales.

Para obtener información sobre cómo usar SSDs locales para escalar bases de datos MySQL, consulta la sección Cambio de tamaño dinámico de los discos, que se encuentra más abajo en esta página.

Funciones adicionales de Compute Engine

Puedes usar las siguientes funciones de Compute Engine para optimizar tu implementación de MySQL.

Cloud Monitoring

Para monitorizar el rendimiento de tu máquina virtual y el uso de los servicios de infraestructura, utiliza la consola deGoogle Cloud . En la página Instancias de VM, en la pestaña Observabilidad, puede monitorizar métricas relacionadas con el rendimiento, como el uso de la CPU y la memoria, el ancho de banda de la red y el rendimiento aprovisionado de sus instancias. Del mismo modo, en la página Discos, en la pestaña Observabilidad, puedes monitorizar el rendimiento y las IOPS de tus volúmenes de disco.

Para personalizar las métricas de rendimiento que ves, usa Cloud Monitoring para crear consultas. Puede seleccionar las métricas de rendimiento específicas que quiera ver de sus servicios de infraestructura. Para las métricas específicas de MySQL, Compute Engine ofrece un complemento de carga de trabajo de MySQL.

Prácticas recomendadas para configurar el sistema operativo

  • Utilice un sistema de archivos adecuado. Google se centra en optimizar los sistemas de archivos ext4 y XFS de Linux. Sin embargo, la mayoría de los sistemas de archivos son adecuados para usar con MySQL.
  • Desactiva las páginas enormes transparentes (THP) en la configuración de tu sistema operativo base. Para saber cómo desactivar THP, consulta la documentación de THP.
  • Si usas Linux, utiliza las marcas relatime y lazytime para la configuración de montaje del sistema de archivos. De esta forma, se reducen los costes de rendimiento asociados a la actualización de los valores atime, mtime y ctime de los archivos cuando se leen, se modifican o se cambian sus metadatos.

Prácticas recomendadas para configurar MySQL

Te recomendamos que utilices los siguientes ajustes de configuración para MySQL.

  • Usa una versión reciente de MySQL. Google se centra en optimizar MySQL para la versión 8.0 y posteriores.

  • Aumenta el tamaño del grupo de búferes. MySQL usa su grupo de búferes para mejorar el rendimiento de lectura almacenando datos en caché en la RAM, lo que reduce los accesos al disco. De forma predeterminada, el tamaño del grupo de búferes de MySQL es de 128 MiB, que es demasiado pequeño para la mayoría de los casos prácticos. Te recomendamos que aumentes el tamaño de innodb_buffer_pool_size para que sea mayor que el del conjunto de trabajo al que accede tu aplicación en la base de datos. Normalmente, se siguen estos pasos:

    1. Mide o estima el tamaño de tu conjunto de trabajo en una copia en ejecución de tu instancia de MySQL.
    2. Elige un tamaño y un tipo de máquina virtual con suficiente RAM para que quepa ese conjunto de trabajo.
    3. Configura el tamaño del grupo de búferes en la VM para que ocupe la mayor parte de la RAM disponible.

  • Activa el búfer de escritura doble. MySQL tiene un búfer de doble escritura que ayuda a protegerse contra las escrituras incompletas, un modo de fallo en el que una escritura que abarca varios bloques en el disco solo se puede confirmar parcialmente si se produce un fallo de hardware o de alimentación en medio de la escritura. Para disfrutar de esta protección, activa innodb_doublewrite.

  • Asigna el valor de innodb_flush_log_at_trx_commit a 1. De esta forma, las transacciones de escritura se conservan en el disco cuando se confirman.

  • Para reducir la sobrecarga del rendimiento, especifique un valor para innodb_flush_method. En la versión 8.0.14 de MySQL y versiones posteriores, asigna el valor O_DIRECT_NO_FSYNC a innodb_flush_method, que es el valor óptimo, pero solo está disponible en estas versiones. En las versiones de MySQL anteriores a la 8.0.14, asigna el valor O_DIRECT a innodb_flush_method.

  • En los casos de replicación de alta disponibilidad, asigne el valor 1 al atributo sync_binlog de la instancia de base de datos principal. MySQL usa su registro binario para comunicar los cambios de la base de datos principal a la secundaria, por lo que se asegura de que los registros binarios se confirmen en el momento de la confirmación de la transacción, con la menor latencia de replicación y el menor objetivo de punto de recuperación (RPO) posibles entre las bases de datos.

  • Cuando uses MySQL en familias de máquinas de la serie C, activa innodb_numa_interleave. De esta forma, el pool de búferes de MySQL puede aprovechar las políticas de acceso a memoria no uniforme (NUMA).

Cuándo desactivar el búfer de escritura doble

El búfer de escritura doble de MySQL, que protege frente a las escrituras incompletas, tiene una sobrecarga de rendimiento de hasta el 25% en las transacciones de escritura de MySQL, lo que podría afectar a la latencia de las transacciones. Google Cloud Hyperdisk también ofrece protección contra escrituras incompletas, por lo que, si usas MySQL para escribir directamente en un sistema de archivos ext4 que se ejecuta en Hyperdisk, puedes desactivar de forma segura el búfer de doble escritura.

Sin embargo, para que la protección contra escritura incompleta de Hyperdisk sea eficaz, debes configurar el sistema de archivos y otras capas de software intermedias entre la base de datos y el disco para evitar que se produzcan escrituras incompletas por encima de la capa del disco. En la siguiente lista se incluyen ejemplos de configuraciones que pueden introducir escrituras incompletas por encima de la capa de Hyperdisk:

  • Ejecutar la instancia de MySQL en contenedores, como Google Kubernetes Engine o Kubernetes autogestionado.
  • Almacenar tus archivos de MySQL en un sistema de archivos XFS, que no admite tamaños de bloque lo suficientemente grandes en la mayoría de las configuraciones del kernel de Linux.
  • Almacenar tus archivos de MySQL en una configuración de matriz redundante de discos independientes (RAID) que provoque la segmentación de discos, como mdadm en Linux o Espacios de almacenamiento y Espacios de almacenamiento directo en Windows.
  • Almacenar tus archivos de MySQL en un gestor de volúmenes, como Logical Volume Manager (LVM) para Linux o Espacios de almacenamiento y Espacios de almacenamiento directo para Windows.

  • Almacenar tus archivos de MySQL en Hyperdisk con unidad de estado sólido (SSD) local configurada como caché, como lvmcache, dm-cache o bcache para Linux o Espacios de almacenamiento para Windows.

  • Ejecutar tu instancia de MySQL en una VM mediante la virtualización anidada.

Aunque puedes configurar las opciones anteriores para que no introduzcan escrituras incompletas, no te recomendamos que desactives el búfer de doble escritura cuando las uses, ya que es difícil validar si una configuración determinada es segura.

(Opcional) Desactivar el búfer de escritura doble

Para desactivar el búfer de escritura doble, sigue estos pasos:

  1. En el sistema de archivos ext4, debes habilitar la función bigalloc y configurar el tamaño del clúster del sistema de archivos en 16 KiB o en un múltiplo de 16 KiB que sea una potencia de 2 mayor. De esta forma, se asegura de que el sistema de archivos no divida las escrituras de MySQL en operaciones de E/S independientes antes de enviarlas a Hyperdisk. Si no aumenta el límite o usa un valor inferior a 16 KiB, no se protegerá contra las escrituras incompletas. Por ejemplo, con un tamaño de clúster de 16 KiB, se configura en el momento de crear el sistema de archivos:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. Inhabilita innodb_doublewrite y define innodb_flush_method en O_DIRECT o O_DIRECT_NO_FSYNC (en función de tu versión de MySQL, tal como se ha descrito anteriormente).

Configurar la alta disponibilidad y una solución de copia de seguridad

Te recomendamos que protejas todas tus cargas de trabajo críticas de MySQL configurando soluciones de alta disponibilidad y de copia de seguridad. En ambos casos, los factores más importantes son los siguientes:

Las soluciones de alta disponibilidad suelen tener como objetivo un tiempo de inactividad y una pérdida de datos casi nulos, pero solo protegen frente a los fallos de la infraestructura. Las soluciones de copia de seguridad se centran en ventanas de RTO y RPO más largas, pero ofrecen cobertura para un conjunto más amplio de situaciones de fallo, como las siguientes:

  • Eliminación accidental de datos
  • Ataques de ransomware
  • Desastres naturales

Configurar la alta disponibilidad

Las funciones de alta disponibilidad usan la redundancia de almacenamiento y de computación para asegurarse de que tu base de datos MySQL tenga menos tiempo de inactividad en caso de fallo o interrupción del host, lo que permite que las aplicaciones cliente accedan a sus datos incluso cuando una instancia o una zona no estén disponibles.

MySQL permite la replicación en los siguientes modos:

  • Modo asíncrono. En el modo asíncrono, el elemento principal confirma las transacciones de escritura en cuanto se completan de forma local, por lo que, si se produce una interrupción en el elemento principal, se podría perder una pequeña cantidad de datos escritos recientemente durante la conmutación por error, ya que el RPO es casi cero, pero no es exactamente cero.
  • Modo semisíncrono. En el modo semisíncrono, la principal espera a que se confirme la transacción hasta que un número configurable de réplicas haya confirmado que ha recibido la transacción. De esta forma, se aumenta considerablemente la probabilidad de que no se pierdan datos durante una conmutación por error no planificada, ya que el RPO es prácticamente cero.

En ambos modos, el RTO se determina en función de la rapidez con la que las comprobaciones de estado hacen lo siguiente:

  1. Identifica una instancia fallida.
  2. Activa la conmutación por error.
  3. Notifica a los clientes que la instancia de conmutación por error es ahora la principal mediante el sistema de nombres de dominio (DNS) u otra forma de identificar el servidor de la base de datos.

En ambos modos de replicación, debes tener una instancia de conmutación por error a la que replicar. Puedes encontrar esa instancia en cualquiera de los siguientes lugares:

  • La misma zona en la que se encuentra la instancia principal
  • Una zona diferente de la región en la que se encuentra el elemento principal
  • Se encuentra en una región distinta a la principal

Para mantener la alta disponibilidad incluso durante las interrupciones zonales, te recomendamos la siguiente configuración:

  • Localiza tus instancias principal y de failover en zonas diferentes, independientemente de si están en la misma región o no.
  • Usa la replicación asíncrona. Esto se debe a que, si utilizas la replicación semisíncrona, ubicar las instancias principal y de failover en zonas independientes puede provocar una latencia alta en las confirmaciones de transacciones de escritura.
  • Si necesitas un RPO igual a cero, usa Hyperdisk Balanced High Availability, que te permite replicar de forma síncrona un disco en dos zonas de la misma región. Para obtener más información, consulta la guía de Google sobre cómo proporcionar servicios de alta disponibilidad con la alta disponibilidad de Hyperdisk. Cuando configures la alta disponibilidad de Hyperdisk Balanced, te recomendamos que lo integres con grupos de instancias gestionadas con estado para diagnosticar problemas de estado de las instancias y automatizar las acciones de recuperación.

Configurar un plan de copias de seguridad y de resiliencia de datos

Los planes de copias de seguridad y de resiliencia de datos ayudan a evitar la pérdida de datos durante fallos como la eliminación accidental de datos, los ataques de ransomware y los desastres naturales. También puedes usarlos como almacenamiento en frío para cumplir los requisitos de cumplimiento y auditoría. En el caso de MySQL, hay muchas metodologías de copia de seguridad entre las que elegir. Algunas actúan a nivel de base de datos y otras, a nivel de volumen de almacenamiento. Al seleccionar una metodología, debes tener en cuenta principalmente tus requisitos de RTO y RPO.

Crear copias de seguridad a nivel de base de datos

Para las copias de seguridad a nivel de base de datos, puedes usar las siguientes opciones que ofrece MySQL:

  • Copias de seguridad incrementales basadas en el registro binario, que crean volcados de datos lógicos. Entre ellas, se incluyen las siguientes:
  • Herramientas que gestionan el proceso de copia de seguridad, como MySQL Enterprise Backup.

Para obtener más información sobre las opciones de copia de seguridad a nivel de base de datos de MySQL, consulta Copia de seguridad y recuperación en la documentación de MySQL.

Para usar cualquiera de estas opciones, debes tener un sistema de almacenamiento secundario en el que copiar los datos de la copia de seguridad. Te recomendamos las siguientes herramientas:

Usar Hyperdisk para crear copias de seguridad y clonar a nivel de almacenamiento

Para las copias de seguridad a nivel de almacenamiento, te recomendamos que utilices los productos Hyperdisk para crear copias, clonar y capturar de otro modo una vista de un momento dado de tu base de datos MySQL. El RPO de este método depende de la frecuencia con la que hagas copias de tu base de datos, y el RTO depende de la solución específica que utilices.

Si la recuperación rápida es importante para ti y solo necesitas cobertura de copia de seguridad en una zona, te recomendamos que uses las instantáneas de Hyperdisk. Las capturas instantáneas registran los datos de forma incremental en un momento específico y pueden restaurarlos rápidamente en un nuevo volumen de Hyperdisk mediante la clonación de discos, lo que proporciona un tiempo de recuperación de minutos. Te permiten recuperar datos cuando el contenido de un disco se ha sobrescrito, eliminado o dañado, y están disponibles de forma local en la misma zona o región que el disco de origen. Para obtener más información, consulta Información sobre las capturas instantáneas.

En los casos de recuperación ante desastres, en los que los datos deben almacenarse con una redundancia mayor que la del disco original y en una ubicación independiente para asegurarse de que un único desastre no afecte a todas las réplicas de los datos, te recomendamos que uses las instantáneas de disco estándar y de archivo de Hyperdisk. Las capturas de disco estándar y de archivo crean una copia de los datos del disco en un momento dado y la almacenan con una alta redundancia en un formato inmutable. Cuando creas varias instantáneas de un disco, como con una programación de instantáneas, Hyperdisk solo almacena los cambios incrementales. Las instantáneas de disco estándar y de archivo son una buena opción si puedes tolerar un RTO más alto, ya que la copia de datos del almacenamiento de instantáneas al almacenamiento de la VM puede significar que tarden más tiempo en restaurarse. Para obtener más información, consulta Crear instantáneas de disco de archivo y estándar.

Las instantáneas de Hyperdisk, así como sus instantáneas de archivo y estándar, son coherentes en caso de fallo en un solo disco. Esto significa que, cuando restauras una base de datos MySQL a partir de una instantánea, debe ejecutar los pasos de recuperación de InnoDB normales para que sus registros y archivos de datos vuelvan a un estado coherente. En función de la configuración de tu registro de rehacer de InnoDB, esto puede alargar el tiempo de recuperación. Los siguientes patrones pueden complicar aún más tus esfuerzos por crear una instantánea de base de datos coherente:

  • Los archivos de tu base de datos MySQL están repartidos en varios volúmenes.
  • Estás usando utilidades RAID de software de Linux, como mdadm.
  • Has separado las ubicaciones de almacenamiento configuradas de MySQL en sistemas de archivos de discos diferentes.

Para crear una captura que no requiera recuperación después de restaurarla, sigue estos pasos:

  1. Bloquea temporalmente el acceso de escritura a la base de datos MySQL.
  2. Para vaciar en el disco todos los búferes en curso, usa los comandos LOCK INSTANCE FOR BACKUP y FLUSH TABLES WITH READ LOCK.
  3. Inicia las operaciones de creación de la instantánea.

  4. En los casos de varios discos, después de vaciar los datos a nivel de MySQL, ejecuta los comandos sync y fsfreeze en el servidor para vaciar todas las escrituras en curso en el disco y pausar las nuevas escrituras entrantes a nivel del sistema de archivos.

Una vez que hayas creado la primera copia de tu base de datos, no es necesario que sigas bloqueando el disco, ya que Hyperdisk crea rápidamente la vista de un momento concreto y, después, puede procesar de forma asíncrona los pasos de copia de almacenamiento posteriores. Si necesitas seguir estos pasos para que las copias de seguridad sean coherentes y quieres evitar que se escriban datos en la base de datos principal, también puedes crear una copia de seguridad de una réplica de la base de datos en lugar de la base de datos principal.

Siguientes pasos