"Pro, гэхдээ кластер биш" эсвэл бид импортын DBMS-ийг хэрхэн сольсон тухай

(ts) Yandex.Images

Бүх дүрүүд зохиомол, барааны тэмдэг нь эзэддээ харьяалагддаг, ижил төстэй байдал нь санамсаргүй бөгөөд ерөнхийдөө энэ бол миний "субъектив үнэ цэнийн дүгнэлт, хаалгыг бүү эвдээрэй ...".

Бид логик бүхий мэдээллийн системийг нэг DBMS-ээс нөгөөд өгөгдлийн сан руу шилжүүлэх асар их туршлагатай. Засгийн газрын 1236 оны 16.11.2016-р сарын XNUMX-ны өдрийн XNUMX тоот тогтоолын хүрээнд энэ нь ихэвчлэн Oracle-аас Postgresql руу шилжих явдал юм. Процедурыг аль болох үр дүнтэй, өвдөлтгүй зохион байгуулах талаар бид тусад нь хэлж чадна; өнөөдөр бид кластер ашиглах онцлог шинж чанарууд, процедур, функцүүдийн нарийн төвөгтэй логик бүхий өндөр ачаалалтай тархсан системийг бий болгоход ямар бэрхшээл тулгарч болох талаар ярих болно.

Spoiler - тийм ээ, cap, RAC болон pg multimaster бол маш өөр шийдэл юм.

Та plsql-ээс pgsql руу бүх логикийг аль хэдийн шилжүүлсэн гэж бодъё. Таны регрессийн тестүүд зүгээр, одоо мэдээжийн хэрэг та масштаблах талаар бодож байна, учир нь ... Ачааллын туршилтууд нь таныг тийм ч их баярлуулдаггүй, ялангуяа уг төсөлд анх орсон техник хангамж, өөр өөр DBMS-ийн хувьд. Та дотоодын үйлдвэрлэгч "Postgres Professional"-аас "multimaster" гэсэн сонголттой шийдлийг олсон гэж бодъё, үүнийг зөвхөн "Postgres Pro Enterprise"-ийн "хамгийн их" хувилбарт ашиглах боломжтой бөгөөд тайлбарын дагуу - энэ нь юутай маш төстэй юм. Танд хэрэгтэй бөгөөд анхны өнгөц судалгаагаар миний толгойд "Өө! Энэ бол RAC-ийн оронд! Тэр ч байтугай манай нутагт техникийн шугам хоолойтой байсан ч!"

Гэхдээ баярлах гэж бүү яар, цаашлаад бид яагаад эдгээр нарийн ширийн зүйлийг мэдэх хэрэгтэйг тайлбарлах болно, учир нь ... Бүтээгдэхүүний баримт бичгийг сайтар уншсан ч тэдгээрийг урьдчилан таамаглахад хэцүү байдаг. Та DBMS хувилбаруудыг үйлдвэрлэлийн сайт дээр байнга шинэчлэхэд бэлэн байгаа эсэхийг үнэлээрэй, учир нь Зарим согог нь үйлдвэрлэлийн хэрэглээнд тохирохгүй бөгөөд туршилтын явцад илрүүлэхэд хэцүү байдаг.
Үйлдвэрлэгчийн вэбсайт дээрх "мултимастер" - "хязгаарлалт" хэсгийг анхааралтай уншиж эхэл.

Таны тулгарч болох хамгийн эхний зүйл бол гүйлгээ гэж нэрлэгддэг гүйлгээний онцлог шинж чанарууд юм. "хоёр фазын" горим, заримдаа процедурын логикийг бүхэлд нь дахин бичихээс бусад тохиолдолд үүнийг засах арга байхгүй. Энд энгийн жишээ байна:

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;

Алдаа гарлаа:

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

Дараа нь та 10.5, 10.6 хувилбаруудын түгжээтэй удаан хугацаанд тэмцэж болох бөгөөд кластерын мөн чанарыг бүхэлд нь устгадаг цорын ганц мэдэгдэж байгаа шийдэл бол кластераас "асуудал" хүснэгтүүдийг арилгах явдал юм. make_table_local хийх боловч энэ нь ядаж үүнийг ажиллах боломжийг олгох бөгөөд гүйлгээний хүлээлтийг хүлээснээс болж бүх зүйлийг саатуулахгүй. За, эсвэл 11.2 хувилбар руу шинэчлэлт суулгаарай, энэ нь туслах болно, гэхдээ үгүй ​​байж магадгүй, шалгахаа бүү мартаарай.

Зарим хувилбарт та илүү нууцлаг түгжээг авах боломжтой:

username= mtm и backend_type = background worker

Ийм нөхцөлд зөвхөн DBMS хувилбарыг 11.2 ба түүнээс дээш хувилбар болгон шинэчлэх нь танд туслах болно, эсвэл энэ нь тус болохгүй.

