Показано с 1 по 8 из 8

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

  1. #1
    Junior Member
    Регистрация
    12.06.2017
    Сообщений
    2

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

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

    срубается с ошибкой
    PHP код:
    MySQL database database:
    Could not restore a database from backupProcess 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

    в строке этой:
    PHP код:
    /*!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 баз ручками что-то совсем не хочется)
    Последний раз редактировалось svtol; 12.06.2017 в 12:58. Причина: добавил версию mysql

  2. #2
    Support team Аватар для Dasha
    Регистрация
    03.11.2011
    Сообщений
    4,621

    По умолчанию

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

  3. #3
    Junior Member
    Регистрация
    12.06.2017
    Сообщений
    2

    По умолчанию

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

  4. #4
    Support team Аватар для Fly
    Регистрация
    14.08.2010
    Сообщений
    4,764

    По умолчанию

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

  5. #5
    Senior Member
    Регистрация
    04.12.2015
    Сообщений
    168

    По умолчанию

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

  6. #6
    Support team Аватар для Fly
    Регистрация
    14.08.2010
    Сообщений
    4,764

    По умолчанию

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

  7. #7
    Member
    Регистрация
    01.06.2012
    Сообщений
    66

    По умолчанию

    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: ''

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

  8. #8
    Member
    Регистрация
    01.06.2012
    Сообщений
    66

    По умолчанию

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

    включил 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 нет, панель именно создаёт временно этого пользователя насколько я вижу), и пытается залить дамп под ним.
    Последний раз редактировалось Gremlin; 19.05.2020 в 08:28.

Метки этой темы

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •