I cluster di follower sono una funzionalità di ScaleGrid che consente di mantenere sincronizzati due sistemi di database indipendenti (dello stesso tipo). A differenza della clonazione o della replica, ciò ti consente di mantenere una copia attiva e puntuale dei tuoi dati di produzione. Questo cluster aggiuntivo, noto come cluster follower, può essere sfruttato per molteplici casi d'uso, inclusi l'analisi, l'ottimizzazione e il test delle prestazioni delle applicazioni per MongoDB, MySQL e PostgreSQL. In questo post del blog, tratteremo i tre scenari principali per sfruttare i cluster di follower per la tua applicazione.
In che modo i cluster di follower differiscono dalla replica?
A differenza di un clone statico, questi dati vengono importati in base a una pianificazione prestabilita in modo che il tuo cluster di follower sia sempre sincronizzato con il tuo cluster di produzione. Ecco alcuni modi critici in cui differisce dalla replica:
- Puoi controllare la frequenza con cui il sistema di destinazione si sincronizza dall'origine:una volta alla settimana, una volta al giorno o anche meno frequentemente. Questo aiuta a ridurre il carico sul sistema sorgente.
- Dato che sono due sistemi indipendenti, hai molta più flessibilità sui dati sincronizzati. Puoi avere credenziali utente diverse e persino rimuovere alcuni dati dalla destinazione in base ai requisiti di sicurezza (nota:ciò richiede script lato utente:non è una funzionalità integrata nei cluster di follower).
- Il sistema "follower" è scrivibile, quindi puoi usarlo come ambiente di staging per testare le modifiche alle tue applicazioni. Questo non è qualcosa che puoi fare su un nodo di replica.
Nota:ScaleGrid implementa i cluster follower utilizzando snapshot di archiviazione. Non è disponibile per le nostre offerte di database in memoria come l'hosting per Redis™*.
1. Configurazione sviluppo/test database
Ci siamo stati tutti:un pezzo di codice presumibilmente ben testato viene distribuito in produzione, e poi si scatena l'inferno. I flussi di lavoro di produzione falliscono o sono così lenti da essere praticamente inutilizzabili. Gli ingegneri vengono svegliati dai loro letti per avviare un'operazione antincendio in piena regola. Un mucchio di notti insonni dopo, quella temuta causa principale emerge.
L'applicazione si comporta in modo diverso nelle impostazioni di produzione e ingegneria.
In altre parole, l'abbiamo testato su "dati di prova". Che, a quanto pare, non assomigliava per niente ai dati di produzione. Assolutamente.
Il modo più ovvio per evitare questa situazione è eseguire test sui dati di produzione. Ovviamente non una produzione effettiva, che flirterà con il disastro. Su una copia clonata dei dati di produzione. Sebbene le preoccupazioni relative alla privacy e alla sicurezza dei dati lo rendano impraticabile in molti scenari, requisiti di privacy permettendo, questa è la soluzione migliore. Non abbiamo più bisogno di fare affidamento su ingegneri che generino set di dati appropriati:se trasmette i dati di test, trasmetterà i dati di produzione.
Ovvero, fino a quando i dati di test non cadono così lontano dalla sincronizzazione con la produzione da non essere più una buona approssimazione. E siamo tornati al punto di partenza.
È qui che entrano in gioco i cluster di follower.
Utilizzando i cluster di follower, puoi importare periodicamente i dati dal tuo database di produzione nel database di sviluppo/test. E poiché l'intera importazione viene eseguita utilizzando snapshot di archiviazione, anziché un dump logico, il processo è quasi istantaneo. Puoi pianificare le tue importazioni una volta ogni 24 ore, una volta alla settimana o qualsiasi frequenza si adatti al tuo scenario particolare.
Con i cluster di sviluppo e QA impostati per seguire il cluster di produzione, puoi stare tranquillo. Se la tua applicazione supera il set di dati di test, è sicuramente adatta per la distribuzione in produzione!
2. Analisi dei dati
Se hai lavorato come DBA, probabilmente hai avuto una conversazione con il tuo team sul rallentamento "misterioso" delle prestazioni del sistema in determinati momenti. Nella maggior parte dei casi, il colpevole risulta essere un lavoro di analisi che accede a tonnellate di dati e finisce per rallentare l'intero sistema.
In qualità di fornitore di DBaaS, abbiamo avuto questa conversazione più volte con i nostri clienti. Ecco le due opzioni che suggeriamo in genere:
- Se il processo di analisi è in esecuzione sul server primario/master, spostalo su un server secondario/di replica.
- Se il processo di analisi è già in esecuzione su un nodo secondario e il degrado delle prestazioni è inaccettabile, consigliamo di spostare i processi in un cluster di analisi dedicato.
Utilizzando la nostra funzione di cluster di follower, è molto facile mantenere un cluster di analisi aggiornato con i dati di produzione effettivi. Puoi creare una pianificazione follower per sincronizzare i dati più recenti dalla produzione appena prima che inizi il tuo lavoro di analisi.
La parte migliore? La sincronizzazione dei follower non esegue alcuna operazione a livello di database, ma ripristina semplicemente l'ultimo snapshot! Quindi, non c'è alcun impatto sul tuo cluster di produzione.
3. Segnalazione
Un altro caso d'uso comune in cui i nostri clienti utilizzano la funzione dei cluster di follower è per la generazione di report. I processi di reporting in genere vengono eseguiti di rado, ma accedono a grandi quantità di dati e occupano la maggior parte delle risorse di un cluster di database. Quando il degrado delle prestazioni è inaccettabile, consigliamo ai nostri clienti di spostare il carico di lavoro dei rapporti in un nuovo cluster.
Poiché le operazioni di reporting sono rare, molti dei nostri clienti preferiscono sfruttare la nostra funzione di pausa/ripresa per "mettere in pausa" i cluster di reporting quando non sono in uso. Questo aiuta a risparmiare enormemente sui costi di infrastruttura. In genere, i cluster di report sono anche molto più "piccoli" (minore CPU/RAM), per aiutare a ridurre i costi.
Dopo aver creato un cluster di follower dalla nostra interfaccia utente, puoi utilizzare questo flusso di lavoro per automatizzare il flusso dei rapporti:
- Utilizza la nostra API resume per riprendere il cluster.
- Aspetta finché il cluster non torna in esecuzione (puoi utilizzare la tua API get-status per questo scopo).
- Attiva un backup sul tuo cluster di produzione, se necessario (in genere, se nella tua produzione sono pianificati backup regolari, puoi saltare questo passaggio. Tuttavia, se desideri che i tuoi rapporti vengano eseguiti sui dati più recenti, questo è essenziale).
- Attendere il completamento del backup.
- Attiva un processo di sincronizzazione sul follower:trova l'ultimo snapshot sul cluster di origine e lo ripristina nella destinazione.
- Attendere il completamento del processo di sincronizzazione.
- Esegui le tue attività di reporting.
- Utilizza la nostra API di pausa per mettere in pausa il cluster fino al tuo prossimo lavoro di reporting!
Ritieni che i cluster di follower siano adatti al tuo caso utente particolare? Puoi imparare tutto su come distribuire e gestire i cluster di follower per MongoDB, MySQL e PostgreSQL nei nostri documenti di aiuto!
Se non sei sicuro se i cluster di follower siano la soluzione corretta per il tuo caso d'uso, lascia un commento o contattaci all'indirizzo [email protected] – noi siamo felici di discutere quale funzione si adatta meglio alle tue esigenze.
