MySQL Cluster FAQ

R: MySQL Cluster è un database transazionale in tempo reale conforme alle proprietà ACID, che offre scalabilità in scrittura e combina il 99,999% di disponibilità dei dati al basso TCO dell'open source. Basato su un'architettura distribuita, multi-master senza singoli punti di guasto, MySQL Cluster è in grado di scalare orizzontalmente su sistemi hardware di largo consumo per gestire carichi di lavoro di lettura e scrittura impegnativi, accessibili mediante le interfacce SQL e NoSQL.

L'architettura in tempo reale di MySQL Cluster offre tempi di risposta prevedibili di pochi millisecondi, con la possibilità di gestire milioni di transazioni al secondo. Il supporto dei dati in memoria e su disco, il partizionamento automatico dei dati con bilanciamento dei carichi e la possibilità di aggiungere nodi a un cluster in esecuzione senza alcuna interruzione garantiscono la scalabilità lineare dei database per gestire anche i carichi di lavoro basati sul web più imprevedibili.

R: MySQL Cluster Carrier Grade Edition (CGE) include strumenti di gestione e monitoraggio del database MySQL Cluster, unitamente all'accesso al supporto Oracle Premier. MySQL Cluster CGE è disponibile tramite abbonamento o con licenza e assistenza commerciale.

• Altre informazioni su MySQL Cluster CGE
• Riesamina le nostre condizioni di concessione di licenza

R: Vedere http://www.mysql.com/customers/cluster/.

R: La versione GA attuale è MySQL Cluster 7.2. MySQL 5.5 è integrato e abbinato a MySQL Cluster.

R: No, MySQL Cluster è stato progettato per essere eseguito su hardware di largo consumo. Utilizzando hardware specializzato, come ad esempio le interconnessioni di rete SCI, è possibile raggiungere livelli di prestazioni ancora superiori.

R:

R: Se la risposta a una delle 10 domande seguenti è "SÌ", è opportuno prendere in considerazione MySQL Cluster come soluzione adatta alle proprie esigenze:

• L'inattività delle applicazioni dovuta a un guasto al database comporterebbe l'interruzione delle normali attività lavorative?
• Siete insoddisfatti degli attuali tempi di esecuzione dei failover?
• Il database dell'applicazione richiede la ridondanza integrata che consenta di raggiungere una disponibilità a "cinque-noni" con failover e ripristino automatici?
• Il database attuale rallenta le operazioni di scrittura? State cercando alternative all'architettura scalabile master-slave e/o al partizionamento delle applicazioni?
• La vostra applicazione è sensibile a tempi di latenza inferiori al secondo?
• Le vostre applicazioni e i vostri servizi devono fornire tempi di risposta prevedibili?
• La vostra applicazione ha requisiti di scalabilità non prevedibili?
• Eseguite un'ampia gamma di applicazioni che trarrebbero vantaggio dall'accesso diretto ai dati, senza dover sempre fare affidamento su SQL (es. applicazioni Java e OpenJPA, OpenLDAP, Web Service e applicazioni C++)?
• Trarreste beneficio da un'architettura cluster in configurazione attiva/attiva in grado di eliminare gli sprechi di risorse hardware?
• La vostra applicazione consiste principalmente di ricerche per chiave primaria e combinazioni di tabelle che restituiscono piccoli set di risultati?

Vi invitiamo a leggere anche la nostra Guida alla valutazione e ad esaminare ulteriori risorse sui prodotti per saperne di più su MySQL Cluster.

R: Le applicazioni ideali includono:

• OLTP per volumi elevati
• Analisi in tempo reale
• e-Commerce e commercio finanziario con rilevamento delle frodi
• Pagamenti mobili e micropagamenti
• Gestione e caching delle sessioni
• Streaming di dati, analisi e raccomandazioni
• Gestione e distribuzione dei contenuti
• Giochi online multigiocatore di massa
• Comunicazioni e servizi di presenza
• Gestione dei profili abbonato/utente e autorizzazioni

Vedere l'elenco completo dei casi di studio e delle applicazioni di MySQL Cluster.

