Alojamiento de servidores de bases de datos: MySQL, PostgreSQL y MongoDB

Los problemas de rendimiento de las bases de datos casi siempre se deben a una de estas tres causas: memoria insuficiente que obliga a leer el grupo de búferes desde el disco, E/S de almacenamiento que no puede mantener el rendimiento de las transacciones o conflicto de CPU debido a un número excesivo de consultas simultáneas que comparten un grupo de recursos. Los servidores dedicados bare metal eliminan estas tres causas del lado del alojamiento.

Este artículo trata sobre parámetros de configuración específicos para MySQL, PostgreSQL y MongoDB en hardware dedicado, con valores de referencia para los niveles de servidor InMotion Hosting. Se trata de puntos de partida, no de ajustes universales. Las características de tu carga de trabajo requerirán ajustes, pero contar con valores iniciales verificados es más rápido que ajustar los valores predeterminados.

Por qué las cargas de trabajo de bases de datos deben ejecutarse en hardware dedicado

Las bases de datos son especialmente sensibles a la contienda por los recursos que genera el alojamiento compartido. Cuando el grupo de búferes InnoDB de MySQL alcanza su límite de tamaño y comienza a expulsar páginas, cada consulta posterior que necesite una página expulsada requiere una lectura del disco. En un entorno compartido, el tráfico de otro inquilino puede reducir la ocupación de tu grupo de búferes en el peor momento posible.

En un servidor dedicado, el grupo de búferes almacena lo que tú has configurado para que almacene. Si asignas 100 GB a InnoDB, tendrás 100 GB. Y punto. La previsibilidad que esto genera no es una ventaja menor. Es la diferencia entre una base de datos que funciona de forma constante bajo carga y otra que se comporta de forma impredecible.

Esto sorprende a muchos administradores de bases de datos que han normalizado la variabilidad del rendimiento como una característica inherente a las bases de datos. En realidad, gran parte de ello es un artefacto del alojamiento.

Configuración de MySQL / MariaDB

Dimensionamiento del búfer de InnoDB

La decisión más importante en la configuración de MySQL es el tamaño del búfer de InnoDB. El objetivo es mantener todo el conjunto de datos de trabajo en la memoria. En un servidor de 64 GB (InMotion Essential o Advanced), asigna entre 40 y 48 GB al búfer. En un sistema de 192 GB, puedes asignar entre 140 y 160 GB:

• innodb_buffer_pool_size = 140G ( en un servidor Extreme de 192 GB)
• innodb_buffer_pool_instances = 8 ( reduce la contienda de mutex en sistemas multinúcleo)
• innodb_log_file_size = 2G ( los registros de rehacer más grandes reducen la frecuencia de los puntos de control)
• innodb_flush_log_at_trx_commit = 1 ( cumplimiento total de ACID; ajústalo a 2 para cargas de trabajo no críticas con gran volumen de escritura)
• innodb_io_capacity = 2000 ( aumenta a 4000+ para NVMe a fin de permitir la utilización completa de E/S)

Ajuste NVMe para NVMe en MySQL

Los valores predeterminados de MySQL se escribieron suponiendo un disco giratorio o SSD SATA. En NVMe, es necesario ajustar varios parámetros para evitar la limitación artificial del rendimiento de E/S:

• innodb_io_capacity_max = 8000 ( permite la utilización de E/S en ráfagas en NVMe)
• innodb_read_io_threads = 8 ( aumenta el valor predeterminado de 4 para aprovechar NVMe )
• innodb_write_io_threads = 8 ( por la misma razón)
• innodb_flush_method = O_DIRECT ( omite la caché de páginas del sistema operativo para evitar el doble búfer con el grupo de búferes de InnoDB)

Con O_DIRECT habilitado en NVMe, MySQL omite la caché de página del sistema operativo y gestiona tu propio grupo de búferes por completo. Esto evita que el grupo de búferes y el sistema operativo almacenen en caché los mismos datos de forma independiente, lo que en un sistema de 192 GB desperdiciaría una cantidad considerable de memoria si ambas capas intentaran almacenar en caché el conjunto de datos.

Registro de consultas lentas

Habilita el registro de consultas lentas con un umbral de 100 ms como herramienta de supervisión permanente, no solo durante la resolución de problemas:

• slow_query_log = ON
• long_query_time = 0,1 ( umbral de 100 ms)
• log_queries_not_using_indexes = ON ( detecta los escaneos completos de tablas, incluso si se completan rápidamente)

PostgreSQL

Configuración de la memoria

