innodb_file_format Barracuda


25

Tôi có một vài câu hỏi cho những người quen thuộc hơn. Hầu hết các trường hợp của tôi đã chạy Antelope mặc dù có hỗ trợ cho Barracuda.

Tôi đang tìm cách để chơi xung quanh với một số bảng innodb nén. Hiểu biết của tôi là điều này chỉ có sẵn dưới định dạng Barracuda.

  1. Tôi thấy innodb_file_format là động nên tôi chỉ có thể chuyển qua mà không bị trả lại. Có bất kỳ ý nghĩa của việc làm này tôi nên nhận thức được. Tất cả những gì tôi có thể nói là điều đó có nghĩa là các bảng mới hoặc sau đó được thay đổi sẽ được tạo với định dạng đó. Đây có phải là tất cả chính xác?
  2. Tôi đã hy vọng không phải đi qua và chuyển đổi tất cả các bảng của tôi. Là kosher để có bảng linh dương và bảng barracude cùng tồn tại trong cùng một không gian bảng? Ngay cả khi nó hoạt động, có bất kỳ gotcha nào để tìm?

Từ những gì tôi đã đọc và thu thập từ các bài kiểm tra của mình, các câu trả lời là: Có. Vâng. Tôi không chắc.

Cập nhật

Tôi đã chạy một số bảng động và một số bảng nén trong các trường hợp khác nhau kể từ bài đăng này có vấn đề. Hơn nữa, tôi đã bỏ qua việc đọc http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html tại thời điểm đó.

Sau khi bạn bật innodb_file_format nhất định, thay đổi này chỉ áp dụng cho các bảng mới được tạo thay vì các bảng hiện có. Nếu bạn tạo một bảng mới, không gian bảng chứa bảng được gắn thẻ với định dạng tệp tin sớm nhất hoặc hay đơn giản nhất là bắt buộc đối với các tính năng của bảng. Ví dụ: nếu bạn bật định dạng tệp Barracuda và tạo một bảng mới không được nén và không sử dụng ROW_FORMAT = DYNAMIC, không gian bảng mới chứa bảng được gắn thẻ là sử dụng định dạng tệp Antelope.

Vì vậy, các bảng sẽ được tạo như Antelope ngay cả khi bạn cho phép Barracuda. Việc trộn là không thể tránh khỏi trừ khi bạn chỉ định mọi bảng là row_format động hoặc bảng nén.

Không có dấu hiệu nào bạn nên thực hiện một kết xuất hoàn chỉnh và tải lại khi giới thiệu bảng Barracuda đầu tiên của bạn (chẳng hạn như được khuyến nghị khi nâng cấp các phiên bản chính của mysql )

Câu trả lời:


18

Vì vậy, tôi đang trả lời câu hỏi này muộn gần 4 năm:

  • Các định dạng tệp InnoDB được hình thành tại thời điểm InnoDB độc lập với Máy chủ MySQL (ví dụ: MySQL 5.1 có thể chạy hai phiên bản khác nhau của InnoDB).

  • Lý do tại sao bạn không muốn chạy Barracuda (vào năm 2012) là vì nó có thể làm giảm tính linh hoạt trong việc hạ cấp MySQL (tức là sau khi nâng cấp không thành công, bạn muốn quay lại phiên bản không thể đọc định dạng mới hơn). tức là không nên có lý do kỹ thuật tại sao Antelope tốt hơn.

  • Trong MySQL 5.7, innodb_file_formattùy chọn không được chấp nhận. Vì MySQL và InnoDB không còn độc lập, và do đó InnoDB có thể sử dụng các quy tắc nâng cấp của MySQL và những gì cần có khả năng tương thích ngược. Không có cài đặt khó hiểu cần thiết!

  • Trong MySQL 5.7, mặc định chuyển sang Barracuda/DYNAMIC. Vì tất cả các bản phát hành hiện đang được hỗ trợ của MySQL đều có thể đọc định dạng này, nên việc rời khỏi Antelope là an toàn và vẫn cung cấp hạ cấp.

  • Trên máy chủ MySQL 5.7, các bảng Antelope sẽ được nâng cấp lên Barracuda/DYNAMICtrên bảng tiếp theo được xây dựng lại (TỐI ƯU BẢNG, v.v.). Đó là trừ khi chúng được tạo ra đặc biệt với ROW_FORMAT=oldrowformat.

  • Trong MySQL 8.0, tùy chọn innodb_file_formatđược loại bỏ.


MySQL 5.7 cũng giới thiệu tùy chọninnodb_default_row_format , mặc định là NĂNG ĐỘNG. Điều này giải quyết điểm trong bản cập nhật của bạn.


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

Nếu bạn thực sự muốn chơi với InnoDB bằng định dạng Barracuda, bạn nên mysqldump mọi thứ thành một cái gì đó như /root/MyQueryData.sql. Điều đó làm cho định dạng tệp dữ liệu độc lập.

Sử dụng một phiên bản MySQL khác với ibdata1 và innodb_file_per_table mới (tùy chọn, tùy chọn cá nhân của tôi). Thay đổi định dạng tệp với ibdata1 trống. Sau đó, tải lại /root/MySQLData.sql và chơi với dữ liệu.

Tôi đã nghe những câu chuyện kinh dị nhỏ về PostgreSQL phải thực hiện các cài đặt để có được cơ sở dữ liệu 8.2.4 để hoạt động với các tệp nhị phân 9.0.1. Câu chuyện tương tự có thể áp dụng nếu chúng tôi cố gắng làm cho cả hai định dạng tệp nằm trong cùng một không gian bảng hệ thống (ibdata1) và / hoặc .ibdtệp nếu chúng tôi biết các cài đặt đó.

