🥇"Pro, ali ne i klaster" ili kako smo uvozili DBMS

(ts) Yandex.Images

Svi likovi su izmišljeni, zaštitni znakovi pripadaju njihovim vlasnicima, sve sličnosti su isključivo slučajne i, općenito, ovo je moj „subjektivni vrijednosni sud, molim vas, nemojte razvaljivati vrata…“.

Imamo opsežno iskustvo u migraciji informacijskih sustava s logikom baze podataka iz jednog DBMS-a u drugi. U skladu s Vladinom odlukom br. 1236 od 16. studenog 2016., to često uključuje migraciju s Oraclea na PostgreSQL. O tome kako što učinkovitije i bezbolnije organizirati ovaj proces možemo razgovarati zasebno. Danas ćemo raspravljati o specifičnostima korištenja klastera i izazovima s kojima se možete susresti prilikom izgradnje distribuiranih sustava visokog opterećenja sa složenom logikom u procedurama i funkcijama.

Spojler: da, cap, RAC i pg multimaster su vrlo različita rješenja.

Recimo da ste već migrirali svu svoju logiku iz plsql-a u pgsql. I vaši regresijski testovi su savršeno u redu. Sada prirodno razmišljate o skaliranju, jer testiranje opterećenja nije baš velika stvar, posebno na hardveru koji je izvorno dizajniran za taj drugi DBMS. Recimo da ste pronašli rješenje domaćeg dobavljača, Postgres Professional, sa značajkom pod nazivom "multimaster", koja je dostupna samo u "ultimate" verziji, Postgres Pro Enterprise. Sudeći po opisu, izgleda vrlo slično onome što vam treba i na prvi pogled biste mogli pomisliti: "Oh! Baš ono što vam treba umjesto RAC-a! I to s domaćom tehničkom podrškom!"

Ali nemojte se previše uzbuđivati. Objasnit ćemo zašto morate biti svjesni ovih nijansi, jer ih je teško predvidjeti, čak i nakon pažljivog čitanja dokumentacije proizvoda. Razmislite jeste li spremni često ažurirati verzije DBMS-a izravno na produkcijskoj lokaciji, jer neki nedostaci nisu kompatibilni s produkcijskom upotrebom i teško ih je otkriti tijekom testiranja.
Započnite pažljivim čitanjem odjeljka "multimaster" - "ograničenje" na web stranici proizvođača.

Prvo što biste mogli uočiti su osobitosti načina rada transakcija u takozvanom "dvofaznom" načinu rada, a ponekad ne postoji način da se to popravi osim prepisivanja cijele logike vašeg postupka. Evo jednostavnog primjera:

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;

Dolazi do greške:

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

Možete se dugo boriti sa zastojima u verzijama 10.5 i 10.6, a jedino poznato rješenje, koje potpuno uništava cijelu poantu klastera, jest uklanjanje "problematičnih" tablica iz klastera, tj. pokretanje make_table_local. Ali to će barem omogućiti da stvari rade, umjesto da se sve sruši zbog zaglavljenog čekanja na potvrđivanje transakcija. Ili možete nadograditi na verziju 11.2, što bi trebalo pomoći, ali možda i ne - svakako provjerite.

U nekim verzijama možete dobiti još misteriozniju bravu:

username= mtm и backend_type = background worker

U ovoj situaciji, samo ažuriranje verzije DBMS-a na 11.2 ili noviju će vam pomoći, ali možda i neće.

Neke operacije indeksiranja mogu uzrokovati pogreške koje jasno ukazuju na to da je problem dvosmjerna replikacija; vidjet ćete BDR-ove u MTM zapisnicima. Je li to 2ndQuadrant? Ne... kupili smo multimaster, to je samo slučajnost; to je naziv tehnologije.

[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

Ako koristite privremene tablice, unatoč uvjeravanjima: "Multimaster ekstenzija izvodi replikaciju podataka potpuno automatski. Možete istovremeno pokretati transakcije pisanja i raditi s privremenim tablicama na bilo kojem čvoru klastera."

Zapravo, završit ćete s replikacijom koja neće raditi na svim tablicama korištenim u postupku ako kod stvori privremenu tablicu, a čak ni korištenje multimaster.remote_functions neće pomoći. Morat ćete nadograditi ili prepisati logiku u postupku. Ako trebate istovremeno koristiti i multimaster i pg_pathman ekstenzije u Postgres Pro Enterprise v10.5, provjerite radi li ovaj jednostavan primjer:

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);

Sljedeće greške počinju se pojavljivati u zapisnicima na DBMS čvorovima:

…
 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

Možete saznati koje su to greške kontaktiranjem tehničke podrške; niste ga uzalud kupili.

Što da radim? Tako je! Nadogradite na Postgres Pro Enterprise (v11.2).

