میرا مشورہ ہے کہ آپ 2019 کے آغاز سے آندرے بوروڈن کی رپورٹ کا ٹرانسکرپٹ پڑھیں "WAL-G کے ساتھ بیک اپ۔ 2019 میں کیا ہے؟"
سب کو سلام! میرا نام اینڈری بوروڈن ہے۔ میں Yandex میں ایک ڈویلپر ہوں۔ میں 2016 سے PostgreSQL میں دلچسپی رکھتا ہوں، جب میں نے ڈویلپرز سے بات کی اور انہوں نے کہا کہ سب کچھ آسان ہے - آپ سورس کوڈ لیں اور اسے بنائیں، اور سب کچھ ٹھیک ہو جائے گا۔ اور تب سے میں رک نہیں سکتا - میں ہر طرح کی مختلف چیزیں لکھتا ہوں۔
میں جن چیزوں پر کام کر رہا ہوں ان میں سے ایک بیک اپ سسٹم ہے۔ . عام طور پر، Yandex میں ہم PostgreSQL میں بیک اپ سسٹمز پر کافی عرصے سے کام کر رہے ہیں۔ اور آپ انٹرنیٹ پر چھ رپورٹس کا ایک سلسلہ دیکھ سکتے ہیں کہ ہم کس طرح بیک اپ سسٹم بناتے ہیں۔ اور ہر سال وہ تھوڑا ترقی کرتے ہیں، تھوڑی ترقی کرتے ہیں، اور زیادہ قابل اعتماد بن جاتے ہیں۔
لیکن آج کی رپورٹ صرف اس بارے میں نہیں ہے کہ ہم نے کیا کیا ہے، بلکہ یہ بھی ہے کہ یہ کتنا سادہ ہے اور کیا ہے۔ آپ میں سے کتنے لوگوں نے پہلے ہی WAL-G کے بارے میں میری رپورٹس دیکھی ہیں؟ یہ اچھی بات ہے کہ بہت سے لوگوں نے نہیں دیکھا، کیونکہ میں سب سے آسان چیز سے شروع کروں گا۔
اگر اچانک آپ کے پاس PostgreSQL کلسٹر ہے، اور مجھے لگتا ہے کہ ہر ایک کے پاس ان میں سے ایک جوڑے ہیں، اور اچانک ابھی تک کوئی بیک اپ سسٹم نہیں ہے، تو آپ کو S3 اسٹوریج یا گوگل کلاؤڈ سے مطابقت رکھنے والا اسٹوریج حاصل کرنے کی ضرورت ہے۔
مثال کے طور پر، آپ ہمارے موقف پر آ کر Yandex Object Storage کے لیے ایک پروموشنل کوڈ لے سکتے ہیں، جو S3 سے مطابقت رکھتا ہے۔
پھر ایک بالٹی بنائیں۔ یہ صرف معلومات کے لیے ایک کنٹینر ہے۔
سروس صارف بنائیں۔
سروس صارف کے لیے ایک رسائی کلید بنائیں: aws-s3-key۔
WAL-G کی تازہ ترین مستحکم ریلیز ڈاؤن لوڈ کریں۔
ہماری پری ریلیز ریلیز سے کیسے مختلف ہیں؟ مجھ سے اکثر جلد رہائی کے لیے کہا جاتا ہے۔ اور اگر ورژن میں کافی وقت کے لیے کوئی بگ نہیں ہے، مثال کے طور پر، ایک مہینہ، تو میں اسے جاری کرتا ہوں۔ نومبر سے یہ رہائی یہاں ہے۔ اور اس کا مطلب ہے کہ ہر ماہ ہمیں کسی نہ کسی قسم کا بگ ملا، عام طور پر غیر اہم فعالیت میں، لیکن ہم نے ابھی تک کوئی ریلیز جاری نہیں کیا ہے۔ پچھلا ورژن صرف نومبر کا ہے۔ اس میں ہمیں کوئی کیڑے معلوم نہیں ہیں، یعنی جیسے جیسے پروجیکٹ آگے بڑھتا گیا بگز شامل کر دیے گئے۔
ایک بار جب آپ WAL-G ڈاؤن لوڈ کر لیتے ہیں، تو آپ ماحولیاتی متغیرات میں گزرتے ہوئے ایک سادہ "بیک اپ لسٹ" کمانڈ چلا سکتے ہیں۔ اور یہ آبجیکٹ اسٹوریج سے جڑ جائے گا اور آپ کو بتائے گا کہ آپ کے پاس کون سے بیک اپ ہیں۔ سب سے پہلے، یقینا، آپ کے پاس بیک اپ نہیں ہونا چاہئے. اس سلائیڈ کا مقصد یہ ظاہر کرنا ہے کہ سب کچھ بہت آسان ہے۔ یہ ایک کنسول کمانڈ ہے جو ماحولیاتی متغیرات کو قبول کرتی ہے اور ذیلی کمانڈ پر عمل درآمد کرتی ہے۔
اس کے بعد، آپ اپنا پہلا بیک اپ بنا سکتے ہیں۔ WAL-G میں "backup-push" بولیں اور WAL-G میں اپنے کلسٹر کے pgdata مقام کی وضاحت کریں۔ اور غالباً، PostgreSQL آپ کو بتائے گا، اگر آپ کے پاس پہلے سے بیک اپ سسٹم نہیں ہے، تو آپ کو "آرکائیو موڈ" کو فعال کرنے کی ضرورت ہے۔
اس کا مطلب ہے کہ آپ کو سیٹنگز میں جا کر "archive_mode = on" کو آن کرنے اور "archive_command" کو شامل کرنے کی ضرورت ہے، جو WAL-G میں ایک ذیلی کمانڈ بھی ہے۔ لیکن کسی وجہ سے لوگ اکثر اس موضوع پر بار اسکرپٹ استعمال کرتے ہیں اور اسے WAL-G کے گرد لپیٹ دیتے ہیں۔ پلیز ایسا نہ کریں۔ WAL-G میں پائی جانے والی فعالیت کا استعمال کریں۔ اگر آپ کو کچھ یاد آرہا ہے، تو لکھیں۔ . WAL-G فرض کرتا ہے کہ یہ واحد پروگرام ہے جو archive_command میں چلتا ہے۔
ہم بنیادی طور پر Yandex ڈیٹا بیس کے انتظام میں ایک اعلی دستیابی کلسٹر بنانے کے لیے WAL-G کا استعمال کرتے ہیں۔
اور یہ عام طور پر ایک ماسٹر کی ٹوپولوجی اور متعدد نقلوں میں استعمال ہوتا ہے۔ ایک ہی وقت میں، یہ Yandex آبجیکٹ اسٹوریج میں بیک اپ کاپی بناتا ہے۔
سب سے عام منظرنامے پوائنٹ ان ٹائم ریکوری کا استعمال کرتے ہوئے کلسٹر کی کاپیاں بنا رہے ہیں۔ لیکن اس معاملے میں بیک اپ سسٹم کی کارکردگی ہمارے لیے اتنی اہم نہیں ہے۔ ہمیں صرف بیک اپ سے ایک نیا کلسٹر اپ لوڈ کرنے کی ضرورت ہے۔
عام طور پر، نیا نوڈ شامل کرتے وقت ہمیں بیک اپ سسٹم کی کارکردگی کی ضرورت ہوتی ہے۔ یہ کیوں ضروری ہے؟ عام طور پر لوگ کلسٹر میں ایک نیا نوڈ شامل کرتے ہیں کیونکہ موجودہ کلسٹر پڑھنے کے بوجھ کو نہیں سنبھال سکتا۔ انہیں ایک نئی نقل شامل کرنے کی ضرورت ہے۔ اگر ہم pg_basebackup سے ماسٹر میں لوڈ شامل کرتے ہیں، تو ماسٹر گر سکتا ہے۔ اس لیے ہمارے لیے یہ بہت اہم تھا کہ ہم ماسٹر پر کم سے کم بوجھ پیدا کرتے ہوئے آرکائیو سے ایک نیا نوڈ تیزی سے اپ لوڈ کر سکیں۔
اور اسی طرح کی دوسری صورتحال۔ یہ ڈیٹا سینٹر سے کلسٹر ماسٹر کو تبدیل کرنے کے بعد پرانے ماسٹر کو دوبارہ شروع کرنے کی ضرورت ہے جس کے ساتھ رابطہ منقطع تھا۔
- نتیجے کے طور پر، کاپی سسٹم کے لیے تقاضے وضع کرتے وقت، ہم نے محسوس کیا کہ pg_basebackup کلاؤڈ میں کام کرتے وقت ہمارے لیے موزوں نہیں ہے۔
- ہم اپنے ڈیٹا کو کمپریس کرنے کے قابل ہونا چاہتے تھے۔ لیکن باکس میں آنے والے کے علاوہ تقریباً کوئی بھی بیک اپ سسٹم ڈیٹا کمپریشن فراہم کرے گا۔
- ہم ہر چیز کو متوازی بنانا چاہتے تھے کیونکہ کلاؤڈ میں صارف بڑی تعداد میں پروسیسر کور خریدتا ہے۔ لیکن اگر ہمارے پاس کسی آپریشن میں متوازی نہیں ہے، تو کور کی ایک بڑی تعداد بیکار ہو جاتی ہے۔
- ہمیں خفیہ کاری کی ضرورت ہے کیونکہ اکثر ڈیٹا ہمارا نہیں ہوتا ہے اور واضح متن میں محفوظ نہیں کیا جا سکتا۔ ویسے، WAL-G میں ہمارا تعاون انکرپشن سے شروع ہوا۔ ہم نے WAL-G میں انکرپشن مکمل کر لیا، جس کے بعد ہم سے پوچھا گیا: "شاید ہم میں سے کوئی پروجیکٹ تیار کرے گا؟" اور تب سے میں ایک سال سے زیادہ عرصے سے WAL-G کے ساتھ کام کر رہا ہوں۔
- ہمیں ریسورس تھروٹلنگ کی بھی ضرورت تھی، کیونکہ وقت گزرنے کے ساتھ ساتھ کلاؤڈ کا استعمال کرتے ہوئے، ہمیں پتہ چلا کہ بعض اوقات لوگوں پر رات کے وقت گروسری کا ایک اہم بوجھ ہوتا ہے اور اس بوجھ میں مداخلت نہیں کی جا سکتی۔ اسی لیے ہم نے ریسورس تھروٹلنگ کو شامل کیا۔
- نیز فہرست سازی اور انتظام۔
- اور تصدیق۔
ہم نے بہت سے مختلف ٹولز کو دیکھا۔ خوش قسمتی سے، ہمارے پاس PostgreSQL میں ایک بہت بڑا انتخاب ہے۔ اور ہر جگہ ہم کچھ نہ کچھ کھو رہے تھے، کوئی ایک چھوٹا سا فنکشن، کوئی ایک چھوٹی سی خصوصیت۔
اور موجودہ نظاموں کا جائزہ لینے کے بعد، ہم اس نتیجے پر پہنچے کہ ہم WAL-G تیار کریں گے۔ تب یہ ایک نیا پروجیکٹ تھا۔ بیک اپ سسٹم کے کلاؤڈ انفراسٹرکچر کی طرف ترقی کو متاثر کرنا کافی آسان تھا۔
بنیادی نظریہ جس پر ہم عمل پیرا ہیں وہ یہ ہے کہ WAL-G کو بالائیکا کی طرح سادہ ہونا چاہیے۔
WAL-G کے پاس 4 کمانڈز ہیں۔ یہ:
وال پش - شافٹ کو محفوظ کریں۔
WAL-FETCH - ایک شافٹ حاصل کریں۔
بیک اپ پش - بیک اپ بنائیں۔
BACKUP-FETCH - بیک اپ سسٹم سے بیک اپ حاصل کریں۔
درحقیقت، WAL-G کے پاس ان بیک اپ کا انتظام بھی ہے، یعنی تاریخ میں ریکارڈ اور بیک اپ کی فہرست بنانا اور حذف کرنا جن کی اس وقت ضرورت نہیں ہے۔
ہمارے لیے ایک اہم کام ڈیلٹا کاپیاں بنانا ہے۔
ڈیلٹا کاپیوں کا مطلب ہے کہ ہم پورے کلسٹر کا مکمل بیک اپ نہیں بناتے ہیں بلکہ کلسٹر میں صرف تبدیل شدہ فائلوں کے بدلے ہوئے صفحات بناتے ہیں۔ ایسا لگتا ہے کہ عملی طور پر یہ WAL کا استعمال کرتے ہوئے بازیافت کرنے کی صلاحیت سے بہت ملتا جلتا ہے۔ لیکن ہم متوازی طور پر WAL سنگل تھریڈڈ ڈیلٹا بیک اپ کو رول کر سکتے ہیں۔ اس کے مطابق، جب ہمارے پاس ہفتہ کو ایک بنیادی بیک اپ ہوتا ہے، روزانہ ڈیلٹا بیک اپ ہوتا ہے، اور جمعرات کو ہم ناکام ہوجاتے ہیں، تو ہمیں 4 ڈیلٹا بیک اپ اور 10 گھنٹے WAL کو رول کرنے کی ضرورت ہوتی ہے۔ اس میں تقریباً اتنا ہی وقت لگے گا کیونکہ ڈیلٹا بیک اپ متوازی رول کرتے ہیں۔
LSN پر مبنی ڈیلٹا - اس کا مطلب ہے کہ بیک اپ بناتے وقت، ہمیں ہر صفحہ کو یکجا کرنے اور اس کے LSN کو پچھلے بیک اپ کے LSN کے ساتھ چیک کرنے کی ضرورت ہوگی تاکہ یہ سمجھ سکیں کہ یہ تبدیل ہو گیا ہے۔ کوئی بھی صفحہ جو ممکنہ طور پر تبدیل شدہ ڈیٹا پر مشتمل ہو سکتا ہے ڈیلٹا بیک اپ میں موجود ہونا چاہیے۔
جیسا کہ میں نے کہا، متوازی پر بہت زیادہ توجہ دی گئی۔
لیکن پوسٹگری ایس کیو ایل میں آرکائیو API مستقل ہے۔ PostgreSQL ایک WAL فائل کو محفوظ کرتا ہے اور اسے بحال کرتے وقت ایک WAL فائل کی درخواست کرتا ہے۔ لیکن جب ڈیٹا بیس "WAL-FETCH" کمانڈ کا استعمال کرتے ہوئے ایک WAL فائل کی درخواست کرتا ہے، تو ہم "WAL-PREFETCH" کمانڈ کہتے ہیں، جو اگلی 8 فائلوں کو متوازی طور پر آبجیکٹ اسٹور سے ڈیٹا حاصل کرنے کے لیے تیار کرتی ہے۔
اور جب ڈیٹا بیس ہم سے ایک فائل کو آرکائیو کرنے کے لیے کہتا ہے، تو ہم archive_status کو دیکھتے ہیں اور دیکھتے ہیں کہ کیا دوسری WAL فائلیں موجود ہیں۔ اور ہم متوازی طور پر WAL کو ڈاؤن لوڈ کرنے کی بھی کوشش کر رہے ہیں۔ یہ ایک اہم کارکردگی کا فائدہ فراہم کرتا ہے اور غیر محفوظ شدہ WALs کی تعداد میں فاصلے کو نمایاں طور پر کم کرتا ہے۔ بہت سے بیک اپ سسٹم ڈویلپرز کا خیال ہے کہ یہ اتنا پرخطر سسٹم ہے کیونکہ ہم کوڈ کے انٹرنل کے بارے میں اپنے علم پر بھروسہ کرتے ہیں جو PostgreSQL API نہیں ہے۔ PostgreSQL ہمارے لیے archive_status فولڈر کی موجودگی کی ضمانت نہیں دیتا اور وہاں WAL فائلوں کے لیے ریڈی نیس سگنلز کی سیمنٹکس کی موجودگی کی ضمانت نہیں دیتا۔ اس کے باوجود، ہم سورس کوڈ کا مطالعہ کر رہے ہیں، ہم دیکھتے ہیں کہ ایسا ہے اور ہم اس سے فائدہ اٹھانے کی کوشش کر رہے ہیں۔ اور ہم اس سمت کو کنٹرول کرتے ہیں جس میں PostgreSQL ترقی کر رہا ہے؛ اگر یہ طریقہ کار اچانک ٹوٹ جاتا ہے، تو ہم اسے استعمال کرنا چھوڑ دیں گے۔
اپنی خالص شکل میں، LSN پر مبنی WAL ڈیلٹا کو کسی بھی کلسٹر فائل کو پڑھنے کی ضرورت ہوتی ہے جس کا فائل سسٹم میں موڈ ٹائم پچھلے بیک اپ کے بعد بدل گیا ہو۔ ہم اس کے ساتھ ایک لمبے عرصے تک رہے، تقریباً ایک سال۔ اور آخر میں ہم اس نتیجے پر پہنچے کہ ہمارے پاس وال ڈیلٹا ہے۔
اس کا مطلب یہ ہے کہ جب بھی ہم WAL کو ماسٹر پر آرکائیو کرتے ہیں، ہم نہ صرف اسے کمپریس کرتے ہیں، اسے انکرپٹ کرتے ہیں اور نیٹ ورک کو بھیجتے ہیں، بلکہ ہم اسے اسی وقت پڑھتے ہیں۔ ہم اس میں موجود ریکارڈ کا تجزیہ اور مطالعہ کرتے ہیں۔ ہم سمجھتے ہیں کہ کون سے بلاکس بدل گئے ہیں اور ڈیلٹا فائلیں جمع کرتے ہیں۔
ایک ڈیلٹا فائل WAL فائلوں کی ایک مخصوص رینج کی وضاحت کرتی ہے، اس بارے میں معلومات کی وضاحت کرتی ہے کہ WAL کی اس رینج میں کن بلاکس کو تبدیل کیا گیا تھا۔ اور پھر یہ ڈیلٹا فائلیں بھی محفوظ شدہ ہیں۔
یہاں ہمیں اس حقیقت کا سامنا کرنا پڑتا ہے کہ ہم نے ہر چیز کو بہت تیزی سے متوازی کر دیا، لیکن ہم ایک ترتیب وار تاریخ کو متوازی طور پر نہیں پڑھ سکتے، کیونکہ ایک مخصوص طبقہ میں ہمیں پچھلے WAL ریکارڈ کے اختتام کا سامنا کرنا پڑ سکتا ہے، جس سے ہمارے پاس ابھی تک کوئی رابطہ نہیں ہے، کیونکہ متوازی پڑھنے کی وجہ سے ہم سب سے پہلے مستقبل کا تجزیہ کرتے ہیں، جس کا ابھی ماضی نہیں ہے۔
نتیجے کے طور پر، ہمیں _delta_partial فائلوں میں ناقابل فہم ٹکڑوں کو ڈالنا پڑا۔ نتیجے کے طور پر، جب ہم ماضی کی طرف لوٹتے ہیں، تو ہم WAL ریکارڈ کے ٹکڑوں کو ایک میں چپکائیں گے، اس کے بعد ہم اسے پارس کریں گے اور سمجھیں گے کہ اس میں کیا تبدیلی آئی ہے۔
اگر ہماری شافٹ پارسنگ کی تاریخ میں کم از کم ایک نقطہ ایسا ہے جہاں ہمیں سمجھ نہیں آ رہی ہے کہ کیا ہو رہا ہے، تو، اس کے مطابق، اگلے بیک اپ کے دوران ہم پورے کلسٹر کو دوبارہ پڑھنے پر مجبور ہو جائیں گے، جیسا کہ ہم نے ایک باقاعدہ LSN کے ساتھ کیا تھا۔ پر مبنی ڈیلٹا۔
نتیجے کے طور پر، ہمارے تمام مصائب اس حقیقت کا باعث بنے کہ ہم نے WAL-G پارسنگ لائبریری کو اوپن سورس کیا۔ جہاں تک میں جانتا ہوں، ابھی تک کوئی بھی اسے استعمال نہیں کر رہا ہے، لیکن اگر کوئی اسے لکھنا اور استعمال کرنا چاہتا ہے، تو یہ پبلک ڈومین میں ہے۔ (اپ ڈیٹ کردہ لنک )
نتیجے کے طور پر، تمام معلومات کے بہاؤ کافی پیچیدہ نظر آتے ہیں. ہمارا ماسٹر شافٹ کو محفوظ کرتا ہے اور ڈیلٹا فائلوں کو محفوظ کرتا ہے۔ اور بیک اپ کاپی بنانے والی نقل کو بیک اپ کے درمیان گزرنے والے وقت کے دوران ڈیلٹا فائلیں موصول ہونی چاہئیں۔ اس صورت میں، تاریخ کے حصوں کو بڑی تعداد میں شامل کرنے اور تجزیہ کرنے کی ضرورت ہوگی، کیونکہ پوری تاریخ بڑے حصوں میں فٹ نہیں بیٹھتی ہے۔ اور اس کے بعد ہی نقل مکمل ڈیلٹا بیک اپ کو آرکائیو کر سکتی ہے۔
گراف پر سب کچھ بہت آسان لگتا ہے۔ یہ ہمارے اصلی کلسٹرز میں سے ایک سے ڈاؤن لوڈ ہے۔ ہمارے پاس LSN پر مبنی ہے، جو ایک دن میں بنایا گیا ہے۔ اور ہم دیکھتے ہیں کہ LSN پر مبنی ڈیلٹا بیک اپ صبح تین بجے سے صبح پانچ بجے تک چل رہا تھا۔ یہ پروسیسر کور کی تعداد میں بوجھ ہے۔ WAL-delta نے ہمیں یہاں تقریباً 20 منٹ لگے۔یعنی یہ نمایاں طور پر تیز تر ہو گیا، لیکن ساتھ ہی نیٹ ورک پر زیادہ شدید تبادلہ ہوا۔
چونکہ ہمارے پاس معلومات ہے کہ کون سے بلاکس تبدیل ہوئے اور ڈیٹا بیس کی تاریخ میں کس وقت، ہم نے مزید آگے بڑھ کر فعالیت کو مربوط کرنے کا فیصلہ کیا - ایک PostgreSQL توسیع جسے "pg_prefaulter" کہا جاتا ہے۔
اس کا مطلب ہے کہ جب اسٹینڈ بائی بیس ریسٹور کمانڈ پر عمل کرتا ہے، تو یہ WAL-G کو اگلی WAL فائل لانے کے لیے کہتا ہے۔ ہم تقریباً سمجھتے ہیں کہ مستقبل قریب میں WAL کی بازیابی کا عمل کن ڈیٹا بلاکس تک رسائی حاصل کرے گا اور ان بلاکس پر ریڈ آپریشن شروع کرے گا۔ یہ ایس ایس ڈی کنٹرولرز کی کارکردگی کو بڑھانے کے لیے کیا گیا تھا۔ کیونکہ WAL رول اس صفحہ تک پہنچ جائے گا جسے تبدیل کرنے کی ضرورت ہے۔ یہ صفحہ ڈسک پر ہے اور صفحہ کیشے میں نہیں ہے۔ اور وہ اس صفحہ کے آنے کا ہم وقتی طور پر انتظار کرے گا۔ لیکن اس کے قریب ہی WAL-G ہے، جو جانتا ہے کہ WAL کے اگلے چند سو میگا بائٹس میں ہمیں مخصوص صفحات کی ضرورت ہو گی اور ساتھ ہی انہیں گرم کرنا شروع ہو جائے گا۔ متعدد ڈسک تک رسائی شروع کرتا ہے تاکہ ان کو متوازی طور پر انجام دیا جائے۔ یہ SSD ڈرائیوز پر اچھی طرح کام کرتا ہے، لیکن، بدقسمتی سے، یہ ہارڈ ڈرائیو کے لیے بالکل قابل اطلاق نہیں ہے، کیونکہ ہم صرف اپنے اشارے سے اس میں مداخلت کرتے ہیں۔
یہ وہی ہے جو اب کوڈ میں ہے۔
ایسی خصوصیات ہیں جو ہم شامل کرنا چاہیں گے۔
یہ تصویر ظاہر کرتی ہے کہ WAL-delta نسبتاً کم وقت لیتا ہے۔ اور یہ ان تبدیلیوں کو پڑھ رہا ہے جو دن کے دوران ڈیٹا بیس میں واقع ہوئی ہیں۔ ہم نہ صرف رات کے وقت WAL-delta کر سکتے ہیں، کیونکہ یہ اب بوجھ کا ایک اہم ذریعہ نہیں ہے۔ ہم ہر منٹ WAL-delta پڑھ سکتے ہیں کیونکہ یہ سستا ہے۔ ایک منٹ میں ہم کلسٹر میں ہونے والی تمام تبدیلیوں کو اسکین کر سکتے ہیں۔ اور اسے "انسٹنٹ وال ڈیلٹا" کہا جا سکتا ہے۔
بات یہ ہے کہ جب ہم کلسٹر کو بحال کرتے ہیں، تو ہم کہانیوں کی تعداد کو کم کر دیتے ہیں جنہیں ہمیں ترتیب وار رول اپ کرنا ہوتا ہے۔ یعنی پوسٹگری ایس کیو ایل کے رولز والی WAL کی مقدار کو کم کیا جانا چاہئے، کیونکہ اس میں کافی وقت لگتا ہے۔
لیکن یہ سب کچھ نہیں ہے۔ اگر ہم جانتے ہیں کہ کچھ بلاک کو بیک اپ مستقل مزاجی کے نقطہ پر تبدیل کیا جائے گا، تو ہم اسے ماضی میں تبدیل نہیں کر سکتے۔ یعنی، اب ہمارے پاس WAL-delta فارورڈنگ کی فائل بہ فائل آپٹیمائزیشن ہے۔ اس کا مطلب یہ ہے کہ اگر، مثال کے طور پر، منگل کو کچھ ٹیبل کو مکمل طور پر حذف کر دیا گیا تھا یا کچھ فائلوں کو ٹیبل سے مکمل طور پر حذف کر دیا گیا تھا، پھر جب ڈیلٹا پیر کو رول اوور ہو گا اور ہفتہ کا pg_basebackup بحال ہو جائے گا، تو ہم یہ ڈیٹا بھی نہیں بنائیں گے۔
ہم اس ٹیکنالوجی کو صفحہ کی سطح تک بڑھانا چاہتے ہیں۔ یعنی، اگر فائل کا کچھ حصہ پیر کو تبدیل ہوتا ہے، لیکن بدھ کو اوور رائٹ ہو جائے گا، تو جمعرات کو کسی پوائنٹ پر بحال ہونے پر، ہمیں صفحات کے پہلے چند ورژن کو ڈسک پر لکھنے کی ضرورت نہیں ہے۔
لیکن یہ ابھی تک ایک خیال ہے جو ہمارے اندر فعال طور پر زیر بحث ہے، لیکن یہ ابھی تک ضابطے تک نہیں پہنچا ہے۔
ہم WAL-G میں ایک اور خصوصیت بنانا چاہتے ہیں۔ ہم اسے قابل توسیع بنانا چاہتے ہیں کیونکہ ہمیں مختلف ڈیٹا بیس کو سپورٹ کرنے کی ضرورت ہے اور اسی طرح بیک اپ مینجمنٹ سے رجوع کرنے کے قابل ہونا چاہیں گے۔ لیکن مسئلہ یہ ہے کہ MySQL APIs یکسر مختلف ہیں۔ MySQL میں، PITR جسمانی WAL لاگ پر نہیں، بلکہ binlog پر مبنی ہے۔ اور ہمارے پاس MySQL میں آرکائیونگ سسٹم نہیں ہے جو کسی بیرونی سسٹم کو بتائے کہ یہ بنلاگ ختم ہوچکا ہے اور اسے آرکائیو کرنے کی ضرورت ہے۔ ہمیں ڈیٹا بیس کے ساتھ کرون میں کہیں کھڑے ہونے کی ضرورت ہے اور چیک کرنا ہوگا کہ کیا کچھ تیار ہے؟
اور اسی طرح، مائی ایس کیو ایل کی بحالی کے دوران، کوئی ریسٹور کمانڈ نہیں ہے جو سسٹم کو بتا سکے کہ مجھے فلاں فلاں فائلز کی ضرورت ہے۔ اپنے کلسٹر کو دوبارہ بنانا شروع کرنے سے پہلے، آپ کو یہ جاننا ہوگا کہ آپ کو کن فائلوں کی ضرورت ہوگی۔ آپ کو خود اندازہ لگانے کی ضرورت ہے کہ آپ کو کن فائلوں کی ضرورت ہوگی۔ لیکن ان مسائل کو کسی نہ کسی طرح دور کیا جا سکتا ہے۔ (وضاحت: MySQL پہلے سے ہی تعاون یافتہ ہے)
رپورٹ میں، میں ان معاملات کے بارے میں بھی بات کرنا چاہتا تھا جب WAL-G آپ کے لیے موزوں نہیں ہے۔
اگر آپ کے پاس مطابقت پذیر نقل نہیں ہے، تو WAL-G اس بات کی ضمانت نہیں دیتا کہ آخری سیگمنٹ محفوظ رہے گا۔ اور اگر آرکائیونگ تاریخ کے آخری چند حصوں سے پیچھے رہ جاتی ہے، تو یہ ایک خطرہ ہے۔ اگر کوئی ہم وقت ساز نقل نہیں ہے تو میں WAL-G استعمال کرنے کی سفارش نہیں کروں گا۔ پھر بھی، یہ بنیادی طور پر کلاؤڈ انسٹالیشن کے لیے ڈیزائن کیا گیا ہے، جس کا مطلب ایک مطابقت پذیر نقل کے ساتھ اعلی دستیابی کا حل ہے، جو آخری بائٹس کی حفاظت کے لیے ذمہ دار ہے۔
میں اکثر لوگوں کو ایک ہی وقت میں WAL-G اور WAL-E دونوں کو چلانے کی کوشش کرتے ہوئے دیکھتا ہوں۔ ہم اس لحاظ سے پسماندہ مطابقت کی حمایت کرتے ہیں کہ WAL-G WAL-E سے فائل کو بحال کر سکتا ہے اور WAL-E میں بنایا گیا بیک اپ بحال کر سکتا ہے۔ لیکن چونکہ یہ دونوں سسٹم متوازی وال پش کا استعمال کرتے ہیں، اس لیے وہ ایک دوسرے سے فائلیں چرانا شروع کر دیتے ہیں۔ اگر ہم اسے WAL-G میں ٹھیک کرتے ہیں تو یہ اب بھی WAL-E میں ہی رہے گا۔ WAL-E میں، یہ آرکائیو اسٹیٹس کو دیکھتا ہے، تیار شدہ فائلوں کو دیکھتا ہے اور ان کو محفوظ کرتا ہے، جب کہ دوسرے سسٹمز کو یہ معلوم نہیں ہوگا کہ یہ WAL فائل موجود ہے، کیونکہ PostgreSQL اسے دوسری بار آرکائیو کرنے کی کوشش نہیں کرے گا۔
ہم یہاں WAL-G کی طرف کیا ٹھیک کرنے جا رہے ہیں؟ ہم PostgreSQL کو مطلع نہیں کریں گے کہ یہ فائل متوازی طور پر منتقل کی گئی تھی، اور جب PostgreSQL ہم سے اسے آرکائیو کرنے کے لیے کہے گا، تو ہم پہلے ہی جان لیں گے کہ اس موڈ ٹائم کے ساتھ اور اس md5 کے ساتھ ایسی فائل کو پہلے ہی محفوظ کیا جا چکا ہے اور ہم صرف PostgreSQL کہیں گے - ٹھیک ہے، بنیادی طور پر کچھ کیے بغیر سب کچھ تیار ہے۔
لیکن WAL-E کی طرف سے یہ مسئلہ حل ہونے کا امکان نہیں ہے، اس لیے فی الحال ایک آرکائیو کمانڈ بنانا ناممکن ہے جو فائل کو WAL-G اور WAL-E دونوں میں محفوظ کرے۔
اس کے علاوہ، ایسے معاملات ہیں جہاں WAL-G اب آپ کے لیے موزوں نہیں ہے، لیکن ہم اسے ضرور ٹھیک کر دیں گے۔
سب سے پہلے، ہمارے پاس فی الحال بلٹ ان بیک اپ تصدیق نہیں ہے۔ بیک اپ یا ریکوری کے دوران ہمارے پاس تصدیق نہیں ہوتی ہے۔ یقینا، یہ بادل میں لاگو کیا جاتا ہے. لیکن یہ صرف کلسٹر کو بحال کرکے، پہلے سے چیک کرکے لاگو کیا جاتا ہے۔ میں صارفین کو یہ فعالیت دینا چاہوں گا۔ لیکن تصدیق کے ذریعے، میں فرض کرتا ہوں کہ WAL-G میں کلسٹر کو بحال کرنا اور اسے شروع کرنا، اور اسموک ٹیسٹ چلانا ممکن ہو گا: pg_dumpall to /dev/null اور amcheck انڈیکس کی تصدیق۔
فی الحال WAL-G میں WAL سے بیک اپ کو ملتوی کرنے کا کوئی طریقہ نہیں ہے۔ یعنی ہم کچھ ونڈو کو سپورٹ کرتے ہیں۔ مثال کے طور پر، پچھلے سات دنوں کو اسٹور کرنا، آخری دس بیک اپ کو اسٹور کرنا، آخری تین مکمل بیک اپ کو اسٹور کرنا۔ اکثر لوگ آتے ہیں اور کہتے ہیں: "ہمیں نئے سال پر کیا ہوا اس کا بیک اپ درکار ہے اور ہم اسے ہمیشہ کے لیے رکھنا چاہتے ہیں۔" WAL-G ابھی تک ایسا نہیں کر سکتا۔ (نوٹ - یہ پہلے ہی طے ہوچکا ہے۔ مزید پڑھیں - بیک اپ مارک آپشن )
اور ہمارے پاس PITR کی توثیق کرتے وقت تمام شافٹ سیگمنٹس کے لیے پیج چیکسم اور انٹیگریٹی چیک نہیں ہیں۔
اس سب سے میں نے گوگل سمر آف کوڈ کے لیے ایک پروجیکٹ اکٹھا کیا۔ اگر آپ ایسے ذہین طلباء کو جانتے ہیں جو گو میں کچھ لکھنا چاہتے ہیں اور ایک کمپنی سے "G" کے خط کے ساتھ کئی ہزار ڈالر حاصل کرنا چاہتے ہیں، تو انہیں ہمارے پروجیکٹ کی سفارش کریں۔ میں اس پروجیکٹ کے لیے بطور سرپرست کام کروں گا، وہ یہ کر سکتے ہیں۔ اگر کوئی طالب علم نہیں ہے تو میں اسے لے کر گرمیوں میں خود کروں گا۔
اور ہمارے بہت سے چھوٹے چھوٹے مسائل ہیں جن پر ہم آہستہ آہستہ کام کر رہے ہیں۔ اور کچھ عجیب و غریب چیزیں ہوتی ہیں۔
مثال کے طور پر، اگر آپ WAL-G کو خالی بیک اپ دیتے ہیں، تو یہ آسانی سے گر جائے گا۔ مثال کے طور پر، اگر آپ اسے بتاتے ہیں کہ اسے ایک خالی فولڈر کا بیک اپ لینے کی ضرورت ہے۔ pg_control فائل وہاں نہیں ہوگی۔ اور وہ سوچے گا کہ اسے کچھ سمجھ نہیں آرہا ہے۔ اصولی طور پر، اس معاملے میں آپ کو صارف کو ایک عام پیغام لکھنے کی ضرورت ہے تاکہ اسے سمجھا جا سکے کہ ٹول کو کیسے استعمال کیا جائے۔ لیکن یہ پروگرامنگ کی خصوصیت بھی نہیں ہے، بلکہ ایک اچھی، فہم زبان کی خصوصیت ہے۔
ہم نہیں جانتے کہ آف لائن بیک اپ کیسے کریں۔ اگر ڈیٹا بیس جھوٹ بول رہا ہے، تو ہم اس کا بیک اپ نہیں لے سکتے۔ لیکن یہاں سب کچھ بہت آسان ہے۔ ہم LSN کے شروع ہونے پر بیک اپ کو کال کرتے ہیں۔ بنیادی بنیاد کے LSN کو کنٹرول فائل سے پڑھنا ضروری ہے۔ اور یہ ایسی غیر حقیقی خصوصیت ہے۔ بہت سے بیک اپ سسٹم ایک بنیادی ڈیٹا بیس کا بیک اپ لے سکتے ہیں۔ اور یہ آسان ہے۔
ہم فی الحال بیک اپ کی جگہ کی کمی کو صحیح طریقے سے نہیں سنبھال سکتے۔ کیونکہ ہم عام طور پر گھر پر بڑے بیک اپ کے ساتھ کام کرتے ہیں۔ اور وہ اس کے ارد گرد نہیں ملے. لیکن اگر کوئی ابھی گو میں پروگرام کرنا چاہتا ہے تو بالٹی میں جگہ سے باہر کی غلطیوں کے لیے ہینڈلنگ شامل کریں۔ میں یقینی طور پر پل کی درخواست پر غور کروں گا۔
اور اہم چیز جو ہمیں پریشان کرتی ہے وہ یہ ہے کہ ہم زیادہ سے زیادہ ڈوکر انٹیگریشن ٹیسٹ چاہتے ہیں جو مختلف منظرناموں کو چیک کرتے ہیں۔ ابھی ہم صرف بنیادی منظرناموں کی جانچ کر رہے ہیں۔ ہر کمٹ پر، لیکن ہم ان تمام فعالیتوں کو چیک کرنا چاہتے ہیں جن کی ہم حمایت کرتے ہیں۔ خاص طور پر، مثال کے طور پر، ہمیں PostgreSQL 9.4-9.5 کے لیے کافی تعاون حاصل ہوگا۔ ہم ان کی حمایت کرتے ہیں کیونکہ کمیونٹی PostgreSQL کو سپورٹ کرتی ہے، لیکن ہم اس بات کو یقینی بنانے کے لیے کمٹ بائی کمٹ نہیں چیک کرتے ہیں کہ ہر چیز ٹوٹی نہیں ہے۔ اور مجھے لگتا ہے کہ یہ ایک سنگین خطرہ ہے۔
ہمارے پاس WAL-G Yandex ڈیٹا بیس مینجمنٹ میں ایک ہزار سے زیادہ کلسٹرز پر چل رہا ہے۔ اور یہ ہر روز کئی سو ٹیرا بائٹس ڈیٹا کا بیک اپ لیتا ہے۔
ہمارے پاس اپنے کوڈ میں بہت سارے TODO ہیں۔ اگر آپ پروگرام کرنا چاہتے ہیں تو آئیں، ہم پل کی درخواستوں کے منتظر ہیں، ہم سوالات کے منتظر ہیں۔
آپ کے سوالات
شام بخیر! شکریہ! میرا اندازہ یہ ہے کہ اگر آپ WAL-delta استعمال کر رہے ہیں، تو آپ شاید پورے صفحے کی تحریروں پر بہت زیادہ انحصار کر رہے ہیں۔ اور اگر ایسا ہے تو کیا آپ نے ٹیسٹ چلائے؟ آپ نے خوبصورت گراف دکھایا۔ اگر FPW بند کر دیا جائے تو یہ کتنا خوبصورت ہو جائے گا؟
پورے صفحے کی تحریریں ہمارے لیے فعال ہیں، ہم نے اسے غیر فعال کرنے کی کوشش نہیں کی۔ یعنی میں نے بطور ڈویلپر اسے بند کرنے کی کوشش نہیں کی۔ سسٹم کے منتظمین جنہوں نے تحقیق کی ہے شاید اس مسئلے پر تحقیق کی ہے۔ لیکن ہمیں FPW کی ضرورت ہے۔ تقریباً کوئی بھی اسے غیر فعال نہیں کرتا، کیونکہ دوسری صورت میں نقل سے بیک اپ لینا ناممکن ہے۔
رپورٹ کے لیے شکریہ! میرے دو سوال ہیں۔ پہلا سوال یہ ہے کہ ٹیبل اسپیس کا کیا ہوگا؟
ہم پل کی درخواست کا انتظار کر رہے ہیں۔ ہمارے ڈیٹا بیس SSD اور NMVE ڈسکوں پر رہتے ہیں اور ہمیں واقعی اس خصوصیت کی ضرورت نہیں ہے۔ میں ابھی اسے اچھی طرح سے کرنے پر سنجیدہ وقت گزارنے کے لیے تیار نہیں ہوں۔ میں پورے دل سے وکالت کرتا ہوں کہ ہم اس کی حمایت کرتے ہیں۔ ایسے لوگ ہیں جنہوں نے اس کی حمایت کی، لیکن اس کی حمایت اس طرح کی جو ان کے لیے مناسب ہے۔ انہوں نے ایک کانٹا بنایا، لیکن وہ پل کی درخواستیں نہیں کرتے۔ (ورژن 0.2.13 میں شامل کیا گیا)
اور دوسرا سوال۔ آپ نے بالکل شروع میں کہا کہ WAL-G فرض کرتا ہے کہ یہ اکیلے کام کرتا ہے اور کسی ریپر کی ضرورت نہیں ہے۔ میں خود ریپر استعمال کرتا ہوں۔ انہیں کیوں استعمال نہیں کیا جانا چاہئے؟
ہم چاہتے ہیں کہ یہ بالائیکا کی طرح سادہ ہو۔ اس کا مطلب یہ ہے کہ آپ کو بالائیکا کے علاوہ کسی چیز کی ضرورت نہیں ہے۔ ہم چاہتے ہیں کہ نظام آسان ہو۔ اگر آپ کے پاس ایسی فعالیت ہے جو آپ کو اسکرپٹ میں کرنے کی ضرورت ہے، تو آکر ہمیں بتائیں - ہم اسے گو میں کریں گے۔
شام بخیر! رپورٹ کے لیے شکریہ! ہم WAL-G کو GPG ڈکرپشن کے ساتھ کام کرنے سے قاصر تھے۔ یہ عام طور پر خفیہ کرتا ہے، لیکن ڈکرپٹ نہیں کرنا چاہتا۔ کیا یہ ایسی چیز ہے جو ہمارے لئے کام نہیں کرتی ہے؟ صورتحال افسردہ کن ہے۔
GitHub پر ایک مسئلہ بنائیں اور آئیے اس کا پتہ لگائیں۔
یعنی کیا آپ نے اس کا سامنا نہیں کیا؟
ایرر رپورٹ کی ایک خصوصیت یہ ہے کہ جب WAL-G کو سمجھ نہیں آتی کہ یہ کس قسم کی فائل ہے، تو وہ پوچھتا ہے: "شاید یہ انکرپٹڈ ہے؟" شاید مسئلہ بالکل بھی خفیہ کاری کا نہیں ہے۔ میں اس موضوع پر لاگنگ کو بہتر بنانا چاہتا ہوں۔ اسے سمجھنا چاہیے۔ ہم فی الحال اس موضوع پر اس لحاظ سے کام کر رہے ہیں کہ ہمیں یہ پسند نہیں ہے کہ سرکاری اور نجی چابیاں حاصل کرنے کا نظام کس طرح منظم ہے۔ کیونکہ ہم ایکسٹرنل جی پی جی کو کہتے ہیں تاکہ یہ ہمیں اپنی چابیاں فراہم کرے۔ اور پھر ہم ان کیز کو لے کر اندرونی GPG میں منتقل کرتے ہیں، جو کہ کھلا PGP ہے، جو WAL-G کے اندر ہمارے لیے مرتب کیا گیا ہے، اور وہاں ہم انکرپشن کو کہتے ہیں۔ اس سلسلے میں، ہم سسٹم کو بہتر بنانا چاہتے ہیں اور Libsodium encryption (ورژن 0.2.15 میں شامل) کو سپورٹ کرنا چاہتے ہیں۔ بلاشبہ، ڈی کوڈنگ کام کرے، آئیے اس کا پتہ لگائیں - آپ کو ایک دو الفاظ سے زیادہ علامت کی ضرورت ہے۔ آپ کسی وقت اسپیکر کے کمرے میں جمع ہو کر سسٹم کو دیکھ سکتے ہیں۔ (بیرونی جی پی جی کے بغیر پی جی پی انکرپشن - v0.2.9)
ہیلو! رپورٹ کے لیے شکریہ! میرے دو سوال ہیں۔ مجھے pg_basebackup اور WAL لاگ ان دو پرووائیڈرز کرنے کی عجیب خواہش ہے، یعنی میں ایک کلاؤڈ اور دوسرا کرنا چاہتا ہوں۔ کیا ایسا کرنے کا کوئی طریقہ ہے؟
یہ اب موجود نہیں ہے، لیکن یہ ایک دلچسپ خیال ہے۔
میں صرف ایک فراہم کنندہ پر بھروسہ نہیں کرتا، میں دوسرے میں بھی ایسا ہی رکھنا چاہتا ہوں، صرف اس صورت میں۔
خیال دلچسپ ہے۔ تکنیکی طور پر، اس پر عمل درآمد مشکل نہیں ہے۔ خیال کو ضائع ہونے سے روکنے کے لیے، کیا میں آپ سے گٹ ہب پر مسئلہ بنانے کے لیے کہہ سکتا ہوں؟
ہاں ضرور
اور پھر، جب طلباء گوگل سمر آف کوڈ پر آتے ہیں، تو ہم انہیں پروجیکٹ میں شامل کریں گے تاکہ ان سے مزید فائدہ اٹھانے کے لیے مزید کام ہو۔
اور دوسرا سوال۔ GitHub پر ایک مسئلہ ہے۔ مجھے لگتا ہے کہ یہ پہلے ہی بند ہے۔ بحالی کے دوران ایک گھبراہٹ ہے. اور اسے شکست دینے کے لیے آپ نے الگ اسمبلی بنائی۔ یہ مسائل میں درست ہے۔ اور ایک تھریڈ میں متغیر ماحول کرنے کا آپشن موجود ہے۔ اور یہی وجہ ہے کہ یہ بہت آہستہ کام کرتا ہے۔ اور ہمیں اس مسئلے کا سامنا کرنا پڑا، اور یہ ابھی تک ٹھیک نہیں ہوا ہے۔
مسئلہ یہ ہے کہ کسی وجہ سے سٹوریج (CEPH) کنکشن کو دوبارہ سیٹ کرتا ہے جب ہم اس کے پاس اعلی اتفاق کے ساتھ آتے ہیں۔ اس بارے میں کیا کیا جا سکتا ہے؟ دوبارہ کوشش کرنے کی منطق اس طرح نظر آتی ہے۔ ہم فائل کو دوبارہ ڈاؤن لوڈ کرنے کی کوشش کر رہے ہیں۔ ایک پاس میں، ہمارے پاس بہت سی فائلیں ڈاؤن لوڈ نہیں ہوئیں، ہم ان تمام لوگوں کے لیے دوسری فائل بنائیں گے جنہوں نے لاگ ان نہیں کیا تھا۔ اور جب تک کم از کم ایک فائل فی تکرار لوڈ ہوتی ہے، ہم دہراتے ہیں اور دہراتے ہیں اور دہراتے ہیں۔ ہم نے دوبارہ کوشش کرنے کی منطق کو بہتر بنایا - ایکسپونینشل بیک آف۔ لیکن یہ پوری طرح سے واضح نہیں ہے کہ اس حقیقت کے ساتھ کیا کرنا ہے کہ کنکشن صرف اسٹوریج سسٹم کی طرف سے ٹوٹ جاتا ہے۔ یعنی، جب ہم ایک سٹریم پر اپ لوڈ کرتے ہیں، تو یہ ان رابطوں کو نہیں توڑتا۔ ہم یہاں کیا بہتر کر سکتے ہیں؟ ہمارے پاس نیٹ ورک تھروٹلنگ ہے، ہم ہر کنکشن کو اس کے بھیجے جانے والے بائٹس کی تعداد سے محدود کر سکتے ہیں۔ بصورت دیگر، میں نہیں جانتا کہ اس حقیقت سے کیسے نمٹا جائے کہ آبجیکٹ اسٹوریج ہمیں اس سے متوازی طور پر ڈاؤن لوڈ یا ڈاؤن لوڈ کرنے کی اجازت نہیں دیتا ہے۔
SLA نہیں؟ کیا ان کے لیے یہ نہیں لکھا گیا کہ وہ کس طرح اپنے آپ کو عذاب میں مبتلا کرتے ہیں؟
بات یہ ہے کہ جو لوگ اس سوال کے ساتھ آتے ہیں عام طور پر ان کی اپنی والٹ ہوتی ہے۔ یعنی، کوئی بھی Amazon یا Google Cloud یا Yandex Object Storage سے نہیں آتا ہے۔
شاید سوال اب آپ کے لئے نہیں ہے؟
اس معاملے میں یہاں سوال یہ نہیں ہے کہ کس کو؟ اگر اس سے نمٹنے کے بارے میں کوئی آئیڈیاز ہیں تو آئیے اسے WAL-G میں کرتے ہیں۔ لیکن ابھی تک مجھے اس سے نمٹنے کے بارے میں کوئی اچھا خیال نہیں ہے۔ کچھ آبجیکٹ اسٹوریج ہیں جو بیک اپ کی لسٹنگ کو مختلف طریقے سے سپورٹ کرتے ہیں۔ آپ ان سے اشیاء کی فہرست بنانے کو کہتے ہیں، اور وہ وہاں فولڈر شامل کرتے ہیں۔ WAL-G اس پر ڈر جاتا ہے - یہاں کچھ ایسی چیز ہے جو فائل نہیں ہے، میں اسے بحال نہیں کر سکتا، جس کا مطلب ہے کہ بیک اپ بحال نہیں ہوا تھا۔ یعنی، درحقیقت، آپ کے پاس مکمل طور پر بحال شدہ کلسٹر ہے، لیکن یہ آپ کو ایک غلط حیثیت دیتا ہے کیونکہ آبجیکٹ اسٹوریج نے کچھ عجیب و غریب معلومات واپس کیں جو اسے پوری طرح سمجھ نہیں آئی تھیں۔
یہ ایک ایسی چیز ہے جو میل کلاؤڈ میں ہوتی ہے۔
اگر آپ دوبارہ پیدا کر سکتے ہیں ...
یہ مستقل طور پر دوبارہ تیار کیا جاتا ہے ...
اگر دوبارہ پیدا کرنا ہے، تو مجھے لگتا ہے کہ ہم دوبارہ کوشش کرنے کی حکمت عملیوں کے ساتھ تجربہ کریں گے اور یہ معلوم کریں گے کہ کس طرح دوبارہ کوشش کی جائے اور سمجھیں کہ بادل ہم سے کیا چاہتے ہیں۔ ہو سکتا ہے یہ ہمارے لیے تین کنکشن پر مستحکم ہو اور کنکشن نہ ٹوٹے، پھر ہم احتیاط سے تین تک پہنچ جائیں گے۔ کیونکہ اب ہم بہت تیزی سے کنکشن چھوڑ دیتے ہیں، یعنی اگر ہم 16 تھریڈز کے ساتھ ریکوری شروع کرتے ہیں، تو پہلی بار دوبارہ کوشش کرنے کے بعد 8 تھریڈز، 4 تھریڈز، 2 تھریڈز اور ایک ہو گا۔ اور پھر یہ فائل کو ایک ندی میں کھینچ لے گا۔ اگر کچھ جادوئی اقدار ہیں جیسے 7,5 تھریڈز پمپنگ کے لیے بہترین ہیں، تو ہم ان پر غور کریں گے اور مزید 7,5 تھریڈز بنانے کی کوشش کریں گے۔ یہاں ایک آئیڈیا ہے۔
رپورٹ کے لیے شکریہ! WAL-G کے ساتھ کام کرنے کا مکمل ورک فلو کیسا لگتا ہے؟ مثال کے طور پر، احمقانہ صورت میں جب صفحات پر کوئی ڈیلٹا نہ ہو۔ اور ہم ابتدائی بیک اپ لیتے اور ہٹاتے ہیں، پھر شافٹ کو آرکائیو کرتے ہیں جب تک کہ ہمارا چہرہ نیلا نہ ہو جائے۔ یہاں، جیسا کہ میں سمجھتا ہوں، ایک خرابی ہے۔ کسی وقت آپ کو صفحات کا ڈیلٹا بیک اپ بنانے کی ضرورت ہوتی ہے، یعنی کوئی بیرونی عمل اس کو چلا رہا ہے یا یہ کیسے ہوتا ہے؟
ڈیلٹا بیک اپ API کافی آسان ہے۔ وہاں ایک نمبر ہے - زیادہ سے زیادہ ڈیلٹا اقدامات، اسی کو کہتے ہیں۔ یہ صفر پر طے شدہ ہے۔ اس کا مطلب ہے کہ جب بھی آپ بیک اپ پش کرتے ہیں، یہ مکمل بیک اپ ڈاؤن لوڈ کرتا ہے۔ اگر آپ اسے کسی بھی مثبت نمبر میں تبدیل کرتے ہیں، مثال کے طور پر، 3، تو اگلی بار جب آپ بیک اپ پش کرتے ہیں، تو یہ پچھلے بیک اپ کی تاریخ کو دیکھتا ہے۔ وہ دیکھتا ہے کہ آپ 3 ڈیلٹا کی زنجیر سے تجاوز نہیں کرتے اور ایک ڈیلٹا بناتا ہے۔
یعنی جب بھی ہم WAL-G لانچ کرتے ہیں، یہ مکمل بیک اپ بنانے کی کوشش کرتا ہے؟
نہیں، ہم WAL-G چلاتے ہیں، اور اگر آپ کی پالیسیاں اس کی اجازت دیتی ہیں تو یہ ڈیلٹا بنانے کی کوشش کرتا ہے۔
موٹے الفاظ میں، اگر آپ اسے ہر بار صفر کے ساتھ چلاتے ہیں، تو کیا یہ pg_basebackup کی طرح برتاؤ کرے گا؟
نہیں، یہ اب بھی تیزی سے چلے گا کیونکہ یہ کمپریشن اور متوازی استعمال کرتا ہے۔ Pg_basebackup شافٹ کو آپ کے پاس رکھے گا۔ WAL-G فرض کرتا ہے کہ آپ نے آرکائیو کو کنفیگر کر لیا ہے۔ اور اگر اسے کنفیگر نہیں کیا گیا تو یہ وارننگ جاری کرے گا۔
Pg_basebackup شافٹ کے بغیر چلایا جا سکتا ہے۔
ہاں، پھر وہ تقریباً ایک جیسا سلوک کریں گے۔ Pg_basebackup فائل سسٹم میں کاپی کرتا ہے۔ ویسے، ہمارے پاس ایک نئی خصوصیت ہے جس کا ذکر کرنا بھول گیا ہوں۔ اب ہم pg_basebackup سے فائل سسٹم میں بیک اپ لے سکتے ہیں۔ مجھے نہیں معلوم کہ اس کی ضرورت کیوں ہے، لیکن یہ موجود ہے۔
مثال کے طور پر، CephFS پر۔ ہر کوئی آبجیکٹ اسٹوریج کو کنفیگر نہیں کرنا چاہتا۔
ہاں، شاید اسی لیے انہوں نے اس خصوصیت کے بارے میں ایک سوال پوچھا تاکہ ہم اسے کر سکیں۔ اور ہم نے یہ کیا۔
رپورٹ کے لیے شکریہ! فائل سسٹم میں کاپی کرنے کے بارے میں صرف ایک سوال ہے۔ باکس سے باہر، کیا آپ اب ریموٹ اسٹوریج میں کاپی کرنے کی حمایت کرتے ہیں، مثال کے طور پر، اگر ڈیٹا سینٹر میں کچھ شیلف ہے یا کچھ اور؟
اس فارمولیشن میں، یہ ایک مشکل سوال ہے۔ جی ہاں، ہم حمایت کرتے ہیں، لیکن یہ فعالیت ابھی تک کسی ریلیز میں شامل نہیں ہے۔ یعنی تمام پری ریلیز اس کی حمایت کرتے ہیں، لیکن ریلیز ورژن ایسا نہیں کرتے۔ اس فعالیت کو ورژن 0.2 میں شامل کیا گیا تھا۔ یہ یقینی طور پر جلد ہی جاری کیا جائے گا، جیسے ہی ہم تمام معلوم کیڑے ٹھیک کر لیں گے۔ لیکن ابھی یہ صرف پری ریلیز میں ہی کیا جا سکتا ہے۔ پری ریلیز میں دو کیڑے ہیں۔ WAL-E ریکوری کے ساتھ مسئلہ، ہم نے اسے ٹھیک نہیں کیا ہے۔ اور تازہ ترین پری ریلیز میں ڈیلٹا بیک اپ کے بارے میں ایک بگ شامل کیا گیا تھا۔ لہذا، ہم ہر کسی کو ریلیز ورژن استعمال کرنے کی تجویز کرتے ہیں۔ جیسے ہی پری ریلیز میں مزید بگ نہیں ہیں، ہم کہہ سکتے ہیں کہ ہم گوگل کلاؤڈ، S3 سے مطابقت رکھنے والی چیزوں اور فائل اسٹوریج کو سپورٹ کرتے ہیں۔
ہیلو، رپورٹ کے لئے شکریہ. جیسا کہ میں اسے سمجھتا ہوں، WAL-G کسی قسم کا مرکزی نظام نہیں ہے جیسے بارمین؟ کیا آپ اس سمت میں آگے بڑھنے کا ارادہ رکھتے ہیں؟
مسئلہ یہ ہے کہ ہم اس سمت سے دور ہو گئے ہیں۔ WAL-G بیس ہوسٹ، کلسٹر ہوسٹ، اور کلسٹر میں موجود تمام میزبانوں پر رہتا ہے۔ جب ہم کئی ہزار کلسٹرز میں چلے گئے تو ہمارے پاس بارٹینڈر کی بہت سی تنصیبات تھیں۔ اور جب بھی ان میں کوئی چیز ٹوٹ جاتی ہے تو یہ ایک بڑا مسئلہ ہوتا ہے۔ چونکہ انہیں مرمت کرنے کی ضرورت ہے، آپ کو یہ سمجھنے کی ضرورت ہے کہ اب کن کلسٹرز میں بیک اپ نہیں ہے۔ میں بیک اپ سسٹمز کے لیے فزیکل ہارڈویئر کی سمت میں WAL-G تیار کرنے کا ارادہ نہیں رکھتا۔ اگر کمیونٹی یہاں کچھ فعالیت چاہتی ہے تو مجھے کوئی اعتراض نہیں ہے۔
ہمارے پاس ایسی ٹیمیں ہیں جو ذخیرہ کرنے کی ذمہ دار ہیں۔ اور ہمیں بہت اچھا لگتا ہے کہ یہ ہم نہیں ہیں، خاص لوگ ہیں جو ہماری فائلیں وہیں رکھتے ہیں جہاں فائلیں محفوظ ہیں۔ وہ فائلوں کی ایک مخصوص تعداد کے نقصان کو برداشت کرنے کے لیے وہاں ہر طرح کی ہوشیار کوڈنگ کرتے ہیں۔ وہ نیٹ ورک بینڈوتھ کے ذمہ دار ہیں۔ جب آپ کے پاس بارٹینڈر ہوتا ہے، تو آپ کو اچانک پتہ چل جاتا ہے کہ بہت سارے ٹریفک والے چھوٹے ڈیٹا بیس ایک ہی سرور پر جمع ہو گئے ہیں۔ ایسا لگتا ہے کہ آپ کے پاس اس پر کافی جگہ ہے، لیکن کسی وجہ سے نیٹ ورک کے ذریعے سب کچھ فٹ نہیں ہوتا ہے۔ ہو سکتا ہے اس کا رخ دوسری طرف ہو۔ وہاں بہت سارے نیٹ ورکس ہیں، پروسیسر کور ہیں، لیکن یہاں کوئی ڈسک نہیں ہے۔ اور ہم اس ضرورت سے تنگ آ گئے کہ کچھ ہنگامہ کریں، اور ہم اس حقیقت کی طرف بڑھے کہ ڈیٹا اسٹوریج ایک الگ سروس ہے، جس کے لیے الگ الگ خاص لوگ ذمہ دار ہیں۔
PS ایک نیا ورژن جاری کیا گیا ہے۔ ، جس میں آپ .walg.json کنفیگریشن فائل استعمال کر سکتے ہیں، جو پوسٹگریس ہوم ڈائرکٹری میں بطور ڈیفالٹ موجود ہے۔ آپ bash اسکرپٹس کو ترک کر سکتے ہیں۔ مثال .walg.json اس شمارے میں ہے۔
ویڈیو:
ماخذ: www.habr.com