Във втората и последна част от нашите най-добри практики за mysqldump ще говорим за това как да се справяме с миграцията и импортирането на съхранени програмни обекти и изгледи от вашата MySQL база данни. За да прочетете повече за предпоставките за успешна операция за изхвърляне и възстановяване на големи MySQL бази данни, вижте първата част от тази поредица от 2 части от блогове.
Импортиране на вашите съхранени процедури, функции и тригери
По подразбиране mysqldump импортира изгледи и задействания. Той обаче не импортира процедури, функции и събития. За импортиране на процедури и функции, --routines трябва да се посочи опцията, а за импортиране на събития --events опцията трябва да бъде посочена.
1. Импортиране на тригери
Mysqldump ще се опита да изхвърли всички тригери във вашата база данни по подразбиране. За да можете да изхвърляте triggers на таблица , трябва да имате TRIGGER привилегия за масата. Ако потребителят на dump няма тази привилегия, тригерите ще бъдат пропуснати и mysqldump няма да изведе грешка. Така че не се изненадвайте, ако не видите никакви задействания, импортирани във вашата дестинационна база данни.
2. Импортиране на събития
За да импортирате събития, трябва да посочите --events опция, докато извиквате помощната програма mysqldump. Тази опция изисква EVENT привилегии за тези бази данни. Отново, mysqldump безшумно ще пропусне събития, ако потребителят на dump няма тези привилегии, дори ако сте посочили опция –event при извикване на mysqldump.
3. Импортиране на функции и съхранена процедура
За да импортирате рутинни програми, трябва да посочите --routines опция, докато извиквате помощната програма mysqldump. Тази опция изисква global select привилегии. Дори в този случай mysqldump тихо ще пропусне функции и процедури, ако потребителят на dump няма тези привилегии, дори ако сте посочили --routines опция при извикване на mysqldump.
3.1 Импортиране на недетерминирани функции
Съхранена програма, която променя данните, се нарича недетерминирана, ако не дава повторяеми резултати. Примерна функция rand(). Особено предизвикателство е да се използват такива функции в репликирани настройки, тъй като те могат да доведат до различни данни за източник и реплика. За да контролира подобни възможности, MySQL налага определени ограничения върху създаването на функции, ако двоичните регистрационни файлове са разрешени.
По подразбиране за CREATE FUNCTION изявление, което трябва да бъде прието, поне едно от DETERMINISTIC , NO SQL , или READS SQL DATA трябва да се посочи изрично. В противен случай възниква грешка:
ГРЕШКА 1418 (HY000) на ред 181:Тази функция няма ДЕТЕРМИНИСТИЧЕН, НЯМА SQL или ЧЕТЕ SQL ДАННИ в своята декларация и двоичното регистриране е активирано (може би * можете* да използвате по-малко безопасния log_bin_trust_funable)
Така че, ако вашата функция не е декларирана като детерминирана в източника и двоичното регистриране е разрешено на вашата дестинация, ще видите горната грешка по време на възстановяването на дъмп. Следователно е важно предварително да разберете детерминистичния характер на вашите функции. Ако сте сигурни, че вашите функции са детерминирани, трябва да включите log_bin_trust_function_creators конфигурация на вашата дестинация преди операцията по възстановяване. Когато е активиран, MySQL позволява създаването на такива функции, дори когато двоичното регистриране е активирано.
4. SQL SECURITY характеристика на съхранените подпрограми и изгледи.
MySQL позволява SQL SECURITY контекст, който трябва да бъде посочен при създаване на програми или изгледи на магазина. SQL SECURITY характеристиката може да бъде зададена като DEFINER или INVOKER . Ако SQL_SECURITY контекстът е DEFINER , рутината се изпълнява с помощта на привилегиите на акаунта, посочен в подпрограмата DEFINER клауза. Ако контекстът е INVOKER , рутина се изпълнява, използвайки привилегиите на потребителя, който я извиква. Стойността по подразбиране е DEFINER .
Ако възстановявате съхранени подпрограми или изгледи, трябва да се уверите, че дефиниращият потребителски акаунт съществува във вашата дестинационна база данни с подходящи разрешения. В противен случай ще срещнете неуспехи по време на възстановяване.
Нека демонстрираме това с пример, свързан с изгледи.
Да предположим, че имате изгледи V1 и V2, както е показано по-долу:
CREATE definer=admin@'%' VIEW mydb.V1 КАТО SELECT * FROM solution_table;CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1, където num1=10;
Обърнете внимание, че изгледите се изхвърлят по подразбиране от mysqldump и ако нямате потребителския 'admin' на вашата дестинация, ще срещнете следната грешка по време на операцията по възстановяване:
Командата неуспешна с грешка - ГРЕШКА 1449 (HY000) на ред 206 във файл:'/mysql_data/mysqldump/sqldump_1582457155758.sql':Потребителят, посочен като дефинер ('admin'@'%'), не съществува. /предварително> Обърнете внимание, че не е достатъчно само да се гарантира, че потребителят съществува, но потребителят трябва да има подходящи привилегии, за да изпълнява изгледите. Например, ако потребителят admin@'%' съществува на местоназначението, но няма SELECT привилегии в базата данни mydb, ще видите съобщение за грешка:
'/mysql_data/mysqldump/sqldump_1582456858033.sql':Изгледът 'mydb.V2' препраща към невалидни таблици или колони или функция(и) или дефинитор/извикване на изглед нямат права за използването им.
|
Резюме
В тази поредица от блогове от 2 части разгледахме важни предпоставки, с които трябва да се справите, за да осигурите успешна миграция на вашите данни и съхранени програми. ScaleGrid MySQL хостинг се справя с тези насоки, за да осигури гладко изживяване, докато импортирате вашите данни в платформата ScaleGrid. Моля, споделете с нас своя опит и най-добри практики, които приемате за мигриране на данни на MySQL!
