it-swarm.asia

كيف تعرّف فساد جدول InnoDB؟

لدي بعض الجداول التي تم تقسيمها ولديها العديد من الفهارس على عبد منسوخ. بعد نسخ اللقطة الإضافية (تم التحقق منها بأمان) إلى عبد جديد وترقية mysqld من 5.1.42 إلى 5.5.15 وإعادة تشغيل النسخ المتماثل ، أتلقى تعطل InnoDB برسالة الخطأ "مؤشر غير صالح ..."

حدثت هذه الأخطاء عبر خادمين مع أجهزة مختلفة و O/S. بعد تشغيل:

ALTER TABLE .... COALESCE PARTION n;

المشكلة تختفي لهذا الجدول.

سؤالي أكبر من ذلك ، وهو "كيف يمكنك تحديد فساد جدول InnoDB؟" أو أعيدت صياغته "كيف تقيم صحة جدول InnoDB؟" هل "CHECK TABLE" الأداة الوحيدة المتاحة لتحديد المشاكل قبل التعطل؟

لست متأكدًا مما إذا كان ذلك مهمًا ، ولكن حدث الأعطال قيد التشغيل: الإصدار: مقبس "5.5.15-55-log": منفذ /opt/mysql.sock ": 3306 خادم بيركونا (GPL) ، الإصدار rel21.0 ، المراجعة 158

24
randomx

Morgan يعطي تلميحًا في تعليقه بأن InnoDB يتحقق باستمرار من الصفحات التالفة عن طريق إجراء عمليات فحص على الصفحات التي يقرأها. إذا وجد InnoDB عدم تطابق المجموع الاختباري ، فسيحدث ذلك يصطدم إيقاف الخادم.

إذا كنت تريد تسريع هذه العملية (بدلاً من انتظار InnoDB لقراءة الصفحة التالفة) ، يمكنك استخدام innochecksum :

نظرًا لأن عدم تطابق المجموع الاختباري سيؤدي إلى إغلاق InnoDB عن عمد خادم قيد التشغيل ، فقد يكون من الأفضل استخدام هذه الأداة بدلاً من انتظار الخادم في استخدام الإنتاج لمواجهة الصفحات التالفة.

تحذير مثير للاهتمام:

لا يمكن استخدام innochecksum على ملفات مساحة الجداول التي فتحها الخادم بالفعل. لمثل هذه الملفات ، يجب عليك استخدام جدول التحقق للتحقق من الجداول داخل مساحة الجدول.

لذا ، نعم ، بالنسبة لجدول عبر الإنترنت CHECK TABLE هو على الأرجح الأداة (أو كما هو موضح في إجابة أخرىmysqlcheck إذا كنت تريد القيام بأكثر من قاعدة بيانات واحدة في زمن.)

إذا كان بإمكانك إغلاق قاعدة البيانات الخاصة بك ، يمكنك فرضها على المجموع الاختباري باستخدام innochecksum

القصص القصصية: على مساحة داخلية بحجم 29 جيجا بايت (مع innodb_file_per_table=1) ، استغرق هذا البرنامج النصي حوالي دقيقتين

