ProHoster > Blog > Administracija > ‘Pro, ali ne klaster’ ili kako smo obavljali zamjenu SUDP-a

‘Pro, ali ne klaster’ ili kako smo obavljali zamjenu SUDP-a

‘Pro, ali ne klaster’ ili kako smo obavljali zamjenu SUDP-a
(c) Yandex.Images

Svi likovi su izmišljeni, trgovački znakovi pripadaju njihovim vlasnicima, a svaka podudarnost je slučajna i ujedno, ovo je moje 'subjektivno vrednovanje, molim vas ne razbijajte vrata…'.

Imamo značajno iskustvo u prevođenju informacijskih sustava s logikom u bazi podataka iz jedne DBMS u drugi. U kontekstu Uredbe Vlade br. 1236 od 16.11.2016., često se radi o prebacivanju s Oracle-a na PostgreSQL. Kako organizirati proces maksimalno učinkovito i bezbolno — možemo posebno reći, danas ćemo pričati o osobitostima korištenja klastera i s kojim se problemima možete susresti prilikom izgradnje visoko opterećenih distribuiranih sustava sa složenom logikom u procedurama i funkcijama.

Spoiler – da, kcep, RAC i pg multimaster su zaista vrlo različita rješenja.

Recimo da ste već prenijeli cijelu logiku s plsql-a na pgsql. A vaši regresijski testovi su sasvim u redu, sada razmišljate o skaliranju, jer vam opterećenjski testovi ne donose puno radosti, pogotovo na onoj opremi koja je prvotno bila predviđena za taj drugi DBMS. Recimo, pronašli ste rješenje domaćeg dobavljača 'Postgres Professional' s opcijom pod nazivom 'multimaster', koja je dostupna samo u 'maksimalnoj' verziji 'Postgres Pro Enterprise', i prema opisu — čini se vrlo sličnim onome što vam treba, i prilikom prvog površnog proučavanja doći će vam na pamet misao: 'Oh! Umjesto RAC-a, ovo je to! A još i s tehničkom podrškom u Domovini!'.

Ali ne žurite s veseljem, i dalje ćemo opisati zašto trebate znati ove nijanse, jer ih je teško predvidjeti, čak i nakon što dobro proučite dokumentaciju proizvoda. Procijenite jeste li spremni često ažurirati verzije DBMS-a ravno na proizvodnoj platformi, jer neki nedostaci nisu kompatibilni s komercijalnim radom i teško ih je otkriti tijekom testiranja.
Počnite pažljivim čitanjem odjeljka 'multimaster' — 'ograničenja' na web stranici proizvođača.

Prvo s čime se možete susresti su osobitosti rada transakcija u takozvanom 'dvofaznom' režimu, a ponekad se to ne može ispraviti osim prepisivanjem cijele logike vaše procedure. Evo jednostavnog primjera:

izradite tablicu test1 (id integer, id1 integer);
unesite u test1 vrijednosti (1, 1),(1, 2);

ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;

ažurirajte test1
           postavite id1 =
               slučaj id1
                 kada 1
                 onda 2
                 inače id1 - znak(2 - 1)
               kraj
         gdje id1 između 1 i 2;

Pojavljuje se greška:

GREŠKA:  [MTM] Transakcija MTM-1-2435-10-605783555137701 (10654) je prekinuta na čvoru 3. Provjerite njezin zapis za detalje o grešci.

Možete se dugo boriti s dead lockom u verzijama 10.5, 10.6 a jedino poznato rješenje koje ubija suštinu klastera je uklanjanje "problematičnih" tablica iz klastera, tj. izvođenje make_table_local, ali to će barem omogućiti rad, a ne zaustaviti sve zbog čekanja na potvrdu transakcija. Možete ili nadograditi na verziju 11.2, koja bi trebala pomoći, ili možda ne, ne zaboravite provjeriti.

U nekim verzijama možete dobiti još tajanstveniju blokadu:

korisničko ime= mtm i backend_type = pozadinski radnik

U ovoj situaciji samo će vam pomoći ažuriranje verzije SGBD-a na 11.2 i više, ili možda neće.

Neke operacije s indeksima mogu izazvati greške, gdje se jasno navodi da je problem u Bi-Directional Replication, u zapisima MTM-a direktno ćete vidjeti BDR. Zar ne 2ndQuadrant? Ne… kupili smo multimaster, to je samo podudarnost, to je naziv tehnologije.

