FAQ: MySQL Cluster

» MySQL Cluster Database

Quesiti generali

1. Cos’è MySQL Cluster?
2. Cos’è MySQL Cluster Carrier Grade Edition?
3. Chi sono i clienti esistenti di MySQL Cluster?
4. Qual è la versione attuale di MySQL Cluster?
5. MySQL Cluster richiede hardware o software speciali?
6. Quali sono i requisiti di sistema di MySQL Cluster?
7. Come è possibile determinare se un carico di lavoro è adeguato per MySQL Cluster?
8. Quali sono le applicazioni ideali per MySQL Cluster?
9. È necessario testare/certificare nuovamente le applicazioni dopo il rilascio di una nuova versione di MySQL Cluster?

Quesiti tecnici

10. Quali sono le tipiche metriche per le prestazioni di MySQL Cluster?
11. Quanti server fisici servono come minimo per poter avere un’installazione Cluster?
12. È possibile suddividere i Data Node geograficamente?
13. Quali sono le API esistenti per l’accesso ai dati di MySQL Cluster?
14. Le interfacce per le applicazioni a 32-bit sono diverse da quelle a 64-bit?
15. MySQL Cluster può essere un buon database integrato?
16. Cos’è la MySQL Cluster Replication?
17. La replicazione è bidirezionale?
18. Quando si usa MySQL Cluster come database in memoria centrale, si rischia di smarrire dati?
19. MySQL Cluster offre un’opzione DISKLESS?

» MySQL Cluster Manager

20. MySQL Cluster Manager è un software open source?
21. Che cos’è MySQL Cluster Manager?
22. Quali sono i vantaggi di MySQL Cluster Manager?
23. Potete fornire un esempio pratico di un caso in cui MySQL Cluster Manager aiuterebbe ad aumentare la produttività e a ridurre il rischio di interruzioni?
24. Quali funzionalità di gestione offre MySQL Cluster Manager?
25. MySQL Cluster Manager gestisce l’intero cluster o soltanto singoli nodi all’interno del cluster?
26. Quali funzionalità di monitoraggio offre MySQL Cluster Manager?
27. Molte delle funzionalità di MySQL Cluster Manager sono già disponibili, oppure possono essere create attraverso degli script, quindi quali sono i vantaggi?
28. MySQL Cluster Manager può recuperare i nodi guasti?
29. MySQL Cluster Manager è quindi in grado di gestire, monitorare e ripristinare tutti i nodi di un cluster?
30. l guasto di un agent MySQL Cluster Manager influisce sulla disponibilità del database MySQL Cluster?
31. Come si implementa MySQL Cluster Manager sul database MySQL Cluster?
32. Come influisce MySQL Cluster Manager sulle precedenti metodologie di gestione di MySQL Cluster?
33. Sono ancora necessari i Management Node all’interno del cluster?
34. MySQL Cluster Manager può riavviare automaticamente gli agenti inattivi?
35. Gli agenti ripristinati da MySQL Cluster Manager possono risincronizzarsi automaticamente con gli altri agenti?
36. MySQL Cluster Manager mantiene i dati di configurazione tra un riavvio e l’altro?
37. Come fa MySQL Cluster Manager a garantire che la configurazione del cluster rimanga uniforme su tutti i nodi del cluster?
38. È possibile adattare MySQL Cluster Manager ai cluster già esistenti e implementati?
39. Posso usare MySQL Enterprise Monitor per monitorare l’uso di MySQL Cluster?
40. MySQL Cluster Manager suppora SNMP ?
41. MySQL Cluster Manager esegue il monitoraggio e la gestione della replicazione geografica?
42. MySQL Cluster Manager può gestire l’aggiunta di nuovi nodi nel Cluster?
43. Quali piattaforme sono supportate da MySQL Cluster Manager?
44. Quali versioni del database MySQL Cluster sono supportate da MySQL Cluster Manager?
45. Dove posso trovare maggiori informazioni su MySQL Cluster Manager?

MySQL Cluster Database - Quesiti generali

D: Cos’è MySQL cluster?

