MySQL "Table is marked as crashed" خرابی اور phpMyAdmin کے ذریعے جدول کی مرمت

MySQL "Table is marked as crashed" خرابی عام طور پر اس بات کا اشارہ کرتی ہے کہ MyISAM اسٹوریج انجن استعمال کرنے والی ایک جدول خراب ہو گئی ہے اور MySQL کے ذریعے محفوظ طریقے سے نہیں پڑھی جا سکتی۔ تیز ترین حل یہ ہے کہ آپ ڈیٹا بیس کا بیک اپ لینے کے بعد phpMyAdmin کے ذریعے متعلقہ جدول کا انتخاب کریں اور جدول کو مرمت کریں کا عمل شروع کریں۔ لیکن یہ خرابی ہمیشہ صرف ایک کلک سے ختم ہونے والا الرٹ نہیں ہوتا؛ اچانک سرور بند ہونے، ڈسک بھر جانے، غلط سوالات، زیادہ لکھنے کی ٹریفک یا پرانی MySQL کنفیگریشنز کی وجہ سے یہ دوبارہ ہو سکتا ہے۔ اس رہنما میں آپ خرابی کی وجوہات، phpMyAdmin کے ذریعے محفوظ مرمت کے مراحل، عمل سے پہلے بیک اپ چیک، اور مستقل روک تھام کے طریقوں کو مرحلہ وار دیکھیں گے۔

آپ کی ویب سائٹ WordPress، OpenCart، خصوصی PHP سافٹ ویئر یا فورم سسٹم استعمال کر رہی ہو سکتی ہے؛ جب MySQL جدول خراب ہو جاتا ہے تو آپ کے وزیٹر سفید اسکرین، 500 خرابی، کنکشن ٹائم آؤٹ یا ایڈمن پینل میں غیر متوقع ڈیٹا بیس کی خرابی دیکھ سکتے ہیں۔ خاص طور پر ای کامرس کی ویب سائٹس میں اگر آرڈر، مصنوعات، سیشن یا ٹوکری کی جدولوں پر اثر پڑتا ہے تو چند منٹ کی بندش بھی آمدنی کے نقصان کا باعث بن سکتی ہے۔ اس لیے مرمت کے عمل کے دوران نہ صرف ڈیٹا کی حفاظت ضروری ہے بلکہ خرابی کی اصل وجہ کو بھی سمجھنا چاہیے۔ ایک قابل اعتماد ہوسٹنگ انفراسٹرکچر، باقاعدہ بیک اپ اور صحیح ڈیٹا بیس انجن کا انتخاب ایسے خطرات کو کافی حد تک کم کرتا ہے۔ اس نقطے پر قابل انتظام اور قابل نگرانی انفراسٹرکچر کے لیے Hostragons ویب ہوسٹنگ یا زیادہ وسائل کی ضرورت والے منصوبوں میں Hostragons VPS سرور کے اختیارات پر غور کیا جا سکتا ہے۔

Table is marked as crashed خرابی کیا ہے؟

Table is marked as crashed خرابی اس بات کی نشاندہی کرتی ہے کہ MySQL سرور نے ایک جدول کو خراب قرار دیا ہے اور متعلقہ جدول پر پڑھنے یا لکھنے کی کارروائیوں میں مسائل پیش آ رہے ہیں۔ خرابی کا پیغام عموماً درج ذیل شکلوں میں دیکھا جاتا ہے: Table './veritabani/tablo_adi' is marked as crashed and should be repaired یا Incorrect key file for table۔ یہ پیغام اس بات کی نشاندہی کرتا ہے کہ جدول کی فائل میں، انڈیکسز میں یا جدول کی مکملت میں مسئلہ ہے۔

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

خرابی کی سب سے عام وجوہات

جب ایک جدول خراب ہو جائے تو صرف phpMyAdmin کے ذریعے مرمت کرنے کا عمل اکثر کافی نظر آتا ہے لیکن اگر آپ خرابی کی وجہ نہیں جانتے تو وہی مسئلہ دنوں یا گھنٹوں کے اندر دوبارہ ہو سکتا ہے۔ درج ذیل وجوہات وہ منظرنامے ہیں جو تجربے کی بنیاد پر سب سے زیادہ عام ہیں:

