🥇 "پرو، خو کلستر نه" یا څنګه موږ د وارداتو DBMS بدل کړ

(ts) Yandex.Images

ټول کرکټرونه جعلي دي، سوداګریزې نښې د دوی په مالکینو پورې اړه لري، هر ډول ورته والی تصادفي دي او په عموم کې، دا زما "د موضوعي ارزښت قضاوت دی، مهرباني وکړئ دروازه مه ماتوئ ...".

موږ له یو DBMS څخه بل ته ډیټابیس ته د منطق سره د معلوماتو سیسټمونو لیږدولو کې د پام وړ تجربه لرو. د 1236 نومبر 16.11.2016 د حکومت د فرمان نمبر XNUMX په شرایطو کې، دا اکثرا د اوراکل څخه Postgresql ته لیږدول کیږي. موږ کولی شو تاسو ته په جلا توګه ووایو چې څنګه د امکان تر حده مؤثره او بې درده پروسه تنظیم کړو؛ نن به موږ د کلستر کارولو ځانګړتیاو په اړه وغږیږو او په کړنلارو او دندو کې د پیچلي منطق سره د خورا بار شوي توزیع شوي سیسټمونو رامینځته کولو کې کومې ستونزې رامینځته کیدی شي.

سپوئلر - هو ، کیپ ، RAC او pg ملټي ماسټر خورا مختلف حلونه دي.

راځئ چې ووایو تاسو دمخه ټول منطق له plsql څخه pgsql ته لیږدولي دي. او ستاسو د راجسټریشن ازموینې خورا سمې دي ، اوس البته تاسو د اندازه کولو په اړه فکر کوئ ، ځکه چې ... د بار ازموینې تاسو ډیر خوښ نه کوي ، په ځانګړي توګه په هارډویر کې چې په اصل کې په پروژه کې شامل و ، د دې خورا مختلف DBMS لپاره. راځئ چې ووایو تاسو د کورني پلورونکي "پوسټګریس پروفیشنل" څخه د "ملټيماسټر" په نوم اختیار سره حل موندلی ، کوم چې یوازې د "پوسټګریس پرو تصدۍ" په "اعظمي" نسخه کې شتون لري او د توضیحاتو سره سم - دا د څه سره ورته دی. تاسو اړتیا لرئ، او د لومړي سطحي مطالعې سره به دا فکر راشي چې زما په سر کې راغلی: "اوه! دا د RAC پرځای دی! او حتی زموږ په هیواد کې د تخنیکي پایپ لاین سره!

مګر د خوښۍ لپاره بېړه مه کوئ ، او نور به موږ تشریح کړو چې ولې تاسو اړتیا لرئ پدې باریکیو پوه شئ ، ځکه چې ... د دوی اټکل کول ستونزمن دي، حتی د محصول اسنادو په بشپړه توګه لوستلو وروسته. ارزونه وکړئ چې ایا تاسو چمتو یاست چې په مکرر ډول د DBMS نسخې په مستقیم ډول د تولید سایټ کې تازه کړئ ، ځکه ځینې نیمګړتیاوې د صنعتي کارونې سره مطابقت نلري او د ازموینې پرمهال کشف کول ستونزمن دي.
د جوړونکي ویب پا onه کې د "ملټي ماسټر" - "محدودیت" برخې په احتیاط سره لوستل پیل کړئ.

لومړی شی چې تاسو ورسره مخ شئ هغه ځانګړتیاوې دي چې څنګه د معاملو کار کوي، په تش په نامه. د "دوه مرحلې" حالت، او ځینې وختونه د دې د حل کولو لپاره هیڅ لاره شتون نلري پرته له دې چې ستاسو د طرزالعمل ټول منطق له سره لیکلو سره. دلته یو ساده مثال دی:

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

او پدې حالت کې ، یوازې 11.2 او لوړ ته د DBMS نسخه تازه کول به تاسو سره مرسته وکړي ، یا شاید دا به مرسته ونه کړي.

د شاخصونو سره ځینې عملیات کولی شي د غلطیو لامل شي، کوم چې په واضح ډول دا په ګوته کوي چې ستونزه په دوه اړخیزه نقل کې ده؛ تاسو به په مستقیم ډول د MTM لاګونو کې BDR وګورئ. ایا دا واقعیا 2nd Quadrant؟ نه... موږ ملټي ماسټر اخیستی، دا یوازې یو تصادف دی، دا د ټیکنالوژۍ نوم دی.

