Patroni ناکامی کی کہانیاں یا اپنے PostgreSQL کلسٹر کو کیسے کریش کریں۔ الیکسی لیسوفسکی

Patroni کا بنیادی ہدف PostgreSQL کے لیے اعلیٰ دستیابی فراہم کرنا ہے۔ لیکن پیٹرونی صرف ایک ٹیمپلیٹ ہے، ایک تیار شدہ ٹول نہیں ہے (جسے عام طور پر دستاویزات میں کہا جاتا ہے)۔ پہلی نظر میں، ٹیسٹ لیب میں پیٹرونی کو قائم کرنے کے بعد، آپ دیکھ سکتے ہیں کہ یہ کتنا زبردست ٹول ہے اور یہ کلسٹر کو توڑنے کی ہماری کوششوں کو کتنی آسانی سے ہینڈل کرتا ہے۔ تاہم، عملی طور پر، پیداواری ماحول میں، ہر چیز ہمیشہ اتنی خوبصورتی اور نفاست سے نہیں ہوتی جتنی ٹیسٹ لیب میں ہوتی ہے۔

میں آپ کو اپنے بارے میں تھوڑا بتاتا ہوں۔ میں نے ایک سسٹم ایڈمنسٹریٹر کے طور پر شروعات کی۔ ویب ڈویلپمنٹ میں کام کیا۔ میں 2014 سے ڈیٹا ایگریٹ میں کام کر رہا ہوں۔ کمپنی پوسٹگریس کے شعبے میں مشاورت میں مصروف ہے۔ اور ہم بالکل Postgres کی خدمت کرتے ہیں، اور ہم ہر روز Postgres کے ساتھ کام کرتے ہیں، اس لیے ہمارے پاس آپریشن سے متعلق مختلف مہارتیں ہیں۔

اور 2018 کے آخر میں، ہم نے آہستہ آہستہ Patroni کا استعمال شروع کیا۔ اور کچھ تجربہ جمع کیا گیا ہے. ہم نے کسی نہ کسی طرح اس کی تشخیص کی، اسے ٹیون کیا، اپنے بہترین طریقوں پر پہنچے۔ اور اس رپورٹ میں ان کے بارے میں بات کروں گا۔

پوسٹگریس کے علاوہ، مجھے لینکس پسند ہے۔ مجھے اس میں گھومنا اور دریافت کرنا پسند ہے، مجھے کور جمع کرنا پسند ہے۔ مجھے ورچوئلائزیشن، کنٹینرز، ڈوکر، کبرنیٹس پسند ہیں۔ یہ سب میری دلچسپی ہے، کیونکہ ایڈمن کی پرانی عادتیں متاثر ہو رہی ہیں۔ میں نگرانی کے ساتھ نمٹنے کے لئے پسند کرتا ہوں. اور مجھے انتظامیہ سے متعلق پوسٹگریس چیزیں پسند ہیں، یعنی نقل، بیک اپ۔ اور فارغ وقت میں گو میں لکھتا ہوں۔ میں سافٹ ویئر انجینئر نہیں ہوں، میں صرف گو میں اپنے لیے لکھتا ہوں۔ اور یہ مجھے خوشی دیتا ہے۔

• مجھے لگتا ہے کہ آپ میں سے بہت سے لوگ جانتے ہیں کہ پوسٹگریس کے پاس باکس سے باہر HA (اعلی دستیابی) نہیں ہے۔ HA حاصل کرنے کے لیے، آپ کو کچھ انسٹال کرنے، اسے ترتیب دینے، کوشش کرنے اور اسے حاصل کرنے کی ضرورت ہے۔
• کئی ٹولز ہیں اور پیٹرونی ان میں سے ایک ہے جو HA کو بہت ٹھنڈا اور بہت اچھی طرح سے حل کرتا ہے۔ لیکن یہ سب ایک ٹیسٹ لیب میں ڈال کر اور اسے چلا کر، ہم دیکھ سکتے ہیں کہ یہ سب کام کرتا ہے، ہم کچھ مسائل کو دوبارہ پیدا کر سکتے ہیں، دیکھیں کہ پیٹرونی ان کی خدمت کیسے کرتا ہے۔ اور ہم دیکھیں گے کہ یہ سب بہت اچھا کام کرتا ہے۔
• لیکن عملی طور پر ہمیں مختلف مسائل کا سامنا کرنا پڑا۔ اور میں ان مسائل پر بات کروں گا۔
• میں آپ کو بتاؤں گا کہ ہم نے اس کی تشخیص کیسے کی، ہم نے کیا ٹویٹ کیا - چاہے اس نے ہماری مدد کی یا نہیں۔

• میں آپ کو پیٹرونی کو انسٹال کرنے کا طریقہ نہیں بتاؤں گا، کیونکہ آپ انٹرنیٹ پر گوگل کر سکتے ہیں، آپ کنفیگریشن فائلوں کو دیکھ کر یہ سمجھ سکتے ہیں کہ یہ سب کیسے شروع ہوتا ہے، اسے کیسے ترتیب دیا جاتا ہے۔ آپ اسکیموں، فن تعمیر کو سمجھ سکتے ہیں، انٹرنیٹ پر اس کے بارے میں معلومات حاصل کر سکتے ہیں۔
• میں کسی اور کے تجربے کی بات نہیں کروں گا۔ میں صرف ان مسائل پر بات کروں گا جن کا ہمیں سامنا ہے۔
• اور میں ان مسائل کے بارے میں بات نہیں کروں گا جو Patroni اور PostgreSQL سے باہر ہیں۔ اگر، مثال کے طور پر، توازن سے منسلک مسائل ہیں، جب ہمارا کلسٹر ٹوٹ گیا ہے، میں اس پر بات نہیں کروں گا۔

اور ہماری رپورٹ شروع کرنے سے پہلے ایک چھوٹا سا دستبرداری۔

یہ تمام مسائل جن کا ہم نے سامنا کیا، وہ آپریشن کے پہلے 6-7-8 مہینوں میں ہوا۔ وقت گزرنے کے ساتھ، ہم اپنے اندرونی بہترین طریقوں پر آ گئے۔ اور ہمارے مسائل ختم ہو گئے۔ اس لیے اس رپورٹ کا اعلان تقریباً چھ ماہ قبل کیا گیا تھا، جب یہ سب میرے ذہن میں تازہ تھا اور مجھے یہ سب بالکل یاد تھا۔

رپورٹ کی تیاری کے دوران، میں نے پہلے ہی پرانے پوسٹ مارٹم اٹھائے، نوشتہ جات کو دیکھا۔ اور مسائل کے تجزیہ کے دوران کچھ تفصیلات کو فراموش کیا جا سکتا ہے، یا کچھ تفصیلات پر پوری طرح تحقیق نہیں ہو سکی، اس لیے بعض مقامات پر ایسا محسوس ہوتا ہے کہ مسائل پر پوری طرح غور نہیں کیا گیا، یا کچھ معلومات کی کمی ہے۔ اور اس لیے میں آپ سے اس لمحے کے لیے معافی مانگتا ہوں۔

Patroni کیا ہے؟

• یہ HA کی تعمیر کے لیے ایک ٹیمپلیٹ ہے۔ دستاویزات میں یہی کہا گیا ہے۔ اور میرے نقطہ نظر سے، یہ ایک بالکل درست وضاحت ہے۔ پیٹرونی چاندی کی گولی نہیں ہے جو آپ کے تمام مسائل کو حل کردے، یعنی آپ کو اس کے کام کرنے اور فوائد پہنچانے کے لیے کوشش کرنے کی ضرورت ہے۔
• یہ ایک ایجنٹ سروس ہے جو ہر ڈیٹا بیس سروس پر انسٹال ہوتی ہے اور یہ آپ کے پوسٹگریس کے لیے ایک قسم کا init سسٹم ہے۔ یہ پوسٹگریس شروع کرتا ہے، رک جاتا ہے، دوبارہ شروع ہوتا ہے، دوبارہ ترتیب دیتا ہے، اور آپ کے کلسٹر کی ٹوپولوجی کو تبدیل کرتا ہے۔
• اس کے مطابق، کلسٹر کی حالت کو ذخیرہ کرنے کے لیے، اس کی موجودہ نمائندگی، جیسا کہ ایسا لگتا ہے، کسی قسم کی اسٹوریج کی ضرورت ہے۔ اور اس نقطہ نظر سے پیٹرونی نے ریاست کو بیرونی نظام میں ذخیرہ کرنے کا راستہ اختیار کیا۔ یہ ایک تقسیم شدہ کنفیگریشن اسٹوریج سسٹم ہے۔ یہ Etcd، Consul، ZooKeeper، یا kubernetes Etcd ہو سکتا ہے، یعنی ان میں سے ایک آپشن۔
• اور پیٹرونی کی ایک خصوصیت یہ ہے کہ آپ آٹو فائلر کو باکس سے باہر نکالتے ہیں، صرف اسے ترتیب دے کر۔ اگر ہم موازنہ کے لیے Repmgr لیتے ہیں، تو فائلر وہاں شامل ہوتا ہے۔ Repmgr کے ساتھ، ہمیں ایک سوئچ اوور ملتا ہے، لیکن اگر ہم آٹو فائلر چاہتے ہیں، تو ہمیں اسے اضافی طور پر کنفیگر کرنے کی ضرورت ہے۔ پیٹرونی کے پاس پہلے سے ہی ایک آٹو فائلر آؤٹ آف دی باکس ہے۔
• اور بھی بہت سی چیزیں ہیں۔ مثال کے طور پر، کنفیگریشنز کی دیکھ بھال، نئی نقلیں ڈالنا، بیک اپ وغیرہ۔ لیکن یہ رپورٹ کے دائرہ کار سے باہر ہے، میں اس پر بات نہیں کروں گا۔

