🥇 ناکامی کے بعد پوسٹگریس ڈیٹا بیس کی بازیافت کا میرا پہلا تجربہ (ریلیٹن بیس/4123007 کے بلاک 16490 میں غلط صفحہ)

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

میں ایک بڑی آئی ٹی کمپنی میں سیمی ڈی اوپس انجینئر کے طور پر کام کرتا ہوں۔ ہماری کمپنی زیادہ بوجھ والی خدمات کے لیے سافٹ ویئر تیار کرتی ہے، اور میں کارکردگی، دیکھ بھال اور تعیناتی کے لیے ذمہ دار ہوں۔ مجھے ایک معیاری کام دیا گیا تھا: ایک سرور پر ایپلیکیشن کو اپ ڈیٹ کرنا۔ ایپلی کیشن Django میں لکھی گئی ہے، اپ ڈیٹ کے دوران ہجرت کی جاتی ہے (ڈیٹا بیس کے ڈھانچے میں تبدیلیاں)، اور اس عمل سے پہلے ہم معیاری pg_dump پروگرام کے ذریعے مکمل ڈیٹا بیس ڈمپ لیتے ہیں، صرف اس صورت میں۔

ڈمپ لینے کے دوران ایک غیر متوقع خرابی پیش آگئی (پوسٹگریس ورژن 9.5):

pg_dump: Oumping the contents of table “ws_log_smevlog” failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989
pg_dump: The command was: COPY public.ws_log_smevlog [...]
pg_dunp: [parallel archtver] a worker process dled unexpectedly

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

بحالی کی تیاری

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

چونکہ ڈیٹا بیس عام طور پر میرے لیے کام کرتا تھا، اس لیے میں نے اپنے آپ کو ایک باقاعدہ ڈیٹا بیس ڈمپ تک محدود رکھا، لیکن خراب ڈیٹا کے ساتھ ٹیبل کو خارج کر دیا (آپشن -T، --exclude-table=TABLE pg_dump میں)۔

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

فائل سسٹم چیک

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

میرے معاملے میں، ڈیٹا بیس کے ساتھ فائل سسٹم نصب تھا۔ "/srv" اور قسم ext4 تھی۔

ڈیٹا بیس کو روکنا: systemctl سٹاپ [ای میل محفوظ] اور چیک کریں کہ فائل سسٹم کسی کے استعمال میں نہیں ہے اور کمانڈ کا استعمال کرکے ان ماؤنٹ کیا جا سکتا ہے۔ lsof:
lsof +D /srv

مجھے ریڈیس ڈیٹا بیس کو بھی روکنا پڑا، کیونکہ یہ بھی استعمال کر رہا تھا۔ "/srv". اگلا میں نے ان ماؤنٹ کیا۔ / ایس آر وی (umount)۔

یوٹیلیٹی کا استعمال کرتے ہوئے فائل سسٹم کو چیک کیا گیا۔ e2fsck سوئچ کے ساتھ -f (جب فائل سسٹم کو صاف نشان زد کیا گیا ہو تب بھی چیکنگ پر مجبور کریں۔):

اگلا، افادیت کا استعمال کرتے ہوئے dumpe2fs (sudo dumpe2fs /dev/mapper/gu2—sys-srv | grep چیک کیا) آپ تصدیق کر سکتے ہیں کہ چیک اصل میں کیا گیا تھا:

e2fsck کہتے ہیں کہ ext4 فائل سسٹم کی سطح پر کوئی مسئلہ نہیں پایا گیا، جس کا مطلب ہے کہ آپ ڈیٹا بیس کو بحال کرنے کی کوشش جاری رکھ سکتے ہیں، یا اس کے بجائے واپس جا سکتے ہیں۔ ویکیوم بھرا ہوا (یقینا، آپ کو فائل سسٹم کو واپس ماؤنٹ کرنے اور ڈیٹا بیس کو شروع کرنے کی ضرورت ہے)۔