R:

• Disponibilità
  • 99,999% (<5 min inattività/anno)
• Prestazioni
  • Tempi di risposta: inferiori a 5 millisecondi (con replicazione sincrona e accesso mediante SQL). È possibile ottenere tempi di risposta inferiori utilizzando uno dei metodi di accesso NoSQL.
  • Throughput di 250.000+ operazioni UPDATE replicate/sec su un server Intel a due socket dotato di 24 GB di RAM. 2,5m operazioni UPDATE su un cluster formato da 8 server Intel. Vedere i benchmark completi.
• Failover
  • Il failover inferiore al secondo consente di fornire servizi senza alcuna interruzione.
• Scalabilità
  • Scale-out, scale-up e scalabilità dinamica.
  • Per uno scale-out economico:
    • Aggiungere più Data Node (8, 10, 12,...48) per cluster, oppure
    • Aggiungere più CPU (4, 8, ecc.), oppure
    • Aggiungere più memoria (16 GB, 32 GB, ecc.) per Data Node

R: Per scopi di valutazione e sviluppo, è possibile eseguire tutti i nodi su un singolo host. Tuttavia per garantire la massima ridondanza e tolleranza ai guasti, sono necessari almeno 6 host fisici:

• 2 Data Node
• 2 Application Node SQL/NoSQL
• 2 Management Node

Spesso gli utenti collocano i Management Node e gli Application Node sullo stesso host, riducendo a quattro il numero di nodi.

R: Sì, a condizione che la rete presenti le caratteristiche specificate qui.

Da tempo MySQL Cluster supporta la replicazione geografica, che consente di distribuire i cluster a data center remoti per ridurre gli effetti della latenza geografica, inviando i dati agli utenti da una posizione più vicina e fornendo funzioni di ripristino di emergenza.

La replicazione geografica è asincrona e può essere implementata come cluster attivo/attivo o attivo/passivo.

La replicazione geografica è il modello di implementazione consigliato per le implementazioni che interessano più data center.

R: Le applicazioni possono essere sviluppate usando qualsiasi connettore MySQL. MySQL Cluster fornisce inoltre la connettività nativa NoSQL attraverso Memcached, C++, Java, JPA e HTTP/REST.

R: No, le interfacce sono le stesse.

R: Sì, MySQL Cluster è spesso usato come database integrato dagli ISV e dai NEP (Network Equipment Provider). Elenco dei clienti »

R: La replicazione geografica consente di eseguire replicazioni asincrone su cluster separati geograficamente. Questa procedura è spesso usata per il ripristino di emergenza.

R: Sì, MySQL Cluster supporta la replicazione unidirezionale e bidirezionale. Con la replicazione geografica bidirezionale sono disponibili il rilevamento e la risoluzione delle collisioni fra transazioni.

R: Le configurazioni di MySQL Cluster dispongono solitamente di almeno due copie di tutti i dati, conservati su host diversi. In caso di guasto totale del sistema, i log delle transazioni e i file di checkpoint vengono mantenuti su disco con frequenza configurabile. Inoltre è possibile memorizzare su disco i dati non indicizzati.

R: MySQL Cluster dispone di un'opzione "Diskless", così come di un'opzione "No logging".

Nel caso dell'opzione Diskless, sono previste le seguenti restrizioni:

1. Nessun dato su disco
2. Perdita di dati in caso di guasto del cluster
3. Nessun backup

Nel caso dell'opzione No logging, il cluster continua a creare i file di log, ma non viene eseguito alcun checkpoint dei dati su disco.

R: No. MySQL Cluster Manager è disponibile solo come parte del database MySQL Cluster Carrier Grade Edition (CGE) commerciale. Per acquistare abbonamenti o licenze di MySQL Cluster CGE, è possibile contattare il Team di vendita MySQL.

R: MySQL Cluster Manager è un software che semplifica la creazione e la gestione del database MySQL Cluster attraverso l'automazione delle attività di gestione più comuni.