اور ایک چھوٹا سا نتیجہ یہ ہے کہ پیٹرونی کا بنیادی کام آٹو فائل کو اچھی طرح اور قابل اعتماد طریقے سے کرنا ہے تاکہ ہمارا کلسٹر فعال رہے اور ایپلیکیشن کلسٹر ٹوپولوجی میں تبدیلیوں کو محسوس نہ کرے۔

لیکن جب ہم Patroni کا استعمال شروع کرتے ہیں، تو ہمارا نظام قدرے پیچیدہ ہو جاتا ہے۔ اگر پہلے ہمارے پاس Postgres تھا، تو Patroni کا استعمال کرتے وقت ہمیں Patroni ہی مل جاتا ہے، ہمیں DCS ملتا ہے جہاں اسٹیٹ اسٹور ہوتا ہے۔ اور یہ سب کسی نہ کسی طرح کام کرنا ہے۔ تو کیا غلط ہو سکتا ہے؟

ٹوٹ سکتا ہے:

• پوسٹگریس ٹوٹ سکتی ہے۔ یہ ایک ماسٹر یا ایک نقل ہو سکتا ہے، ان میں سے ایک ناکام ہو سکتا ہے.
• پیٹرونی خود ٹوٹ سکتا ہے۔
• DCS جہاں ریاست کو ذخیرہ کیا جاتا ہے ٹوٹ سکتا ہے۔
• اور نیٹ ورک ٹوٹ سکتا ہے۔

ان تمام نکات پر میں رپورٹ میں غور کروں گا۔

میں مقدمات پر غور کروں گا کیونکہ وہ زیادہ پیچیدہ ہو جاتے ہیں، اس نقطہ نظر سے نہیں کہ کیس میں بہت سے اجزاء شامل ہیں۔ اور موضوعی احساسات کے نقطہ نظر سے، کہ یہ کیس میرے لیے مشکل تھا، اسے جدا کرنا مشکل تھا... اور اس کے برعکس، کچھ کیس ہلکا تھا اور اسے جدا کرنا آسان تھا۔

اور پہلی صورت سب سے آسان ہے۔ یہ اس وقت ہوتا ہے جب ہم نے ڈیٹا بیس کلسٹر لیا اور اسی کلسٹر پر اپنے DCS اسٹوریج کو تعینات کیا۔ یہ سب سے عام غلطی ہے۔ یہ فن تعمیر کی غلطی ہے، یعنی مختلف اجزاء کو ایک جگہ پر جمع کرنا۔

تو، ایک فائلر تھا، چلو کیا ہوا اس سے نمٹنے کے لئے چلتے ہیں.

اور یہاں ہم اس میں دلچسپی رکھتے ہیں کہ فائلر کب ہوا۔ یعنی، ہم وقت کے اس لمحے میں دلچسپی رکھتے ہیں جب کلسٹر کی حالت بدل گئی تھی۔

لیکن فائلر ہمیشہ فوری نہیں ہوتا، یعنی اس میں وقت کی کوئی اکائی نہیں لگتی، اس میں تاخیر ہو سکتی ہے۔ یہ دیرپا ہو سکتا ہے۔

لہٰذا، اس کا آغاز وقت اور اختتامی وقت ہے، یعنی یہ ایک مسلسل واقعہ ہے۔ اور ہم تمام واقعات کو تین وقفوں میں تقسیم کرتے ہیں: ہمارے پاس فائلر سے پہلے، فائلر کے دوران اور فائلر کے بعد وقت ہوتا ہے۔ یعنی ہم اس ٹائم لائن میں تمام واقعات پر غور کرتے ہیں۔

اور پہلی بات، جب کوئی فائلر ہوا تو ہم اس کی وجہ تلاش کرتے ہیں کہ کیا ہوا، فائلر کی وجہ کیا تھی۔

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

اگلا، ہمیں یہ سمجھنے کی ضرورت ہے کہ فائلر کیوں ہوا، یعنی کون سے واقعات پیش آئے جس کی وجہ سے ماسٹر رول ایک نوڈ سے دوسرے میں منتقل ہوا۔ اور اس معاملے میں، سب کچھ آسان ہے. ہمیں اسٹوریج سسٹم کے ساتھ تعامل کرنے میں ایک خامی ہے۔ ماسٹر نے محسوس کیا کہ وہ ڈی سی ایس کے ساتھ کام نہیں کر سکتا، یعنی بات چیت میں کسی قسم کا مسئلہ تھا۔ اور وہ کہتا ہے کہ اب وہ ماسٹر نہیں رہ سکتا اور استعفیٰ دے دیتا ہے۔ یہ سطر "ذہنی نفس" بالکل یہی کہتی ہے۔

اگر ہم فائلر سے پہلے کے واقعات کو دیکھیں تو ہم وہاں وہی وجوہات دیکھ سکتے ہیں جن کی وجہ سے وزرڈ کو جاری رکھنے میں مسئلہ پیدا ہوا۔

اگر ہم پیٹرونی لاگز کو دیکھیں گے، تو ہم دیکھیں گے کہ ہمارے پاس بہت ساری خرابیاں ہیں، ٹائم آؤٹ، یعنی پیٹرونی ایجنٹ DCS کے ساتھ کام نہیں کر سکتا۔ اس معاملے میں، یہ قونصل ایجنٹ ہے، جو پورٹ 8500 پر بات چیت کر رہا ہے۔

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

کچھ عرصے کے بعد جب بوجھ کم ہوا تو ہمارا پیٹرونی دوبارہ ایجنٹوں سے رابطہ کرنے میں کامیاب ہوگیا۔ معمول کا کام دوبارہ شروع ہو گیا۔ اور وہی Pgdb-2 سرور دوبارہ ماسٹر بن گیا۔ یعنی، ایک چھوٹا سا فلپ تھا، جس کی وجہ سے نوڈ نے ماسٹر کے اختیارات کو استعفی دے دیا، اور پھر انہیں دوبارہ لے لیا، یعنی، سب کچھ جیسا تھا واپس آ گیا.

اور اسے غلط الارم قرار دیا جا سکتا ہے، یا یہ سمجھا جا سکتا ہے کہ پیٹرونی نے سب کچھ ٹھیک کیا۔ یعنی اس نے محسوس کیا کہ وہ کلسٹر کی حالت کو برقرار نہیں رکھ سکتا اور اس کے اختیار کو ختم کر دیا۔

اور یہاں مسئلہ اس حقیقت کی وجہ سے پیدا ہوا کہ قونصل سرورز اڈوں کی طرح ہارڈ ویئر پر ہیں۔ اس کے مطابق، کوئی بھی بوجھ: چاہے وہ ڈسک یا پروسیسرز پر بوجھ ہو، یہ قونصل کلسٹر کے ساتھ تعامل کو بھی متاثر کرتا ہے۔

اور ہم نے فیصلہ کیا کہ اسے اکٹھے نہیں رہنا چاہیے، ہم نے قونصل کے لیے الگ کلسٹر مختص کیا۔ اور پیٹرونی پہلے ہی ایک علیحدہ قونصل کے ساتھ کام کر رہا تھا، یعنی ایک الگ پوسٹگریس کلسٹر تھا، ایک الگ قونصل کلسٹر تھا۔ یہ ایک بنیادی ہدایت ہے کہ ان تمام چیزوں کو کیسے اٹھانا اور رکھنا ہے تاکہ یہ ایک ساتھ نہ رہے۔

ایک اختیار کے طور پر، آپ ttl، loop_wait، retry_timeout کے پیرامیٹرز کو موڑ سکتے ہیں، یعنی ان پیرامیٹرز کو بڑھا کر ان قلیل مدتی بوجھ کی چوٹیوں کو برقرار رکھنے کی کوشش کریں۔ لیکن یہ سب سے مناسب آپشن نہیں ہے، کیونکہ یہ بوجھ وقت میں لمبا ہو سکتا ہے۔ اور ہم صرف ان پیرامیٹرز کی ان حدود سے باہر جائیں گے۔ اور یہ واقعی مدد نہیں کر سکتا.

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

دوسرا مسئلہ پہلے کی طرح ہے۔ یہ اسی طرح ہے کہ ہمارے پاس ڈی سی ایس سسٹم کے ساتھ انٹرآپریبلٹی کے مسائل ہیں۔

اگر ہم نوشتہ جات پر نظر ڈالیں تو ہم دیکھیں گے کہ ہمارے پاس ایک بار پھر کمیونیکیشن کی خرابی ہے۔ اور پیٹرونی کا کہنا ہے کہ میں DCS کے ساتھ بات چیت نہیں کرسکتا لہذا موجودہ ماسٹر ریپلیکا موڈ میں چلا جاتا ہے۔

پرانا ماسٹر ایک نقل بن جاتا ہے، یہاں پیٹرونی کام کرتا ہے، جیسا کہ ہونا چاہئے. یہ ٹرانزیکشن لاگ کو ریوائنڈ کرنے کے لیے pg_rewind چلاتا ہے اور پھر نئے ماسٹر سے رابطہ کرنے کے لیے نئے ماسٹر سے جڑ جاتا ہے۔ یہاں پیٹرونی کام کرتا ہے، جیسا کہ اسے کرنا چاہیے۔

یہاں ہمیں فائلر سے پہلے والی جگہ تلاش کرنی چاہیے، یعنی وہ غلطیاں جن کی وجہ سے ہمیں فائلر ملا۔ اور اس سلسلے میں پیٹرونی لاگز کام کرنے کے لیے کافی آسان ہیں۔ وہ ایک خاص وقفے سے وہی پیغامات لکھتا ہے۔ اور اگر ہم ان لاگز کو تیزی سے اسکرول کرنا شروع کر دیں، تو ہم لاگز سے دیکھیں گے کہ لاگز تبدیل ہو گئے ہیں، جس کا مطلب ہے کہ کچھ مسائل شروع ہو گئے ہیں۔ ہم جلدی سے اس جگہ پر لوٹتے ہیں، دیکھتے ہیں کیا ہوتا ہے۔

