Най-добри практики на mysqldump:Част 1

Mysqldump е клиентска помощна програма, която се използва за извършване на логически архиви на базата данни MySQL. Този популярен инструмент за мигриране е полезен за различни случаи на използване на MySQL като:

Архивиране и възстановяване на бази данни.
Мигриране на данни от един сървър на друг.
Мигриране на данни между различни управлявани MySQL доставчици на услуги.
Мигриране на данни между различни версии на MySQL.

Mysqldump работи, като чете изходните обекти на базата данни и генерира набор от SQL изрази, които се съхраняват в дъмп файл. Чрез възпроизвеждане на тези изрази на целевия сървър на база данни, оригиналните данни се възстановяват. Тъй като този модел използва четене на цялата база данни и след това по същество повторно изграждане, както изхвърлянето, така и възстановяването са отнемащи време операции за голяма база данни. Процесът може дори да стане тромав, ако срещнете грешки по време на изхвърляне или възстановяване, тъй като това може да ви накара да отстраните проблемите и да стартирате отново операциите. Ето защо е важно да планирате добре, преди да започнете изхвърлянето и да възстановите дейността.

В тази поредица от блогове от 2 части ние обсъждаме някои от често срещаните аспекти, с които трябва да се справите предварително, за да осигурите успешно изхвърляне и възстановяване. В първата част се фокусираме върху предпоставките, за които трябва да се погрижите, докато импортирате данните от MySQL таблицата, а във втората част ще говорим за това как да се справяме с импортирането за съхранени програмни обекти и изгледи.

1. Изисквания за пространство

Първо, важно е да се уверите, че обемът на вашата дестинационна база данни има достатъчно място за съхранение на импортираните данни. По-конкретно, трябва да бъдете внимателни, ако двоичните регистрационни файлове са активирани във вашата дестинационна MySQL база данни, тъй като двоичните регистрационни файлове, генерирани по време на импортиране на данните, може да заемат почти същия размер като самите данни. Двоични регистрационни файлове са необходими, ако искате да възстановите данните си на един сървър и искате те да бъдат репликирани. В такива случаи е добра идея да планирате размера на дестинацията, по-голям от два пъти размера на изходната база данни.

Важно е също така да се уверите, че има достатъчно място на тома, където генерирате изходния файл mysqldump. Без тези предпазни мерки може да видите, че изхвърлянето или възстановяването ви се проваля поради недостатъчно място след продължителна работа, което е загуба на вашето продуктивно време и усилия.

2. Sql_mode

Настройките на sql_mode за MySQL сървър определят синтаксиса на SQL израза и проверките за проверка на данните, които сървърът изпълнява за операциите. Важно е да осигурите sql_mode на изходните и дестинационните MySQL сървъри са съвместими помежду си или може да срещнете неуспехи, докато възстановявате дъмпа, който сте взели. Нека демонстрираме това с пример.

Да кажем, че имате таблица във вашия източник, която има колона с дата, която има записи като нулеви дати:

mysql> показване на график за създаване на таблица;--------------------------------------- ----------------+| Таблица | Създаване на таблица |------------------------------------------------------- ---------+| график | СЪЗДАВАНЕ НА ТАБЛИЦА `sched` ( `id` int(11) ПО ПОДРАЗБИРАНЕ NULL, `ts` дата ПО ПОДРАЗБИРАНЕ NULL) ENGINE=InnoDB СИСТЕМА ПО ПОДРАЗБИРАНЕ=latin1 |+-------+---------- -------------------------------------------------- -------------------------------------------------- -------mysql> изберете * от график;+------+------------+| ID | ts |+------+------------+| 1 | 12.01.2020 || 2 | 0000-00-00 |+------+-----------+

Да предположим, че стриктният sql_mode (и NO_ZERO_DATE ) е деактивиран в източника, но е активиран на местоназначението – възстановяването на такива редове ще доведе до неуспех като:

ГРЕШКА 1292 (22007) на ред 40:Неправилна стойност на датата:„0000-00-00“ за колона „ts“ на ред 2

Обикновено ще видите такива проблеми, ако правите компактен дъмп, като активирате компактната опция като част от вашия mysqldump.

Ако compact е деактивиран (което е по подразбиране), тогава няма да се сблъскате с този проблем, тъй като mysqldump генерира следното условно изявление като част от dump:

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

Това означава, че по време на възстановяването sql_mode е зададен на 'NO_AUTO_VALUE_ON_ZERO' преди да възстановите данните на таблицата, така че възстановяването преминава добре.

Най-добра практика за mysqldump:Част 1 - Предпоставки за MySQL Щракнете за Tweet

3. Unique_checks и external_key_checks

По подразбиране (ако не използвате опция –compact), mysqldump също задава следното:

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

Както е обяснено тук, можете да ускорите операцията по възстановяване, като временно изключите проверките за уникалност по време на сесията. За големи таблици това спестява много дисков вход/изход, тъй като InnoDB може да използва своя буфер за промяна за запис на вторични индексни записи в пакет.

Ако имате FOREIGN KEY ограничения във вашите таблици, можете да ускорите операцията по възстановяване на таблицата, като изключите проверките на външния ключ за продължителността на сесията за възстановяване:За големи таблици това може да спести много I/O диск.

Деактивиране на FOREIGN_KEY_CHECKS също така ще помогне да се избегнат грешки, дължащи се на проверките на ограниченията на външния ключ по време на операцията по възстановяване. Всеки път, когато се създаде таблица с ограничение на предния ключ, MySQL очаква, че родителската таблица, която се позовава от предния ключ, вече съществува. Това е проблем, тъй като помощната програма mysqldump изхвърля таблиците по азбучен ред. Нека вземем пример, за да демонстрираме това.

В изходната база данни имаме две таблици:

СЪЗДАВАНЕ НА ТАБЛИЦА `таблица_решения` ( `num1` int(11) НЕ NULL, `num2` int(11) ПО ПОДРАЗБИРАНЕ NULL, ПЪРВИЧЕН КЛЮЧ (`num1`));СЪЗДАВАНЕ НА ТАБЛИЦА `ref_table` ( `ключ` int(11) ) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` ВЪНШЕН КЛЮЧ (`ref_num`) РЕФЕРЕНЦИИ `solution_table`)Таблицата ref_table има ограничение за външен ключ, което препраща към solution_table . Въз основа на азбучния ред, mysqldump първо изхвърля съдържанието на ref_table . Когато това се възпроизведе по време на възстановяването, то ще се провали с грешката:

ГРЕШКА 1215 (HY000) на ред 50:Не може да се добави ограничение за външен ключ -

Което се случва, докато се изпълнява изразът create table за ‘ref_table’ .

В обобщение, имайте предвид проблемите, които може да срещнете, ако посочите --compact опция, докато изпълнявате mysqldump.

4. Необходими права за стартиране на mysqldump

Минималната привилегия, изисквана от mysqldump за изхвърляне на база данни е SELECT в тази база данни.

Въпреки това, ако вашата база данни има изгледи, ще ви трябват и разрешения SHOW VIEW, тъй като mysqldump винаги изхвърля изгледи заедно с таблиците на базата данни. Да предположим, че нямате SHOW VIEW разрешения, тогава mysqldump ще се провали с:

 mysqldump:Не можа да се изпълни 'show create table `ivew`':команда SHOW VIEW е отказана на потребителя 'dumpuser'@'172.31.18.79' за таблица 'iview' (1142)

Друг интересен момент е, ако вашият дъмпусър има SELECT разрешения само за определена таблица от базата данни, mysqldump ще изхвърли данни само за тази конкретна таблица и автоматично игнорира всички други таблици или изгледи.

Така че, моля, уверете се, че потребителят, изпълняващ mysqldump, има предварително всички подходящи привилегии, за да избегнете изненади или неуспехи в по-късен момент.

Интересувате ли се от напълно управлявано MySQL решение?

За да научите повече за това как доставчик на DBaaS като ScaleGrid може да ви помогне да управлявате вашите MySQL бази данни, вижте нашата страница MySQL. Вижте как ScaleGrid може да ви позволи да се съсредоточите повече върху разработването на вашия продукт и по-малко върху управлението на бази данни.

5. Max_allowed_packet

Най-големият комуникационен пакет, обработван от mysql, се определя от настройката max_allowed_packet . В контекста на импортирането комуникационният пакет е единичен SQL израз, изпратен до MySQL сървъра по време на възстановяването ИЛИ един ред, който се изпраща на клиента по време на изхвърлянето.

Стойността по подразбиране на max_allowed_packet за mysqldump е 24MB. ако mysqldump получи пакет, по-голям от този, тогава може да срещнете грешката:

mysqldump:Грешка 2020:Получих пакет, по-голям от байтове 'max_allowed_packet' при изхвърляне на таблица `huge1` на ред:2.

Така че се уверете, че mysqldump използва същата или по-голяма стойност на max_allowed_packet който е конфигуриран в изходния екземпляр на MySQL.

Опцията може да бъде посочена с флага --max-allowed-packet=value при извикване на mysqldump.

Когато възстановявате дъмпа, уверете се, че max_allowed_packet размерът на вашия дестинационен сървър е достатъчно голям, за да получи пакетите от дъмп файла.

В противен случай, по време на възстановяването на дъмп, ще видите съобщение за грешка:

ГРЕШКА 2006 (HY000) на ред 70:MySQL сървърът е изчезнал

Тази грешка може да бъде малко подвеждаща, тъй като може да си помислите, че MySQL сървърът е изключен или се е сринал. Но това просто означава, че сървърът е получил пакет с по-голям размер от конфигурирания му размер на max_allowed_packet . Отново, най-добрата практика е да се гарантира, че max_allowed_packet стойността за вашия дестинационен сървър е същата като стойността в изходния сървър. Това също е важна настройка, която може да бъде проверена и зададена по подходящ начин предварително, вместо да се сблъсква с грешките по-късно.

В тази първа част от поредицата mysqldump обсъдихме предпоставките за успешно изхвърляне и възстановяване на големи MySQL бази данни, за да ви помогнем да избегнете множество опити и непродуктивно прекарано време.

В следващата част ще обсъдим най-добрите практики за импортиране на съхранените програми и изгледи от вашата MySQL база данни.