🥇«Pro, amma klaster deyil» və ya necə biz DBMS yerli təchiz edərək

Bütün obrazlar uydurmadır, ticarət markaları onların sahiblərinə aiddir, hər hansı bir uyğunluq təsadüfidir və ümumiyyətlə, bu mənim «subyektiv qiymətləndirməmdir, zəhmət olmasa, qapını sındırmayın…».

Bizdə bir SУBD-dən digərinə məlumat bazasındakı məntiqi aşırtma sahəsində kifayət qədər təcrübə var. Hökumətin 16.11.2016-cı il tarixli №1236 saylı qərarını nəzərə alaraq, bu, tez-tez Oracle-dan Postgresql-ə keçirilməsidir. Prosesi maksimum dərəcədə səmərəli və ağrısız təşkil etməyin yollarını ayrıca izah edə bilərik, bugün isə klasterin istifadəsinin xüsusiyyətlərindən və yüksək yüklənmiş paylanmış sistemləri qurarkən qarşılaşa biləcəyiniz problemlərdən danışacağıq.

Spoiler – bəli, кэп, RAC və pg multimaster tamamilə fərqli həllərdir.

Təsəvvür edin ki, siz artıq bütün plsql məntiqini pgsql-ə köçürmüsünüz. Regression testləriniz tamamilə YAXŞIDIR, indi əlbəttə ki, miqyaslandırmanızı düşünürsünüz, çünki yük testləri sizə çox da sevinc vermir, xüsusən də layihəyə əvvəldən qoyulmuş o cihazda, məhz o başqa SУBD üçün. Təsəvvür edin ki, siz «Postgres Professional» yerli istehsalçısından «multimaster» adlı bir həlli tapdınız, bu yalnız «Postgres Pro Enterprise» maksimum versiyasında mövcuddur və təsvirinə görə – bu sizə lazım olana çox oxşayır və ilk səthi öyrənmədə başınıza belə bir fikir gələcək: «O! RAC yerinə əla olacaq! Həm də doğma ölkədə texniki dəstəklə!».

Amma sevinmək tələsməyin, daha sonra bu nüansları bilmək lazım olduğunu izah edəcəyik, çünki onları əvvəlcədən nəzərdə tutmaq çətindir, hətta məhsulun sənədini yaxşı oxumaqla belə. Qiymətləndirin, siz SУBD-nin versiyalarını sənaye sahəsində tez-tez yeniləməyə hazır olacaqsınızmı, çünki bəzi çatışmazlıqlar istehsal işləri ilə uyğunlaşmır və onları testdə aşkar etmək çətindir.
«multimaster» bölməsi – istehsalçının saytında «məhdudiyyət»i diqqətlə oxumağınızı tövsiyə edirik.

İlk qarşılaşacağınız şey tranzaksiyaların «iki fazalı» rejimdə işinə dair xüsusiyyətlərdir və bəzən, sizin prosedur məntiqinizi tamamilə yenidən yazmaqdan başqa, bu vəziyyəti düzəltmək mümkün deyil. Budur sadə bir nümunə:

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;

Xəta baş verir:

XƏTA:  [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) node 3-də ləğv edilib. Xəta detalları üçün onun jurnalını yoxlayın.

Sonra 10.5 ve 10.6 sürümlerinde dead lock ile uzun süre mücadele edebilirsiniz ve bunun tek bilinen çözümü, kümede 'sorunlu' tabloları çıkararak make_table_local yapmaktır. Bu, en azından çalışmayı sağlayacak ve işlemlerin onaylanmasını bekleyen takılmalar nedeniyle her şeyi bloke etmeyecektir. Ya da 11.2 sürümüne güncelleme yapabilirsiniz; bu yardımcı olmalı, ya da belki de hayır, bunu kontrol etmeyi unutmayın.

Bazı sürümlerde daha gizemli bir kilitlenme ile karşılaşabilirsiniz:

username= mtm ve backend_type = background worker

Bu durumda yalnızca DBMS sürümünüzü 11.2 ve üzeri bir versiyona güncellemek yardımcı olacaktır, belki de olmayacaktır.

İndekslerle yapılan bazı işlemler, açıkça Bi-Directional Replication sorununu belirten hatalara yol açabilir; MTM günlüklerinde BDR'yi doğrudan göreceksiniz. 2ndQuadrant mı? Hayır... biz multimaster'ı satın aldık, bu sadece bir tesadüf, bu teknolojinin adı.

[MTM] bdr indeks yeniden kontrolünü desteklemiyor
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: coordinator 3'e (5467) local xid=4083 için ABORT bildirimini gönder
[MTM] node 3'ten MTM-3-25030-83-605694076627780 işlemine ait ABORT_PREPARED mantıksal mesajı alındı
[MTM] node 3 originId=3 olan MTM-3-25030-83-605694076627780 hazırlanan işlem durumu InProgress durumu ile iptal edildi
[MTM] MtmLogAbortLogicalMessage node=3 işlem=MTM-3-25030-83-605694076627780 lsn=9fff448

Eğer geçici tablolar kullanıyorsanız, ''Multimaster genişlemesi verilerinizi tamamen otomatik olarak çoğaltır. Aynı anda yazma işlemleri gerçekleştirebilir ve kümedeki herhangi bir düğümde geçici tablolarla çalışabilirsiniz.'' şeklindeki vaatlere rağmen.

O zaman, gerçekte işleminizde kullanılan tüm tablolarda çoğaltmanın çalışmadığını göreceksiniz, eğer kodda bir geçici tablo oluşturulursa ve hatta multimaster.remote_functions kullanımı da bir fayda sağlamayacaktır; güncellenmek ya da prosedürünüze özgü mantığınızı yeniden yazmak zorunda kalacaksınız. Eğer 'Postgres Pro Enterprise' v 10.5 içinde aynı anda iki genişlemeyi kullanmanız gerekiyorsa, multimaster ve pg_pathman, basit bir örnekte kontrol edin:

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 düğümlerinde bu tür hatalar ortaya çıkmaya başlar:

…
 PATHMAN_CONFIG, əlaqə 23245-i əhatə etmir
> find_in_dynamic_libpath: "\/opt\/…\/ent-10\/lib\/pg_pathman" a baxılır
> find_in_dynamic_libpath: "\/opt\/…\/ent-10\/lib\/pg_pathman.so" a baxılır
> DEBAGLA: find_in_dynamic_libpath: "\/opt\/…\/ent-10\/lib\/pg_pathman" a baxılır
> find_in_dynamic_libpath: "\/opt\/…\/ent-10\/lib\/pg_pathman.so" a baxılır
> PrepareTransaction(1) adı: qeyd olunmamış; blockState: PREPARE; state: INPROGR, xid\/subid\/cid: 6919\/1\/40
> StartTransaction(1) adı: qeyd olunmamış; blockState: DEFAULT; state: INPROGR, xid\/subid\/cid: 0\/1\/0
> 0\/0 tarixində qüvvədə olan 1 zaman şəklinə keçildi
…
Transaction MTM-1-13604-7-612438856339841 (6919) 2 node-də ləğv edildi. Xətanın detallarını görmək üçün qeydini yoxlayın.
...
[MTM] 28295: UZAQ başlanğıc ləğv etmək tranzaksiyası 7017
…
[MTM] 28295: 1 koordinator üçün tranzaksiya (6919) lokal xid=7017 üçün ABORT bildirişi göndərilir

Bu xətaların nə olduğunu texniki dəstəkdə öyrənə bilərsiniz, axı bunu almaqda səbəbsiz deyildiniz.

Nə etməli? Düzdür! ‘Postgres Pro Enterprise’ versiyası 11.2-ə yeniləyin

Xüsusilə bilmək lazımdır ki, sequence, replikasiya edilən DB obyekti olaraq, bütün klaster boyunca davamlı bir dəyərə sahib deyil, hər bir sequence klasterdəki hər bir node üçün lokaldır və əgər unikal məhdudiyyətləri olan sahələriniz varsa və sequence istifadə edirsinizsə, yalnız klasterdəki node sayına uyğun artım edə bilərsiniz, çünki klasterdə nə qədər node varsa, o qədər sürətlə artacaq və sequence, int daha tez tükənəcək, gözlədiyinizdən daha tez. Productda sequence ilə işinizi asanlaşdırmaq üçün, bütün node-larda hər bir sequence üçün lazım olan artımları edə biləcək alter_sequences funksiyasını tapacaqsınız, amma funksiyanın bütün versiyalarda işləməyəcəyinə hazır olun. Əlbəttə, kodu github-dan götürərək və ya DBMS-də birbaşa düzəldərək özünüz yaza bilərsiniz. Bu zaman serialbigserial tipli sahələr daha dəqiq işləyəcək, lakin istifadələri üçün, ehtimal ki, prosedurlarınızın və funksiyalarınızın kodunu yenidən yazmaq lazım gələcək. Bəlkə də bəzi insanlara monotonic_sequences funksiyası faydalı olacaq.

11.2 versiyasından əvvəl ‘Postgres Pro Enterprise’ replikasiyası yalnız unikal birincil açarların olması halında işləyəcək, bunu inkişaf etdirərkən nəzərə alın.

Xüsusilə, npgsql-ın klaster həllindəki xüsusiyyətlərini qeyd etmək istərdim, bu problemlər single node-da meydana gəlmir, amma multi-masterda tamamilə mövcuddur.
Bəzi versiyalarda aşağıdakı xətaya rast gələ bilərsiniz:

İstisna Detalları: Npgsql.PostgresException: 25001: SET TRANSACTION ISOLATION LEVEL komandasını icra etmək zamanı
Təsvir: Cari veb tələbin icrası zamanı idarə olunmayan bir istisna baş verdi. Xətanın haradan qaynaqlandığı barədə daha ətraflı məlumat üçün stack trace-ı nəzərdən keçirin.