R: MySQL Cluster è un database transazionale open source progettato per garantire il costante e rapido accesso ai dati con velocità di elaborazione dei dati estremamente elevate. MySQL Cluster utilizza un’architettura “shared-nothing”, che non richiede alcun investimento in ulteriori infrastrutture per garantire la disponibilità dei dati al 99,999% senza alcun single point of failure.

MySQL Cluster supporta i dati in memoria principale e su disco, accessibili attraverso un’interfaccia SQL oppure (facoltativamente) attraverso un'interfaccia Java o C++ nativa ad alte prestazioni.

D: Cos’è MySQL Cluster Carrier Grade Edition?

R: MySQL Cluster Carrier Grade Edition (CGE) pone l’enfasi sulla scalabilità, l’adattabilità e le prestazioni. MySQL Cluster CGE include metodi ottimizzati di accesso ai dati, importanti nel settore delle comunicazioni, così come opzioni per la replicazione geografica e l’aggiunta di Data Node online.

D: Chi sono i clienti esistenti di MySQL Cluster?

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

D: Qual è la versione attuale di MySQL Cluster?

R: La versione attuale è MySQL Cluster 7.1. MySQL 5.1 è integrato e abbinato a MySQL Cluster. Per informazioni sui bundle visitare la pagina Documentazione.

D: MySQL Cluster richiede hardware o software speciali?

R: No, MySQL Cluster è stato progettato per essere eseguito su hardware di largo consumo. Utilizzando hardware specializzato si possono raggiungere livelli di prestazioni ancora superiori.

D: Quali sono i requisiti di sistema di MySQL Cluster?

R:

Sistema operativo:	Elenco delle piattaforme attualmente supportate »
CPU:	Intel/AMD x86, UltraSPARC
Memoria:	Minimo 1GB RAM
HDD:	3GB
Rete:	1+ nodi (Gigabit Ethernet - TCP/IP)

D: Come è possibile determinare se un carico di lavoro è adeguato per MySQL Cluster?

R: A causa della sua architettura distribuita e "shared nothing", è importante conoscere i tipi di carichi di lavoro più adatti a MySQL Cluster. La seguente tabella riassume gli aspetti chiave da prendere in considerazione per poter definire se MySQL Cluster sia adatto alle vostre esigenze.

È possibile utilizzare MySQL Cluster	È necessario abbinare altri storage engine MySQL
Elevato throughput in scrittura, risposte a bassa latenza	Dimensioni del database superiori a 2 TB
Disponibilità 99,999% con failover inferiore al secondo e ripristini automatici	Le righe richiedono più di 8 KB di memoria (esclusi i BLOB) e 128 campi
Requisiti di scalabilità non prevedibili	Necessità di memorizzare oggetti superiori a 2 MB
Accesso principalmente tramite chiavi primarie o sottocomponenti di chiavi primarie con più campi	Elevati volumi di reportistica che richiedano scansioni complete delle tabelle con join "complessi"
Join "semplici"	Supporto delle foreign key

Dovreste porvi inoltre le seguenti domande per capire se sia utile usare MySQL Cluster nei vostri progetti che richiedono i massimi livelli di disponibilità e prestazioni in tempo reale:

• Quale % del tempo è dedicata allo sviluppo di logica ridonante e failover per le applicazioni e i database?
• Quali sono le conseguenze quando l'applicazione non rispetta i requisiti di disponibilità e prestazioni?
• Quale percentuale del budget è spesa per il mantenimento di più RDBMS per soddisfare i requisiti dell’applicazione?
• Necessitate di supporto in fase di sviluppo e/o produzione per il vostro ambiente MySQL?

Vi invitiamo a leggere la nostra Evaluation Guide e le risorse sui prodotti per saperne di più su MySQL Cluster.

D: Quali sono le applicazioni ideali per MySQL Cluster?

R: Le tabelle da gestire con MySQL Cluster sono partizionate e distribuite su nodi separati. MySQL Cluster è un database multi-master con un’architettura parallela. Ciò permette di eseguire contemporaneamente elevati volumi di operazioni in lettura E in scrittura. Qualsiasi aggiornamento è immediatamente disponibile su tutti i nodi dell'applicazione (SQL o NDB API) che accedono ai dati conservati sui Data Node.

