Configura MySQL en Compute Engine

Compute Engine ofrece una variedad de tipos de instancias y opciones de almacenamiento diferentes para leer y escribir datos desde tus bases de datos de MySQL. Para garantizar que obtengas el mejor rendimiento y costo para tus cargas de trabajo de bases de datos, te recomendamos que ejecutes 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 operaciones de lectura, como el procesamiento de transacciones en línea (OLTP) o la base de datos que respalda una aplicación web típica. También tienen en cuenta las opciones de configuración comunes, como el uso de la versión 8.0 o posterior de MySQL y el uso del motor de almacenamiento InnoDB. En el caso de las cargas de trabajo sensibles al rendimiento, es posible que debas ajustar tus configuraciones para que se adapten. Te recomendamos que uses esta guía como punto de partida para tu implementación y, luego, realices pruebas con tu carga de trabajo real para validar que la configuración satisfaga tus necesidades.

Elige tu máquina virtual (VM)

Para las cargas de trabajo de MySQL, recomendamos usar la última generación de familias de máquinas C y N, ya que incluyen formas que funcionan bien para 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.

Enfócate en el rendimiento

Para las cargas de trabajo sensibles al rendimiento, como las bases de datos de MySQL fundamentales 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 de C3 y C3D ofrecen un enfoque similar en el rendimiento.

Estas instancias ofrecen la latencia más baja y coherente para las operaciones vinculadas a la capacidad de procesamiento, y también incluyen las siguientes funciones útiles para las cargas de trabajo centradas en el rendimiento:

  • Control sobre los eventos de mantenimiento del host con notificación avanzada
  • Control de la potenciación turbo de un solo núcleo para una mayor coherencia del rendimiento
  • Redes Tier_1 para un mayor 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 con requisitos de rendimiento específicos.

Optimiza los costos

Para las cargas de trabajo en las que tu prioridad principal es optimizar los costos, como las bases de datos de MySQL con niveles de tráfico bajos a medios o las bases de datos que se usan en entornos de prueba o desarrollo, te recomendamos que uses las instancias N4 más recientes. Estas instancias usan la administración dinámica de recursos de próxima generación de Compute Engine para optimizar tu costo total y mantener un rendimiento sólido, sin las garantías sólidas que ofrecen las instancias C4, C4A, C3 y C3D. Para obtener más detalles, consulta Administración dinámica de recursos de nueva generación.

Configura el tamaño de tu VM

Para cualquier VM que uses, es importante elegir el tamaño adecuado para el nivel de rendimiento de MySQL que deseas alcanzar.

Si tu objetivo es lograr un alto rendimiento de transacciones de escritura por segundo (TPS), el factor principal que debes tener en cuenta es el almacenamiento en bloque. Para obtener más detalles, consulta Configura el almacenamiento en bloque, que se encuentra en esta página.

Si buscas un alto rendimiento de consultas de lectura por segundo (QPS), te recomendamos que uses el grupo de búferes basado en RAM de MySQL para almacenar en caché los datos activos y reducir los accesos al disco. Para maximizar estos beneficios, sigue estos pasos:

  • Elige un tamaño de VM que garantice 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úfer para usar la mayor parte de la RAM en la VM.

Para minimizar el costo de dimensionar tu VM de esta manera, te recomendamos que uses una VM con una proporción alta de RAM en relación con las CPU virtuales (vCPUs), para evitar pagar por las vCPUs que no usas.

Para lograr 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, luego, elige la forma de instancia highmem más pequeña que se ajuste a ese conjunto de trabajo en la RAM. Las formas de instancias highmem tienen alrededor de 8 GB de RAM por CPU virtual. Esto te proporciona suficiente memoria para almacenar en caché un conjunto de trabajo grande y, al mismo tiempo, mantener suficiente CPU para controlar una carga de consultas alta.

Para las cargas de trabajo con grandes conjuntos de trabajo, pero con tasas de consultas bajas, puedes optimizar aún más el costo total con tipos de máquinas personalizados con memoria extendida para aumentar aún más la proporción de RAM a CPU virtual.

Configura el ancho de banda de la red de tu VM

En la mayoría de los casos de uso de MySQL, puedes mantener los límites predeterminados de ancho de banda de la red para tu instancia. Si esto satisface tus necesidades, no es necesario que actualices a la red Tier_1.

