"Pro, nanging ora kluster" utawa carane ngganti DBMS sing diimpor

(ts) Yandex.Images

Kabeh karakter iku fiktif, merek dagang kagungane sing nduweni, sembarang podho acak lan ing umum, iki sandi "nilai subyektif pertimbangan, please ora break lawang ...".

Kita duwe pengalaman sing cukup kanggo nransfer sistem informasi kanthi logika menyang database saka siji DBMS menyang liyane. Ing konteks SK pemerintah No.. 1236 tanggal 16.11.2016 November XNUMX, iki asring transfer saka Oracle kanggo Postgresql. Kita bisa ngomong kanthi kapisah carane ngatur proses kanthi efisien lan tanpa rasa lara, dina iki kita bakal ngomong babagan fitur nggunakake kluster lan masalah apa sing bisa ditemoni nalika mbangun sistem distribusi sing dimuat kanthi logika rumit ing prosedur lan fungsi.

Spoiler - ya, tutup, RAC lan pg multimaster minangka solusi sing beda banget.

Contone, sampeyan wis nransfer kabeh logika saka plsql menyang pgsql. Lan tes regresi sampeyan cukup OK, saiki sampeyan mikir babagan skala, amarga ... tes mbukak ora nggawe sampeyan seneng banget, utamané ing hardware sing Originally klebu ing project, kanggo DBMS sing beda banget. Contone, sampeyan nemokake solusi saka vendor domestik "Postgres Professional" kanthi pilihan sing disebut "multimaster", sing mung kasedhiya ing versi "maksimum" saka "Postgres Pro Enterprise" lan miturut katrangan - meh padha karo apa. sampeyan kudu, lan karo sinau entheng pisanan bakal teka pikirane teka ing sirah: "Oh! Iku tinimbang RAC! Lan sanajan karo pipa teknis ing tanah air kita!

Nanging aja cepet-cepet bungah, lan kita bakal nerangake kenapa sampeyan kudu ngerti nuansa kasebut, amarga ... lagi angel kanggo prédhiksi, malah sawise sak tenane maca dokumentasi produk. Netepake manawa sampeyan wis siyap kerep nganyari versi DBMS langsung ing situs produksi, amarga Sawetara cacat ora cocog karo panggunaan industri lan angel dideteksi sajrone tes.
Miwiti kanthi maca kanthi teliti bagean "multimaster" - "watesan" ing situs web pabrikan.

Wangsulan: Bab ingkang pisanan sampeyan bisa nemokke iku peculiarities carane transaksi bisa, ing supaya disebut-. Mode "loro-fase", lan kadhangkala ora ana cara kanggo ndandani iki kajaba kanthi nulis ulang kabeh logika prosedur sampeyan. Punika conto prasaja:

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;

Ana kesalahan:

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

Banjur sampeyan bisa perang kanggo dangu karo mati kunci ing versi 10.5, 10.6, lan mung solusi dikenal sing matèni kabèh inti saka kluster kanggo mbusak "masalah" tabel saka kluster, i.e. apa make_table_local, nanging iki bakal paling ngidini kanggo bisa, lan ora bakal sijine kabeh ditahan amarga nggandhol ngenteni transaksi commits. Inggih, utawa nginstal nganyari kanggo versi 11.2, kang kudu bantuan, nanging bisa uga ora, aja lali kanggo mriksa.

Ing sawetara versi, sampeyan bisa entuk kunci sing luwih misterius:

username= mtm и backend_type = background worker

Lan ing kahanan iki, mung nganyari versi DBMS menyang 11.2 lan luwih dhuwur bakal mbantu, utawa bisa uga ora bakal mbantu.

Sawetara operasi kanthi indeks bisa nyebabake kesalahan, sing jelas nuduhake yen masalah kasebut ana ing Replikasi Bi-Directional; sampeyan bakal langsung ndeleng BDR ing log MTM. Apa tenan 2ndQuadrant? Ora ... kita tuku multimaster, iku mung kebetulan, iku jeneng teknologi.

