Ошибка экспорта phpmyadmin

phpMyAdmin has announced that in a few days on Sept 1st 2013 they’re closing down their other resources such as mailing list and forums and are deferring us to use StackOverflow / StackExchange.

I provide general support at a small cPanel hosting service and part of my duties include doing frequent DB Exports in phpMyAdmin and also showing hosting customers how to export their databases from phpMyAdmin within their cPanel as a backup tool.

Been working fine for many years and across many servers / cPanel versions / PHP versions / mysQL versions.

But after we recently upgraded to phpMyAdmin 4.0.5 final (we use WHM’s EasyApache to keep PHP and other server modules updated regularly) we’re encountering an apparent bug and cannot Export databases.

Any attempt to Export a DB over a certain size (haven’t determined exactly yet, but seems to be around 20MB) instead of getting the usual download prompt, it simply immediately fails.

If the Export is attempted in FireFox the error looks like this:

Firefox can't find the file at https://example.example.net:2083/cpsess1210889896/3rdparty/phpMyAdmin/export.php

If the Export is attempted in Internet Explorer simply says "The website cannot display the page" and when more info is clicked says:

This error (HTTP 500 Internal Server Error) means that the website you are visiting had a server problem which prevented the webpage from displaying. 

Since upgrading to 4.0.5 that just started happening with DB’s that I’ve been exporting through phpMyAdmin for years, literally, with no problem before.

I tried raising some memory limits within WHM / cPanel such as the max memory cPanel session can use, but it doesn’t help. Also a couple of discussions on the cPanel forums seem to be claiming that this problem stems from a bug in phpMyAdmin, not a problem with cPanel or PHP.

Can anyone shed any more light on this problem?

Is there anyone from phpMyAdmin who knows if this specific issue is being addressed?

Thanks very much for any help or feedback that anyone here is willing to provide. This is putting me in a bit of a jam with our clients.

Just in case it matters here is the general server environment:

cPanel/WHM 11.38.2 (build 6)
Apache 2.2.25
PHP 5.4.18
mySQL 5.5.32-cll
RHEL 5 64bit
running suPHP

EDIT — I forgot to mention that the problem occurs whether doing a straight «Quick» SQL export and/or a «Custom» compressed export (such as a gzip). Either way, quick or compressed we can’t export databases larger than around 20MB.

UPDATE / FIX — Marc Delisle’s code changes in phpMyAdmin 4.0.6 fixes this bug, and after cPanel 11.38.2.7 «Release» came out recently it has resolved the issues on my servers. Thank you Marc and the PMA team!

phpMyAdmin has announced that in a few days on Sept 1st 2013 they’re closing down their other resources such as mailing list and forums and are deferring us to use StackOverflow / StackExchange.

I provide general support at a small cPanel hosting service and part of my duties include doing frequent DB Exports in phpMyAdmin and also showing hosting customers how to export their databases from phpMyAdmin within their cPanel as a backup tool.

Been working fine for many years and across many servers / cPanel versions / PHP versions / mysQL versions.

But after we recently upgraded to phpMyAdmin 4.0.5 final (we use WHM’s EasyApache to keep PHP and other server modules updated regularly) we’re encountering an apparent bug and cannot Export databases.

Any attempt to Export a DB over a certain size (haven’t determined exactly yet, but seems to be around 20MB) instead of getting the usual download prompt, it simply immediately fails.

If the Export is attempted in FireFox the error looks like this:

Firefox can't find the file at https://example.example.net:2083/cpsess1210889896/3rdparty/phpMyAdmin/export.php

If the Export is attempted in Internet Explorer simply says "The website cannot display the page" and when more info is clicked says:

This error (HTTP 500 Internal Server Error) means that the website you are visiting had a server problem which prevented the webpage from displaying. 

Since upgrading to 4.0.5 that just started happening with DB’s that I’ve been exporting through phpMyAdmin for years, literally, with no problem before.

