Не восстанавливает бекап базы если в ней есть хранимые процедуры

[svtol]

При

• восстановлении бекапа
• импорте пользователя
• импорте базы через ISP

срубается с ошибкой

MySQL database database:
Could not restore a database from backup. Process ended with an error: 'ERROR 1227 (42000) at line 3255: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
' 

в строке этой:

/*!50003 CREATE */ /*!50017 DEFINER=`gotti`@`localhost` */ /*!50003 TRIGGER `new_order` AFTER INSERT ON `oc_order` FOR EACH ROW INSERT IGNORE INTO gotti.1c_order_log Set shop = database(), date_added = NOW(), order_id = NEW.order_id, total = NEW.total, order_status_id = NEW.order_status_id */;;
/*!50003 SET SESSION SQL_MODE="" */;; 

повторяется даже на чистом и новом ISP
Если делаю то же самое руками от юзера gotti или root - все ок.

ISPmanager Lite
Операционная система - CentOS 7.3.1611.el7.centos (x86_64)
Репозиторий - ispsystem-stable5
Версия COREmanager - 5.104.1-2017.05.19_15:50
Версия панели - 5.104.5-2017.05.26_15:23
Версия сервера: 5.5.52-MariaDB - MariaDB Server

Вопросы:
1. Под каким таким пользователем заливается бекап если
2017-06-12_11-56-12.jpg
2. Что делать что бы бекапы восстанавливались из ISP (30 баз ручками что-то совсем не хочется)

[Dasha]

Здравствуйте. Здесь, к сожалению, все упирается в логику работы панели, поэтому обойти данную проблему никак не получится. Бэкап разворачивается из-под уровня пользователя, а MySQL для того, чтобы восстановить базу из дампа, которая содержит триггеры, нужен уровень выше. Тоже самое и с импортом.
Могу только посоветовать работать с подобными базами вручную.

[svtol]

выдать права пользователю/как-то использовать coremgr пользователя - не получится?

[Fly]

Речь о пользователе mysql. Восстанавливать данные от суперпользователя Mysql не безопасно. COREmanager тут не при чем.

[clydebarrow]

Пользуясь случаем сообщу, что панель бэкапит триггеры, а конкретные процедуры - нет. Это нормально?

[Fly]

Выше ведь как раз рассказано почему этого нельзя сделать )

[Gremlin]

3 года прошло, воз и ныне там.
Скажите пожалуйста какой именно уровень пользователя вы имеете ввиду?

демонстрирую:

база создана под пользователем test в ispmanager
в ispmanager у пользователя базы данных testdb (пользователь именуется так же testdb) стоит галочка TRIGGER в привилегиях
поставлена cms magento в базе у которой есть триггеры
далее делаем дамп этой базы, после пробуем залить этот дамп вручную через консоль под пользователем test (в ssh под пользователем test):

-bash-4.2$ id
uid=507(test) gid=507(test) группы=507(test),1000(mgrsecure)
-bash-4.2$ mysql -utestdb -p testdb < testdb.sql
Enter password:
-bash-4.2$

далее идём в ispmanager, авторизируемся под пользователем test в панель, переходим в Резервные копии, переходим внутрь последнего бэкапа, выбираем базы данных, жмём восстановить базу testdb
смотрим лог ispmanager, видим:

May 19 01:57:46 [6268:1057] db ERROR query error: Trigger in wrong schema
May 19 01:57:46 [6268:1057] libmgr ERROR Error: Type: 'db' Object: 'query' Value: ''

из этого складываются логичные вопросы:
как так то?
и всё же под каким пользователем тогда панель пытается залить дамп если под тем что нужно вручную дамп заливается нормально вместе с триггерами и без ошибок?

[Gremlin]

Продолжения истории:
если убрать все триггеры относящиеся к базе то панель замечательно восстанавливает базу из бэкапа,просто без проблем!

включил LogLevel 9, запустил восстановления из бэкапа, в логе есть строчка:

May 19 02:15:13 [19581:394] proc EXTINFO Run '/bin/sh -c /bin/mysql\ -hlocalhost\ -ubackup_85805e2a\ -p\$pw\ --local-infile=0\ \'testdb\'' pid 21691

откуда этот пользователь backup_85805e2a?
зачем оно там надо?

можно заливать дамп под пользователь под которым создана база данных mysql, которую собственно и пытаемся залить и тогда никаких проблем с триггерами не будет и прочих проблем....

PS как я понимаю панель вместо того что бы залить дамп под mysql пользователем testdb, зачем то создаёт нового пользователя backup_85805e2a (поскольку этого пользователя в списке users в базе mysql нет, панель именно создаёт временно этого пользователя насколько я вижу), и пытается залить дамп под ним.