Doporučené postupy mysqldump:Část 1 – Předpoklady pro MySQL

Mysqldump je klientský nástroj, který se používá k provádění logických záloh databáze MySQL. Tento oblíbený migrační nástroj je užitečný pro různé případy použití MySQL, jako jsou:

• Zálohování a obnova databází.
• Migrace dat z jednoho serveru na druhý.
• Migrace dat mezi různými poskytovateli spravovaných služeb MySQL.
• Migrace dat mezi různými verzemi MySQL.

Mysqldump funguje tak, že čte objekty zdrojové databáze a generuje sadu příkazů SQL, které jsou uloženy v souboru výpisu. Přehráním těchto příkazů na cílovém databázovém serveru se rekonstruují původní data. Vzhledem k tomu, že tento model využívá čtení celé databáze a poté v podstatě opětovné sestavení, jsou u velké databáze jak výpis, tak obnova časově náročné operace. Tento proces se může dokonce stát těžkopádným, pokud během výpisu nebo obnovy narazíte na chyby, protože to může vést k vyřešení problémů a opětovnému spuštění operací. To je důvod, proč je důležité dobře naplánovat, než spustíte výpis a obnovíte aktivitu.

V této dvoudílné sérii blogů diskutujeme o některých běžných aspektech, které byste měli zvládnout předem, abyste zajistili úspěšnou činnost výpisu a obnovení. V první části se zaměříme na předpoklady, které musíte dodržovat při importu dat tabulky MySQL a ve druhé části si povíme, jak zvládnout import uložených programových objektů a pohledů.

1. Požadavky na prostor

Zaprvé je důležité zajistit, aby objem cílové databáze měl dostatek místa pro uložení importovaných dat. Konkrétně musíte být opatrní, pokud jsou v cílové databázi MySQL povoleny binární protokoly, protože binární protokoly generované při importu dat mohou mít téměř stejnou velikost jako samotná data. Binární protokoly jsou potřebné, pokud chcete obnovit data na jednom serveru a chcete, aby byla replikována. V takových případech je dobré naplánovat velikost cíle větší než dvojnásobek velikosti zdrojové databáze.

Je také důležité zajistit dostatek místa na svazku, kde generujete výstupní soubor mysqldump. Bez těchto opatření se může stát, že po dlouhé době běhu selže výpis nebo obnova kvůli nedostatku místa, což znamená ztrátu vašeho produktivního času a úsilí.

2. Sql_mode

Nastavení sql_mode pro server MySQL určují syntaxi příkazů SQL a kontroly ověření dat, které server pro operace provádí. Je důležité zajistit sql_mode zdrojových a cílových serverů MySQL jsou vzájemně kompatibilní, nebo se můžete setkat se selháním při obnově uloženého výpisu. Ukažme si to na příkladu.

Řekněme, že máte ve svém zdroji tabulku, která má sloupec data obsahující nula dat:

mysql> zobrazit vytvoření tabulky sched;---------------------------------------- -----------------+| Tabulka | Vytvořit tabulku |----------------------------------------------- ---------+| naplánováno | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL) ENGINE=InnoDB VÝCHOZÍ CHARSET=latin1 |+-------+----------- -------------------------------------------------- -------------------------------------------------- -------mysql> vyberte * ze sched;+------+------------+| id | ts |+------+------------+| 1 | 2020-01-12 || 2 | 0000-00-00 |+------+------------+

Předpokládejme, že přísný sql_mode (a NO_ZERO_DATE ) je ve zdroji zakázána, ale v cíli povolena – obnovení takových řádků bude mít za následek selhání, například:

CHYBA 1292 (2007) na řádku 40:Nesprávná hodnota data:'0000-00-00' pro sloupec 'ts'' na řádku 2

Takové problémy obvykle zaznamenáte, pokud vytváříte kompaktní výpis, když povolíte možnost kompaktní jako součást vašeho mysqldump.

Pokud je kompakt deaktivován (což je ve výchozím nastavení), nebudete tomuto problému čelit, protože mysqldump generuje následující podmíněný příkaz jako součást výpisu:

/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;

To znamená, že během obnovy sql_mode je nastaven na 'NO_AUTO_VALUE_ON_ZERO' před obnovením dat tabulky, takže obnovení proběhne v pořádku.

3. Unique_checks a Foreign_key_checks

Ve výchozím nastavení (pokud nepoužijete možnost –compact) nastavuje mysqldump také následující:

/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

Jak je zde vysvětleno, operaci obnovy můžete urychlit dočasným vypnutím kontrol jedinečnosti během relace. U velkých tabulek to ušetří spoustu diskových I/O, protože InnoDB může použít svůj change buffer k zápisu sekundárních indexových záznamů v dávce.

Pokud máte FOREIGN KEY omezení ve vašich tabulkách můžete urychlit operaci obnovy tabulky vypnutím kontrol cizího klíče po dobu trvání relace obnovy:U velkých tabulek to může ušetřit spoustu diskových I/O.

Deaktivace FOREIGN_KEY_CHECKS také pomůže vyhnout se chybám kvůli kontrolám omezení klíče foregin během operace obnovy. Kdykoli je vytvořena tabulka s omezením foregin key, MySQL očekává, že nadřazená tabulka, na kterou se odkazuje foregin key, již existuje. To je problém, protože obslužný program mysqldump vypisuje tabulky v abecedním pořadí. Ukažme si to na příkladu.

Ve zdrojové databázi máme dvě tabulky:

CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) VÝCHOZÍ NULL, PRIMÁRNÍ KLÍČ (`num1`));CREATE TABLE `ref_table` ( `key` int(11) ) VÝCHOZÍ NULL, `ref_num` int(11) VÝCHOZÍ NULL, KLÍČ `ref_num` (`ref_num`), OMEZENÍ `ref_num_ibfk_1` CIZÍ KLÍČ (`ref_num`) REFERENCE `solution_table` (`num1`))) 
Tabulka ref_table má omezení cizího klíče, které odkazuje na solution_table . Na základě abecedního pořadí mysqldump nejprve vypíše obsah ref_table . Když je toto znovu přehráno v době obnovy, selže s chybou:
 
CHYBA 1215 (HY000) na řádku 50:Nelze přidat omezení cizího klíče - 
 
Což se stane při provádění příkazu create table pro ‘ref_table’ .
 
V souhrnu mějte na paměti, s jakými problémy se můžete setkat, pokud zadáte --compact možnost při spuštění mysqldump.
 
4. Oprávnění požadovaná pro spuštění mysqldump
 
Minimální oprávnění vyžadované službou mysqldump pro ukládání databáze je SELECT v této databázi.
 
Pokud má vaše databáze pohledy, budete potřebovat také oprávnění SHOW VIEW, protože mysqldump vždy vypíše pohledy spolu s tabulkami databáze. Předpokládejme, že nemáte SHOW VIEW oprávnění, pak mysqldump selže s:
 
 mysqldump:Nelze provést 'show create table `ivew`':Příkaz SHOW VIEW odepřen uživateli 'dumpuser'@'172.31.18.79' pro tabulku 'iview' (1142)
 
Dalším bodem zájmu je, pokud má váš sklápěč SELECT oprávnění pouze pro konkrétní tabulku databáze, mysqldump vypíše data pouze pro tuto konkrétní tabulku a automaticky ignoruje všechny ostatní tabulky nebo pohledy.
 
Zajistěte tedy, aby uživatel spouštějící mysqldump měl předem všechna příslušná oprávnění, abyste se později vyhnuli případným překvapením nebo selháním.
 
 
 
 
Máte zájem o plně spravované řešení MySQL?
 

 Chcete-li se dozvědět více o tom, jak vám poskytovatel DBaaS, jako je ScaleGrid, může pomoci spravovat vaše databáze MySQL, podívejte se na naši stránku MySQL. Podívejte se, jak vám ScaleGrid umožní soustředit se více na vývoj vašeho produktu a méně na správu databází.
 

 
 
 
 
 
 
 
 
 
5. Max_allowed_packet
 
Největší komunikační paket zpracovávaný mysql je určen nastavením max_allowed_packet . V kontextu importu je komunikační paket jeden příkaz SQL odeslaný na server MySQL během obnovy NEBO jeden řádek, který je odeslán klientovi během výpisu.
 
Výchozí hodnota max_allowed_packet pro mysqldump je 24 MB. pokud mysqldump přijme paket větší než tento, můžete narazit na chybu:
 
mysqldump:Chyba 2020:Získal paket větší než 'max_allowed_packet' bajtů při vyhazování tabulky ,huge1` na řádku:2.
 
Zajistěte tedy, aby mysqldump používal stejnou nebo větší hodnotu max_allowed_packet který je nakonfigurován na zdrojové instanci MySQL.
 
Možnost lze zadat příznakem --max-allowed-packet=value při vyvolání mysqldump.
 
Při obnově výpisu se ujistěte, že max_allowed_packet velikost vašeho cílového serveru je dostatečně velká, aby mohla přijímat pakety ze souboru výpisu.
 
V opačném případě se během obnovy výpisu zobrazí chybová zpráva:
 
CHYBA 2006 (HY000) na řádku 70:MySQL server zmizel
 
Tato chyba může být trochu zavádějící, protože si můžete myslet, že se server MySQL vypnul nebo zhroutil. Znamená to však, že server přijal paket větší velikosti, než je jeho nakonfigurovaná velikost max_allowed_packet . Opět platí, že nejlepším postupem je zajistit, aby max_allowed_packet hodnota pro váš cílový server je stejná jako hodnota na zdrojovém serveru. Toto je také důležité nastavení, které lze zkontrolovat a vhodně nastavit předem, namísto toho, abyste se s chybami setkali později.
 
V této první části série mysqldump jsme probrali předpoklady pro úspěšnou operaci výpisu a obnovení pro velké databáze MySQL, abychom vám pomohli vyhnout se vícenásobným pokusům a neproduktivnímu strávenému času.
 
V další části probereme osvědčené postupy pro import uložených programů a pohledů z vaší databáze MySQL.