• اچانک سرور بند ہونا: بجلی کا کٹنا، ہارڈ ویئر ری سیٹ یا آپریٹنگ سسٹم کا کریش ہوتے وقت اگر MySQL جدول میں لکھ رہا ہو تو جدول خراب ہو سکتا ہے۔
• ڈسک کی جگہ کا بھر جانا: اگر MySQL عارضی فائل، انڈیکس یا جدول کی تازہ کاری نہیں لکھ سکتا تو ڈیٹا کی مکملت متاثر ہو سکتی ہے۔ ڈسک کی استعمال کی فیصد 90 سے اوپر جانے میں خطرہ ہوتا ہے۔
• MySQL سروس کا زبردستی بند کرنا: kill -9 جیسے سخت بندش، خاص طور پر زیادہ لکھنے کے دوران MyISAM جدولوں میں مسائل پیدا کرتا ہے۔
• زیادہ لکھنے کی ٹریفک: لاگ، کاؤنٹر، سیشن یا تلاش کی جدولیں جیسے مستقل اپ ڈیٹ ہونے والی جدولیں اگر MyISAM استعمال کر رہی ہوں تو زیادہ حساس ہوتی ہیں۔
• غلط پلگ ان یا تھیم: WordPress جیسے سسٹمز میں خراب لکھے ہوئے پلگ ان زیادہ سوالات پیدا کر سکتے ہیں اور جدول کی لاکنگ کا سبب بن سکتے ہیں۔
• ہارڈ ویئر یا فائل سسٹم کے مسائل: ڈسک کی خراب سیکٹر، I/O کی خرابی یا خراب فائل سسٹم ڈیٹا بیس کی فائلوں کو متاثر کر سکتے ہیں۔
• پرانی MySQL ورژن: غیر جدید ورژن میں کارکردگی، لاکنگ اور بحالی کے رویے کمزور ہو سکتے ہیں۔

مرمت سے پہلے کے اہم حفاظتی اقدامات

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

1. موجودہ ڈیٹا بیس کا بیک اپ لیں

phpMyAdmin کے ذریعے مرمت شروع کرنے سے پہلے، ڈیٹا بیس کا فوری بیک اپ برآمد کریں۔ اگرچہ جدول خراب ہو چکی ہو، لیکن پڑھی جانے والی معلومات کا بیک اپ لینا اہم ہے۔ phpMyAdmin میں ڈیٹا بیس کا انتخاب کریں، برآمد ٹیب پر کلک کریں، تیز طریقے کے بجائے ممکن ہو تو خصوصی طریقہ منتخب کریں اور SQL فارمیٹ میں بیک اپ لیں۔ بڑے ڈیٹا بیسز میں برآمدی عمل ٹائم آؤٹ ہو سکتا ہے؛ اس صورت میں ہوسٹنگ کنٹرول پینل کے بیک اپ ٹول یا SSH کے ذریعے mysqldump زیادہ مؤثر ہو سکتا ہے۔ باقاعدہ بیک اپ کی پالیسی نہ ہونے والے منصوبوں میں ہوسٹنگ بیک اپ کے حل جیسے وسائل کا جائزہ لینا مفید رہتا ہے۔

2. یہ طے کریں کہ کون سی جدول خراب ہوئی ہے

خرابی کے پیغام میں عام طور پر جدول کا نام موجود ہوتا ہے۔ مثال کے طور پر، WordPress سائٹ میں wp_options، wp_posts، wp_comments یا wp_actionscheduler_actions جدولیں سامنے آ سکتی ہیں۔ خصوصی سافٹ ویئر میں جدول کا نام ایپلیکیشن لاگز، PHP کی خرابی کی روزنامچوں یا MySQL کی خرابی کی لاگ میں دیکھا جا سکتا ہے۔ یہ جاننا کہ کون سی جدول خراب ہوئی ہے، آپ کو تمام ڈیٹا بیس پر غیر ضروری کارروائی کرنے سے روکتا ہے۔

