Jak na to:Vyčistit mysql úložiště InnoDB?

• Zajistí, aby data a indexy tabulky byly souvislé uvnitř ibdata1
• Vytváří ibdata1 rostou, protože souvislá data a stránky indexu jsou připojeny na ibdata1

Data tabulek a indexy tabulek však můžete oddělit od ibdata1 a spravovat je samostatně.

Mohu spustit OPTIMIZE TABULKA s innodb_file_per_table ?

Předpokládejme, že jste přidali innodb_file_per_table do /etc/my.cnf (my.ini) . Můžete pak spustit OPTIMIZE TABLE na všech tabulkách InnoDB?

Dobré zprávy :Když spustíte OPTIMIZE TABLE s innodb_file_per_table povoleno, vytvoří se .ibd soubor pro tuto tabulku. Pokud máte například tabulku mydb.mytable s datovým adresářem /var/lib/mysql , vytvoří následující:

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd

Soubor .ibd bude obsahovat datové stránky a indexové stránky pro tuto tabulku. Skvělé.

Špatné zprávy :Jediné, co jste udělali, je extrahovat datové stránky a indexové stránky mydb.mytable od života v ibdata . Záznam datového slovníku pro každou tabulku, včetně mydb.mytable , stále zůstává v datovém slovníku (viz obrazové znázornění ibdata1 ). NELZE JEDNODUŠE VYMAZAT ibdata1 V TOMTO BOD !!! Vezměte prosím na vědomí, že ibdata1 se vůbec nezmenšil.

Vyčištění infrastruktury InnoDB

Chcete-li zmenšit ibdata1 jednou provždy musíte udělat následující:

1. Dump (např. pomocí mysqldump ) všechny databáze do .sql textový soubor (SQLData.sql se používá níže)

2. Zrušte všechny databáze (kromě mysql a informační_schéma ) UPOZORNĚNÍ :Preventivně prosím spusťte tento skript, abyste se ujistili, že máte všechna uživatelská oprávnění:

   mkdir /var/lib/mysql_grants
   cp /var/lib/mysql/mysql/* /var/lib/mysql_grants/.
   chown -R mysql:mysql /var/lib/mysql_grants
   

3. Přihlaste se do mysql a spusťte SET GLOBAL innodb_fast_shutdown =0; (Tím se úplně vyprázdní všechny zbývající transakční změny z ib_logfile0 a ib_logfile1 )

4. Vypněte MySQL

5. Přidejte následující řádky do /etc/my.cnf (nebo my.ini v systému Windows)

   [mysqld]
   innodb_file_per_table
   innodb_flush_method=O_DIRECT
   innodb_log_file_size=1G
   innodb_buffer_pool_size=4G
   

   (Sidenote:Bez ohledu na to, co jste nastavili pro innodb_buffer_pool_size , ujistěte se, že innodb_log_file_size je 25 % z innodb_buffer_pool_size .

   Také:innodb_flush_method=O_DIRECT není k dispozici v systému Windows)

6. Smazat ibdata* a ib_logfile* , Volitelně můžete odstranit všechny složky v /var/lib/mysql , kromě /var/lib/mysql/mysql .

7. Spusťte MySQL (Tím se znovu vytvoří ibdata1 [10 MB ve výchozím nastavení] a ib_logfile0 a ib_logfile1 na 1G každý).

8. Importujte SQLData.sql

Nyní ibdata1 bude stále růst, ale bude obsahovat pouze metadata tabulky, protože každá tabulka InnoDB bude existovat mimo ibdata1 . ibdata1 již nebude obsahovat data InnoDB a indexy pro jiné tabulky.

Předpokládejme například, že máte tabulku InnoDB s názvem mydb.mytable . Pokud se podíváte do /var/lib/mysql/mydb , uvidíte dva soubory představující tabulku:

• mytable.frm (Záhlaví úložiště)
• mytable.ibd (Tabulková data a indexy)

Pomocí innodb_file_per_table možnost v /etc/my.cnf , můžete spustit OPTIMIZE TABLE mydb.mytable a soubor /var/lib/mysql/mydb/mytable.ibd se skutečně zmenší.

Během své kariéry jako MySQL DBA jsem to udělal mnohokrát. Ve skutečnosti, když jsem to udělal poprvé, zmenšil jsem 50 GB ibdata1 soubor na pouhých 500 MB!

Pokusit se. Pokud k tomu máte další otázky, zeptejte se. Věř mi; to bude fungovat krátkodobě i dlouhodobě.

UPOZORNĚNÍ

V kroku 6, pokud se mysql nemůže restartovat kvůli mysql schéma začíná zrušeno, podívejte se zpět na krok 2. Vytvořili jste fyzickou kopii mysql schéma. Můžete jej obnovit následovně:

mkdir /var/lib/mysql/mysql
cp /var/lib/mysql_grants/* /var/lib/mysql/mysql
chown -R mysql:mysql /var/lib/mysql/mysql

Vraťte se ke kroku 6 a pokračujte

AKTUALIZACE 2013-06-04 11:13 EDT

S ohledem na nastavení innodb_log_file_size až 25 % z innodb_buffer_pool_size v kroku 5 je obecné pravidlo spíše staré školy.

Zpět 3. července 2006 , Percona měl pěkný článek proč zvolit správnou velikost innodb_log_file_size . Později, 21. listopadu 2008 , Percona navázala dalším článkem na jak vypočítat správnou velikost na základě maximálního vytížení při zachování jedné hodiny změn .

Od té doby jsem psal příspěvky na DBA StackExchange o výpočtu velikosti protokolu a kde jsem odkazoval na tyto dva články Percona.

• 27. srpna 2012 :Správné vyladění pro 30GB tabulku InnoDB na serveru se 48GB RAM
• 17. ledna 2013 :MySQL 5.5 – Innodb – innodb_log_file_size větší než 4 GB dohromady?

Osobně bych stále šel s pravidlem 25% pro počáteční nastavení. Poté, jak lze pracovní vytížení určit v průběhu času ve výrobě přesněji, můžete změnit velikost protokoly během cyklu údržby během několika minut.