Poiché i carichi di scrittura sono distribuiti su tutti i Data Node, MySQL Cluster è in grado di offrire elevati livelli di scalabilità e throughput in scrittura nel caso di carichi di lavoro transazionali. Oltre ciò, MySQL Cluster è in grado di sfruttare molti nodi SQL che eseguono in parallelo le istruzioni, laddove ogni nodo gestisce più connessioni, supportando quindi le applicazioni transazionali altamente concorrenti.

Alla luce di quanto fino a qui descritto, la seguente tabella mostra un esempio di applicazioni nell’ambito delle quali MySQL Cluster è stato utilizzato con successo. Fate clic qui per vedere l’elenco completo dei casi di studio e delle applicazioni di MySQL Cluster.

• Authentication, Authorization & Accounting
• Server applicativi
• LDAP / RADIUS / Diameter Data Store
• Servizi di e-Commerce (ad es. carrello della spesa, transazioni di pagamento, evasione degli ordini, ecc.)
• Servizi per sottosistemi IP multimediali
• Nodi di rete intelligenti
• Servizi localizzati e Presence Management
• Message Store / Queue
• Trasmissione di contenuti mobili
• Portali e Application Store online
• Giochi online
• Elaborazione dei pagamenti
• Piattaforme per servizi di telecomunicazione e servizi a valore aggiunto
• Database per la gestione delle sottoscrizioni (ad es. HLR, HSS, ecc.)
• Servizi VoIP, IPTV e Video-on-Demand
• Gestione delle sessioni web

D: È necessario testare/certificare nuovamente le applicazioni dopo il rilascio di una nuova versione di MySQL Cluster

R: La decisione spetta al proprietario dell’applicazione e dipende solitamente dal rapporto tempo/lavoro necessario per testare nuovamente l’applicazione rispetto alla probabilità che si presentino problemi nel caso in cui l'applicazione fosse utilizzata senza nuovi test. Il proprietario dell’applicazione deve anche prendere in considerazione se sia necessaria una nuova valutazione delle prestazioni con la nuova versione di MySQL Cluster.

Sono due i motivi principali per cui un’applicazione potrebbe non funzionare correttamente dopo il passaggio a una nuova versione di MySQL Cluster:

• Modifiche funzionali o API intenzionalmente introdotte in MySQL Cluster
• Bug accidentalmente presenti nel codice della nuova versione

Le nuove versioni di MySQL Cluster (versione X.Y.Z) sono di tre tipi:

• Versione principale: contraddistinta dalla lettera X. Queste versioni introducono nuove funzionalità importanti, così come modifiche significative del codice. La probabilità che una versione principale introduca nella vostra applicazione nuovi bug o modifiche incompatibili a livello di funzionalità/API sono molto più alte rispetto alle versioni minori o di manutenzione.
• Versione minore: contraddistinta dalla lettera Y. Queste versioni introducono solitamente piccole modifiche a livello di funzionalità e codice (le modifiche sono minime rispetto alla versione di manutenzione più recente).
• Versione di manutenzione: contraddistinta dalla lettera Z. Queste versioni contengono bug fix e non contengono modifiche funzionali, quindi il rischio maggiore è che i bug fix introducano un nuovo problema.

Per aiutare i proprietari delle applicazioni a prendere una decisione, MySQL offre le seguenti risorse:

• Per le versioni principali e minori sono forniti white paper e webinar che descrivono le più importanti modifiche funzionali: http://www.mysql.com/products/cluster/resources.html
• La sezione "MySQL Cluster Development Roadmap" della MySQL Cluster Reference Guide offre una panoramica delle modifiche funzionali contenute in ciascuna versione principale e minore. La Reference Guide più recente si trova all'indirizzo http://dev.mysql.com/doc/#cluster
• Le modifiche contenute in una versione di manutenzione (in termini di descrizione dei bug risolti) sono descritte nel file "ChangeLog" incluso in ciascun rilascio.
• I rapporti riguardanti i bug aperti e risolti si trovano alla pagina http://bugs.mysql.com

Vi invitiamo a leggere la nostra Evaluation Guide e le risorse sui prodotti per saperne di più su MySQL Cluster.

MySQL Cluster Database - Quesiti tecnici

D: Quali sono le tipiche metriche per le prestazioni di MySQL Cluster?