Važno je napomenuti da sekvenca, kao replicirani objekt baze podataka, nema konzistentnu vrijednost u cijelom klasteru. Svaka sekvenca je lokalna za svaki čvor. Ako imate polja s jedinstvenim ograničenjima koja koriste sekvencu, možete je povećati samo za broj čvora klastera. To znači da što je više čvorova u klasteru, brže će vaša sekvenca rasti, a i sekvenca i cijeli broj će se iscrpiti brže od očekivanog. Kako bi se pojednostavio rad sa sekvencama, proizvod čak uključuje funkciju alter_sequences koja će izvršiti potrebne inkremente za svaku sekvencu na svim čvorovima. Međutim, imajte na umu da ova funkcija neće raditi u svim verzijama. Naravno, možete je sami napisati, koristeći kod s GitHuba ili ga izravno modificirajući u DBMS-u. Polja Serialbigserial će raditi ispravnije, ali njihovo korištenje vjerojatno će zahtijevati prepisivanje vaših procedura i funkcija. Možda će funkcija monotonic_sequences nekome biti korisna.

Prije Postgres Pro Enterprise 11.2, replikacija će raditi samo ako postoje jedinstveni primarni ključevi, stoga imajte to na umu prilikom dizajniranja.

Također bih želio spomenuti specifičnosti rada npgsql-a u klasteriranom rješenju. Ovi problemi se ne javljaju na jednom čvoru, ali su prilično prisutni u rješenju s više glavnih čvorova.
U nekim verzijama možete naići na grešku:

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.

Što se može učiniti? Jednostavno izbjegavajte korištenje određenih verzija. Važno ih je poznavati jer se greška pojavljuje u više verzija, pa čak i nakon početnog ispravljanja, možete je kasnije naići. Trebali biste biti spremni i na to, a najbolje je sve identificirane nedostatke DBMS-a koje dobavljač ispravlja pokriti zasebnim regresijskim testovima. Vjeruj, ali provjeri, da tako kažem.

Ako vaša aplikacija koristi npgsql i prebacuje se između čvorova, misleći da su svi isti, možete naići na sljedeću grešku:

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

Do ove greške će doći jer je povezivanje u tijeku.

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

Kompozitni tipovi se koriste pri pokretanju aplikacije za sve veze. Kao rezultat toga, identifikator primljen s jednog čvora ne podudara se kada se zatraži na drugom čvoru, što rezultira pogreškom. To znači da će transparentni rad s kompozitnim tipovima u klasteru biti nemoguć za neke aplikacije bez dodatnih prepisivanja na strani aplikacije (ako to uspijete učiniti).

Kao što svi znamo, sveukupna procjena stanja klastera ključna je za dijagnostiku i operativne intervencije. Proizvod uključuje neke značajke koje bi vam trebale olakšati život, ali ponekad možda neće pružiti ono što vi, ili čak proizvođač, očekujete.

Na primjer:

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")

Ali zašto polje LiveNodes uvijek prikazuje broj 2, iako opis multimastera kaže AllNodes=3? Odgovor: Morate ažurirati verziju svoje DBMS-a.

Budite spremni prikupljati zapisnike za sve čvorove, jer ćete obično vidjeti "grešku koja se nalazi u zapisniku drugog čvora". Tehnička podrška će prihvatiti sve nedostatke koje ste identificirali i obavijestiti vas kada sljedeća verzija bude spremna, što će ponekad zahtijevati zastoj, ponekad čak i dugo vrijeme (ovisno o veličini vašeg DBMS-a). Nemojte očekivati da će operativni problemi previše zabrinjavati dobavljača, a ažuriranje zbog otkrivenih nedostataka bit će izvršeno uz sudjelovanje predstavnika dobavljača. Zapravo, ne biste trebali ni uključivati predstavnike dobavljača, jer biste mogli završiti s rastavljenim klasterom u produkciji bez sigurnosne kopije.

Zapravo, u licenci za komercijalni proizvod, proizvođač jasno upozorava: "Ovaj softver se pruža 'kakav jest', a Postgres Professional Limited Liability Company nije obvezan pružati održavanje, podršku, ažuriranja, proširenja ili preinake."

Ako još niste pogodili o kojem proizvodu govorimo, svo ovo iskustvo stečeno je tijekom godine korištenja Postgres Pro Enterprise baze podataka. Možete sami izvući zaključak: toliko je vlažna da se širi kao gljive.

Ali to ne bi bilo tako loše da se provede pravovremeno i da se svi problemi koji se pojave brzo riješe.

Ali upravo se to ne događa. Očito proizvođaču nedostaju resursi za brzo ispravljanje svih otkrivenih grešaka.

U anketi mogu sudjelovati samo registrirani korisnici. Prijaviti se, molim.