Nə edə bilərsiniz? Bəzi versiyaları istifadə etməmək lazımdır. Bunu bilmək vacibdir, çünki xəta yalnız bir versiyada meydana gəlmir və hətta ilk düzəlişdən sonra belə, daha sonra onunla qarşılaşa bilərsiniz. Bunun üçün hazırlıqlı olmaq da lazımdır və istehsalçı tərəfindən düzəldilən bütün aşkar edilmiş DBMS defektlərini ayrı regressiya testləri ilə əhatə etmək daha yaxşıdır. Yəni, etibar et, amma yoxla.

Əgər tətbiq npgsql istifadə edirsə və node-lar arasında keçid edirsə, düşünərək ki, hamısı tamamilə eynidir, sizdə aşağıdakı xəta ortaya çıxa bilər:

İSTİSNADA: Npgsql.PostgresException (0x80004005): XX000: tip üçün keçid önbelleğinde baxış uğursuz oldu ...

Belə bir səhv, quraşdırma aparıldığı üçün baş verəcəkdir.

(NpgsqlConnection.GlobalTypeMapper.MapComposite("some_composite_type");)

kompozit tiplərin tətbiq işə düşdüyü zaman bütün bağlantılar üçün. Nəticədə isə bir nödın identifikatorunu alırıq, və başqa bir nöd üçün sorğu göndərdiyimizdə, bu uyğunsuz olur, buna görə də bir səhv qaytarılır. Yəni, bəzi proqramlar üçün klasterdə kompozit tiplerle şaffaf şəkildə işləmək mümkün olmayacaq, əgər əlavə yazılışlar etməsəniz.

Həmçinin, biz bilirik ki, klasterin vəziyyəti haqqında ümumi qiymətləndirmə, diaqnostika və əməliyyat üçün olduqca vacibdir. Məhsulda sizin həyatınızı asanlaşdırmalı olan bəzi funksiyalar tapa biləcəksiniz, amma bəzən onlar, gözlədiyinizdən və hətta istehsalçının özündən tamamilə fərqli nəticələr qaytara bilərlər.

Məsələn:

select mtm.collect_cluster_info();
Hər bir nöd eyni nəticəni verir:
(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")

Amma niyə LiveNodes sahəsində hər yerdə 2 var, halbuki multimasterin fəaliyyət izahına görə bu AllNodes=3-ə uyğun gəlməlidir? Cavab: DBMS versiyasını yeniləmək lazımdır.

Və bütün düyünlərdən loqlar toplamaya hazır olun, çünki adətən «səhv digər düyünün loğunda tapılır» görəcəksiniz. Texniki dəstək siz tərəfindən aşkar edilən bütün səhvləri qəbul edəcək və növbəti versiyanın hazır olması barədə məlumat verəcəkdir. Bəzən bu versiyanı, xidmətin dayandırılması ilə, bəzən də uzun müddət işlətmək lazımdır (bu sizin DBMS-in ölçüsündən asılıdır). İstismar problemlərin istehsalçını ciddi narahat edəcəyinə ümid etməyin və aşkar edilən səhvlər üzərində yeniləmə prosesi üçün istehsalçının nümayəndələrini cəlb etmək lazım deyil, çünki nəticədə aktivdə ehtiyat nüsxəsi olmadan açıq kütlə ilə qarşılaşa bilərsiniz.

Əslində, kommersiya məhsulunun lisenziyasının şərtlərində istehsalçı açıq-aşkar xəbərdarlıq edir: «Bu proqram təminatı olduğu kimi təqdim olunur və Məlumatların Sürətləndirilməsi Şirkəti 'Postgres Professional' hər hansı bir dəstək, dəstək, yeniləmələr, genişləndirilmiş və ya dəyişikliklər təqdim etməyə borclu deyil.»

Əgər hansı məhsuldan bəhs etdiyinizi hələ anlamamısınızsa, bu bütün təcrübə Postgres Pro Enterprise verilən bazasının birillik istifadəsi nəticəsində əldə olunub. Özünüz qərar verin, vəziyyət o qədər acınacaqlıdır ki, göbələklər meydana gəlir.

Amma bu, yaranan problemlərin vaxtında və operativ şəkildə aradan qaldırılmadığı da olardı.

Amma, bu dəqiq olaraq baş vermir. Görünür ki, istehsalçının resursları aşkar edilən səhvləri operativ şəkildə aradan qaldırmağa kifayət etmir.

Yalnız qeydiyyatdan keçmiş istifadəçilər sorğuda iştirak edə bilərlər. Daxil olun, xahiş edirəm.

İxrac edilmiş xarici/propriyətçi DBMS-dən azad/daxili sistemlərə keçid təcrübəniz varmı?

21,3%Bəli, müsbət 10
10,6%Bəli, mənfi 5
21,3%Xeyr, DBMS dəyişdirilməyib10
4,3%DBMS dəyişdirildi, amma heç nə dəyişmədi2
42,6%Nəticələri görmək20

47 istifadəçi səs verdi. 12 istifadəçi tərəddüd etdi.

Mənbə: habr.com

«Pro, ama clusterdən yox» və ya biz SУBD-ni necə importdan yerli istehsala keçirdik

İxrac edilmiş xarici/propriyətçi DBMS-dən azad/daxili sistemlərə keçid təcrübəniz varmı?