it-swarm-eu.dev

Jak obnovit tabulku InnoDB, jejíž soubory byly přesunuty

Mám tedy testovací server db, který byl nastaven na replikačním proudu. Přes jméno přišla optimalizace, která rychle zaplnila prostor na datadiru otroků. Mysql poslušně čekal na další prostor.

Tento datadir je souborový systém používaný POUZE jako datadir mysql, takže nebylo co uvolnit.

Měl jsem zkušební tabulku pro 4 koncerty, která nebyla součástí proudu replikace, takže jsem si myslel, že zkusím něco zjistit, jestli to bude fungovat, a jako testovací prostředí jsem se příliš nebál, kdyby se věci strašně pokazily.

Zde jsou kroky, které jsem podnikl

  1. Propláchl stůl, který jsem se chystal pohnout
  2. Umístil na něj zámek pro čtení (i když na něj nic nenapsalo a nebylo v replikačním proudu)
  3. Zkopírovali .frm a .ibd do souborového systému s nějakou volnou místností
  4. Odemkl stůl
  5. Zkrácená tabulka - to uvolnilo dostatek místa pro dokončení optimalizace, aby se replikace mohla začít znovu chugging.
  6. Přestaňte otrokovat/vypínat mysql
  7. Zkopírujte soubor z tmp zpět do datového adresáře
  8. Restartujte mysql

V protokolu .err se nic neobjevuje, věci vypadají dobře. Připojuji a používám mydb; a podívejte se na tabulku, se kterou jsem si pohrával, v tabulkách. Ale pokud to zkusím

select * from testtable limit 10;

Dostal jsem chybu

ERROR 1146 (42S02): Table 'mydb.testtable' doesn't exist

Z toho, co mohu prozradit, dokážu číst ze všech ostatních tabulek v pořádku a replikace začala zálohovat bez stížností.

Existuje něco, co mohu udělat, abych se z tohoto bodu zotavil? Pokud to bude potřeba, dokážu to znovu vytvořit od nuly, ale byl jsem zvědavý, co si ostatní o tomto podniku obecně myslí. Bylo něco o sérii kroků, které jsem podnikl, které by skončily bezchybnými výsledky?

Co kdyby to nebyl testovací server, nemohl bych jen „to udělat naživo“ a zjistit, co se stane? Jaký by byl nejlepší způsob, jak dočasně uvolnit místo na produkčním otrokovi, kdybych to měl rád?

14
atxdba

Největší věc, kterou většina lidí zapomíná na TRUNCATE TABLE, je to, že TRUNCATE TABLE je DDL a ne DML . V InnoDB obsahují metadata v ibdata1 číslovaný seznam InnoDB tabulek. Použití TRUNCATE TABLE způsobí posun interního ID metadat tabulky InnoDB. K tomu dochází, protože TRUNCATE TABLE účinně provádí následující:

Příklad: Zkrácení tabulky InnoDB nazvané mydb.mytb

USE mydb
CREATE TABLE newtb LIKE mytb;
ALTER TABLE mytb RENAME oldtb;
ALTER TABLE newtb RENAME mytb;
DROP TABLE oldtb;

Nový mytb by tedy měl jiné ID interních metadat.

Když jste zkopírovali soubor .ibd na jiné místo, obsahuje .ibd v něm původní interní ID metadat. Jednoduše vrácení souboru .ibd nezpůsobí sladění ID interních metadat s tím, které je uvedeno v ibdata1.

Co byste měli udělat, je toto:

Zkopírujte soubor .ibd tabulky InnoDB. Potom to spusťte

ALTER TABLE tablename DISCARD TABLESPACE;

Chcete-li jej vrátit později, zkopírujte soubor .ibd zpět do datadiru a poté spusťte

ALTER TABLE tablename IMPORT TABLESPACE;

To by zachovalo vnitřní ID metadat.

Ujistěte se, že .frm je vždy přítomen.

Jednou jsem pomohl klientovi obnovit 30 InnoDB tabulek, které hosed stejným způsobem. Musel jsem použít jiný DB server a hrát nějaké hry s přidáváním a klesáním tabulek InnoDB, abych sháněl správné interní ID metadat.

Klient našel tento článek: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Použili jsme to a hodně to pomohlo. Doufám, že vám to pomůže.

15
RolandoMySQLDBA