اور عام صورت حال میں، نوشتہ جات کچھ اس طرح نظر آتے ہیں۔ تالے کے مالک کی جانچ پڑتال کی جاتی ہے۔ اور اگر مالک، مثال کے طور پر، بدل گیا ہے، تو کچھ واقعات رونما ہو سکتے ہیں جن کا پیٹرونی کو جواب دینا چاہیے۔ لیکن اس معاملے میں ہم ٹھیک ہیں۔ ہم اس جگہ کی تلاش کر رہے ہیں جہاں سے غلطیاں شروع ہوئیں۔

اور اس مقام تک سکرول کرنے کے بعد جہاں غلطیاں ظاہر ہونا شروع ہوئیں، ہم دیکھتے ہیں کہ ہمارے پاس ایک آٹو فائل اوور ہے۔ اور چونکہ ہماری غلطیاں DCS کے ساتھ بات چیت سے متعلق تھیں اور ہمارے معاملے میں ہم نے قونصل کا استعمال کیا، ہم قونصل کے لاگز کو بھی دیکھتے ہیں، وہاں کیا ہوا تھا۔

فائلر کے وقت اور قونصل لاگ میں وقت کا موٹا موازنہ کرتے ہوئے، ہم دیکھتے ہیں کہ قونصل کلسٹر میں ہمارے پڑوسیوں نے قونصل کلسٹر کے دیگر اراکین کے وجود پر شک کرنا شروع کر دیا۔

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

اگر آپ دیکھیں کہ ان غلطیوں سے پہلے کیا ہوا تھا، تو آپ دیکھ سکتے ہیں کہ ہر طرح کی غلطیاں ہیں، مثال کے طور پر، ڈیڈ لائن، RPC گر گئی، یعنی قونصل کلسٹر ممبران کے ایک دوسرے کے ساتھ بات چیت میں واضح طور پر کسی قسم کی پریشانی ہے۔ .

سب سے آسان جواب نیٹ ورک کو ٹھیک کرنا ہے۔ لیکن میرے لیے پوڈیم پر کھڑے ہو کر یہ کہنا آسان ہے۔ لیکن حالات ایسے ہیں کہ ہمیشہ گاہک نیٹ ورک کی مرمت کا متحمل نہیں ہوتا۔ وہ ڈی سی میں رہ سکتا ہے اور ہو سکتا ہے کہ نیٹ ورک کو ٹھیک نہ کر سکے، آلات کو متاثر کر سکے۔ اور اس لیے کچھ اور آپشنز کی ضرورت ہے۔

اختیارات ہیں:

• سب سے آسان آپشن، جو لکھا گیا ہے، میری رائے میں، یہاں تک کہ دستاویزات میں بھی، قونصل چیک کو غیر فعال کرنا ہے، یعنی صرف ایک خالی صف کو پاس کرنا۔ اور ہم قونصل ایجنٹ سے کہتے ہیں کہ کوئی چیک استعمال نہ کریں۔ ان چیکوں کے ساتھ، ہم نیٹ ورک کے ان طوفانوں کو نظر انداز کر سکتے ہیں اور فائلر کو شروع نہیں کر سکتے ہیں۔
• دوسرا آپشن raft_multiplier کو دو بار چیک کرنا ہے۔ یہ خود قونصل سرور کا ایک پیرامیٹر ہے۔ پہلے سے طے شدہ طور پر، یہ 5 پر سیٹ کیا جاتا ہے۔ اس قدر کی سفارش ماحولیات کے لیے دستاویزات کے ذریعے کی جاتی ہے۔ درحقیقت، یہ قونصل نیٹ ورک کے اراکین کے درمیان پیغام رسانی کی فریکوئنسی کو متاثر کرتا ہے۔ درحقیقت، یہ پیرامیٹر قونصل کلسٹر کے اراکین کے درمیان سروس مواصلات کی رفتار کو متاثر کرتا ہے۔ اور پیداوار کے لیے، پہلے ہی اسے کم کرنے کی سفارش کی جاتی ہے تاکہ نوڈس زیادہ کثرت سے پیغامات کا تبادلہ کریں۔
• ایک اور آپشن جو ہم لے کر آئے ہیں وہ ہے آپریٹنگ سسٹم کے پراسیس شیڈیولر کے لیے دیگر عملوں کے درمیان قونصل کے عمل کی ترجیح کو بڑھانا۔ اس طرح کا ایک "اچھا" پیرامیٹر ہے، یہ صرف ان عملوں کی ترجیح کا تعین کرتا ہے جنہیں شیڈول کرتے وقت OS شیڈولر کے حساب سے لیا جاتا ہے۔ ہم نے قونصل ایجنٹوں کے لیے اچھی قیمت کو بھی کم کر دیا ہے، یعنی ترجیح میں اضافہ کیا تاکہ آپریٹنگ سسٹم قونصل کے عمل کو کام کرنے اور اپنے کوڈ پر عمل کرنے کے لیے مزید وقت فراہم کرے۔ ہمارے معاملے میں، اس سے ہمارا مسئلہ حل ہو گیا۔
• دوسرا آپشن قونصل کو استعمال نہ کرنا ہے۔ میرا ایک دوست ہے جو Etcd کا بڑا حامی ہے۔ اور ہم باقاعدگی سے اس کے ساتھ بحث کرتے ہیں کہ کون بہتر ہے Etcd یا قونصل۔ لیکن جس کے لحاظ سے بہتر ہے، ہم عام طور پر اس سے اتفاق کرتے ہیں کہ قونصل کے پاس ایک ایجنٹ ہے جو ڈیٹا بیس کے ساتھ ہر نوڈ پر چل رہا ہے۔ یعنی پیٹرونی کا قونصل کلسٹر کے ساتھ تعامل اس ایجنٹ کے ذریعے ہوتا ہے۔ اور یہ ایجنٹ رکاوٹ بن جاتا ہے۔ اگر ایجنٹ کو کچھ ہو جاتا ہے، تو پیٹرونی قونصل کلسٹر کے ساتھ مزید کام نہیں کر سکتا۔ اور یہی مسئلہ ہے۔ Etcd پلان میں کوئی ایجنٹ نہیں ہے۔ Patroni Etcd سرورز کی فہرست کے ساتھ براہ راست کام کر سکتا ہے اور پہلے ہی ان کے ساتھ بات چیت کر سکتا ہے۔ اس سلسلے میں، اگر آپ اپنی کمپنی میں Etcd استعمال کرتے ہیں، تو Etcd ممکنہ طور پر قونصل سے بہتر انتخاب ہوگا۔ لیکن ہم اپنے صارفین کے لیے ہمیشہ محدود رہتے ہیں جو کلائنٹ نے منتخب کیا اور استعمال کیا ہے۔ اور ہمارے پاس تمام کلائنٹس کے لیے زیادہ تر قونصلر ہیں۔
• اور آخری نکتہ پیرامیٹر کی اقدار پر نظر ثانی کرنا ہے۔ ہم ان پیرامیٹرز کو اس امید کے ساتھ بڑھا سکتے ہیں کہ ہمارے قلیل مدتی نیٹ ورک کے مسائل مختصر ہوں گے اور ان پیرامیٹرز کی حد سے باہر نہیں ہوں گے۔ اس طرح ہم پیٹرونی کی جارحیت کو آٹو فائل میں کم کر سکتے ہیں اگر نیٹ ورک کے کچھ مسائل پیش آئیں۔

میرے خیال میں پیٹرونی استعمال کرنے والے بہت سے لوگ اس حکم سے واقف ہیں۔

یہ کمانڈ کلسٹر کی موجودہ حالت کو ظاہر کرتا ہے۔ اور پہلی نظر میں یہ تصویر نارمل لگ سکتی ہے۔ ہمارے پاس ایک ماسٹر ہے، ہمارے پاس ایک نقل ہے، نقل کی کوئی وقفہ نہیں ہے۔ لیکن یہ تصویر بالکل نارمل ہے جب تک کہ ہم یہ نہ جان لیں کہ اس کلسٹر میں دو نہیں بلکہ تین نوڈس ہونے چاہئیں۔

اس کے مطابق، ایک آٹو فائل تھی. اور اس آٹو فائل کے بعد ہماری نقل غائب ہو گئی۔ ہمیں یہ معلوم کرنے کی ضرورت ہے کہ وہ کیوں غائب ہوئی اور اسے واپس لانا، اسے بحال کرنا ہے۔ اور ہم دوبارہ لاگز پر جاتے ہیں اور دیکھتے ہیں کہ ہمارے پاس آٹو فائل اوور کیوں تھا۔

اس صورت میں، دوسری نقل ماسٹر بن گیا. یہاں سب ٹھیک ہے۔

اور ہمیں اس نقل کو دیکھنے کی ضرورت ہے جو گر گئی اور جو کلسٹر میں نہیں ہے۔ ہم پیٹرونی لاگز کو کھولتے ہیں اور دیکھتے ہیں کہ pg_rewind مرحلے پر کلسٹر سے جڑنے کے عمل کے دوران ہمیں ایک مسئلہ درپیش تھا۔ کلسٹر سے جڑنے کے لیے، آپ کو ٹرانزیکشن لاگ کو ریوائنڈ کرنے کی ضرورت ہے، ماسٹر سے مطلوبہ لین دین لاگ کی درخواست کریں، اور اسے ماسٹر سے ملنے کے لیے استعمال کریں۔

