“Pro, lakin çoxluq deyil” və ya idxal edilmiş DBMS-ni necə əvəz etdiyimiz

(ts) Yandex.Şəkillər

Bütün personajlar uydurmadır, əmtəə nişanları öz sahiblərinə məxsusdur, hər hansı oxşarlıqlar təsadüfidir və ümumiyyətlə, bu mənim “subyektiv dəyər mühakiməmdir, xahiş edirəm qapını sındırmayın...”.

Məntiqli informasiya sistemlərinin verilənlər bazasına bir DBMS-dən digərinə ötürülməsində kifayət qədər təcrübəmiz var. Hökumətin 1236 noyabr 16.11.2016-cı il tarixli XNUMX saylı fərmanı kontekstində bu, çox vaxt Oracle-dan Postgresql-a köçürmədir. Prosesi mümkün qədər səmərəli və ağrısız şəkildə necə təşkil edəcəyinizi ayrıca söyləyə bilərik, bu gün klasterdən istifadənin xüsusiyyətləri və prosedur və funksiyalarda mürəkkəb məntiqə malik yüksək yüklənmiş paylanmış sistemlər qurarkən hansı problemlərlə qarşılaşa biləcəyiniz barədə danışacağıq.

Spoyler – bəli, cap, RAC və pg multimaster çox fərqli həllərdir.

Tutaq ki, siz artıq bütün məntiqi plsql-dən pgsql-ə köçürdünüz. Və reqressiya testləriniz olduqca yaxşıdır, indi əlbəttə ki, miqyasını genişləndirməyi düşünürsünüz, çünki... yükləmə testləri sizi çox xoşbəxt etmir, xüsusən də layihəyə ilkin olaraq daxil edilmiş avadanlıqda, o çox fərqli DBMS üçün. Deyək ki, siz yerli satıcı "Postgres Professional"-dan "multimaster" adlı bir seçimlə həll tapdınız, bu həll yalnız "Postgres Pro Enterprise" in "maksimum" versiyasında mövcuddur və təsvirə görə - bu, nəyə çox bənzəyir. ehtiyacınız var və ilk səthi araşdırma ilə ağlıma belə bir fikir gələcək: “Oh! RAC əvəzinə budur! Hətta vətənimizdə texniki kəmərlə belə!”

Ancaq sevinməyə tələsməyin və daha sonra bu nüansları niyə bilməli olduğunuzu izah edəcəyik, çünki... məhsul sənədlərini hərtərəfli oxuduqdan sonra belə onları proqnozlaşdırmaq çətindir. DBMS versiyalarını birbaşa istehsal saytında tez-tez yeniləməyə hazır olub olmadığınızı qiymətləndirin, çünki Bəzi qüsurlar sənaye istifadəsi ilə uyğun gəlmir və sınaq zamanı aşkar etmək çətindir.
İstehsalçının veb saytındakı "multimaster" - "məhdudiyyətlər" bölməsini diqqətlə oxumaqla başlayın.

Qarşılaşa biləcəyiniz ilk şey, sözdə əməliyyatların necə işləməsinin xüsusiyyətləridir. "iki fazalı" rejimdir və bəzən prosedurunuzun bütün məntiqini yenidən yazmaqdan başqa bunu düzəltməyin heç bir yolu yoxdur. 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;

Səhv baş verir:

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

Sonra 10.5, 10.6 versiyalarında ölü kilidlə uzun müddət mübarizə apara bilərsiniz və klasterin bütün mahiyyətini öldürən yeganə məlum həll "problem" cədvəllərini klasterdən çıxarmaqdır, yəni. make_table_local edin, lakin bu, ən azı onun işləməsinə imkan verəcək və əməliyyatların icrası üçün gözləntilərin asılması səbəbindən hər şeyi gözləməyə qoymayacaq. Yaxşı, və ya 11.2 versiyasına bir yeniləmə quraşdırın, bu kömək etməlidir, amma bəlkə də yox, yoxlamağı unutmayın.

Bəzi versiyalarda daha da sirli bir kilid əldə edə bilərsiniz:

username= mtm и backend_type = background worker

Və bu vəziyyətdə, yalnız DBMS versiyasını 11.2 və daha yüksək versiyaya yeniləmək sizə kömək edəcək və ya bəlkə də kömək etməyəcək.

