IT knowledge base
CTRL+F per cercare la tua parola chiave

Tira fuori il cavo, strizza il bicchiere

Istruzioni per la diagnosi dei problemi nel funzionamento delle banche dati in caso di incidente.

Ciao. Tutti al lavoro a volte hanno giorni "neri". Per me, questi giorni sono guasti del servizio che rendono i sistemi non disponibili per gli utenti finali. Fortunatamente, questo non accade spesso, ma ognuno di questi casi mi fa riflettere a lungo sulle domande "cosa abbiamo sbagliato".

Dopo uno degli incidenti, mi sono sorpreso a pensare che la diagnosi del motivo dell'indisponibilità del servizio richiedesse troppo tempo. Gli ingegneri coinvolti nella risoluzione dell'incidente non hanno agito in maniera del tutto coordinata: hanno testato le stesse ipotesi e hanno passato del tempo a studiare opzioni del tutto “fantastiche”. Non ho dubbi sulle qualifiche dei ragazzi, quindi nell'ambito della riflessione lo attribuisco alla situazione stressante dell'incidente.

Affinché la prossima volta che la diagnosi e l'eliminazione delle cause dell'incidente fossero più rapide, noi, insieme all'ingegnere DevOps Alexei Popov, abbiamo deciso di scrivere un "piano antincendio": un'istruzione passo passo che potrebbe essere utilizzata per indagare su un incidente.

L'ultimo problema riguardava il funzionamento del database e l'interazione dell'applicazione web con il database. Pertanto, l'istruzione riguarda la diagnosi del database. Voglio anche notare che questo schema non è la verità ultima, ma solo la nostra esperienza, trasferita su "carta". Non abbiamo volutamente incluso cause troppo “esotiche” dell'incidente, poiché il diagramma diventa troppo ingombrante e illeggibile.

Sarei grato per commenti e descrizioni di problemi simili che hai avuto.

Pertanto, quando si verifica un arresto anomalo, di solito è facile diagnosticare se il problema è nell'applicazione, sul lato del database o nell'interazione tra il database e l'applicazione. Ma cosa fare dopo spesso non è chiaro - e qui suggerisco di utilizzare il seguente schema:

Di seguito descriverò ogni passaggio dello schema e gli strumenti che utilizziamo per ogni passaggio.

Passaggio 1. Verifica del carico dei core del processore sul server del database (Load Average)

Nella maggior parte dei casi, la manifestazione esterna di un problema nel funzionamento del database è l'aumento del carico sui core del processore del server del database. Penso che LOAD AVERAGE sia la migliore metrica per diagnosticare questo fatto. Allo stesso tempo, mi piace di più questa metrica in termini di core del processore del server di database. LA (Load Average) per core più di 1 non è valido. Ciò significa che la richiesta al database attende un po' di tempo prima di essere eseguita.

Per tenere traccia di questa metrica, utilizziamo il sistema di monitoraggio Zabbix con la possibilità di configurare avvisi su vari canali. Un esempio di tale metrica in caso di incidente:

Passaggio 2. Il carico del core del processore (LA) è cambiato di oltre il 30% rispetto alla stessa ora dello stesso giorno della settimana?

Quando si verifica un grave incidente, Los Angeles di solito cresce come una valanga. Tuttavia, anche un aumento del 30% è un segno di una sorta di anomalia. Se la crescita di LA è evidente e supera il limite specificato, è il momento di andare al passaggio 3 e controllare il numero di connessioni al database. Se non c'è crescita di LA, allora è meglio andare al passaggio 27.

FASE 3. Verifica del numero di connessioni dell'applicazione al database e delle dinamiche della sua crescita

Questo è un altro indicatore che dà una chiara comprensione del fatto che qualcosa è andato storto con il database. Più interessante qui è la dinamica della crescita del numero di connessioni al database.

Usiamo lo stesso Zabbix come strumento di monitoraggio. Il numero massimo consentito di connessioni al database può essere trovato eseguendo il comandoSHOW_MAX_CONNECTIONS ...

