ProHoster > Blogs > Administrācija > ā€œPro, bet ne klasterisā€ jeb kā mēs nomainÄ«jām importēto DBVS

ā€œPro, bet ne klasterisā€ jeb kā mēs nomainÄ«jām importēto DBVS

ā€œPro, bet ne klasterisā€ jeb kā mēs nomainÄ«jām importēto DBVS
(ts) Yandex.Images

Visi varoņi ir fiktÄ«vi, preču zÄ«mes pieder to Ä«paÅ”niekiem, jebkādas lÄ«dzÄ«bas ir nejauÅ”as un vispār tāds ir mans ā€œsubjektÄ«vais vērtÄ«bu spriedums, lÅ«dzu nelauzt durvis...ā€.

Mums ir ievērojama pieredze informācijas sistēmu ar loÄ£iku pārsÅ«tÄ«Å”anā datu bāzē no vienas DBVS uz citu. SaistÄ«bā ar valdÄ«bas 1236. gada 16.11.2016. novembra dekrētu Nr. XNUMX tā bieži vien ir pāreja no Oracle uz Postgresql. AtseviŔķi varam pastāstÄ«t, kā procesu organizēt pēc iespējas efektÄ«vāk un nesāpÄ«gāk, Å”odien parunāsim par klastera izmantoÅ”anas iespējām un ar kādām problēmām var saskarties, veidojot ļoti noslogotas dalÄ«tās sistēmas ar sarežģītu loÄ£iku procedÅ«rās un funkcijās.

Spoileris ā€“ jā, cap, RAC un pg multimaster ir ļoti dažādi risinājumi.

Pieņemsim, ka jÅ«s jau esat pārnesis visu loÄ£iku no plsql uz pgsql. Un jÅ«su regresijas testi ir diezgan labi, tagad jÅ«s, protams, domājat par mērogoÅ”anu, jo... slodzes testi jÅ«s neiepriecina, jo Ä«paÅ”i attiecÄ«bā uz aparatÅ«ru, kas sākotnēji bija iekļauta projektā, Å”ai ļoti atŔķirÄ«gajai DBVS. Pieņemsim, ka esat atradis vietējā pārdevēja "Postgres Professional" risinājumu ar opciju "multimaster", kas ir pieejama tikai "Postgres Pro Enterprise" "maksimālajā" versijā un saskaņā ar aprakstu ir ļoti lÄ«dzÄ«ga tev vajag, un ar pirmo virspusējo izpēti man ienāca prātā doma: ā€œAk! Tas ir tas, nevis RAC! Un pat ar tehnisko cauruļvadu mÅ«su dzimtenē!ā€

Bet nesteidzieties priecāties, un tālāk mēs aprakstÄ«sim, kāpēc jums ir jāzina Ŕīs nianses, jo... tos ir grÅ«ti paredzēt pat pēc rÅ«pÄ«gas produkta dokumentācijas izlasÄ«Å”anas. Novērtējiet, vai esat gatavs bieži atjaunināt DBVS versijas tieÅ”i ražoÅ”anas vietā, jo Daži defekti nav saderÄ«gi ar rÅ«pniecisku izmantoÅ”anu, un tos ir grÅ«ti noteikt testÄ“Å”anas laikā.
Sāciet, rÅ«pÄ«gi izlasiet sadaļu ā€œmultimasterā€ - ā€œierobežojumiā€ ražotāja vietnē.

Pirmā lieta, ar ko jÅ«s varētu saskarties, ir darÄ«jumu darbÄ«bas Ä«patnÄ«bas, t.s. ā€œdivfāžuā€ režīms, un dažreiz to nevar novērst, izņemot visas procedÅ«ras loÄ£ikas pārrakstÄ«Å”anu. Å eit ir vienkārÅ”s piemērs:

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;

Rodas kļūda:

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

Tad vēl ilgi var cÄ«nÄ«ties ar dead lock versijās 10.5, 10.6 un vienÄ«gais zināmais risinājums, kas nogalina visu klastera bÅ«tÄ«bu ir ā€œproblēmuā€ tabulu noņemÅ”ana no klastera, t.i. veiciet make_table_local, bet tas vismaz ļaus tai darboties un neatliks visu aizturētu, jo tiek gaidÄ«ta transakcijas apņemÅ”anās. Vai arÄ« instalējiet atjauninājumu versijai 11.2, kam vajadzētu palÄ«dzēt, bet varbÅ«t ne, neaizmirstiet pārbaudÄ«t.

