it-swarm.asia

innodb_file_format باراكودا

لدي سؤالان لأولئك الأكثر دراية. معظم حالاتي كانت تدير Antelope على الرغم من دعمها لباراكودا.

كنت أتطلع للعب مع بعض منضدات إينودب الكمادات. ما أفهمه هو أن هذا متاح فقط في شكل باراكودا.

  1. أرى أن innodb_file_format ديناميكي حتى أتمكن من التبديل دون حدوث ارتداد. هل هناك أي آثار للقيام بذلك يجب أن أكون على علم بها. كل ما يمكنني قوله هو أن الجداول الجديدة أو التي سيتم تعديلها لاحقًا سيتم إنشاؤها بهذا التنسيق. هل كل هذا صحيح؟
  2. كنت آمل ألا اضطر إلى تحويل جميع طاولاتي وتحويلها. هل من الكوشر أن تتواجد طاولات الظباء والباراكود في نفس مساحة الطاولة؟ حتى لو كان يعمل هل هناك أي مسكتك للبحث عنها؟

من خلال ما قرأته وجمعته من اختباراتي ، الإجابات هي: نعم. نعم. لست واثق.

تحديث

لقد تم تشغيل بعض الجداول الديناميكية وبعض الجداول المضغوطة في حالات مختلفة منذ هذا المنشور دون مشكلة. علاوة على ذلك أهملت قراءة http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html في ذلك الوقت.

بعد تمكين innodb_file_format معين ، ينطبق هذا التغيير فقط على الجداول التي تم إنشاؤها حديثًا بدلاً من الجداول الحالية. إذا قمت بإنشاء جدول جديد ، فسيتم تمييز مساحة الجدول التي تحتوي على الجدول بتنسيق الملف "الأقدم" أو "الأبسط" المطلوب لميزات الجدول. على سبيل المثال ، إذا قمت بتمكين تنسيق الملف Barracuda ، وقمت بإنشاء جدول جديد غير مضغوط ولا يستخدم ROW_FORMAT = DYNAMIC ، فسيتم وضع علامة على مساحة الجدول الجديدة التي تحتوي على الجدول باستخدام تنسيق الملف Antelope.

لذلك سيتم إنشاء الجداول باسم Antelope حتى إذا سمحت لباراكودا. الخلط لا يمكن تجنبه إلا إذا حددت كل جدول كصف ديناميكي للصف أو جدول مضغوط.

لا يوجد ما يشير إلى أنه يجب عليك إجراء تفريغ وإعادة تحميل كاملة عند تقديم جدول Barracuda الأول الخاص بك (كما هو موصى به عند ترقية الإصدارات الرئيسية من mysql )

28
atxdba

لذا أجيب على هذا السؤال متأخراً 4 سنوات تقريباً:

  • تم إنشاء تنسيقات ملفات InnoDB في وقت كان فيه InnoDB مستقلاً عن خادم MySQL (على سبيل المثال: يمكن لـ MySQL 5.1 تشغيل نسختين مختلفتين من InnoDB).

  • السبب في عدم رغبتك في تشغيل Barracuda (في عام 2012) هو أنه يمكن أن يقلل من المرونة في تخفيض إصدار MySQL (أي بعد الترقية الفاشلة ، فأنت تريد العودة إلى إصدار لا يمكنه قراءة تنسيق أحدث). أي أنه لا ينبغي أن تكون هناك أسباب فنية تجعل الظباء أفضل.

  • في MySQL 5.7 الـ innodb_file_format تم إيقاف الخيار. نظرًا لأن MySQL و InnoDB لم يعدا مستقلين ، وبالتالي يمكن لـ InnoDB استخدام قواعد MySQL للترقيات وما هو التوافق العكسي المطلوب. لا يلزم إعداد مربك!

  • في MySQL 5.7 ، تحول الافتراضي إلى Barracuda/DYNAMIC. نظرًا لأن جميع إصدارات MySQL المدعومة حاليًا يمكنها قراءة هذا التنسيق ، فمن الآمن الابتعاد عن Antelope مع الاستمرار في الرجوع إلى إصدار أقدم.

  • على خادم MySQL 5.7 ، سيتم ترقية جداول Antelope إلى Barracuda/DYNAMIC في الجدول التالي إعادة بناء (تحسين الجدول وما إلى ذلك). هذا ما لم يتم إنشاؤها على وجه التحديد بـ ROW_FORMAT=oldrowformat.

  • في MySQL 8.0 ، الخيار innodb_file_format تم حذفه.