I tried raising some memory limits within WHM / cPanel such as the max memory cPanel session can use, but it doesn’t help. Also a couple of discussions on the cPanel forums seem to be claiming that this problem stems from a bug in phpMyAdmin, not a problem with cPanel or PHP.

Can anyone shed any more light on this problem?

Is there anyone from phpMyAdmin who knows if this specific issue is being addressed?

Thanks very much for any help or feedback that anyone here is willing to provide. This is putting me in a bit of a jam with our clients.

Just in case it matters here is the general server environment:

cPanel/WHM 11.38.2 (build 6)
Apache 2.2.25
PHP 5.4.18
mySQL 5.5.32-cll
RHEL 5 64bit
running suPHP

EDIT — I forgot to mention that the problem occurs whether doing a straight «Quick» SQL export and/or a «Custom» compressed export (such as a gzip). Either way, quick or compressed we can’t export databases larger than around 20MB.

UPDATE / FIX — Marc Delisle’s code changes in phpMyAdmin 4.0.6 fixes this bug, and after cPanel 11.38.2.7 «Release» came out recently it has resolved the issues on my servers. Thank you Marc and the PMA team!

1. Offline

   DKraev

   <i>(aka gft)</i>
   => Cпециалист <=

   Регистрация:

   16.08.2008

   Сообщения:

   1 627

   Симпатии:

   219

   Пол:

   Мужской

   Приветствую всех. За время моего пребывания на данном форуме довольно часто возникали вопросы по ошибкам при импорте/экспорте базы данных MySQL (далее БД).

   Вопросы примерно такие:

   • После переноса (импорта) БД на хостинг на сайте сбилась кодировка. На локальном сайте все нормально;
   • При переносе (импорте) БД возникает ошибка #1064 или другая;
   • Пропадает текст после переноса (импорта) БД.
   • Как перенести базу с Denwer на хостинг (или наоборот)
   • и т.д

   Прежде чем публиковать подобный вопрос на форуме, настоятельно рекомендую прочитать данный пост полностью, и что самое главное — СДЕЛАТЬ все что здесь написано.

   Большинство ошибок возникает именно из-за неправильного переноса, поэтому я опишу импорт/экспорт БД при помощи скрипта Sypex Dumper. Я буду описывать работу с Lite версией, с которой я успешно работаю уже больше трех лет. Хотел бы заметить что подобной информации полно в сети, однако у нас на форуме её нет. А так как большинство новичков при любой проблеме сразу идут сюда, а не в Google, то я решил написать этот небольшой мануальчик. Многим он поможет решить проблемы с переносом БД, а старожилов форума избавит от необходимости писать про Sypex Dumper снова и снова

   В первую очередь скачиваем скрипт отсюда (utf-8, архив прикреплен к посту) либо с сайта разработчика (cp1251). Распаковываем архив. На выходе получим два файла — readme.txt (инструкция) и dumper.php (сам скрипт).

   Экспорт БД с локального компьютера.

   Я работаю на Denwer, но и для других должно быть точно так же по идее.

   1. Копируете файл dumper.php в корень сайта.
   2. Создаете новую папку, которую называете backup
   3. Набираете в браузере: www.adres_sayta.ru/dumper.php
   4. Вводите логин пользователя и пароль для базы данных, нажимаете «Применить»
   5. Чекбокс на «Backup/Создание резервной копии БД». Фильтр таблиц — оставляете пустым. Метод сжатия — GZip. Степень сжатия — 7. Нажимаете «Применить»

   Наблюдаем, как весело бегут строчки вверх. Ваш дамп готов! Зайдите в ранее созданную папку backup, вы увидите архив примерно такой — amurka_2010-08-20_23-30.sql.gz — это и есть дамп БД.

   Импорт БД на хостинг.

   1. Заливаете файл dumper.php в корень сайта на хостинг.
   2. Заливаете папку backup тоже в корень сайта. Права на папку — 777. Так же внутри данной папки будет лежать файл dumper.cfg.php — для него тоже выставляете 777
   3. Набираете в браузере: www.adres_sayta.ru/dumper.php
   4. Вводите логин пользователя и пароль для базы данных, нажимаете «Применить»
   5. Чекбокс на «Restore / Восстановление БД из резервной копии». БД — выбираете базу данных на хостинге. Файл — выбираете наш файл с дампом (пример — amurka_2010-08-20_23-30.sql.gz). Нажимаете «Применить».

   Наш дамп имортируется на хост.

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

   Ошибки.

   Многие могут столкнуться с ошибкой «#2005: Unknown MySQL server host ‘имя’ (11004)» при импорте БД на хостинг. Это говорит о том, что неверно указан MySQL сервер. В dumper.php по умолчанию указан «localhost», на хостинге же может быть любой. Например — p1543.mysql.ihc.ru

   Откройте файл dumper.php и в 34 строке найдите код:

   1. define(‘DBHOST’, ‘localhost:3306’);

   Вместо localhost:3306 впишите MySQL сервер вашего хостинга. Сохраните файл. Повторите попытку импорта.
   ———————————————-

   Несколько раз у меня не получалось залить базу на хост при помощи этого скрипта. Но это была проблема хостера. Решалось выставлением CHMOD 777 на папку www
   ———————————————-

   Я не рассматривал дополнительные настройки данного скрипта (кстати их довольно много). Данный мануал рассчитан на новичков, которые испытывают проблемы при переносе БД. Того что я написал достаточно для успешного переноса БД в 90% случаев. За более полной информацией — на сайт разработчика, либо в Google.

   Вложения:

   Последнее редактирование: 17.09.2010