Configura el almacenamiento en bloque

Google Cloud Hyperdisk es la única generación de almacenamiento en bloque duradero disponible para las familias de VMs recientes de Compute Engine. Creemos que Hyperdisk Balanced es la mejor opción 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 características:

  • Latencia de unidad de estado sólido (SSD) a bajo costo
  • Configuraciones de alto rendimiento para las aplicaciones que lo necesitan
  • Durabilidad superior al 99.999% para proteger contra el riesgo de fallas de hardware y corrupción silenciosa de datos en toda la industria
  • Encriptación de todos los datos en reposo de Hyperdisk con claves de encriptación administradas por Google o por el cliente

Selecciona tu nivel de rendimiento

Con Hyperdisk Balanced, puedes seleccionar el nivel de rendimiento independientemente del tamaño de 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 necesita tu carga de trabajo. Si el búfer de una base de datos de MySQL es más grande que su conjunto de trabajo, durante las operaciones en estado estable, puede atender casi todas las consultas de lectura desde el búfer, sin acceder al disco.

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

  • Acceso a los registros de rehacer InnoDB
  • Actualizaciones posteriores de los archivos de datos y los índices de InnoDB

Fuera de las operaciones en estado estable, los eventos de mantenimiento de la base de datos también pueden provocar un rendimiento del disco más irregular. La frecuencia con la que esto ocurre tiende a aumentar con la carga de trabajo de escritura de tu base de datos, por lo que es más probable en situaciones como la recuperación posterior a una falla con registros de rehacer o un sistema de copia de seguridad que se copia a sí mismo leyendo todos los cambios de la base de datos desde la última copia de seguridad.

Cómo ajustar el tamaño del disco

Existen tres estrategias comunes para determinar los límites de rendimiento del disco:

  1. Usa la configuración predeterminada. Cada disco incluye al menos 3,000 operaciones de entrada/salida por segundo (IOPS) y 140 MiBps de capacidad de procesamiento. Esto es suficiente para las cargas de trabajo básicas de MySQL y los volúmenes de arranque del sistema operativo (SO). Si tu caso de uso supera este límite, puedes modificar el rendimiento de E/S aprovisionado a pedido sin detener tu carga de trabajo.
  2. Mide tu uso existente. Si tu base de datos ya se ejecuta en otro entorno, registra sus IOPS y su capacidad de procesamiento de disco con una granularidad de un minuto o menos. Después de tener datos de una a dos semanas, de modo que tu conjunto de muestras incluya algunas fluctuaciones en la carga y eventos de mantenimiento normales, selecciona un valor de percentil alto de ese conjunto de datos y agrega un pequeño búfer para tener en cuenta el crecimiento orgánico o el uso inesperado.
  3. Estima tus necesidades y, luego, modifícalas. Si no tienes una fuente de datos existente, es posible que debas estimar tus necesidades de rendimiento inicialmente y, luego, ajustarlas más después de la implementación. Te recomendamos que aprovisiones un valor más alto del que crees que necesitarás inicialmente para que tu carga de trabajo no experimente cuellos de botella en el rendimiento y, luego, reduzcas el rendimiento aprovisionado para que se ajuste a tu carga de trabajo.

Aumenta el rendimiento de tu disco

Puedes aumentar el rendimiento de cada disco Hyperdisk Balanced hasta un máximo de 160,000 IOPS y 2,400 MB/s de capacidad de procesamiento. El tamaño de tu VM ayuda a determinar los límites máximos de rendimiento de Hyperdisk, por lo que, si deseas un rendimiento muy alto de Hyperdisk, es posible que debas aumentar la cantidad de núcleos de tu VM. Si tus cargas de trabajo más exigentes necesitan un mayor rendimiento del disco del que puede proporcionar un solo disco Hyperdisk Balanced, puedes usar uno de los siguientes métodos para combinar varios discos Hyperdisk Balanced:

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

A medida que escalas tus bases de datos de MySQL, puedes aumentar de forma dinámica la capacidad y el rendimiento de tus discos sin tiempo de inactividad. Esto ayuda al rendimiento de las cargas de trabajo de procesamiento analítico en línea (OLAP) que realizan uniones grandes y complejas que no caben en la RAM y se desbordan 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 en la durabilidad:

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

Aprovecha las funciones adicionales de Hyperdisk

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