Индекстэй зарим үйлдлүүд нь алдаа гаргахад хүргэдэг бөгөөд энэ нь асуудал нь хоёр чиглэлтэй хуулбарлалд байгааг тодорхой харуулж байна; та MTM бүртгэлээс BDR-г шууд харах болно. Энэ үнэхээр 2-р квадрант мөн үү? Үгүй ээ... бид multimaster худалдаж авсан, энэ бол зүгээр л тохиолдлын зүйл, энэ бол технологийн нэр юм.

[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 

Хэрэв та түр зуурын хүснэгтүүдийг ашиглаж байгаа бол "Мультимастер өргөтгөл нь мэдээллийн хуулбарыг бүрэн автоматаар гүйцэтгэдэг. Та кластерын дурын цэг дээр нэгэн зэрэг бичих гүйлгээг хийж, түр хүснэгтүүдтэй ажиллах боломжтой."

Дараа нь үнэн хэрэгтээ та хуулбарлах нь процедурт ашигласан бүх хүснэгтэд ажиллахгүй гэдгийг олж мэдэх болно, хэрэв код нь түр зуурын хүснэгт үүсгэхийг агуулж байгаа бол multimaster.remote_functions ашиглах нь ч тус болохгүй бол та логикоо шинэчлэх эсвэл дахин бичих хэрэгтэй болно. журам. Хэрэв та "Postgres Pro Enterprise" v 10.5-ийн хүрээнд multimaster болон pg_pathman хоёр өргөтгөлийг нэгэн зэрэг ашиглах шаардлагатай бол дараах энгийн жишээгээр шалгана уу:

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

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

Эдгээр алдаа нь юу болохыг техникийн дэмжлэгээс олж мэдэх боломжтой, та үүнийг дэмий хоосон худалдаж аваагүй болно.

Юу хийх вэ? Зөв! "Postgres Pro Enterprise" v 11.2 руу шинэчилнэ үү

Хуулбарласан өгөгдлийн сангийн объект болох дараалал нь бүхэл бүтэн кластерын төгсгөл хүртэлх утгагүй, дараалал бүр зангилаа тус бүрд локал байх ба хэрэв танд өвөрмөц хязгаарлалттай талбарууд байгаа бол дарааллыг ашиглах боломжтой гэдгийг тусад нь мэдэх хэрэгтэй. тэгвэл та зөвхөн кластер дахь зангилааны дугаартай дүйцэхүйц өсөлтийг хийж болно, учир нь Кластерт аль болох олон зангилаа, дараалал болон int таны бодож байснаас хурдан өсөх болно. Бүтээгдэхүүн дэх дараалалтай ажиллахыг хялбарчлахын тулд та бүх зангилааны дараалал бүрт шаардлагатай нэмэгдлийг хийх alter_sequences функцийг олох болно, гэхдээ функц бүх хувилбарт ажиллахгүй гэдэгт бэлэн байгаарай. Мэдээжийн хэрэг, та үүнийг өөрөө бичиж, github-ийн кодыг үндэс болгон ашиглах эсвэл DBMS-д өөрөө засах боломжтой. Энэ тохиолдолд serialbigserial төрлийн талбарууд илүү зөв ажиллах болно, гэхдээ тэдгээрийг ашиглахын тулд та процедур, функцийнхээ кодыг дахин бичих хэрэгтэй болно. Магадгүй хэн нэгэн нь monotonic_sequences функцийг ашигтай гэж үзэх байх.

Postgres Pro Enterprise-ийн 11.2 хувилбараас өмнө хуулбарлах нь зөвхөн өвөрмөц үндсэн түлхүүрүүд байгаа тохиолдолд л ажиллах болно, үүнийг боловсруулахдаа анхаарч үзээрэй.

Кластер шийдэлд npgsql хэрхэн ажилладаг талаар би тусад нь дурдахыг хүсч байна; эдгээр асуудлууд нь нэг зангилаа дээр үүсдэггүй, харин мультимастерт нэлээд байдаг.
Зарим хувилбаруудад та алдаатай тулгарч магадгүй:

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. 

Юу хийж болох вэ? Та зүгээр л зарим хувилбарыг ашиглахгүй байх хэрэгтэй. Та тэдгээрийг мэдэх хэрэгтэй, учир нь ... Алдаа нь нэгээс олон хувилбарт гарч ирдэг бөгөөд үүнийг анх зассан ч дараа нь та тулгарах болно. Та үүнд бэлэн байх хэрэгтэй бөгөөд үйлдвэрлэгчээс зассан DBMS-ийн бүх тодорхойлсон согогийг тусдаа регрессийн тестээр хамрах нь дээр. Тиймээс, итгэ, гэхдээ баталгаажуул.

Хэрэв програм нь npgsql-г ашиглаж, зангилаанууд хоорондоо адилхан гэж бодоод сэлгэвэл танд алдаа гарч болзошгүй:

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

Холбогдол хийгдэж байгаа тул энэ алдаа гарна

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

бүх холболтод зориулсан програмыг эхлүүлэх үед нийлмэл төрлүүд. Үүний үр дүнд бид нэг зангилаанаас танигчийг авдаг бөгөөд өөр зангилаа дээр хүсэлт гаргахад энэ нь таарахгүй, үр дүнд нь алдаа гарч ирдэг, өөрөөр хэлбэл. Кластер дахь нийлмэл төрлүүдтэй ил тод ажиллах нь зарим програмын хувьд нэмэлт програмын талыг дахин бичихгүйгээр (хэрэв та үүнийг хийж чадвал) боломжгүй болно.

Бид бүгд мэдэж байгаагаар кластерын төлөв байдлын ерөнхий үнэлгээ нь ашиглалтын явцад оношлогоо, үйл ажиллагааны арга хэмжээнд маш чухал байдаг тул бүтээгдэхүүнээс таны амьдралыг хөнгөвчлөх зарим функцийг олж авах боломжтой боловч заримдаа тэдгээр нь юунаас тэс өөр зүйлийг өгч чаддаг. та, тэр ч байтугай үйлдвэрлэгч өөрөө тэднээс хүлээж байна.

Жишээ нь:

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

Мультимастерын үйл ажиллагааны тайлбарын дагуу энэ нь AllNodes=2 тоотой тохирч байх ёстой ч LiveNodes талбар яагаад хаа сайгүй 3-ын тоог агуулж байна вэ? Хариулт: Та DBMS хувилбарыг шинэчлэх хэрэгтэй.

Бүх зангилааны бүртгэлийг цуглуулахад бэлэн байгаарай, учир нь ... ихэвчлэн та "алдаа өөр зангилааны бүртгэлд байна" гэж харах болно. Техникийн дэмжлэг нь таны илрүүлсэн бүх согогийг хүлээн авч дараагийн хувилбар бэлэн болсныг мэдээлэх бөгөөд энэ нь заримдаа үйлчилгээ зогссон, заримдаа удаан хугацаагаар (таны DBMS-ийн хэмжээнээс хамаарч) суулгах шаардлагатай болдог. Үйл ажиллагааны асуудал нь худалдагчийг ихээхэн зовооно гэж найдаж болохгүй бөгөөд илэрсэн согогтой холбоотой шинэчлэлтийг худалдагчийн төлөөлөгчдийн оролцоотойгоор хийх болно, эс тэгвээс та худалдагчийн төлөөлөгчдийг оролцуулах шаардлагагүй болно. эцэст нь та задалсан кластерыг нөөцгүйгээр үйлдвэрлэх боломжтой.

Үнэн хэрэгтээ, арилжааны бүтээгдэхүүний лиценз дээр үйлдвэрлэгч: "Энэ програм хангамжийг" байгаагаар нь" хангасан бөгөөд Postgres Мэргэжлийн Хязгаарлагдмал Хариуцлагатай Компани нь засвар үйлчилгээ, дэмжлэг, шинэчлэлт, өргөтгөл, өөрчлөлт оруулах үүрэг хүлээхгүй" гэж үнэнчээр анхааруулдаг.

Хэрэв та ямар бүтээгдэхүүний тухай ярьж байгааг тааж амжаагүй байгаа бол Postgres Pro Enterprise мэдээллийн баазыг бүтэн жилийн турш ажилласны үр дүнд энэ бүх туршлага хуримтлуулсан болно. Та өөрөө дүгнэлт хийж болно, энэ нь маш чийгтэй байдаг тул мөөг ургадаг.

Гэхдээ үүнийг цаг тухайд нь хийж, шинээр гарч ирж буй асуудлуудыг цаг алдалгүй арилгавал тийм ч муу зүйл болохгүй.

Гэхдээ энэ нь яг тохиолддоггүй зүйл юм. Тодорхойлсон алдааг нэн даруй арилгахын тулд үйлдвэрлэгчид хангалттай нөөц байхгүй бололтой.

Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. Нэвтрэх, гуйя.

Танд гадаад/өмчийн DBMS-ээс үнэ төлбөргүй/дотоод руу шилжих туршлагатай юу?

• 21,3%Тийм ээ, эерэг10

• 10,6%Тийм ээ, сөрөг5

• 21,3%Үгүй, DBMS өөрчлөгдөөгүй10

• 4,3%DBMS өөрчлөгдсөн боловч юу ч өөрчлөгдөөгүй2

• 42,6%Үр дүнг харах20

47 хэрэглэгч санал өгсөн. 12 хэрэглэгч түдгэлзсэн.

Эх сурвалж: www.habr.com