اس صورت میں، ہمارے پاس ٹرانزیکشن لاگ نہیں ہے اور نقل شروع نہیں ہو سکتی۔ اس کے مطابق، ہم پوسٹگریس کو ایک غلطی کے ساتھ روکتے ہیں۔ اور اس لیے یہ کلسٹر میں نہیں ہے۔

ہمیں یہ سمجھنے کی ضرورت ہے کہ یہ کلسٹر میں کیوں نہیں ہے اور وہاں لاگ کیوں نہیں ہیں۔ ہم نئے ماسٹر کے پاس جاتے ہیں اور دیکھتے ہیں کہ اس کے نوشتہ جات میں کیا ہے۔ یہ پتہ چلتا ہے کہ جب pg_rewind کیا گیا تھا، ایک چوکی واقع ہوئی. اور کچھ پرانے لین دین کے نوشتہ جات کا نام بدل دیا گیا۔ جب پرانے ماسٹر نے نئے ماسٹر سے رابطہ قائم کرنے اور ان لاگز سے استفسار کرنے کی کوشش کی، تو ان کا نام تبدیل کر دیا گیا تھا، وہ صرف موجود ہی نہیں تھے۔

میں نے ٹائم اسٹیمپ کا موازنہ کیا جب یہ واقعات پیش آئے۔ اور وہاں فرق لفظی طور پر 150 ملی سیکنڈ کا ہے، یعنی چوکی 369 ملی سیکنڈ میں مکمل ہوئی، WAL سیگمنٹس کا نام تبدیل کر دیا گیا۔ اور لفظی طور پر 517 میں، 150 ملی سیکنڈ کے بعد، پرانی نقل پر ریوائنڈ شروع ہوا۔ یعنی ہمارے لیے لفظی طور پر 150 ملی سیکنڈ کافی تھے تاکہ ریپلیکا جوڑ کر کمائی نہ کر سکے۔

اختیارات کیا ہیں؟

ہم نے ابتدائی طور پر نقل کی سلاٹ استعمال کیں۔ ہم نے سوچا کہ یہ اچھا ہے۔ اگرچہ آپریشن کے پہلے مرحلے میں ہم نے سلاٹس کو بند کر دیا تھا۔ ہمیں ایسا لگتا تھا کہ اگر سلاٹ بہت زیادہ WAL سیگمنٹس جمع کر لیتے ہیں، تو ہم ماسٹر کو گرا سکتے ہیں۔ وہ گر جائے گا۔ ہم نے کچھ عرصہ بغیر سلاٹ کے سہا۔ اور ہم نے محسوس کیا کہ ہمیں سلاٹ کی ضرورت ہے، ہم نے سلاٹ واپس کردیئے۔

لیکن یہاں ایک مسئلہ ہے، کہ جب ماسٹر ریپلیکا پر جاتا ہے، تو وہ سلاٹس کو حذف کر دیتا ہے اور سلاٹ کے ساتھ WAL سیگمنٹس کو بھی حذف کر دیتا ہے۔ اور اس مسئلے کو ختم کرنے کے لیے، ہم نے wal_keep_segments پیرامیٹر کو بڑھانے کا فیصلہ کیا۔ یہ 8 حصوں پر طے شدہ ہے۔ ہم نے اسے بڑھا کر 1 کر دیا اور دیکھا کہ ہمارے پاس کتنی خالی جگہ ہے۔ اور ہم نے wal_keep_segments کے لیے 000 گیگا بائٹس عطیہ کیں۔ یعنی سوئچ کرتے وقت، ہمارے پاس ہمیشہ تمام نوڈس پر 16 گیگا بائٹس کے لین دین کے لاگز کا ذخیرہ ہوتا ہے۔

اور پلس - یہ اب بھی طویل مدتی دیکھ بھال کے کاموں کے لیے متعلقہ ہے۔ ہم کہتے ہیں کہ ہمیں نقلوں میں سے ایک کو اپ ڈیٹ کرنے کی ضرورت ہے۔ اور ہم اسے بند کرنا چاہتے ہیں۔ ہمیں سافٹ ویئر کو اپ ڈیٹ کرنے کی ضرورت ہے، شاید آپریٹنگ سسٹم، کچھ اور۔ اور جب ہم ایک نقل کو بند کرتے ہیں، تو اس نقل کی سلاٹ بھی ہٹا دی جاتی ہے۔ اور اگر ہم چھوٹے wal_keep_segments استعمال کرتے ہیں، تو نقل کی طویل غیر موجودگی کے ساتھ، لین دین کے لاگز ضائع ہو جائیں گے۔ ہم ایک نقل تیار کریں گے، یہ ان ٹرانزیکشن لاگز کی درخواست کرے گا جہاں یہ رکا تھا، لیکن ہو سکتا ہے وہ ماسٹر پر نہ ہوں۔ اور نقل بھی مربوط نہیں ہو سکے گی۔ اس لیے، ہم رسالوں کا ایک بڑا ذخیرہ رکھتے ہیں۔

ہمارے پاس پیداوار کی بنیاد ہے۔ پہلے سے ہی منصوبے جاری ہیں۔

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

پروڈکٹ ٹیم کا کہنا ہے کہ کچھ ڈیٹا ہونا چاہیے، لیکن ہم اسے ایک ذریعہ سے دیکھتے ہیں، لیکن ہم اسے ڈیٹا بیس میں نہیں دیکھتے۔ اور ہمیں یہ سمجھنے کی ضرورت ہے کہ ان کے ساتھ کیا ہوا۔

یہ واضح ہے کہ pg_rewind نے انہیں یاد کیا۔ ہم فوراً یہ بات سمجھ گئے، لیکن یہ دیکھنے گئے کہ کیا ہو رہا ہے۔

لاگز میں، ہم ہمیشہ یہ تلاش کر سکتے ہیں کہ فائلر کب ہوا، کون ماسٹر بنا، اور ہم یہ تعین کر سکتے ہیں کہ پرانا ماسٹر کون تھا اور وہ کب ریپلیکا بننا چاہتا تھا، یعنی ہمیں ٹرانزیکشن لاگز کی مقدار معلوم کرنے کے لیے ان لاگز کی ضرورت ہوتی ہے۔ کھو گیا تھا.

ہمارے پرانے ماسٹر نے دوبارہ شروع کیا ہے۔ اور پیٹرونی کو آٹورن میں رجسٹر کیا گیا تھا۔ Patroni کا آغاز کیا۔ اس کے بعد اس نے پوسٹگریس شروع کی۔ مزید واضح طور پر، Postgres کو شروع کرنے سے پہلے اور اسے ایک نقل بنانے سے پہلے، Patroni نے pg_rewind عمل شروع کیا۔ اس کے مطابق، اس نے لین دین کے لاگز کا کچھ حصہ مٹا دیا، نئے ڈاؤن لوڈ کیے اور منسلک ہو گئے۔ یہاں پیٹرونی نے ہوشیاری سے کام کیا، یعنی توقع کے مطابق۔ کلسٹر کو بحال کر دیا گیا ہے۔ ہمارے پاس 3 نوڈس تھے، فائلر 3 نوڈس کے بعد - سب کچھ ٹھنڈا ہے۔

ہم نے کچھ ڈیٹا کھو دیا ہے۔ اور ہمیں یہ سمجھنے کی ضرورت ہے کہ ہم نے کتنا کھویا ہے۔ ہم صرف اس لمحے کی تلاش میں ہیں جب ہمارے پاس ریوائنڈ تھا۔ ہم اسے اس طرح کے جریدے کے اندراجات میں تلاش کرسکتے ہیں۔ ریوائنڈ شروع ہوا، وہاں کچھ کیا اور ختم ہوا۔

ہمیں ٹرانزیکشن لاگ میں وہ پوزیشن تلاش کرنے کی ضرورت ہے جہاں پرانے ماسٹر نے چھوڑا تھا۔ اس صورت میں، یہ نشان ہے. اور ہمیں ایک دوسرے نشان کی ضرورت ہے، یعنی وہ فاصلہ جس سے پرانا ماسٹر نئے سے مختلف ہو۔

ہم معمول کے مطابق pg_wal_lsn_diff لیتے ہیں اور ان دو نشانوں کا موازنہ کرتے ہیں۔ اور اس صورت میں، ہمیں 17 میگا بائٹس ملتے ہیں۔ بہت یا تھوڑا، ہر کوئی اپنے لیے فیصلہ کرتا ہے۔ کیونکہ کسی کے لیے 17 میگا بائٹس زیادہ نہیں ہے، کسی کے لیے یہ بہت زیادہ اور ناقابل قبول ہے۔ یہاں، ہر فرد اپنے لیے کاروبار کی ضروریات کے مطابق تعین کرتا ہے۔

لیکن ہم نے اپنے لیے کیا پایا؟

سب سے پہلے، ہمیں خود فیصلہ کرنا چاہیے - کیا ہمیں سسٹم ریبوٹ کے بعد آٹو سٹارٹ کرنے کے لیے Patroni کی ضرورت ہے؟ اکثر ایسا ہوتا ہے کہ ہمیں بوڑھے آقا کے پاس جانا پڑتا ہے، دیکھتے ہیں کہ وہ کتنی دور چلا گیا ہے۔ شاید ٹرانزیکشن لاگ کے حصوں کا معائنہ کریں، دیکھیں کہ وہاں کیا ہے۔ اور یہ سمجھنے کے لیے کہ آیا ہم اس ڈیٹا کو کھو سکتے ہیں یا اس ڈیٹا کو باہر نکالنے کے لیے ہمیں پرانے ماسٹر کو اسٹینڈ اسٹون موڈ میں چلانے کی ضرورت ہے۔

