"Pro, ma micca un cluster" o cumu avemu rimpiazzatu DBMS impurtati

(ts) Yandex.Images

Tutti i caratteri sò fittizi, i marchi appartenenu à i so patroni, ogni similarità sò aleatoriu è in generale, questu hè u mo "ghjudiziu di valore subjective, per piacè ùn rompe a porta ...".

Avemu una sperienza considerableu in u trasferimentu di sistemi d'infurmazione cù logica in una basa di dati da un DBMS à l'altru. In u cuntestu di u decretu di u guvernu n ° 1236 di nuvembre 16.11.2016, XNUMX, questu hè spessu un trasferimentu da Oracle à Postgresql. Puderemu dì per separatamente cumu urganizà u prucessu in modu efficiente è indolore quantu pussibule; oghje parlemu di e caratteristiche di l'usu di un cluster è di quali prublemi si ponu scontru quandu custruisce sistemi distribuiti altamente carichi cù logica cumplessa in prucedure è funzioni.

Spoiler - iè, cap, RAC è pg multimaster sò suluzioni assai diffirenti.

Diciamu chì avete digià trasferitu tutta a logica da plsql à pgsql. E i vostri testi di regressione sò abbastanza bè, avà di sicuru pensate à scaling, perchè... e teste di carica ùn vi facenu micca assai felice, in particulare nantu à u hardware chì era urigginariamente inclusu in u prugettu, per quellu DBMS assai diversu. Dicemu chì avete trovu una suluzione da u venditore domesticu "Postgres Professional" cù una opzione chjamata "multimaster", chì hè dispunibule solu in a versione "massimu" di "Postgres Pro Enterprise" è secondu a descrizzione - hè assai simili à ciò chì avete bisognu, è cù u primu studiu superficiale vinarà u pensamentu hè vinutu in u mo capu: "Oh! Eccu invece di RAC ! È ancu cù un pipeline tecnicu in a nostra patria !

Ma ùn affruntate micca à rallegra, è in più discrivaremu perchè avete bisognu di cunnosce queste sfumature, perchè ... sò difficiuli di predichendu, ancu dopu avè lettu bè a documentazione di u produttu. Evaluate s'ellu site prontu à aghjurnà spessu e versioni DBMS direttamente nantu à u situ di produzzione, perchè Certi difetti ùn sò micca cumpatibili cù l'usu industriale è sò difficiuli di detectà durante a prova.
Accuminciate da leghje attentamente a sezione "multimaster" - "limitazioni" in u situ web di u fabricatore.

A prima cosa chì pudete scontru hè a peculiarità di cumu travaglianu e transacciones, in u cusì chjamatu. Modu "du-fase", è qualchì volta ùn ci hè manera di riparà questu, salvu riscrivendu tutta a logica di a vostra prucedura. Eccu un esempiu simplice:

create table test1 (id integer, id1 integer);
insert into test1 values (1, 1),(1, 2);
 
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
update test1
           set id1 =
               case id1
                 when 1
                 then 2
                 else id1 - sign(2 - 1)
               end
         where id1 between 1 and 2;

Ci hè un errore:

ОШИБКА:  [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.

Allora pudete luttà per un bellu pezzu cù a serratura morta in e versioni 10.5, 10.6, è l'unica suluzione cunnisciuta chì tumba tutta l'essenza di u cluster hè di sguassà e tavule "prublema" da u cluster, i.e. fate make_table_local, ma questu almenu permetterà di travaglià, è ùn metterà micca tuttu in attesa per via di l'attesa di attese per i cummissioni di transazzione. Ebbè, o stallà una aghjurnazione à a versione 11.2, chì deve aiutà, ma forsi micca, ùn vi scurdate di verificà.

In alcune versioni pudete ottene un serratura ancu più misteriosa:

username= mtm и backend_type = background worker

È in questa situazione, solu l'aghjurnà a versione DBMS à 11.2 è più altu vi aiuterà, o forse ùn aiuterà micca.

Alcune operazioni cù l'indici ponu purtà à errori, chì indicanu chjaramente chì u prublema hè in Replicazione Bi-Direzzione; vi vede direttamente BDR in i logs MTM. Hè veramente 2ndQuadrant? Innò... avemu compru un multimaster, hè solu una coincidenza, hè u nome di a tecnulugia.

[MTM] bdr doesn't support index rechecks
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: send ABORT notification for transaction  (5467) local xid=4083 to coordinator 3
[MTM] Receive ABORT_PREPARED logical message for transaction MTM-3-25030-83-605694076627780 from node 3
[MTM] Abort prepared transaction MTM-3-25030-83-605694076627780 status InProgress from node 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448 

Sè vo aduprate tavule tempuranee, malgradu l'assicurazioni: "L'estensione multimaster realiza a replicazione di dati in una manera completamente automatica. Pudete simultaneamente eseguisce transazzioni di scrittura è travaglià cù tavule tempurane nantu à qualsiasi node in u cluster.

Allora, in fattu, uttene chì a replicazione ùn viaghja micca in tutti i tavulini utilizati in a prucedura, se u codice cuntene a creazione di una tavola pruvisoria, è ancu cù multimaster.remote_functions ùn aiuterà micca, avete da aghjurnà o riscrivite a vostra logica in a prucedura. Sè avete bisognu di utilizà duie estensioni multimaster è pg_pathman simultaneamente in u quadru di "Postgres Pro Enterprise" v 10.5, allora verificate cù questu esempiu simplice:

CREATE TABLE measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

CREATE TABLE measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
insert into measurement values (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

I seguenti errori cumincianu à apparisce in i logs nantu à i nodi DBMS:

…
 PATHMAN_CONFIG doesn't contain relation 23245
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt//…/ent-10/lib/pg_pathman.so"
> ОТЛАДКА:  find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) name: unnamed; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> switched to timeline 1 valid until 0/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) is aborted on node 2. Check its log to see error details.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: send ABORT notification for transaction  (6919) local xid=7017 to coordinator 1

Pudete scopre ciò chì sti errori sò in supportu tecnicu, ùn hè micca in vain chì avete compru.

Chì fà ? Diritta! Avanzate à "Postgres Pro Enterprise" v 11.2

Separatamente, avete bisognu di sapè chì a sequenza, essendu un ughjettu di una basa di dati replicata, ùn hà micca un valore end-to-end in tuttu u cluster, ogni sequenza hè lucale per ogni node è se avete campi cù restrizioni uniche è sequenza d'utilizazione, tandu pudete fà solu un incrementu equivalente à u numeru di node in cluster, perchè Tanti nodi in u cluster pussibule, a sequenza è l'int creceranu più veloce di ciò chì aspettavate. Per simplificà u travagliu cù a sequenza in u pruduttu, truverete ancu a funzione alter_sequences, chì farà l'incrementi necessarii per ogni sequenza in tutti i nodi, ma preparate chì a funzione ùn hà micca travagliatu in tutte e versioni. Di sicuru, pudete scrivite sè stessu, utilizendu u codice da github cum'è una basa o correggendu direttamente in u DBMS. In questu casu, i campi cù u tipu serialbigserial anu da travaglià più currettamente, ma per usà, u più prubabile avete bisognu di riscrive u codice di e vostre prucedure è funzioni. Forsi qualcunu truverà a funzione monotonic_sequences utile.

Prima di a versione 11.2 di Postgres Pro Enterprise, a replicazione funziona solu s'ellu ci sò chjavi primari unichi, pigliate questu in contu quandu u sviluppu.

Separatamente, vogliu menziunà e peculiarità di cumu npgsql funziona in una suluzione di cluster; sti prublemi ùn si sviluppanu micca in un unicu node, ma sò abbastanza prisenti in un multimaster.
In certi versioni pudete truvà un errore:

Exception Details: Npgsql.PostgresException: 25001: команда SET TRANSACTION ISOLATION LEVEL 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Chì si pò fà ? Solu avete micca aduprà alcune versioni. Avete bisognu di cunnosceli, perchè ... L'errore appare in più di una versione, è ancu dopu a so prima correzione, pudete scuntrà dopu. Avete ancu esse preparatu per questu è hè megliu copre tutti i difetti DBMS identificati chì sò curretti da u fabricatore cù teste di regressione separati. Per dì cusì, fiducia, ma verificate.

Se l'applicazione usa npgsql è cambia trà i nodi pensendu chì sò tutti listessi, pudete avè un errore:

EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...

Stu errore accade perchè u vintu hè in corso

(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) 

tipi di composti à l'iniziu di l'applicazione per tutte e cunnessione. In u risultatu, avemu un identificatore da un node, è quandu dumandà à un altru node, ùn currisponde micca, per via di quale un errore hè tornatu, i.e. U travagliu di manera trasparente cù i tipi di composti in un cluster ùn serà micca pussibule per alcune applicazioni senza riscrittura supplementu di l'applicazione (se riesce à fà).

Comu tutti sapemu, una valutazione generale di u statu di u cluster hè assai impurtante per i diagnostichi è e misure operative durante l'operazione, in u pruduttu pudete truvà alcune funzioni chì duveranu fà a vostra vita più faciule, ma qualchì volta ponu dà qualcosa completamente diversu da ciò chì voi è ancu u fabricatore stessu da elli vi aspettate.

Per esempiu:

select mtm.collect_cluster_info();
на каждой ноде выдает одинаковый результат:
(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è u campu LiveNodes cuntene u numeru 2 in ogni locu, ancu s'è secondu a descrizzione di l'operazione di u multimaster, deve currisponde à u numeru AllNodes = 3? Risposta: avete bisognu di aghjurnà a versione DBMS.

È preparate à cullà logs per tutti i nodi, perchè ... di solitu vi vede "l'errore hè in u logu di un altru node". U supportu tecnicu accetterà tutti i difetti chì identificate è vi informanu chì a prossima versione hè pronta, chì qualchì volta deve esse installata cù u serviziu fermatu, à volte per un bellu pezzu (secondu a dimensione di u vostru DBMS). Ùn deve micca sperà chì i prublemi operativi disturbanu assai u venditore, è l'aghjurnamentu per i difetti identificati serà realizatu cù a participazione di i rapprisentanti di u venditore, o, piuttostu, ùn avete mancu bisognu di participà à i rapprisentanti di u venditore, postu chì in u fine pudete finisce cù un cluster disassemblatu in produzzione senza copia di salvezza.

In verità, in a licenza per un pruduttu cummerciale, u fabricatore avverte onestamente: "Stu software hè furnitu nantu à una basa "cum'è" è Postgres Professional Limited Liability Company ùn hè micca obligatu à furnisce mantenimentu, supportu, aghjurnamenti, estensioni o cambiamenti".

Se ùn avete micca indovinatu di quale pruduttu parlemu, allora tutta sta sperienza hè stata guadagnata da u funziunamentu di l'annu di a basa di dati Postgres Pro Enterprise. Pudete piglià a vostra propria cunclusione, hè cusì umida chì i funghi crescenu.

Ma questu ùn saria micca cusì male s'ellu hè stata fatta in una manera puntuale è prontamente eliminata i prublemi emergenti.

Ma questu hè precisamente ciò chì ùn succede micca. Apparentemente, u fabricatore ùn hà micca abbastanza risorse per eliminà rapidamente i bug identificati.

Solu l'utilizatori registrati ponu participà à l'indagine. Firmà lu, per piacè.

Avete sperienza in cambià da un DBMS straneru / pruprietariu à un liberu / domesticu?

• 21,3%Iè, pusitivu 10

• 10,6%Iè, negativu 5

• 21,3%No, u DBMS ùn hè micca cambiatu10

• 4,3%U DBMS hè statu cambiatu, ma nunda hà cambiatu2

• 42,6%Vede i risultati 20

47 utilizatori anu vutatu. 12 utilizatori si sò astenuti.

Source: www.habr.com