R:

• Disponibilità
  • 99.999% (<5 min downtime / anno)
• Performance
  • Tempi di risposta: 2-5 milliseconi (con replicazione sincrona e accesso via API NDB)
  • Throughput di 10.000+ transazioni replicate/sec. su un 2 Node Cluster, con 1 CPU per nodo (configurazione minima)
  • Throughput di 100.000.000+ transazioni replicate/sec. su un 4 Node Cluster, con 2 CPU per nodo (configurazione di fascia bassa)
• 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 (16GB, 32GB, ecc.) per Data Node

MySQL Cluster offre un “in-memory database” distribuito*, quindi nel caso delle richieste atomiche è estremamente veloce e prevedibile, ma l’architettura distribuita non è ideale nel caso di query complesse con un’elevata quantità di join. Le prestazioni migliori sono ottenibili se l’applicazione è consapevole della distribuzione (tutti i record accessibili da parte della transazione sono conservati e serviti dallo stesso Data Node). Usando l’API NDB, le transazioni possono essere eseguite in batch, per migliorare ulteriormente le prestazioni.

*MySQL Cluster supporta inoltre i dati basati su disco, per aumentare ulteriormente la flessibilità e la scalabilità offerte dal database.

D: Quanti server fisici sono necessari per creare una configurazione Cluster minima?

R: Per garantire un buon livello di ridondanza sono consigliati 2 MySQL Server Node, 2 Data Node e 1 Management Node. Ai fini della semplice valutazione, è possibile avere solo un singolo server fisico, sebbene ciò consentirebbe di effettuare solo una semplice valutazione di base.

D: È possibile suddividere i Data Node geograficamente?

R: Non è una pratica raccomandata o supportata. Non dovrebbe esserci troppa latenza tra i Data Node presenti nel cluster, quindi tipicamente si troveranno nello stesso data center o rack. Tuttavia, MySQL Cluster CGE supporta la replicazione geografica, quindi si potrebbero avere 2 installazioni Cluster separate in una configurazione master-slave. Questo tipo di replicazione è asincrona ed è quindi diversa dalla replicazione sincrona tra Data Node di una singola installazione Cluster; la latenza della rete non influisce quindi sulle prestazioni dell’applicazione.

D: Quali sono le API esistenti per l’accesso ai dati di MySQL Cluster?

R: Le applicazioni possono essere sviluppate usando uno qualsiasi dei connettori MySQL. MySQL Cluster CGE fornisce inoltre la connettività nativa attraverso C++, Java, OpenJPA, LDAP e HTTP.

D: Le interfacce per le applicazioni a 32-bit sono diverse da quelle a 64-bit?

R: No, le interfacce sono le stesse.

D: MySQL Cluster può essere un buon database integrato?

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

D: Cos’è la replicazione geografica di MySQL Cluster?

R: La replicazione geografica consente di eseguire replicazioni asincrone su cluster separati geograficamente. Questa procedura è spesso usata in caso di Disaster Recovery.

D: La replicazione è bidirezionale?

R: Sì, MySQL Cluster CGE supporta la replicazione unidirezionale e bidirezionale.

D: Quando si usa MySQL Cluster come database in memoria centrale, si rischia di smarrire dati?

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 transazioi e i checkpoint file persistono sul disco, con frequenza configurabile. Inoltre, sul disco possono essere conservati dati non indicizzati.

D: MySQL Cluster offre un’opzione DISKLESS?

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 dei dati in caso di guasto del Cluster
3. Nessun backup

Nel caso dell'opzione "No logging", Cluster continua a creare i file di log, ma non vi è alcun checkpoint dei dati su disco.

Inizio pagina

MySQL Cluster Manager FAQ

Q: MySQL Cluster Manager è un software open source?

A:No. MySQL Cluster Manager è disponibile solo quale parte del database MySQL Cluster Carrier Grade Edition (CGE). Per acquistare licenze di MySQL Cluster CGE, contattate il Team di vendita MySQL

Q: Che cos’è MySQL Cluster Manager?

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

Q: Quali sono i vantaggi di MySQL Cluster Manager?

