„Pro, ale nie klaster” czyli jak zastąpiliśmy importowany system DBMS

(ts) Yandex.Images

Wszystkie postacie są fikcyjne, znaki towarowe należą do ich właścicieli, wszelkie podobieństwa są przypadkowe i ogólnie jest to moja „subiektywna ocena wartości, proszę nie wyważać drzwi…”.

Mamy duże doświadczenie w przenoszeniu systemów informatycznych wraz z logiką do bazy danych z jednego SZBD do drugiego. W kontekście dekretu rządowego nr 1236 z dnia 16.11.2016 listopada XNUMX r. często jest to przeniesienie z Oracle do Postgresql. Możemy osobno powiedzieć, jak zorganizować proces tak efektywnie i bezboleśnie, jak to możliwe, dzisiaj porozmawiamy o cechach korzystania z klastra i jakie problemy można napotkać podczas budowania mocno obciążonych systemów rozproszonych o złożonej logice procedur i funkcji.

Spoiler – tak, cap, RAC i pg multimaster to bardzo różne rozwiązania.

Powiedzmy, że przeniosłeś już całą logikę z plsql do pgsql. A Twoje testy regresyjne są całkiem w porządku, teraz oczywiście myślisz o skalowaniu, bo... testy obciążeniowe nie sprawiają zbyt wiele radości, szczególnie na sprzęcie, który był pierwotnie zawarty w projekcie, dla tego bardzo innego systemu DBMS. Załóżmy, że znalazłeś rozwiązanie od krajowego dostawcy „Postgres Professional” z opcją o nazwie „multimaster”, które jest dostępne tylko w „maksymalnej” wersji „Postgres Pro Enterprise” i zgodnie z opisem - jest bardzo podobne do tego, co potrzebujesz, a już po pierwszym powierzchownym przestudiowaniu przyszła mi do głowy myśl: „Och! To wszystko zamiast RAC! A nawet z rurociągiem technicznym w naszej ojczyźnie!”

Ale nie spiesz się z radością, a dalej opiszemy, dlaczego musisz znać te niuanse, ponieważ... trudno je przewidzieć, nawet po dokładnym zapoznaniu się z dokumentacją produktu. Oceń, czy jesteś gotowy na częste aktualizowanie wersji DBMS bezpośrednio na stronie produkcyjnej, ponieważ Niektóre wady nie nadają się do użytku przemysłowego i są trudne do wykrycia podczas testów.
Zacznij od uważnego przeczytania działu „multimaster” – „ograniczenia” na stronie producenta.

Pierwszą rzeczą, z którą możesz się spotkać, są specyfiki działania transakcji, w tzw. tryb „dwufazowy” i czasami nie da się tego naprawić, chyba że przepiszesz całą logikę swojej procedury. Oto prosty przykład:

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;

Występuje błąd:

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

Można wtedy długo walczyć z dead lockiem w wersjach 10.5, 10.6 i jedyne znane rozwiązanie, które zabija całą istotę klastra, to usunięcie z klastra tabel „problematycznych”, tj. wykonaj make_table_local, ale to przynajmniej pozwoli mu działać i nie spowoduje wstrzymania wszystkiego z powodu zawieszenia oczekiwania na zatwierdzenie transakcji. Cóż, lub zainstaluj aktualizację do wersji 11.2, która powinna pomóc, ale może nie, nie zapomnij sprawdzić.

W niektórych wersjach można uzyskać jeszcze bardziej tajemniczy zamek:

username= mtm и backend_type = background worker

I w tej sytuacji dopiero aktualizacja DBMS do wersji 11.2 i wyższej pomoże, a może nie pomoże.

Niektóre operacje na indeksach mogą prowadzić do błędów, co wyraźnie wskazuje, że problem dotyczy replikacji dwukierunkowej; BDR zobaczysz bezpośrednio w dziennikach MTM. Czy to naprawdę druga ćwiartka? Nie... kupiliśmy multimastera, to przypadek, taka jest nazwa technologii.