Si deseas obtener más información para configurar estas funciones con MySQL para Compute Engine, consulta la sección de alta disponibilidad que se encuentra más adelante en esta página.

SSD locales

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

Para obtener información sobre el uso de SSDs locales para escalar bases de datos de MySQL, consulta Cambio de tamaño dinámico del disco, que se explica 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 supervisar el rendimiento de tu VM y el uso de los servicios de infraestructura, usa la consola deGoogle Cloud . En la pestaña Observabilidad de la página Instancias de VM, puedes supervisar métricas relacionadas con el rendimiento, como el uso de CPU y memoria, el ancho de banda de redes y el rendimiento aprovisionado de tus instancias. Del mismo modo, en la página Discos, en la pestaña Observabilidad, puedes supervisar la capacidad de procesamiento y las IOPS de tus volúmenes de disco.

Para personalizar las métricas de rendimiento que ves, usa Cloud Monitoring para compilar consultas. Puedes seleccionar las métricas de rendimiento específicas que deseas ver para tus 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 tu sistema operativo

  • Usa un sistema de archivos adecuado. Google se enfoca en optimizar los sistemas de archivos ext4 y XFS de Linux. Sin embargo, la mayoría de los sistemas de archivos son adecuados para usarse con MySQL.
  • Desactiva las páginas enormes transparentes (THP) en la configuración del sistema operativo base. Si quieres conocer los pasos para desactivar THP, consulta la documentación de THP.
  • Si usas Linux, usa las marcas relatime y lazytime para la configuración de activación del sistema de archivos. Esto reduce la sobrecarga de rendimiento asociada con la actualización de los valores atime, mtime y ctime en los archivos cuando se leen, modifican o cambian sus metadatos.

Prácticas recomendadas para configurar MySQL

Te recomendamos que uses los siguientes parámetros de configuración para MySQL.

  • Usa una versión reciente de MySQL. Google se enfoca en optimizar MySQL 8.0 y versiones posteriores.

  • Aumenta el tamaño del búfer de memoria. 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, lo 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 tamaño del conjunto de trabajo al que accede tu aplicación en la base de datos. Por lo general, esto incluye los siguientes 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 una forma de máquina virtual (VM) con suficiente RAM para que quepa ese conjunto de trabajo.
    3. Configura el tamaño del búfer de 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 escritura doble que ayuda a proteger contra las escrituras incompletas, un modo de falla en el que una escritura que abarca varios bloques en el disco solo se puede confirmar parcialmente si se produce una falla de hardware o de energía en medio de la escritura. Para aprovechar esta protección, activa innodb_doublewrite.

  • Establece el valor de innodb_flush_log_at_trx_commit en 1. Esto garantiza que las transacciones de escritura sean duraderas en el disco cuando se confirmen.

  • Para reducir la sobrecarga de rendimiento, especifica un valor para innodb_flush_method. Para MySQL 8.0.14 y versiones posteriores, establece el valor de innodb_flush_method en O_DIRECT_NO_FSYNC, que es óptimo, pero solo está presente en estas versiones. Para las versiones de MySQL anteriores a la 8.0.14, establece el valor de innodb_flush_method en O_DIRECT.

  • En situaciones de replicación de alta disponibilidad, establece el valor de sync_binlog de la instancia de la base de datos principal en 1. MySQL usa su registro binario para comunicar los cambios de la base de datos principal a la secundaria, por lo que esto garantiza que los registros binarios se confirmen en el momento de la confirmación de la transacción, con el menor rezago de replicación y 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. Esto garantiza que el búfer de MySQL pueda aprovechar las políticas de acceso a la memoria no uniforme (NUMA).

Cuándo desactivar el búfer de escritura doble

El búfer de escritura doble de MySQL, que protege contra escrituras incompletas, tiene una sobrecarga de rendimiento de hasta el 25% para las transacciones de escritura de MySQL, lo que podría afectar 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 escritura doble.