A: Utilizzando MySQL Cluster Manager, i Database Administrator (DBA) e i Systems Administrator sono più produttivi e possono concentrarsi sulle iniziative IT più strategiche, rispondendo più rapidamente alle esigenze degli utenti. Allo stesso tempo, si riducono notevolmente i rischi legati alle interruzioni del database che in precedenza erano causati da errori manuali di configurazione.

Q: Potete fornire un esempio pratico di un caso in cui MySQL Cluster Manager aiuterebbe ad aumentare la produttività e a ridurre il rischio di interruzioni?

A: Per esempio, le operazioni di manutenzione che prevedono il riavvio di un database MySQL Cluster e che in precedenza richiedevano 46 comandi manuali¹ , impegnando ² ore e mezza del tempo di un DBA2 , possono ora essere eseguite con un singolo comando e sono completamente automatizzate grazie a MySQL Cluster Manager, riducendo

• La complessità e i costi amministrativi;
• Il rischio di interruzioni, grazie all’automazione dei processi di configurazione e gestione delle modifiche;
• La scrittura di comandi personalizzati e lo sviluppo e manutenzione di strumenti di gestione sviluppati internamente.

Q: Quali funzionalità di gestione offre MySQL Cluster Manager?

A: Gli amministratori possono creare ed eliminare interi cluster, così come avviare, interrompere e riavviare il cluster con un unico comando. Gli amministratori non devono quindi riavviare più manualmente ciascun Data Node nella corretta sequenza, 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 di 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 siano necessari dei 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 ad errori.

Q: MySQL Cluster Manager gestisce l’intero cluster o soltanto singoli nodi all’interno del cluster?

A: 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.

Q: Quali funzionalità di monitoraggio offre MySQL Cluster Manager?

A: MySQL Cluster Manager è in grado di monitorare lo stato di salute del cluster sia a livello di sistema operativo, sia a livello di processo, esaminando ciascun 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 più rapidamente.

Q: Molte delle funzionalità di MySQL Cluster Manager sono già disponibili, oppure possono essere create attraverso degli script, quindi quali sono i vantaggi?

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

In termini di scripting o persino di sviluppo di un sistema di gestione personalizzato, le attività di sviluppo, testing e manutenzione di tali progetti richiedono molto tempo, sono costose e sono potenzialmente soggette ad 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.

Q: MySQL Cluster Manager può recuperare i nodi guasti?

A: Sì. MySQL Cluster dispone di una capacità 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 Management. Ciò favorisce la completa auto-riparazione del cluster, ripristinando completamente le operazioni e le funzionalità delle applicazioni.

Q: MySQL Cluster Manager è quindi in grado di gestire, monitorare e ripristinare tutti i nodi di un cluster?

A: Sì, fatta eccezione per i nodi dell’applicazione che usano l’API NDB (per esempio i nodi che accedono al Cluster tramite le interfacce C++, il Cluster Connector for Java, OpenLDAP, ecc.)

Q: Il guasto di un agent MySQL Cluster Manager influisce sulla disponibilità del database MySQL Cluster?

A: 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 il suo host associato non è disponibile, MySQL Cluster Manager continua ad operare sui nodi attivi rimanenti.

Q: Come si implementa MySQL Cluster Manager sul database MySQL Cluster?

A: MySQL Cluster Manager si implementa 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.

Q: Come influisce MySQL Cluster Manager sulle precedenti metodologie di gestione di MySQL Cluster?

A: Quando si usa MySQL Cluster Manager per gestire un’implementazione di MySQL Cluster, l’amministratore non deve più modificare i file di configurazione (per 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 simile, 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).

Q: Sono ancora necessari i Management Node all’interno del cluster?

A: 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 riavvia un Data Node attraverso MySQL Cluster Manager, la variazione di stato è eseguita di fatto dal Management Node;
• I Management Node possono continuare ad agire da “arbitri” (per evitare situazioni “split-brain”). Per questo 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.

Q: MySQL Cluster Manager può riavviare automaticamente gli agenti inattivi?

A: ThNon 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, per esempio creando uno script in /etc/init.d

Q: Gli agenti ripristinati da MySQL Cluster Manager possono risincronizzarsi automaticamente con gli altri agenti?

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

Q: MySQL Cluster Manager mantiene i dati di configurazione tra un riavvio e l’altro?

