Dans la deuxième et dernière partie de nos meilleures pratiques mysqldump, nous expliquerons comment gérer la migration et l'importation d'objets et de vues de programme stockés à partir de votre base de données MySQL. Pour en savoir plus sur les conditions préalables à une opération de vidage et de restauration réussie pour les grandes bases de données MySQL, consultez la première partie de cette série de blogs en 2 parties.
Importer vos procédures stockées, fonctions et déclencheurs
Par défaut, mysqldump importe les vues et les déclencheurs. Cependant, il n'importe pas les procédures, les fonctions et les événements. Pour importer des procédures et des fonctions, le --routines l'option doit être spécifiée, et pour importer des événements, le --events l'option doit être spécifiée.
1. Importer des déclencheurs
Mysqldump tentera de vider tous les déclencheurs de votre base de données par défaut. Pour pouvoir dumper les triggers d'une table , vous devez avoir le TRIGGER privilège pour la table. Si l'utilisateur de vidage n'a pas ce privilège, les déclencheurs seront ignorés et mysqldump ne générera aucune erreur. Ne soyez donc pas surpris si vous ne voyez aucun déclencheur importé dans votre base de données de destination.
2. Importer des événements
Pour importer des événements, vous devez spécifier --events option lors de l'appel de l'utilitaire mysqldump. Cette option nécessite le EVENT privilèges pour ces bases de données. Encore une fois, mysqldump ignorera silencieusement les événements si l'utilisateur du vidage ne dispose pas de ces privilèges, même si vous avez spécifié l'option –event lors de l'appel de mysqldump.
3. Importation de fonctions et procédure stockée
Pour importer des routines, vous devez spécifier --routines option lors de l'appel de l'utilitaire mysqldump. Cette option nécessite la global select privilèges. Même dans ce cas, mysqldump ignorera silencieusement les fonctions et les procédures si l'utilisateur de vidage n'a pas ces privilèges, même si vous avez spécifié --routines option lors de l'appel de mysqldump.
3.1 Importer des fonctions non déterministes
Un programme stocké qui modifie des données est dit non déterministe s'il ne produit pas de résultats reproductibles. Exemple de fonction rand(). Il est particulièrement difficile d'utiliser de telles fonctions dans des configurations répliquées, car elles peuvent entraîner des données différentes sur la source et la réplique. Pour contrôler ces possibilités, MySQL impose certaines restrictions sur la création de fonctions si les journaux binaires sont activés.
Par défaut, pour une CREATE FUNCTION énoncé à accepter, au moins l'un des DETERMINISTIC , NO SQL , ou READS SQL DATA doit être spécifié explicitement. Sinon, une erreur se produit :
ERREUR 1418 (HY000) à la ligne 181 :Cette fonction n'a aucun DETERMINISTIC, NO SQL ou READS SQL DATA dans sa déclaration et la journalisation binaire est activée (vous *pourriez* vouloir utiliser le moins sûr log_bin_trust_funable)
Donc, si votre fonction n'est pas déclarée comme déterministe sur la source et que la journalisation binaire est activée sur votre destination, vous verrez l'erreur ci-dessus lors de la restauration du vidage. Il est donc important de comprendre dès le départ la nature déterministe de vos fonctions. Si vous êtes sûr que vos fonctions sont déterministes, vous devez activer le log_bin_trust_function_creators configuration sur votre destination avant l'opération de restauration. Lorsqu'il est activé, MySQL permet la création de telles fonctions même lorsque la journalisation binaire est activée.
4. SÉCURITÉ SQL caractéristique des routines et des vues stockées.
MySQL permet une SQL SECURITY contexte à spécifier lors de la création des programmes ou des vues du magasin. La SQL SECURITY caractéristique peut être spécifiée comme DEFINER ou INVOKER . Si le SQL_SECURITY le contexte est DEFINER , la routine s'exécute en utilisant les privilèges du compte nommé dans la routine DEFINER clause. Si le contexte est INVOKER , la routine s'exécute en utilisant les privilèges de l'utilisateur qui l'invoque. La valeur par défaut est DEFINER .
Si vous restaurez des routines ou des vues stockées, vous devez vous assurer que le compte utilisateur définisseur existe sur votre base de données de destination avec les autorisations appropriées. Sinon, vous rencontrerez des échecs lors de la restauration.
Démontrons cela avec un exemple lié aux vues.
Supposons que vous ayez défini les vues V1 et V2 comme ci-dessous :
CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table;CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 where num1=10;
Notez que les vues sont vidées par défaut par mysqldump et si vous n'avez pas l'utilisateur 'admin' sur votre destination, vous rencontrerez l'erreur ci-dessous lors de l'opération de restauration :
Échec de la commande avec erreur - ERREUR 1449 (HY000) à la ligne 206 du fichier :'/mysql_data/mysqldump/sqldump_1582457155758.sql' :l'utilisateur spécifié en tant que définisseur ('admin'@'%') n'existe pas. Notez qu'il ne suffit pas seulement de s'assurer que l'utilisateur existe, mais que l'utilisateur doit disposer des privilèges appropriés pour exécuter les vues. Par exemple si l'utilisateur admin@'%' existe sur la destination, mais n'a pas SELECT privilèges sur la base de données mydb, vous verrez un message d'erreur :
'/mysql_data/mysqldump/sqldump_1582456858033.sql' :la vue 'mydb.V2' fait référence à des tables, des colonnes ou des fonctions invalides ou le définisseur/invocateur de la vue n'a pas le droit de les utiliser.
|
Résumé
Dans cette série de blogs en 2 parties, nous avons couvert les conditions préalables importantes que vous devez gérer pour assurer une migration réussie de vos données et programmes stockés. L'hébergement ScaleGrid MySQL gère ces directives pour offrir une expérience fluide lors de l'importation de vos données sur la plate-forme ScaleGrid. Veuillez partager avec nous votre expérience et les meilleures pratiques que vous adoptez pour les migrations de données MySQL !
