it-swarm-eu.dev

Proč InnoDB ukládá všechny databáze do jednoho souboru?

Bylo výhodné, když MyISAM ukládal každou tabulku do odpovídajícího souboru. InnoDB udělal pokrok v mnoha aspektech, ale zajímalo by mě, proč InnoDB ukládá všechny databáze do jednoho souboru (ibdata1 ve výchozím stavu).

Chápu, že InnoDB bude mapovat umístění dat v souboru podle jednotlivých indexových souborů pro tabulky, ale nechápu, proč mísí všechna data do jednoho souboru. A co je důležitější, proč kombinovat data ze všech databází na serveru?

Zajímavou vlastností systému MyISAM je, že lze kopírovat/vložit složku databáze do jiného počítače a poté ji použít (bez výpisu).

55
Googlebot

Architektura InnoDB vyžaduje použití čtyř základních typů informačních stránek

  • Datové stránky tabulky
  • Stránky indexu tabulky
  • Tabulka MetaData
  • MVCC Data (pro podporu izolace transakcí a ACID shoda )
    • Vrácení segmentů
    • Vraťte zpět vesmír
    • Double Write Buffer (psaní na pozadí, aby se zabránilo spoléhání na ukládání do mezipaměti OS)
    • Vložit vyrovnávací paměť (správa změn neoriginálních sekundárních indexů)

Viz obrázkové znázornění ibdata1

Ve výchozím nastavení je innodb_file_per_table zakázáno. To způsobí, že všechny čtyři typy informačních stránek vyloží jeden soubor s názvem ibdata1. Mnoho lidí se snaží šířit data vytvořením několika souborů ibdata. To by mohlo vést k fragmentaci dat a indexových stránek.

Proto často doporučuji vyčistit infrastrukturu InnoDB pomocí výchozího souboru ibdata1 a nic víc .

Kopírování je velmi nebezpečné kvůli infrastruktuře, pod níž InnoDB funguje. Existují dvě základní infrastruktury

  • innodb_file_per_table disabled
  • innodb_file_per_table enabled

InnoDB ( innodb_file_per_table zakázáno)

Když je innodb_file_per_table deaktivováno, všechny tyto typy informací InnoDB žijí v rámci ibdata1. Jediným projevem jakékoli tabulky InnoDB mimo ibdata1 je soubor .frm tabulky InnoDB. Kopírování všech dat InnoDB najednou vyžaduje zkopírování všech/var/lib/mysql.

Kopírování jednotlivé tabulky InnoDB je naprosto nemožné. Výpis MySQL musíte extrahovat výpisem tabulky jako logickou reprezentaci dat a odpovídajících definic indexů. Pak byste tento výpis načíst do jiné databáze na stejném serveru nebo na jiném serveru.

InnoDB ( innodb_file_per_table povoleno)

Když je povoleno innodb_file_per_table , jsou data tabulky a její indexy aktivní ve složce databáze vedle souboru .frm. Například pro tabulku db1.mytable by manifest této tabulky InnoDB mimo ibdata1 byl:

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

Systémový tabulkový prostor ibdata1

Všechna metadata pro db1.mytable stále leží v ibdata1 a neexistuje absolutně žádná cesta. Redo logs a MVCC data také stále žijí s ibdata1.

Pokud jde o fragmentaci tabulky, je to, co se stane s ibdata1:

  • innodb_file_per_table enabled: můžete zmenšit db1.mytables pomocí ALTER TABLE db1.mytable ENGINE=InnoDB; nebo OPTIMIZE TABLE db1.mytable;. Výsledkem je, že /var/lib/mysql/db1/mytable.ibd je fyzicky menší bez fragmentace.
  • innodb_file_per_table vypnuto: nemůžete zmenšit db1.mytables pomocí ALTER TABLE db1.mytable ENGINE=InnoDB; nebo OPTIMIZE TABLE db1.mytable; protože to spočívá na ibdata1. Vlastně spuštěním některého příkazu uděláte z tabulky souvislou a rychlejší čtení a zápis. Bohužel k tomu dochází na konci ibdata1. Díky tomu bude ibdata1 rychle růst. Toto je plně vyřešeno v mém příspěvku InnoDB Cleanup Post .