A: Sì. Tutte le informazioni di configurazione di MySQL Cluster e gli identificatori dei processi sono mantenuti sul disco, sopravvivendo quindi ai guasti o ai riavvii del MySQL Cluster Manager.

Q: Come fa MySQL Cluster Manager a garantire che la configurazione del cluster rimanga uniforme su tutti i nodi del cluster?

A: MySQL Cluster Manager supporta la comunicazione asincrona tra ciascun 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 aver ricevuto la richiesta di riconfigurazione. Se uno o più nodi non riceve la richiesta, al client è comunicato un errore. Attraverso l’automazione della comunicazione e sincronizzazione delle richieste di riconfigurazione, si eliminano gli errori generati dalla distribuzione manuale dei file di configurazione.

Q: È possibile adattare MySQL Cluster Manager ai cluster già esistenti e implementati?

A: Si può, ma soltanto attraverso una procedura manuale:
http://dev.mysql.com/doc/mysql-cluster-manager/1.0/en/mcm-install-cluster-migrating.html.

Attenzione: questa operazione prevede l’interruzione del cluster quando tutti i nodi sono riavviati, così da poter utilizzare i nuovi file di configurazione definiti per la gestione del cluster. La procedura è fornita “così com’è” ed è responsabilità dell’utente ottimizzarla in base alle proprie esigenze, verificandone il funzionamento prima di cercare di applicarla al database.

Q: Posso usare MySQL Enterprise Monitor per monitorare l’uso di MySQL Cluster?

A: MySQL Enterprise Monitor può essere usato per monitorare i MySQL Server API Node che sono utilizzati all’interno di un cluster, ma non per monitorare i Data Node o i Management Node.

È importante notare che, sebbene MySQL Enterprise Monitor non esegua attualmente il monitoraggio dei Data Node, esso può essere usato per la gestione e il monitoraggio dei MySQL Server API Node che fanno parte di un cluster. MySQL Enterprise Monitor è in grado di monitorare lo stato dei MySQL Server API Node, fornendo metriche sulle prestazioni. Offre inoltre i benefici del Query Analyzer, segnalando le query che stanno consumando troppo tempo e risorse.

Q: MySQL Cluster Manager suppora SNMP?

A: Non nella prima versione.

Q: MySQL Cluster Manager esegue il monitoraggio e la gestione della replicazione geografica?

A: Non nella prima versione.

Q: MySQL Cluster Manager può gestire l’aggiunta di nuovi nodi nel Cluster?

A: Non nella prima versione.

Q: Quali piattaforme sono supportate da MySQL Cluster Manager?

A: Consultare la pagina delle piattaforme supportate.

Q: Quali versioni del database MySQL Cluster sono supportate da MySQL Cluster Manager?

A: MySQL Cluster 6.3 e versioni superiori.

Q: Dove posso trovare maggiori informazioni su MySQL Cluster Manager?

A: Attraverso le seguenti risorse:

• Whitepaper su MySQL Cluster Manager

¹Sulla base di una configurazione MySQL Cluster costituita da 4 x MySQL Cluster Data Node , 2 x MySQL Server SQL Node e 2 x MySQL Cluster Management Node implementati su server singoli (8 x in totale). L’operazione complessiva è costituita dai seguenti comandi: 1 x controlli preliminari dello stato del cluster; 8 x comandi ssh per server; 8 x comandi per-process stop; 4 x scp dei file di configurazione (2 x mgmd & 2 x mysqld); 8 x comandi per-process start; 8 x controlli dei processi avviati e re-joined; 8 x verifiche del completamento del processo; 1 x verifica del completamento dell’intero cluster. Il conteggio totale dei comandi non include la modifica manuale di ciascun file di configurazione, le operazioni di preparazione con copia del nuovo software su ciascun host e la definizione della sua posizione: Mysql> add package --basedir=/usr/local/mysql_7_0_7 7.0;

²Sulla base di un DBA che esegua il riavvio di 4 x MySQL Cluster Data Node, ognuno con 6 GB di dati, e che esegua 10.000 operazioni al secondo http://www.clusterdb.com/mysql-cluster/mysql-cluster-data-node-restart-times/

Inizio pagina