#!/bin/bash
for i in $(ls /var/lib/mysql/*/*.ibd)
do
  innochecksum -v $i
done

كمكافأة ، على الرغم من ذلك ، نظرًا لأنك تقوم بتشغيل Percona ، فقد قاموا بتطبيق طريقة جديدة لـ المجموع الاختباري السريع للداخل . لم أستخدمه أبدًا ، ولكنه قد يسرع العملية.

18
Derek Downey

تحذير: قبل تجربة أي من هذه التعليمات ، يوصى بشدة بالتحقق من وجود نسخة احتياطية صحية لقاعدة البيانات الخاصة بك ، في حالة حدوث ذلك. (بفضلNick للتحذير)

حاول استخدام الأمر mysqlcheck. على المحطة:

mysqlcheck -u username -p --databases database1 database2

سيخرج هذا الأمر قائمة بجميع الجداول وحالة تخبرك إذا كان هناك نوع من الفساد:

table1  OK
table2  OK
table3  OK
tableN  OK

مع ذلك في يدك سوف تعرف بالفعل الجداول التي يجب إصلاحها. فقط إذا كنت تريد إصلاح كل شيء دفعة واحدة:

mysqlcheck -u username -p --auto-repair --databases database1 database2 

المزيد عن mysqlcheck: http://dev.mysql.com/doc/refman/5.0/en/mysqlcheck.html

ملاحظة: لقد قمت بوضع علامة على سؤالك بـ percona . لم يكن لدي أي فكرة عما كان ذلك ، لذلك كنت غوغل. يبدو أنها شوكة من MySQL ، ولكن ليس لدي أي سبب للاعتقاد بأن الأوامر غير متوافقة (تقاطع الأصابع).


أشارني شخص ما إلى هذا الدليل الذي يحتوي على تعليمات أكثر تحديدًا لاستعادة قاعدة بيانات InnoDB في المواقف الأكثر خطورة حيث لا تبدأ قاعدة البيانات بأكملها: http://www.softwareprojects.com/resources/programming/t-how-to -fix-mysql-database-myisam-innodb-1634.html

6
marcio

وفقًا لـ دليل دراسة شهادة MySQL 5.0 ، الصفحة 443،444 القسم 30.4 :

يمكنك التحقق من جداول InnoDB باستخدام الأمر CHABLE TABLE أو باستخدام برنامج عميل لإصدار البيان نيابة عنك. ومع ذلك ، إذا واجه جدول InnoDB مشاكل ، فلا يمكنك إصلاحه باستخدام جدول الإصلاح لأن هذا البيان ينطبق فقط على MyISAM.

إذا كان فحص الجدول يشير إلى وجود مشاكل في جدول InnoDB ، فيجب أن تكون قادرًا على استعادة الجدول إلى حالة متناسقة عن طريق تفريغه باستخدام mysqldump وإسقاطه وإعادة إنشائه من هذا التفريغ.

في حالة تعطل خادم MySQL أو على المضيف الذي يعمل عليه ، قد تحتاج بعض جداول InnoDB إلى إصلاحات. عادة ما يكفي إعادة تشغيل الخادم لأن محرك تخزين InnoDB يقوم بالاسترداد التلقائي كجزء من تسلسل بدء التشغيل. في حالات نادرة ، قد لا يبدأ تشغيل الخادم بسبب فشل InnoDB في الاسترداد التلقائي. إذا حدث ذلك ، استخدم الإجراء التالي:

  • أعد تشغيل الخادم مع تعيين الخيار --innodb_force_recovery على قيمة في الغضب من 1 إلى 6. تشير هذه القيم إلى زيادة مستويات الحذر في تجنب التعطل ، وزيادة مستويات التسامح لاحتمال عدم الاتساق في الجداول المستردة. قيمة جيدة لتبدأ بها هي 4.

  • عند بدء تشغيل الخادم مع تعيين --innodb_force_recovery على قيمة غير صفرية ، يتعامل InnoDB مع مساحة الجدول على أنها للقراءة فقط. وبالتالي ، يجب تفريغ جداول InnoDB باستخدام mysqldump ثم إسقاطها أثناء تفعيل الخيار. ثم أعد تشغيل الخادم بدون خيار --innodb_force_recovery. عندما يأتي الخادم ، قم باستعادة جداول InnoDB من ملفات التفريغ.

  • إذا فشلت الخطوات السابقة ، فمن الضروري استعادة جداول InnoDB من نسخة احتياطية سابقة.

يرجى قراءة MySQL Docs على InnoDB Forced Recovery

6
RolandoMySQLDBA

أتساءل ماذا يحدث إذا كان أي شخص يستخدم بيانات InnoDB التي تم إنشاؤها عبر InnoDB Plugin ثم انتقل إلى إصدار آخر من InnoDB. يمكن أن يخلق ذلك تلفًا محتملاً في الصفحة في عيون الخلية.

لاحظ ما يقوله وثائق MySQL على تنسيق ملف InnoDB حول هذا الاحتمال:

بشكل عام ، قد يؤدي إصدار أحدث من InnoDB إلى إنشاء جدول أو فهرس لا يمكن قراءته أو كتابته بأمان باستخدام إصدار سابق من InnoDB دون التعرض لخطر حدوث أعطال أو تعليق أو نتائج خاطئة أو تلف. يقدم InnoDB Plugin آلية جديدة للحماية من هذه الظروف وللمساعدة في الحفاظ على التوافق بين ملفات قاعدة البيانات وإصدارات InnoDB.

كنت ألغي البيانات على العبد. في الواقع ، أود فقط استخدام القوة الغاشمة عن طريق الحصول على تفريغ منطقي (mysqldump) للبيانات:

  • إسقاط جميع قواعد البيانات باستخدام InnoDB على الرقيق
  • اغلاق الخلية على العبد
  • احذف ibdata1 و ib_logfile0 و ib_logfile1 على الرقيق
  • ابدأ mysql على الرقيق ، مع السماح بإعادة إنشاء ibdata1 و ib_logfile0 و ib_logfile1
  • mysqldump البيانات من السيد إلى العبد

تعتبر إجابتي الأصلية المنشورة "مدرسة قديمة". ومع ذلك ، في هذه الحالة ، سوف أبحث بالتأكيد في تنسيقات الملفات التي يستخدمها .ibd و/أو ibdata1.

2
RolandoMySQLDBA