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))?
Réponses:
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.
la source
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.
la source
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.
la source
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
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
la source