Requisito de MySQL Cluster RAM

8

Desde MySQL 5.1, los datos ya no necesitan estar completamente en la memoria.

He leído que las columnas indexadas (creo que toda la estructura del índice) todavía deben estar en la memoria ( MySQL High Availability, 2010, pág. 533 , "MySQL Cluster mantiene todas las columnas indexadas en la memoria principal" ).

A la luz de esto, ¿qué sucede si NO hay suficiente memoria (es decir, una gran base de datos (> 100 GB o 1 TB) que se ejecuta en servidores con configuraciones de memoria baja (2 nodos de datos, cada uno con 1 GB de RAM, por ejemplo))?

mysql memory ndbcluster

— gsb
fuente

Lo he preguntado porque tengo curiosidad por saber qué sucedería si un nodo de datos no tiene suficiente memoria principal. ¿MySQL Cluster no mantendrá parte del índice en la memoria secundaria? ¿Qué pasa si no tengo mucha RAM y el tamaño de mi base de datos es enorme? ¿Entonces MySQL Cluster no es una opción para mí?

— gsb

4

MySQL Cluster admite el almacenamiento de columnas no indexadas solo en disco con un caché LRU de datos a los que se accedió recientemente. Sin embargo, las columnas indexadas siempre se mantienen en la memoria.

MySQL Cluster asigna previamente toda la memoria, de acuerdo con los parámetros DataMemory e IndexMemory. No le pedirá al sistema operativo subyacente más memoria de forma dinámica.

Esto significa que debe haber configurado suficiente memoria en su clúster para contener todas las columnas indexadas en la memoria. Si su conjunto de datos es lo suficientemente grande como para que las columnas indexadas sean más grandes que la memoria del clúster disponible, entonces no puede cargar ese conjunto de datos en el clúster. En algún momento se quedará sin espacio, y sus transacciones de inserción serán abortadas.

Al configurar DataMemory e IndexMemory, es mejor limitarse a algo menos que la memoria física en cada sistema. Alguna memoria física debe reservarse para el sistema operativo y otros procesos.

Teóricamente, MySQL Cluster se puede configurar para que use memoria virtual a través de un dispositivo de intercambio (por ejemplo, más que memoria física), pero como dicen las otras respuestas, este no es un caso de uso diseñado. Tener estructuras en memoria intercambiadas en el disco suele ser subóptimo, ya que los patrones de acceso aleatorio en memoria dan como resultado un acceso aleatorio al disco, lo que da como resultado un intercambio y desaceleración en todo el sistema. Con MySQL Cluster, el resultado más probable es la falla de los latidos del corazón y la falla del clúster debido a que un nodo de intercambio de datos no responde a las señales lo suficientemente rápido.

Para soportar eficientemente índices de memoria más grandes que el agregado, MySQL Cluster necesitaría soportar formatos de índice en disco (quizás un árbol B, etc.) con patrones de caché y acceso alineados con las propiedades de acceso al disco.

— Frazer Clement
fuente

3

MySQL cluster está construido alrededor de una estructura de índice que está optimizada para el ajuste de memoria; T-árbol . Esto es diferente de sus motores de almacenamiento normales en MySQL que usan una estructura de árbol B-tree o B + , que puede sobrevivir bastante bien sin memoria, suponiendo que tenga algunos puntos calientes / acceso no uniforme (esto es normalmente una suposición segura )

Si desea crear algún tipo de prueba de concepto, no hay nada que le impida usar una gran cantidad de intercambio para compensar su falta de ram. Solo tenga en cuenta que esto no funcionará bien y que está utilizando un producto para un caso de uso para el que no está diseñado.

— Morgan Tocker
fuente

Tu respuesta y la de Frazer son bastante buenas. Pero como él respondió primero, le daré los créditos. Espero que no te importe. :)

— gsb

No, no importa;) Frazer funciona en el clúster MySQL.

— Morgan Tocker

2

A la luz de esto, ¿qué sucede si NO hay suficiente memoria?

Probablemente lo que esperarías si no hay suficiente memoria. Los archivos se crearán en sus unidades y se ejecutará tan rápido como lo permitan sus unidades.

Asegúrese de limitar MySQL correctamente para que no consuma toda la memoria necesaria para otros procesos del sistema.

— Derek Downey
fuente

1

Básicamente, una cadena es tan fuerte como su eslabón más débil.

Cuando se configuran servidores virtuales privados (usando VMWare para configurar los Clústeres ESX), se supone que todos los servidores básicos en el Clúster tienen la misma cantidad de RAM.

MySQL Cluster debe tratarse con el mismo tipo de guantes para niños. Si algún servidor (incluso solo 1) tiene menos memoria que otros en un Clúster, eso sería un factor limitante. No me sorprendería si un servidor con 2 GB de RAM hace que otros servidores en el Clúster MySQL (incluso si esos otros servidores tienen 8 GB de RAM) se comporten como si tuvieran 2 GB como máximo.

Por lo menos, deberías

actualice su RAM en los nodos de datos para que coincida con los nodos SQL
Use tantas tablas basadas en disco como sea posible
Eliminar todos los índices superfluos (los índices no se utilizan)
Para más información
- MySQL Sharding vs MySQL Cluster
- http://messagepassing.blogspot.com/2011/03/data-distribution-in-mysql-cluster.html

Como nota al margen, tenga en cuenta que MySQL Cluster también tiene la capacidad de almacenar datos en el disco para cada servidor que se ejecuta como un nodo de almacenamiento

— RolandoMySQLDBA
fuente