{"id":91846,"date":"2020-08-19T19:41:57","date_gmt":"2020-08-19T17:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster"},"modified":"2020-08-19T19:41:57","modified_gmt":"2020-08-19T17:41:57","slug":"o-pereezde-s-redis-na-redis-cluster","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","title":{"rendered":"Sulla migrazione da Redis a Redis-cluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Sulla migrazione da Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/ea8bc47f73ef3b06ccfdf94d323592bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Quando si entra in un prodotto che si \u00e8 evoluto per pi\u00f9 di dieci anni, non sorprende affatto imbattersi in tecnologie obsolete. Ma cosa succede se tra sei mesi devi gestire un carico dieci volte superiore e il costo dei malfunzionamenti aumenta di centinaia di volte? In questo caso, hai bisogno di un ottimo Highload Engineer. Tuttavia, non avendo a disposizione uno, hanno deciso di affidare a me la risoluzione del problema. Nella prima parte dell'articolo parler\u00f2 di come siamo passati da Redis a Redis-cluster, mentre nella seconda parte dar\u00f2 consigli su come iniziare a utilizzare il cluster e su cosa fare attenzione durante l'operativit\u00e0.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1 id=\"vybor-tehnologii\">Scelta della tecnologia<\/h1>\n<p><\/p>\n<p>\u00c8 cos\u00ec male <em>Redis separato<\/em> (standalone redis) nella configurazione 1 master e N slave? Perch\u00e9 lo considero una tecnologia obsoleta?<\/p>\n<p><\/p>\n<blockquote><p>No, Redis non \u00e8 cos\u00ec male\u2026 Tuttavia, ci sono alcune imperfezioni che non si possono ignorare.<\/p><\/blockquote>\n<p><\/p>\n<ul>\n<li>\n<p>In primo luogo, Redis non supporta meccanismi di ripristino di emergenza dopo un guasto del master. Per risolvere questo problema, abbiamo utilizzato una configurazione che prevede il failover automatico degli indirizzi VIP a un nuovo master, cambiando il ruolo di uno degli slave e commutando gli altri. Questo meccanismo funzionava, ma non si pu\u00f2 etichettarlo come una soluzione affidabile. Prima di tutto, si verificavano falsi allarmi, e in secondo luogo, era una soluzione una tantum, e dopo che scattava era necessario un intervento manuale per riarmare la molla.<\/p>\n<p>\n<\/li>\n<li>\n<p>In secondo luogo, avere solo un master portava a problemi di sharding. Era necessario creare pi\u00f9 cluster indipendenti \"1 master e N slave\", poi distribuire manualmente i database su queste macchine e sperare che domani uno dei database non si espandesse cos\u00ec tanto da dover essere spostato su un'istanza separata.<\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Quali sono le opzioni?<\/p>\n<p><\/p>\n<ul>\n<li>La soluzione pi\u00f9 costosa e ricca \u00e8 Redis-Enterprise. Questa \u00e8 una soluzione confezionata con supporto tecnico completo. Anche se appare ideale dal punto di vista tecnico, non era adatta per motivi ideologici. <\/li>\n<li>Redis-cluster. Di serie offre il supporto per il failover del master e lo sharding. L'interfaccia \u00e8 quasi identica a quella della versione normale. Sembra promettente, discuteremo dei potenziali problemi in seguito.<\/li>\n<li>Tarantool, Memcache, Aerospike e altri. Tutti questi strumenti svolgono fondamentalmente lo stesso compito. Ma ognuno ha i propri svantaggi. Abbiamo deciso di non mettere tutte le uova in un solo paniere. Memcache e Tarantool li utilizziamo per altri compiti e, anticipando, posso dire che nella nostra esperienza abbiamo avuto pi\u00f9 problemi con loro.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"specifika-ispolzovaniya\">Specificit\u00e0 dell'uso<\/h1>\n<p><\/p>\n<p>Diamo un'occhiata a quali problemi abbiamo storicamente risolto con Redis e quale funzionalit\u00e0 abbiamo utilizzato:<\/p>\n<p><\/p>\n<ul>\n<li>Cache prima delle richieste a servizi remoti come 2GIS | Golang<br \/>\n<blockquote><p>GET SET MGET MSET \"SELEZIONA DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Cache prima di MYSQL | PHP<br \/>\n<blockquote><p>GET SET MGET MSET SCAN \"CHIAVE PER PATRON\" \"SELEZIONA DB\"\n<\/p><\/blockquote>\n<\/li>\n<li>Archivio principale per il servizio di gestione delle sessioni e delle coordinate degli autisti | Golang<br \/>\n<blockquote><p>GET SET MGET MSET \"SELEZIONA DB\" \"AGGIUNGI CHIAVE GEO\" \"OTTENERE CHIAVE GEO\" SCAN\n<\/p><\/blockquote>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Come potete vedere, nessuna matematica avanzata. Qual \u00e8 allora la complessit\u00e0? Analizziamo ogni metodo separatamente.<\/p>\n<p><\/p>\n<p>Sanitizer.replaceElementWithChildren()<br \/>\nDescrizione<br \/>\nCaratteristiche di Redis-cluster<br \/>\nSoluzione<\/p>\n<p>GET SET<br \/>\nScrivere\/leggere una chiave<\/p>\n<p>MGET MSET<br \/>\nScrivere\/leggere pi\u00f9 chiavi<br \/>\nLe chiavi saranno distribuite su nodi diversi. Le librerie pronte possono eseguire operazioni multiple solo all'interno di un unico nodo<br \/>\nSostituire MGET con pipeline di N operazioni GET<\/p>\n<p>SELECT DB<br \/>\nScegliere il database con cui lavoreremo<br \/>\nNon supporta pi\u00f9 database<br \/>\nConsolidare tutto in un unico database. Aggiungere prefissi alle chiavi<\/p>\n<p>SCAN<br \/>\nScorrere tutte le chiavi nel database<br \/>\nPoich\u00e9 abbiamo un solo database, scorrere tutte le chiavi nel cluster \u00e8 troppo costoso<br \/>\nMantenere un'invarianza all'interno di una singola chiave ed eseguire HSCAN su quella chiave. Oppure rinunciare completamente<\/p>\n<p>GEO<br \/>\nOperazioni con chiavi geografiche<br \/>\nLa chiave geografica non viene shardata<\/p>\n<p>KEY BY PATTERN<br \/>\nRicerca di una chiave per pattern<br \/>\nPoich\u00e9 abbiamo un solo database, cercheremo tra tutte le chiavi nel cluster. Troppo costoso<br \/>\nRinunciare o mantenere invarianti, come nel caso di SCAN<\/p>\n<p><\/p>\n<h1 id=\"redis-vs-redis-cluster\">Redis vs Redis-cluster<\/h1>\n<p><\/p>\n<p>Cosa perdiamo e cosa guadagniamo passando al cluster?<\/p>\n<p><\/p>\n<ul>\n<li>Svantaggi: perdiamo la funzionalit\u00e0 di pi\u00f9 database. \n<ul>\n<li>Se vogliamo memorizzare in un unico cluster dati logicamente non correlati, dovremo fare dei compromessi sotto forma di prefissi. <\/li>\n<li>Perdiamo tutte le operazioni 'sul database', come SCAN, DBSIZE, CLEAR DB e simili.<\/li>\n<li>Le operazioni multiple sono diventate significativamente pi\u00f9 complesse da implementare, poich\u00e9 potrebbe essere necessario accedere a pi\u00f9 nodi.<\/li>\n<\/ul>\n<\/li>\n<li>Vantaggi: \n<ul>\n<li>Resilienza con failover automatico del master.<\/li>\n<li>Sharding lato Redis.<\/li>\n<li>Trasferimento atomico e senza interruzioni dei dati tra i nodi.<\/li>\n<li>Aggiunta e ridistribuzione delle risorse e dei carichi senza interruzioni.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><\/p>\n<p><em>Direi che se non \u00e8 necessario garantire un alto livello di disponibilit\u00e0, non vale la pena migrare a un cluster, poich\u00e9 potrebbe essere un compito non banale. Ma se inizialmente si deve scegliere tra una versione separata e quella cluster, \u00e8 consigliabile optare per il cluster, in quanto non \u00e8 peggiore e, inoltre, allevier\u00e0 parte della vostra fatica.<\/em><\/p>\n<p><\/p>\n<h1 id=\"podgotovka-k-pereezdu\">Preparazione alla migrazione<\/h1>\n<p><\/p>\n<p>Iniziamo con i requisiti per la migrazione:<\/p>\n<p><\/p>\n<ul>\n<li>Deve essere senza soluzione di continuit\u00e0. Un'interruzione totale del servizio di 5 minuti non \u00e8 accettabile.<\/li>\n<li>Deve essere il pi\u00f9 sicuro e graduale possibile. Vogliamo avere un certo controllo sulla situazione. Non vogliamo trasferire tutto all'improvviso e pregare per un pulsante di ripristino.<\/li>\n<li>Minime perdite di dati durante la migrazione. Comprendiamo che sar\u00e0 molto difficile migrare in modo atomico, quindi accettiamo una certa desincronizzazione tra i dati nel Redis normale e in quello cluster.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"obsluzhivanie-klastera\">Manutenzione del cluster<\/h1>\n<p><\/p>\n<p>Poco prima della migrazione, \u00e8 importante pensare se possiamo sostenere il cluster:<\/p>\n<p><\/p>\n<ul>\n<li>Grafici. Utilizziamo Prometheus e Grafana per i grafici di utilizzo della CPU, della memoria occupata, del numero di client, delle operazioni GET, SET, AUTH, ecc.<\/li>\n<li>Esperienza. Immaginate che domani sotto la vostra responsabilit\u00e0 ci sia un enorme cluster. Se si guasta, nessuno tranne voi sar\u00e0 in grado di ripararlo. Se inizia a rallentare, tutti verranno da voi. Se serve aggiungere risorse o ridistribuire il carico, di nuovo a voi. Per non diventare grigi a 25 anni, \u00e8 fondamentale prevedere questi casi e testare in anticipo come la tecnologia si comporter\u00e0 in determinate azioni. Ne parleremo in dettaglio nella sezione 'Esperienza'.<\/li>\n<li>Monitoraggio e avvisi. Quando il cluster si rompe, vogliamo essere i primi a saperlo. Qui ci siamo limitati ad avvisare che tutti i nodi restituiscono le stesse informazioni sullo stato del cluster (s\u00ec, ci sono anche altre possibilit\u00e0). \u00c8 pi\u00f9 facile notare altri problemi tramite le notifiche dei servizi client Redis.<\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"pereezd\">Trasloco<\/h1>\n<p><\/p>\n<p>Come procederemo con la migrazione:<\/p>\n<p><\/p>\n<ul>\n<li>In primo luogo, \u00e8 necessario preparare la libreria per lavorare con il cluster. Come base per la versione in Go abbiamo preso go-redis e l'abbiamo leggermente modificata. Abbiamo implementato i metodi Multi tramite pipeline e abbiamo anche corretto un po' le regole di ripetizione delle richieste. Con la versione per PHP sono sorti pi\u00f9 problemi, ma alla fine abbiamo scelto php-redis. Recentemente hanno introdotto il supporto per il cluster, e a nostro avviso sembra funzionare bene.<\/li>\n<li>Successivamente, \u00e8 necessario configurare il cluster stesso. Questo si fa letteralmente con due comandi basati sul file di configurazione. Discuteremo ulteriormente la configurazione qui sotto.<\/li>\n<li>Per una transizione graduale utilizziamo la modalit\u00e0 di simulazione. Poich\u00e9 abbiamo due versioni della libreria con la stessa interfaccia (una per la versione normale, l'altra per il cluster), non \u00e8 difficile creare un wrapper che funzioni con la versione separata e nel contempo duplichi tutte le richieste al cluster, confronti le risposte e registri le discrepanze nei log (nel nostro caso in NewRelic). In questo modo, anche se durante il rilascio la versione cluster si rompe, il nostro ambiente di produzione non ne sar\u00e0 influenzato. <\/li>\n<li>Lanciando il cluster in modalit\u00e0 di simulazione, possiamo osservare tranquillamente il grafico delle discrepanze delle risposte. Se la percentuale di errori si sta lentamente ma inesorabilmente avvicinando a una piccola costante, significa che va tutto bene. Perch\u00e9 ci sono comunque delle discrepanze? Perch\u00e9 la scrittura nella versione separata avviene leggermente prima rispetto al cluster, e a causa di micro-latency i dati possono divergere. Resta solo da controllare i log delle discrepanze, e se tutte sono spiegabili dalla non atomicit\u00e0 della scrittura, possiamo procedere.<\/li>\n<li>Ora possiamo passare dalla modalit\u00e0 di simulazione. Scriveremo e leggeremo dal cluster, mentre duplichiamo nella versione separata. Perch\u00e9? Nel corso della prossima settimana vogliamo osservare il funzionamento del cluster. Se dovessimo scoprire che ci sono problemi durante i picchi di carico, o se abbiamo trascurato qualcosa, abbiamo sempre un rollback di emergenza al vecchio codice e dati attuali grazie alla modalit\u00e0 di simulazione.<\/li>\n<li>Bisogna spegnere la modalit\u00e0 di simulazione e smontare la versione separata. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"ekspertiza\">Esperienza<\/h1>\n<p><\/p>\n<p>Per prima cosa, un breve riassunto della struttura del cluster.<\/p>\n<p><\/p>\n<p>In primo luogo, Redis \u00e8 un archivio key-value. Come chiave si utilizzano stringhe arbitrarie. Come valori possono essere utilizzati numeri, stringhe e intere strutture. Ce ne sono moltissimi, ma per capire la struttura complessiva non \u00e8 importante.<br \/>\nIl livello di astrazione successivo alle chiavi \u00e8 rappresentato dagli slot (SLOTS). Ogni chiave appartiene a uno dei 16.383 slot. All'interno di ciascuno slot pu\u00f2 esserci un numero qualsiasi di chiavi. In questo modo, tutte le chiavi si suddividono in 16.383 insiemi non sovrapposti.<br \/>\n<img decoding=\"async\" alt=\"Sulla migrazione da Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/a5e4be23381b42287f693e01d5d59a99.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Inoltre, nel cluster devono essere presenti N master node. Ogni nodo pu\u00f2 essere rappresentato come un'istanza separata di Redis, che conosce tutto sulle altre nodi all'interno del cluster. Ogni master node contiene un certo numero di slot. Ogni slot appartiene solo a un master node. Tutti gli slot devono essere distribuiti tra i nodi. Se alcuni slot non sono distribuiti, le chiavi in essi contenute non saranno accessibili. Ha senso eseguire ogni master node su una macchina logica o fisica separata. Vale anche la pena ricordare che ogni nodo opera solo su un core, e se si desidera eseguire pi\u00f9 istanze di Redis su una singola macchina logica, assicurarsi che operino su core diversi (non abbiamo provato a farlo, ma in teoria dovrebbe funzionare). In sostanza, i master node garantiscono una normale sharding, e un numero maggiore di master node consente di scalare le richieste di scrittura e lettura.<\/p>\n<p><\/p>\n<p>Dopo che tutte le chiavi sono state distribuite su slot e gli slot sono stati distribuiti tra i master node, \u00e8 possibile aggiungere un numero arbitrario di slave node a ciascun master node. All'interno di ciascuna di queste coppie \"master-slave\" operer\u00e0 una normale replica. Gli slave sono necessari per scalare le richieste di lettura e per il failover in caso di guasto del master.<br \/>\n<img decoding=\"async\" alt=\"Sulla migrazione da Redis a Redis-cluster\" src=\"\/wp-content\/uploads\/2020\/08\/90feb7ef9dacb858d5f21edc214df14d.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Adesso parliamo delle operazioni che sarebbe utile saper eseguire.<\/p>\n<p><\/p>\n<p>Per accedere al sistema utilizzeremo Redis-CLI. Poich\u00e9 Redis non ha un unico punto di ingresso, \u00e8 possibile eseguire le seguenti operazioni su qualsiasi nodo. In ogni punto evidenzio separatamente la possibilit\u00e0 di eseguire l'operazione sotto carico.<\/p>\n<p><\/p>\n<ul>\n<li>La prima e pi\u00f9 importante operazione di cui avremo bisogno \u00e8: cluster nodes. Essa restituisce lo stato del cluster, mostrando l'elenco dei nodi, i loro ruoli, la distribuzione degli slot, ecc. Ulteriori informazioni possono essere ottenute tramite cluster info e cluster slots.<\/li>\n<li>Sarebbe utile poter aggiungere e rimuovere nodi. A questo scopo ci sono le operazioni cluster meet e cluster forget. Si prega di notare che cluster forget deve essere applicato a OGNI nodo, sia ai master che alle repliche. Mentre per cluster meet \u00e8 sufficiente chiamarlo su un solo nodo. Tale distinzione pu\u00f2 essere disorientante, quindi \u00e8 meglio conoscerla prima di mettere in produzione il cluster. L'aggiunta di un nodo avviene in modo sicuro durante il funzionamento e non influisce sul lavoro del cluster (il che \u00e8 logico). Tuttavia, se si intende rimuovere un nodo dal cluster, \u00e8 necessario assicurarsi che non siano rimasti slot su di esso (altrimenti si rischia di perdere l'accesso a tutte le chiavi su quel nodo). Non rimuovere il master che ha slave, altrimenti verr\u00e0 eseguita una votazione non necessaria per un nuovo master. Se sui nodi non ci sono pi\u00f9 slot, \u00e8 un piccolo problema, ma perch\u00e9 complicarsi la vita se si pu\u00f2 prima rimuovere gli slave.<\/li>\n<li>Se \u00e8 necessario forzare il cambio di posto tra master e slave, si pu\u00f2 usare il comando cluster failover. Invocandolo durante il normale funzionamento, bisogna tenere presente che durante l'esecuzione dell'operazione il master non sar\u00e0 disponibile. Solitamente, il passaggio avviene in meno di un secondo, ma non \u00e8 atomico. Puoi aspettarti che parte delle richieste al master in quel momento si concludano con un errore.<\/li>\n<li>Prima di rimuovere un nodo dal cluster, non devono rimanere slot. \u00c8 meglio ridistribuirli utilizzando il comando cluster reshard. Gli slot saranno trasferiti da un master a un altro. L'intera operazione pu\u00f2 richiedere alcuni minuti, a seconda del volume dei dati trasferiti; tuttavia, il processo di trasferimento \u00e8 sicuro e non influisce sul funzionamento del cluster. In questo modo, tutti i dati possono essere trasferiti da un nodo a un altro sotto carico, senza preoccuparsi della loro disponibilit\u00e0. Tuttavia, ci sono alcune sottigliezze. Prima di tutto, il trasferimento dei dati implica un certo carico sul nodo ricevente e sul nodo mittente. Se il nodo ricevente \u00e8 gi\u00e0 molto carico dal punto di vista della CPU, non dovreste sovraccaricarlo ulteriormente con l'accettazione di nuovi dati. In secondo luogo, appena il master mittente non avr\u00e0 pi\u00f9 slot, tutti i suoi slave passeranno immediatamente al master a cui questi slot sono stati trasferiti. E il problema \u00e8 che tutti questi slave vorranno sincronizzare i dati contemporaneamente. E sarete fortunati se si tratter\u00e0 di una sincronizzazione parziale e non completa. Tenete conto di questo e abbinare le operazioni di trasferimento degli slot e di disattivazione\/ trasferimento degli slave. Oppure sperate che abbiate un'adeguata riserva di capacit\u00e0.<\/li>\n<li>Cosa fare se, durante il trasferimento, scoprite di aver perso alcuni slot? Spero che questo problema non vi tocchi, ma in caso contrario, c'\u00e8 l'operazione cluster fix. Essa distribuir\u00e0 gli slot sui nodi in modo casuale, anche se con qualche difficolt\u00e0. Consiglio di testarne il funzionamento, rimuovendo preventivamente dal cluster un nodo con slot distribuiti. Poich\u00e9 i dati negli slot non distribuiti sono gi\u00e0 inaccessibili, \u00e8 troppo tardi per preoccuparsi di eventuali problemi di accessibilit\u00e0 di questi slot. D'altra parte, l'operazione non influenzer\u00e0 gli slot distribuiti.<\/li>\n<li>Un'altra operazione utile \u00e8 monitor. Essa consente di vedere in tempo reale l'intero elenco delle richieste che arrivano al nodo. Inoltre, \u00e8 possibile fare grep per verificare se \u00e8 presente il traffico desiderato.<\/li>\n<\/ul>\n<p><\/p>\n<p>Vale la pena menzionare anche la procedura di failover del master. In breve, esiste ed, a mio avviso, funziona molto bene. Tuttavia, non bisogna pensare che staccando il cavo dalla presa su una macchina con nodo master, Redis si commuti immediatamente e i client non notino la perdita. Nella mia esperienza, il passaggio richiede alcuni secondi. Durante questo tempo, una parte dei dati sar\u00e0 inaccessibile: viene rilevata l'inaccessibilit\u00e0 del master, i nodi votano per un nuovo master, i slave si commutano e i dati vengono sincronizzati. Il modo migliore per verificare autonomamente che lo schema funzioni \u00e8 effettuare delle prove locali. Avvia il cluster sul tuo laptop, applica un carico minimo, simula un crash (ad esempio, bloccando le porte), valuta la velocit\u00e0 di commutazione. A mio avviso, solo giocando in questo modo per un giorno o due, si pu\u00f2 essere certi che la tecnologia funzioni. Oppure, si pu\u00f2 sperare che il software utilizzato dalla met\u00e0 di Internet funzioni sicuramente.<\/p>\n<p><\/p>\n<h1 id=\"konfiguraciya\">Configurazione<\/h1>\n<p><\/p>\n<p>Spesso, la configurazione \u00e8 la prima cosa necessaria per iniziare a lavorare con lo strumento. E quando tutto \u00e8 in funzione, non si ha voglia di toccare la configurazione. Richiede uno sforzo particolare forzarsi a tornare alle impostazioni e controllarle attentamente. A quanto ricordo, abbiamo avuto almeno due seri problemi a causa della scarsa attenzione alla configurazione. Presta particolare attenzione ai seguenti punti:<\/p>\n<p><\/p>\n<ul>\n<li>timeout 0<br \/>\n<em>Tempo dopo il quale si chiudono le connessioni inattive (in secondi). 0 \u2014 non vengono chiuse<\/em><br \/>\nNon tutte le nostre librerie erano in grado di chiudere correttamente le connessioni. Disattivando questa impostazione, rischiamo di arrivare al limite massimo di clienti. D'altra parte, se esiste un problema del genere, la disconnessione automatica delle connessioni perse la mascherer\u00e0, e potremmo non accorgercene. Inoltre, non bisogna attivare questa impostazione quando si usano connessioni persistenti.<\/li>\n<li>Save x y &amp; appendonly yes<br \/>\n<em>Salvataggio di uno snapshot RDB.<\/em><br \/>\nDiscuteremo in dettaglio i problemi RDB\/AOF qui sotto.<\/li>\n<li>stop-writes-on-bgsave-error no &amp; slave-serve-stale-data yes<br \/>\n<em>Se attivato, il master smetter\u00e0 di accettare richieste di modifica in caso di errore nello snapshot RDB. Se la connessione con il master viene persa, lo slave pu\u00f2 continuare a rispondere alle richieste (yes). Oppure smetter\u00e0 di rispondere (no)<\/em><br \/>\nNon ci piace la situazione in cui Redis si trasforma in una zucca.<\/li>\n<li>repl-ping-slave-period 5<br \/>\n<em>Trascorso questo intervallo di tempo, inizieremo a preoccuparci che il master si sia rotto e sia tempo di eseguire la procedura di failover.<\/em><br \/>\nDovremo trovare manualmente un equilibrio tra falsi allarmi e attivazione del failover. Nella nostra pratica, questo \u00e8 di 5 secondi.<\/li>\n<li>repl-backlog-size 1024mb &amp; epl-backlog-ttl 0<br \/>\n<em>Esattamente quanti dati possiamo mantenere nel buffer per una replica disconnessa. Se il buffer si esaurisce, sar\u00e0 necessario sincronizzarsi completamente.<\/em><br \/>\nLa pratica suggerisce che \u00e8 meglio impostare un valore pi\u00f9 alto. Ci sono molte ragioni per cui una replica potrebbe iniziare a ritardare. Se sta rallentando, probabilmente il vostro master sta gi\u00e0 facendo fatica e una sincronizzazione completa sar\u00e0 l'ultima goccia.<\/li>\n<li>maxclients 10000<br \/>\n<em>Numero massimo di clienti simultanei.<\/em><br \/>\nDalla nostra esperienza, \u00e8 meglio impostare un valore pi\u00f9 alto. Redis gestisce perfettamente 10.000 connessioni. Assicurati solo che ci siano abbastanza socket nel sistema. <\/li>\n<li>maxmemory-policy volatile-ttl<br \/>\n<em>Regola secondo cui le chiavi vengono rimosse al raggiungimento del limite di memoria disponibile.<\/em><br \/>\nQui ci\u00f2 che conta non \u00e8 tanto la regola, quanto la comprensione di come avverr\u00e0. Redis merita un elogio per la sua capacit\u00e0 di lavorare normalmente al raggiungimento del limite di memoria. <\/li>\n<\/ul>\n<p><\/p>\n<h1 id=\"problemy-rdb-i-aof\">Problemi RDB e AOF<\/h1>\n<p><\/p>\n<p>Anche se Redis memorizza tutte le informazioni nella memoria volatile, esiste anche un meccanismo per salvare i dati su disco. Anzi, tre meccanismi:<\/p>\n<p><\/p>\n<ul>\n<li>RDB-snapshot \u2014 una copia completa di tutti i dati. Viene impostata tramite la configurazione SAVE X Y e letta come \u00abSalvare un'istantanea completa di tutti i dati ogni X secondi, se \u00e8 stato modificato almeno Y chiavi\u00bb.<\/li>\n<li>Append-only file \u2014 lista delle operazioni nell'ordine in cui vengono eseguite. Aggiunge nuove operazioni arrivate nel file ogni X secondi o ogni Y operazioni.<\/li>\n<li>RDB e AOF \u2014 combinazione dei due precedenti.<\/li>\n<\/ul>\n<p><\/p>\n<p>Tutti i metodi hanno i loro pregi e difetti, non elencher\u00f2 tutti, ma richiamo l'attenzione su aspetti che non sono cos\u00ec evidenti, secondo me.<\/p>\n<p><\/p>\n<p>Per prima cosa, per salvare un'istantanea RDB \u00e8 necessario chiamare FORK. Se ci sono molti dati, questo pu\u00f2 mettere in timeout l'intero Redis per un periodo che va da alcuni millisecondi a un secondo. Inoltre, il sistema deve allocare memoria per tale istantanea, il che porta alla necessit\u00e0 di mantenere sulla macchina logica un doppio margine di memoria: se a Redis sono stati dedicati 8 GB, sulla virtuale con esso devono essere disponibili 16.<\/p>\n<p><\/p>\n<p>In secondo luogo, ci sono problemi con la sincronizzazione parziale. In modalit\u00e0 AOF, durante il ripristino della connessione con lo slave, pu\u00f2 essere eseguita una sincronizzazione completa invece di quella parziale. Non ho capito perch\u00e9 accada. Ma vale la pena ricordarlo.<\/p>\n<p><\/p>\n<p>Questi due punti gi\u00e0 ci fanno riflettere su quanto siano necessari questi dati su disco, se tutto viene comunque duplicato dagli slave. I dati possono andare persi solo se tutti gli slave si guastano, e questo \u00e8 un problema di livello \"incendio nel centro dati\". Come compromesso, si potrebbe considerare di conservare i dati solo sugli slave, ma in tal caso \u00e8 necessario assicurarsi che questi slave non diventino mai master durante un ripristino d'emergenza (per questo esiste una configurazione della priorit\u00e0 degli slave nel loro file di configurazione). Noi, caso per caso, riflettiamo su se sia necessario salvare i dati su disco, e pi\u00f9 spesso rispondiamo \"no\".<\/p>\n<p><\/p>\n<h1 id=\"zaklyuchenie\">Conclusione<\/h1>\n<p><\/p>\n<p>In conclusione, spero di aver fornito una panoramica sull'operato di redis-cluster a chi non ne ha mai sentito parlare, e di aver messo in evidenza alcuni aspetti non evidenti per coloro che lo utilizzano da tempo.<br \/>\nGrazie per il tempo dedicato e, come al solito, i commenti sull'argomento sono benvenuti.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/citymobil\/blog\/515620\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435 \u0434\u0435\u0441\u044f\u0442\u043a\u0430 \u043b\u0435\u0442, \u0441\u043e\u0432\u0435\u0440\u0448\u0435\u043d\u043d\u043e \u043d\u0435 \u0443\u0434\u0438\u0432\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0432\u0441\u0442\u0440\u0435\u0442\u0438\u0442\u044c \u0432 \u043d\u0435\u043c \u0443\u0441\u0442\u0430\u0440\u0435\u0432\u0448\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438. \u041d\u043e \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u0447\u0435\u0440\u0435\u0437 \u043f\u043e\u043b\u0433\u043e\u0434\u0430 \u0432\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0434\u0435\u0440\u0436\u0430\u0442\u044c \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 \u0432 10 \u0440\u0430\u0437 \u0432\u044b\u0448\u0435, \u0430 \u0446\u0435\u043d\u0430 \u043f\u0430\u0434\u0435\u043d\u0438\u0439 \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u0441\u044f \u0432 \u0441\u043e\u0442\u043d\u0438 \u0440\u0430\u0437? \u0412 \u044d\u0442\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c \u043a\u0440\u0443\u0442\u043e\u0439 Highload Engineer. \u041d\u043e \u0437\u0430 \u043d\u0435\u0438\u043c\u0435\u043d\u0438\u0435\u043c \u0433\u043e\u0440\u043d\u0438\u0447\u043d\u043e\u0439 \u0442\u0430\u043a\u043e\u0432\u043e\u0433\u043e, \u0440\u0435\u0448\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0434\u043e\u0432\u0435\u0440\u0438\u043b\u0438 \u043c\u043d\u0435. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91847,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91846","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e \u043f\u0435\u0440\u0435\u0435\u0437\u0434\u0435 \u0441 Redis \u043d\u0430 Redis-cluster | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-19T17:41:57+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-19T17:41:57+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Sulla migrazione da Redis a Redis-cluster | ProHoster","description":"Entrando in un prodotto che si evolve maggiormente.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e \u043f\u0435\u0440\u0435\u0435\u0437\u0434\u0435 \u0441 Redis \u043d\u0430 Redis-cluster | ProHoster","og:description":"\u041f\u0440\u0438\u0445\u043e\u0434\u044f \u0432 \u043f\u0440\u043e\u0434\u0443\u043a\u0442, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0435.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/o-pereezde-s-redis-na-redis-cluster","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-19T17:41:57+00:00","article:modified_time":"2020-08-19T17:41:57+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91846","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:19:41","updated":"2022-10-03 14:54:15","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=91846"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/91846\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/91847"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=91846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=91846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=91846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}