يقدم MySQL 5.7 أيضًا الخيار innodb_default_row_format ، التي يتم تعيينها افتراضيًا على DYNAMIC. هذا يعالج النقطة في التحديث الخاص بك.

20
Morgan Tocker
Just give a try!!!

mysql> select version();
+------------+
| version()  |
+------------+
| 5.5.21-log |
+------------+
1 row in set (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| innodb_file_format       | Antelope |
| innodb_file_format_check | ON       |
| innodb_file_format_max   | Antelope |
| innodb_file_per_table    | ON       |
+--------------------------+----------+
4 rows in set (0.00 sec)

mysql> SET GLOBAL innodb_file_format = barracuda;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Antelope  |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+
4 rows in set (0.00 sec)

mysql> SET GLOBAL innodb_file_format_max = barracuda;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Barracuda |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+
4 rows in set (0.00 sec)

I had observed a single line logged in Error Log file :

[[email protected] Desktop]# tail -1 /usr/local/mysql/data/dhcppc0.err
120402 11:26:52 [Info] InnoDB: the file format in the system tablespace is
now set to Barracuda.

After switching to barracuda file format, I could also access my Database
and tables without any error :

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| opentaps1          |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)

mysql> use opentaps1;
Database changed
mysql> select count(*) from product;
+----------+
| count(*) |
+----------+
|     3244 |
+----------+
1 row in set (0.42 sec)

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status: 
=====================================
120402 11:36:29 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 18446744073709534037 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 12 1_second, 12 sleeps, 1 10_second, 2 background,
2 flush
srv_master_thread log flush and writes: 12
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 5, signal count 5
Mutex spin waits 2, rounds 60, OS waits 2
RW-shared spins 3, rounds 90, OS waits 3
RW-excl spins 0, rounds 0, OS waits 0
Spin rounds per wait: 30.00 mutex, 30.00 RW-shared, 0.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter F01
Purge done for trx's n:o < 0 undo n:o < 0
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION F00, not started
MySQL thread id 1, OS thread handle 0x7f38309f9710, query id 28 localhost
root
show engine innodb status
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer
thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
554 OS file reads, 7 OS file writes, 7 OS fsyncs
-0.01 reads/s, 16384 avg bytes/read, -0.00 writes/s, -0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276707, node heap has 15 buffer(s)
-0.15 hash searches/s, -0.12 non-hash searches/s
---
LOG
---
Log sequence number 221536390
Log flushed up to   221536390
Last checkpoint at  221536390
0 pending log writes, 0 pending chkp writes
10 log i/o's done, -0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 3476070
Buffer pool size   8192
Free buffers       7635
Database pages     542
Old database pages 220
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
-0.00 youngs/s, -0.00 non-youngs/s
Pages read 542, created 0, written 1
-0.01 reads/s, -0.00 creates/s, -0.00 writes/s
Buffer pool hit rate 980 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead -0.00/s, evicted without access -0.00/s, Random read ahead
-0.00/s
LRU len: 542, unzip_LRU len: 0
I/O sum[0]:cur[238], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 2937, id 139879303665424, state: waiting for server
activity
Number of rows inserted 0, updated 0, deleted 0, read 3244
-0.00 inserts/s, -0.00 updates/s, -0.00 deletes/s, -0.18 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
1 row in set (0.00 sec)
11
Gopinath

إذا كنت ترغب حقًا في اللعب مع InnoDB باستخدام تنسيق Barracuda ، يجب عليك mysqldump كل شيء إلى شيء مثل /root/MySQLData.sql. وهذا يجعل تنسيق ملف البيانات مستقلاً.

استخدم مثيل MySQL آخر مع ibdata1 جديد و innodb_file_per_table (اختياري ، تفضيلاتي الشخصية). قم بتغيير تنسيق الملف مع ibdata1 فارغة. ثم أعد تحميل /root/MySQLData.sql واللعب بالبيانات.

لقد سمعت قصص رعب طفيفة حول PostgreSQL مضطرة إلى تعديل الإعدادات للحصول على 8.2.4 قاعدة بيانات للعمل مع 9.0.1 ثنائيات. يمكن تطبيق نفس القصة إذا حاولنا جعل كل من تنسيقات الملفات موجودة في نفس مساحة جدول النظام (ibdata1) و/أو .ibd الملف إذا كنا على علم بهذه الإعدادات.

بقدر ما كوشير ...

  • لا يجب تخزين اللحوم والألبان في نفس الثلاجة
  • لا أحد يجب أن يضع الثور والحمار تحت نفس نير (تثنية 22:10)
  • لا أحد يجب تخزين Antelope و Barracuda داخل نفس ibdata1