Dažās versijās jūs varat iegūt vēl noslēpumainu slēdzeni:

username= mtm Šø backend_type = background worker

Un Å”ajā situācijā jums palÄ«dzēs tikai DBVS versijas atjaunināŔana uz 11.2 un jaunāku versiju, vai varbÅ«t tas nepalÄ«dzēs.

Dažas darbÄ«bas ar indeksiem var izraisÄ«t kļūdas, kas skaidri norāda, ka problēma ir divvirzienu replikācijā; jÅ«s tieÅ”i redzēsit BDR MTM žurnālos. Vai tas tieŔām ir 2.kvadrants? Nē... mēs nopirkām multimasteri, tā ir tikai sakritÄ«ba, tas ir tehnoloÄ£ijas nosaukums.

[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

Ja izmantojat pagaidu tabulas, neskatoties uz garantijām: ā€œMultimaster paplaÅ”inājums veic datu replikāciju pilnÄ«gi automātiski. Varat vienlaikus veikt rakstÄ«Å”anas transakcijas un strādāt ar pagaidu tabulām jebkurā klastera mezglā.

Tad faktiski jÅ«s redzēsit, ka replikācija nedarbojas visās procedÅ«rā izmantotajās tabulās, ja kods satur pagaidu tabulas izveidi un pat multimaster.remote_functions izmantoÅ”ana nepalÄ«dzēs, jums bÅ«s jāatjaunina vai jāpārraksta sava loÄ£ika procedÅ«ru. Ja ā€œPostgres Pro Enterpriseā€ v10.5 ietvaros vienlaikus ir jāizmanto divi paplaÅ”inājumi multimaster un pg_pathman, pārbaudiet to, izmantojot Å”o vienkārÅ”o piemēru:

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

DBVS mezglu žurnālos sāk parādīties Ŕādas kļūdas: 

ā€¦
 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

Kādas ir Ŕīs kļūdas, varat uzzināt tehniskajā atbalstā, ne velti to iegādājāties.

Ko darīt? Pa labi! Jauniniet uz "Postgres Pro Enterprise" v11.2

AtseviŔķi jums jāzina, ka secÄ«bai, kas ir replicētas datu bāzes objekts, visā klasterÄ« nav pilnÄ«gas vērtÄ«bas, katra secÄ«ba ir lokāla katram mezglam un, ja jums ir lauki ar unikāliem ierobežojumiem un lietoÅ”anas secÄ«ba, tad jÅ«s varat veikt tikai pieaugumu, kas lÄ«dzvērtÄ«gs mezgla numuram klasterÄ«, jo KlasterÄ« pēc iespējas vairāk mezglu, secÄ«ba un int pieaugs ātrāk, nekā gaidÄ«jāt. Lai vienkārÅ”otu darbu ar secÄ«bu produktā, jÅ«s pat atradÄ«siet funkciju alter_sequences, kas veiks nepiecieÅ”amos palielinājumus katrai secÄ«bai visos mezglos, taču esiet gatavi tam, ka funkcija nedarbosies visās versijās. Protams, jÅ«s varat to uzrakstÄ«t pats, par pamatu izmantojot kodu no github vai labojot to pats tieÅ”i DBVS. Å ajā gadÄ«jumā pareizāk darbosies lauki ar serialbigserial tipu, taču, lai tos izmantotu, visticamāk, bÅ«s jāpārraksta savu procedÅ«ru un funkciju kods. VarbÅ«t kādam noderēs funkcija monotonic_sequences.

Pirms Postgres Pro Enterprise versijas 11.2 replikācija darbosies tikai tad, ja ir unikālas primārās atslēgas, ņemiet to vērā, izstrādājot.

AtseviŔķi es vēlos pieminēt npgsql darbÄ«bas Ä«patnÄ«bas klastera risinājumā; Ŕīs problēmas nerodas vienā mezglā, bet ir diezgan izplatÄ«tas multimasterā.
Dažās versijās var rasties kļūda:

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.

Ko var darÄ«t? Jums vienkārÅ”i nav jāizmanto dažas versijas. Jums tie ir jāzina, jo... Kļūda parādās vairākās versijās, un pat pēc tās pirmās laboÅ”anas var rasties vēlāk. Tam arÄ« jābÅ«t gatavam un visus konstatētos DBVS defektus, ko ražotājs labo, labāk noklāt ar atseviŔķiem regresijas testiem. Tā teikt, uzticieties, bet pārbaudiet.

Ja lietojumprogramma izmanto npgsql un pārslēdzas starp mezgliem, domājot, ka tie visi ir vienādi, var parādīties kļūda:

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

Šī kļūda radīsies, jo notiek saistīŔana 

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

saliktie veidi lietojumprogrammas startÄ“Å”anas laikā visiem savienojumiem. Rezultātā no viena mezgla iegÅ«stam identifikatoru, un, pieprasot citā mezglā, tas nesakrÄ«t, kā rezultātā tiek atgriezta kļūda, t.i. Pārskatāms darbs ar saliktajiem tipiem klasterÄ« dažām lietojumprogrammām nebÅ«s iespējams bez papildu lietojumprogrammas puses pārrakstÄ«Å”anas (ja jums tas izdosies).

Kā mēs visi zinām, vispārējs klastera stāvokļa novērtējums ir ļoti svarīgs diagnostikai un ekspluatācijas pasākumiem ekspluatācijas laikā, produktā var atrast dažas funkcijas, kurām vajadzētu atvieglot jūsu dzīvi, bet dažreiz tās var dot kaut ko pavisam citu jūs un pat pats ražotājs no viņiem jūs gaidāt.

Piemēram:

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

Bet kāpēc laukā LiveNodes visur ir skaitlis 2, lai gan pēc multimastera darbības apraksta tam jāatbilst skaitlim AllNodes=3? Atbilde: jums ir jāatjaunina DBVS versija.

Un esiet gatavi vākt žurnālus par visiem mezgliem, jo... parasti jÅ«s redzēsit "kļūda ir cita mezgla žurnālā". Tehniskais atbalsts pieņems visus jÅ«su identificētos defektus un informēs, ka ir gatava nākamā versija, kas dažkārt bÅ«s jāinstalē, kad pakalpojums ir apturēts, dažreiz uz ilgu laiku (atkarÄ«bā no jÅ«su DBVS lieluma). Nevajag cerēt, ka darbÄ«bas problēmas pārdevējam stipri traucēs un atjaunināŔana konstatēto defektu dēļ tiks veikta ar pārdevēja pārstāvju piedalÄ«Å”anos, pareizāk sakot, pārdevēja pārstāvjus pat nav jāiesaista, jo beigās jÅ«s varat beigties ar izjauktu klasteru ražoÅ”anā bez rezerves.

Faktiski komerciāla produkta licencē ražotājs godÄ«gi brÄ«dina: "Å Ä« programmatÅ«ra tiek nodroÅ”ināta tāda, kāda tā ir, un Postgres Professional Company ar ierobežotu atbildÄ«bu nav pienākuma nodroÅ”ināt apkopi, atbalstu, atjauninājumus, paplaÅ”inājumus vai izmaiņas."

Ja vēl neesi uzminējis, par kuru produktu ir runa, tad visa Ŕī pieredze iegÅ«ta gadu ilgas Postgres Pro Enterprise datu bāzes darbÄ«bas rezultātā. Secinājumu varat izdarÄ«t pats, tas ir tik mitrs, ka aug sēnes.

Bet tas nebÅ«tu tik slikti, ja tas tiktu darÄ«ts savlaicÄ«gi un nekavējoties novērstu raduŔās problēmas.

Bet tas ir tieÅ”i tas, kas nenotiek. AcÄ«mredzot ražotājam nav pietiekami daudz resursu, lai nekavējoties novērstu identificētās kļūdas.

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai jums ir pieredze, pārejot no ārvalstu/patentētas DBVS uz bezmaksas/iekÅ”zemes?

  • 21,3%Jā, pozitÄ«vi10

  • 10,6%Jā, negatÄ«vs5

  • 21,3%Nē, DBVS netika mainÄ«ta10

  • 4,3%DBVS tika mainÄ«ta, bet nekas nemainÄ«jās2

  • 42,6%SkatÄ«t rezultātus20

Nobalsoja 47 lietotāji. 12 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru