innodb_file_format 바라쿠다


25

더 친숙한 사람들을 위해 몇 가지 질문이 있습니다. 바라쿠다에 대한 지원에도 불구하고 대부분의 인스턴스는 영양을 실행했습니다.

압축 innodb 테이블을 가지고 놀려고했습니다. 내 이해는 이것이 바라쿠다 형식에서만 사용할 수 있다는 것입니다.

  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를 사용하여 태그가 지정됩니다.

따라서 바라쿠다를 허용하더라도 테이블은 영양으로 생성됩니다. 모든 테이블을 row_format 동적 또는 압축 테이블로 지정하지 않으면 혼합을 피할 수 없습니다.

첫 Barracuda 테이블을 도입 할 때 완전한 덤프 및 재로드를 수행해야한다는 표시는 없습니다 (예 : mysql의 주요 버전을 업그레이드 할 때 권장 됨 )

답변:


18

그래서 나는 거의 4 년 늦게이 질문에 대답하고 있습니다.

  • InnoDB 파일 형식은 InnoDB가 MySQL 서버와 독립적 일 때 고려되었습니다 (예 : MySQL 5.1은 두 가지 버전의 InnoDB를 실행할 수 있음).

  • 바라쿠다 (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 TABLE 등) 업그레이드됩니다 . 그것들이 특별히 만들어지지 않았다면 ROW_FORMAT=oldrowformat.

  • MySQL 8.0에서는 옵션 innodb_file_format이 제거되었습니다.


MySQL 5.7은 또한 DYNAMIC으로 기본 설정 되는 옵션을innodb_default_row_format 도입 했습니다 . 이것은 업데이트의 요점을 해결합니다.


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로 게임을하려면 mysqldump를 /root/MySQLData.sql과 같은 형식으로 덤프해야합니다. 이는 데이터 파일 형식을 독립적으로 만듭니다.

새로운 ibdata1 및 innodb_file_per_table (선택 사항, 개인 취향)과 함께 다른 MySQL 인스턴스를 사용하십시오. ibdata1을 비워 파일 형식을 변경하십시오. 그런 다음 /root/MySQLData.sql을 다시로드하고 데이터를 재생하십시오.

PostgreSQL이 9.0.1 바이너리와 작동하도록 8.2.4 데이터베이스를 가져 오기 위해 설정을 tweek해야한다는 약간의 공포 이야기를 들었습니다. 두 가지 파일 형식을 동일한 시스템 테이블 공간 (ibdata1) 및 / 또는 .ibd이러한 설정을 알고있는 경우 파일에 두려고하면 같은 이야기가 적용될 수 있습니다 .

정결 한 한 ...

  • 육류와 유제품을 같은 냉장고에 보관해서는 안됩니다
  • 아무도 같은 멍에로 황소와 엉덩이를 두어서는 안됩니다 (신 22:10).
  • 아무도 동일한 ibdata1을 저장 Antelope하고 저장해서는 Barracuda안됩니다.

업데이트 2013-07-05 14:26 EDT

방금 ServerFault : MySQL INNODB 압축 설정 KEY_BLOCK_SIZE 에서이 질문에 대답했습니다 . DBA StackExchange에서 Barracuda형식에 대해 논의한 질문에 대해 되돌아 보게되었고이 오래된 게시물을 찾았습니다. 나는 여기에 같은 정보를 둘 것이다 ...

바라쿠다의 InnoDB 압축에 관한 MySQL 문서 에 따르면

압축 및 InnoDB 버퍼 풀

압축 된 InnoDB 테이블에서 모든 압축 된 페이지 (1K, 2K, 4K 또는 8K)는 16K 바이트의 압축되지 않은 페이지에 해당합니다. 페이지의 데이터에 액세스하기 위해 InnoDB는 압축 된 페이지가 아직 버퍼 풀에없는 경우 디스크에서 압축 된 페이지를 읽은 다음 페이지를 원래의 16K 바이트 형식으로 압축 해제합니다. 이 섹션에서는 InnoDB가 압축 테이블의 페이지와 관련하여 버퍼 풀을 관리하는 방법에 대해 설명합니다.