[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 چوکاټ کې په ورته وخت کې دوه توسیع ملټي ماسټر او 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

تاسو کولی شئ ومومئ چې دا غلطۍ په تخنیکي ملاتړ کې څه دي، دا بې ګټې ندي چې تاسو یې اخیستي.

چې څه کول پکار دي؟ سمه ده! د "پوسټګریس پرو انټرپریس" v 11.2 ته لوړ کړئ

په جلا توګه، تاسو اړتیا لرئ پوه شئ چې ترتیب، د نقل شوي ډیټابیس یو څیز دی، په ټول کلستر کې د پای څخه تر پای پورې ارزښت نلري، هر ترتیب د هر نوډ لپاره ځایی دی او که تاسو د ځانګړي محدودیتونو سره ساحې لرئ او د ترتیب کارول، بیا تاسو کولی شئ یوازې په کلستر کې د نوډ شمیر سره مساوي زیاتوالی رامینځته کړئ ، ځکه چې څومره چې ممکنه وي په کلستر کې ډیری نوډونه، ترتیب او انټ به ستاسو د توقع په پرتله ګړندی وده وکړي. په محصول کې د ترتیب سره کار کولو ساده کولو لپاره تاسو به حتی د alter_sequences فنکشن ومومئ ، کوم چې به په ټولو نوډونو کې د هرې ترتیب لپاره اړین زیاتوالی رامینځته کړي ، مګر چمتو اوسئ چې دا فنکشن به په ټولو نسخو کې کار ونکړي. البته ، تاسو کولی شئ دا پخپله ولیکئ ، د ګیتوب څخه کوډ د اساس په توګه وکاروئ یا پخپله مستقیم په DBMS کې سم کړئ. په دې حالت کې، د سیریلبیګسیریل ډول سره ساحې به ډیر سم کار وکړي، مګر د دوی کارولو لپاره، ډیری احتمال به تاسو د خپلو پروسیجرونو او دندو کوډ بیا لیکلو ته اړتیا ولرئ. شاید یو څوک به د 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")

مګر ولې د LiveNodes ساحه په هر ځای کې 2 شمیره لري، که څه هم د ملټي ماسټر عملیاتو توضیحاتو سره سم دا باید د AllNodes = 3 شمیرې سره مطابقت ولري؟ ځواب: تاسو اړتیا لرئ د DBMS نسخه تازه کړئ.

او د ټولو نوډونو لپاره د لاګونو راټولولو لپاره چمتو اوسئ ، ځکه چې ... معمولا تاسو به وګورئ "غلطي د بل نوډ په لاګ کې ده." تخنیکي ملاتړ به ټول هغه نیمګړتیاوې ومني چې تاسو یې پیژنئ او تاسو ته به خبر درکړي چې راتلونکی نسخه چمتو ده، کوم چې ځینې وختونه د خدماتو بندیدو سره نصب کولو ته اړتیا لري، ځینې وختونه د اوږدې مودې لپاره (ستاسو د DBMS اندازې پورې اړه لري). تاسو باید امید ونلرئ چې عملیاتي ستونزې به پلورونکي ته ډیر زیان ورسوي، او د پیژندل شوي نیمګړتیاو له امله تازه کول به د پلورونکي استازو ګډون سره ترسره شي، یا بلکه، تاسو اړتیا نلرئ چې د پلورونکي استازو کې برخه واخلئ، ځکه چې په پای کې تاسو کولی شئ د بیک اپ پرته په تولید کې د جلا شوي کلستر سره پای ته ورسیږئ.

په حقیقت کې ، د سوداګریز محصول لپاره جواز کې ، تولید کونکی په صادقانه توګه خبرداری ورکوي: "دا سافټویر د "لکه څنګه چې دی" اساس چمتو شوی او د پوسټګریس پروفیشنل محدود مسؤلیت شرکت د ساتنې ، ملاتړ ، تازه معلوماتو ، غزولو یا بدلونونو چمتو کولو مکلف ندي.

که تاسو تراوسه اټکل نه دی کړی چې موږ د کوم محصول په اړه خبرې کوو، نو دا ټوله تجربه د پوسټګریس پرو تصدۍ ډیټابیس د کال اوږد عملیاتو په پایله کې ترلاسه شوې. تاسو کولی شئ خپله پایله راوباسئ ، دا دومره لندبل دی چې مرخیړی وده کوي.

مګر دا به دومره بده نه وي که چیرې دا په وخت سره ترسره شي او په چټکۍ سره رامینځته شوي ستونزې له منځه یوسي.

مګر دا دقیقا هغه څه دي چې نه کیږي. په ښکاره ډول تولید کونکی دومره سرچینې نلري چې په سمدستي توګه پیژندل شوي کیګونه له مینځه یوسي.

یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. ننوزئمهرباني وکړئ

ایا تاسو د بهرني/ملکیت DBMS څخه وړیا/کورني ته د بدلولو تجربه لرئ؟

۸۵٪هو، مثبت 10
۸۵٪هو، منفي5
۸۵٪نه، DBMS نه دی بدل شوی10
۸۵٪DBMS بدل شوی، مګر هیڅ بدلون نه دی راغلی
۸۵٪پایلې وګورئ 20

47 کاروونکو رایه ورکړه. 12 کاروونکي منع شوي.

سرچینه: www.habr.com

"پرو، مګر کلستر نه" یا څنګه موږ وارد شوي DBMS ځای په ځای کړل

ایا تاسو د بهرني/ملکیت DBMS څخه وړیا/کورني ته د بدلولو تجربه لرئ؟