Magento 2 – Importation de la base de données interrompue avec des droits SUPER manquants

Lors de l'importation d'une exportation de base de données à partir d'un autre serveur, l'erreur «ERREUR 1227 (42000) à la ligne 15126: Accès refusé; vous avez besoin (au moins un des) le privilège SUPER(s) pour cette opération "- vous avez regardé la décharge à ce stade, y a été trouvé

/*!50001 CRÉER UN ALGORITHME = NON DÉFINI */
/*!50013 DEFINER = `MEINDBUSER` @`% `SQL SECURITY INVOKER */

Le problème ici était la partie "DEFINER =` MEINDBUSER` @ `%` " (MEINDBUSER ne doit bien sûr être considéré que comme un exemple). L'utilisateur de la base de données utilisé pour l'importation et dans ce cas également l'hôte local devait être stocké ici. Ça ressemblait à ça

/*!50001 CRÉER UN ALGORITHME = NON DÉFINI */
/*!50013 DEFINER = MEINDBUSERNEU @ localhost SQL SECURITY INVOKER */

Il était également important de supprimer les citations individuelles, que seul MEINDBUSERNEU @ localhost y a été laissé. Ensuite, l'importation a fonctionné sans aucun problème.

Mise à jour de 11.05.2020

Maintenant, ce problème est revenu, mais pas si facile cette fois. La partie déclenchante de l'erreur lors de l'importation de la base de données était cette fois:

/*!50003 CRÉER*/ /*!50017 DEFINER = '[MEINDBUSER]`@` localhost` * / /*!50003 TRIGGER trg_catalog_category_entity_after_insert APRÈS INSÉRER SUR catalog_category_entity POUR CHAQUE RANG

Le Definer était maintenant très courant - et pas seulement une fois comme dans la partie précédente- appelé.

Il y avait donc deux options:

1. Empêcher, que lors de la sauvegarde / Le vidage de la base de données de ces utilisateurs de base de données est écrit dans le fichier de sauvegarde OU
2. Supprimez ensuite l'utilisateur du fichier, puis importez-le.

Il existe des options pour les deux. J'ai créé le fichier de sauvegarde moi-même à l'aide de la commande SSH, Je peux ajuster un peu la commande et la réaliser, qu'aucun utilisateur concret mais “Utilisateur actuel” on utilise. La commande serait celle-ci:

mysqldump -u "[Utilisateur]" --opt --single-transaction --password ="[Mot de passe]" -h "[Hôte z.B. localhost]" "[Nom de la base de données]" | sed -E 's / DEFINER ='[^ `]+`@`[^ `]+`/ DEFINER = CURRENT_USER / g ' | gzip -9 > DATEINAME.sql.gz;

Cela crée une sauvegarde de base de données avec le nom DATEINAME.sql.gz (il est donc emballé tout de suite). Lors de la création du fichier, la commande SED transforme les données utilisateur définies par la base de données par rapport aux données générales “UTILISATEUR ACTUEL”-Informations échangées. Ainsi, le fichier peut être importé plus tard. (Pour décompresser à nouveau le fichier sur le serveur cible “gunzip DATEINAME.sql.zip” entrer. Je n'ai probablement pas besoin de mentionner que, que le nom peut être librement attribué. De même, les supports d'espace entre crochets INCL. les parenthèses sont remplacées par leurs propres données.)

Mais je dois réviser le fichier SQL fini, les importer, Je peux le faire via SSH avec la commande suivante et obtenir le même résultat que ci-dessus

sed -E 's / DEFINER ='[^ `]+`@`[^ `]+`/ DEFINER = CURRENT_USER / g 'DATEINAME.sql > Nom de fichier new.sql

Pour des raisons de sécurité, le fichier n'est pas simplement écrasé, un nouveau fichier est créé, qui porte le nom FILENAMEnew.sql.

Mise à jour de 04.05.2021

Aujourd'hui nous avons encore eu ce problème lors de la création d'une boutique test. Une erreur s'est produite lors de l'importation de la base de données de la boutique en direct dans la nouvelle base de données

ERROR 1227 (42000) at line 717: Access denied; you need (at least one of) the SU          PER privilege(s) for this operation

Nous avons ensuite déterré à nouveau cet article et avons maintenant une possibilité, pour étendre un peu cela avec une nouvelle possibilité de résoudre ce problème. La commande suivante supprime toutes les références à l'utilisateur et ainsi une importation est possible sans aucun problème:

 sed -i.bak -e "s/\/\*[^*]*DEFINER=[^*]*\*\///" meindumpfile.sql