I / O를 최소화하고 페이지를 압축 해제해야 할 필요성을 줄이기 위해 때때로 버퍼 풀에는 압축 및 압축되지 않은 형태의 데이터베이스 페이지가 모두 포함됩니다. 다른 필요한 데이터베이스 페이지를위한 공간을 확보하기 위해 InnoDB는 압축 된 페이지를 메모리에 남겨두고 버퍼 풀에서 압축되지 않은 페이지를 "제거"할 수 있습니다. 또는 페이지가 한동안 액세스되지 않은 경우 압축 된 페이지 형식의 디스크가 다른 데이터를위한 공간을 확보하기 위해 디스크에 기록 될 수 있습니다. 따라서, 임의의 주어진 시간에, 버퍼 풀은 페이지의 압축 및 압축되지 않은 형태, 또는 페이지의 압축 된 형태 만 또는 둘 다를 포함하지 않을 수있다.

InnoDB는 메모리에 보관할 페이지와 LRU (Least-Recently-Used) 목록을 사용하여 어느 페이지를 제거해야하는지 추적하여 "핫"또는 자주 액세스하는 데이터가 메모리에 남아있는 경향이 있습니다. 압축 된 테이블에 액세스 할 때 InnoDB는 적응 형 LRU 알고리즘을 사용하여 메모리에서 압축 및 압축되지 않은 페이지의 적절한 균형을 달성합니다. 이 적응 형 알고리즘은 시스템이 I / O 바운드 또는 CPU 바운드 방식으로 실행 중인지 여부에 민감합니다. 목표는 CPU가 사용 중일 때 페이지를 압축 해제하는 데 너무 많은 처리 시간을 소비하지 않도록하고 CPU에 압축 된 페이지를 압축 해제하는 데 사용할 수있는 여분의주기 (메모리에있을 수 있음)가있을 때 과도한 I / O를 수행하지 않도록하는 것입니다. 시스템이 I / O 바운드 인 경우 알고리즘은 두 사본이 아닌 압축되지 않은 페이지 사본을 제거하는 것을 선호합니다. 다른 디스크 페이지가 메모리 상주가되도록 더 많은 공간을 확보합니다. 시스템이 CPU 바운드 인 경우 InnoDB는 압축 된 페이지와 압축되지 않은 페이지를 모두 제거하여 "핫"페이지에 더 많은 메모리를 사용하고 압축 된 형식으로 만 메모리의 데이터를 압축 해제 할 필요성을 줄입니다.

InnoDB 버퍼 풀은 쿼리를 수행하기 위해 데이터 페이지와 인덱스 페이지를로드해야합니다. 테이블과 인덱스를 처음 읽을 때는 압축 된 페이지를 16K로 압축 해제해야합니다. 즉, 압축 및 압축되지 않은 데이터 페이지 인 버퍼 풀에 두 배의 데이터 컨텐츠가있게됩니다.

버퍼 풀에서 이러한 데이터 컨텐츠 복제가 진행중인 경우 새 압축률의 작은 선형 계수로 innodb_buffer_pool_size 를 늘려야 합니다. 방법은 다음과 같습니다.

대본

  • 8G 버퍼 풀이있는 DB 서버가 있습니다.
  • 당신은 압축을 실행 key_block_size=8
    • 8~ 50.00%16
    • 50.00%8GIS4G
    • 인상 innodb_buffer_pool_size12G( 8G+ 4G)
  • 당신은 압축을 실행 key_block_size=4
    • 4~ 25.00%16
    • 25.00%8GIS2G
    • 인상 innodb_buffer_pool_size10G( 8G+ 2G)
  • 당신은 압축을 실행 key_block_size=2
    • 2~ 12.50%16
    • 12.50%8GIS1G
    • 인상 innodb_buffer_pool_size9G( 8G+ 1G)
  • 당신은 압축을 실행 key_block_size=1
    • 1~ 06.25%16
    • 06.25%8GIS 0.5G( 512M)
    • 인상 innodb_buffer_pool_size8704M( 8G( 8192M) + 512M)

스토리의 주제 : InnoDB 버퍼 풀은 압축 된 데이터 및 인덱스 페이지를 처리 ​​할 때 추가 호흡 공간이 필요합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.