«Пра, ды не кластар» ці як мы СКБД імпартазамяшчалі

(ц) Яндэкс.Малюнкі

Усе персанажы выдуманыя, гандлёвыя маркі належаць іх уладальнікам, любыя супадзенні выпадковыя і наогул, гэта маё "суб'ектыўнае ацэначнае меркаванне, калі ласка не ламайце дзверы…".

У нас ёсць немалы досвед перакладу інфармацыйных сістэм з логікай у БД з адной СКБД у іншую. У разрэзе пастановы ўрада №1236 ад 16.11.2016/XNUMX/XNUMX, часта гэта пераклад з Oracle на Postgresql. Як арганізаваць працэс максімальна эфектыўна і бязбольна — мы можам расказаць асобна, сёння мы раскажам пра асаблівасці выкарыстання кластара і з якімі праблемамі можна сутыкнуцца пры пабудове высоканагружаных размеркаваных сістэм са складанай логікай у працэдурах і функцыях.

Спойлер ды кэп, RAC і pg multimaster гэта ну вельмі розныя рашэнні.

Дапушчальны, вы перанеслі ўжо ўсю логіку з plsql на pgsql. А вашы рэгрэсійныя тэсты цалкам сабе ОК, зараз вы вядома думаеце аб маштабаванні, т.к. нагрузачныя тэсты не вельмі вас цешаць, тым больш на тым жалезе, якое было закладзена ў праект першапачаткова, пад тую самую іншую СКБД. Дапушчальны, вы знайшлі рашэнне ад айчыннага вендара "Postgres Professional" з опцыяй пад назвай "multimaster", якая даступная толькі ў "максімальнай" версіі "Postgres Pro Enterprise" і па апісанні - гэта вельмі падобна на патрэбнае вам, і пры першым павярхоўным вывучэнні прыйдзе у галаву думка: «О! Замест RAC самае тое! Ды яшчэ і з тэхсуправадам на Радзіме!».

Але не спяшаецеся цешыцца, і далей мы апішам чаму гэтыя нюансы трэба шляхта, т.к. іх складана прадугледзець, нават добра пачытаўшы дакументацыю па прадукце. Ацэніце, ці будзеце вы гатовыя часцяком абнаўляць версіі СКБД прама на прамысловай пляцоўцы, т.я. некаторыя дэфекты не сумяшчальныя з прамысловай эксплуатацыяй і іх складана выявіць на тэсціраванні.
Пачніце з уважлівага чытання часткі «multimaster» - «абмежаванне» на сайце вытворцы.

Першае, з чым можна сутыкнуцца, гэта асаблівасці працы транзакцый, у т.зв. "двух фазным" рэжыме, і часам, акрамя як перапісваннем усёй логікі вашай працэдуры, гэта ніяк не выправіць. Вось просты прыклад:

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;

Узнікае памылка:

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

Далей можна доўга змагацца з dead lock у версіях 10.5/10.6, 11.2/XNUMX і адзінае вядомае выратаванне, якое забівае ўсю сутнасць кластара - гэта прыбіраць з кластара «праблемныя» табліцы, г.зн. рабіць make_table_local, але гэта хоць бы дазволіць працаваць, а не паставіць "калом" усё з-за якія завіслі чаканняў фіксацыі транзакцый. Ну ці ставіць абнаўленне да XNUMX/XNUMX версіі, якое павінна дапамагчы, а можа і не, не забудзьцеся праверыць.

У некаторых версіях вы зможаце атрымаць яшчэ больш загадкавую блакіроўку:

username= mtm и backend_type = background worker

І ў гэтай сітуацыі вам дапаможа толькі абнаўленне версіі СКБД да 11.2/XNUMX і вышэй, а можа і не дапаможа.

Некаторыя аперацыі з азначнікамі могуць прыводзіць да памылак, дзе відавочна паказваецца, што праблема менавіта ў Bi-Directional Replication, у логах MTM вы прама ўбачыце BDR. Няўжо 2ndQuadrant? Ды не… мы ж купілі multimaster, гэта проста супадзенне, гэтая назва тэхналогіі.