Sin embargo, para que la protección contra escrituras incompletas 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 proporcionan ejemplos de configuraciones que podrían introducir escrituras incompletas por encima de la capa de Hyperdisk:

  • Ejecutar tu instancia de MySQL dentro de contenedores, como Google Kubernetes Engine o Kubernetes autohospedado
  • 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
  • Almacena tus archivos de MySQL en una configuración de matriz redundante de discos independientes (RAID) que provoque la segmentación de discos, como mdadm para Linux o Espacios de almacenamiento y Espacios de almacenamiento directos para Windows.
  • Almacena tus archivos de MySQL sobre un administrador de volúmenes, como Logical Volume Manager (LVM) para Linux o Espacios de almacenamiento y Espacios de almacenamiento directos para Windows.

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

  • Ejecutar tu instancia de MySQL dentro de una VM con virtualización anidada

Si bien puedes configurar los parámetros anteriores para que no se produzcan escrituras incompletas, no te recomendamos que desactives el búfer de escritura doble cuando los uses, ya que es difícil validar que una configuración determinada sea segura.

(Opcional) Desactiva el búfer de escritura doble

Para desactivar el búfer de escritura doble, completa los siguientes 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 2 mayor de 16 KiB. Esto garantiza que el sistema de archivos no dividirá las escrituras de MySQL en IO separadas antes de que se envíen a Hyperdisk. Si no aumentas el límite o usas un valor inferior a 16 KiB, no se protegerá contra las escrituras incompletas. Como ejemplo con un tamaño de clúster de 16 KiB, esto se configura en el momento de la creación del sistema de archivos:

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

  2. Inhabilita innodb_doublewrite y configura innodb_flush_method en O_DIRECT o O_DIRECT_NO_FSYNC (según tu versión de MySQL, como se describió anteriormente).

Configura la alta disponibilidad (HA) 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 (HA) y copias de seguridad para ellas. Para la HA y la copia de seguridad, los siguientes factores son los más importantes:

Por lo general, las soluciones de HA tienen como objetivo un RTO y un RPO casi nulos, pero solo protegen contra las fallas de infraestructura. Las soluciones de copias de seguridad se enfocan en ventanas de RTO y RPO más largas, pero brindan cobertura para un conjunto más grande de situaciones de falla, como las siguientes:

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

Configura la alta disponibilidad (HA)

Las funciones de HA usan redundancia de almacenamiento y procesamiento para garantizar que tu base de datos de MySQL tenga un tiempo de inactividad reducido en caso de que falle o se interrumpa un host, lo que permite que las aplicaciones cliente accedan a sus datos incluso cuando una instancia o zona no está disponible.

MySQL permite la replicación en los siguientes modos:

  • Modo asíncrono: En el modo asíncrono, el servidor principal confirma las transacciones de escritura en cuanto se confirman de forma local, por lo que, si hay una interrupción en el servidor principal, es posible que se pierda una pequeña cantidad de datos escritos recientemente durante la conmutación por error, ya que el RPO es cercano a cero, pero no es cero.
  • Modo semisíncrono. En el modo semisíncrono, el nodo principal espera para confirmar la transacción hasta que una cantidad configurable de réplicas haya confirmado la recepción de la transacción. Esto aumenta en gran medida la probabilidad de que no se produzca pérdida de datos durante una conmutación por error no planificada, ya que el RPO es efectivamente cero.

En ambos modos, el RTO se determina según la rapidez con la que las verificaciones de estado realizan las siguientes acciones:

  1. Identifica una instancia con errores.
  2. Activa la conmutación por error.
  3. Notifica a los clientes que la instancia de conmutación por error ahora es la principal a través del sistema de nombres de dominio (DNS) o de otra forma de identificar el servidor de la base de datos.

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

  • La misma zona en la que se encuentra la instancia principal
  • Una zona diferente dentro de la región en la que se encuentra el servidor principal
  • Una región diferente a la principal

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

  • Ubica tus instancias principal y de conmutación por error en diferentes zonas, ya sea que estén o no dentro de la misma región.
  • Usa la replicación asíncrona. Esto se debe a que, si usas la replicación semisíncrona, ubicar tus instancias principal y de conmutación por error en zonas separadas puede causar una latencia alta para 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 detalles, consulta la guía de Google para proporcionar servicios de alta disponibilidad con Hyperdisk High Availability. Cuando configures la alta disponibilidad balanceada de Hyperdisk, te recomendamos que realices la integración con grupos de instancias administrados con estado para diagnosticar problemas de estado de las instancias y automatizar las acciones de recuperación.

Configura un plan de copia de seguridad y resiliencia de datos