[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 

Jeśli pomimo zapewnień korzystasz z tabel tymczasowych: „Rozszerzenie multimaster wykonuje replikację danych w sposób całkowicie automatyczny. Możesz jednocześnie wykonywać transakcje zapisu i pracować z tabelami tymczasowymi w dowolnym węźle klastra.”

Wtedy tak naprawdę otrzymasz, że replikacja nie działa na wszystkich tabelach użytych w procedurze, jeśli kod zawiera utworzenie tabeli tymczasowej i nawet użycie multimaster.remote_functions nie pomoże, będziesz musiał zaktualizować lub przepisać swoją logikę w procedura. Jeśli chcesz używać jednocześnie dwóch rozszerzeń multimaster i pg_pathman w Postgres Pro Enterprise v 10.5, sprawdź to na tym prostym przykładzie:

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

W logach węzłów DBMS zaczynają pojawiać się następujące błędy:

…
 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żesz dowiedzieć się, jakie są te błędy w pomocy technicznej, nie na próżno to kupiłeś.

Co robić? Prawidłowy! Uaktualnij do „Postgres Pro Enterprise” v 11.2

Osobno musisz wiedzieć, że sekwencja będąc obiektem replikowanej bazy danych nie ma wartości typu end-to-end w całym klastrze, każda sekwencja jest lokalna dla każdego węzła i jeśli masz pola z unikalnymi ograniczeniami i sekwencją użycia, wtedy możesz dokonać jedynie przyrostu odpowiadającego numerowi węzła w klastrze, ponieważ Jak najwięcej węzłów w klastrze, sekwencja i int będzie rosła szybciej, niż oczekiwano. Aby uprościć pracę z sekwencją w produkcie, znajdziesz nawet funkcję alter_sequences, która wykona niezbędne przyrosty dla każdej sekwencji we wszystkich węzłach, ale bądź przygotowany na to, że funkcja ta nie będzie działać we wszystkich wersjach. Można go oczywiście napisać samodzielnie, bazując na kodzie z githuba lub samodzielnie poprawiając go bezpośrednio w DBMS-ie. W tym przypadku pola o typie serialbigserial będą działać poprawniej, ale aby z nich skorzystać, najprawdopodobniej będziesz musiał przepisać kod swoich procedur i funkcji. Być może komuś przyda się funkcja monotonic_sequences.

Przed wersją 11.2 Postgres Pro Enterprise replikacja będzie działać tylko wtedy, gdy istnieją unikalne klucze podstawowe. Weź to pod uwagę podczas programowania.

Osobno chciałbym wspomnieć o osobliwościach działania npgsql w rozwiązaniu klastrowym; problemy te nie pojawiają się w pojedynczym węźle, ale są dość obecne w multimasterze.
W niektórych wersjach może wystąpić błąd:

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. 

Co można zrobić? Po prostu nie musisz używać niektórych wersji. Warto je poznać, bo... Błąd pojawia się w więcej niż jednej wersji i nawet po jego pierwszym naprawieniu możesz natknąć się na niego później. Na to też trzeba być przygotowanym i lepiej wszystkie zidentyfikowane defekty DBMS, które naprawia producent, pokryć osobnymi testami regresyjnymi. Że tak powiem, ufaj, ale sprawdzaj.

Jeśli aplikacja używa npgsql i przełącza się między węzłami, myśląc, że wszystkie są takie same, może pojawić się błąd:

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

Ten błąd wystąpi, ponieważ trwa wiązanie

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

typy złożone przy uruchamianiu aplikacji dla wszystkich połączeń. W efekcie dostajemy identyfikator z jednego węzła, a przy żądaniu na innym węźle nie pasuje, w efekcie czego zwracany jest błąd, tj. W przypadku niektórych aplikacji przejrzysta praca z typami złożonymi w klastrze nie będzie możliwa bez dodatkowych zapisów po stronie aplikacji (jeśli uda ci się to zrobić).

Jak wszyscy wiemy ogólna ocena stanu klastra jest bardzo ważna dla diagnostyki i działań eksploatacyjnych podczas pracy, w produkcie można znaleźć pewne funkcje, które powinny ułatwić Ci życie, ale czasami mogą dać coś zupełnie innego niż to, co Ty, a nawet sam producent oczekujesz od nich, których oczekujesz.

Na przykład:

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

Ale dlaczego w polu LiveNodes wszędzie jest cyfra 2, choć zgodnie z opisem działania multimastera powinna ona odpowiadać liczbie AllNodes=3? Odpowiedź: musisz zaktualizować wersję DBMS.

I przygotuj się na zbieranie dzienników dla wszystkich węzłów, ponieważ... zazwyczaj zobaczysz „błąd znajduje się w dzienniku innego węzła”. Wsparcie techniczne zaakceptuje wszystkie zidentyfikowane przez Ciebie defekty i poinformuje Cię, że jest gotowa kolejna wersja, którą czasami trzeba będzie zainstalować przy wyłączonej usłudze, czasami na dłuższy czas (w zależności od wielkości Twojego systemu DBMS). Nie należy liczyć na to, że problemy operacyjne będą bardzo przeszkadzać dostawcy, a aktualizacja ze względu na wykryte wady zostanie przeprowadzona z udziałem przedstawicieli sprzedawcy, a raczej nie trzeba w ogóle angażować przedstawicieli sprzedawcy, gdyż w ostatecznie możesz otrzymać zdemontowany klaster w produkcji bez tworzenia kopii zapasowych.

Właściwie w licencji produktu komercyjnego producent uczciwie ostrzega: „To oprogramowanie jest dostarczane w stanie „takim, jakim jest”, a firma Postgres Professional Limited Liability Company nie jest zobowiązana do zapewniania konserwacji, wsparcia, aktualizacji, rozszerzeń ani zmian”.

Jeśli jeszcze nie domyśliłeś się o jakim produkcie mowa, to całe to doświadczenie zostało zdobyte w wyniku całorocznego funkcjonowania bazy danych Postgres Pro Enterprise. Można wyciągnąć własne wnioski, jest tak wilgotno, że rosną grzyby.

Ale nie byłoby tak źle, gdyby zostało to zrobione w odpowiednim czasie i szybko wyeliminowało pojawiające się problemy.

Ale właśnie tak się nie dzieje. Najwyraźniej producent nie ma wystarczających zasobów, aby szybko wyeliminować zidentyfikowane błędy.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Czy masz doświadczenie w przejściu z zagranicznego/zastrzeżonego DBMS-a na darmowy/krajowy?

• 21,3%Tak, pozytywne 10

• 10,6%Tak, negatywny 5

• 21,3%Nie, system DBMS nie został zmieniony10

• 4,3%DBMS został zmieniony, ale nic się nie zmieniło2

• 42,6%Zobacz wyniki20

Głosowało 47 użytkowników. 12 użytkowników wstrzymało się od głosu.

Źródło: www.habr.com