[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 

Калі вы выкарыстоўваеце часовыя табліцы, нягледзячы на ​​запэўненні: «Пашырэнне multimaster ажыццяўляе рэплікацыю дадзеных цалкам аўтаматычнай выявай. Вы можаце адначасова выконваць пішучыя транзакцыі і працаваць з часовымі табліцамі на любым вузле кластара».

Тады па факце вы атрымаеце, што не працуе рэплікацыя па ўсіх табліцах, якія выкарыстоўваюцца ў працэдуры, калі ў кодзе прысутнічае стварэнне часовай табліцы, і нават выкарыстанне multimaster.remote_functions не дапаможа, давядзецца абнаўляцца або перапісваць сваю логіку ў працэдуры. Калі вам трэба выкарыстоўваць адначасова два пашырэння multimaster і pg_pathman у рамках "Postgres Pro Enterprise" v 10.5, то праверце, што пры вось такім просценькім прыкладзе:

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

У логах на вузлах СКБД пачынаюць сыпацца такія памылкі:

…
 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

Што гэта за памылкі, вы зможаце пазнаць у тэхпадтрымцы, нездарма ж вы яе куплялі.

Што рабіць? Правільна! Абнаўляць да "Postgres Pro Enterprise" да v 11.2

Асобна трэба ведаць, што sequence, з'яўляючыся аб'ектам рэпліцыруемай БД, зусім не мае скразное значэнне па ўсім кластары, кожны sequence лакальны для кожнага вузла і калі ў вас ёсць палі з унікальнымі абмежаваннямі і выкарыстоўваюць sequence, то вы можаце толькі зрабіць інкрымент эквівалентны нумары вузла ў кластары, т.я. колькі вузлоў у кластары на столькі хутчэй у вас будзе прырастаць і sequence, ды int скончыцца хутчэй, чым вы разлічвалі. Для спрашчэння працы з sequence у прадукце вы знойдзеце нават функцыю alter_sequences, якая зробіць патрэбныя інкрэменты па кожным sequnce на ўсіх вузлах, але будзьце гатовыя, што функцыя не ва ўсіх версіях будзе працаваць. Вядома яе можна напісаць самім, узяўшы за аснову код з github ці паправіўшы самастойна прама ў СКБД. Пры гэтым палі з тыпам serialbigserial будуць працаваць больш карэктна, але для іх выкарыстання хутчэй за ўсё вам трэба перапісваць код вашых працэдур і функцый. Магчыма камусьці будзе карысная функцыя monotonic_sequences.

Да версіі 11.2 "Postgres Pro Enterprise" рэплікацыя будзе працаваць толькі пры наяўнасці унікальных першасных ключоў, улічвайце гэта пры распрацоўцы.

Асобна хацелася б згадаць аб асаблівасцях працы npgsql менавіта ў кластарным рашэнні, гэтыя праблемы не ўзнікаюць на single node, але ў мультымастры цалкам сабе прысутнічаюць.
У некаторых версіях можна сутыкнуцца з памылкай:

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. 

Што можна зрабіць? Проста трэба не выкарыстоўваць некаторыя версіі. Трэба іх ведаць, т.я. памылка з'яўляецца не ў адной версіі, і нават пасля яе першага выпраўлення, вы можаце сутыкнуцца з ёй пазней. Да гэтага таксама трэба быць гатовым і лепш за ўсе выяўленыя дэфекты СКБД, якія выпраўляе вытворца, пакрываць асобнымі рэгрэсійнымі тэстамі. Так бы мовіць, давярай, але правярай.

Калі дадатак выкарыстоўвае npgsql і перамыкаецца паміж нодамі думаючы, што яны прамы ўсе аднолькавыя, то ў вас можа ўзнікаць памылка:

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

Такая памылка будзе адбываецца з-за таго, што выконваецца прывязка.

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

кампазітных тыпаў пры старце прыкладання для ўсіх падлучэнняў. У выніку атрымліваем ідэнтыфікатар з нейкай адной ноды, і пры запыце на іншай нодзе, ён не супадае, з прычыны чаго вяртаецца памылка, г.зн. празрыста працаваць з кампазітнымі тыпамі ў кластары для некаторых прыкладанняў будзе немагчыма без дадатковых перапісванняў на баку прыкладання (калі вам атрымаецца гэта зрабіць).

Як мы ўсе ведаем, агульная ацэнка стану кластара вельмі важная для дыягностыкі і аператыўных мер пры працы, у прадукце вы зможаце знайсці некаторыя функцыі, якія павінны палягчаць вам жыццё, але часам яны могуць выдаваць зусім не тое, што вы і нават сам вытворца ад іх чакаеце.

Напрыклад:

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

Але чаму ў поле LiveNodes усюды варта лік 2, хоць па апісанні працы мультымастра павінна адпавядаць ліку AllNodes=3? Адказ: трэба абнавіць версію СКБД.

І будзьце гатовыя збіраць логі па ўсіх вузлах, т.я. звычайна вы будзеце бачыць "памылка знаходзіцца ў логу іншага вузла". Техсаппорт прыме ўсе вамі выяўленыя дэфекты і паведаміць аб гатоўнасці чарговай версіі, якую трэба будзе ставіць часам і з прыпынкам сэрвісу, часам і на доўга (залежыць ад аб'ёму вашай СКБД). Не варта спадзяецца, што праблемы эксплуатацыі будуць моцна трывожыць вендара, і абнаўленне з-за выяўленых дэфектаў будзе выконвацца з удзелам прадстаўнікоў вендара, дакладней нават не трэба прыцягваць прадстаўнікоў вендара, бо ў выніку вы можаце атрымаць на прадуктыве разабраны кластар без бекапа.

Уласна, у ліцэнзіі на камерцыйны прадукт вытворца сапраўды папярэджвае: "Гэтае праграмнае забеспячэнне прадастаўляецца на аснове прынцыпу "як ёсць" і таварыства з абмежаванай адказнасцю "Постгрэс Прафесійны" не абавязана прадастаўляць суправаджэнне, падтрымку, абнаўлення, пашырэння або змены."

Калі вы яшчэ не здагадаліся пра які прадукт ідзе гаворка, то ўвесь гэты досвед быў атрыманы ў выніку гадавой эксплуатацыі базы Postgres Pro Enterprise. Выснова можаце зрабіць самі, такая волкасць, што грыбы вырастаюць.

Але гэта яшчэ б і паўбяды, калі б выраблялася своечасова і аператыўна ўхіляў якія ўзнікаюць праблемы.

Але гэтага тое, якраз і не адбываецца. Мабыць рэсурсаў у вытворцы мала, каб аператыўна ўстараняць выяўленыя багі.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Ці ёсць у Вас вопыт пераходу з замежнай/прапрыетарнай СКБД на свабодную/айчынную?

• 21,3%Так, станоўчы10

• 10,6%Так, адмоўны5

• 21,3%Не, СКБД не мянялі10

• 4,3%СКБД мянялі, але нічога не змянілася2

• 42,6%Паглядзець вынікі20

Прагаласавалі 47 карыстальнікаў. Устрымаліся 12 карыстальнікаў.

Крыніца: habr.com