Exigence de RAM de MySQL Cluster

8

Depuis MySQL 5.1, les données n'ont plus besoin d'être entièrement en mémoire.

J'ai lu que les colonnes indexées (je pense que la structure d'index entière) doit toujours être en mémoire ( MySQL High Availability, 2010, p. 533 , "MySQL Cluster conserve toutes les colonnes indexées dans la mémoire principale" ).

À la lumière de cela, que se passe-t-il s'il n'y a PAS assez de mémoire (c'est-à-dire une énorme base de données (> 100 Go ou 1 To), fonctionnant sur des serveurs avec des configurations de mémoire faible (2 nœuds de données, chacun avec 1 Go de RAM, par exemple))?

mysql memory ndbcluster

— gsb
source

J'ai posé cette question parce que je suis curieux de savoir ce qui se passerait si un nœud de données n'a pas assez de mémoire principale. MySQL Cluster ne conservera-t-il pas du tout une partie de l'index dans la mémoire secondaire? Et si je n'ai pas beaucoup de RAM et que la taille de ma base de données est énorme. Alors le cluster MySQL n'est pas une option pour moi?

— gsb

4

MySQL Cluster prend en charge le stockage de colonnes non indexées sur disque uniquement avec un cache LRU de données récemment consultées. Cependant, les colonnes indexées sont toujours conservées en mémoire.

MySQL Cluster pré-alloue toute la mémoire, selon les paramètres DataMemory et IndexMemory. Il ne demandera pas dynamiquement plus de mémoire au système d'exploitation sous-jacent.

Cela signifie que vous devez avoir configuré suffisamment de mémoire sur votre cluster pour conserver toutes les colonnes indexées en mémoire. Si votre ensemble de données est suffisamment grand pour que les colonnes indexées soient plus grandes que la mémoire de cluster disponible, vous ne pouvez pas charger cet ensemble de données dans le cluster. À un moment donné, vous manquerez d'espace et vos transactions d'insertion seront abandonnées.

Lors de la configuration de DataMemory et IndexMemory, il est préférable de vous limiter à un peu moins que la mémoire physique de chaque système. Une partie de la mémoire physique doit être réservée au système d'exploitation et à d'autres processus.

Théoriquement, MySQL Cluster peut être configuré de sorte qu'il utilise la mémoire virtuelle via un périphérique d'échange (par exemple plus que la mémoire physique), mais comme les autres réponses l'indiquent, ce n'est pas un cas d'utilisation conçu. Le fait que les structures en mémoire soient échangées sur le disque est généralement sous-optimal, car les modèles d'accès aléatoire en mémoire entraînent un accès aléatoire au disque, ce qui entraîne un écrasement et un ralentissement du swap sur le système. Avec MySQL Cluster, le résultat le plus probable est l'échec du rythme cardiaque et l'échec du cluster en raison d'un nœud de données d'échange qui ne répond pas assez rapidement aux signaux.

Pour prendre en charge efficacement des index de mémoire plus grands que la mémoire agrégée, MySQL Cluster devrait prendre en charge les formats d'index sur disque (peut-être une arborescence B, etc.) avec des modèles de mise en cache et d'accès alignés sur les propriétés d'accès au disque.

— Frazer Clement
source

3

Le cluster MySQL est construit autour d'une structure d'index optimisée pour l'ajustement de la mémoire; T-arbre . Ceci est différent de vos moteurs de stockage habituels dans MySQL qui utilisent une arborescence B ou B + , qui peuvent survivre assez bien en dehors de la mémoire en supposant que vous avez des points chauds / un accès non uniforme (c'est normalement une hypothèse sûre ).

Si vous voulez construire une sorte de preuve de concept, rien ne vous empêche d'utiliser une grande quantité de swap pour compenser votre manque de RAM. Sachez simplement que cela ne fonctionnera pas bien et que vous utilisez un produit pour un cas d'utilisation pour lequel il n'est pas conçu.

— Morgan Tocker
source

Votre réponse et Frazer sont assez bonnes. Mais comme il a répondu le premier, je vais lui donner les crédits. J'espère que cela ne vous dérange pas. :)

— gsb

Non, ne me dérange pas;) Frazer fonctionne sur le cluster MySQL.

— Morgan Tocker

2

À la lumière de cela, que se passe-t-il s'il n'y a PAS assez de mémoire

Probablement ce à quoi vous vous attendriez s'il n'y a pas assez de mémoire. Les fichiers seront créés sur vos disques et vous fonctionnerez aussi vite que vos disques le permettent.

Assurez-vous de limiter MySQL correctement afin qu'il ne consomme pas toute votre mémoire nécessaire pour d'autres processus système.

— Derek Downey
source

1

Fondamentalement, une chaîne n'est aussi solide que son maillon le plus faible.

Lorsque des serveurs virtuels privés sont configurés (en utilisant VMWare pour configurer les clusters ESX), tous les serveurs bare-metal du cluster sont censés avoir la même quantité de RAM.

MySQL Cluster doit être traité avec le même type de gants pour enfants. Si des serveurs (même un seul) ont moins de mémoire que d'autres dans un cluster, ce serait comme un facteur limitant. Cela ne me surprendrait pas si un serveur avec 2 Go de RAM fait en sorte que les autres serveurs du cluster MySQL (même si ces autres serveurs ont chacun 8 Go de RAM) se comportent comme s'ils avaient au plus 2 Go.

À tout le moins, vous devriez

mettre à niveau votre RAM sur les nœuds de données pour correspondre aux nœuds SQL
Utilisez autant de tables sur disque que possible
Supprimer tous les index superflus (index non utilisés)
Pour plus d'informations
- MySQL Sharding vs MySQL Cluster
- http://messagepassing.blogspot.com/2011/03/data-distribution-in-mysql-cluster.html

En guise de remarque, veuillez garder à l'esprit que MySQL Cluster a également la capacité de stocker des données sur le disque pour chaque serveur fonctionnant en tant que nœud de stockage

— RolandoMySQLDBA
source