İndekslərlə bəzi əməliyyatlar səhvlərə gətirib çıxara bilər ki, bu da problemin İki İstiqamətli Replikasiyada olduğunu açıq şəkildə göstərir; siz birbaşa MTM qeydlərində BDR-ni görəcəksiniz. Həqiqətən 2-ci Quadrantdır? Yox... biz multimaster aldıq, bu, sadəcə bir təsadüfdür, texnologiyanın adıdır.

[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 

Təminatlara baxmayaraq, müvəqqəti cədvəllərdən istifadə edirsinizsə: “Multimaster genişləndirilməsi məlumatların təkrarlanmasını tam avtomatik şəkildə həyata keçirir. Siz eyni vaxtda klasterdəki istənilən qovşaqda yazı əməliyyatları həyata keçirə və müvəqqəti cədvəllərlə işləyə bilərsiniz.”

Onda faktiki olaraq əldə edəcəksiniz ki, replikasiya prosedurda istifadə edilən bütün cədvəllərdə işləmir, əgər kod müvəqqəti cədvəlin yaradılmasını ehtiva edirsə və hətta multimaster.remote_functions funksiyalarından istifadə kömək etməyəcəksə, məntiqinizi yeniləməli və ya yenidən yazmalı olacaqsınız. prosedur. Əgər “Postgres Pro Enterprise” v 10.5 çərçivəsində eyni vaxtda iki multimaster və pg_pathman uzantısından istifadə etməlisinizsə, bu sadə nümunə ilə bunu yoxlayın:

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 qovşaqlarının qeydlərində aşağıdakı səhvlər görünməyə başlayır:

…
 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

Bu səhvlərin nə olduğunu texniki dəstəkdə öyrənə bilərsiniz, onu almağınız boş yerə deyil.

Nə etməli? Doğru! "Postgres Pro Enterprise" v 11.2-ə təkmilləşdirin

Ayrı-ayrılıqda bilməlisiniz ki, təkrarlanan verilənlər bazasının obyekti olan ardıcıllıq bütün klasterdə başdan-başa dəyərə malik deyil, hər bir ardıcıllıq hər bir qovşaq üçün lokaldir və əgər unikal məhdudiyyətləri və istifadə ardıcıllığı olan sahələriniz varsa, onda siz yalnız klasterdəki node nömrəsinə ekvivalent artım edə bilərsiniz, çünki Klasterdə mümkün qədər çox qovşaq, ardıcıllıq və int gözlədiyinizdən daha sürətli artacaq. Məhsulda ardıcıllıqla işləməyi asanlaşdırmaq üçün hətta bütün qovşaqlarda hər ardıcıllıq üçün lazımi artımları edəcək alter_sequences funksiyasını tapa bilərsiniz, lakin bu funksiyanın bütün versiyalarda işləməyəcəyinə hazır olun. Əlbəttə ki, github kodunu əsas götürərək və ya onu birbaşa DBMS-də özünüz düzəldəraq özünüz yaza bilərsiniz. Bu halda serialbigserial tipli sahələr daha düzgün işləyəcək, lakin onlardan istifadə etmək üçün çox güman ki, prosedur və funksiyalarınızın kodunu yenidən yazmalısınız. Bəlkə kimsə monotonic_sequences funksiyasını faydalı tapa bilər.

Postgres Pro Enterprise-in 11.2 versiyasından əvvəl təkrarlama yalnız unikal əsas açarlar olduqda işləyəcək, inkişaf etdirərkən bunu nəzərə alın.

Ayrı-ayrılıqda, npgsql-in klaster həllində necə işləməsinin xüsusiyyətlərini qeyd etmək istərdim; bu problemlər bir qovşaqda yaranmır, lakin multimasterdə olduqca mövcuddur.
Bəzi versiyalarda xəta ilə qarşılaşa bilərsiniz:

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. 

Nə etmək olar? Sadəcə bəzi versiyalardan istifadə etməməlisiniz. Onları bilmək lazımdır, çünki... Səhv birdən çox versiyada görünür və hətta ilk düzəlişdən sonra belə daha sonra qarşılaşa bilərsiniz. Siz də buna hazır olmalısınız və istehsalçı tərəfindən düzəldilmiş bütün müəyyən edilmiş DBMS qüsurlarını ayrıca reqressiya testləri ilə əhatə etmək daha yaxşıdır. Demək, güvən, amma yoxla.

Tətbiq npgsql istifadə edirsə və onların hamısının eyni olduğunu düşünərək qovşaqlar arasında keçid edirsə, onda xəta ala bilərsiniz:

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

Bağlama davam etdiyi üçün bu xəta baş verəcək

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

bütün bağlantılar üçün tətbiqin başlanğıcında kompozit növlər. Nəticədə, bir qovşaqdan bir identifikator alırıq və başqa bir qovşaqda sorğu edərkən, uyğun gəlmir, nəticədə bir səhv qaytarılır, yəni. Klasterdə kompozit tiplərlə şəffaf işləmək əlavə proqram tərəfi yenidən yazmalar olmadan bəzi proqramlar üçün mümkün olmayacaq (əgər bunu bacarırsınızsa).

Hamımızın bildiyimiz kimi, klasterin vəziyyətinin ümumi qiymətləndirilməsi əməliyyat zamanı diaqnostika və əməliyyat tədbirləri üçün çox vacibdir, məhsulda həyatınızı asanlaşdıran bəzi funksiyaları tapa bilərsiniz, lakin bəzən onlar tamamilə fərqli bir şey verə bilər. siz və hətta istehsalçının özləri də onlardan gözləyirsiniz.

Misal üçün:

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

Bəs niyə LiveNodes sahəsində hər yerdə 2 rəqəmi var, baxmayaraq ki, multimasterin işinin təsvirinə görə AllNodes=3 nömrəsinə uyğun olmalıdır? Cavab: DBMS versiyasını yeniləməlisiniz.

Və bütün qovşaqlar üçün qeydlər toplamağa hazır olun, çünki... adətən "xəta başqa bir node jurnalındadır" yazısını görəcəksiniz. Texniki dəstək müəyyən etdiyiniz bütün qüsurları qəbul edəcək və növbəti versiyanın hazır olduğunu sizə məlumat verəcək, bəzən xidmət dayandırılmış, bəzən isə uzun müddət (DBMS-nin ölçüsündən asılı olaraq) quraşdırılmalı olacaq. Siz ümid etməməlisiniz ki, əməliyyat problemləri satıcını çox narahat edəcək və aşkar edilmiş qüsurlarla bağlı yeniləmə satıcının nümayəndələrinin iştirakı ilə həyata keçiriləcək, daha doğrusu, satıcının nümayəndələrini cəlb etməyə belə ehtiyac yoxdur, çünki sonunda ehtiyatsız istehsalda sökülən çoxluqla nəticələnə bilərsiniz.

Əslində, kommersiya məhsulu üçün lisenziyada istehsalçı vicdanla xəbərdarlıq edir: "Bu proqram təminatı" olduğu kimi" təmin edilir və Postgres Peşəkar Məhdud Məsuliyyətli Cəmiyyəti texniki xidmət, dəstək, yeniləmələr, genişləndirmələr və ya dəyişikliklər təmin etmək məcburiyyətində deyil."

Hansı məhsuldan bəhs etdiyimizi hələ təxmin etməmisinizsə, onda bütün bu təcrübə Postgres Pro Enterprise verilənlər bazasının bir il ərzində fəaliyyəti nəticəsində əldə edilmişdir. Özünüz nəticə çıxara bilərsiniz, o qədər nəmdir ki, göbələklər böyüyür.

Amma bu, vaxtında görülsə və yaranan problemləri operativ şəkildə aradan qaldırsaydı, o qədər də pis olmazdı.

Ancaq bu baş vermir. Görünür, istehsalçının müəyyən edilmiş səhvləri dərhal aradan qaldırmaq üçün kifayət qədər resursları yoxdur.

Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. Daxil olunxahiş edirəm.

Xarici/mülkiyyət DBMS-dən pulsuz/yerli verilənlər bazasına 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, lakin heç nə dəyişmədi2

• 42,6%Nəticələrə baxın20

47 istifadəçi səs verib. 12 istifadəçi bitərəf qalıb.

Mənbə: www.habr.com