La nostra ultima versione di ClusterControl trasforma alcune delle attività più problematiche di MongoDB in un lavoro di soli 15 secondi. Sono state aggiunte nuove funzionalità per darti un maggiore controllo sul tuo cluster ed eseguire modifiche alla topologia:
- Convertire un replicaSet MongoDB in un cluster MongoDB con partizionamento orizzontale
- Aggiungi e rimuovi frammenti
- Aggiungi router shard a un cluster MongoDB con shard
- Disattiva o blocca un nodo
- Nuovi consulenti MongoDB
Descriveremo queste funzionalità aggiuntive in dettaglio di seguito.
Convertire un MongoDB ReplicaSet in un cluster MongoDB con partizionamento orizzontale
Poiché la maggior parte degli utenti di MongoDB inizierà con un replicaSet per archiviare il proprio database, questo è il tipo di cluster più utilizzato. Se si verificano problemi di ridimensionamento, è possibile ridimensionare questo replicaSet aggiungendo più secondari o aumentando la scalabilità orizzontale tramite partizionamento orizzontale. Puoi convertire un replicaSet esistente in un cluster partizionato, tuttavia questo è un processo lungo in cui potresti facilmente commettere errori. In ClusterControl abbiamo automatizzato questo processo, in cui aggiungiamo automaticamente i Configserver, i router shard e abilitiamo lo sharding.
Per convertire un replicaSet in un cluster partizionato, puoi semplicemente attivarlo tramite il menu a discesa delle azioni:
Questo aprirà un dialogo in due passaggi su come convertirlo in un frammento. Il primo passaggio consiste nel definire dove distribuire il Configserver e i router shard su:
Il secondo passaggio è dove archiviare i dati e quali file di configurazione devono essere utilizzati per il server di configurazione e lo shard router.
Al termine del processo di migrazione degli shard, la panoramica del cluster ora mostra gli shard anziché le istanze di replicaSet:
Dopo la conversione in un cluster partizionato, è possibile aggiungere nuovi frammenti.
Aggiungi o rimuovi frammenti da un cluster MongoDB con partizionamento orizzontale
Aggiunta di frammenti
Poiché uno shard MongoDB è tecnicamente un replicaSet, l'aggiunta di un nuovo shard implica anche la distribuzione di un nuovo replicaSet. All'interno di ClusterControl distribuiamo prima un nuovo replicaSet e poi lo aggiungiamo al cluster partizionato.
Dall'interfaccia utente di ClusterControl, puoi facilmente aggiungere nuovi shard con una procedura guidata in due passaggi, aperta dal menu a discesa delle azioni:
Qui puoi definire la topologia del nuovo shard.
Una volta che il nuovo shard è stato aggiunto al cluster, il router shard MongoDB inizierà ad assegnargli nuovi blocchi e il bilanciatore bilancerà automaticamente tutti i blocchi su tutti gli shard.
Rimozione dei frammenti
Rimuovere i frammenti è un po' più difficile che aggiungere un frammento, poiché ciò comporta lo spostamento dei dati sugli altri frammenti prima di rimuovere il frammento stesso. Per tutti i dati che sono stati suddivisi su tutti gli shard, questo sarà un lavoro eseguito dal bilanciatore MongoDB.
Tuttavia, qualsiasi database/raccolta non partizionato, a cui è stato assegnato questo shard come shard principale, deve essere spostato in un altro shard e creato il suo nuovo shard primario. Per questo processo, MongoDB deve sapere dove spostare questi database/raccolte non partizionati.
In ClusterControl puoi semplicemente rimuoverli tramite il menu a discesa delle azioni:
Ciò ti consentirà di selezionare lo shard che desideri rimuovere e lo shard in cui desideri migrare eventuali database primari:
Il processo che rimuove lo shard eseguirà quindi azioni simili a quelle descritte in precedenza:sposterà tutti i database primari nello shard designato, abiliterà il bilanciatore e quindi attenderà che sposti tutti i dati dallo shard.
Una volta rimossi tutti i dati, lo shard verrà rimosso dall'interfaccia utente.
Aggiunta di router shard MongoDB aggiuntivi
Dopo aver avviato la scalabilità orizzontale dell'applicazione utilizzando un cluster shard MongoDB, potresti aver bisogno di router shard aggiuntivi.
L'aggiunta di ulteriori router shard MongoDB è un processo molto semplice con ClusterControl, basta aprire la finestra di dialogo Aggiungi nodo dal menu a discesa delle azioni:
Ciò aggiungerà un nuovo router shard al cluster. Non dimenticare di impostare la porta predefinita corretta (27017) sul router.
Disattiva il server
Nel caso in cui desideri eseguire la manutenzione sul nodo primario in un replicaSet, è meglio che prima si "abbandoni" in modo corretto prima di portarlo offline. Abbandonare un primario significa sostanzialmente che l'host smette di essere un primario e diventa un secondario e non è idoneo a diventare un primario per un determinato numero di secondi. I nodi nel replicaSet MongoDB con potere di voto eleggeranno un nuovo primario con il primario dimesso escluso per il numero di secondi impostato.
In ClusterControl è stata aggiunta la funzionalità di riduzione come azione nella pagina Nodi. Per scendere, seleziona semplicemente questa come azione dal menu a discesa:
Dopo aver impostato il numero di secondi per le dimissioni e aver confermato, le primarie si dimetteranno e verrà eletta una nuova primaria.
Blocca un nodo
Questa funzionalità è simile al comando step down:ciò rende un determinato nodo non idoneo a diventare primario per un determinato numero di secondi. Ciò significa che potresti impedire che uno o più nodi secondari diventino primari quando abbandoni il primario e costringere un determinato nodo a diventare il nuovo primario in questo modo.
In ClusterControl è stata aggiunta la funzionalità di blocco del nodo come azione nella pagina Nodi. Per bloccare un nodo, seleziona semplicemente questa come azione dal menu a discesa:
Dopo aver impostato il numero di secondi e aver confermato, il nodo non sarà idoneo come primario per il numero di secondi impostato.
Nuovi consulenti MongoDB
Gli advisor sono mini programmi che forniscono consigli su problemi specifici del database. Abbiamo aggiunto tre nuovi consulenti per MongoDB. Il primo calcola la finestra di replica, il secondo controlla la finestra di replica e il terzo verifica la presenza di database/raccolte non partizionati.
Consulente del ritardo di replica MongoDB
Il ritardo di replica è molto importante da tenere d'occhio, se stai aumentando le letture aggiungendo più secondari. MongoDB utilizzerà questi secondari solo se non sono troppo indietro. Se il secondario presenta un ritardo di replica, rischi di distribuire dati obsoleti che sono già stati sovrascritti sul primario.
Per controllare il ritardo di replica, è sufficiente connettersi al primario e recuperare questi dati utilizzando il comando replSetGetStatus. Contrariamente a MySQL, il primario tiene traccia dello stato di replica dei suoi secondari.
Abbiamo implementato questo controllo in un consulente in ClusterControl, per garantire che il tuo ritardo di replica sia sempre controllato.
Consulente finestra di replica MongoDB
Proprio come il ritardo di replica, la finestra di replica è una metrica altrettanto importante da considerare. L'advisor lag ci informa già del numero di secondi in cui un nodo secondario si trova dietro il primario/master. Poiché l'oplog ha dimensioni limitate, avere uno slave lag impone i seguenti rischi:
- Se un nodo è troppo indietro, potrebbe non essere più in grado di recuperare il ritardo poiché le transazioni necessarie per recuperare non sono più nell'oplog del primario.
- Un nodo secondario in ritardo è meno favorito in un'elezione MongoDB per una nuova primaria. Se tutte le secondarie sono in ritardo nella replica, si verificherà un problema e quella con il ritardo minore verrà resa primaria.
- I secondari in ritardo sono meno favoriti dal driver MongoDB durante il ridimensionamento delle letture con MongoDB, inoltre aggiunge un carico di lavoro maggiore sui restanti secondari.
Se avessimo un nodo secondario in ritardo di alcuni minuti (o ore), sarebbe utile avere un consulente che ci informi di quanto tempo ci resta prima che la nostra prossima transazione venga eliminata dall'oplog. La differenza di tempo tra la prima e l'ultima voce nell'oplog è chiamata Finestra di replica. Questa metrica può essere creata recuperando il primo e l'ultimo elemento dall'oplog e calcolando la differenza dei relativi timestamp.
Nella shell MongoDB è già disponibile una funzione che calcola la finestra di replica per te. Tuttavia questa funzione è incorporata nella shell della riga di comando, quindi qualsiasi connessione esterna che non utilizza la shell della riga di comando non avrà questa funzione incorporata. Per questo motivo abbiamo creato un consulente che controllerà la finestra di replica e ti avviserà se superi una soglia preimpostata.
Consulente per raccolte e database non partizionati MongoDB
I database e le raccolte non partizionati verranno assegnati a uno shard primario predefinito dal router shard MongoDB. Ciò significa che il database o la raccolta è limitato alla dimensione di questo shard primario e, se scritto in grandi volumi, potrebbe esaurire tutto lo spazio su disco rimanente di uno shard. Una volta che ciò accade, lo shard ovviamente non funzionerà più. Pertanto è importante controllare tutti i database e le raccolte esistenti ed eseguire la scansione del database di configurazione per verificare che siano stati abilitati per lo sharding.
Per evitare che ciò accada, abbiamo creato un database non suddiviso e un consulente di raccolta. Questo consulente eseguirà la scansione di ogni database e raccolta e ti avviserà se non è stato suddiviso in partizioni.
ClusterControl ha migliorato la manutenibilità di MongoDB
Abbiamo fatto un grande passo avanti aggiungendo tutti i miglioramenti a ClusterControl per i replicaSet MongoDB e i cluster partizionati. Ciò migliora notevolmente l'usabilità di MongoDB e consente a DBA, sysop e devops di mantenere i propri cluster ancora meglio!