R: Utilizzando MySQL Cluster Manager, gli amministratori di database (DBA) e gli amministratori di sistema sono più produttivi e possono concentrarsi sulle iniziative IT più strategiche, rispondendo più rapidamente alle esigenze degli utenti man mano che esse cambiano. Allo stesso tempo si riducono notevolmente i rischi legati alle interruzioni del database che in precedenza erano causate da errori di configurazione manuale.

R: Ad esempio, le operazioni di gestione che prevedono il riavvio di un database MySQL Cluster che in precedenza richiedevano 46 comandi manuali¹, impegnando due ore e mezza del tempo di un DBA ², ora possono essere eseguite con un singolo comando e sono completamente automatizzate grazie a MySQL Cluster Manager. Ciò consente di ridurre:

• La complessità e i costi amministrativi;
• Il rischio di interruzioni, grazie all'automazione dei processi di configurazione e gestione delle modifiche;
• La creazione di script personalizzati dei comandi di gestione e lo sviluppo e manutenzione di strumenti di gestione interni.

R: Gli amministratori possono creare ed eliminare interi cluster, così come avviare, interrompere e riavviare il cluster con un unico comando e aggiungere nodi online. Pertanto gli amministratori non devono più riavviare manualmente ogni Data Node nella sequenza corretta, oppure creare script personalizzati per automatizzare il processo.

MySQL Cluster Manager automatizza le operazioni di gestione online, inclusi gli upgrade, i downgrade e la riconfigurazione dei cluster in esecuzione, senza interrompere le applicazioni o i client che accedono al database. Gli amministratori non devono più modificare manualmente i file di configurazione e distribuirli a tutti gli altri nodi del cluster, oppure determinare se sia necessario eseguire riavvii. MySQL Cluster Manager gestisce tutte queste attività, applicando quindi le best practice e rendendo le operazioni online notevolmente più semplici, più veloci e meno soggette a errori.

R: Può fare entrambe le cose. MySQL Cluster Manager consente di controllare l'intero cluster come un'unica entità, supportando allo stesso tempo il controllo granulare dei singoli processi all'interno del cluster.

R: MySQL Cluster Manager è in grado di monitorare lo stato di salute del cluster sia a livello di sistema operativo, sia a livello di processo, mediante l'esecuzione automatica del polling di ogni nodo del cluster. Può rilevare se un processo o un server host sia attivo, spento oppure in sospeso, consentendo quindi di individuare e risolvere i problemi nonché di effettuare il ripristino più rapidamente.

R: MySQL Cluster Manager integra ed estende le funzionalità di gestione esistenti attraverso l'automazione di attività che in precedenza dovevano essere svolte manualmente da un amministratore. Come dimostrato nell'esempio precedente, un processo che richiedeva 46 comandi manuali ora è ridotto a un singolo comando, poiché ogni sua fase è stata completamente automatizzata.

In termini di creazione di script o persino di sviluppo di un sistema di gestione personalizzato, le attività di sviluppo, testing e manutenzione manuali di tali progetti richiedono molto tempo, sono costose e sono potenzialmente soggette a errori. Nel caso di molte attività di manutenzione, il ricorso a questo tipo di attività è eliminato da MySQL Cluster Manager.

Attraverso l'automazione, MySQL Cluster Manager semplifica la gestione del cluster, riducendone allo stesso tempo i costi, i rischi e le attività di manutenzione.

R: Sì. MySQL Cluster dispone di una funzionalità di auto-riparazione, che riavvia automaticamente i Data Node guasti senza alcun intervento manuale. MySQL Cluster Manager estende questa funzionalità attraverso il monitoraggio e il recupero automatico dei nodi SQL e dei Management Node. Ciò consente la perfetta e completa auto-riparazione del cluster, con il totale ripristino delle operazioni e delle funzionalità delle applicazioni.

R: Sì, fatta eccezione per i nodi dell'applicazione che usano l'API NDB nativa (ad esempio i nodi che accedono al cluster tramite le interfacce dirette C++, il connettore di cluster per Java, OpenLDAP, ecc.).