اگر آپ کے پاس فزیکل سرور ہے تو، ڈسکوں کی حیثیت کو ضرور چیک کریں (بذریعہ smartctl -a /dev/XXX) یا RAID کنٹرولر یہ یقینی بنانے کے لیے کہ مسئلہ ہارڈ ویئر کی سطح پر نہیں ہے۔ میرے معاملے میں، RAID "ہارڈ ویئر" نکلا، اس لیے میں نے مقامی منتظم سے کہا کہ وہ RAID کا اسٹیٹس چیک کرے (سرور مجھ سے کئی سو کلومیٹر دور تھا)۔ انہوں نے کہا کہ کوئی خرابی نہیں تھی جس کا مطلب ہے کہ ہم بحالی کا کام یقینی طور پر شروع کر سکتے ہیں۔

کوشش 1: صفر_خراب_صفحات

ہم ڈیٹا بیس سے psql کے ذریعے ایک ایسے اکاؤنٹ سے جڑتے ہیں جس کے پاس سپر یوزر کے حقوق ہیں۔ ہمیں ایک سپر یوزر کی ضرورت ہے، کیونکہ... اختیار صفر_خراب_صفحات صرف وہی بدل سکتا ہے۔ میرے معاملے میں یہ پوسٹگریس ہے:

psql -h 127.0.0.1 -U postgres -s [database_name]

آپشن صفر_خراب_صفحات پڑھنے کی غلطیوں کو نظر انداز کرنے کی ضرورت ہے (پوسٹگریسپرو ویب سائٹ سے):

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

ہم آپشن کو فعال کرتے ہیں اور میزوں کا مکمل ویکیوم کرنے کی کوشش کرتے ہیں:

VACUUM FULL VERBOSE

بدقسمتی سے، بدقسمتی.

ہمیں ایک ایسی ہی خرابی کا سامنا کرنا پڑا:

INFO: vacuuming "“public.ws_log_smevlog”
WARNING: invalid page in block 4123007 of relation base/16400/21396989; zeroing out page
ERROR: unexpected chunk number 573 (expected 565) for toast value 21648541 in pg_toast_106070

pg_toast - Poetgres میں "لمبا ڈیٹا" ذخیرہ کرنے کا ایک طریقہ کار اگر یہ ایک صفحہ پر فٹ نہیں ہوتا ہے (8kb بذریعہ ڈیفالٹ)۔

کوشش 2: دوبارہ ترتیب دیں۔

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

reindex table ws_log_smevlog

ری انڈیکس مسائل کے بغیر مکمل.

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

کوشش 3: منتخب کریں، حد کریں، آف سیٹ کریں۔

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

for ((i=0; i<"Number_of_rows_in_nodes"; i++ )); do psql -U "Username" "Database Name" -c "SELECT * FROM nodes LIMIT 1 offset $i" >/dev/null || echo $i; done

میرے معاملے میں، میز پر مشتمل ہے 1 628 991 لائنیں اس کا اچھی طرح خیال رکھنا ضروری تھا۔ ڈیٹا کی تقسیملیکن یہ ایک الگ بحث کا موضوع ہے۔ یہ ہفتہ کا دن تھا، میں نے یہ حکم tmux میں چلایا اور بستر پر چلا گیا:

for ((i=0; i<1628991; i++ )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog LIMIT 1 offset $i" >/dev/null || echo $i; done

صبح تک میں نے یہ دیکھنے کا فیصلہ کیا کہ حالات کیسے چل رہے ہیں۔ میری حیرت میں، میں نے دریافت کیا کہ 20 گھنٹوں کے بعد، صرف 2% ڈیٹا کو اسکین کیا گیا تھا! میں 50 دن انتظار نہیں کرنا چاہتا تھا۔ ایک اور مکمل ناکامی۔

لیکن میں نے ہمت نہیں ہاری۔ میں حیران تھا کہ اسکیننگ میں اتنا وقت کیوں لگا۔ دستاویزات سے (دوبارہ postgrespro پر) مجھے پتہ چلا:

OFFSET آؤٹ پٹ قطاروں کو شروع کرنے سے پہلے قطاروں کی مخصوص تعداد کو چھوڑنے کی وضاحت کرتا ہے۔
اگر OFFSET اور LIMIT دونوں کی وضاحت کی گئی ہے، تو سسٹم پہلے OFFSET قطاروں کو چھوڑ دیتا ہے اور پھر LIMIT کی رکاوٹ کے لیے قطاروں کی گنتی شروع کر دیتا ہے۔

LIMIT استعمال کرتے وقت، ORDER BY شق کا استعمال کرنا بھی ضروری ہے تاکہ نتیجہ کی قطاریں ایک مخصوص ترتیب میں واپس آئیں۔ بصورت دیگر، قطاروں کے غیر متوقع ذیلی سیٹ واپس کر دیے جائیں گے۔

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

کوشش 4: ٹیکسٹ فارم میں ڈمپ لیں۔

تب میرے ذہن میں ایک بظاہر شاندار خیال آیا: متن کی شکل میں ایک ڈمپ لیں اور آخری ریکارڈ شدہ لائن کا تجزیہ کریں۔

لیکن پہلے، آئیے ٹیبل کی ساخت پر ایک نظر ڈالتے ہیں۔ ws_log_smevlog:

ہمارے معاملے میں ہمارے پاس ایک کالم ہے۔ "شناخت"، جس میں قطار کا منفرد شناخت کنندہ (کاؤنٹر) ہوتا ہے۔ منصوبہ کچھ یوں تھا:

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

میں نے ٹیکسٹ فارم میں ڈمپ لینا شروع کیا:

pg_dump -U my_user -d my_database -F p -t ws_log_smevlog -f ./my_dump.dump

ڈمپ، جیسا کہ توقع کی گئی تھی، اسی غلطی کے ساتھ روکا گیا تھا:

pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989

مزید کے ذریعے پونچھ میں نے ڈمپ کے آخر میں دیکھا (دم -5 ./my_dump.dump) نے دریافت کیا کہ id کے ساتھ لائن پر ڈمپ میں خلل پڑا تھا۔ 186 525. "لہذا مسئلہ 186 526 id کے ساتھ ہے، یہ ٹوٹ گیا ہے، اور اسے حذف کرنے کی ضرورت ہے!" - میں نے سوچا. لیکن، ڈیٹا بیس سے استفسار کرنا:
«ws_log_smevlog سے * کو منتخب کریں جہاں id=186529 ہے۔"یہ پتہ چلا کہ اس لائن کے ساتھ سب کچھ ٹھیک تھا... انڈیکس 186 - 530 والی قطاریں بھی بغیر کسی پریشانی کے کام کرتی تھیں۔ ایک اور "شاندار خیال" ناکام ہو گیا۔ بعد میں میں سمجھ گیا کہ ایسا کیوں ہوا: جب کسی ٹیبل سے ڈیٹا کو حذف اور تبدیل کرتے ہیں، تو وہ جسمانی طور پر حذف نہیں ہوتے ہیں، بلکہ "ڈیڈ ٹوپلز" کے طور پر نشان زد ہوتے ہیں، پھر آتا ہے۔ آٹو ویکیوم اور ان لائنوں کو حذف شدہ کے بطور نشان زد کرتا ہے اور ان لائنوں کو دوبارہ استعمال کرنے کی اجازت دیتا ہے۔ سمجھنے کے لیے، اگر ٹیبل میں ڈیٹا تبدیل ہوتا ہے اور آٹو ویکیوم کو فعال کیا جاتا ہے، تو یہ ترتیب وار ذخیرہ نہیں ہوتا ہے۔

کوشش 5: SELECT, FROM, WHERE id=

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

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

اگر کوئی سمجھ نہیں پاتا ہے تو کمانڈ اس طرح کام کرتی ہے: یہ ٹیبل کی قطار کو قطار میں اسکین کرتی ہے اور stdout کو بھیجتی ہے۔ / dev / null، لیکن اگر SELECT کمانڈ ناکام ہوجاتی ہے، تو غلطی کا متن پرنٹ ہوجاتا ہے (stderr کو کنسول پر بھیجا جاتا ہے) اور غلطی پر مشتمل ایک لائن پرنٹ ہوجاتی ہے (بشکریہ ||، جس کا مطلب ہے کہ منتخب کرنے میں دشواری تھی (کمانڈ کا واپسی کوڈ) 0 نہیں ہے)۔

میں خوش قسمت تھا، میں نے میدان میں اشاریہ جات بنائے تھے۔ id:

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

صبح تک میں نے پایا کہ تقریباً 90 اندراجات دیکھے جا چکے ہیں، جو کہ صرف 000% سے زیادہ ہے۔ پچھلے طریقہ (5%) کے مقابلے میں ایک بہترین نتیجہ! لیکن میں 2 دن انتظار نہیں کرنا چاہتا تھا...

کوشش 6: SELECT, FROM, WHERE id >= اور id <

صارف کے پاس ڈیٹا بیس کے لیے وقف ایک بہترین سرور تھا: ڈوئل پروسیسر Intel Xeon E5-2697 v2ہمارے مقام پر 48 تھریڈز تھے! سرور پر لوڈ اوسط تھا؛ ہم بغیر کسی پریشانی کے تقریباً 20 تھریڈز ڈاؤن لوڈ کر سکتے تھے۔ کافی RAM بھی تھی: جتنی 384 گیگا بائٹس!

لہذا، کمانڈ کو متوازی کرنے کی ضرورت ہے:

for ((i=1; i<1628991; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

یہاں ایک خوبصورت اور خوبصورت اسکرپٹ لکھنا ممکن تھا، لیکن میں نے سب سے تیز متوازی طریقہ کا انتخاب کیا: دستی طور پر رینج 0-1628991 کو 100 ریکارڈ کے وقفوں میں تقسیم کریں اور فارم کے 000 کمانڈز کو الگ سے چلائیں۔

for ((i=N; i<M; i=$((i+1)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done

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

for ((i=N; i<M; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

tmux سیشن میں 16 ونڈوز کھولیں اور کمانڈ چلائیں:

1) for ((i=0; i<100000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
2) for ((i=100000; i<200000; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
…
15) for ((i=1400000; i<1500000; i=$((i+1000)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done
16) for ((i=1500000; i<1628991; i=$((i+1000)) )); do psql -U my_user -d my_database  -c "SELECT * FROM ws_log_smevlog where id>=$i and id<$((i+1000))" >/dev/null || echo $i; done

ایک دن بعد میں نے پہلے نتائج حاصل کیے! یعنی (XXX اور ZZZ کی قدریں اب محفوظ نہیں ہیں):

ERROR:  missing chunk number 0 for toast value 37837571 in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value XXX in pg_toast_106070
829000
ERROR:  missing chunk number 0 for toast value ZZZ in pg_toast_106070
146000

اس کا مطلب ہے کہ تین لائنوں میں ایک غلطی ہے۔ پہلے اور دوسرے مسئلے کے ریکارڈز کی id 829 اور 000 کے درمیان تھی، تیسرے کی id 830 اور 000 کے درمیان تھی۔ اس کے بعد، ہمیں صرف مسئلے کے ریکارڈ کی صحیح شناختی قدر تلاش کرنی تھی۔ ایسا کرنے کے لیے، ہم 146 کے مرحلے کے ساتھ مشکل ریکارڈ کے ساتھ اپنی رینج کو دیکھتے ہیں اور آئی ڈی کی شناخت کرتے ہیں:

for ((i=829000; i<830000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number 2 (expected 0) for toast value 37837843 in pg_toast_106070
829449
for ((i=146000; i<147000; i=$((i+1)) )); do psql -U my_user -d my_database -c "SELECT * FROM ws_log_smevlog where id=$i" >/dev/null || echo $i; done
829417
ERROR:  unexpected chunk number ZZZ (expected 0) for toast value XXX in pg_toast_106070
146911

خوشی ختم ہونے والا

ہمیں پریشانی والی لکیریں ملیں۔ ہم psql کے ذریعے ڈیٹا بیس میں جاتے ہیں اور انہیں حذف کرنے کی کوشش کرتے ہیں:

my_database=# delete from ws_log_smevlog where id=829417;
DELETE 1
my_database=# delete from ws_log_smevlog where id=829449;
DELETE 1
my_database=# delete from ws_log_smevlog where id=146911;
DELETE 1

میری حیرت کی بات یہ ہے کہ اندراجات کو بغیر کسی پریشانی کے حذف کردیا گیا یہاں تک کہ آپشن کے بغیر صفر_خراب_صفحات.

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

اعترافات اور نتیجہ

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

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

ماخذ: www.habr.com

ناکامی کے بعد پوسٹگریس ڈیٹا بیس کی بازیافت کا میرا پہلا تجربہ (ریلیٹن بیس/4123007 کے بلاک 16490 میں غلط صفحہ)