Passaggio 4. Il numero di connessioni al database è aumentato notevolmente in un breve periodo di tempo?

Molto probabilmente, noterai che il numero di connessioni è aumentato bruscamente o è aumentato gradualmente, ha raggiunto il limite ed è diventato pari. A seconda di ciò, devi andare al passaggio 7 o al passaggio 5.

Passaggio 5. Aumentare il numero di connessioni installando un estrattore di connessione

Se vedi che il numero di connessioni non è cambiato drasticamente, ma è cresciuto gradualmente e ha raggiunto il limite consentito, è molto probabile che il carico sul database abbia superato il limite e le richieste siano accodate, in attesa che la connessione venga rilasciata . Una soluzione rapida in questo caso è aumentare il numero di connessioni. Questo può essere fatto nella configurazione del database usando l'attributoMAX_CONNECTIONS ... Non lasciarti trasportare da questo, perché un gran numero di connessioni non è normale. Tale misura dovrebbe essere utilizzata come medicina d'urgenza per guadagnare tempo per ulteriori studi sul problema.

Richiamo la tua attenzione sul fatto che se il tuo database ha una o più repliche (ci mancherebbe anche quelle a cascata), allora prima di tutto è necessario cambiare il numero di connessioni su queste repliche, e partendo dall'ultima nel cascata. E solo allora - al maestro.

Se l'applicazione funziona ancora in modo ottimale, dovresti pensare di utilizzare un puller di connessione (il più comune è PGBuncer). Questo servizio si occupa della gestione della connessione e lo fa in modo abbastanza efficiente. L'applicazione per interagire con il database contatterà PGBuncer, il quale, a sua volta, reindirizzerà la richiesta al database tramite le sue connessioni. Puoi leggere di più su questa tecnologia qui: https://habr.com/ru/company/okmeter/blog/420429/ .

Mi sono anche imbattuto in una situazione in cui è stato installato l'estrattore di connessione (PGBouncer), ma ha avuto problemi. Vale la pena prestare attenzione al limite delle connessioni al database nel puller stesso. Inoltre, PGBuncer (non conosco i suoi analoghi) ha una caratteristica di implementazione: quando si stabilisce una connessione al database, viene aperto un descrittore di file. Pertanto, su grandi ecosistemi caricati con un gran numero di servizi e database che utilizzano un PGBuncer centralizzato, potrebbe esserci un problema con la limitazione del numero di descrittori di file aperti contemporaneamente a livello di sistema operativo.

Passaggio 7. Verifica dei blocchi e delle query in sospeso nel database

Questo è uno dei motivi più comuni per i rallentamenti del database. Spesso, migrazioni di grandi dimensioni possono presentare blocchi a lungo termine su più righe nelle tabelle del database. Di conseguenza, le query che accedono a queste linee non possono essere eseguite e rimangono in sospeso (riprendendo la connessione). Dopo poco tempo, la maggior parte delle connessioni potrebbe essere occupata e già tutte le richieste (anche quelle che non interessano le righe bloccate) iniziano a languire anticipatamente.

Il modo per testare questa ipotesi è la dinamica con il numero di richieste al database nello stato "IDLE IN TRANSACTION". Utilizziamo un meccanismo per misurare periodicamente il numero di richieste in questo stato, con l'output del grafico corrispondente in Grafana.

Passaggio 8. Ci sono molti blocchi e query in sospeso nel database

Se la risposta a questa domanda è sì, allora siamo già a metà strada verso una soluzione. Andiamo a provare la soluzione rapida (passaggio 9). Se è presente un numero elevato di blocchi (ripeto: un numero elevato ! I blocchi sono normali, se il loro numero standard) e non vengono osservate richieste in sospeso, andare al passaggio 11.

PASSO 9. Elimina tutti i blocchi nel database

A volte una tale misura porta a una rapida vittoria. Se, ad esempio, una transazione durante la quale è stata aperta una richiesta è stata avviata da un servizio che presentava un problema e il servizio era già sovraccarico/ridistribuito, una semplice eliminazione dei blocchi può essere d'aiuto.