3. سائٹ کو مختصر وقت کے لیے دیکھ بھال کے موڈ میں رکھیں

جب مرمت کی جا رہی ہو تو اگر جدول میں نئی لکھنے کی کارروائی آتی ہے تو عمل ناکام ہو سکتا ہے یا ڈیٹا کی عدم مطابقت ہو سکتی ہے۔ زیادہ ٹریفک والی سائٹس میں 2-5 منٹ کی دیکھ بھال کا موڈ عمل کو زیادہ محفوظ بنا دیتا ہے۔ اگر آپ WordPress استعمال کر رہے ہیں تو دیکھ بھال کے پلگ ان کے ذریعے، اور اگر آپ خصوصی سافٹ ویئر استعمال کر رہے ہیں تو عارضی دیکھ بھال کی صفحہ یا ویب سرور کی ری ڈائریکشن کے ذریعے صارف کی کارروائیوں کو روک سکتے ہیں۔ محفوظ وزیٹر کے تجربے کے لیے دیکھ بھال کے صفحے پر SSL فعال ہونا ضروری ہے؛ اگر آپ کو سرٹیفکیٹ میں مسئلہ ہو رہا ہے تو SSL سرٹیفکیٹ کے اختیارات پر غور کر سکتے ہیں۔

phpMyAdmin کے ذریعے MySQL جدول کی مرمت کیسے کی جائے؟

phpMyAdmin، بغیر تکنیکی کمانڈ لائن کی معلومات کے صارفین کے لیے MySQL جدول کی مرمت کو آسان بناتا ہے۔ درج ذیل مراحل عمومی cPanel، Plesk اور دیگر ہوسٹنگ پینلز میں ملتے جلتے ہیں۔

مرحلہ 1: ہوسٹنگ پینل سے phpMyAdmin میں لاگ ان کریں

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

مرحلہ 2: صحیح ڈیٹا بیس کا انتخاب کریں

بائیں مینو سے اپنی سائٹ کے استعمال کردہ ڈیٹا بیس کا انتخاب کریں۔ WordPress کے لیے، آپ ڈیٹا بیس کا نام wp-config.php فائل میں DB_NAME لائن سے جان سکتے ہیں۔ خصوصی PHP منصوبوں میں، ڈیٹا بیس کا نام عام طور پر config.php، .env یا database.php فائلوں میں ہوتا ہے۔ اگر ایک ہی سرور پر متعدد سائٹس ہیں تو یہ چیک بہت اہم ہے۔

مرحلہ 3: خراب جدول کو نشان زد کریں

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

مرحلہ 4: جدول کو مرمت کرنے کا اختیار چلائیں

جدول کو منتخب کرنے کے بعد، صفحے کے نیچے موجود ڈراپ ڈاؤن مینو سے جدول کو مرمت کریں کا اختیار منتخب کریں۔ phpMyAdmin عام طور پر پس منظر میں REPAIR TABLE جدول_کا_نام کمانڈ چلاتا ہے۔ جب عمل مکمل ہوتا ہے تو آپ کو کامیاب، انتباہی یا ناکام نتیجہ نظر آئے گا۔ کامیاب نتیجہ اکثر status OK کی شکل میں ہوتا ہے۔ بڑے جدولوں میں عمل چند سیکنڈ کے بجائے چند منٹ لے سکتا ہے؛ اس دوران صفحہ کو ریفریش نہ کریں اور براؤزر کو بند نہ کریں۔

مرحلہ 5: جدول کو چیک کریں اور سائٹ کا تجربہ کریں

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

phpMyAdmin مرمت کے اختیارات کا کیا مطلب ہے؟

phpMyAdmin میں صرف مرمت ہی نہیں بلکہ جدول کی دیکھ بھال کے مختلف اختیارات بھی موجود ہیں۔ ہر اختیار کا مقصد مختلف ہوتا ہے؛ اس لیے غلط توقع کے ساتھ استعمال نہیں کیا جانا چاہیے۔

