"پرو، لیکن کلسٹر نہیں" یا ہم نے درآمد شدہ DBMS کو کیسے تبدیل کیا۔

(ts) Yandex.Images

تمام کردار فرضی ہیں، ٹریڈ مارک ان کے مالکان سے تعلق رکھتے ہیں، کوئی بھی مماثلت بے ترتیب ہے اور عام طور پر، یہ میرا "سبجیکٹو ویلیو ججمنٹ ہے، براہ کرم دروازہ نہ توڑیں..."۔

ہمارے پاس منطق کے ساتھ انفارمیشن سسٹمز کو ڈیٹا بیس میں ایک DBMS سے دوسرے DBMS میں منتقل کرنے کا کافی تجربہ ہے۔ 1236 نومبر 16.11.2016 کے حکومتی فرمان نمبر XNUMX کے تناظر میں، یہ اکثر Oracle سے Postgresql میں منتقلی ہوتی ہے۔ ہم آپ کو الگ سے بتا سکتے ہیں کہ اس عمل کو مؤثر طریقے سے اور بغیر تکلیف کے کیسے ممکن ہوسکے؛ آج ہم کلسٹر کے استعمال کی خصوصیات کے بارے میں بات کریں گے اور طریقہ کار اور افعال میں پیچیدہ منطق کے ساتھ انتہائی بھاری بھرکم تقسیم شدہ نظاموں کی تعمیر میں کن مسائل کا سامنا کرنا پڑ سکتا ہے۔

سپوئلر - ہاں، کیپ، آر اے سی اور پی جی ملٹی ماسٹر بہت مختلف حل ہیں۔

فرض کریں کہ آپ نے پہلے ہی تمام منطق کو plsql سے pgsql میں منتقل کر دیا ہے۔ اور آپ کے ریگریشن ٹیسٹ بالکل ٹھیک ہیں، اب یقیناً آپ اسکیلنگ کے بارے میں سوچ رہے ہیں، کیونکہ... لوڈ ٹیسٹ آپ کو بہت خوش نہیں کرتے، خاص طور پر اس ہارڈ ویئر پر جو اصل میں پروجیکٹ میں شامل کیا گیا تھا، اس بہت مختلف DBMS کے لیے۔ فرض کریں کہ آپ نے گھریلو فروش "پوسٹگریس پروفیشنل" سے "ملٹی ماسٹر" نامی آپشن کے ساتھ ایک حل تلاش کیا ہے، جو صرف "پوسٹگریس پرو انٹرپرائز" کے "زیادہ سے زیادہ" ورژن میں دستیاب ہے اور تفصیل کے مطابق - یہ اس سے بہت ملتا جلتا ہے۔ آپ کو ضرورت ہے، اور پہلے سطحی مطالعہ کے ساتھ ہی میرے ذہن میں یہ خیال آئے گا: "اوہ! 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 نظر آئے گا۔ کیا یہ واقعی 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 کا استعمال کرنے سے بھی کوئی فائدہ نہیں ہوگا، آپ کو اپنی منطق کو اپ ڈیٹ یا دوبارہ لکھنا پڑے گا۔ طریقہ کار. اگر آپ کو پوسٹگریس پرو انٹرپرائز 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 میں اپ گریڈ کریں۔

علیحدہ طور پر، آپ کو یہ جاننے کی ضرورت ہے کہ ترتیب، ایک نقل شدہ ڈیٹا بیس کی آبجیکٹ ہونے کے ناطے، پورے کلسٹر میں اینڈ ٹو اینڈ ویلیو نہیں ہے، ہر ترتیب ہر نوڈ کے لیے مقامی ہے اور اگر آپ کے پاس انوکھی پابندیوں کے ساتھ فیلڈز ہیں اور ترتیب استعمال کرتے ہیں، پھر آپ صرف کلسٹر میں نوڈ نمبر کے برابر اضافہ کر سکتے ہیں، کیونکہ کلسٹر میں جتنے نوڈس ہوں گے، ترتیب اور int آپ کی توقع سے زیادہ تیزی سے بڑھیں گے۔ پروڈکٹ میں ترتیب کے ساتھ کام کرنے کو آسان بنانے کے لیے آپ کو alter_sequences فنکشن بھی مل جائے گا، جو تمام نوڈس پر ہر ترتیب کے لیے ضروری اضافہ کرے گا، لیکن تیار رہیں کہ یہ فنکشن تمام ورژنز میں کام نہیں کرے گا۔ یقینا، آپ اسے خود لکھ سکتے ہیں، گیتھب کے کوڈ کو بنیاد کے طور پر استعمال کرتے ہوئے یا اسے براہ راست 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")

