«Pro, բայց ոչ կլաստեր» կամ ինչպես մենք փոխարինեցինք ներմուծված DBMS-ը

(ts) Yandex.Images

Բոլոր կերպարները հորինված են, ապրանքանիշերը պատկանում են իրենց սեփականատերերին, ցանկացած նմանություն զուտ պատահական է, և ընդհանուր առմամբ, սա իմ «սուբյեկտիվ արժեքային դատողությունն է, խնդրում եմ, դուռը մի՛ կոտրեք…»։

Մենք զգալի փորձ ունենք տվյալների բազայի տրամաբանությամբ տեղեկատվական համակարգերը մեկ տվյալների բազայից մյուսը փոխանցելու հարցում: 1236 թվականի նոյեմբերի 16.11.2016-ի թիվ XNUMX կառավարության որոշման համատեքստում սա հաճախ Oracle-ից Postgresql փոխանցում է: Մենք կարող ենք առանձին պատմել, թե ինչպես կազմակերպել գործընթացը հնարավորինս արդյունավետ և անցավ. այսօր մենք կպատմենք կլաստերի օգտագործման առանձնահատկությունների և այն խնդիրների մասին, որոնց կարող եք հանդիպել բարդ տրամաբանությամբ բարձր ծանրաբեռնվածությամբ բաշխված համակարգեր կառուցելիս՝ ընթացակարգերում և գործառույթներում:

Սփոյլեր - այո, cap-ը, RAC-ը և pg multimaster-ը շատ տարբեր լուծումներ են։

Ենթադրենք, որ դուք արդեն ամբողջ տրամաբանությունը plsql-ից տեղափոխել եք pgsql: Եվ ձեր ռեգրեսիոն թեստերը բավականին լավն են, հիմա դուք, իհարկե, մտածում եք մասշտաբավորման մասին, քանի որ բեռնվածության թեստերը ձեզ այդքան էլ չեն գոհացնում, հատկապես այն սարքավորումների վրա, որոնք սկզբնապես ներառված էին նախագծում, հենց այդ այլ DBMS-ի համար: Ենթադրենք, որ դուք գտել եք լուծում տեղական մատակարարից՝ «Postgres Professional»-ից, «multimaster» անվամբ տարբերակով, որը հասանելի է միայն «Postgres Pro Enterprise»-ի «maximum» տարբերակում, և նկարագրության համաձայն՝ այն շատ նման է ձեզ անհրաժեշտին, և առաջին մակերեսային ուսումնասիրության ժամանակ միտք կգա. «Օ՜հ: RAC-ի փոխարեն՝ այդքանը: Եվ նույնիսկ հայրենիքում տեխնիկական աջակցությամբ»:

Բայց մի շտապեք ուրախանալ, և հետագայում մենք կնկարագրենք, թե ինչու է անհրաժեշտ իմանալ այս նրբերանգները, քանի որ դրանք դժվար է կանխատեսել, նույնիսկ ապրանքի փաստաթղթերը լավ կարդալուց հետո: Գնահատեք, թե արդյոք պատրաստ կլինեք հաճախակի թարմացնել տվյալների բազայի կառավարման համակարգերի տարբերակները անմիջապես արտադրական վայրում, քանի որ որոշ թերություններ համատեղելի չեն արդյունաբերական շահագործման հետ և դժվար է հայտնաբերել փորձարկման ընթացքում:
Սկսեք արտադրողի կայքում ուշադիր կարդալով «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 կամ ավելի բարձր թարմացնելը կօգնի ձեզ, բայց կարող է և չօգնել։

Որոշ ինդեքսային գործողություններ կարող են հանգեցնել սխալների, որտեղ հստակ նշված է, որ խնդիրը երկկողմանի վերարտադրման մեջ է, MTM գրանցամատյաններում դուք անմիջապես կտեսնեք BDR-ը: Արդյո՞ք դա իսկապես 2ndQuadrant է: Ոչ... մենք գնել ենք multimaster, դա պարզապես պատահականություն է, դա տեխնոլոգիայի անունն է:

[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-ի օգտագործումը չի օգնի, ապա դուք ստիպված կլինեք թարմացնել կամ վերաշարադրել ձեր տրամաբանությունը ընթացակարգում: Եթե «Postgres Pro Enterprise» v 10.5-ի շրջանակներում անհրաժեշտ է միաժամանակ օգտագործել երկու ընդլայնում՝ multimaster և pg_pathman, ապա ստուգեք դա այսպիսի պարզ օրինակով.

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»-ին մինչև 11.2 տարբերակ։

Առանձին, դուք պետք է իմանաք, որ հաջորդականությունը, լինելով կրկնօրինակված տվյալների բազայի օբյեկտ, չունի խաչաձև արժեք ամբողջ կլաստերի համար, յուրաքանչյուր հաջորդականություն տեղական է յուրաքանչյուր հանգույցի համար, և եթե դուք ունեք եզակի սահմանափակումներով դաշտեր և օգտագործում եք հաջորդականություն, ապա կարող եք կատարել միայն կլաստերի հանգույցի համարին համարժեք աճ, քանի որ որքան շատ հանգույցներ լինեն կլաստերում, այնքան արագ կաճի ձեր հաջորդականությունը, և թե՛ հաջորդականությունը, թե՛ ամբողջ թիվը կսպառվեն ավելի արագ, քան դուք սպասում էիք: Հաջորդականության հետ աշխատանքը պարզեցնելու համար դուք նույնիսկ կգտնեք alter_sequences ֆունկցիան արտադրանքի մեջ, որը կկատարի անհրաժեշտ աճերը յուրաքանչյուր հաջորդականության համար բոլոր հանգույցների վրա, բայց պատրաստ եղեք, որ ֆունկցիան չի աշխատի բոլոր տարբերակներում: Իհարկե, դուք կարող եք այն գրել ինքներդ՝ որպես հիմք վերցնելով github-ի կոդը կամ ինքներդ այն ուղղելով անմիջապես տվյալների բազայի համակարգում: Այս դեպքում 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. 

Ի՞նչ կարելի է անել։ Պարզապես պետք է չօգտագործել որոշ տարբերակներ։ Դուք պետք է իմանաք դրանք, քանի որ սխալը հայտնվում է մեկից ավելի տարբերակներում, և նույնիսկ առաջին շտկումից հետո կարող եք հանդիպել դրան ավելի ուշ։ Դուք նաև պետք է պատրաստ լինեք դրան, և ավելի լավ է ծածկել բոլոր հայտնաբերված տվյալների բազայի կառավարման համակարգի թերությունները, որոնք արտադրողը շտկում է, առանձին ռեգրեսիոն թեստերով։ Այսպես ասած՝ վստահեք, բայց ստուգեք։

Եթե ​​ձեր ծրագիրը օգտագործում է 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 տվյալների բազայի մեկ տարվա օգտագործման արդյունքում։ Կարող եք ինքներդ եզրակացություն անել. այնտեղ այնքան խոնավ է, որ սունկ են աճում։

Բայց սա այդքան էլ վատ չէր լինի, եթե դա արվեր ժամանակին, և առաջացող խնդիրները արագ վերացվեին։

Բայց սա հենց այն է, ինչ տեղի չի ունենում։ Պարզվում է, որ արտադրողը բավարար ռեսուրսներ չունի հայտնաբերված սխալները արագ վերացնելու համար։

Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ Մուտք գործել, խնդրում եմ:

Դուք փորձ ունե՞ք օտարերկրյա/սեփականատիրական տվյալների շտեմարանից ազատ/տեղական տվյալների շտեմարանին անցնելու հարցում։

• 21,3%Այո, դրական 10

• 10,6%Այո, բացասական 5

• 21,3%Ոչ, տվյալների բազայի կառավարման համակարգը (DBMS) չի փոփոխվել10

• 4,3%Տվյալների բազայի կառավարման համակարգը փոխվեց, բայց ոչինչ չփոխվեց2

• 42,6%Դիտել արդյունքները 20

Քվեարկել է 47 օգտատեր։ 12 օգտատեր ձեռնպահ է մնացել։

Source: www.habr.com