Questo può essere fatto eliminando il processo che ha causato il blocco -pg_terminate_backend(pid); ...

Passaggio 10. La situazione è migliorata?

Quindi, abbiamo rimosso tutti i blocchi nel database. In pochi minuti la situazione potrebbe tornare alla normalità. Allora siamo grandi. Oppure non venire, quindi vai al passaggio 37.

Passaggio 11. Ottenere un elenco di query eseguite, ordinate per frequenza e costo

Per fare ciò, devi eseguire il comandoPG_STAT_STATEMENTS ... Quando chiamiamo questa utility, raccoglieremo un registro di tutte le query eseguite nel database e saremo in grado di stimare quali di esse occupano attualmente la maggior parte delle risorse (in termini di frequenza e costo di esecuzione). Si consiglia di azzerare le statistiche accumulate in precedenza con il comandoPG_STAT_STATEMENTS_RESET () e ricominciare a montarlo, già durante l'incidente. Pertanto, riceveremo statistiche pure con il costo delle richieste già nella fase dell'incidente.

Passaggio 12. Esaminare SlowLog (richieste che richiedono più tempo del tempo critico)

Questa operazione, forse, darà immediatamente una risposta alle query che devono essere ottimizzate, senza ulteriori dispendiose analisi dei risultati.PG_STAT_STATEMENTS ... Solitamente, eseguiamo entrambi i passaggi (11 e 12) in parallelo per avere immediatamente un'idea del carico sul database. Un altro vantaggioSlowLog - dopo aver ricevuto un campione da esso per un periodo di tempo più lungo, saremo in grado di isolare le query che prima non c'erano (cioè sono state eseguite rapidamente), ma a un certo punto hanno iniziato a essere eseguite lentamente, molto probabilmente a causa di un incidente .

Passaggio 13. Esistono query "costose" che in precedenza venivano eseguite rapidamente?