[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 

Yen sampeyan nggunakake tabel sementara, sanajan jaminan: "Ekstensi multimaster nindakake replikasi data kanthi otomatis. Sampeyan bisa nindakake transaksi nulis lan nggarap tabel sementara ing sembarang simpul ing kluster.

Banjur nyatane sampeyan bakal entuk replikasi sing ora bisa digunakake ing kabeh tabel sing digunakake ing prosedur kasebut, yen kode kasebut ngemot nggawe tabel sementara, lan malah nggunakake multimaster.remote_functions ora bakal mbantu, sampeyan kudu nganyari utawa nulis maneh logika sampeyan. tata cara. Yen sampeyan kudu nggunakake rong ekstensi multimaster lan pg_pathman bebarengan ing Postgres Pro Enterprise v 10.5, banjur priksa nganggo conto prasaja iki:

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

Kesalahan ing ngisor iki wiwit katon ing log ing simpul 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

Sampeyan bisa ngerteni apa kesalahan kasebut ing dhukungan teknis, ora muspra yen sampeyan tuku.

Apa sing kudu ditindakake? Bener! Nganyarke menyang "Postgres Pro Enterprise" v 11.2

Dhewe, sampeyan kudu ngerti yen urutan, minangka obyek saka database replikasi, ora duwe nilai end-to-end ing saindhenging kluster, saben urutan lokal kanggo saben simpul lan yen sampeyan duwe lapangan karo watesan unik lan nggunakake urutan, banjur sampeyan mung bisa nggawe tambahan padha karo nomer simpul ing cluster, amarga Sakehe simpul ing kluster, urutan lan int bakal tuwuh luwih cepet tinimbang sing dikarepake. Kanggo menakake karya karo urutan ing produk sampeyan malah bakal nemokake fungsi alter_sequences, kang bakal nggawe tambahan perlu kanggo saben urutan ing kabeh kelenjar, nanging disiapake sing fungsi ora bisa digunakake ing kabeh versi. Mesthi, sampeyan bisa nulis dhewe, nggunakake kode saka github minangka basis utawa mbenerake dhewe langsung ing DBMS. Ing kasus iki, kothak karo jinis serialbigserial bakal bisa luwih bener, nanging kanggo nggunakake, paling kamungkinan sampeyan kudu nulis ulang kode saka prosedur lan fungsi. Mbok menawa ana sing bakal nemokake fungsi monotonic_sequences migunani.

Sadurunge versi 11.2 saka Postgres Pro Enterprise, replikasi mung bakal bisa digunakake yen ana kunci utami sing unik, njupuk iki nalika ngembangaken.

Dhewe, aku pengin sebutno keanehan carane npgsql bisa digunakake ing solusi kluster; masalah iki ora muncul ing siji simpul, nanging cukup ana ing multimaster.
Ing sawetara versi sampeyan bisa nemoni kesalahan:

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. 

Apa sing bisa ditindakake? Sampeyan mung kudu ora nggunakake sawetara versi. Sampeyan kudu ngerti dheweke, amarga ... Kesalahan katon ing luwih saka siji versi, lan malah sawise ndandani pisanan, sampeyan bisa nemoni mengko. Sampeyan uga kudu siyap kanggo iki lan luwih apik kanggo nutupi kabeh cacat DBMS sing diidentifikasi sing didandani dening pabrikan kanthi tes regresi sing kapisah. Dadi ngomong, dipercaya, nanging verifikasi.

Yen aplikasi nggunakake npgsql lan ngalih ing antarane simpul mikir yen kabeh padha, sampeyan bisa uga ngalami kesalahan:

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

Kesalahan iki bakal kedadeyan amarga ikatan lagi ditindakake

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

jinis komposit ing wiwitan aplikasi kanggo kabeh sambungan. Akibaté, kita njaluk pengenal saka siji simpul, lan nalika njaluk ing simpul liyane, iku ora cocog, minangka asil saka kesalahan bali, i.e. Makarya kanthi transparan karo jinis komposit ing kluster ora bisa ditindakake kanggo sawetara aplikasi tanpa nulis ulang sisih aplikasi tambahan (yen sampeyan bisa nindakake).

Kita kabeh ngerti, taksiran sakabèhé saka negara kluster penting banget kanggo diagnostik lan ngukur operasional sak operasi, ing produk sampeyan bisa nemokake sawetara fungsi sing kudu nggawe urip luwih gampang, nanging kadhangkala padha bisa menehi soko temen beda saka apa. sampeyan lan malah pabrikan dhewe nyana saka wong-wong mau sing dikarepake.

Contone:

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

Nanging kenapa lapangan LiveNodes ngemot nomer 2 ing endi wae, sanajan miturut deskripsi operasi multimaster kudu cocog karo nomer AllNodes = 3? Jawaban: sampeyan kudu nganyari versi DBMS.

Lan siyap ngumpulake log kanggo kabeh simpul, amarga ... biasane sampeyan bakal weruh "kesalahan ana ing log simpul liyane." Dhukungan teknis bakal nampa kabeh cacat sing sampeyan kenal lan ngandhani yen versi sabanjure wis siyap, sing kadhangkala kudu diinstal kanthi layanan mandheg, kadhangkala nganti suwe (gumantung saka ukuran DBMS sampeyan). Sampeyan ora kudu ngarep-arep sing masalah operasional bakal nemen disturb vendor, lan nganyari amarga cacat dikenali bakal digawa metu karo partisipasi saka wakil vendor, utawa rodo, sampeyan ora perlu kanggo melu wakil vendor, wiwit ing pungkasan sampeyan bisa mungkasi munggah karo kluster disassembled ing produksi tanpa serep.

Bener, ing lisensi kanggo produk komersial, pabrikan kanthi jujur ​​ngelingake: "Perangkat lunak iki diwenehake kanthi basis" kaya apa wae lan Perusahaan Tanggung Jawab Terbatas Profesional Postgres ora wajib menehi pangopènan, dhukungan, nganyari, ekstensi utawa owah-owahan.

Yen sampeyan durung ngira produk apa sing diomongake, mula kabeh pengalaman iki dipikolehi minangka asil saka operasi database Postgres Pro Enterprise sajrone setaun. Sampeyan bisa nggawe kesimpulan dhewe, lembab banget nganti jamur tuwuh.

Nanging iki ora bakal dadi ala yen rampung ing wektu sing tepat lan kanthi cepet ngilangi masalah sing muncul.

Nanging iki sabenere apa ora kelakon. Ketoke pabrikan ora duwe sumber daya sing cukup kanggo ngilangi bug sing wis dingerteni.

Mung pangguna pangguna sing bisa melu survey. mlebunggih.

Apa sampeyan duwe pengalaman ngoper saka DBMS manca / kepemilikan menyang gratis / domestik?

• 21,3%Ya, positif10

• 10,6%Ya, negatif5

• 21,3%Ora, DBMS ora diganti10

• 4,3%DBMS wis diganti, nanging ora ana sing diganti2

• 42,6%Ndeleng asil20

47 pangguna milih. 12 kedhaftar abstained.

Source: www.habr.com