innodb_file_format Barracuda


25

ฉันมีคำถามสองสามข้อสำหรับผู้ที่คุ้นเคยมากกว่า อินสแตนซ์ส่วนใหญ่ของฉันใช้แอนตีโลปแม้จะได้รับการสนับสนุนจาก Barracuda

ฉันกำลังมองหาที่จะเล่นกับตาราง innodb ที่บีบอัด ความเข้าใจของฉันคือนี่ใช้ได้เฉพาะในรูปแบบ Barracuda

  1. ฉันเห็นว่า innodb_file_format เป็นแบบไดนามิกดังนั้นฉันจึงสามารถสลับกลับได้โดยไม่ต้องตีกลับ มีความหมายใด ๆ ในการทำเช่นนี้ฉันควรระวัง ทั้งหมดที่ฉันบอกได้คือนั่นหมายถึงตารางใหม่หรือการเปลี่ยนแปลงในภายหลังจะถูกสร้างด้วยรูปแบบนั้น ทั้งหมดนี้ถูกต้องหรือไม่
  2. ฉันหวังว่าจะไม่ผ่านและแปลงตารางทั้งหมดของฉัน เป็น kosher ที่มี antelope และ barracude table อยู่ใน tablespace เดียวกันหรือไม่? แม้ว่ามันจะใช้ได้หรือไม่มี gotcha ที่ต้องระวัง?

จากสิ่งที่ฉันอ่านและรวบรวมจากการทดสอบของฉันคำตอบคือ: ใช่ ใช่. ฉันไม่แน่ใจ.

ปรับปรุง

ฉันใช้ Dynamic กับบางตารางที่ถูกบีบอัดในอินสแตนซ์ต่าง ๆ ตั้งแต่โพสต์นี้โดยไม่มีปัญหา ต่อไปฉันละเลยที่จะอ่านhttp://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html ในเวลานั้น

หลังจากที่คุณเปิดใช้งาน innodb_file_format ที่กำหนดการเปลี่ยนแปลงนี้จะใช้กับตารางที่สร้างขึ้นใหม่เท่านั้นแทนที่จะเป็นตารางที่มีอยู่ หากคุณสร้างตารางใหม่พื้นที่ตารางที่มีตารางจะถูกติดแท็กด้วยรูปแบบไฟล์“ เร็วที่สุด” หรือ“ ง่ายที่สุด” ที่จำเป็นสำหรับคุณสมบัติของตาราง ตัวอย่างเช่นหากคุณเปิดใช้งานรูปแบบไฟล์ Barracuda และสร้างตารางใหม่ที่ไม่ได้บีบอัดและไม่ใช้ ROW_FORMAT = DYNAMIC พื้นที่ตารางใหม่ที่มีตารางจะถูกแท็กว่าใช้รูปแบบไฟล์ละมั่ง

ดังนั้นตารางจะถูกสร้างขึ้นเป็นละมั่งแม้ว่าคุณจะอนุญาตให้ Barracuda ไม่สามารถหลีกเลี่ยงการผสมยกเว้นว่าคุณระบุทุกตารางเป็น row_format dynamic หรือตารางที่ถูกบีบอัด

ไม่มีข้อบ่งชี้ว่าคุณควรทำการดัมพ์และรีโหลดแบบสมบูรณ์เมื่อแนะนำตาราง Barracuda แรกของคุณ (เช่นแนะนำเมื่ออัพเกรด mysql รุ่นใหญ่ )

คำตอบ:


18

ดังนั้นฉันจึงตอบคำถามนี้เกือบ 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บนการสร้างตารางถัดไป (ตาราง OPTIMIZE และอื่น ๆ ) ROW_FORMAT=oldrowformatนั่นคือจนกว่าพวกเขาจะถูกสร้างขึ้นโดยเฉพาะกับ

  • ใน MySQL 8.0 ตัวเลือกinnodb_file_formatจะถูกลบออก


