(ts) Yandex.Mga Larawan
Ang lahat ng mga character ay kathang-isip lamang, ang mga trademark ay pag-aari ng kanilang mga may-ari, anumang pagkakatulad ay random at sa pangkalahatan, ito ang aking "subjective value judgment, mangyaring huwag sirain ang pinto...".
Mayroon kaming malaking karanasan sa paglilipat ng mga sistema ng impormasyon na may lohika sa isang database mula sa isang DBMS patungo sa isa pa. Sa konteksto ng utos ng pamahalaan No. 1236 ng Nobyembre 16.11.2016, XNUMX, ito ay madalas na paglilipat mula sa Oracle patungo sa Postgresql. Maaari naming sabihin sa iyo nang hiwalay kung paano ayusin ang proseso nang mahusay at walang sakit hangga't maaari ngayon ay pag-uusapan natin ang tungkol sa mga tampok ng paggamit ng isang kumpol at kung anong mga problema ang maaaring makaharap kapag nagtatayo ng mga napaka-load na ipinamamahagi na mga sistema na may kumplikadong lohika sa mga pamamaraan at pag-andar.
Spoiler – oo, magkaibang solusyon ang cap, RAC at pg multimaster.
Sabihin nating nailipat mo na ang lahat ng lohika mula plsql patungo sa pgsql. At ang iyong mga pagsusuri sa regression ay medyo OK, ngayon siyempre iniisip mo ang tungkol sa pag-scale, dahil... Ang mga pagsubok sa pag-load ay hindi nakakapagpasaya sa iyo, lalo na sa hardware na orihinal na kasama sa proyekto, para sa ibang DBMS na iyon. Sabihin nating nakakita ka ng solusyon mula sa domestic vendor na "Postgres Professional" na may opsyon na tinatawag na "multimaster", na magagamit lamang sa "maximum" na bersyon ng "Postgres Pro Enterprise" at ayon sa paglalarawan - ito ay halos kapareho sa kung ano kailangan mo, at sa unang mababaw na pag-aaral ay darating ang kaisipang pumasok sa aking isipan: “Oh! Iyon na lang sa halip na RAC! At kahit na may teknikal na pipeline sa ating tinubuang-bayan!"
Ngunit huwag magmadali upang magalak, at higit pa ay ilalarawan namin kung bakit kailangan mong malaman ang mga nuances na ito, dahil... mahirap hulaan ang mga ito, kahit na matapos mong basahin nang mabuti ang dokumentasyon ng produkto. Tayahin kung handa ka nang madalas na i-update ang mga bersyon ng DBMS nang direkta sa site ng produksyon, dahil Ang ilang mga depekto ay hindi tugma sa pang-industriya na paggamit at mahirap matukoy sa panahon ng pagsubok.
Magsimula sa pamamagitan ng maingat na pagbabasa sa seksyong "multimaster" - "mga limitasyon" sa website ng gumawa.
Ang unang bagay na maaari mong makaharap ay ang mga kakaibang paraan kung paano gumagana ang mga transaksyon, sa tinatawag na. "two-phase" mode, at kung minsan ay walang paraan upang ayusin ito maliban sa pamamagitan ng muling pagsusulat ng buong lohika ng iyong pamamaraan. Narito ang isang simpleng halimbawa:
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;May naganap na error:
ОШИБКА: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.Pagkatapos ay maaari kang lumaban nang mahabang panahon gamit ang patay na lock sa mga bersyon 10.5, 10.6, at ang tanging kilalang solusyon na pumapatay sa buong kakanyahan ng kumpol ay ang pag-alis ng mga talahanayan ng "problema" mula sa kumpol, i.e. gawin make_table_local, ngunit ito ay hindi bababa sa payagan ito upang gumana, at hindi ilagay ang lahat sa hold dahil sa hanging paghihintay para sa transaksyon commit. Well, o mag-install ng update sa bersyon 11.2, na dapat makatulong, ngunit maaaring hindi, huwag kalimutang suriin.
Sa ilang bersyon maaari kang makakuha ng mas mahiwagang lock:
username= mtm и backend_type = background workerAt sa sitwasyong ito, ang pag-update lamang ng bersyon ng DBMS sa 11.2 at mas mataas ay makakatulong sa iyo, o marahil ay hindi ito makakatulong.
Ang ilang mga operasyon na may mga index ay maaaring humantong sa mga error, na malinaw na nagpapahiwatig na ang problema ay nasa Bi-Directional Replication, direkta mong makikita ang BDR sa mga log ng MTM. 2ndQuadrant ba talaga? Hindi... bumili kami ng multimaster, nagkataon lang, pangalan ng 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 gumagamit ka ng mga pansamantalang talahanayan, sa kabila ng mga katiyakan: "Ang multimaster extension ay nagsasagawa ng pagtitiklop ng data sa ganap na awtomatikong paraan. Maaari kang sabay na magsagawa ng mga transaksyon sa pagsulat at magtrabaho kasama ang mga pansamantalang talahanayan sa anumang node sa cluster."
Pagkatapos sa katunayan ay makakakuha ka na ang pagtitiklop ay hindi gagana sa lahat ng mga talahanayan na ginamit sa pamamaraan, kung ang code ay naglalaman ng paglikha ng isang pansamantalang talahanayan, at kahit na ang paggamit ng multimaster.remote_functions ay hindi makakatulong, kailangan mong i-update o muling isulat ang iyong lohika sa ang pamamaraan. Kung kailangan mong gumamit ng dalawang extension na multimaster at pg_pathman nang sabay-sabay sa loob ng Postgres Pro Enterprise v 10.5, pagkatapos ay suriin iyon gamit ang simpleng halimbawang ito:
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 mga sumusunod na error ay nagsisimulang lumitaw sa mga log sa mga DBMS node:
…
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
Maaari mong malaman kung ano ang mga error na ito sa teknikal na suporta, hindi walang kabuluhan na binili mo ito.
Ano ang gagawin? Tama! Mag-upgrade sa "Postgres Pro Enterprise" v 11.2
Hiwalay, kailangan mong malaman na ang pagkakasunud-sunod, bilang isang object ng isang replicated database, ay walang end-to-end na halaga sa buong cluster, ang bawat sequence ay lokal para sa bawat node at kung mayroon kang mga field na may natatanging mga paghihigpit at paggamit ng sequence , pagkatapos ay maaari ka lamang gumawa ng isang pagtaas na katumbas ng numero ng node sa cluster, dahil Sa dami ng node sa cluster hangga't maaari, ang sequence ay lalago nang mas mabilis, at ang int ay mauubos nang mas mabilis kaysa sa iyong inaasahan. Upang pasimplehin ang pagtatrabaho sa pagkakasunud-sunod sa produkto ay makikita mo pa ang alter_sequences function, na gagawa ng mga kinakailangang increment para sa bawat sequence sa lahat ng node, ngunit maging handa na ang function ay hindi gagana sa lahat ng mga bersyon. Siyempre, maaari mo itong isulat sa iyong sarili, gamit ang code mula sa github bilang batayan o itama ito nang direkta sa DBMS. Sa kasong ito, ang mga patlang na may uri ng serialbigserial ay gagana nang mas tama, ngunit upang magamit ang mga ito, malamang na kakailanganin mong muling isulat ang code ng iyong mga pamamaraan at pag-andar. Marahil ay makikita ng isang tao na kapaki-pakinabang ang monotonic_sequences function.
Bago ang bersyon 11.2 ng Postgres Pro Enterprise, gagana lamang ang pagtitiklop kung mayroong mga natatanging pangunahing key, isaalang-alang ito kapag bumubuo.
Hiwalay, nais kong banggitin ang mga kakaibang paraan kung paano gumagana ang npgsql sa isang cluster solution ang mga problemang ito ay hindi lumabas sa isang node, ngunit medyo naroroon sa isang multimaster.
Sa ilang bersyon maaari kang makatagpo ng error:
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. Ano ang maaaring gawin? Kailangan mo lang hindi gumamit ng ilang bersyon. Kailangan mo silang kilalanin, dahil... Lumilitaw ang error sa higit sa isang bersyon, at kahit na matapos ang unang pag-aayos nito, maaari mo itong makaharap sa ibang pagkakataon. Kailangan mo ring maging handa para dito at mas mainam na sakupin ang lahat ng natukoy na mga depekto sa DBMS na itinatama ng tagagawa na may hiwalay na mga pagsubok sa pagbabalik. Kaya magsalita, magtiwala, ngunit i-verify.
Kung ang application ay gumagamit ng npgsql at nagpalipat-lipat sa pagitan ng mga node na iniisip na ang mga ito ay pareho, maaari kang makakuha ng isang error:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...Ang error na ito ay magaganap dahil ang pagbubuklod ay isinasagawa
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");) mga composite na uri sa pagsisimula ng application para sa lahat ng koneksyon. Bilang resulta, nakatanggap kami ng isang identifier mula sa isang node, at kapag humihiling sa isa pang node, hindi ito tumutugma, bilang isang resulta kung saan ang isang error ay ibinalik, i.e. Ang malinaw na pagtatrabaho sa mga composite na uri sa isang cluster ay hindi magiging posible para sa ilang mga application na walang karagdagang application-side rewrites (kung nagawa mong gawin ito).
Tulad ng alam nating lahat, ang isang pangkalahatang pagtatasa ng estado ng kumpol ay napakahalaga para sa mga diagnostic at mga hakbang sa pagpapatakbo sa panahon ng operasyon, sa produkto maaari kang makahanap ng ilang mga function na dapat gawing mas madali ang iyong buhay, ngunit kung minsan maaari silang magbigay ng isang bagay na ganap na naiiba mula sa kung ano ikaw at maging ang tagagawa mismo mula sa kanila na iyong inaasahan.
Halimbawa:
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")Ngunit bakit ang patlang ng LiveNodes ay naglalaman ng numero 2 sa lahat ng dako, bagama't ayon sa paglalarawan ng operasyon ng multimaster dapat itong tumutugma sa numerong AllNodes=3? Sagot: kailangan mong i-update ang bersyon ng DBMS.
At maging handa upang mangolekta ng mga log para sa lahat ng mga node, dahil... kadalasan makikita mo ang "ang error ay nasa log ng isa pang node." Tatanggapin ng teknikal na suporta ang lahat ng mga depekto na natukoy mo at ipaalam sa iyo na ang susunod na bersyon ay handa na, na kung minsan ay kailangang i-install nang huminto ang serbisyo, minsan sa mahabang panahon (depende sa laki ng iyong DBMS). Hindi ka dapat umasa na ang mga problema sa pagpapatakbo ay lubhang makaistorbo sa vendor, at ang pag-update dahil sa mga natukoy na mga depekto ay isasagawa kasama ng mga kinatawan ng vendor, o sa halip, hindi mo na kailangang isali ang mga kinatawan ng vendor, dahil sa sa dulo maaari kang magkaroon ng isang disassembled cluster sa produksyon nang walang backup.
Sa totoo lang, sa lisensya para sa isang komersyal na produkto, tapat na nagbabala ang tagagawa: "Ibinigay ang software na ito sa "as is" na batayan at ang Postgres Professional Limited Liability Company ay hindi obligado na magbigay ng pagpapanatili, suporta, mga update, mga extension o mga pagbabago."
Kung hindi mo pa nahulaan kung aling produkto ang pinag-uusapan natin, ang lahat ng karanasang ito ay nakuha bilang resulta ng isang taon na operasyon ng database ng Postgres Pro Enterprise. Maaari kang gumawa ng iyong sariling konklusyon, ito ay sobrang basa na tumutubo ang mga kabute.
Ngunit hindi ito magiging masama kung gagawin ito sa isang napapanahong paraan at agad na maalis ang mga umuusbong na problema.
Ngunit ito ay tiyak kung ano ang hindi mangyayari. Tila ang tagagawa ay walang sapat na mapagkukunan upang agad na maalis ang mga natukoy na bug.
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Mayroon ka bang karanasan sa paglipat mula sa isang dayuhan/pagmamay-ari na DBMS patungo sa isang libre/domestic?
21,3%Oo, positibo10
10,6%Oo, negatibo5
21,3%Hindi, ang DBMS ay hindi binago10
4,3%Ang DBMS ay binago, ngunit walang nagbago2
42,6%Tingnan ang mga resulta20
47 user ang bumoto. 12 na user ang umiwas.
Pinagmulan: www.habr.com
