it-swarm.asia

كيفية استرداد جدول InnoDB الذي تم نقل ملفاته

لذلك لدي خادم ديسيبل اختبار تم إعداده على دفق النسخ المتماثل. فوق الاسم جاء التحسين الذي ملأ المساحة بسرعة على datadir العبيد. كان Mysql في انتظار بعض المساحة.

Datadir هو نظام ملفات يستخدم فقط كقاعدة بيانات mysql لذلك لم يكن هناك أي شيء آخر لتحريره.

كان لدي جدول اختبار 4 غيغابايت innodb لم يكن جزءًا من دفق النسخ المتماثل ، لذا اكتشفت أنني سأجرب شيئًا لمعرفة ما إذا كان سيعمل ، وكوني بيئة اختبار لم أكن قلقًا للغاية إذا سارت الأمور بشكل فظيع.

إليك الخطوات التي اتخذتها

  1. مسح الجدول كنت على وشك التحرك
  2. وضع قفل قراءة عليه (على الرغم من عدم كتابة أي شيء عليه وعدم وجوده في دفق النسخ المتماثل)
  3. نسخ ملف .frm و .ibd إلى نظام ملفات مع بعض الفراغ
  4. فتح الجدول
  5. تم اقتطاع هذا الجدول - أدى هذا إلى توفير مساحة كافية للتحسين لإنهاء عملية النسخ المتماثل مع بدء التشغيل مرة أخرى.
  6. وقف سلاف/اغلاق الخلية
  7. انسخ الملف من tmp إلى دير البيانات
  8. إعادة تشغيل الخلية

لا يظهر شيء في سجل .err ، وتبدو الأمور جيدة. أقوم بتوصيل واستخدام mydb ؛ وشاهد الجدول الذي كنت أعبث به في جداول العرض. ولكن ، إذا حاولت

select * from testtable limit 10;

أحصل على الخطأ

ERROR 1146 (42S02): Table 'mydb.testtable' doesn't exist

من ما يمكنني أن أقول حتى الآن يمكنني القراءة من جميع الجداول الأخرى على ما يرام وبدأ النسخ المتماثل احتياطيًا دون أي شكاوى.

هل هناك أي شيء يمكنني القيام به للتعافي من هذه النقطة؟ يمكنني إعادة بنائه من الصفر إذا لزم الأمر ولكن كان من الغريب ما يعتقده الآخرون حول هذا المشروع بشكل عام. هل كان هناك أي شيء حول سلسلة الخطوات التي اتخذتها والتي كانت ستنتهي مع نتائج أكثر خللًا؟

ماذا لو لم يكن هذا خادم اختبار ، فلا يمكنني فقط "القيام به على الهواء مباشرة" ومعرفة ما يحدث؟ ما هي أفضل طريقة لتفريغ مساحة مؤقتًا على عبدة الإنتاج إذا اضطررت إلى ذلك؟

14
atxdba

أكبر شيء ينسى معظم الناس حول TRUNCATE TABLE هو أن TRUNCATE TABLE هو DDL وليس DML . في InnoDB ، تحتوي البيانات الوصفية داخل ibdata1 على قائمة مرقمة من جداول InnoDB. يؤدي استخدام جدول TRUNCATE إلى تغيير معرّف البيانات التعريفية الداخلية لجدول InnoDB. يحدث هذا لأن جدول TRUNCATE يقوم بما يلي بشكل فعال:

مثال: لاقتطاع جدول InnoDB يسمى mydb.mytb

USE mydb
CREATE TABLE newtb LIKE mytb;
ALTER TABLE mytb RENAME oldtb;
ALTER TABLE newtb RENAME mytb;
DROP TABLE oldtb;

وبالتالي فإن mytb الجديد سيكون له معرف بيانات تعريف داخلي مختلف.

عندما نسخت ملف .ibd إلى مكان آخر ، يحتوي .ibd داخله على معرف البيانات الوصفية الداخلي الأصلي. لا يؤدي إعادة ملف .ibd إلى التوفيق بين معرّف البيانات الوصفية الداخلي ومعرف iddata1.

ما عليك فعله هو هذا:

انسخ ملف .ibd لجدول InnoDB. ثم ، قم بتشغيل هذا

ALTER TABLE tablename DISCARD TABLESPACE;

لإعادته لاحقًا ، انسخ ملف .ibd إلى datadir ثم قم بتشغيله

ALTER TABLE tablename IMPORT TABLESPACE;

كان هذا سيحافظ على معرف البيانات الوصفية الداخلي.

تأكد من وجود .frm دائمًا.

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

عثر العميل على هذا المقال: http://www.chriscalender.com/؟tag=innodb-error-tablespace-id-in-file . استخدمناها وساعدت كثيرا. وآمل أن يساعد أنت.

15
RolandoMySQLDBA