La configuración PostgreSQL es menos agresiva que la de MySQL por defecto, ya que está diseñada para ejecutarse junto con otros procesos. En un servidor de base de datos dedicado, puedes aumentar mucho más:

• shared_buffers = 48 GB ( 25 % de la RAM en un sistema de 192 GB; PostgreSQL recomienda un 25 % como punto de partida, aunque algunas cargas de trabajo se benefician de valores más altos).
• effective_cache_size = 144 GB ( indica al planificador de consultas cuánta memoria hay disponible para el almacenamiento en caché; se establece en el 75 % de la RAM)
• work_mem = 256 MB ( por operación de ordenación/hash; multiplicar por max_connections para obtener el uso potencial total; valor inicial conservador)
• maintenance_work_mem = 4 GB ( utilizado para VACUUM, CREATE INDEX y operaciones similares)
• max_wal_size = 8 GB ( reduce la frecuencia de los puntos de control para cargas de trabajo con gran volumen de escritura)

shared_buffers al 25 % es una PostgreSQL , no un límite máximo. Las cargas de trabajo con grandes conjuntos de datos a los que se accede con frecuencia se benefician de valores de hasta el 40 % de la RAM, con effective_cache_size aumentado proporcionalmente. El planificador de consultas utiliza effective_cache_size para decidir entre exploraciones de índices y exploraciones secuenciales, por lo que un valor inexacto da lugar a planes de consulta subóptimos.

Agrupación de conexiones con PgBouncer

PostgreSQL un proceso por cada conexión. Con más de 200 conexiones simultáneas, la sobrecarga del cambio de contexto del proceso se vuelve apreciable. PgBouncer actúa como un proxy de conexión que mantiene un grupo más pequeño de PostgreSQL reales, multiplexando cientos de conexiones de aplicaciones a través de ellas.

Para aplicaciones con cientos de usuarios simultáneos, instala PgBouncer en el mismo servidor y configura las aplicaciones para que se conecten a PgBouncer en el puerto 6432. El agrupamiento en modo transacción es adecuado para la mayoría de las cargas de trabajo de aplicaciones web; el agrupamiento en modo sesión es necesario para aplicaciones que utilizan tablas temporales o bloqueos de aviso.

Rendimiento de NVMe WAL

El rendimiento PostgreSQL se ve muy influido por el rendimiento de escritura de WAL (Write-Ahead Log). Cada transacción confirmada escribe un registro WAL antes de volver al cliente. En NVMe, las operaciones fsync de WAL se completan en microsegundos, frente a los milisegundos que tardan en las unidades SSD SATA. Esto mejora directamente el rendimiento de las transacciones para cargas de trabajo con gran volumen de escritura.

Configura wal_compression = on para reducir el volumen de WAL en cargas de trabajo con muchas lecturas y escrituras ocasionales de gran tamaño. Para las réplicas analíticas que reciben replicación en streaming, NVMe tanto NVMe el primario como NVMe la réplica garantiza que el retraso de replicación sea mínimo, incluso durante periodos de escritura intensiva.

Configuración de MongoDB

Tamaño de la caché de WiredTiger

El motor de almacenamiento WiredTiger de MongoDB utiliza una caché interna independiente de la caché de página del sistema operativo. Por defecto, la caché de WiredTiger se establece en el 50 % de la RAM menos 1 GB. En un sistema de 192 GB, eso supone aproximadamente 95 GB. En el caso de los servidores de bases de datos dedicados, puedes aumentar este valor:

• storage.wiredTiger.engineConfig.cacheSizeGB: 120 ( en mongod.conf para un servidor dedicado de 192 GB)

WiredTiger realiza la compresión en tu caché interna (Snappy de forma predeterminada). En NVMe con margen de CPU disponible, la compresión zstd proporciona mejores ratios con una sobrecarga de CPU aceptable, lo que reduce la carga efectiva de E/S para grandes colecciones de documentos.

Preocupación por lectura/escritura y configuración del diario

Para implementaciones de conjuntos de réplicas en un único servidor dedicado que ejecute varias instancias de mongod, configura adecuadamente la preocupación por la escritura:

• w: mayoría para datos financieros o críticos (espera a que la mayoría del conjunto de réplicas lo confirme)
• j: true habilita el registro en diario, que escribe en NVMe confirmar; coste de latencia aceptable en NVMe
• readPreference: secondaryPreferred para cargas de trabajo con gran volumen de lectura distribuye la carga de lectura entre los miembros réplica