3. 

   Offline

   woojin

   Местный
   Команда форума
   => Cпециалист <=

   Регистрация:

   31.05.2009

   Сообщения:

   3 206

   Симпатии:

   334

   Пол:

   Мужской

   «+» тебе за описание

   я приведу свой пример, немного по другому, но принцип то же

   1. открываем phpMyAdmin
   2. делаем дамп базы
   3. потом в получевшемся файлике ищем такую строкуENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1, нас интересует выделенный фрагмент — эта строчка обычно идёт после функции создания таблицы т.е. CREATE TABLE IF NOT EXISTS
   4. если не ясно в какой кодировке должна быть таблицы то этот выделенный фрагмент удаляем везде где он есть, сохраняем получившийся файл
   5. импортируем дамп в другую базу

   P.S. если всё равно кякозяблики, то просто пере сохраняем файл с дампом в другой кодировке — меня этот метод ни когда ещё не подводил

4. 

   Offline

   mcsweb

   Недавно здесь

   Регистрация:

   25.01.2010

   Сообщения:

   10

   Симпатии:

   0

   Пол:

   Мужской

   А вот нифига phpMyAdmin не вышло.

   Ради науки решил перекинуть сайт с одного локального сервера на другой.
   С ХАМРР на Денвер.
   Как бы я не делал экспорт базу данных на ХАММРе в Денвере он не принимался.
   В конце концов просто скопировал папку с таблицами с одного сервака на другой.
   В результате сайт работает с ошибками.

   Буду пробовать скрипт от первого советчика.

   Попробовал- результат тот же .
   Хотя дампер.пхп отработал отлично.
   Виднео что то в денвере не так совмещается

   Последнее редактирование: 23.08.2010

5. 

   Offline

   woojin

   Местный
   Команда форума
   => Cпециалист <=

   Регистрация:

   31.05.2009

   Сообщения:

   3 206

   Симпатии:

   334

   Пол:

   Мужской

   интересно по чему не сработал ни один ни второй вариант?!

   есть вариант воспользоваться компонентом http://www.akeebabackup.com/ это следующая версия joomlapack

   в описании почитай про совместимость компонента с версиями php

