innodb_file_format Barracuda


25

Daha tanıdık olanlar için birkaç sorum var. Örneklerimin çoğu, Barracuda'yı desteklemesine rağmen Antilop kullanıyor.

Bazı kompresler innodb masaları ile oynamak istiyordum. Anladığım kadarıyla bu sadece Barracuda formatında mevcut.

  1. İnnodb_file_format'ın dinamik olduğunu görüyorum, böylece hemen çıkma ile geçiş yapabiliyorum. Bunu bilmem gereken herhangi bir sonuç var mı? Söyleyebileceğim tek şey, bu yeni tablolar anlamına gelir ya da daha sonra değiştirilmiş, bu formatta oluşturulacak. Hepsi doğru mu?
  2. Tüm masalarımı alıp dönüştürmemem gerektiğini umuyordum. Koşer aynı tablo alanında bir arada bulunan antilop ve barracude masalara sahip midir? Hatta o takdirde işler için dışarı bakmak için herhangi yakaladım en vardır?

Testlerimden okuduklarım ve topladıklarımdan cevaplar: Evet. Evet. Emin değilim.

Güncelleştirme

Bu yayından çıktıktan sonra çeşitli durumlarda w / bazı Dinamik ve bazı Sıkıştırılmış tabloları çalıştırıyorum. Ayrıca , o zaman http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html okumayı ihmal ettim .

Belirli bir innodb_file_format öğesini etkinleştirdikten sonra, bu değişiklik yalnızca mevcut tablolar yerine yeni oluşturulan tablolar için geçerlidir. Yeni bir tablo oluşturursanız, tabloyu içeren tablo alanı tablonun özellikleri için gerekli olan “en erken” veya “en basit” dosya formatıyla etiketlenir. Örneğin, Barracuda dosya biçimini etkinleştirirseniz ve sıkıştırılmamış ve ROW_FORMAT = DYNAMIC kullanmayan yeni bir tablo oluşturursanız, tabloyu içeren yeni tablo alanı Antelope dosya biçimini kullanarak etiketlenir.

Barracuda'ya izin verseniz bile tablolar Antilop olarak oluşturulacak. Her tabloyu row_format dynamic veya sıkıştırılmış bir tablo olarak belirtmezseniz, karıştırma işlemi kaçınılmazdır.

İlk Barracuda masanızı tanıtırken tam bir boşaltma yapmanız ve yeniden yüklemeniz gerektiğine dair herhangi bir gösterge yoktur ( mysql'in ana sürümlerini yükseltirken önerilir )

Yanıtlar:


18

Bu soruya neredeyse 4 yıl geç cevap veriyorum:

  • InnoDB dosya formatları, InnoDB'nin MySQL Sunucusundan bağımsız olduğu bir zamanda tasarlandı (örneğin: MySQL 5.1, iki farklı InnoDB sürümü çalıştırabilir).

  • Barracuda'yı (2012'de) çalıştırmak istememesinin nedeni, MySQL'i düşürme esnekliğini azaltabileceğidir (örneğin, başarısız bir yükseltme işleminden sonra, daha yeni bir format okuyamayan bir sürüme geri dönmek isteyebilirsiniz). yani, Antilop'un daha iyi olmasının teknik nedenleri olmamalıdır.

  • MySQL 5.7'de innodb_file_formatseçenek iptal edildi. MySQL ve InnoDB artık bağımsız olmadığından ve InnoDB, MySQL yükseltme kurallarını ve geriye dönük uyumluluk gerektiren uygulamaları kullanabilir. Kafa karıştırıcı ayar gerekmez!

  • MySQL 5.7'de varsayılan olarak ayarlandı Barracuda/DYNAMIC. Şu anda MySQL'in desteklenen tüm sürümleri bu formatı okuyabildiğinden, Antilop'tan uzaklaşmak ve hala düşürmek teklif etmek güvenlidir.

  • Bir MySQL 5.7 sunucusunda, Antelope masaları bir Barracuda/DYNAMICsonraki masaya yükseltilecek (OPTIMIZE TABLE etc). Özel olarak yaratılmadıkça bu değildir ROW_FORMAT=oldrowformat.

  • MySQL 8.0'da seçenek innodb_file_formatkaldırılmıştır.


MySQL 5.7 , varsayılan olarak DYNAMIC için olan seçeneğiinnodb_default_row_format de sunar . Bu, güncellemenizdeki noktayı ele alır.


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

Barracuda formatını kullanarak InnoDB ile gerçekten oynamak istiyorsanız, /root/MySQLData.sql gibi bir şeye her şeyi mysqldump yapmalısınız. Bu veri dosya formatını bağımsız kılar.

Yeni bir ibdata1 ve innodb_file_per_table (isteğe bağlı, kişisel tercihim) ile başka bir MySQL örneği kullanın. Dosya formatını ibdata1 boş olarak değiştirin. Ardından, /root/MySQLData.sql dosyasını yeniden yükleyin ve verilerle oynayın.

9.0.1 ikiliklerle çalışmak üzere 8.2.4 veri tabanı elde etmek için ayarları tweek yapmak zorunda kaldıklarından PostgreSQL hakkında ufak korku hikayeleri duydum. Aynı hikaye, hem dosya formatlarını aynı sistem tablo alanında (ibdata1) hem de / veya .ibddosyada bu tür ayarların farkında olmamız durumunda yapmayı denediğimizde uygulanabilir .

Koşer kadarıyla ...

  • Hiç kimse et ve süt ürünlerini aynı buzdolabında saklamamalıdır
  • Hiç kimse aynı boğanın altına boğayı ve kıçını sokmamalı (Deuteronomy 22:10)
  • Kimse saklamalısınız Antelopeve Barracudaaynı ibdata1 içeride