MySQL 5.7 ยังแนะนำตัวเลือกinnodb_default_row_formatซึ่งเป็นค่าเริ่มต้นของ DYNAMIC ที่อยู่นี้จุดในการปรับปรุงของคุณ


11
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 :

[root@dhcppc0 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)

9

หากคุณต้องการเล่นกับ InnoDB โดยใช้รูปแบบ Barracuda คุณควร mysqldump ทุกอย่างเป็น /root/MySQLData.sql ทำให้รูปแบบไฟล์ข้อมูลเป็นอิสระ

ใช้อินสแตนซ์ MySQL อีกอันกับ ibdata1 และ innodb_file_per_table ใหม่ (เป็นตัวเลือกการตั้งค่าส่วนตัวของฉัน) เปลี่ยนรูปแบบไฟล์ด้วย ibdata1 ที่ว่างเปล่า จากนั้นรีโหลด /root/MySQLData.sql แล้วเล่นกับข้อมูล

ฉันเคยได้ยินเรื่องราวสยองขวัญเล็กน้อยเกี่ยวกับ PostgreSQL ที่ต้องตั้งค่าทวีตเพื่อรับฐานข้อมูล 8.2.4 เพื่อทำงานกับ 9.0.1 ไบนารี เรื่องเดียวกันอาจนำไปใช้ถ้าเราพยายามทำให้ทั้งสองรูปแบบไฟล์อยู่ใน tablespace ระบบเดียวกัน (ibdata1) และ / หรือ.ibdไฟล์หากเราตระหนักถึงการตั้งค่าดังกล่าว

เท่าที่เป็นเพียว ...

  • ไม่มีใครควรเก็บเนื้อสัตว์และผลิตภัณฑ์นมในตู้เย็นเดียวกัน
  • ไม่มีใครควรใส่วัวและลาภายใต้แอกเดียวกัน (เฉลยธรรมบัญญัติ 22:10)
  • ไม่มีใครควรเก็บAntelopeและBarracudaอยู่ใน ibdata1 เดียวกัน

อัพเดท 2013-07-05 14:26 EDT

ฉันเพียงแค่ตอบคำถามนี้ใน ServerFault: การตั้งค่า MySQL INNODB การบีบอัด KEY_BLOCK_SIZE นี่ทำให้ฉันมองย้อนกลับไปสำหรับคำถามใด ๆ ที่ฉันตอบใน DBA StackExchange ได้พูดถึงBarracudaรูปแบบและฉันพบโพสต์เก่าของฉัน ฉันจะวางข้อมูลเดียวกันที่นี่ ...

ตาม เอกสาร MySQLเกี่ยวกับการบีบอัด InnoDB สำหรับ Barracuda

การบีบอัดและพูลบัฟเฟอร์ InnoDB

ในตาราง InnoDB ที่ถูกบีบอัดทุกหน้าที่ถูกบีบอัด (ไม่ว่าจะเป็น 1K, 2K, 4K หรือ 8K) นั้นสอดคล้องกับหน้าที่ไม่มีการบีบอัดขนาด 16K ไบต์ ในการเข้าถึงข้อมูลในหน้าเว็บ InnoDB จะอ่านหน้าที่ถูกบีบอัดจากดิสก์หากยังไม่ได้อยู่ในบัฟเฟอร์พูลจากนั้นคลายการบีบอัดหน้าดังกล่าวเป็นรูปแบบไบต์ 16K ดั้งเดิม ส่วนนี้อธิบายถึงวิธีที่ InnoDB จัดการกับบัฟเฟอร์พูลเมื่อเทียบกับหน้าของตารางที่บีบอัด

เพื่อลด I / O ให้น้อยที่สุดและเพื่อลดความต้องการในการคลายการบีบอัดเพจในบางครั้งพูลบัฟเฟอร์มีทั้งรูปแบบที่บีบอัดและไม่บีบอัดของหน้าฐานข้อมูล เพื่อให้มีที่ว่างสำหรับหน้าฐานข้อมูลอื่น ๆ ที่จำเป็น InnoDB อาจ "ขับไล่" จากพูลบัฟเฟอร์เป็นหน้าที่ไม่บีบอัดในขณะที่ปล่อยให้หน้าบีบอัดในหน่วยความจำ หรือหากหน้าไม่ได้รับการเข้าถึงในขณะที่รูปแบบการบีบอัดของหน้าอาจถูกเขียนไปยังดิสก์เพื่อพื้นที่ว่างสำหรับข้อมูลอื่น ๆ ดังนั้นในเวลาใดก็ตามบัฟเฟอร์พูลอาจมีทั้งรูปแบบที่บีบอัดและไม่บีบอัดของหน้าหรือเฉพาะรูปแบบที่บีบอัดของหน้าหรือไม่

InnoDB ติดตามว่าหน้าใดที่จะเก็บไว้ในหน่วยความจำและที่จะขับไล่โดยใช้รายการที่ใช้น้อยที่สุดเมื่อไม่นานมานี้เพื่อให้ข้อมูล "ร้อน" หรือที่เข้าถึงบ่อยมีแนวโน้มที่จะอยู่ในหน่วยความจำ เมื่อเข้าถึงตารางที่บีบอัดแล้ว InnoDB จะใช้อัลกอริธึม LRU แบบปรับตัวเพื่อให้เกิดความสมดุลที่เหมาะสมของหน้าที่ถูกบีบอัดและไม่ถูกบีบอัดในหน่วยความจำ อัลกอริทึมแบบปรับตัวนี้มีความอ่อนไหวต่อว่าระบบกำลังทำงานในลักษณะ I / O-bound หรือ CPU-bound เป้าหมายคือเพื่อหลีกเลี่ยงการใช้เวลาประมวลผลมากเกินไปในการยกเลิกการบีบอัดเพจเมื่อ CPU ไม่ว่างและหลีกเลี่ยงการทำ I / O มากเกินไปเมื่อ CPU มีรอบว่างที่สามารถใช้สำหรับการบีบอัดเพจที่ไม่ได้บีบอัด (ซึ่งอาจอยู่ในหน่วยความจำแล้ว) เมื่อระบบเป็น I / O-ผูกอัลกอริทึมชอบที่จะขับไล่สำเนาที่ไม่มีการบีบอัดของหน้ามากกว่าสำเนาทั้งสอง เพื่อเพิ่มพื้นที่ให้ดิสก์เพจอื่น ๆ กลายเป็นหน่วยความจำ เมื่อระบบเชื่อมโยงกับ CPU InnoDB ชอบที่จะไล่ทั้งหน้าที่ถูกบีบอัดและไม่บีบอัดดังนั้นหน่วยความจำเพิ่มเติมสามารถใช้สำหรับหน้า“ ร้อน” และลดความจำเป็นในการคลายข้อมูลในหน่วยความจำในรูปแบบการบีบอัดเท่านั้น

ขอให้สังเกตว่า InnoDB Buffer Pool ต้องโหลดหน้าข้อมูลและหน้าดัชนีเพื่ออ่านแบบสอบถาม เมื่ออ่านตารางและดัชนีของมันเป็นครั้งแรกหน้าบีบอัดจะต้องไม่ถูกบีบอัดเป็น 16K นั่นหมายความว่าคุณจะมีเนื้อหาข้อมูลมากเป็นสองเท่าในบัฟเฟอร์พูลหน้าข้อมูลที่บีบอัดและไม่บีบอัด

หากการทำซ้ำของเนื้อหาข้อมูลเกิดขึ้นใน Buffer Pool คุณจะต้องเพิ่มinnodb_buffer_pool_sizeโดยปัจจัยเชิงเส้นเล็ก ๆ ของอัตราการบีบอัดใหม่ นี่คือวิธี:

สถานการณ์

  • คุณมีเซิร์ฟเวอร์ฐานข้อมูลพร้อมกับบัฟเฟอร์ 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 เพียงต้องการห้องหายใจเพิ่มเติมเมื่อจัดการข้อมูลที่บีบอัดและหน้าดัชนี

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.