خلاصہ یہ کہ، Table is marked as crashed خرابی کے لیے براہ راست متعلقہ اختیار جدول کو مرمت کریں عمل ہے۔ بہتر بنانا اور تجزیہ کرنا مفید دیکھ بھال کے ٹولز ہیں؛ لیکن یہ خراب جدول کو اکیلے ٹھیک نہیں کر سکتے۔

InnoDB جدولوں میں صورت حال کیوں مختلف ہے؟

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

اگر آپ کا خرابی کا پیغام MyISAM جدول کو دکھاتا ہے تو phpMyAdmin کی مرمت کے امکانات زیادہ تر کامیاب ہوں گے۔ لیکن اگر آپ InnoDB کی طرف سے corrupt، tablespace، cannot open table جیسے پیغامات دیکھ رہے ہیں تو براہ راست مرمت کی کوششوں کے بجائے پہلے بیک اپ لیں اور سرور کے لاگ کا جائزہ لیں۔ اس صورت میں، آپ کے ہوسٹنگ فراہم کنندہ سے مدد طلب کرنا زیادہ محفوظ ہے۔ خاص طور پر اہم ای کامرس کے ڈیٹا میں بے ترتیب کوششیں کرنے کے بجائے پیشہ ورانہ مداخلت کو ترجیح دینا چاہیے۔

اگر مرمت ناکام ہو جائے تو کیا کرنا چاہیے؟

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

• بیک اپ سے بحالی: سب سے محفوظ طریقہ یہ ہے کہ آپ اس تاریخ کے قریب ترین بیک اپ کو بحال کریں جب خرابی واقع نہیں ہوئی تھی۔ بحالی سے پہلے موجود خراب ڈیٹا بیس کو ایک علیحدہ فائل کے طور پر محفوظ کریں۔
• SSH کے ذریعے myisamchk کا استعمال: MyISAM جدولوں کے لیے اگر سرور تک رسائی ہو تو myisamchk ٹول استعمال کیا جا سکتا ہے۔ یہ عمل MySQL سروس کو بند کرکے یا جدول تک رسائی کو روک کر کیا جانا چاہیے۔
• REPAIR TABLE کمانڈ: phpMyAdmin SQL ٹیب سے REPAIR TABLE جدول_کا_نام; کمانڈ چلائی جا سکتی ہے۔ بڑے جدولوں کے لیے QUICK یا EXTENDED اختیارات پر غور کیا جا سکتا ہے۔
• ڈسک اور inode کی جانچ: اگر ڈسک کی جگہ یا inode بھرا ہوا ہے تو مرمت ناکام ہو جائے گی۔ پہلے غیر ضروری بیک اپ، لاگ اور عارضی فائلوں کو صاف کیا جانا چاہیے۔
• سرور کی خرابی کی لاگ کا جائزہ: MySQL error log، ویب سرور لاگ اور PHP error log اصل وجہ کا تعین کرنے کے لیے اہم معلومات فراہم کرتے ہیں۔

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

خرابی کے دوبارہ ہونے سے کیسے بچیں؟

ایک بار کی مرمت، مسئلے کو عارضی طور پر ختم کر دیتی ہے؛ مستقل حل بنیادی ڈھانچے اور دیکھ بھال کی نظم و ضبط ہے۔ درج ذیل احتیاطیں MySQL جدول کی خرابی کے خطرے کو نمایاں طور پر کم کرتی ہیں۔

MyISAM جدولوں کو InnoDB میں تبدیل کرنے پر غور کریں

جدید ویب ایپلیکیشنز میں InnoDB عموماً زیادہ محفوظ اور مستحکم انتخاب ہوتا ہے۔ سطر کی سطح پر لاکنگ، ٹرانزیکشن کی مدد اور کرش کے بعد بحالی کی خصوصیات کی بدولت زیادہ لکھنے کی ٹریفک میں MyISAM کے مقابلے میں فائدہ فراہم کرتا ہے۔ تبدیل کرنے کا عمل سادہ ALTER TABLE جدول_کا_نام ENGINE=InnoDB; کمانڈ کے ذریعے کیا جا سکتا ہے؛ لیکن براہ راست سائٹ پر لاگو کرنے سے پہلے اسے ٹیسٹ ماحول میں ضرور آزمایا جانا چاہیے اور مکمل بیک اپ لیا جانا چاہیے۔ کچھ پرانی سافٹ ویئر مکمل ٹیکسٹ انڈیکس یا خصوصی MyISAM کے رویے پر منحصر ہو سکتے ہیں۔