اور اس کے بعد ہی ہمیں یہ فیصلہ کرنا ہوگا کہ آیا ہم اس ڈیٹا کو ضائع کر سکتے ہیں یا ہم اسے بحال کر سکتے ہیں، اس نوڈ کو اپنے کلسٹر سے نقل کے طور پر جوڑ سکتے ہیں۔

اس کے علاوہ، ایک "maximum_lag_on_failover" پیرامیٹر ہے۔ پہلے سے طے شدہ طور پر، اگر میری میموری مجھے کام کرتی ہے، تو اس پیرامیٹر کی قدر 1 میگا بائٹ ہے۔

وہ کیسے کام کرتا ہے؟ اگر ہماری نقل نقل کے وقفے میں ڈیٹا کے 1 میگا بائٹ سے پیچھے ہے، تو یہ نقل انتخابات میں حصہ نہیں لے گی۔ اور اگر اچانک کوئی فائل اوور ہو تو پیٹرونی دیکھتا ہے کہ کون سی نقلیں پیچھے رہ گئی ہیں۔ اگر وہ بڑی تعداد میں ٹرانزیکشن لاگ سے پیچھے ہیں، تو وہ ماسٹر نہیں بن سکتے۔ یہ ایک بہت اچھی حفاظتی خصوصیت ہے جو آپ کو بہت سارے ڈیٹا کو ضائع ہونے سے روکتی ہے۔

لیکن اس میں ایک مسئلہ ہے کہ پیٹرونی کلسٹر اور ڈی سی ایس میں نقل کی وقفے کو ایک خاص وقفے سے اپ ڈیٹ کیا جاتا ہے۔ میرے خیال میں 30 سیکنڈ ڈیفالٹ ٹی ٹی ایل ویلیو ہے۔

اس کے مطابق، ایسی صورت حال ہو سکتی ہے جہاں ڈی سی ایس میں نقل کے لیے ایک نقلی وقفہ ہو، لیکن درحقیقت بالکل مختلف وقفہ ہو سکتا ہے یا بالکل بھی وقفہ نہیں ہو سکتا، یعنی یہ چیز حقیقی وقت میں نہیں ہے۔ اور یہ ہمیشہ حقیقی تصویر کی عکاسی نہیں کرتا۔ اور اس پر فینسی منطق کرنے کے قابل نہیں ہے۔

اور نقصان کا خطرہ ہمیشہ رہتا ہے۔ اور بدترین صورت میں، ایک فارمولہ، اور اوسط صورت میں، دوسرا فارمولا۔ یعنی، جب ہم پیٹرونی کے نفاذ کی منصوبہ بندی کرتے ہیں اور اس بات کا اندازہ لگاتے ہیں کہ ہم کتنا ڈیٹا کھو سکتے ہیں، تو ہمیں ان فارمولوں پر بھروسہ کرنا چاہیے اور تقریباً اندازہ لگانا چاہیے کہ ہم کتنا ڈیٹا کھو سکتے ہیں۔

اور اچھی خبر ہے۔ جب پرانا ماسٹر آگے بڑھ گیا ہے، تو وہ کچھ پس منظر کے عمل کی وجہ سے آگے بڑھ سکتا ہے۔ یعنی، کچھ قسم کا آٹو ویکیوم تھا، اس نے ڈیٹا لکھا، انہیں ٹرانزیکشن لاگ میں محفوظ کیا۔ اور ہم آسانی سے اس ڈیٹا کو نظر انداز کر سکتے ہیں اور کھو سکتے ہیں۔ اس میں کوئی حرج نہیں۔

اور لاگز اس طرح نظر آتے ہیں اگر Max_lag_on_failover سیٹ ہو اور فائلر آ گیا ہو، اور آپ کو ایک نیا ماسٹر منتخب کرنے کی ضرورت ہے۔ نقل خود کو انتخابات میں حصہ لینے کے لیے نااہل قرار دیتی ہے۔ اور وہ لیڈر کی دوڑ میں حصہ لینے سے انکار کر دیتی ہے۔ اور وہ ایک نئے ماسٹر کے منتخب ہونے کا انتظار کرتی ہے، تاکہ وہ اس سے رابطہ کر سکے۔ یہ ڈیٹا کے نقصان کے خلاف ایک اضافی اقدام ہے۔

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

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

ایک ہی وقت میں، ہم پہلے سے جانتے تھے کہ ہمیں ڈسک کے ساتھ مسائل ہیں، یعنی، ہم پہلے سے ہی نگرانی سے جانتے تھے کہ کہاں کھودنا ہے اور کیا تلاش کرنا ہے.

ہم پوسٹگریس لاگ میں داخل ہوئے، یہ دیکھنا شروع کیا کہ وہاں کیا ہو رہا ہے۔ ہم نے کمٹ کو دیکھا جو وہاں ایک، دو، تین سیکنڈ تک رہتا ہے، جو کہ بالکل نارمل نہیں ہے۔ ہم نے دیکھا کہ ہمارا آٹو ویکیوم بہت آہستہ اور عجیب انداز میں شروع ہوتا ہے۔ اور ہم نے ڈسک پر عارضی فائلیں دیکھیں۔ یہ ہے، یہ تمام ڈسک کے ساتھ مسائل کے اشارے ہیں.

ہم نے سسٹم ڈی ایم ایس جی (کرنل لاگ) کو دیکھا۔ اور ہم نے دیکھا کہ ہمیں ایک ڈسک کے ساتھ مسئلہ ہے۔ ڈسک کا سب سسٹم سافٹ ویئر ریڈ تھا۔ ہم نے /proc/mdstat کو دیکھا اور دیکھا کہ ہم ایک ڈرائیو کھو رہے ہیں۔ یعنی، 8 ڈسکوں کا ایک چھاپہ ہے، ہمیں ایک غائب ہے۔ اگر آپ سلائیڈ کو غور سے دیکھیں تو آؤٹ پٹ میں آپ دیکھ سکتے ہیں کہ ہمارے پاس ایس ڈی ای نہیں ہے۔ ہمارے پاس، مشروط طور پر، ڈسک چھوڑ دیا گیا ہے. اس نے ڈسک کے مسائل کو جنم دیا، اور پوسٹگریس کلسٹر کے ساتھ کام کرتے وقت ایپلی کیشنز کو بھی مسائل کا سامنا کرنا پڑا۔

اور اس معاملے میں پیٹرونی ہماری کسی بھی طرح مدد نہیں کرے گا، کیونکہ پیٹرونی کے پاس سرور کی حالت، ڈسک کی حالت کی نگرانی کا کام نہیں ہے۔ اور ہمیں بیرونی نگرانی سے ایسے حالات کی نگرانی کرنی چاہیے۔ ہم نے فوری طور پر بیرونی نگرانی میں ڈسک کی نگرانی کو شامل کیا۔

اور ایسی سوچ تھی - کیا باڑ لگانے یا واچ ڈاگ سافٹ ویئر ہماری مدد کر سکتے ہیں؟ ہم نے سوچا کہ اس نے اس معاملے میں شاید ہی ہماری مدد کی ہوگی، کیونکہ مسائل کے دوران پیٹرونی نے ڈی سی ایس کلسٹر کے ساتھ بات چیت جاری رکھی اور اسے کوئی مسئلہ نظر نہیں آیا۔ یعنی، ڈی سی ایس اور پیٹرونی کے نقطہ نظر سے، کلسٹر کے ساتھ سب کچھ ٹھیک تھا، اگرچہ حقیقت میں ڈسک کے ساتھ مسائل تھے، ڈیٹا بیس کی دستیابی کے ساتھ مسائل تھے.

میری رائے میں، یہ ان عجیب مسائل میں سے ایک ہے جس پر میں نے کافی عرصے سے تحقیق کی ہے، میں نے بہت سارے لاگ پڑھے ہیں، دوبارہ اٹھایا ہے اور اسے کلسٹر سمیلیٹر کہا ہے۔

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

اور یہ سب کیسے شروع ہوا؟ یہ پچھلے مسئلے کی طرح ڈسک بریک کے ساتھ شروع ہوا۔ ہمارے پاس ایک سیکنڈ، دو کے لیے وعدے تھے۔

کنکشن ٹوٹ گئے تھے، یعنی کلائنٹ پھٹے ہوئے تھے۔

مختلف شدت کی رکاوٹیں تھیں۔

اور، اس کے مطابق، ڈسک سب سسٹم بہت ذمہ دار نہیں ہے.

اور میرے لیے سب سے پراسرار چیز فوری طور پر بند کرنے کی درخواست ہے جو پہنچ گئی۔ پوسٹگریس کے تین شٹ ڈاؤن موڈ ہیں:

• جب ہم تمام کلائنٹس کے اپنے طور پر منقطع ہونے کا انتظار کرتے ہیں تو یہ خوش آئند ہے۔
• تیز رفتار ہے جب ہم کلائنٹس کو منقطع ہونے پر مجبور کرتے ہیں کیونکہ ہم بند ہونے جا رہے ہیں۔
• اور فوری۔ اس معاملے میں، فوری کلائنٹس کو بند کرنے کے لیے بھی نہیں کہتا، یہ صرف انتباہ کے بغیر بند ہوجاتا ہے۔ اور تمام کلائنٹس کو، آپریٹنگ سسٹم پہلے سے ہی ایک RST پیغام بھیجتا ہے (ایک TCP پیغام کہ کنکشن میں خلل پڑا ہے اور کلائنٹ کے پاس پکڑنے کے لیے مزید کچھ نہیں ہے)۔