Estrategia RAID para cargas de trabajo de bases de datos

Los servidores dedicados de InMotion utilizan RAID por software configurado con mdadm. Esto es importante para comprender las características de rendimiento, ya que el RAID por software en NVMe una CPU multinúcleo moderna se comporta de manera diferente a los controladores RAID por hardware tradicionales con caché de escritura respaldada por batería.

Nivel RAID	Capacidad útil	Leer rendimiento	Escribir rendimiento	Caso práctico
RAID 0 (franja)	7,68 TB (completo)	2x secuencial	2x secuencial	Espacio temporal, datos no críticos
RAID 1 (espejo, predeterminado en InMotion)	3,84 TB	Leer desde cualquiera de las unidades	Escribir en ambas unidades	Bases de datos de producción
Sin RAID (una sola unidad)	3,84 TB	NVMe completa	NVMe completa	Leer réplicas con copia de seguridad externa

Para los servidores de bases de datos de producción, RAID 1 a través de mdadm es la opción predeterminada adecuada. La penalización por escritura es mínima en NVMe ambas unidades son lo suficientemente rápidas como para que las escrituras duplicadas superen la mayoría de los requisitos de rendimiento de las aplicaciones), y la redundancia protege contra el fallo de una sola unidad sin pérdida de datos durante el periodo de sustitución.

RAID no es una estrategia de copia de seguridad. Un error de software que corrompe el directorio de datos, un DROP TABLE accidental o un ransomware afectan simultáneamente a ambas unidades duplicadas. El almacenamiento automatizado de 500 GB de Premier Care proporciona protección real contra esos modos de fallo.

Estrategia de copia de seguridad para bases de datos de producción

Copia de seguridad de MySQL

Para bases de datos MySQL de menos de 50 GB, mysqldump nocturno con –single-transaction produce copias de seguridad consistentes sin bloquear tablas. Para bases de datos más grandes, Percona XtraBackup realiza copias de seguridad físicas en caliente que se restauran más rápido que los volcados SQL. Almacenad las copias de seguridad en el volumen de copia de seguridad de 500 GB de Premier Care, que se encuentra fuera del servidor.

PostgreSQL

pg_dump para bases de datos más pequeñas; pg_basebackup para copias de seguridad físicas de instancias más grandes. Para requisitos de RPO cercanos a cero, configura el archivado continuo de WAL en el volumen de copia de seguridad: cada segmento WAL completado se envía automáticamente, lo que proporciona una capacidad de recuperación puntual con una granularidad típica de 5 a 10 minutos.

Copia de seguridad de MongoDB

mongodump proporciona copias de seguridad lógicas; para implementaciones más grandes, las instantáneas a nivel del sistema de archivos del directorio de datos WiredTiger (tomadas cuando la base de datos está inactiva o en un punto coherente) son más rápidas de restaurar. Para las implementaciones de conjuntos de réplicas, realizar copias de seguridad desde un miembro secundario evita cualquier impacto en el rendimiento de escritura primario.

Elegir el nivel adecuado de servidor dedicado

Tamaño de la base de datos	Conexiones simultáneas	Nivel recomendado	Coste mensual
Menos de 20 GB de conjunto de trabajo	Hasta 100	Esencial (64 GB DDR4)	99,99 $ al mes
Conjunto de trabajo de 20-50 GB	100-300	Avanzado (64 GB DDR4, RAID-1)	149,99 $ al mes
Conjunto de trabajo de 50-140 GB	300-500	Elite	199,99 $ al mes
Conjunto de trabajo de más de 140 GB	500+	Extreme (192 GB DDR5 ECC)	349,99 $ al mes

Estos umbrales suponen que el servidor está dedicado a la carga de trabajo de la base de datos. Los servidores mixtos que alojan la capa de aplicación junto con la base de datos necesitan un mayor margen de memoria en todos los niveles.

Cómo empezar

• Precios de servidores dedicados: inmotionhosting .com/dedicated-servers/dedicated-server-price
• ServidoresNVMe : inmotionhosting .nvme
• Premier Care para copias de seguridad automáticas: inmotionhosting .com/blog/inmotion-premier-care/

El equipo APS InMotion Hostingse encarga de la gestión a nivel del sistema operativo y puede ayudar con la configuración inicial en el marco del servicio Premier Care. Vale la pena aprovechar la consulta mensual de una hora de InMotion Solutions para revisar el ajuste de la base de datos, especialmente cuando se migra una base de datos de producción desde un alojamiento compartido, donde la mejora del rendimiento suele ser considerable.