GÜNCELLEME 2013-07-05 14:26 EDT

Ben sadece bu soruyu ServerFault'da cevapladım: MySQL INNODB Sıkıştırmasını Ayarlama KEY_BLOCK_SIZE . Bu DBA StackExchange'te cevapladığım soruların arkasına bakmamı sağladı Barracudave bu eski yazıyı buldum. Aynı bilgiyi buraya da koyacağım ...

Barracuda İçin InnoDB Sıkıştırma Üzerine MySQL Belgesine Göre

Sıkıştırma ve InnoDB Tampon Havuzu

Sıkıştırılmış bir InnoDB tablosunda, her sıkıştırılmış sayfa (1K, 2K, 4K veya 8K), sıkıştırılmamış 16K bayt sayfalara karşılık gelir. Bir sayfadaki verilere erişmek için, InnoDB sıkıştırılmış sayfayı zaten arabellek havuzunda değilse diskten okur, ardından sayfayı orijinal 16K bayt formunda açar. Bu bölümde, InnoDB'nin sıkıştırılmış tabloların sayfalarına göre arabellek havuzunu nasıl yönettiği anlatılmaktadır.

G / Ç'yi en aza indirmek ve bir sayfayı açma gereksinimini azaltmak için, arabellek havuzu bazen bir veritabanı sayfasının hem sıkıştırılmış hem de sıkıştırılmamış biçimini içerir. Diğer gerekli veritabanı sayfalarına yer açmak için InnoDB, sıkıştırılmış sayfayı bellekte bırakırken, tampon havuzundan sıkıştırılmamış bir sayfayı “çıkarabilir”. Veya, bir sayfaya bir süre erişilmemişse, sayfanın sıkıştırılmış formu diğer veriler için yer açmak üzere diske yazılabilir. Bu nedenle, herhangi bir zamanda tampon havuzu, sayfanın hem sıkıştırılmış hem de sıkıştırılmamış formlarını veya sadece sayfanın sıkıştırılmış formunu veya her ikisini de içerebilir.

InnoDB, hangi sayfaların bellekte tutulacağını ve en son kullanılanlar (LRU) listesini kullanarak hangilerinin çıkarılacağını izler, böylece “sıcak” veya sık erişilen verilerin bellekte kalması sağlanır. Sıkıştırılmış tablolara erişildiğinde, InnoDB bellekteki sıkıştırılmış ve sıkıştırılmamış sayfaların uygun bir dengesini elde etmek için uyarlanabilir bir LRU algoritması kullanır. Bu uyarlanabilir algoritma, sistemin bir G / Ç veya CPU bağlı bir şekilde çalışıp çalışmadığına duyarlıdır. Amaç, CPU meşgulken sayfaları sıkıştırmak için çok fazla işlem süresi harcamayı önlemek ve CPU sıkıştırılmış sayfaları sıkıştırmak için kullanılabilecek yedek çevrimleri (zaten bellekte olabilir) olduğunda fazla G / Ç yapmaktan kaçınmaktır. Sistem G / Ç'ye bağlıyken, algoritma her iki kopyadan ziyade sayfanın sıkıştırılmamış kopyasını çıkarmayı tercih eder, diğer disk sayfalarına bellekte yer açmak için daha fazla yer açmak için. Sistem CPU'ya bağlı olduğunda, InnoDB hem sıkıştırılmış hem de sıkıştırılmamış sayfayı çıkarmayı tercih eder, böylece “sıcak” sayfalar için daha fazla bellek kullanılabilir ve bellekteki verileri yalnızca sıkıştırılmış biçimde açma gereksinimini azaltır.

InnoDB Buffer Pool'un sorguları yerine getirmek için okunan veri sayfalarını ve indeks sayfalarını yüklemesi gerektiğine dikkat edin. Bir tabloyu ve dizinlerini ilk kez okurken, sıkıştırılmış sayfa 16K'ya sıkıştırılmamalıdır. Bu, sıkıştırılmış ve sıkıştırılmamış veri sayfasındaki tampon havuzunda iki kat daha fazla veri içeriğine sahip olacağınız anlamına gelir.

Bu veri içeriğinin çoğaltılması Tampon Havuzunda devam ediyorsa , innodb_buffer_pool_size değerini, yeni sıkıştırma oranının küçük bir doğrusal faktörüyle arttırmanız gerekir . İşte nasıl:

SENARYO

  • 8G Tampon Havuzlu bir DB Sunucunuz var
  • İle sıkıştırma yaptınız key_block_size=8
    • 8olduğu 50.00%bir16
    • 50.00%ait 8GDİR4G
    • yükseltmek innodb_buffer_pool_sizeiçin 12G( 8G+ 4G)
  • İle sıkıştırma yaptınız key_block_size=4
    • 4olduğu 25.00%bir16
    • 25.00%ait 8GDİR2G
    • yükseltmek innodb_buffer_pool_sizeiçin 10G( 8G+ 2G)
  • İle sıkıştırma yaptınız key_block_size=2
    • 2olduğu 12.50%bir16
    • 12.50%ait 8GDİR1G
    • yükseltmek innodb_buffer_pool_sizeiçin 9G( 8G+ 1G)
  • İle sıkıştırma yaptınız key_block_size=1
    • 1olduğu 06.25%bir16
    • 06.25%arasında 8GIS 0.5G( 512M)
    • yükseltmek innodb_buffer_pool_sizeiçin 8704M( 8G( 8192M) + 512M)

HİKAYE SINIRLI : InnoDB Buffer Pool, yalnızca sıkıştırılmış veri ve indeks sayfalarını kullanırken ilave nefes alan odaya ihtiyaç duyar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.