یہ سگنل کس نے بھیجا؟ پوسٹگریس پس منظر کے عمل ایک دوسرے کو ایسے سگنل نہیں بھیجتے ہیں، یعنی یہ kill-9 ہے۔ وہ ایسی چیزیں ایک دوسرے کو نہیں بھیجتے، وہ صرف ایسی چیزوں پر ردعمل ظاہر کرتے ہیں، یعنی یہ پوسٹگریس کا ہنگامی دوبارہ آغاز ہے۔ کس نے بھیجا، مجھے نہیں معلوم۔

میں نے "آخری" کمانڈ کو دیکھا اور میں نے ایک شخص کو دیکھا جس نے اس سرور میں بھی ہمارے ساتھ لاگ ان کیا تھا، لیکن میں سوال پوچھنے میں بہت شرما رہا تھا۔ شاید یہ قتل تھا -9۔ میں نوشتہ جات میں kill -9 دیکھوں گا، کیونکہ پوسٹگریس کا کہنا ہے کہ اس نے قتل -9 لیا، لیکن میں نے اسے لاگز میں نہیں دیکھا۔

مزید دیکھتے ہوئے، میں نے دیکھا کہ پیٹرونی نے لاگ پر کافی عرصے سے نہیں لکھا - 54 سیکنڈ۔ اور اگر ہم دو ٹائم اسٹیمپ کا موازنہ کریں تو تقریباً 54 سیکنڈ تک کوئی پیغامات نہیں تھے۔

اور اس دوران ایک آٹو فائل تھی۔ پیٹرونی نے یہاں ایک بار پھر بہت اچھا کام کیا۔ ہمارے پرانے ماسٹر دستیاب نہیں تھے، انہیں کچھ ہوا. اور نئے آقا کے انتخاب کا آغاز ہوا۔ یہاں سب کچھ اچھی طرح سے کام کیا. ہمارا pgsql01 نیا لیڈر بن گیا ہے۔

ہمارے پاس ایک چربہ ہے جو ماسٹر بن گیا ہے۔ اور دوسرا جواب ہے۔ اور دوسری نقل کے ساتھ مسائل تھے۔ اس نے دوبارہ ترتیب دینے کی کوشش کی۔ جیسا کہ میں اسے سمجھتا ہوں، اس نے recovery.conf کو تبدیل کرنے، پوسٹگریس کو دوبارہ شروع کرنے اور نئے ماسٹر سے جڑنے کی کوشش کی۔ وہ ہر 10 سیکنڈ میں پیغامات لکھتی ہے کہ وہ کوشش کر رہی ہے، لیکن وہ کامیاب نہیں ہو رہی ہے۔

اور ان کوششوں کے دوران، پرانے ماسٹر پر فوری طور پر بند ہونے کا سگنل آتا ہے۔ ماسٹر دوبارہ شروع ہوا ہے۔ اور ریکوری بھی رک جاتی ہے کیونکہ پرانا ماسٹر ریبوٹ میں چلا جاتا ہے۔ یعنی نقل اس سے جڑ نہیں سکتی، کیونکہ یہ شٹ ڈاؤن موڈ میں ہے۔

کسی وقت، اس نے کام کیا، لیکن نقل شروع نہیں ہوئی۔

میرا صرف اندازہ یہ ہے کہ recovery.conf میں ایک پرانا ماسٹر ایڈریس تھا۔ اور جب ایک نیا ماسٹر نمودار ہوا، دوسری نقل نے پھر بھی پرانے ماسٹر سے جڑنے کی کوشش کی۔

جب پیٹرونی نے دوسری نقل شروع کی تو نوڈ شروع ہوا لیکن نقل نہیں کر سکا۔ اور ایک نقلی وقفہ تشکیل دیا گیا تھا، جو کچھ اس طرح نظر آتا تھا۔ یعنی تینوں نوڈ اپنی جگہ پر تھے لیکن دوسرا نوڈ پیچھے رہ گیا۔

اسی وقت، اگر آپ ان لاگز کو دیکھیں جو لکھے گئے تھے، تو آپ دیکھ سکتے ہیں کہ نقل شروع نہیں ہو سکی کیونکہ لین دین کے لاگز مختلف تھے۔ اور وہ ٹرانزیکشن لاگز جو ماسٹر پیش کرتا ہے، جو کہ recovery.conf میں بتائے گئے ہیں، ہمارے موجودہ نوڈ میں فٹ نہیں ہوتے۔

اور یہاں میں نے غلطی کی۔ مجھے اپنے مفروضے کو جانچنے کے لیے recovery.conf میں آکر دیکھنا پڑا کہ ہم غلط ماسٹر سے جڑ رہے ہیں۔ لیکن تب میں صرف اس سے نمٹ رہا تھا اور یہ میرے ذہن میں نہیں آیا، یا میں نے دیکھا کہ نقل پیچھے رہ گئی ہے اور اسے دوبارہ بھرنا پڑے گا، یعنی میں نے کسی طرح لاپرواہی سے کام کیا۔ یہ میرا جوائنٹ تھا۔

30 منٹ کے بعد ایڈمن پہلے ہی آ گیا، یعنی میں نے پیٹرونی کو ریپلیکا پر دوبارہ شروع کیا۔ میں نے اسے پہلے ہی ختم کر دیا ہے، میں نے سوچا کہ اسے دوبارہ بھرنا پڑے گا۔ اور میں نے سوچا - میں پیٹرونی کو دوبارہ شروع کروں گا، شاید کچھ اچھا ہو جائے گا. بحالی شروع ہوگئی۔ اور اڈہ بھی کھل گیا، یہ کنکشن قبول کرنے کے لیے تیار تھا۔

نقل شروع ہو گئی ہے۔ لیکن ایک منٹ بعد، وہ اس غلطی کے ساتھ گر گئی کہ ٹرانزیکشن لاگ ان کے لیے موزوں نہیں ہیں۔

میں نے سوچا کہ میں دوبارہ شروع کروں گا۔ میں نے Patroni کو دوبارہ شروع کیا، اور میں نے Postgres کو دوبارہ شروع نہیں کیا، لیکن Patroni کو اس امید پر دوبارہ شروع کیا کہ یہ جادوئی طور پر ڈیٹا بیس کو شروع کر دے گا۔

نقل دوبارہ شروع ہوئی، لیکن ٹرانزیکشن لاگ میں نشانات مختلف تھے، وہ پچھلی شروعات کی کوشش کی طرح نہیں تھے۔ نقل پھر رک گئی۔ اور پیغام پہلے ہی تھوڑا مختلف تھا۔ اور یہ میرے لیے زیادہ معلوماتی نہیں تھا۔

اور پھر یہ میرے ساتھ ہوتا ہے - اگر میں پوسٹگریس کو دوبارہ شروع کروں تو کیا ہوگا، اس وقت میں موجودہ ماسٹر پر ایک چیک پوائنٹ بناتا ہوں تاکہ ٹرانزیکشن لاگ میں پوائنٹ کو تھوڑا آگے لے جایا جا سکے تاکہ بحالی کسی اور لمحے سے شروع ہو؟ اس کے علاوہ، ہمارے پاس ابھی بھی WAL کا ذخیرہ تھا۔

میں نے پیٹرونی کو دوبارہ شروع کیا، ماسٹر پر چند چیک پوائنٹس کیے، جب یہ کھلا تو ریپلیکا پر دوبارہ اسٹارٹ پوائنٹس کے ایک جوڑے۔ اور اس نے مدد کی۔ میں نے ایک طویل عرصے تک سوچا کہ اس نے کیوں مدد کی اور اس نے کیسے کام کیا۔ اور نقل شروع ہو گئی۔ اور نقل اب پھٹی نہیں تھی۔

میرے لیے اس طرح کا مسئلہ زیادہ پراسرار مسائل میں سے ایک ہے، جس پر میں اب بھی اس بات پر حیران ہوں کہ وہاں واقعی کیا ہوا تھا۔

یہاں کیا مضمرات ہیں؟ Patroni ارادے کے مطابق اور بغیر کسی غلطی کے کام کر سکتا ہے۔ لیکن ایک ہی وقت میں، یہ 100% گارنٹی نہیں ہے کہ ہمارے ساتھ سب کچھ ٹھیک ہے۔ نقل شروع ہو سکتی ہے، لیکن یہ نیم کام کرنے والی حالت میں ہو سکتی ہے، اور ایپلیکیشن ایسی نقل کے ساتھ کام نہیں کر سکتی، کیونکہ پرانا ڈیٹا ہو گا۔

اور فائلر کے بعد، آپ کو ہمیشہ یہ چیک کرنے کی ضرورت ہے کہ کلسٹر کے ساتھ سب کچھ ترتیب میں ہے، یعنی نقل کی مطلوبہ تعداد موجود ہے، نقل میں کوئی وقفہ نہیں ہے۔

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

جب آپ Patroni استعمال کرتے ہیں، تو آپ کی نگرانی ہونی چاہیے۔ آپ کو ہمیشہ معلوم ہونا چاہیے کہ آٹو فائل اوور کب ہوا، کیونکہ اگر آپ نہیں جانتے کہ آپ کے پاس آٹو فائل اوور ہے، تو آپ کا کلسٹر پر کوئی کنٹرول نہیں ہے۔ اور یہ بری بات ہے۔

ہر فائلر کے بعد، ہمیں ہمیشہ دستی طور پر کلسٹر کو چیک کرنا پڑتا ہے۔ ہمیں اس بات کو یقینی بنانے کی ضرورت ہے کہ ہمارے پاس ہمیشہ نقل کی تازہ ترین تعداد موجود ہے، نقل تیار کرنے میں کوئی وقفہ نہیں ہے، پیٹرونی کے ساتھ، DCS سسٹم کے ساتھ، سٹریمنگ ریپلیکیشن سے متعلق لاگز میں کوئی خرابی نہیں ہے۔

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