باقاعدہ اور بحال کے قابل بیک اپ کا استعمال کریں

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

ڈسک کی استعمال اور وسائل کی نگرانی کریں

جب ڈسک کی جگہ 85-90 فیصد کی سطح پر پہنچ جاتی ہے تو ایک الارم پیدا کرنا چاہیے۔ MySQL عارضی جدولوں، لاگ فائلوں اور انڈیکس کے عمل کے لیے خالی جگہ کی ضرورت ہوتی ہے۔ اس کے علاوہ CPU، RAM اور I/O کی انتظار کے اوقات کی باقاعدگی سے نگرانی کی جانی چاہیے۔ مسلسل وسائل کی حد میں پھنسنے والی سائٹ، ڈیٹا بیس کی خرابیوں کے لیے زیادہ حساس ہوتی ہے۔ اگر آپ کی ٹریفک بڑھ گئی ہے تو مشترکہ منصوبے سے زیادہ طاقتور پیکج پر منتقل ہونا سمجھ میں آتا ہے؛ اس بارے میں کاروباری ہوسٹنگ یا اعلی کارکردگی والی ہوسٹنگ صفحات پر غور کیا جا سکتا ہے۔

پلگ ان، تھیم اور سافٹ ویئر کی تازہ کاریوں کو چیک کریں

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

سرور کو صحیح طریقے سے بند کریں اور دیکھ بھال کا منصوبہ بنائیں

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

WordPress سائٹس پر خصوصی نوٹس

WordPress اکثر MySQL کی خرابیوں کو عمومی ڈیٹا بیس کنکشن قائم کرتے وقت خرابی ہوئی کے پیغام کے ساتھ ظاہر کرتا ہے۔ لیکن جب خرابی کے لاگ کو دیکھا جائے تو خراب جدول کی تفصیل نظر آ سکتی ہے۔ WordPress میں اکثر متاثر ہونے والی جدولوں میں wp_options، wp_posts، wp_postmeta، wp_comments اور کچھ پلگ ان کے ذریعے بنائی گئی ٹائمر یا لاگ جدولیں شامل ہیں۔ اگر wp_options جدول خراب ہو جائے تو ویب سائٹ کی عمومی ترتیبات نہیں پڑھی جا سکتی ہیں؛ اگر wp_posts خراب ہو جائے تو مشمولات کی فہرست نہیں ہو سکتی؛ اگر پلگ ان کی لاگ جدولیں خراب ہو جائیں تو ایڈمن پینل سست ہو سکتا ہے۔

WordPress میں ایک بلٹ ان ڈیٹا بیس کی مرمت کی خصوصیت بھی ہے۔ wp-config.php فائل میں عارضی طور پر define('WP_ALLOW_REPAIR', true); لائن شامل کرکے /wp-admin/maint/repair.php ایڈریس سے مرمت چلائی جا سکتی ہے۔ تاہم، عمل مکمل ہونے کے بعد اس لائن کو لازمی طور پر ہٹا دینا چاہیے؛ بصورت دیگر مرمت کا صفحہ غیر مجاز رسائی کے لیے کھلا رہ سکتا ہے۔ phpMyAdmin کا طریقہ عام طور پر زیادہ کنٹرول میں ہوتا ہے کیونکہ آپ براہ راست دیکھ سکتے ہیں کہ آپ کس جدول پر کارروائی کر رہے ہیں۔ اگر آپ WordPress منصوبوں کے لیے بہتر بنایا گیا بنیادی ڈھانچہ تلاش کر رہے ہیں تو ورڈپریس ہوسٹنگ کے وسائل پر نظر ڈال سکتے ہیں۔

آپ کو کب پیشہ ورانہ مدد لینی چاہیے؟