[MTM] bdr ne podržava provjere indeksa
[MTM] 12124: REMOTE početak prekida transakcije 4083
[MTM] 12124: pošaljite obavijest o PREKIDU za transakciju (5467) lokalni xid=4083 koordinatoru 3
[MTM] Primite ABORT_PREPARED logičku poruku za transakciju MTM-3-25030-83-605694076627780 s čvora 3
[MTM] Prekini pripremljenu transakciju MTM-3-25030-83-605694076627780 status InProgress s čvora 3 originId=3
[MTM] MtmLogAbortLogicalMessage čvor=3 transakcija=MTM-3-25030-83-605694076627780 lsn=9fff448

Ako koristite privremene tablice, unatoč uvjeravanjima: "Proširenje multimaster provodi replikaciju podataka potpuno automatski. Možete istovremeno izvoditi zapisne transakcije i raditi s privremenim tablicama na kojem god čvoru klastera."

Tada ćete zapravo dobiti da replikacija ne radi za sve tablice korištene u proceduri, ako u kodu postoji kreiranje privremene tablice, a čak ni korištenje multimaster.remote_functions neće pomoći, morat ćete nadograditi ili prepisati svoju logiku u proceduri. Ako morate istovremeno koristiti dva proširenja multimaster i pg_pathman unutar "Postgres Pro Enterprise" v 10.5, provjerite da li pri ovakvom jednostavnom primjeru:

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

