„Професионалист, но не и клъстер“ или как заменихме импортираната СУБД

(ts) Yandex.Изображения

Всички герои са измислени, търговските марки принадлежат на техните собственици, всякакви прилики са случайни и като цяло това е моята „субективна ценностна преценка, моля, не разбивайте вратата...“.

Имаме значителен опит в прехвърлянето на информационни системи с логика в база данни от една СУБД в друга. В контекста на правителствено постановление № 1236 от 16.11.2016 ноември XNUMX г. това често е прехвърляне от Oracle към Postgresql. Отделно можем да ви кажем как да организирате процеса възможно най-ефективно и безболезнено; днес ще говорим за характеристиките на използването на клъстер и какви проблеми могат да възникнат при изграждането на силно натоварени разпределени системи със сложна логика в процедурите и функциите.

Спойлер – да, cap, RAC и pg multimaster са много различни решения.

Да приемем, че вече сте прехвърлили цялата логика от plsql към pgsql. И вашите регресионни тестове са съвсем наред, сега, разбира се, мислите за мащабиране, защото... тестовете за натоварване не ви правят много щастливи, особено на хардуера, който първоначално беше включен в проекта, за тази много различна СУБД. Да приемем, че сте намерили решение от местния доставчик "Postgres Professional" с опция, наречена "multimaster", която е налична само в "максималната" версия на "Postgres Pro Enterprise" и според описанието - тя е много подобна на това, което имате нужда, и с първото повърхностно проучване ще дойде мисълта ми дойде в главата: „О! Това е вместо RAC! И дори с технически тръбопровод в родината ни!“

Но не бързайте да се радвате и по-нататък ще опишем защо трябва да знаете тези нюанси, защото... те са трудни за предсказване, дори след задълбочено прочитане на документацията на продукта. Преценете дали сте готови често да актуализирате версиите на СУБД директно на производствения сайт, т.к Някои дефекти не са съвместими с индустриална употреба и са трудни за откриване по време на тестване.
Започнете, като внимателно прочетете раздела „мултимайстор“ - „ограничения“ на уебсайта на производителя.

Първото, с което може да се сблъскате, са особеностите на функциониране на транзакциите, при т.нар. „двуфазен“ режим и понякога няма начин да се поправи това, освен чрез пренаписване на цялата логика на вашата процедура. Ето един прост пример:

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 и единственото известно решение, което убива цялата същност на клъстера, е да премахнете „проблемните“ таблици от клъстера, т.е. направете make_table_local, но това поне ще му позволи да работи и няма да постави всичко на изчакване поради висящи чакания за ангажиране на транзакция. Е, или инсталирайте актуализация до версия 11.2, която трябва да помогне, но може би не, не забравяйте да проверите.

В някои версии можете да получите още по-мистериозна ключалка:

username= mtm и backend_type = background worker

И в тази ситуация само актуализирането на версията на СУБД до 11.2 и по-нова ще ви помогне или може би няма да помогне.

Някои операции с индекси могат да доведат до грешки, които ясно показват, че проблемът е в двупосочна репликация; вие директно ще видите BDR в регистрационните файлове на MTM. Наистина ли е 2-ри квадрант? Не... купихме мултимастър, просто случайно, така се казва технологията.

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

Следните грешки започват да се появяват в регистрационните файлове на 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

Можете да разберете какви са тези грешки в техническата поддръжка, не напразно сте го купили.

Какво да правя? вярно! Надстройте до "Postgres Pro Enterprise" v 11.2

Отделно, трябва да знаете, че последователността, като обект на репликирана база данни, няма стойност от край до край в целия клъстер, всяка последователност е локална за всеки възел и ако имате полета с уникални ограничения и използвате последователност, тогава можете да направите само увеличение, еквивалентно на номера на възела в клъстера, защото Колкото е възможно повече възли в клъстера, последователност и int ще растат по-бързо, отколкото сте очаквали. За да опростите работата с последователност в продукта, ще намерите дори функцията alter_sequences, която ще направи необходимите увеличения за всяка последователност на всички възли, но бъдете готови, че функцията няма да работи във всички версии. Разбира се, можете да го напишете сами, като използвате кода от github като основа или да го коригирате сами директно в СУБД. В този случай полетата с тип serialbigserial ще работят по-правилно, но за да ги използвате, най-вероятно ще трябва да пренапишете кода на вашите процедури и функции. Може би някой ще намери за полезна функцията monotonic_sequences.

Преди версия 11.2 на Postgres Pro Enterprise, репликацията ще работи само ако има уникални първични ключове, вземете това предвид при разработването.

Отделно бих искал да спомена особеностите на това как npgsql работи в клъстерно решение; тези проблеми не възникват на един възел, но са доста присъстващи в multimaster.
В някои версии може да срещнете грешка:

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 Professional Limited Liability Company не е задължено да предоставя поддръжка, поддръжка, актуализации, разширения или промени.“

Ако все още не сте се досетили за кой продукт говорим, тогава целият този опит е натрупан в резултат на дългогодишна работа с базата данни Postgres Pro Enterprise. Сами можете да си направите извода, толкова е влажно, че растат гъби.

Но това не би било толкова лошо, ако беше направено своевременно и своевременно отстрани възникващите проблеми.

Но точно това не се случва. Очевидно производителят не разполага с достатъчно ресурси, за да отстрани своевременно откритите грешки.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Имате ли опит в преминаването от чужда/собствена СУБД към безплатна/местна?

• 21,3%Да, положително10

• 10,6%Да, отрицателен 5

• 21,3%Не, СУБД не е променена10

• 4,3%СУБД беше променена, но нищо не се промени2

• 42,6%Вижте резултатите20

47 потребители гласуваха. 12 потребители се въздържаха.

Източник: www.habr.com