6. Offline

   VashMaster

   Недавно здесь

   Регистрация:

   19.08.2010

   Сообщения:

   19

   Симпатии:

   1

   Пол:

   Мужской

   Тоже всегда делаю всё аналогично посту ТС. Пользуюсь утилиткой дампер. Проблем обычно не было. Но вот при переносе сайта на Joomla почему-то появились

   Сделал дамп, потом этим же дамперов восстановил дамп. Но всё равно появились кракозябры.
   Проблему удалось решить только с помощью добавления команды:

   1. mysql_query(«SET NAMES cp1251»);

   в файле index.php на фронт энде и бекенде. Добавил после вызова функции

   1. $mainframe->initialise();

   Получилось примерно так:

   1. $mainframe->initialise();

   3. mysql_query(«SET NAMES cp1251»);

   Только тогда всё стало ОК. Если не поможет, то, возможно, у вас используется кодировка UTF. Пробуйте…

   p.s. При работе с «дампером» редко бывают проблемы с кодировкой, но вот случилось Видимо, я не зря недолюбливаю Джумлу

7. Offline

   DKraev

   <i>(aka gft)</i>
   => Cпециалист <=

   Регистрация:

   16.08.2008

   Сообщения:

   1 627

   Симпатии:

   219

   Пол:

   Мужской

   Модераторы, закрепите тему. Подобные вопросы продолжают сыпаться. До второй страницы (куда уже спустилась эта тема) пользователям дочитывать уже лень… По всей видимости что такое поиск они тоже не знают…

8. Offline

   Владимир.

   Недавно здесь

   Регистрация:

   25.02.2011

   Сообщения:

   1

   Симпатии:

   0

   Пол:

   Мужской

   Не хотел ставиться русский язык, вылезали кракозябры. Как я только не пересохранял файлы и базы ничего не помогало… Снес снова все и сделал по главной инструкции через Sypex и чудо таки случилось!!!

   Хочу добавить:

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

   При запуске на хостинге необходимо указать логин и пароль к базе данных, лежащей у хостера.

   Дальше необходимо просто перенести все файлы с локального компьютера на сервер хостера и поправить файл configuration.php

   А еще у меня возник вопрос относительно приключений с кодировками…
   Не может ли сама операционка выдавать эти сюрпризы?
   Когда я первый раз заливал этот же сайт на хостинг у меня все прошло гладко и не возникло проблем.
   После того как сайт сломали, я переустановил винду, денвер и джумлу на 1.5.22. Вот и думаю, что именно повлияло на неправильное отображение символов…

9. Offline

   DKraev

   <i>(aka gft)</i>
   => Cпециалист <=

   Регистрация:

   16.08.2008

   Сообщения:

   1 627

   Симпатии:

   219

   Пол:

   Мужской

   Не знаю, работал и на XP и на семёрке — проблем не возникало. Но может быть потому что я всегда пользуюсь Sypex… Чаше всего траблы вылезают именно на хостинге… НА локалке, как уже сказал, всегда всё ровно…

10. Offline

    oceay

    Недавно здесь

    Регистрация:

    12.09.2011

    Сообщения:

    1

    Симпатии:

    0

    Пол:

    Мужской

    Спасибо огромное, gft !!!! Сначала многое кажется непонятным, но начинаешь делать согласно инструкции и всё получается само собой. Ещё раз спасибо!

11. 

    Offline

    woojin

    Местный
    Команда форума
    => Cпециалист <=

    Регистрация:

    31.05.2009

    Сообщения:

    3 206

    Симпатии:

    334

    Пол:

    Мужской

    это ты админу отправь, я не могу этого сделать!!!

Перейти к ответу
Данный вопрос помечен как решенный

Ответы
15

mysqldump --column-statistics=0 --host=<server> --user <user> --password <securepass> 

[mysqldump]
column-statistics=0

Перейдите в C:Program FilesMySQLMySQL Workbench 8.0 CEmodules, откройте этот файл wb_admin_export.py и раскомментируйте «—column-statistics=0», затем перезапустите рабочую среду.