تحديث 2013-07-05 14:26 بتوقيت شرق الولايات المتحدة

لقد أجبت للتو على هذا السؤال في ServerFault: Setting MySQL INNODB Compression KEY_BLOCK_SIZE . هذا جعلني أنظر إلى الوراء لأية أسئلة أجبت عنها في DBA StackExchange ناقشت تنسيق Barracuda ووجدت هذا المنصب القديم الخاص بي. سأضع نفس المعلومات هنا ...

وفقًا توثيق MySQL على ضغط InnoDB لـ Barracuda

الضغط ومجمع InnoDB المؤقت

في جدول InnoDB مضغوط ، تقابل كل صفحة مضغوطة (سواء كانت 1K أو 2K أو 4K أو 8K) صفحة غير مضغوطة تبلغ 16 كيلو بايت. للوصول إلى البيانات الموجودة في الصفحة ، يقرأ InnoDB الصفحة المضغوطة من القرص إذا لم تكن موجودة بالفعل في تجمع المخزن المؤقت ، ثم تقوم بإلغاء ضغط الصفحة إلى شكلها الأصلي 16 كيلو بايت. يصف هذا القسم كيفية إدارة InnoDB لمجموعة المخزن المؤقت فيما يتعلق بصفحات الجداول المضغوطة.

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

يتتبع InnoDB الصفحات التي يجب حفظها في الذاكرة وأي الصفحات التي سيتم إخلاؤها باستخدام قائمة الأقل استخدامًا (LRU) ، بحيث تميل البيانات "الساخنة" أو التي يتم الوصول إليها كثيرًا إلى البقاء في الذاكرة. عند الوصول إلى الجداول المضغوطة ، يستخدم InnoDB خوارزمية LRU تكيفية لتحقيق التوازن المناسب للصفحات المضغوطة وغير المضغوطة في الذاكرة. هذه الخوارزمية التكيفية حساسة لما إذا كان النظام يعمل بطريقة مرتبطة بإدخال/إخراج أو مرتبطة بوحدة المعالجة المركزية. الهدف هو تجنب قضاء الكثير من الوقت في معالجة الصفحات غير المضغوطة عندما تكون وحدة المعالجة المركزية مشغولة ، وتجنب القيام بإدخال/إخراج زائد عندما تحتوي وحدة المعالجة المركزية على دورات احتياطية يمكن استخدامها لفك ضغط الصفحات المضغوطة (التي قد تكون موجودة بالفعل في الذاكرة). عندما يكون النظام مرتبطًا بإدخال/إخراج ، تفضل الخوارزمية طرد النسخة غير المضغوطة من الصفحة بدلاً من كلتا النسختين ، لتوفير مساحة أكبر لصفحات القرص الأخرى لتصبح مقيمة في الذاكرة. عندما يكون النظام مرتبطًا بوحدة المعالجة المركزية ، يفضل InnoDB طرد كل من الصفحة المضغوطة وغير المضغوطة ، بحيث يمكن استخدام المزيد من الذاكرة للصفحات "الساخنة" وتقليل الحاجة إلى إلغاء ضغط البيانات في الذاكرة فقط في شكل مضغوط.

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

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

سيناريو

  • لديك خادم DB مع تجمع عازلة 8G
  • قمت بتشغيل الضغط مع key_block_size=8
    • 8 يكون 50.00% من 16
    • 50.00% من 8G يكون 4G
    • رفع innodb_buffer_pool_size إلى 12G (8G + 4G)
  • قمت بتشغيل الضغط مع key_block_size=4
    • 4 يكون 25.00% من 16
    • 25.00% من 8G يكون 2G
    • رفع innodb_buffer_pool_size إلى 10G (8G + 2G)
  • قمت بتشغيل الضغط مع key_block_size=2
    • 2 يكون 12.50% من 16
    • 12.50% من 8G يكون 1G
    • رفع innodb_buffer_pool_size إلى 9G (8G + 1G)
  • قمت بتشغيل الضغط مع key_block_size=1
    • 1 يكون 06.25% من 16
    • 06.25% من 8G يكون 0.5G (512M)
    • رفع innodb_buffer_pool_size إلى 8704M (8G (8192M) + 512M)

معنويات القصة : يحتاج InnoDB Buffer Pool فقط إلى مساحة تنفس إضافية عند التعامل مع البيانات المضغوطة وصفحات الفهرس.

9
RolandoMySQLDBA