ہر MySQL خرابی اتنی سادہ نہیں ہوتی کہ آپ اسے خود حل کر سکیں۔ اگر نیچے دیے گئے حالات میں سے کوئی ایک ہو تو پیشہ ورانہ مدد لینا زیادہ محفوظ ہے:

• اگر خراب جدول میں آرڈر، ادائیگی، رکنیت یا مالیاتی ڈیٹا ہو۔
• اگر مرمت کی کوشش کے بعد خرابی برقرار رہے یا جدول غائب نظر آئے۔
• اگر ڈیٹا بیس کا سائز چند GB سے زیادہ ہو اور phpMyAdmin ٹائم آؤٹ ہو جائے۔
• اگر InnoDB tablespace یا redo log کی خرابی کی صورت حال ہو۔
• اگر ڈسک کی خرابی، I/O کی خرابی یا فائل سسٹم کی وارننگ ہو۔
• اگر آپ کے پاس حالیہ تاریخ کا صاف بیک اپ نہ ہو۔

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

مختصر چیک لسٹ

ایمرجنسی میں فوری اقدام کرنے کے لیے آپ مندرجہ ذیل ترتیب پر عمل کر سکتے ہیں:

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

اکثر پوچھے جانے والے سوالات

MySQL Table is marked as crashed خرابی کا مطلب کیا ہے؟ کیا یہ ڈیٹا کے نقصان کا باعث بنتا ہے؟

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

phpMyAdmin کے ذریعے جدول کی مرمت کا عمل محفوظ ہے؟

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

InnoDB جدولوں کے لیے کیا مجھے جدول کو مرمت کرنا چاہیے؟

InnoDB جدولیں MyISAM کی طرح روایتی REPAIR TABLE کے اصول کے ساتھ مرمت نہیں کی جاتیں۔ InnoDB کی خرابیوں میں MySQL لاگ کا جائزہ لینا، ڈسک کی حالت کو چیک کرنا اور اگر ضرورت ہو تو بیک اپ سے واپس آنا زیادہ درست طریقہ ہے۔ بے ترتیب مرمت کی کوششیں ڈیٹا کے نقصان کے خطرے کو بڑھا سکتی ہیں۔

یہ خرابی کیوں بار بار ہو رہی ہے؟

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

کیا مجھے مرمت کرنے سے پہلے اپنے ہوسٹنگ کمپنی سے رابطہ کرنا چاہیے؟

سادہ MyISAM جدول کی خرابیوں میں آپ بیک اپ لے کر phpMyAdmin کے ذریعے مرمت کر سکتے ہیں۔ لیکن اگر جدول میں اہم ڈیٹا ہو، آپ کے پاس بیک اپ نہ ہو، ڈیٹا بیس بہت بڑا ہو، یا آپ InnoDB کی خرابیوں کا سامنا کر رہے ہوں تو ہوسٹنگ سپورٹ ٹیم سے رابطہ کرنا زیادہ محفوظ ہے۔

نتیجہ

MySQL "Table is marked as crashed" خرابی خاص طور پر MyISAM جدولوں میں دیکھی جاتی ہے اور زیادہ تر صورتوں میں phpMyAdmin کے ذریعے حل کی جا سکتی ہے۔ درست طریقہ یہ ہے کہ پہلے بیک اپ لیں، خراب جدول کی نشاندہی کریں، phpMyAdmin کے ذریعے مرمت کریں اور پھر خرابی کی وجہ کو ختم کریں۔ باقاعدہ بیک اپ، مناسب سرور کی وسائل، InnoDB کا استعمال اور جدید سافٹ ویئر بنیادی ڈھانچہ اس مسئلے کے دوبارہ ہونے کے امکانات کو کم کرتے ہیں۔ اگر آپ کی ویب سائٹ پر ایسے ہی خرابیوں کا سامنا بار بار ہو رہا ہے تو آپ اپنے بنیادی ڈھانچے کا جائزہ لے سکتے ہیں اور اپنی ضروریات کے مطابق ہوسٹنگ کے حل پر غور کرنے کے لیے Hostragons کے وسائل کو دیکھ سکتے ہیں یا سپورٹ ٹیم سے گائیڈنس حاصل کر سکتے ہیں۔