Theo như ...

  • Không ai nên lưu trữ thịt và sữa trong cùng một tủ lạnh
  • Không ai nên đặt một con bò và một cái mông dưới cùng một ách (Phục truyền Luật lệ Ký 22: 10)
  • Không ai nên lưu trữ AntelopeBarracudabên trong cùng một ibdata1

CẬP NHẬT 2013-07-05 14:26 EDT

Tôi vừa trả lời câu hỏi này trong ServerFault: Đặt MySQL INNODB Nén KEY_BLOCK_SIZE . Điều này khiến tôi nhìn lại bất kỳ câu hỏi nào tôi đã trả lời trong DBA StackExchange đã thảo luận về Barracudađịnh dạng và tôi tìm thấy bài đăng cũ này của tôi. Tôi sẽ đặt thông tin tương tự ở đây ...

Theo Tài liệu MySQL về nén InnoDB cho Barracuda

Nén và nhóm đệm InnoDB

Trong bảng InnoDB đã nén, mọi trang được nén (cho dù 1K, 2K, 4K hoặc 8K) tương ứng với một trang không nén 16K byte. Để truy cập dữ liệu trong một trang, InnoDB đọc trang được nén từ đĩa nếu nó chưa có trong vùng đệm, sau đó giải nén trang thành dạng byte 16K ban đầu. Phần này mô tả cách InnoDB quản lý nhóm bộ đệm đối với các trang của bảng nén.

Để giảm thiểu I / O và để giảm nhu cầu giải nén một trang, đôi khi nhóm bộ đệm chứa cả dạng nén và không nén của trang cơ sở dữ liệu. Để nhường chỗ cho các trang cơ sở dữ liệu cần thiết khác, InnoDB có thể đuổi ra khỏi bộ đệm một trang không nén, trong khi để trang nén trong bộ nhớ. Hoặc, nếu một trang không được truy cập trong một thời gian, hình thức nén của trang có thể được ghi vào đĩa, để giải phóng không gian cho dữ liệu khác. Do đó, tại bất kỳ thời điểm nào, nhóm bộ đệm có thể chứa cả dạng nén và dạng không nén của trang hoặc chỉ dạng nén của trang hoặc không.

InnoDB theo dõi những trang nào cần lưu trong bộ nhớ và những trang nào sẽ bị trục xuất bằng cách sử dụng danh sách ít được sử dụng gần đây nhất (LRU), do đó, hot hot hay dữ liệu thường xuyên truy cập có xu hướng lưu lại trong bộ nhớ. Khi các bảng nén được truy cập, InnoDB sử dụng thuật toán LRU thích ứng để đạt được sự cân bằng thích hợp của các trang được nén và không nén trong bộ nhớ. Thuật toán thích ứng này nhạy cảm với việc hệ thống đang chạy theo cách liên kết I / O hay ràng buộc CPU. Mục tiêu là để tránh mất quá nhiều thời gian xử lý các trang nén khi CPU bận và để tránh làm I / O dư thừa khi CPU có các chu kỳ dự phòng có thể được sử dụng để giải nén các trang nén (có thể đã có trong bộ nhớ). Khi hệ thống bị ràng buộc I / O, thuật toán thích loại bỏ bản sao không nén của trang hơn là cả hai bản sao, để có thêm chỗ cho các trang đĩa khác trở thành cư dân bộ nhớ. Khi hệ thống bị ràng buộc bởi CPU, InnoDB thích loại bỏ cả trang được nén và không nén, để có thể sử dụng nhiều bộ nhớ hơn cho các trang nóng của Cameron và giảm nhu cầu giải nén dữ liệu trong bộ nhớ ở dạng nén.

Lưu ý rằng Bộ đệm InnoDB phải tải các trang dữ liệu và các trang chỉ mục được đọc để thực hiện các truy vấn. Khi đọc một bảng và các chỉ mục của nó lần đầu tiên, trang nén phải được giải nén thành 16K. Điều đó có nghĩa là bạn sẽ có gấp đôi số lượng nội dung dữ liệu trong nhóm bộ đệm, trang dữ liệu được nén và không nén.

Nếu việc sao chép nội dung dữ liệu này đang diễn ra trong Vùng đệm, bạn cần tăng innodb_buffer_pool_size bằng một hệ số tuyến tính nhỏ của tốc độ nén mới. Đây là cách thực hiện:

PHONG CÁCH

  • Bạn có Máy chủ DB với Bộ đệm 8G
  • Bạn đã chạy nén với key_block_size=8
    • 850.00%của16
    • 50.00%của 8G4G
    • nâng innodb_buffer_pool_sizelên 12G( 8G+ 4G)
  • Bạn đã chạy nén với key_block_size=4
    • 425.00%của16
    • 25.00%của 8G2G
    • nâng innodb_buffer_pool_sizelên 10G( 8G+ 2G)
  • Bạn đã chạy nén với key_block_size=2
    • 212.50%của16
    • 12.50%của 8G1G
    • nâng innodb_buffer_pool_sizelên 9G( 8G+ 1G)
  • Bạn đã chạy nén với key_block_size=1
    • 106.25%của16
    • 06.25%của 8G0.5G( 512M)
    • nâng innodb_buffer_pool_sizelên 8704M( 8G( 8192M) + 512M)

NHIỀU CÂU CHUYỆN : Bể đệm InnoDB chỉ cần phòng thở bổ sung khi xử lý các trang chỉ mục và dữ liệu nén.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.