VAROVÁNÍ (NEBEZPEČÍ jako Robot by řekl v Ztraceni ve vesmír )

Pokud uvažujete pouze o kopírování souborů .frm a .ibd, jste v souladu se světem bolí. Kopírování souborů .frm a .ibd z tabulky InnoDB je dobré pouze pokud a pouze v případě, že můžete zaručit, že ID tabulky tablespace souboru .ibd se přesně shoduje s položkou id tablespace id v metadatech soubor ibdata1.

O tomto konceptu id tabulkového prostoru jsem napsal v DBA StackExchange dva příspěvky

Zde je vynikající odkaz na to, jak znovu připojit jakýkoli soubor .ibd k ibdata1 v případě neshodujících se ID tabulkového prostoru: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in- soubor . Po přečtení této zprávy byste měli okamžitě zjistit, že kopírování souborů .ibd je prostě šílené.

Pro InnoDB potřebujete pouze něco, co se má přesunout

CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;

vytvořit kopii tabulky InnoDB.

Pokud ji migrujete na jiný DB server, použijte mysqldump.

Pokud jde o míchání všech tabulek InnoDB ze všech databází, vidím při tom skutečně moudrost. V hostitelské společnosti zaměstnavatele DB/Web mám jednoho klienta MySQL, který má tabulku v jedné databázi, jejíž omezení jsou mapována do jiné tabulky v jiné databázi v rámci stejné instance MySQL. S jedním společným úložištěm metadat umožňuje transakční podporu a funkčnost MVCC ve více databázích.

69
RolandoMySQLDBA

InnoDB můžete přepínat tak, aby ukládal tabulky do souboru přidáním innodb-file-per-table do vašeho cnf.

Innodb se opravdu stará jen o stránky dat na základní úrovni. Ve skutečnosti můžete nastavit InnoDB tak, aby používal pouze zařízení s blokovým blokem bez jakéhokoli systému souborů, co vůbec! http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html

Existují vymoženosti pro ukládání tabulek do souboru, jako je například možnost snadnějšího získání využitého prostoru pomocí optimalizace.

I se soubory v tabulce nemůžete jednoduše kopírovat soubory ibd tak snadno, protože InnoDB je transakční a ukládá informace o svém stavu do globálně sdílených souborů ibdata/log.

To neznamená, že to nelze udělat. Pokud je tabulka offline, můžete zrušit/importovat tabulkové prostory a zkopírovat .idbs kolem http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

14
atxdba

Toto je výchozí chování, ale není povinné. Z dokumenty MySQL, použití tabulkových stolů :

Ve výchozím nastavení jsou všechny tabulky a indexy InnoDB uloženy v systémovém tabulkovém prostoru. Alternativně můžete uložit každou tabulku InnoDB a její indexy do svého vlastního souboru . Tato funkce se nazývá „více tabulkových prostorů“, protože každá tabulka, která se vytvoří, když je toto nastavení platné, má svůj vlastní tabulkový prostor.

Důvodem je pravděpodobně rozdílná architektura obou motorů (MyISAM a InnoDB). Například v InnoDB nemůžete pouze zkopírovat soubor .ibd do jiné databáze nebo instalace. Vysvětlení (ze stejné stránky):

Aspekty přenositelnosti souborů .ibd

Nelze volně přesouvat soubory .ibd mezi databázovými adresáři, jak to můžete s tabulkovými soubory MyISAM. Definice tabulky uložená ve sdíleném tabulkovém prostoru InnoDB zahrnuje název databáze. ID transakcí a pořadová čísla protokolu uložená v souborech tablespace se také liší mezi databázemi.

10
ypercubeᵀᴹ