🥇«Про, да не кластер» или как ние СУБД импортозаместихме

(ц) Яндекс.Картинки

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

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

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

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

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

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

създайте таблица test1 (id цяло число, id1 цяло число);
въведете в test1 стойности (1, 1),(1, 2);
 
ALTER TABLE test1 ДОДАДЕТЕ ПРЕДПИСАНИЕ test1_uk УНИКАЛНО (id,id1) ВЪЗМОЖНО ЗА ОТЛАГАНЕ ПРЪВО НА ОТЛАГАНЕ;
 
актуализирайте test1
           задайте id1 =
               случай id1
                 когато 1
                 тогава 2
                 иначе id1 - знак(2 - 1)
               край
         където id1 между 1 и 2;

Възниква грешка:

ГРЕШКА:  [MTM] Транзакция MTM-1-2435-10-605783555137701 (10654) е прекратена на възел 3. Проверете логовете, за да видите подробности за грешката.

След това можете дълго да се борите с мъртвата блокировка в версии 10.5, 10.6 и единственото известно решение, което убива същността на клъстера – е да се премахнат "проблемните" таблици от клъстера, т.е. да се направи make_table_local, но това поне ще позволи работа, а не ще спре всичко заради задържани очаквания за фиксиране на транзакции. Или да се обновите до версия 11.2, което трябва да помогне, а може и не, не забравяйте да проверите.

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

потребителско име= mtm и backend_type = фонова работник

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

Някои операции с индекси могат да доведат до грешки, където явно е посочено, че проблемът е точно в Bi-Directional Replication, в логовете на MTM ще видите BDR. Не може да бъде 2ndQuadrant? Не, ние закупихме multimaster, това е просто съвпадение, това е наименованието на технологията.

[MTM] bdr не поддържа проверки на индекси
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: изпратете уведомление ABORT за транзакция (5467) местен xid=4083 към координатор 3
[MTM] Получете ABORT_PREPARED логично съобщение за транзакция MTM-3-25030-83-605694076627780 от възел 3
[MTM] Прекратяване на подготвена транзакция MTM-3-25030-83-605694076627780 статус В процес от възел 3 originId=3
[MTM] MtmLogAbortLogicalMessage възел=3 транзакция=MTM-3-25030-83-605694076627780 lsn=9fff448

Ако използвате временни таблици, независимо от уверенията: "Разширението multimaster извършва репликация на данни напълно автоматично. Можете едновременно да изпълнявате записващи транзакции и да работите с временни таблици на всяка възел на клъстера."

Тогава всъщност ще получите, че репликацията не работи за всички таблици, използвани в процедурата, ако в кода има създаване на временна таблица, и дори използването на multimaster.remote_functions няма да помогне, ще трябва да се обновите или да пренапишете логиката си в процедурата. Ако трябва да използвате едновременно две разширения multimaster и pg_pathman в рамките на "Postgres Pro Enterprise" v 10.5, уверете се, че при такъв просто пример:

Създайте таблица measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) ПАРТИЦИОНИРАНЕ ПО ДИАПАЗОН (logdate);

Създайте таблица measurement_y2019m06 ПАРТИЦИЯ НА measurement ЗА СТОЙНОСТИ ОТ ('2019-06-01') ДО ('2019-07-01');
въведете в measurement стойности (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
въведете в measurement стойности (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
въведете в measurement стойности (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
въведете в measurement стойности (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

В логовете на възлите СУБД започват да се появяват следните грешки:

…
 PATHMAN_CONFIG не съдържа връзка 23245
> find_in_dynamic_libpath: опитва "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: опитва "\/opt\/\/…\/ent-10\/lib\/pg_pathman.so"
> ОТЛАДКА:  find_in_dynamic_libpath: опитва "\/opt\/…\/ent-10\/lib\/pg_pathman"
> find_in_dynamic_libpath: опитва "\/opt\/…\/ent-10\/lib\/pg_pathman.so"
> PrepareTransaction(1) име: неназован; blockState: PREPARE; state: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) име: неназован; blockState: DEFAULT; state: INPROGR, xid\/subid\/cid: 0\/1\/0
> превключено на времева линия 1, валидна до 0\/0
…
Транзакция MTM-1-13604-7-612438856339841 (6919) е отменена на възел 2. Проверете логовете му, за да видите детайлите за грешката.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: изпратих ABORT известие за транзакция (6919) локален xid=7017 до координатор 1

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

Какво да направите? Правилно! Обновете до «Postgres Pro Enterprise» до v 11.2

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

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

Поотделно трябва да споменем особеностите на работата на npgsql именно в кластерни решения, тези проблеми не възникват на единен възел, но в многоузелно решение категорично присъстват.
В някои версии можете да се сблъскате с грешка:

Детайли за изключение: Npgsql.PostgresException: 25001: команда SET TRANSACTION ISOLATION LEVEL 
Описание: Необработена изключение възникна по време на изпълнението на текущата уеб заявка. Моля, прегледайте стека на извикванията за допълнителна информация относно грешката и откъде е произлязла в кода.

Какво можете да направите? Просто не използвайте някои версии. Трябва да ги знаете, тъй като грешката не се появява в една версия, и дори след първото й коригиране, можете да се сблъскате с нея по-късно. Трябва да сте готови за това и е добре всички открити дефекти на СУБД, които производителят поправя, да се покриват с отделни регресионни тестове. Както се казва, доверявай, но проверявай.

Ако приложението използва npgsql и преминава между възлите, мислейки, че всички те са изцяло еднакви, може да получите грешка:

EXCEPTION: Npgsql.PostgresException (0x80004005): XX000: неуспешно търсене на кеш за тип ...

Такава грешка ще възникне, защото се изпълнява свързване

(NpgsqlConnection.GlobalTypeMapper.MapComposite("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. Можете да направите извода сами, толкова е сурово, че гъбите израстват.

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

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

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