„პრო, მაგრამ არა კლასტერი“ ან როგორ შევცვალეთ იმპორტირებული DBMS

(ც) Yandex.გამოსახულებები

ყველა პერსონაჟი ფიქტიურია, სასაქონლო ნიშნები ეკუთვნის მათ მფლობელებს, ნებისმიერი მსგავსება არის შემთხვევითი და ზოგადად, ეს არის ჩემი „სუბიექტური ღირებულებითი განსჯა, გთხოვთ, არ გატეხოთ კარი...“.

ჩვენ გვაქვს მნიშვნელოვანი გამოცდილება ლოგიკის მქონე საინფორმაციო სისტემების მონაცემთა ბაზაში გადატანის ერთი DBMS-დან მეორეზე. მთავრობის 1236 წლის 16.11.2016 ნოემბრის No. XNUMX დადგენილების კონტექსტში, ეს ხშირად არის Oracle-დან Postgresql-ზე გადაცემა. ჩვენ შეგვიძლია ცალ-ცალკე გითხრათ, თუ როგორ უნდა მოაწყოთ პროცესი რაც შეიძლება ეფექტურად და უმტკივნეულოდ, დღეს ვისაუბრებთ კლასტერის გამოყენების მახასიათებლებზე და რა პრობლემები შეიძლება შეგვხვდეს პროცედურებსა და ფუნქციებში რთული ლოგიკით დატვირთული სისტემების აგებისას.

სპოილერი – დიახ, cap, RAC და pg multimaster ძალიან განსხვავებული გადაწყვეტილებებია.

ვთქვათ, თქვენ უკვე გადაიტანეთ მთელი ლოგიკა plsql-დან pgsql-ზე. და თქვენი რეგრესიის ტესტები საკმაოდ კარგია, ახლა რა თქმა უნდა, თქვენ ფიქრობთ სკალირებაზე, რადგან... დატვირთვის ტესტები დიდად არ გაგახარებთ, განსაკუთრებით იმ აპარატურაზე, რომელიც თავდაპირველად შედიოდა პროექტში, ძალიან განსხვავებული DBMS-ისთვის. ვთქვათ, თქვენ იპოვეთ გამოსავალი შიდა გამყიდველისგან "Postgres Professional" ოფციით სახელწოდებით "multimaster", რომელიც ხელმისაწვდომია მხოლოდ "Postgres Pro Enterprise"-ის "მაქსიმალურ" ვერსიაში და აღწერილობის მიხედვით - ძალიან ჰგავს იმას. გჭირდება და პირველი ზედაპირული შესწავლით თავში გამიჩნდება აზრი: „ოჰ! RAC-ის ნაცვლად ესე იგი! და თუნდაც ტექნიკური მილსადენით ჩვენს სამშობლოში!“.

ოღონდ ნუ იჩქარებთ გახარებას და შემდგომ ჩვენ აღვწერთ, რატომ გჭირდებათ ამ ნიუანსების ცოდნა, რადგან... მათი პროგნოზირება რთულია, პროდუქტის დოკუმენტაციის კარგად წაკითხვის შემდეგაც კი. შეაფასეთ მზად ხართ თუ არა ხშირად განაახლოთ DBMS ვერსიები პირდაპირ წარმოების ადგილზე, რადგან ზოგიერთი დეფექტი არ არის თავსებადი სამრეწველო გამოყენებასთან და ძნელია გამოვლენილი ტესტირების დროს.
დაიწყეთ მწარმოებლის ვებსაიტზე "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.

მერე შეიძლება დიდხანს ებრძოლო 10.5, 10.6 ვერსიებში მკვდარი ბლოკით და ერთადერთი ცნობილი გამოსავალი, რომელიც კლავს კლასტერის მთელ არსს, არის კლასტერიდან „პრობლემური“ ცხრილების ამოღება, ე.ი. გააკეთეთ make_table_local, მაგრამ ეს მინიმუმ საშუალებას მისცემს მას იმუშაოს და არ დააყოვნებს ყველაფერს ტრანზაქციის ჩაბარების მოლოდინების გამო. კარგად, ან დააინსტალირეთ 11.2 ვერსიის განახლება, რაც დაგვეხმარება, მაგრამ შესაძლოა არა, არ დაგავიწყდეთ შემოწმება.

ზოგიერთ ვერსიაში შეგიძლიათ მიიღოთ კიდევ უფრო იდუმალი საკეტი:

username= mtm и backend_type = background worker

და ამ სიტუაციაში, მხოლოდ DBMS ვერსიის 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.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 კოდი ან თავად შეასწოროთ იგი პირდაპირ DBMS-ში. ამ შემთხვევაში ველები serialbigserial ტიპის უფრო სწორად იმუშავებს, მაგრამ მათი გამოსაყენებლად, სავარაუდოდ, დაგჭირდებათ თქვენი პროცედურების და ფუნქციების კოდის გადაწერა. იქნებ ვინმეს გამოადგეს ფუნქცია monotonic_sequences.

Postgres Pro Enterprise-ის 11.2 ვერსიამდე, რეპლიკაცია იმუშავებს მხოლოდ იმ შემთხვევაში, თუ არსებობს უნიკალური პირველადი გასაღებები, გაითვალისწინეთ ეს განვითარებისას.

ცალკე, მინდა აღვნიშნო ის თავისებურებები, თუ როგორ მუშაობს npgsql კლასტერულ გადაწყვეტაში, ეს პრობლემები არ წარმოიქმნება ერთ კვანძზე, მაგრამ საკმაოდ არსებობს მულტიმასტერში.
ზოგიერთ ვერსიაში შეიძლება შეგექმნათ შეცდომა:

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. 

Რა შეიძლება გაკეთდეს? თქვენ უბრალოდ არ უნდა გამოიყენოთ ზოგიერთი ვერსია. თქვენ უნდა იცოდეთ ისინი, რადგან... შეცდომა ჩნდება ერთზე მეტ ვერსიაში და მისი პირველი გამოსწორების შემდეგაც შეიძლება მოგვიანებით შეგხვდეთ. თქვენ ასევე უნდა მოემზადოთ ამისთვის და უმჯობესია დაფაროთ ყველა გამოვლენილი DBMS დეფექტი, რომელიც გამოსწორებულია მწარმოებლის მიერ ცალკე რეგრესიული ტესტებით. ასე ვთქვათ, ენდეთ, მაგრამ გადაამოწმეთ.

თუ აპლიკაცია იყენებს 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? პასუხი: თქვენ უნდა განაახლოთ DBMS ვერსია.

და მოემზადეთ შეაგროვოთ ჟურნალი ყველა კვანძისთვის, რადგან... ჩვეულებრივ ნახავთ "შეცდომა სხვა კვანძის ჟურნალშია." ტექნიკური მხარდაჭერა მიიღებს თქვენს მიერ იდენტიფიცირებულ ყველა დეფექტს და გაცნობებთ, რომ შემდეგი ვერსია მზად არის, რომელიც ხან სერვისის შეჩერებით, ხან დიდი ხნით (დამოკიდებულია თქვენი DBMS-ის ზომაზე) დასჭირდება ინსტალაციას. არ უნდა გქონდეთ იმედი, რომ ოპერაციული პრობლემები დიდად შეაწუხებს გამყიდველს და გამოვლენილი დეფექტების გამო განახლება განხორციელდება გამყიდველის წარმომადგენლების მონაწილეობით, უფრო სწორად, თქვენ არც კი გჭირდებათ გამყიდველის წარმომადგენლების ჩართვა, ვინაიდან დასასრულს, თქვენ შეგიძლიათ დაასრულოთ დაშლილი კლასტერი წარმოებაში სარეზერვო ასლის გარეშე.

სინამდვილეში, კომერციული პროდუქტის ლიცენზიაში მწარმოებელი გულწრფელად აფრთხილებს: „ეს პროგრამული უზრუნველყოფა მოწოდებულია „როგორც არის“ საფუძველზე და Postgres Professional Limited Liability Company არ არის ვალდებული უზრუნველყოს ტექნიკური მომსახურება, მხარდაჭერა, განახლებები, გაფართოებები ან ცვლილებები“.

თუ ჯერ არ გამოიცანით რომელ პროდუქტზეა საუბარი, მაშინ მთელი ეს გამოცდილება Postgres Pro Enterprise-ის მონაცემთა ბაზის ერთწლიანი მუშაობის შედეგად მოიპოვეთ. თქვენ შეგიძლიათ გააკეთოთ საკუთარი დასკვნა, ის იმდენად ნესტიანია, რომ სოკო იზრდება.

მაგრამ ეს არც ისე ცუდი იქნებოდა, თუ დროულად გაკეთდა და დროულად აღმოიფხვრა წარმოშობილი პრობლემები.

მაგრამ ეს არის ზუსტად ის, რაც არ ხდება. როგორც ჩანს, მწარმოებელს არ აქვს საკმარისი რესურსი გამოვლენილი შეცდომების დროულად აღმოსაფხვრელად.

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

გაქვთ გამოცდილება უცხოური/საკუთრების DBMS-დან თავისუფალ/შინაურზე გადასვლის?

• 21,3%დიახ, დადებითი10

• 10,6%დიახ, უარყოფითი5

• 21,3%არა, DBMS არ შეცვლილა10

• 4,3%DBMS შეიცვალა, მაგრამ არაფერი შეცვლილა2

• 42,6%შედეგების ნახვა20

მისცა ხმა 47 მომხმარებელმა. 12-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com