اور پیٹرونی چاندی کی گولی نہیں ہے۔ ہمیں ابھی بھی یہ سمجھنے کی ضرورت ہے کہ پوسٹگریس کیسے کام کرتا ہے، نقل کیسے کام کرتی ہے اور پیٹرونی پوسٹگریس کے ساتھ کیسے کام کرتی ہے، اور نوڈس کے درمیان بات چیت کیسے فراہم کی جاتی ہے۔ اپنے ہاتھوں سے مسائل کو حل کرنے کے لیے یہ ضروری ہے۔

میں تشخیص کے مسئلے سے کیسے رجوع کروں؟ ایسا ہوا کہ ہم مختلف کلائنٹس کے ساتھ کام کرتے ہیں اور کسی کے پاس ELK اسٹیک نہیں ہے، اور ہمیں 6 کنسولز اور 2 ٹیبز کھول کر لاگز کو ترتیب دینا ہوگا۔ ایک ٹیب میں، یہ ہر نوڈ کے لیے پیٹرونی لاگز ہیں، دوسرے ٹیب میں، یہ قونصل لاگز، یا اگر ضروری ہو تو پوسٹگریس ہیں۔ اس کی تشخیص کرنا بہت مشکل ہے۔

میں نے کیا نقطہ نظر تیار کیا ہے؟ سب سے پہلے، میں ہمیشہ دیکھتا ہوں کہ فائلر کب آیا ہے۔ اور میرے لیے یہ ایک واٹرشیڈ ہے۔ میں دیکھتا ہوں کہ فائلر سے پہلے، فائلر کے دوران اور فائلر کے بعد کیا ہوا۔ فائل اوور کے دو نشان ہیں: یہ آغاز اور اختتام کا وقت ہے۔

اس کے بعد، میں فائلر سے پہلے کے واقعات کے نوشتہ جات میں دیکھتا ہوں، جو فائلر سے پہلے تھا، یعنی میں فائلر کے ہونے کی وجوہات تلاش کرتا ہوں۔

اور اس سے یہ سمجھنے کی تصویر ملتی ہے کہ کیا ہوا اور مستقبل میں کیا کیا جا سکتا ہے تاکہ ایسے حالات پیدا نہ ہوں (اور اس کے نتیجے میں، کوئی فائلر نہیں ہے)۔

اور ہم عام طور پر کہاں دیکھتے ہیں؟ میں دیکھتا ہوں:

• سب سے پہلے، پیٹرونی لاگز پر.
• اگلا، میں پوسٹگریس لاگز، یا ڈی سی ایس لاگز کو دیکھتا ہوں، اس پر منحصر ہے کہ پیٹرونی لاگز میں کیا پایا گیا تھا۔
• اور سسٹم لاگز بھی بعض اوقات اس بات کی سمجھ دیتے ہیں کہ فائلر کی وجہ کیا ہے۔

میں پیٹرونی کے بارے میں کیسا محسوس کرتا ہوں؟ میرے پیٹرونی کے ساتھ بہت اچھے تعلقات ہیں۔ میری رائے میں، یہ آج کا بہترین ہے۔ میں بہت سی دوسری مصنوعات کو جانتا ہوں۔ یہ Stolon، Repmgr، Pg_auto_failover، PAF ہیں۔ 4 ٹولز۔ میں نے ان سب کو آزمایا۔ پیٹرونی میرا پسندیدہ ہے۔

اگر وہ مجھ سے پوچھیں: "کیا میں پیٹرونی کی سفارش کرتا ہوں؟"۔ میں ہاں کہوں گا، کیونکہ مجھے پیٹرونی پسند ہے۔ اور مجھے لگتا ہے کہ میں نے اسے پکانا سیکھ لیا ہے۔

اگر آپ یہ دیکھنے میں دلچسپی رکھتے ہیں کہ پیٹرونی کے ساتھ میں نے جن مسائل کا ذکر کیا ہے اس کے علاوہ اور کیا مسائل ہیں، آپ ہمیشہ صفحہ کو دیکھ سکتے ہیں۔ مسائل GitHub پر۔ وہاں بہت سی مختلف کہانیاں ہیں اور بہت سے دلچسپ مسائل پر بحث کی گئی ہے۔ اور اس کے نتیجے میں، کچھ کیڑے متعارف کرائے گئے اور حل کیے گئے، یعنی یہ ایک دلچسپ پڑھنا ہے۔

لوگوں کے پاؤں میں خود کو گولی مارنے کے بارے میں کچھ دلچسپ کہانیاں ہیں۔ بہت معلوماتی. آپ پڑھ کر سمجھتے ہیں کہ ایسا کرنا ضروری نہیں ہے۔ میں نے خود کو ٹک کیا۔

اور میں اس پروجیکٹ کو تیار کرنے کے لیے Zalando کا بہت شکریہ کہنا چاہوں گا، یعنی الیگزینڈر کوکوشکن اور الیکسی کلوکن کا۔ Aleksey Klyukin شریک مصنفین میں سے ایک ہیں، وہ اب Zalando میں کام نہیں کرتے، لیکن یہ دو لوگ ہیں جنہوں نے اس پروڈکٹ کے ساتھ کام کرنا شروع کیا۔

اور میں سمجھتا ہوں کہ پیٹرونی بہت اچھی چیز ہے۔ میں خوش ہوں کہ وہ موجود ہے، یہ اس کے ساتھ دلچسپ ہے۔ اور تمام تعاون کرنے والوں کا بہت شکریہ جنہوں نے Patroni کو پیچ لکھے۔ مجھے امید ہے کہ پیٹرونی عمر کے ساتھ ساتھ زیادہ بالغ، ٹھنڈا اور کارآمد ہو جائے گا۔ یہ پہلے ہی فعال ہے، لیکن مجھے امید ہے کہ یہ اور بھی بہتر ہو جائے گا۔ لہذا، اگر آپ Patroni استعمال کرنے کا ارادہ رکھتے ہیں، تو گھبرائیں نہیں۔ یہ ایک اچھا حل ہے، اسے لاگو اور استعمال کیا جا سکتا ہے۔

بس۔ اگر آپ کے سوالات ہیں تو پوچھیں۔

آپ کے سوالات

رپورٹ کے لیے شکریہ! اگر فائلر کے بعد بھی آپ کو وہاں بہت غور سے دیکھنے کی ضرورت ہے تو پھر ہمیں خودکار فائلر کی کیا ضرورت ہے؟

کیونکہ یہ نئی چیزیں ہیں۔ ہم صرف ایک سال سے اس کے ساتھ رہے ہیں۔ محفوظ رہنا بہتر ہے۔ ہم اندر آنا چاہتے ہیں اور دیکھنا چاہتے ہیں کہ سب کچھ واقعی اس طرح سے کام کرتا ہے جس طرح ہونا چاہئے۔ یہ بالغوں کے عدم اعتماد کی سطح ہے - یہ بہتر ہے کہ دو بار چیک کریں اور دیکھیں۔

مثال کے طور پر، ہم صبح گئے اور دیکھا، ٹھیک ہے؟

صبح نہیں، ہم عام طور پر آٹو فائل کے بارے میں تقریباً فوراً ہی سیکھ لیتے ہیں۔ ہمیں اطلاعات موصول ہوتی ہیں، ہم دیکھتے ہیں کہ ایک آٹو فائل آ گئی ہے۔ ہم تقریباً فوراً جا کر دیکھتے ہیں۔ لیکن ان تمام چیکوں کو مانیٹرنگ کی سطح پر لایا جانا چاہیے۔ اگر آپ REST API کے ذریعے Patroni تک رسائی حاصل کرتے ہیں، تو ایک تاریخ ہے۔ تاریخ کے مطابق آپ ٹائم اسٹیمپ دیکھ سکتے ہیں کہ فائلر کب ہوا تھا۔ اس کی بنیاد پر نگرانی کی جا سکتی ہے۔ آپ تاریخ دیکھ لیں، کتنے واقعات ہوئے۔ اگر ہمارے پاس مزید واقعات ہیں، تو ایک آٹو فائل واقع ہوئی ہے۔ آپ جا کر دیکھ سکتے ہیں۔ یا ہماری مانیٹرنگ آٹومیشن نے چیک کیا کہ ہمارے پاس تمام نقلیں موجود ہیں، کوئی وقفہ نہیں ہے اور سب کچھ ٹھیک ہے۔

آپ کا شکریہ!

عظیم کہانی کے لئے بہت شکریہ! اگر ہم نے DCS کلسٹر کو پوسٹگریس کلسٹر سے کہیں دور منتقل کیا ہے، تو اس کلسٹر کو بھی وقتاً فوقتاً سروس کرنے کی ضرورت ہے؟ DCS کلسٹر کے کچھ ٹکڑوں کو آف کرنے کے لیے، ان کے ساتھ کچھ کرنے کی ضرورت، وغیرہ کیا بہترین طریقے ہیں؟ یہ سارا ڈھانچہ کیسے زندہ رہتا ہے؟ اور آپ یہ چیزیں کیسے کرتے ہیں؟