Los planes de copias de seguridad y de resiliencia de datos ayudan a evitar la pérdida de datos durante fallas como la eliminación accidental de datos, los ataques de ransomware y las catástrofes naturales. También puedes usarlos como almacenamiento en frío para cumplir con los requisitos de cumplimiento y auditoría. En el caso de MySQL, existen muchas metodologías de copia de seguridad para elegir, algunas de las cuales actúan a nivel de la base de datos y otras a nivel del volumen de almacenamiento. Cuando selecciones una metodología, debes tener en cuenta principalmente tus requisitos de RTO y RPO.

Copia de seguridad a nivel de la base de datos

Para las copias de seguridad a nivel de la base de datos, considera usar las siguientes opciones que proporciona MySQL:

  • Copias de seguridad incrementales basadas en el registro binario, que crean volcados de datos lógicos Estas incluyen las siguientes:
  • Herramientas que administran el proceso de copia de seguridad por ti, como MySQL Enterprise Backup

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

Para 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:

Usa Hyperdisk para crear instantáneas y clonar a nivel del almacenamiento

Para las copias de seguridad a nivel del almacenamiento, recomendamos usar los productos de Hyperdisk para tomar instantáneas, clonar y capturar de otro modo una vista en un momento determinado de tu base de datos de MySQL. El RPO de este enfoque depende de la frecuencia con la que tomas instantáneas de tu base de datos, y el RTO depende de la solución específica que uses.

Si la recuperación rápida es importante para ti y solo necesitas cobertura de copias de seguridad dentro de una zona, te recomendamos que uses las instantáneas instantáneas de Hyperdisk. Las Instant Snapshots capturan datos de forma incremental en un momento específico y pueden restablecer rápidamente los datos en un nuevo volumen de Hyperdisk a través de la clonación de discos, lo que proporciona un RTO de minutos. Te permiten recuperar datos cuando el contenido de un disco se sobrescribió, borró o dañó, 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 Acerca de las Instant Snapshots.

En situaciones de recuperación ante desastres, en las que los datos deben almacenarse con una redundancia mayor que la del disco original y en una ubicación separada para garantizar que un solo desastre no afecte todas las réplicas de los datos, te recomendamos que uses las instantáneas de disco estándar y de archivo de Hyperdisk. Las instantáneas de disco estándar y de archivo crean una copia de los datos del disco en un momento determinado y la almacenan con alta redundancia en un formato inmutable. Cuando creas varias instantáneas de un disco, por ejemplo, con un programa 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 tardan más en restablecerse. Para obtener más información, consulta Crea instantáneas de disco estándar y de archivo.

Las instantáneas inmediatas de Hyperdisk y sus instantáneas de archivo y estándar son coherentes ante fallas dentro de un solo disco. Esto significa que, cuando restableces desde una instantánea, tu base de datos de MySQL debe ejecutar los pasos de recuperación de InnoDB normales para que sus registros y archivos de datos vuelvan a un estado coherente. Según la configuración de tu registro de rehacer de InnoDB, esto puede alargar el RTO. Los siguientes patrones pueden complicar aún más tus esfuerzos por crear una instantánea coherente de la base de datos:

  • Tus archivos de base de datos de MySQL se distribuyen en varios volúmenes.
  • Estás usando utilidades RAID de software de Linux, como mdadm.
  • Separaste las ubicaciones de almacenamiento configuradas de MySQL en sistemas de archivos en diferentes discos.

Para crear una instantánea que no requiera recuperación después de restaurarla, completa los siguientes pasos:

  1. Bloquea temporalmente el acceso de escritura a la base de datos de MySQL.
  2. Descarga todos los búferes en curso al disco con los comandos LOCK INSTANCE FOR BACKUP y FLUSH TABLES WITH READ LOCK.
  3. Inicia las operaciones de instantáneas.

  4. En situaciones con 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.

Después de capturar la instantánea inicial de tu base de datos, no es necesario que sigas bloqueando el disco, ya que Hyperdisk captura rápidamente la vista en un momento determinado y, luego, puede procesar de forma asíncrona cualquier paso posterior de copia de almacenamiento. Si necesitas estos pasos para la coherencia de las instantáneas y deseas quitar este impacto de escritura en la base de datos principal, también puedes ejecutar la copia de seguridad en una réplica de la base de datos en lugar de en la base de datos principal.

¿Qué sigue?