(c) Gambar Yandex
Semua karakter adalah fiktif, merek dagang milik pemiliknya, setiap kebetulan adalah acak dan secara umum, ini adalah "penilaian nilai subyektif saya, tolong jangan mendobrak pintu ...".
Kami memiliki pengalaman yang cukup dalam menerjemahkan sistem informasi dengan logika dalam database dari satu DBMS ke yang lain. Dalam konteks keputusan pemerintah No. 1236 dari 11/16/2016, sering kali transfer dari Oracle ke Postgresql. Cara mengatur proses seefisien dan semudah mungkin - kami dapat memberi tahu Anda secara terpisah, hari ini kami akan berbicara tentang fitur menggunakan cluster dan masalah apa yang mungkin Anda temui saat membangun sistem terdistribusi dengan logika kompleks dalam prosedur dan fungsi.
Spoiler - yes cap, RAC dan pg multimaster adalah solusi yang sangat berbeda.
Misalkan Anda sudah mentransfer semua logika dari pl \ sql ke pg \ sql. Dan tes regresi Anda cukup baik, sekarang Anda tentu saja berpikir tentang penskalaan, karena tes beban tidak terlalu menyenangkan bagi Anda, terutama pada perangkat keras yang ditetapkan dalam proyek pada awalnya, di bawah DBMS yang sangat berbeda. Misalkan Anda menemukan solusi dari vendor domestik "Postgres Professional" dengan opsi yang disebut "multimaster", yang hanya tersedia dalam versi "maksimum" "Postgres Pro Enterprise" dan uraiannya sangat mirip dengan apa yang Anda butuhkan, dan ketika Anda pertama kali memeriksanya dalam benak saya pikiran: "Oh! Alih-alih RAC, kalau begitu! Ya, dan dengan saluran pipa teknis di tanah air! ”
Tapi jangan buru-buru bersukacita, dan lebih lanjut kami akan menjelaskan mengapa Anda perlu tahu nuansa ini, karena mereka sulit untuk dibayangkan bahkan setelah membaca dokumentasi produk dengan baik. Evaluasi apakah Anda akan siap untuk sering memperbarui versi DBMS langsung di situs industri, seperti beberapa cacat tidak kompatibel dengan operasi industri dan sulit dideteksi dalam pengujian.
Mulailah dengan membaca dengan seksama bagian “multimaster” - “pembatasan” di situs web pabrikan.
Hal pertama yang dapat Anda temui adalah fitur operasi transaksi, yang disebut Mode "dua fase", dan kadang-kadang, kecuali dengan menulis ulang seluruh logika prosedur Anda, ini tidak dapat diperbaiki. Ini adalah contoh sederhana:
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;
Terjadi kesalahan:
: [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.
Kemudian Anda bisa melawan kunci mati untuk waktu yang lama di versi 10.5, 10.6 dan satu-satunya keselamatan yang diketahui yang membunuh seluruh esensi cluster adalah untuk menghapus tabel "masalah" dari cluster, mis. lakukan make_table_local, tetapi setidaknya itu akan memungkinkan Anda untuk bekerja, dan tidak akan "mempertaruhkan" segalanya karena menggantungkan harapan melakukan transaksi. Baik, atau letakkan pembaruan ke versi 11.2, yang seharusnya membantu, atau mungkin tidak, jangan lupa untuk memeriksa.
Dalam beberapa versi, Anda bisa mendapatkan kunci yang lebih misterius:
username= mtm backend_type = background worker
Dan dalam situasi ini, hanya memperbarui versi DBMS ke 11.2 dan lebih tinggi akan membantu Anda, atau mungkin tidak membantu.
Beberapa operasi dengan indeks dapat menyebabkan kesalahan di mana ditunjukkan dengan jelas bahwa masalahnya ada dalam Replikasi Dua Arah, dalam log MTM Anda akan langsung melihat BDR. Benarkah 2ndQuadrant? Oh tidak ... kami membeli multimaster, itu hanya kebetulan, itu nama teknologinya.
[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
Jika Anda menggunakan tabel sementara, meskipun ada jaminan: “Ekstensi multimaster mereplikasi data dengan cara yang sepenuhnya otomatis. "Anda dapat secara bersamaan menulis transaksi dan bekerja dengan tabel sementara pada sembarang simpul dalam gugus."
Kemudian, pada kenyataannya, Anda akan mendapatkan bahwa replikasi tidak berfungsi untuk semua tabel yang digunakan dalam prosedur, jika kode berisi pembuatan tabel sementara, dan bahkan menggunakan multimaster.remote_functions tidak membantu, Anda harus memperbarui atau menulis ulang logika Anda dalam prosedur. Jika Anda perlu menggunakan dua ekstensi multimaster dan pg_pathman secara bersamaan sebagai bagian dari Postgres Pro Enterprise v 10.5, maka periksa dengan contoh sederhana ini:
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 berikut mulai menuangkan log pada node 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
Anda dapat mengetahui kesalahan apa yang ada dalam dukungan teknis, bukan karena Anda membelinya.
Apa yang harus dilakukan Benar! Tingkatkan ke Postgres Pro Enterprise ke v 11.2
Perlu diketahui secara terpisah bahwa, sebagai objek dari basis data yang direplikasi, itu tidak memiliki nilai lintas-lintas di seluruh kluster, setiap urutan bersifat lokal untuk setiap simpul dan jika Anda memiliki bidang dengan batasan unik dan menggunakan urutan, maka Anda hanya dapat menambah nomor simpul dalam cluster, karena berapa banyak node dalam cluster yang jauh lebih cepat sehingga urutan akan tumbuh, dan int akan berakhir lebih cepat dari yang Anda harapkan. Untuk menyederhanakan bekerja dengan urutan dalam produk, Anda bahkan akan menemukan fungsi alter_afterences, yang akan membuat kenaikan yang diperlukan untuk setiap sequnce pada semua node, tetapi bersiaplah bahwa fungsi tidak akan bekerja di semua versi. Tentu saja, Anda dapat menulisnya sendiri, mengambil kode dari github sebagai dasar atau mengoreksi diri Anda secara langsung dalam DBMS. Pada saat yang sama, bidang dengan tipe serial \ bigserial akan bekerja lebih benar, tetapi untuk menggunakannya, kemungkinan besar Anda perlu menulis ulang kode prosedur dan fungsi Anda. Mungkin seseorang akan menemukan fungsi monotonic_afterences bermanfaat.
Sebelum versi 11.2 dari Postgres Pro Enterprise, replikasi hanya akan berfungsi jika ada kunci primer unik, ingatlah ini saat mendesain.
Saya juga ingin menyebutkan fitur-fitur npgsql dalam solusi cluster, masalah ini tidak terjadi pada satu node, tetapi mereka cukup hadir di multimaster.
Dalam beberapa versi Anda mungkin mengalami 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 yang bisa dilakukan? Hanya saja, jangan menggunakan beberapa versi. Anda perlu mengenal mereka, karena kesalahan tidak muncul dalam satu versi, dan bahkan setelah koreksi pertama, Anda mungkin menjumpai nanti. Anda juga harus siap untuk ini dan yang terbaik adalah mengidentifikasi semua cacat DBMS yang diperbaiki oleh pabrikan dan menutupinya dengan tes regresi terpisah. Percayalah, begitulah, tapi verifikasi.
Jika aplikasi menggunakan npgsql dan beralih di antara node berpikir bahwa semuanya sama, maka Anda mungkin mendapatkan kesalahan:
EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...
Kesalahan seperti itu akan terjadi karena fakta yang mengikat
(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");)
tipe komposit saat startup aplikasi untuk semua koneksi. Akibatnya, kami mendapatkan pengidentifikasi dari salah satu node, dan ketika diminta pada node lain, itu tidak cocok, sebagai akibatnya kesalahan dikembalikan, yaitu. bekerja secara transparan dengan tipe komposit dalam sebuah cluster untuk beberapa aplikasi tidak akan mungkin tanpa penulisan ulang tambahan di sisi aplikasi (jika Anda berhasil melakukan ini).
Seperti yang kita semua tahu, penilaian umum tentang keadaan cluster sangat penting untuk diagnostik dan langkah-langkah operasional saat bekerja, dalam produk Anda dapat menemukan beberapa fungsi yang seharusnya membuat hidup Anda lebih mudah, tetapi kadang-kadang mereka mungkin tidak menghasilkan sama sekali apa yang Anda dan bahkan pabrikan sendiri dari mereka. harapkan.
Sebagai contoh:
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")
Tetapi mengapa angka 2 ada di mana-mana di bidang LiveNodes, meskipun menurut deskripsi pekerjaan multimaster, itu harus sesuai dengan angka AllNodes = 3? Jawab: Anda perlu memperbarui versi DBMS.
Dan bersiaplah untuk mengumpulkan log pada semua node, seperti biasanya Anda akan melihat "kesalahan ada di log node lain." TechSupport akan menerima semua cacat yang diidentifikasi dan memberi tahu Anda bahwa versi berikutnya siap, yang perlu diinstal kadang-kadang dengan layanan dihentikan, kadang-kadang untuk waktu yang lama (tergantung pada volume DBMS Anda). Tidak layak berharap bahwa masalah operasi akan sangat mengganggu vendor, dan pembaruan karena cacat yang diidentifikasi akan dilakukan dengan partisipasi perwakilan vendor, atau lebih tepatnya, bahkan tidak perlu melibatkan perwakilan vendor, karena pada akhirnya Anda bisa mendapatkan kluster yang dibongkar tanpa cadangan pada produk.
Sebenarnya, dalam lisensi untuk produk komersial, pabrikan dengan jujur memperingatkan: "Perangkat lunak ini disediakan atas dasar" sebagaimana adanya "dan perusahaan tanggung jawab terbatas Postgres Professional tidak diharuskan untuk memberikan dukungan, dukungan, pembaruan, ekstensi atau perubahan."
Jika Anda belum menebak produk apa yang sedang kita bicarakan, maka semua pengalaman ini didapat sebagai hasil dari operasi tahunan basis Postgres Pro Enterprise. Anda bisa membuat kesimpulan sendiri, seperti kelembapan yang tumbuh jamur.
Tapi itu akan menjadi setengah masalah, jika dilakukan tepat waktu dan segera menghilangkan masalah yang muncul.
Tapi ini tidak terjadi. Tampaknya, sumber daya pabrikan tidak cukup untuk dengan cepat memperbaiki bug yang diidentifikasi.