Requisiti RAM MySQL Cluster

Da MySQL 5.1, i dati non devono più essere interamente in memoria.

Ho letto che le colonne indicizzate (penso che l'intera struttura dell'indice) debba essere ancora in memoria ( MySQL High Availability, 2010, pag. 533 , "MySQL Cluster mantiene tutte le colonne indicizzate nella memoria principale" ).

Alla luce di ciò, cosa succede se NON c'è abbastanza memoria (ad esempio, un enorme database (> 100 GB o 1 TB), in esecuzione su server con configurazioni di memoria insufficiente (2 nodi di dati, ciascuno con 1 GB di RAM, ad esempio))?

MySQL Cluster supporta la memorizzazione di colonne non indicizzate su solo disco con una cache LRU di dati a cui è stato effettuato l'accesso di recente. Tuttavia, le colonne indicizzate vengono sempre mantenute in memoria.

MySQL Cluster prealloca tutta la memoria, secondo i parametri DataMemory e IndexMemory. Non richiederà dinamicamente più memoria al sistema operativo sottostante.

Ciò significa che è necessario aver configurato memoria sufficiente nel cluster per contenere tutte le colonne indicizzate in memoria. Se il set di dati è abbastanza grande da rendere le colonne indicizzate più grandi della memoria del cluster disponibile, non è possibile caricare tale set di dati nel cluster. Ad un certo punto rimarrai senza spazio e le tue transazioni di inserimento verranno interrotte.

Quando si configura DataMemory e IndexMemory, è meglio limitarsi a un po 'meno della memoria fisica di ciascun sistema. Parte della memoria fisica dovrebbe essere riservata al sistema operativo e ad altri processi.

Teoricamente MySQL Cluster può essere configurato in modo da utilizzare la memoria virtuale tramite un dispositivo di scambio (ad es. Più della memoria fisica), ma come affermano le altre risposte, questo non è un caso d'uso progettato per l'uso. Avere strutture in memoria scambiate su disco di solito non è ottimale poiché i modelli di accesso casuale in memoria comportano un accesso casuale al disco, con conseguente blocco dello swap e rallentamento del sistema. Con MySQL Cluster, il risultato più probabile è il fallimento del battito cardiaco e il fallimento del cluster a causa di un nodo di dati di scambio che non risponde ai segnali abbastanza rapidamente.

Per supportare in modo efficiente indici di memoria più grandi di aggregati, MySQL Cluster dovrebbe supportare formati di indice su disco (forse un albero B ecc.) Con cache e schemi di accesso allineati con le proprietà di accesso al disco.

Il cluster MySQL è costruito attorno a una struttura di indice ottimizzata per adattarsi alla memoria; una T-albero . Questo è diverso dai tuoi normali motori di archiviazione in MySQL che usano una struttura B-tree o B + tree , che può sopravvivere abbastanza bene dalla memoria, supponendo che tu abbia alcuni hot-spot / accesso non uniforme (questo è normalmente un presupposto sicuro ).

Se vuoi costruire una sorta di proof-of-concept, non c'è nulla che ti impedisca di usare una grande quantità di swap per compensare la tua mancanza di ram. Basta essere consapevoli del fatto che questo non funzionerà bene e si sta utilizzando un prodotto per un caso d'uso per cui non è progettato.

Alla luce di ciò, cosa succede se NON c'è abbastanza memoria

Probabilmente cosa ti aspetteresti se non ci fosse abbastanza memoria. I file verranno creati sulle tue unità e sarai in esecuzione alla massima velocità consentita dalle tue unità.

Assicurati di limitare correttamente MySQL in modo che non consumi tutta la memoria necessaria per altri processi di sistema.

Fondamentalmente, una catena è forte solo quanto il suo anello più debole.

Quando vengono configurati server virtuali privati ​​(utilizzando VMWare per configurare i cluster ESX), tutti i server bare metal nel cluster devono avere la stessa quantità di RAM.

MySQL Cluster deve essere trattato con lo stesso tipo di guanti per bambini. Se un server (anche solo 1) ha meno memoria di altri in un cluster, sarebbe come un fattore limitante. Non mi sorprenderebbe se un server con 2 GB di RAM fa sì che altri server nel cluster MySQL (anche se quegli altri server hanno 8 GB di RAM) si comportino come se avessero al massimo 2 GB.

Per lo meno, dovresti

• aggiorna la tua RAM sui nodi di dati per abbinare i nodi SQL
• Utilizzare il maggior numero possibile di tabelle basate su disco
• Rimuovi tutti gli indici superflui (indici non utilizzati)
• Per maggiori informazioni
  • MySQL Sharding vs MySQL Cluster
  • http://messagepassing.blogspot.com/2011/03/data-distribution-in-mysql-cluster.html

Come nota a margine, tieni presente che MySQL Cluster ha anche la capacità di archiviare dati su disco per ciascun server in esecuzione come nodo di archiviazione