A questo punto, il problema principale è determinare la velocità con cui le richieste sono state eseguite in precedenza (prima dell'arresto anomalo). UtilitàSlowLog ePG_STAT_STATEMENTS darà una comprensione della velocità di esecuzione delle query "ora". Ma per trovare una richiesta problematica, devi capire quanto velocemente le richieste sono state eseguite in precedenza. A tale scopo, consiglio di utilizzare utilità aggiuntive: PGHero o NewRelic. Si tratta di strumenti abbastanza utili che consentono di comprendere le dinamiche della velocità di esecuzione delle query.

Se è possibile notare una diminuzione della velocità di esecuzione di alcune query specifiche, andare al passaggio 14. Se non è stato possibile correggere una diminuzione della velocità di esecuzione di una query, andare al passaggio 30.

Passaggio 14. Verifica del piano per le richieste "costose"

Se sei riuscito a identificare una richiesta specifica con una dinamica negativa pronunciata della velocità di esecuzione, il passaggio successivo è un'analisi dettagliata della richiesta utilizzando l'utilitàEXPLAIN ANALYZE ... I dettagli su come funziona questo comando e su come interpretare i risultati della sua esecuzione sono disponibili qui: https://thoughtbot.com/blog/reading-an-explain-analyze-query-plan .

Passaggio 15. Hai bisogno di un nuovo indice?

Sulla base dell'analisi dei risultati dell'esecuzione del comandoEXPLAIN ANALYZE si può concludere se è necessario un nuovo indice o se sono sufficienti quelli esistenti. Se è necessario un nuovo indice, benvenuto al passaggio 29. Se ci sono indici sufficienti, vai al passaggio 16.

Passaggio 16. L'indice è presente, ma non utilizzato (ed è stato utilizzato prima)

Questa situazione può verificarsi in qualsiasi momento. Quando si sceglie come elaborare i dati, il pianificatore di query si basa sulle statistiche accumulate dei contenuti delle tabelle nel database. E ad un certo punto nel tempo, le statistiche potrebbero iniziare a dare risultati errati, e quindi il pianificatore deciderà di non usare l'indice, anche se avrebbe dovuto essere usato in modo amichevole. Questo può accadere anche dopo grandi migrazioni di dati o quando c'è un eccesso di una certa quantità di dati nella tabella, in cui il pianificatore sceglierà di enumerare in sequenza invece di usare un indice.

In ogni caso, se vedi che l'indice viene creato ed è, ma allo stesso tempoEXPLAIN ANALYZE indica che non è utilizzato, quindi andare al passaggio 17. Se l'indice è utilizzato, andare al passaggio 20.

FASE 17. Aggiornamento delle statistiche della tabella del database

Una semplice operazione che può salvare la giornata. Per raccogliere statistiche con maggiore precisione, basta eseguire il comandoANALYZE oset default_statistics_target = 500; ANALYZE ... 500 è il fattore quantitativo della tabella "campione" che PostgreSQL sceglie per calcolare le statistiche. Puoi leggere di più su come funzionano le statistiche e le mappe di visibilità qui: https://postgrespro.ru/docs/postgrespro/10/routine-vacuuming .

Passaggio 18. La situazione è migliorata?

Se, dopo aver aggiornato le statistiche del contenuto delle tabelle, la velocità di esecuzione della query è tornata alla normalità - evviva, evviva, siamo a posto. Se il problema persiste, andare al passaggio 19.

Passaggio 19. Ricostruire l'indice

Lascia che ti ricordi che abbiamo una richiesta problematica che in precedenza era stata eseguita rapidamente, ma ora ha iniziato improvvisamente a essere eseguita lentamente. Per accelerare l'esecuzione di una query, esiste un indice nel database, ma non viene utilizzato dal pianificatore di query. L'aggiornamento delle statistiche non ha aiutato.

Ricreiamo l'indice. Questo può essere fatto con il comandoREINDEX (leggi di più qui: https://postgrespro.ru/docs/postgrespro/9.5/sql-reindex ).

Vai al passaggio 31.

Passaggio 20. Profilo di lavoro con la cache (Hit / Miss)

La richiesta ha iniziato improvvisamente a rallentare, ma l'indice è in uso. Il passaggio successivo consiste nel verificare se la cache del database funziona. Per questo, la metrica Hit / Miss del numero di record ricevuti da una query dalla cache o recuperati dal database "da zero" è più adatta. Usiamo Zabbix per questi scopi.

Se con una metrica simile concludi che il profilo di lavoro con la cache è cambiato, vai al passaggio 21. Altrimenti, il passaggio 22 ci sta aspettando.

Passaggio 21. Espandi la dimensione del buffer del database

Questa misura ci darà un po' di tempo, ma solo se sarà possibile espandere di una quantità significativa. In effetti, trasferiremo parte dei dati del database nella cache, il che accelererà l'accesso a questi dati. L'espansione della dimensione del buffer della cache del DB è determinata dal parametroshared_buffers nella configurazione del database.

Attenzione: espandere la dimensione del buffer della cache richiederà un riavvio del database. Tuttavia, se tutto sta già rallentando spudoratamente per te, questo non dovrebbe essere un grosso problema.

Passaggio 22. I parametri della query sono stati modificati?

A volte può essere che la velocità di esecuzione della query diminuisca a causa di parametri aggiuntivi che fungono da condizione per il recupero dei dati. Ad esempio, se il filtro era un attributo i cui identificatori erano elencati nel predicato della query (where atribut_id in (id1, id2, id3) ), e ad un certo punto, invece di 2-3 identificatori, diverse centinaia hanno iniziato a essere trasmesse, è ovvio che la velocità di esecuzione della query diminuirà. Potrebbe essere necessario creare un nuovo indice che tenga conto di questa variante della selezione dei dati. Questo può accadere dopo il rilascio successivo di un sistema adiacente che legge i dati dal tuo servizio.

Per identificare una situazione simile è sufficiente estrarre dai log una richiesta simile, che era qualche giorno fa, e confrontarla con la stessa richiesta ora. Di solito la differenza nel numero drammatico di parametri di query è immediatamente evidente. Se trovi una situazione del genere, vai al passaggio 26. Altrimenti, vai al passaggio 23.

Passaggio 23. Il numero e la dimensione dei file temporanei sono cambiati?

Durante l'esecuzione di una query, il database genera dati temporanei che vengono utilizzati per recuperare i dati nel formato desiderato. Di solito, per questo, viene utilizzata la RAM, la cui quantità è determinata dal parametroWork_Mem configurabile nella configurazione del database. Se questa memoria è insufficiente, il database può creare file temporanei, che sono dati intermedi scritti per l'esecuzione della query. Per determinare una situazione del genere, utilizziamo la metrica in base al numero di file temporanei dello stesso Zabbix.

Se noti che il numero di file temporanei creati dal database è aumentato notevolmente, vai al passaggio 25. Altrimenti, vai al passaggio 24.

Passaggio 24. Ricrea l'indice

Ricreiamo l'indice. Questo può essere fatto con il comandoREINDEX (puoi leggere maggiori dettagli qui: https://postgrespro.ru/docs/postgrespro/9.5/sql-reindex ).

Vai al passaggio 31.

Passaggio 25. Aumenta la dimensione di Work_mem o ottimizza la richiesta sul lato dell'applicazione

Se noti che il numero di file temporanei creati è aumentato notevolmente, come soluzione rapida (ma pericolosa!), puoi provare ad aumentare la dimensione della memoria disponibile per l'elaborazione dei dati temporanei. Questo attributo controllaWork_mem configurabile nella configurazione del database.

Vorrei sottolineare che questa non è una soluzione per la situazione, ma semplicemente guadagnare tempo per una soluzione più sistematica. Parallelamente, è necessario analizzare la query e le modalità per ottimizzarla.

Vai al passaggio 31.

Passaggio 26. Crea un nuovo indice in base ai nuovi parametri di input

Il modo più veloce in questa situazione sarebbe creare un nuovo indice (possibilmente composto), che renderebbe più facile recuperare i dati, tenendo conto dei nuovi parametri di input della query. Se possibile, vai al passaggio 27. Altrimenti, vai al passaggio 28.

Passaggio 27. Crea un nuovo indice in base ai nuovi parametri di input della query

Qui tutto è chiaro: la richiesta è identificata, anche il nuovo set di attributi è chiaro: creiamo un nuovo indice. Tuttavia, consiglio di aggiornare le statistiche della tabella in modo che il nuovo indice venga applicato immediatamente dal pianificatore di query. Quindi, vai al passaggio 31.

Passaggio 28. Correzione della richiesta stessa dal lato dell'applicazione, escludendo nuovi parametri

Probabilmente, in alcuni casi, sarà più semplice e veloce ottimizzare immediatamente la richiesta lato applicazione (oppure eseguire il rollback delle modifiche che hanno portato alla modifica dei parametri della richiesta). Vai al passaggio 31.

Passaggio 29. Crea un nuovo indice

Nel caso in cui, in base ai risultatiEXPLAIN ANALYZE si è capito che il database ha bisogno di un nuovo indice, quindi il modo più semplice è crearlo. Questo può essere fatto con il comandoCREATE INDEX specificando il parametroCONCURRENTLY per una build non bloccante (puoi leggere di più qui: https://postgrespro.ru/docs/postgresql/11/sql-createindex ). Quindi, vai al passaggio 31.

Passaggio 30. Verifica dell'influenza di fattori aggiuntivi (interazione con il disco rigido, processi di terze parti sul server, lavoro di altri database)

Forse il problema delle prestazioni non è causato dal nostro database stesso, ma da fattori esterni. Pertanto, è importante controllare e tagliare la loro influenza. Innanzitutto può essere:

  • funzionamento di dischi rigidi/sistemi di archiviazione dati;
  • ha caricato le query su altri database situati sullo stesso server del tuo;
  • processi di terze parti in esecuzione sul server del database (ad esempio, il lavoro di un antivirus);
  • creazione di database di replica, durante i quali viene creata un'istantanea dei dati dal tuo master;
  • problemi di rete e perdita di comunicazione tra l'applicazione e il database.

Se vengono rilevati tali fattori, provare a eliminarli e andare al passaggio 31.

Passaggio 31. La situazione è migliorata?

La situazione si è stabilizzata e il problema è stato risolto? Siamo grandi! Altrimenti, è il momento di raccogliere tutti gli uomini reali e contattare l'amministratore del DB.

Passaggio 32. Ci sono molti blocchi e query in sospeso nel database?

Per analogia con lo Step 8, controlliamo la dinamica del numero di richieste al database nello stato "IDLE IN TRANSACTION". Utilizziamo un meccanismo per misurare periodicamente il numero di richieste in questo stato, con l'output del grafico corrispondente in Grafana. Vorrei sottolineare che i blocchi sono normali, si verificheranno periodicamente. Ma se hai un forte aumento del numero di blocchi, vai al passaggio 37. Se non sei riuscito a diagnosticare un aumento del numero di blocchi e richieste in sospeso, vai al passaggio 33.

Passaggio 33. Controllo dei registri di PG Bouncer e dei registri dell'applicazione quando si è connessi a PG Bouncer

A volte l'applicazione non accede direttamente al database, ma tramite un pool di connessioni specializzato (il più comune è PGBuncer). Ma a parte i suoi numerosi vantaggi, rappresenta ancora un altro punto di fallimento. Pertanto, se non c'è un aumento di LA nel database e non ci sono blocchi e richieste in sospeso, si consiglia di esaminare attentamente i registri del pool di connessioni e l'applicazione che si connette ad esso. Vai al passaggio 34.

Passaggio 34. Hai problemi con PGBuncer?

Se sono presenti errori nei registri, si consiglia di passare al passaggio 35. In caso contrario, passare al passaggio 36.

Passaggio 35. Correzione del problema con PGBuncer / collegamento dell'applicazione direttamente al database, bypassando PGBuncer

Se il problema nel lavoro di PGBuncer può essere risolto rapidamente (è comprensibile ed è ovvio come può essere risolto), allora fallo (non posso dare consigli esatti, dipende dal tipo di problema). Se ciò non può essere fatto in breve tempo, ti consiglio di provare a connettere l'applicazione bypassando PGBuncer direttamente al database. Detto questo, vale la pena aumentare il numero di connessioni al database consentite, poiché l'applicazione di solito non le gestisce in modo efficiente come PGBuncer.

Si tratta di una misura temporanea per ripristinare rapidamente la disponibilità del servizio. Questa non è una soluzione al problema!

Vai al passaggio 31.

Passaggio 36. Consultazione dell'analista richiesta

Se sei arrivato a questo punto, significa che il caso è atipico e per risolvere il guasto devi coinvolgere uno specialista di analisti di database di profilo ristretto. Per un rapido tuffo nel problema, ti consiglio di trasmettergli immediatamente tutti i log e le metriche che hai studiato fino a questo punto.

Passaggio 37. È stata apportata una modifica recente allo schema dei dati del database?

La situazione in cui, inaspettatamente, senza una dichiarazione di guerra nel database, cresce un numero anomalo di blocchi e richieste in sospeso è estremamente rara. Molto spesso questa è una conseguenza di un rilascio o di una migrazione con una modifica nello schema dei dati del database. Se ciò è accaduto di recente, vai al passaggio 45. Se non sono state apportate modifiche allo schema dei dati, vai al passaggio 38.

Passaggio 38: controllo dei registri DB (o PG_STAT_ACTIVITY) per identificare la query che ha causato il blocco

I blocchi vengono avviati da una sorta di richiesta. Pertanto, il passaggio successivo consiste nell'identificare la query che ha generato i blocchi più frequenti. Questo può essere fatto in base ai registri del database o utilizzando l'utilitàPG_STAT_ACTIVITY ...

Passaggio 39. Identificazione del servizio richiedente che ha causato il blocco

Dopo aver identificato la richiesta che ha causato il blocco, dobbiamo determinare il servizio o l'applicazione che ha avviato questa richiesta. Il modo più semplice per farlo si basa sui registri del database.

Passaggio 40. Il servizio che ha avviato la richiesta funziona correttamente?

A volte ci sono situazioni in cui, quando accede al database, l'applicazione apre una transazione, esegue una prima operazione (ad esempio,Select per ottenere un'istantanea dei dati), quindi elabora i dati secondo la sua logica interna e scrive i dati aggiornati all'interno della stessa transazione. In questo caso, se sorgono problemi nel funzionamento di tale applicazione, può verificarsi una situazione in cui, all'apertura di una transazione, non si verificano operazioni successive e chiusura della transazione. Ciò si traduce in blocchi e richieste in sospeso.

È necessario controllare l'applicazione che ha avviato le richieste che portano al blocco. Se vengono rilevati problemi con il servizio che ha avviato la richiesta di blocco, andare al passaggio 43. Altrimenti, benvenuto al passaggio 41.

Passaggio 41. Ci sono state versioni recenti del servizio che hanno attivato la richiesta di blocco?

Se i rilasci del servizio che avvia le richieste di blocco coincidono nel tempo con l'inizio del problema nel database, è buona norma eseguire il rollback dell'ultimo rilascio. Questo potrebbe aiutare (vai al passaggio 43).

Se non ci sono stati rilasci, vai al passaggio 44.

Passaggio 42. Diagnosticare e riparare il servizio che ha avviato le richieste di blocco

Abbiamo stabilito che le richieste che causano il blocco sono generate da un servizio che sta riscontrando problemi al momento. L'ipotesi è che errori nel funzionamento del servizio portino a errori nel funzionamento del database. Sarà consigliabile ripristinare l'ultima versione (se presente) o concentrarsi sulla correzione di questo servizio. Se riportiamo il servizio alla normalità, è probabile che il database inizi a funzionare come previsto.

Dopo aver corretto il servizio, andare al passaggio 31.

Passaggio 43. Eseguire il rollback dell'ultima versione

Per accelerare la risoluzione del problema, il modo più semplice consiste nel ripristinare l'ultima versione del servizio che avvia le richieste del problema. In questo caso, vedremo immediatamente se il problema è scomparso o meno. Dopo questa operazione, passare al punto 31.

Passaggio 44. Consultazione dell'analista richiesta

Se sei arrivato a questo punto, significa che il caso è atipico e per risolvere il guasto devi coinvolgere uno specialista di analisti di database di profilo ristretto. Per un rapido tuffo nel problema, ti consiglio di trasmettergli immediatamente tutti i log e le metriche che hai studiato fino a questo punto.

Passaggio 45. È possibile eseguire il rollback della migrazione?

Abbiamo scoperto che c'era una versione recente nel database problematico che ha cambiato lo schema dei dati. Il modo più rapido e semplice è eseguire il rollback di una migrazione di modifica dello schema. Se possibile, andare al passaggio 46. Se non è possibile, andare al passaggio 47.

Passaggio 46. Eseguire il rollback della migrazione

Devi eseguire il rollback dell'ultima migrazione o delle migrazioni. Il modo più semplice per farlo è tramite Alembic, se lo stai usando. Quindi vai al passaggio 31.

Passaggio 47. Attendi il completamento della migrazione

La soluzione migliore è attendere il completamento della migrazione. Ci saranno meno problemi in futuro. Quindi vai al passaggio 31.

Conclusione

Spero che questo diagramma ti aiuti in una situazione difficile (ad esempio, durante un incidente). Ha raccolto una parte significativa dei nostri disturbi e delle nostre esperienze traumatiche.

Vorrei esprimere la mia profonda gratitudine ad Alexey Popov per il suo aiuto nella preparazione dell'articolo. Senza la sua recensione e i suoi consigli, l'articolo non sarebbe così completo e accurato.