skip_column_statistics = True if get_mysqldump_version() > Version(8,
0, 2) and self.owner.ctrl_be.target_version < Version(8, 0, 0) else
True

skip_column_statistics = True if get_mysqldump_version() > Version(8, 0, 2) and self.owner.ctrl_be.target_version < Version(8, 0, 0) else False

skip_column_statistics = True

 skip_column_statistics = True # This won't work

def start(self):
.
.
.
    title = "Dumping " + schema
    title += " (%s)" % table
    # description, object_count, pipe_factory, extra_args, objects
    args = []
    args.append('--column-statistics=0')

class ViewsRoutinesEventsDumpData(DumpThread.TaskData):
    def __init__(self, schema, views, args, make_pipe):
        title = "Dumping " + schema + " views and/or routines and/or events"
        if not views:
           extra_args = ["--no-create-info"]
        else:
            extra_args = []
        DumpThread.TaskData.__init__(self,title, len(views), ["--skip-triggers", " --no-data" ," --no-create-db", "--column-statistics=0"] + extra_args + args, [schema] + views, None, make_pipe)```

Вы можете использовать собственный MySQL Workbench «Мастер миграции» для переноса данных без ошибок.
Его можно найти в меню
База данных -> Мастер миграции
Он может передавать данные «онлайн», но я не нашел возможности создать с его помощью файл дампа.
Это довольно хорошее решение для миграций

C:Program FilesMySQLMySQL Workbench 8.0 CEmysqldump --column-statistics=0  --user=USERNAME --host=REMOTE_HOST --protocol=tcp --port=3306 --default-character-set=utf8 DATABASE_NAME > c:tempdump.sql --password

brew install putty

puttygen id_rsa -O private-openssh -o id_rsa.pem

SSH Key File: /Users/local/.ssh/id_rsa.pem

Другие вопросы по теме

Вопрос:

Dumping test (all tables)
Running: mysqldump.exe --defaults-extra-file="c:usersd_michaappdatalocaltemptmpgtwa_m.cnf"  --user=root --max_allowed_packet=1G --host=localhost --port=3306 --default-character-set=utf8 --single-transaction=TRUE --routines --events --no-data "test"

mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: NO) when trying to connect

Operation failed with exitcode 2

Ответ №1

mysqldump: Got error: 1044: Access denied for user 'XXX'@'%' to database 'XXX' when doing LOCK TABLES

Ответ №2

[client]
user=root
password=your-root-password
single-transaction=TRUE
host=localhost
port=3306
default-character-set=utf8
max_allowed_packet=1G

Running: mysqldump.exe --defaults-extra-file="c:usersd_michaappdatalocaltemptmpgtwa_m.cnf"  --user=root --max_allowed_packet=1G --host=localhost --port=3306 --default-character-set=utf8 --single-transaction=TRUE --routines --events --no-data "test"

mysqldump.exe --defaults-extra-file="c:tempdatabase.cnf" --routines --events --no-data "test"

cd c:Program FilesMySQLMySQL Workbench 6.3 CE
mmysqldump.exe --defaults-extra-file="c:tempdatabase.cnf" --routines --events --no-data "test" > c:UsersuserDownloadstable1.sql

[client]
user=root
password=secretPassword
single-transaction=TRUE
host=localhost
protocol=tcp
port=3306
default-character-set=utf8
skip-triggers=TRUE
all-databases=TRUE
all-tablespaces=TRUE

cd c:Program FilesMySQLMySQL Workbench 6.3 CE
mysqldump.exe  > c:UsersuserDownloadsdump.sql

Ответ №3

Ответ №4

MySQL Workbench пытается получить доступ к вашей базе данных без пароля (обратите внимание на using password: NO в ошибке). Удивительно, что вам удалось получить доступ к экземпляру сервера. Восстановите экземпляр сервера или, по крайней мере, попробуйте с созданным экземпляром.