Nella seconda e ultima parte delle nostre best practices di mysqldump parleremo di come gestire la migrazione e l'importazione per gli oggetti di programma memorizzati e le viste dal tuo database MySQL. Per ulteriori informazioni sui prerequisiti per un'operazione di dump e ripristino di successo per database MySQL di grandi dimensioni, dai un'occhiata alla prima parte di questa serie di blog in 2 parti.
Importazione di stored procedure, funzioni e trigger
Per impostazione predefinita, mysqldump importa viste e trigger. Tuttavia non importa procedure, funzioni ed eventi. Per importare procedure e funzioni, le --routines deve essere specificata l'opzione e, per importare eventi, il --events l'opzione deve essere specificata.
1. Importazione di trigger
Mysqldump tenterà di eseguire il dump di tutti i trigger nel database per impostazione predefinita. Per poter scaricare i triggers di una tabella , devi avere il TRIGGER privilegio per la tavola. Se l'utente dump non dispone di questo privilegio, i trigger verranno ignorati e mysqldump non genererà alcun errore. Quindi non sorprenderti se non vedi alcun trigger importato nel tuo database di destinazione.
2. Importazione di eventi
Per importare eventi, devi specificare --events opzione mentre si richiama l'utilità mysqldump. Questa opzione richiede il EVENT privilegi per quei database. Anche in questo caso, mysqldump salterà silenziosamente gli eventi se l'utente dump non dispone di questi privilegi, anche se hai specificato l'opzione –event durante il richiamo di mysqldump.
3. Importazione di funzioni e stored procedure
Per importare le routine, devi specificare --routines opzione mentre si richiama l'utilità mysqldump. Questa opzione richiede la global select privilegi. Anche in questo caso, mysqldump salterà silenziosamente funzioni e procedure se l'utente dump non ha questi privilegi, anche se hai specificato --routines opzione quando si richiama mysqldump.
3.1 Importazione di funzioni non deterministiche
Un programma memorizzato che modifica i dati è detto non deterministico se non produce risultati ripetibili. Esempio di funzione rand(). È particolarmente difficile utilizzare tali funzioni in configurazioni replicate, poiché possono generare dati diversi sull'origine e sulla replica. Per controllare tali possibilità, MySQL impone alcune restrizioni alla creazione di funzioni se i log binari sono abilitati.
Per impostazione predefinita, per un CREATE FUNCTION dichiarazione da accettare, almeno una tra DETERMINISTIC , NO SQL o READS SQL DATA deve essere specificato in modo esplicito. In caso contrario si verifica un errore:
ERROR 1418 (HY000) at line 181: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_funable)
Quindi, se la tua funzione non è dichiarata come deterministica sull'origine e la registrazione binaria è abilitata sulla tua destinazione, vedrai l'errore sopra riportato durante il ripristino del dump. Quindi è importante capire in anticipo la natura deterministica delle tue funzioni. Se sei sicuro che le tue funzioni siano deterministiche, devi attivare log_bin_trust_function_creators configurazione sulla destinazione prima dell'operazione di ripristino. Se abilitato, MySQL consente la creazione di tali funzioni anche quando è abilitato il logging binario.
4. SQL SECURITY caratteristica delle routine e delle viste memorizzate.
MySQL consente una SQL SECURITY contesto da specificare durante la creazione dei programmi o viste del negozio. Il SQL SECURITY la caratteristica può essere specificata come DEFINER o INVOKER . Se il SQL_SECURITY il contesto è DEFINER , la routine viene eseguita utilizzando i privilegi dell'account denominato nella routine DEFINER clausola. Se il contesto è INVOKER , la routine viene eseguita utilizzando i privilegi dell'utente che la invoca. Il valore predefinito è DEFINER .
Se stai ripristinando le routine o le viste memorizzate, devi assicurarti che l'account utente del definitore esista sul tuo database di destinazione con le autorizzazioni appropriate. In caso contrario, si verificheranno errori durante il ripristino.
Dimostriamolo con un esempio relativo alle visualizzazioni.
Supponiamo che le viste V1 e V2 siano definite come di seguito:
CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table; CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 where num1=10;
Nota che le viste vengono scaricate per impostazione predefinita da mysqldump e se non hai l'utente 'admin' sulla tua destinazione, riscontrerai il seguente errore durante l'operazione di ripristino:
Command failed with error - ERROR 1449 (HY000) at line 206 in file: '/mysql_data/mysqldump/sqldump_1582457155758.sql': The user specified as a definer ('admin'@'%') does not exist. Si noti che non è solo sufficiente per assicurarsi che l'utente esista, ma che l'utente deve disporre dei privilegi appropriati per eseguire le viste. Ad esempio se l'utente admin@'%' esiste sulla destinazione, ma non ha SELECT privilegi sul database mydb, vedrai un messaggio di errore:
'/mysql_data/mysqldump/sqldump_1582456858033.sql':View 'mydb.V2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them.
|
Riepilogo
In questa serie di blog in 2 parti, abbiamo trattato importanti prerequisiti che devi gestire per garantire la corretta migrazione dei tuoi dati e dei programmi archiviati. L'hosting ScaleGrid MySQL gestisce queste linee guida per fornire un'esperienza fluida durante l'importazione dei dati nella piattaforma ScaleGrid. Condividi con noi la tua esperienza e le best practice che adotti per le migrazioni dei dati MySQL!