ایک کمپنی کے لیے، مسائل کا میٹرکس بنانا ضروری تھا، اگر کسی ایک پرزنٹ یا کئی پرزوں میں ناکام ہو جائے تو کیا ہوتا ہے۔ اس میٹرکس کے مطابق، ہم ترتیب وار تمام اجزاء سے گزرتے ہیں اور ان اجزاء کی ناکامی کی صورت میں منظرنامے بناتے ہیں۔ اس کے مطابق، ہر ناکامی کے منظر نامے کے لیے، آپ بحالی کے لیے ایک ایکشن پلان بنا سکتے ہیں۔ اور DCS کے معاملے میں، یہ معیاری انفراسٹرکچر کے حصے کے طور پر آتا ہے۔ اور ایڈمن اس کا انتظام کرتا ہے، اور ہم پہلے ہی ان ایڈمنز پر بھروسہ کرتے ہیں جو اسے ایڈمنسٹر کرتے ہیں اور حادثات کی صورت میں اسے ٹھیک کرنے کی صلاحیت رکھتے ہیں۔ اگر بالکل بھی کوئی DCS نہیں ہے، تو ہم اسے تعینات کرتے ہیں، لیکن ساتھ ہی ہم اس کی خاص طور پر نگرانی نہیں کرتے، کیونکہ ہم بنیادی ڈھانچے کے ذمہ دار نہیں ہیں، لیکن ہم اس بارے میں سفارشات دیتے ہیں کہ کس طرح اور کس چیز کی نگرانی کی جائے۔

یعنی، کیا میں نے صحیح طور پر سمجھا کہ مجھے میزبانوں کے ساتھ کچھ کرنے سے پہلے پیٹرونی کو غیر فعال، فائلر کو غیر فعال، ہر چیز کو غیر فعال کرنے کی ضرورت ہے؟

یہ اس بات پر منحصر ہے کہ ہمارے پاس DCS کلسٹر میں کتنے نوڈس ہیں۔ اگر بہت سے نوڈس ہیں اور اگر ہم نوڈس میں سے صرف ایک کو غیر فعال کرتے ہیں (نقل)، تو کلسٹر ایک کورم برقرار رکھتا ہے۔ اور Patroni آپریشنل رہتا ہے. اور کچھ بھی متحرک نہیں ہوتا ہے۔ اگر ہمارے پاس کچھ پیچیدہ آپریشن ہیں جو زیادہ نوڈس کو متاثر کرتے ہیں، جن کی عدم موجودگی کورم کو خراب کر سکتی ہے، تو - ہاں، پیٹرونی کو توقف پر رکھنا سمجھ میں آ سکتا ہے۔ اس میں ایک متعلقہ کمانڈ ہے - patronictl pause, patronictl resume۔ ہم صرف توقف کرتے ہیں اور آٹو فائلر اس وقت کام نہیں کرتا ہے۔ ہم DCS کلسٹر پر دیکھ بھال کرتے ہیں، پھر ہم وقفہ ختم کرتے ہیں اور زندہ رہتے ہیں۔

большое большое!

آپ کی رپورٹ کے لئے بہت بہت شکریہ! پروڈکٹ ٹیم ڈیٹا کے ضائع ہونے کے بارے میں کیسا محسوس کرتی ہے؟

پروڈکٹ ٹیموں کو پرواہ نہیں ہے، اور ٹیم لیڈز پریشان ہیں۔

کیا ضمانتیں ہیں؟

ضمانتیں بہت مشکل ہیں۔ الیگزینڈر کوکوشکن کے پاس ایک رپورٹ ہے "آر پی او اور آر ٹی او کا حساب کیسے لگایا جائے"، یعنی ریکوری کا وقت اور ہم کتنا ڈیٹا کھو سکتے ہیں۔ میرے خیال میں ہمیں ان سلائیڈوں کو تلاش کرنے اور ان کا مطالعہ کرنے کی ضرورت ہے۔ جہاں تک مجھے یاد ہے، ان چیزوں کا حساب کتاب کرنے کے مخصوص مراحل ہیں۔ ہم کتنے لین دین کھو سکتے ہیں، کتنا ڈیٹا کھو سکتے ہیں۔ ایک آپشن کے طور پر، ہم پیٹرونی کی سطح پر ہم وقت ساز نقل استعمال کر سکتے ہیں، لیکن یہ ایک دو دھاری تلوار ہے: ہمارے پاس یا تو ڈیٹا قابل اعتماد ہے، یا ہم رفتار کھو دیتے ہیں۔ ہم وقت ساز نقل ہے، لیکن یہ ڈیٹا کے نقصان کے خلاف 100% تحفظ کی ضمانت بھی نہیں دیتا ہے۔

الیکسی، عظیم رپورٹ کے لیے شکریہ! پیٹرونی کو صفر سطح کے تحفظ کے لیے استعمال کرنے کا کوئی تجربہ ہے؟ یہ ہے، ہم وقت ساز یوز کے ساتھ مل کر؟ یہ پہلا سوال ہے۔ اور دوسرا سوال۔ آپ نے مختلف حل استعمال کیے ہیں۔ ہم نے Repmgr استعمال کیا، لیکن آٹو فائلر کے بغیر، اور اب ہم آٹو فائلر کو شامل کرنے کا منصوبہ بنا رہے ہیں۔ اور ہم پیٹرونی کو متبادل حل سمجھتے ہیں۔ آپ Repmgr کے مقابلے میں فوائد کے طور پر کیا کہہ سکتے ہیں؟

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

دوسرے سوال کے بارے میں، ہم نے Repmgr کا استعمال کیا ہے اور اب بھی تاریخی وجوہات کی بنا پر کچھ کلائنٹس کے ساتھ کرتے ہیں۔ کیا کہا جا سکتا ہے؟ Patroni ایک آٹو فائلر آؤٹ آف دی باکس کے ساتھ آتا ہے، Repmgr ایک اضافی خصوصیت کے طور پر آٹو فائلر کے ساتھ آتا ہے جسے فعال کرنے کی ضرورت ہے۔ ہمیں ہر نوڈ پر Repmgr ڈیمون چلانے کی ضرورت ہے اور پھر ہم آٹو فائلر کو کنفیگر کر سکتے ہیں۔

Repmgr چیک کرتا ہے کہ آیا پوسٹگریس نوڈس زندہ ہیں۔ Repmgr عمل ایک دوسرے کے وجود کی جانچ پڑتال کرتے ہیں، یہ بہت موثر طریقہ نہیں ہے۔ نیٹ ورک کی تنہائی کے پیچیدہ معاملات ہو سکتے ہیں جس میں ایک بڑا Repmgr کلسٹر کئی چھوٹے حصوں میں ٹوٹ کر کام جاری رکھ سکتا ہے۔ میں کافی عرصے سے Repmgr کی پیروی نہیں کر رہا ہوں، شاید یہ طے ہو گیا تھا... یا شاید نہیں۔ لیکن DCS میں کلسٹر کی حالت کے بارے میں معلومات کو ہٹانا، جیسا کہ Stolon، Patroni کرتا ہے، سب سے زیادہ قابل عمل آپشن ہے۔

الیکسی، میرے پاس ایک سوال ہے، شاید ایک لنگڑا۔ پہلی مثالوں میں سے ایک میں، آپ نے DCS کو مقامی مشین سے ریموٹ ہوسٹ میں منتقل کیا۔ ہم سمجھتے ہیں کہ نیٹ ورک ایک ایسی چیز ہے جس کی اپنی خصوصیات ہیں، یہ اپنے آپ ہی رہتا ہے۔ اور کیا ہوتا ہے اگر کسی وجہ سے DCS کلسٹر دستیاب نہ ہو جائے؟ میں وجوہات نہیں بتاؤں گا، ان میں سے بہت کچھ ہو سکتا ہے: نیٹ ورکرز کے ٹیڑھے ہاتھوں سے لے کر حقیقی مسائل تک۔

میں نے اسے اونچی آواز میں نہیں کہا، لیکن DCS کلسٹر کو بھی فیل اوور ہونا چاہیے، یعنی کورم پورا کرنے کے لیے یہ نوڈس کی ایک طاق تعداد ہے۔ کیا ہوتا ہے اگر DCS کلسٹر دستیاب نہ ہو، یا کورم پورا نہ ہو سکے، یعنی کسی قسم کا نیٹ ورک اسپلٹ یا نوڈ فیل ہو جائے؟ اس صورت میں، پیٹرونی کلسٹر صرف پڑھنے کے موڈ میں چلا جاتا ہے۔ پیٹرونی کلسٹر اس بات کا تعین نہیں کر سکتا کہ کلسٹر کی حالت اور کیا کرنا ہے۔ یہ DCS سے رابطہ نہیں کر سکتا اور نئی کلسٹر سٹیٹ کو وہاں ذخیرہ نہیں کر سکتا، اس لیے پورا کلسٹر صرف پڑھنے میں چلا جاتا ہے۔ اور یا تو آپریٹر کی طرف سے دستی مداخلت یا DCS کے ٹھیک ہونے کا انتظار کرتا ہے۔

موٹے الفاظ میں، DCS ہمارے لیے ایک خدمت بن جاتی ہے جتنی کہ خود بنیاد؟

ہاں ہاں. بہت ساری جدید کمپنیوں میں، سروس ڈسکوری بنیادی ڈھانچے کا ایک لازمی حصہ ہے۔ بنیادی ڈھانچے میں ڈیٹا بیس سے پہلے بھی اس پر عمل درآمد کیا جا رہا ہے۔ نسبتاً، بنیادی ڈھانچہ شروع کیا گیا، ڈی سی میں تعینات کیا گیا، اور ہمارے پاس فوری طور پر سروس ڈسکوری ہے۔ اگر یہ قونصل ہے، تو اس پر ڈی این ایس بنایا جا سکتا ہے۔ اگر یہ Etcd ہے، تو Kubernetes کلسٹر کا ایک حصہ ہو سکتا ہے، جس میں باقی سب کچھ تعینات کیا جائے گا۔ مجھے ایسا لگتا ہے کہ سروس ڈسکوری پہلے سے ہی جدید انفراسٹرکچر کا ایک لازمی حصہ ہے۔ اور وہ اس کے بارے میں ڈیٹا بیس کے مقابلے میں بہت پہلے سوچتے ہیں۔

آپ کا شکریہ!

ماخذ: www.habr.com