"Pro, apan dili usa ka cluster" o kung giunsa namo pag-ilis ang imported nga DBMS

"Pro, apan dili usa ka cluster" o kung giunsa namo pag-ilis ang imported nga DBMS
(ts) Yandex.Mga Hulagway

Ang tanan nga mga karakter dili tinumotumo, ang mga marka sa pamatigayon iya sa ilang mga tag-iya, ang bisan unsang pagkaparehas random ug sa kinatibuk-an, kini ang akong "subjective value judgement, palihug ayaw gub-a ang pultahan ...".

Kami adunay daghang kasinatian sa pagbalhin sa mga sistema sa impormasyon nga adunay lohika sa usa ka database gikan sa usa ka DBMS ngadto sa lain. Sa konteksto sa dekreto sa gobyerno No. 1236 sa Nobyembre 16.11.2016, XNUMX, kini kasagaran usa ka pagbalhin gikan sa Oracle ngadto sa Postgresql. Mahimo namon isulti kanimo nga gilain kung giunsa ang pag-organisar sa proseso nga episyente ug wala’y sakit kutob sa mahimo; karon maghisgot kami bahin sa mga bahin sa paggamit sa usa ka kumpol ug kung unsang mga problema ang mahimong masugatan kung magtukod mga labi ka puno nga gipang-apod-apod nga mga sistema nga adunay komplikado nga lohika sa mga pamaagi ug mga gimbuhaton.

Spoiler - oo, cap, RAC ug pg multimaster lahi kaayo nga mga solusyon.

Ingnon ta nga nabalhin na nimo ang tanang logic gikan sa plsql ngadto sa pgsql. Ug ang imong mga pagsulay sa pagbalik OK ra, karon siyempre naghunahuna ka bahin sa pag-scale, tungod kay ... Ang mga pagsulay sa pagkarga dili makapalipay kanimo, labi na sa hardware nga orihinal nga gilakip sa proyekto, alang sa lahi kaayo nga DBMS. Ingnon ta nga nakit-an nimo ang usa ka solusyon gikan sa domestic vendor nga "Postgres Professional" nga adunay kapilian nga gitawag nga "multimaster", nga magamit ra sa "maximum" nga bersyon sa "Postgres Pro Enterprise" ug sumala sa paghulagway - parehas kini sa kung unsa kinahanglan nimo, ug uban sa unang taphaw nga pagtuon moabut ang hunahuna nga misulod sa akong ulo: β€œOh! Mao na imbes nga RAC! Ug bisan sa usa ka teknikal nga pipeline sa among yutang natawhan!

Apan ayaw pagdalidali sa pagmaya, ug dugang nga among ihulagway kung nganong kinahanglan nimo nga mahibal-an kini nga mga nuances, tungod kay... lisud sila matagna, bisan human sa hingpit nga pagbasa sa dokumentasyon sa produkto. Pagtimbang-timbang kung andam ka ba nga kanunay nga mag-update sa mga bersyon sa DBMS direkta sa site sa produksiyon, tungod kay Ang ubang mga depekto dili uyon sa industriyal nga paggamit ug lisud nga makit-an sa panahon sa pagsulay.
Pagsugod pinaagi sa mabinantayon nga pagbasa sa seksyon nga "multimaster" - "limitasyon" sa website sa tiggama.

Ang una nga butang nga mahimo nimong masugatan mao ang mga peculiarities kung giunsa ang mga transaksyon molihok, sa gitawag nga. "two-phase" mode, ug usahay walay paagi sa pag-ayo niini gawas sa pagsulat pag-usab sa tibuok nga lohika sa imong pamaagi. Ania ang usa ka yano nga pananglitan:

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;

Usa ka sayup ang mahitabo:

ΠžΠ¨Π˜Π‘ΠšΠ:  [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.

Dayon mahimo ka nga makig-away sa dugay nga panahon nga adunay patay nga lock sa mga bersyon 10.5, 10.6, ug ang bugtong nahibal-an nga solusyon nga makapatay sa tibuok nga esensya sa cluster mao ang pagtangtang sa "problema" nga mga lamesa gikan sa cluster, i.e. pagbuhat sa paghimo_table_local, apan kini sa labing menos tugotan kini sa pagtrabaho, ug dili ibutang ang tanan sa pagpugong tungod sa nagbitay nga paghulat alang sa transaksyon commits. Aw, o i-install ang usa ka update sa bersyon 11.2, nga makatabang, apan tingali dili, ayaw kalimti ang pagsusi.

Sa pipila ka mga bersyon mahimo nimong makuha ang labi ka misteryosong kandado:

username= mtm ΠΈ backend_type = background worker

Ug sa kini nga sitwasyon, ang pag-update lamang sa bersyon sa DBMS sa 11.2 ug mas taas makatabang kanimo, o tingali dili kini makatabang.

Ang ubang mga operasyon nga adunay mga indeks mahimong mosangpot sa mga sayup, nga tin-aw nga nagpakita nga ang problema anaa sa Bi-Directional Replication; direkta nimong makita ang BDR sa MTM logs. 2ndQuadrant ba gyud? Dili... mipalit mi ug multimaster, sulagma lang, ngalan sa teknolohiya.

[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 

Kung naggamit ka temporaryo nga mga lamesa, bisan pa sa mga kasiguruhan: "Ang multimaster extension naghimo sa data replication sa usa ka hingpit nga awtomatiko nga paagi. Mahimo nimong dungan nga maghimo mga transaksyon sa pagsulat ug magtrabaho kauban ang mga temporaryo nga lamesa sa bisan unsang node sa cluster.

Unya sa pagkatinuod imong makuha nga ang pagkopya dili molihok sa tanan nga mga lamesa nga gigamit sa pamaagi, kung ang code naglangkob sa paghimo sa usa ka temporaryo nga lamesa, ug bisan ang paggamit sa multimaster.remote_functions dili makatabang, kinahanglan nimo nga i-update o isulat pag-usab ang imong lohika sa ang pamaagi. Kung kinahanglan nimo nga gamiton ang duha nga mga extension nga multimaster ug pg_pathman nga dungan sa sulod sa Postgres Pro Enterprise v 10.5, unya susiha kini sa yano nga pananglitan:

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

Ang mosunod nga mga sayop nagsugod sa pagpakita sa mga log sa DBMS nodes:

…
 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

Mahimo nimong mahibal-an kung unsa kini nga mga sayup sa teknikal nga suporta, dili kawang nga imong gipalit kini.

Unsay buhaton? Husto! Pag-upgrade sa "Postgres Pro Enterprise" v 11.2

Sa linain, kinahanglan nimong mahibal-an nga ang pagkasunod-sunod, nga usa ka butang sa usa ka gisubli nga database, wala’y katapusan nga kantidad sa tibuuk nga kumpol, ang matag han-ay lokal alang sa matag node ug kung ikaw adunay mga natad nga adunay talagsaon nga mga pagdili ug paggamit sa han-ay, unya makahimo ka lamang sa pagdugang nga katumbas sa numero sa node sa cluster, tungod kay Ingon sa daghang mga node sa cluster kutob sa mahimo, ang sequence ug int motubo nga mas paspas kaysa sa imong gilauman. Aron mapasayon ​​ang pagtrabaho uban ang pagkasunodsunod sa produkto makit-an nimo ang alter_sequences function, nga maghimo sa gikinahanglan nga mga pag-uswag alang sa matag han-ay sa tanan nga mga node, apan pag-andam nga ang function dili molihok sa tanan nga mga bersyon. Siyempre, mahimo nimong isulat kini sa imong kaugalingon, gamit ang code gikan sa github isip basehan o pagtul-id kini sa imong kaugalingon direkta sa DBMS. Sa kini nga kaso, ang mga uma nga adunay serialbigserial nga tipo molihok nga mas husto, apan aron magamit kini, lagmit kinahanglan nimo nga isulat pag-usab ang code sa imong mga pamaagi ug mga gimbuhaton. Tingali adunay makakita sa monotonic_sequences function nga mapuslanon.

Sa wala pa ang bersyon 11.2 sa Postgres Pro Enterprise, ang pagkopya molihok lamang kung adunay mga talagsaon nga panguna nga yawe, tagda kini kung nag-uswag.

Gilain, gusto nakong hisgutan ang mga peculiarities kung giunsa ang npgsql nagtrabaho sa usa ka cluster solution; kini nga mga problema dili motungha sa usa ka node, apan naa sa usa ka multimaster.
Sa pipila ka mga bersyon mahimo kang makasugat og sayop:

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. 

Unsa may mahimo? Kinahanglan lang nga dili nimo gamiton ang pipila ka mga bersyon. Kinahanglan nimong mailhan sila, tungod kay... Ang sayup makita sa labaw sa usa ka bersyon, ug bisan human sa una nga pag-ayo niini, mahimo nimong masugatan kini sa ulahi. Kinahanglan ka usab nga mangandam alang niini ug mas maayo nga tabunan ang tanan nga giila nga mga depekto sa DBMS nga gitul-id sa tiggama nga adunay lahi nga mga pagsulay sa pagbag-o. Busa sa pagsulti, pagsalig, apan pamatud-i.

Kung ang aplikasyon naggamit sa npgsql ug nagbalhin-balhin tali sa mga node nga naghunahuna nga parehas silang tanan, mahimo ka nga makakuha usa ka sayup:

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

Kini nga sayup mahitabo tungod kay ang pagbugkos nagpadayon

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

composite nga mga tipo sa pagsugod sa aplikasyon para sa tanang koneksyon. Ingon usa ka sangputanan, nakakuha kami usa ka identifier gikan sa usa ka node, ug kung naghangyo sa lain nga node, dili kini magkatugma, ingon usa ka sangputanan diin ang usa ka sayup gibalik, i.e. Ang pagtrabaho nga transparent sa mga composite type sa usa ka cluster dili mahimo alang sa pipila ka mga aplikasyon nga walay dugang nga application-side rewrites (kung mahimo nimo kini).

Sama sa nahibal-an namong tanan, ang usa ka kinatibuk-ang pagtasa sa kahimtang sa cluster hinungdanon kaayo alang sa mga diagnostic ug mga lakang sa operasyon sa panahon sa operasyon, sa produkto makit-an nimo ang pipila nga mga gimbuhaton nga kinahanglan maghimo sa imong kinabuhi nga labi kadali, apan usahay makahatag sila usa ka butang nga hingpit nga lahi sa kung unsa ikaw ug bisan ang tiggama mismo nagpaabot gikan kanila nga imong gipaabot.

Pananglitan:

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

Apan ngano nga ang uma sa LiveNodes naglangkob sa numero 2 bisan diin, bisan kung sumala sa paghulagway sa operasyon sa multimaster kinahanglan kini nga katumbas sa numero nga AllNodes = 3? Tubag: kinahanglan nimo nga i-update ang bersyon sa DBMS.

Ug pag-andam sa pagkolekta sa mga troso alang sa tanan nga mga node, tungod kay ... kasagaran imong makita "ang sayup naa sa log sa laing node." Ang teknikal nga suporta modawat sa tanan nga mga depekto nga imong nahibal-an ug ipahibalo kanimo nga ang sunod nga bersyon andam na, nga usahay kinahanglan nga i-install uban ang serbisyo nga gihunong, usahay sa dugay nga panahon (depende sa gidak-on sa imong DBMS). Dili ka angay nga maglaum nga ang mga problema sa operasyon makasamok pag-ayo sa vendor, ug ang pag-update tungod sa giila nga mga depekto himuon uban ang pag-apil sa mga representante sa vendor, o labi pa, dili nimo kinahanglan nga iapil ang mga representante sa vendor, tungod kay sa katapusan mahimo ka nga adunay usa ka nabungkag nga cluster sa produksyon nga walay backup.

Sa tinuud, sa lisensya alang sa usa ka komersyal nga produkto, ang tiggama matinud-anon nga nagpasidaan: "Kini nga software gihatag sa "as is" nga basehan ug ang Postgres Professional Limited Liability Company dili obligado sa paghatag og pagmentinar, suporta, mga update, mga extension o mga pagbag-o."

Kung wala ka pa makatag-an kung unsang produkto ang among gihisgutan, nan ang tanan nga kini nga kasinatian nakuha ingon usa ka sangputanan sa usa ka tuig nga operasyon sa database sa Postgres Pro Enterprise. Makahimo ka sa imong kaugalingon nga konklusyon, kini basa kaayo nga ang mga uhong motubo.

Apan dili kini daotan kung buhaton kini sa tukma nga panahon ug mawagtang dayon ang mga nag-uswag nga mga problema.

Apan kini mao gayud ang dili mahitabo. Dayag nga ang tiggama wala’y igong mga kapanguhaan aron mapapas dayon ang nahibal-an nga mga bug.

Ang mga rehistradong tiggamit lamang ang makaapil sa survey. Sign in, walay sapayan.

Aduna ka bay kasinatian sa pagbalhin gikan sa usa ka langyaw/proprietary nga DBMS ngadto sa usa ka libre/domestic?

  • 21,3%Oo, positibo 10

  • 10,6%Oo, negatibo 5

  • 21,3%Dili, ang DBMS wala giusab10

  • 4,3%Nausab ang DBMS, pero walay nausab2

  • 42,6%Tan-awa ang mga resulta20

47 ka tiggamit ang nagboto. 12 ka tiggamit ang nag-abstain.

Source: www.habr.com

Idugang sa usa ka comment