R: No. Per garantire l'alta disponibilità delle operazioni, MySQL Cluster Manager è indipendente dagli effettivi processi del database, quindi se un Management Agent è interrotto oppure aggiornato, ciò non influisce in alcun modo sull'esecuzione del database. Quando un agente o l'host a esso associato non è disponibile, MySQL Cluster Manager continua a operare sui nodi attivi rimanenti.

R: MySQL Cluster Manager è implementato come insieme di agenti, ciascuno in esecuzione su ogni host fisico contenente i nodi (processi) MySQL Cluster da gestire. L'amministratore collega il client mysql a uno di questi agenti, quindi gli agenti comunicano e lavorano gli uni con gli altri per eseguire le operazioni sui nodi del cluster.

R: Quando si usa MySQL Cluster Manager per gestire un'implementazione di MySQL Cluster, l'amministratore non deve più modificare i file di configurazione (ad esempio config.ini e my.cnf), poiché questi file sono creati e mantenuti dagli agenti. Di fatto, se questi file fossero modificati manualmente, le modifiche sarebbero sovrascritte dalle informazioni di configurazione contenute negli agenti.

Tutti i processi che costituiscono l'implementazione di MySQL Cluster sono avviati, riavviati e interrotti da MySQL Cluster Manager. Ciò comprende i Data Node, i Management Node e i MySQL Server Node.

In modo analogo, quando si usa MySQL Cluster Manager, le attività di gestione non devono essere eseguite dall'amministratore attraverso il comando ndb_mgm (che collega direttamente al Management Node, quindi gli agenti non avrebbero visibilità su alcuna delle operazioni eseguite da esso).

R: L'introduzione di MySQL Cluster Manager non elimina la necessità dei Management Node, che continuano a rivestire alcuni ruoli importanti:

• Quando i Data Node sono avviati (o riavviati), si collegano ai Management Node per recuperare i propri dati di configurazione (il Management Node a sua volta recupera i dati dai file di configurazione creati dagli agenti);
• Quando si interrompe o si riavvia un Data Node attraverso MySQL Cluster Manager, la variazione dello stato è eseguita in realtà dal Management Node;
• I Management Node possono continuare ad agire da "arbitri" (per evitare situazioni di split-brain). Per tale motivo è importante continuare ad eseguire questi processi su host separati dai Data Node;
• Alcune informazioni, come ad esempio quelle sull'utilizzo della memoria, non sono ancora disponibili con MySQL Cluster Manager, ma sono ottenibili con lo strumento ndb_mgm.

R: Non esiste un processo miracoloso per gli agenti, quindi per ottenere il massimo livello di disponibilità l'amministratore potrebbe scegliere di usare un monitor dei processi per individuare l'inattività di un agente e riavviarlo automaticamente, ad esempio creando uno script in /etc/init.d

R: Sì. Quando i Management Agent sono riavviati, si risincronizzano automaticamente con gli altri agenti in esecuzione per garantire uniformità nella configurazione dell'intero cluster, senza alcun intervento da parte dell'amministratore.

R: Sì. Tutte le informazioni di configurazione di MySQL Cluster e gli identificatori dei processi sono mantenuti sul disco, pertanto non vanno persi in caso di guasti o riavvii di MySQL Cluster Manager.

R: MySQL Cluster Manager supporta la comunicazione asincrona tra ogni Management Agent per propagare in modo affidabile le richieste di riconfigurazione. Le configurazioni rimangono quindi uniformi su tutti i nodi del cluster.

Qualsiasi modifica è applicata solo quando tutti i nodi confermano di avere ricevuto la richiesta di riconfigurazione. Se uno o più nodi non ricevono la richiesta, al client viene comunicato un errore. Attraverso l'automazione del coordinamento delle richieste di riconfigurazione, si eliminano gli errori generati dalla distribuzione manuale dei file di configurazione.

R: Consultare la pagina delle piattaforme supportate.

R: MySQL Cluster 6.3 e versioni successive.

R: Attraverso le seguenti risorse:

• White paper su MySQL Cluster Manager