STVORI TABLICU measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
ubaci u measurement vrijednosti (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
ubaci u measurement vrijednosti (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
ubaci u measurement vrijednosti (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
ubaci u measurement vrijednosti (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

Na logovima na čvorovima DBMS počinju se javljati ovakve greške:

…
 PATHMAN_CONFIG ne sadrži relaciju 23245
> find_in_dynamic_libpath: pokušava "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: pokušava "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> ODLAGANJE: find_in_dynamic_libpath: pokušava "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: pokušava "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) naziv: bez naziva; blockState: PREPARE; state: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) naziv: bez naziva; blockState: DEFAULT; state: INPROGR, xid\/subid\/cid: 0\/1\/0
> prebačeno na vremensku liniju 1 važeću do 0\/0
…
Transakcija MTM-1-13604-7-612438856339841 (6919) je prekinuta na čvoru 2. Provjerite njezin log za detalje o grešci.
...
[MTM] 28295: DALJINSKI započni poništi transakciju 7017
…
[MTM] 28295: pošalji ABORT obavijest za transakciju (6919) lokalni xid=7017 koordinatoru 1

Što su te greške, možete saznati u tehničkoj podršci, nije džaba ste je kupili.

Što učiniti? Točno! Ažurirati na „Postgres Pro Enterprise“ do v 11.2

Treba znati da sequenca, kao objekt replicirane baze podataka, nipošto nemaju consecutivnu vrijednost unutar cijelog klastera, svaka sequenca je lokalna za svaki čvor i ako imate polja s jedinstvenim ograničenjima i koristite sequencu, onda možete samo napraviti inkrement ekvivalentan broju čvora u klasteru, jer koliko čvorova imate u klasteru toliko brže će se vrednosti sequece povećavati, a int će se brže završiti nego što ste planirali. Za pojednostavljenje rada s sequencima u proizvodu naći ćete čak i funkciju alter_sequences koja će napraviti potrebne inkremetne po svakoj sequenci na svim čvorovima, ali budite spremni da funkcija ne radi u svim verzijama. Naravno, možete je sami napisati, uzimajući kao osnovu kod s github-a ili prilagoditi sami direktno u DBMS-u. Također, polja tipa serialbigserial će raditi ispravnije, ali za njihovu upotrebu najvjerojatnije ćete morati prepisati kod svojih procedura i funkcija. Možda će nekome biti korisna funkcija monotonic_sequences.

Do verzije 11.2 „Postgres Pro Enterprise“ replikacija će raditi samo uz prisutnost jedinstvenih primarnih ključeva, obratite pažnju na to prilikom razvoja.

Posebno se treba osvrnuti na karakteristike rada npgsql-a u klasterskom rješenju; ti se problemi ne pojavljuju na single node-u, ali u multimaster-u su prisutni.
U nekim verzijama možete naići na grešku:

Detalji iznimke: Npgsql.PostgresException: 25001: komanda SET TRANSACTION ISOLATION LEVEL 
Opis: Došlo je do neobrađene iznimke tijekom izvršavanja trenutnog web zahtjeva. Molimo pregledajte trag stoga za više informacija o grešci i gdje je nastala u kodu.

Što se može učiniti? Jednostavno je potrebno ne koristiti određene verzije. Važno je znati koje su to verzije, jer greška ne pojavljuje samo u jednoj verziji, a čak i nakon prvog ispravka, možete se susresti s njom kasnije. Na to se također treba pripremiti i najbolje bi bilo svaku identificiranu pogrešku u SGBD-u koju ispravlja proizvođač pokriti posebnim regresijskim testovima. Drugim riječima, vjeruj, ali provjeri.

Ako aplikacija koristi npgsql i prelazi između nodova misleći da su oni svi identični, moglo bi doći do greške:

IZUZETAK: Npgsql.PostgresException (0x80004005): XX000: neuspjeh u pregledu predmemorije za tip ...

Takva greška nastaje zbog priključivanja

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

kompozitnih tipova prilikom pokretanja aplikacije za sve veze. Kao rezultat, dobijamo identifikator s neke jedne nodu, a pri upitu na drugoj nodi, ne poklapa se, što dovodi do greške, tj. transparentno raditi s kompozitnim tipovima u klasteru za neke aplikacije neće biti moguće bez dodatnih prepravki na strani aplikacije (ako to uspijete učiniti).

Kao što svi znamo, ukupna procjena stanja klastera vrlo je važna za dijagnostiku i brze mjere tijekom rada; u proizvodu ćete moći pronaći neke funkcije koje bi vam trebale olakšati život, ali ponekad one mogu izbaciti potpuno nešto drugo nego što očekujete, čak i sam proizvođač.

Na primjer:

select mtm.collect_cluster_info();
na svakoj nodi daje isti rezultat:
(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")

Ali zašto u polju LiveNodes svuda stoji broj 2, iako bi opis rada multimastera trebao odgovarati broju AllNodes=3? Odgovor: potrebno je ažurirati verziju SGBD-a.

Budite spremni prikupljati logove sa svih čvorova, jer obično ćete vidjeti «greška je u logu drugog čvora». Tehnička podrška će prihvatiti sve uočene nedostatke i obavijestiti vas o spremnosti sljedeće verzije, koju će ponekad trebati instalirati uz zaustavljanje usluge, a ponekad i na duže vrijeme (ovisno o veličini vaše baze podataka). Ne treba očekivati da će problemi s eksploatacijom previše brinuti dobavljača, a ažuriranje zbog uočenih nedostatka se neće provoditi uz sudjelovanje predstavnika dobavljača, točnije, bolje ih ne privlačiti, jer na kraju možete dobiti razbijeni klaster na produkciji bez backupa.

U licenci za komercijalni proizvod, proizvođač iskreno upozorava: «Ovaj softver se daje na osnovi principa

Ako još niste shvatili o kojem se proizvodu radi, svi su ti uvidi dobiveni tijekom godišnjeg korištenja baze Postgres Pro Enterprise. Možete izvući vlastiti zaključak, takva sirovost da gljive rastu.

Ali to bi bila samo polu-problema, da se pravovremeno i učinkovito rješavaju nastali problemi.

Međutim, to se ne događa. Izgleda da proizvođaču nedostaje resursa da hitno riješi uočene greške.

Samo registrirani korisnici mogu sudjelovati u anketi. Prijavite se, molimo.

Imate li iskustva u prelasku s stranih/proprietarnih baza podataka na slobodne/domestic?

  • 21,3%Da, pozitivno10

  • 10,6%Da, negativno5

  • 21,3%Ne, nismo mijenjali bazu podataka10

  • 4,3%Mijenjali smo bazu podataka, ali to nije donijelo promjene2

  • 42,6%Pogledajte rezultate20

Glasalo je 47 korisnika. Suzdržano 12 korisnika.

Izvor: habr.com

Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere 🔥 Kupite pouzdan hosting za web stranice s DDoS zaštitom, VPS VDS servere | ProHoster