لیکن LiveNodes فیلڈ میں ہر جگہ نمبر 2 کیوں ہوتا ہے، حالانکہ ملٹی ماسٹر کے آپریشن کی تفصیل کے مطابق اسے AllNodes=3 نمبر کے مطابق ہونا چاہیے؟ جواب: آپ کو DBMS ورژن کو اپ ڈیٹ کرنے کی ضرورت ہے۔

اور تمام نوڈس کے لیے نوشتہ جات جمع کرنے کے لیے تیار رہیں، کیونکہ... عام طور پر آپ دیکھیں گے کہ "خرابی کسی اور نوڈ کے لاگ میں ہے۔" تکنیکی معاونت ان تمام نقائص کو قبول کرے گی جن کی آپ شناخت کرتے ہیں اور آپ کو مطلع کرتے ہیں کہ اگلا ورژن تیار ہے، جسے بعض اوقات سروس بند ہونے کے ساتھ انسٹال کرنے کی ضرورت ہوگی، بعض اوقات طویل عرصے تک (آپ کے DBMS کے سائز پر منحصر ہے)۔ آپ کو یہ امید نہیں کرنی چاہئے کہ آپریشنل مسائل وینڈر کو بہت زیادہ پریشان کریں گے، اور شناخت شدہ نقائص کی وجہ سے اپ ڈیٹ وینڈر کے نمائندوں کی شرکت کے ساتھ کیا جائے گا، یا اس کے برعکس، آپ کو وینڈر کے نمائندوں کو شامل کرنے کی بھی ضرورت نہیں ہے، کیونکہ آخر آپ بیک اپ کے بغیر پروڈکشن میں جداگانہ کلسٹر کے ساتھ ختم کر سکتے ہیں۔

دراصل، تجارتی مصنوعات کے لائسنس میں، مینوفیکچرر ایمانداری سے خبردار کرتا ہے: "یہ سافٹ ویئر "جیسے ہے" کی بنیاد پر فراہم کیا گیا ہے اور Postgres Professional Limited Liability Company دیکھ بھال، مدد، اپ ڈیٹس، توسیع یا تبدیلیاں فراہم کرنے کی پابند نہیں ہے۔

اگر آپ نے ابھی تک اندازہ نہیں لگایا ہے کہ ہم کس پروڈکٹ کے بارے میں بات کر رہے ہیں، تو یہ تمام تجربہ پوسٹگریس پرو انٹرپرائز ڈیٹا بیس کے سال بھر کے آپریشن کے نتیجے میں حاصل ہوا ہے۔ آپ اپنا نتیجہ نکال سکتے ہیں، یہ اتنا گیلا ہے کہ مشروم اگتے ہیں۔

لیکن یہ اتنا برا نہیں ہوگا اگر اسے بروقت کیا جائے اور ابھرتے ہوئے مسائل کو فوری طور پر ختم کر دیا جائے۔

لیکن یہ بالکل وہی ہے جو نہیں ہوتا ہے۔ بظاہر مینوفیکچرر کے پاس اتنے وسائل نہیں ہیں کہ وہ شناخت شدہ کیڑے کو فوری طور پر ختم کر سکے۔

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

کیا آپ کو غیر ملکی/ ملکیتی DBMS سے مفت/ گھریلو میں تبدیل کرنے کا تجربہ ہے؟

• 21,3٪ہاں، مثبت 10

• 10,6٪ہاں، منفی5

• 21,3٪نہیں، ڈی بی ایم ایس کو تبدیل نہیں کیا گیا تھا10

• 4,3٪ڈی بی ایم ایس کو تبدیل کیا گیا تھا، لیکن کچھ نہیں بدلا 2

• 42,6٪نتائج دیکھیں 20

47 صارفین نے ووٹ دیا۔ 12 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com