(c) Yandex.Immagini
Tutti i personaggi sono inventati, i marchi appartengono ai rispettivi proprietari, eventuali somiglianze sono casuali e, in effetti, questa è la mia «opinione soggettiva, per favore non rompete la porta…».
Abbiamo una notevole esperienza nella traduzione di sistemi informativi con logica nel DB da un SGBD a un altro. In relazione al decreto governativo n. 1236 del 16.11.2016, spesso si tratta di una migrazione da Oracle a Postgresql. Possiamo raccontarti come organizzare il processo in modo massimo ed efficiente e indolore; oggi parleremo delle peculiarità dell'uso di un cluster e dei problemi che si possono incontrare nella costruzione di sistemi distribuiti ad alta carico con logica complessa nelle procedure e nelle funzioni.
Spoiler: sì, cap, RAC e pg multimaster sono soluzioni molto diverse.
Supponiamo che tu abbia già trasferito tutta la logica da plsql a pgsql. I tuoi test di regressione vanno abbastanza bene, ora ovviamente stai pensando alla scalabilità, dato che i test di carico non ti soddisfano molto, soprattutto sull'hardware che era stato previsto nel progetto inizialmente per quell'altro SGBD. Supponiamo che tu abbia trovato una soluzione da un fornitore locale, «Postgres Professional», con un'opzione chiamata «multimaster», disponibile solo nella versione «massima» di «Postgres Pro Enterprise» e, da quanto descritto, sembra molto simile a ciò di cui hai bisogno, e durante il primo studio superficiale verrà in mente il pensiero: «Oh! È proprio ciò che serve al posto del RAC! E inoltre con supporto tecnico in Patria!».
Ma non affrettarti a rallegrarti, e in seguito descriveremo perché è importante conoscere queste sfumature, poiché è difficile prevederle, anche leggendo bene la documentazione sul prodotto. Considera se sarai disposto a aggiornare frequentemente le versioni del SGBD direttamente in produzione, poiché alcuni difetti non sono compatibili con l'operatività industriale e sono difficili da identificare durante il test.
Inizia con una lettura attenta della sezione «multimaster» - «limitazioni» sul sito del produttore.
La prima cosa con cui puoi trovarti a che fare sono le peculiarità del funzionamento delle transazioni in modalità cosiddetta «a due fasi», e a volte, oltre a riscrivere completamente la logica della tua procedura, non c'è modo di risolverlo. Ecco un semplice esempio:
crea tabella test1 (id intero, id1 intero);
inserisci in test1 valori (1, 1),(1, 2);
ALTER TABLE test1 AGGIUNGI VINCOLO test1_uk UNICO (id,id1) DIFFERIBILE INIZIALMENTE DIFFERITO;
aggiorna test1
imposta id1 =
caso id1
quando 1
allora 2
altrimenti id1 - segno(2 - 1)
fine
dove id1 è compreso tra 1 e 2;Si verifica un errore:
ERRORE: [MTM] Transazione MTM-1-2435-10-605783555137701 (10654) è abortita sul nodo 3. Controlla il suo registro per vedere i dettagli dell'errore.In seguito si può combattere a lungo con il deadlock nelle versioni 10.5, 10.6 e l'unico salvataggio noto che uccide tutto il senso del cluster è rimuovere le tabelle "problematiche" dal cluster, cioè effettuare make_table_local, ma questo permetterà almeno di lavorare, e non fermerà tutto a causa di attese di commit delle transazioni. Oppure aggiornare alla versione 11.2, che dovrebbe aiutare, ma potrebbe anche non farlo, non dimenticare di controllare.
In alcune versioni potresti ottenere un blocco ancora più misterioso:
username= mtm e backend_type = lavoratore in backgroundE in questa situazione l'unica soluzione è aggiornare la versione del DBMS a 11.2 o superiore, ma potrebbe anche non funzionare.
Alcune operazioni sugli indici possono portare a errori che indicano chiaramente che il problema è nel Bi-Directional Replication, nei log MTM vedrai direttamente BDR. È davvero 2ndQuadrant? No… abbiamo acquistato multimaster, è solo una coincidenza, è il nome della tecnologia.
[MTM] bdr non supporta i controlli degli indici
[MTM] 12124: REMOTO inizio abortire transazione 4083
[MTM] 12124: invia notifica di ABORT per transazione (5467) xid locale=4083 al coordinatore 3
[MTM] Ricevi messaggio logico ABORT_PREPARED per la transazione MTM-3-25030-83-605694076627780 dal nodo 3
[MTM] Abortisci la transazione preparata MTM-3-25030-83-605694076627780 stato InProgress dal nodo 3 originId=3
[MTM] MtmLogAbortLogicalMessage nodo=3 transazione=MTM-3-25030-83-605694076627780 lsn=9fff448 Se utilizzi tabelle temporanee, nonostante le affermazioni: "L'estensione multimaster esegue la replica dei dati in modo completamente automatico. Puoi eseguire transazioni in scrittura e lavorare con tabelle temporanee su qualsiasi nodo del cluster."
Allora in realtà vedrai che la replica non funziona su tutte le tabelle utilizzate nella procedura, se nel codice è presente la creazione di una tabella temporanea, e persino l'utilizzo di multimaster.remote_functions non aiuterà, dovrai aggiornare o riscrivere la tua logica nella procedura. Se hai bisogno di utilizzare contemporaneamente due estensioni multimaster e pg_pathman nel contesto di "Postgres Pro Enterprise" v 10.5, controlla che in questo semplice esempio:
CREA TABELLA measurement (
city_id int non nullo,
logdate data non nulla,
peaktemp int,
unitsales int
) PARTIZIONE PER INTERVALLO (logdate);
CREA TABELLA measurement_y2019m06 PARTIZIONE DI measurement PER VALORI DA ('2019-06-01') A ('2019-07-01');
inserisci in measurement valori (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
inserisci in measurement valori (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
inserisci in measurement valori (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
inserisci in measurement valori (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);Nei log dei nodi del DBMS iniziano a comparire questi errori:
…
PATHMAN_CONFIG non contiene la relazione 23245
> find_in_dynamic_libpath: tentando "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: tentando "\/opt\/\/…\/ent-10\/lib\/pg_pathman.so"
> DEBUG: find_in_dynamic_libpath: tentando "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: tentando "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) nome: unnamed; blockState: PREPARE; stato: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) nome: unnamed; blockState: DEFAULT; stato: INPROGR, xid/subid/cid: 0/1/0
> passato a timeline 1 valido fino a 0/0
…
Transazione MTM-1-13604-7-612438856339841 (6919) è abortita sul nodo 2. Controlla il suo log per vedere i dettagli dell'errore.
...
[MTM] 28295: REMOTE inizio abortire transazione 7017
…
[MTM] 28295: invia notifica di ABORT per transazione (6919) xid locale=7017 al coordinatore 1
Per scoprire di cosa si tratta, puoi rivolgerti all'assistenza, non l'hai comprata per niente.
Cosa fare? Esatto! Aggiornare a "Postgres Pro Enterprise" fino alla v 11.2
È importante sapere che la sequence, essendo un oggetto del database replicabile, non possiede un valore sequenziale in tutto il cluster, ogni sequence è locale per ogni nodo e se hai campi con vincoli unici che utilizzano sequence, puoi solo incrementare in modo equivalente al numero del nodo nel cluster, poiché più nodi ci sono nel cluster, più rapidamente aumenterai e la sequence, così come il int si esaurirà più velocemente di quanto ti aspetti. Per semplificare il lavoro con la sequence nel prodotto troverai anche la funzione alter_sequences, che eseguirà gli incrementi necessari su ogni sequenze in tutti i nodi, ma preparati che la funzione potrebbe non funzionare in tutte le versioni. Certamente puoi scriverla da solo, basandoti sul codice su github o modificandolo direttamente nel DBMS. In questo caso, i campi di tipo serialbigserial funzioneranno in modo più corretto, ma per usarli probabilmente dovrai riscrivere il codice delle tue procedure e funzioni. Potrebbe essere utile a qualcuno la funzione monotonic_sequences.
Fino alla versione 11.2 di "Postgres Pro Enterprise", la replicazione funzionerà solo in presenza di chiavi primarie uniche, tienilo a mente durante lo sviluppo.
In particolare, vorrei sottolineare le peculiarità del funzionamento di npgsql in una soluzione cluster: questi problemi non si riscontrano su un nodo singolo, ma sono presenti nel multimaster.
In alcune versioni si può incorrere nell'errore:
Exception Details: Npgsql.PostgresException: 25001: comando SET TRANSACTION ISOLATION LEVEL
Description: Si è verificata un'eccezione non gestita durante l'esecuzione della richiesta web corrente. Si prega di esaminare il tracciato dello stack per ulteriori informazioni sull'errore e da dove è originato nel codice. Cosa si può fare? Semplicemente non si devono utilizzare alcune versioni. È importante conoscerle, poiché l'errore non si presenta in un'unica versione, e anche dopo la prima correzione, si può incorrere di nuovo in esso successivamente. Anche questo deve essere previsto e sarebbe meglio coprire ogni difetto del DBMS identificato che viene corretto dal produttore con test di regressione specifici. Diciamo che è meglio fidarsi ma verificare.
Se l'applicazione utilizza npgsql e si sposta tra i nodi pensando che siano tutti uguali, può verificarsi il seguente errore:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: errore di ricerca nella cache per tipo ...Questo errore si verifica a causa del fatto che viene eseguita la mappatura
(NpgsqlConnection.GlobalTypeMapper.MapComposite("some_composite_type");) dei tipi composti all'avvio dell'applicazione per tutte le connessioni. Di conseguenza, otteniamo un identificatore da un certo nodo, e quando si effettua una richiesta su un altro nodo, non corrisponde, il che provoca un errore; quindi, lavorare in modo trasparente con i tipi composti in un cluster sarà impossibile per alcune applicazioni senza ulteriori riscritture sul lato dell'applicazione (se riuscite a farlo).
Come sappiamo, una valutazione generale dello stato del cluster è molto importante per la diagnosi e le azioni tempestive durante il funzionamento; nel prodotto troverete alcune funzioni che dovrebbero rendervi la vita più facile, ma a volte possono restituire risultati completamente diversi da quelli che voi e lo stesso produttore vi aspettavate.
Ad esempio:
select mtm.collect_cluster_info();
su ogni nodo restituisce lo stesso risultato:
(1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")Ma perché nel campo LiveNodes è presente ovunque il numero 2, se secondo la descrizione del funzionamento del multimasters dovrebbe corrispondere al numero AllNodes=3? Risposta: è necessario aggiornare la versione del DBMS.
E siate pronti a raccogliere i log da tutti i nodi, perché di solito vedrete «l'errore si trova nel log di un altro nodo». Il supporto tecnico accetterà tutti i difetti da voi segnalati e informerà sulla disponibilità di una nuova versione da installare, a volte con fermo del servizio e altre volte in modo prolungato (dipende dalla dimensione del vostro DBMS). Non aspettatevi che i problemi di sfruttamento preoccupino molto il fornitore e che l'aggiornamento a causa dei difetti identificati venga effettuato con la partecipazione di rappresentanti del fornitore; in effetti, non è necessario coinvolgere i rappresentanti del fornitore, poiché alla fine potreste trovarvi con un cluster sul produttivo smontato e senza backup.
Infatti, nella licenza del prodotto commerciale, il produttore avverte onestamente: «Questo software è fornito sul principio di 'come è' e la società a responsabilità limitata 'Postgres Professionale' non è obbligata a fornire supporto, assistenza, aggiornamenti, estensioni o modifiche.»
Se non avete ancora indovinato di quale prodotto si tratta, tutta questa esperienza è stata accumulata a seguito di un anno di sfruttamento del database Postgres Pro Enterprise. La conclusione la potete trarre voi stessi, è così grezza che crescono funghi.
Ma sarebbe già un mezzo problema se venissero risolti tempestivamente e rapidamente i problemi emergenti.
Ma questo non accade. Evidentemente il produttore non ha sufficienti risorse per risolvere rapidamente i bug identificati.
Solo gli utenti registrati possono partecipare al sondaggio. , per favore.
Avete esperienza di transizione da un DBMS straniero/proprietario a uno libero/nazionale?
21,3%Sì, positivo10
10,6%Sì, negativo5
21,3%No, non abbiamo cambiato DBMS10
4,3%Abbiamo cambiato DBMS, ma nulla è cambiato2
42,6%Visualizza i risultati20
Hanno votato 47 utenti. Si sono astenuti 12 utenti.
Fonte: habr.com
