it-swarm.asia

لماذا يقوم InnoDB بتخزين جميع قواعد البيانات في ملف واحد؟

كان من المريح أن تستخدم MyISAM لتخزين كل جدول في ملف مناظر. حقق InnoDB تطورات في العديد من الجوانب ، لكني أتساءل لماذا يخزن InnoDB جميع قواعد البيانات في ملف واحد (ibdata1 بشكل افتراضي).

أفهم أن InnoDB سيحدد موقع البيانات في الملف عن طريق ملفات فهرس فردية للجداول ، لكنني لا أفهم سبب مزجها لجميع البيانات في ملف واحد. والأهم من ذلك ، لماذا تخلط بيانات جميع قواعد البيانات على الخادم؟

ميزة مثيرة للاهتمام في MyISAM هي أنه يمكن للمرء نسخ/لصق مجلد قاعدة بيانات إلى جهاز آخر ثم استخدام قاعدة البيانات (بدون تفريغ).

55
Googlebot

تتطلب بنية InnoDB استخدام أربعة أنواع أساسية من صفحات المعلومات

  • صفحات بيانات الجدول
  • صفحات فهرس الجدول
  • جدول بيانات التعريف
  • [~ # ~] mvcc [~ # ~] البيانات (لدعم عزل المعاملات و توافق ACID )
    • شرائح الاستعادة
    • تراجع عن الفضاء
    • ذاكرة التخزين المؤقت للكتابة المزدوجة (كتابة الخلفية لمنع الاعتماد على التخزين المؤقت لنظام التشغيل)
    • إدراج المخزن المؤقت (إدارة التغييرات على الفهارس الثانوية غير الفريدة)

راجع التمثيل التصويري للبدات 1

بشكل افتراضي ، innodb_file_per_table معطل. يؤدي هذا إلى جميع أنواع صفحات المعلومات الأربعة لوضع ملف واحد يسمى ibdata1. يحاول العديد من الأشخاص نشر البيانات عن طريق إنشاء ملفات ibdata متعددة. قد يؤدي هذا إلى تجزئة البيانات وصفحات الفهرس.

هذا هو السبب في كثير من الأحيان أوصي بتنظيف البنية التحتية لـ InnoDB ، باستخدام ملف ibdata1 الافتراضي وليس أكثر .

النسخ أمر خطير للغاية بسبب البنية التحتية التي يعمل InnoDB. هناك نوعان من البنى التحتية الأساسية

  • تم تعطيل innodb_file_per_table
  • تم تمكين innodb_file_per_table

InnoDB ( innodb_file_per_table معطل)

مع innodb_file_per_table معطل ، كل هذه الأنواع من معلومات InnoDB تعيش داخل ibdata1. المظهر الوحيد لأي جدول InnoDB خارج ibdata1 هو ملف .frm لجدول InnoDB. يتطلب نسخ جميع بيانات InnoDB دفعة واحدة نسخ/var/lib/mysql بالكامل.

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

InnoDB ( innodb_file_per_table ممكّن)

عند تمكين innodb_file_per_table ، تصبح بيانات الجدول وفهارسها موجودة في مجلد قاعدة البيانات بجوار ملف .frm. على سبيل المثال ، بالنسبة للجدول db1.mytable ، فإن مظهر جدول InnoDB خارج ibdata1 سيكون:

  • /var/lib/mysql/db1/mytable.frm
  • /var/lib/mysql/db1/mytable.ibd

مساحة جدول النظام ibdata1

جميع البيانات الوصفية لـ db1.mytable لا تزال موجودة في ibdata1 و لا توجد طريقة على الإطلاق لذلك . سجلات الإعادة وبيانات MVCC لا تزال تعمل أيضًا مع ibdata1.

عندما يتعلق الأمر بتجزئة الجدول ، فإليك ما يحدث لـ ibdata1:

  • innodb_file_per_table ممكّن : يمكنك تقليص db1.mytables باستخدام ALTER TABLE db1.mytable ENGINE=InnoDB; أو OPTIMIZE TABLE db1.mytable;. وينتج عن ذلك /var/lib/mysql/db1/mytable.ibd أن يكون أصغر جسديًا بدون تجزئة.
  • innodb_file_per_table معطل : لا يمكنك تقليص db1.mytables بـ ALTER TABLE db1.mytable ENGINE=InnoDB; أو OPTIMIZE TABLE db1.mytable; لأنه موجود مع ibdata1. عند تشغيل أي من الأمرين فعليًا ، اجعل الجدول متجاورًا وأسرع في القراءة والكتابة إليه. لسوء الحظ ، يحدث ذلك في نهاية ibdata1. هذا يجعل ibdata1 ينمو بسرعة. يتم تناول هذا بالكامل في InnoDB Cleanup Post .

تحذير (أو خطر كـ سيقول الروبوت في Lost in Space )

إذا كنت تفكر في مجرد نسخ ملف .frm و .ibd ، فأنت في طليعة عالم الأذى. يعد نسخ ملف .frm و .ibd لجدول InnoDB أمرًا جيدًا فقط إذا وفقط إذا كان بإمكانك ضمان تطابق معرف مساحة الجدول لملف .ibd تمامًا مع إدخال معرف مساحة الجدول في البيانات الوصفية لملف ibdata1 .

كتبت مقالتين في DBA StackExchange حول مفهوم معرف مساحة الجدول هذا

في ما يلي رابط ممتاز حول كيفية إعادة إرفاق أي ملف .ibd إلى ibdata1 في حالة عدم تطابق معرّفات مساحات الجداول: http://www.chriscalender.com/؟tag=innodb-error-tablespace-id-in- ملف . بعد قراءة هذا ، يجب أن تدرك على الفور أن نسخ ملفات .ibd هو مجرد مجنون.

بالنسبة إلى InnoDB ، ما عليك سوى الانتقال إلى هذا الشيء

CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;

لعمل نسخة من جدول InnoDB.

إذا كنت تقوم بترحيله إلى خادم DB آخر ، فاستخدم mysqldump.

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

69
RolandoMySQLDBA

يمكنك تبديل InnoDB لتخزين الجداول لكل ملف عن طريق إضافة innodb-file-per-table إلى cnf.

Innodb يهتم فقط بصفحات البيانات على المستوى الأساسي. في الواقع ، يمكنك إعداد InnoDB لاستخدام جهاز كتلة أولية بدون نظام ملفات على الإطلاق! http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html

هناك وسائل راحة لتخزين الجداول للملف مثل القدرة على استعادة المساحة المستخدمة بسهولة أكبر عن طريق التحسين.

حتى مع الملفات لكل جدول ، لا يمكنك فقط نسخ ملفات ibd بهذه السهولة لأن InnoDB هي معاملات وتخزن معلومات حول حالتها في ملفات ibdata/ملفات السجل المشتركة عالميًا.

هذا لا يعني أنه لا يمكن القيام به. إذا كان الجدول غير متصل ، يمكنك تجاهل/استيراد مساحات الطاولات ونسخ .idbs حول http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

14
atxdba

هذا هو السلوك الافتراضي ولكنه ليس إلزامياً. من مستندات MySQL ، باستخدام مساحات الجداول لكل طاولة :

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

أما السبب ، فمن المحتمل أن السبب هو الهياكل المختلفة للمحركين (MyISAM و InnoDB). على سبيل المثال ، في InnoDB ، لا يمكنك فقط نسخ ملف .ibd إلى قاعدة بيانات أو تثبيت آخر. شرح (من نفس الصفحة):

اعتبارات النقل لملفات .ibd

لا يمكنك نقل ملفات .ibd بحرية بين دلائل قاعدة البيانات كما يمكنك مع ملفات جدول MyISAM. يتضمن تعريف الجدول المخزن في مساحة الجدول المشتركة InnoDB اسم قاعدة البيانات. تختلف معرفات المعاملات وأرقام تسلسل السجلات المخزنة في ملفات مساحة الجداول أيضًا بين قواعد البيانات.

10
ypercubeᵀᴹ