Ошибка экспорта базы данных mysql

I am trying to export my database from MySQL Workbench but I get this during the export progress:

Running: mysqldump.exe
—defaults-file=»c:usersuserappdatalocaltemptmp2h91wa.cnf» —user=root —host=localhost —protocol=tcp —port=3306 —default-character-set=utf8 —skip-triggers «mydb» mysqldump: Couldn’t execute ‘SELECT COLUMN_NAME,
JSON_EXTRACT(HISTOGRAM, ‘$.»number-of-buckets-specified»‘)
FROM information_schema.COLUMN_STATISTICS WHERE
SCHEMA_NAME = ‘mydb’ AND TABLE_NAME = ‘courses’;’: Unknown table
‘column_statistics’ in information_schema (1109)

Operation failed with exitcode 2 20:55:09 Export of
C:UsersuserDocumentsdumpsmydb.sql has finished with 1 errors

Nimantha's user avatar

Nimantha

6,5136 gold badges27 silver badges68 bronze badges

asked Jun 11, 2018 at 18:01

the essential's user avatar

4

To summarize what I did from the helpful comments of @JustinLaureno and @Mohd.Shaizad, tested on MySQL Workbench 8.0.18:

  • Navigate to C:Program FilesMySQLMySQL Workbench 8.0 CEmodules
  • Edit the file wb_admin_export.py (you need admin permissions for this)
  • amend the line:
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
  • to:
skip_column_statistics = True
  • DO NOT add inline comments or it won’t work!
 skip_column_statistics = True # This won't work
  • Restart MySQL Workbench
  • Perform the export

answered Jan 30, 2020 at 9:33

SharpC's user avatar

SharpCSharpC

6,8764 gold badges45 silver badges40 bronze badges

5

Also ran into this problem.
Decided as follows:
In the Workbench menu, go to:

Edit — Preferences — Administration

In the field «Path to mysqldump Tool«, prescribe the path to mysqldump.exe, in my case «C:Program FilesMySQLMySQL Server 5.7binmysqldump.exe«, click OK.

After that, the error no longer appeared.

rooby's user avatar

rooby

71113 silver badges23 bronze badges

answered Nov 14, 2018 at 10:18

Artem's user avatar

ArtemArtem

6755 silver badges11 bronze badges

5

In MySql Workbench version 8.0.13 do the following steps:

  1. Go to Management/Data export
  2. Choose the schema to export in the ‘Tables to export’ list
  3. Click the ‘Advanced Options…’ button (top right)
  4. Search for the option ‘Other/column-statistics’
  5. Set the value to 0
  6. Click the ‘Return’ button (top right)

Now it should work. Unfortunately, you’ll have to do that every time you start MySql Workbench.

TheEdge's user avatar

TheEdge

9,19314 gold badges67 silver badges133 bronze badges

answered Oct 23, 2018 at 8:21

Sander Bouwhuis's user avatar

7

It is due to a flag that is by default «enabled» in mysqldump 8.

That can be disabled by adding --column-statistics=0.

Syntax :

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

For more info please go to this link.

To disable column statistics by default, you can add:

[mysqldump]
column-statistics=0

to a MySQL config file, such as /etc/my.cnf or ~/.my.cnf.

SharpC's user avatar

SharpC

6,8764 gold badges45 silver badges40 bronze badges

answered Sep 20, 2018 at 10:26

Amitesh Bharti's user avatar

Amitesh BhartiAmitesh Bharti

13.9k6 gold badges62 silver badges61 bronze badges

2

Bug still in Workbench 8.0.16.

Fix:

You can edit wb_admin_export.py under modules in the workbench program directory. Search for «skip_column_statistics = True» (you will find a conditional, don’t worry), comment that line and add a line «skip_column_statistics = True» (without a conditional).

The required parameter will now be always added.

answered Jul 29, 2019 at 12:05

Wolfram's user avatar

WolframWolfram

1611 silver badge2 bronze badges

1

I had the same issue 5 minutes ago.

I fixed it by adding in my mysqldump command --column-statistics=0.
Do it and it should work.

In my case it’s a phing task but you should get the idea.

enter image description here

answered Jun 27, 2018 at 12:44

Matt Komarnicki's user avatar

Matt KomarnickiMatt Komarnicki

5,1767 gold badges39 silver badges91 bronze badges

I too had the same problem.. I am able to resolve this Issue by disabling the column-statistics in the advanced options of the MySQL Workbench Data Export.

1: Click on the advanced options:
enter image description here

2: In the other section for the column-statistics remove TRUE and set it to 0 to disable it.
enter image description here

Now Return and Export the Data.
Thank You

answered Dec 18, 2018 at 6:46

Sunil Valmiki's user avatar

I found this condition in wb_admin_export.py instead of a commented --column-statistics=0. you can remove the else False condition, or change it to 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
True

answered Nov 8, 2019 at 20:16

Justin Laureano's user avatar

I had the same problem and I solved it like this:

edit the workbench preferences:
Edit -> Preferences -> Administration

in the property «Path to mysqldump Tool» place the path of your mysqldump.exe
It is usually found in «C:Program FilesMySQLMySQL Server 5.7binmysqldump.exe»

answered Feb 25, 2019 at 15:03

Yosbel Santana's user avatar

From Mysql-workbench version 8.0.14 you don’t have the option to disable column-statistics.

But you have an option to do it by enabling delete-master-logs:
Mysql-workbench version 8.0.22

  • —delete-master-logs has the same effect as the «RESET MASTER» SQL command
  • RESET MASTER deletes all binary log files listed in the index file, resets the binary log index file to be empty, and creates a new binary log file. This statement is intended to be used only when the master is started for the first time.

answered Nov 16, 2020 at 9:16

Nob Hokleng's user avatar

3

Go to C:Program FilesMySQLMySQL Workbench 8.0 CEmodules and open this file wb_admin_export.py and uncomment «--column-statistics=0» then Restart the workbench

Michel Feinstein's user avatar

answered Oct 23, 2019 at 6:16

Mohd. Shaizad's user avatar

1

I faced the same issue with MySQL workbench latest edition, I resolved it using the mysqldump command line

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

Replace USERNAME, REMOTE_HOST, DATABASE_NAME with your names.

answered Jan 6, 2021 at 11:40

Hany Sakr's user avatar

Hany SakrHany Sakr

2,55128 silver badges26 bronze badges

On MACOS, just downgrade to version 8.0.13, that’s the only thing did the job for us.

The following link can help

https://downloads.mysql.com/archives/workbench/

MacOS MySQL Work Bench 8.0.13

If you are using SSH key to access remote database then do the following -:

Step 1

brew install putty

Step 2

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

Step 3 — In MySQL workbench

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

Hope it helps someone because it wasted 3 hours of our time :)

answered Mar 27, 2021 at 23:18

user63323's user avatar

in version 8, I modified «wb_admin_export.py» and restart workbench. works for me

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)```

answered Jun 19, 2020 at 14:16

chunkiat's user avatar

chunkiatchunkiat

111 silver badge3 bronze badges

1

You can use native MySQL Workbench «Migration wizard» to migrate data without errors.
It can be found in menu
Database -> Migration Wizard
It can transfer data «online» but I didn’t found an option to create a dump file with it.
It is a pretty good solution for migrations

SAUMYA's user avatar

SAUMYA

1,5081 gold badge13 silver badges20 bronze badges

answered Aug 20, 2020 at 7:48

Oleksandr Grin's user avatar

Oleksandr GrinOleksandr Grin

7211 gold badge9 silver badges12 bronze badges

If you are using windows with XAMPP, you need to indicate the path through XAMP. Do the following:

In your MySQL Workbench:
Go to edit -> preferences -> administration under «Path to mysqldump tool» enter the path: C:xamppmysqlbinmysqldump.exe then click ok.

answered Sep 24, 2021 at 22:10

Pierre Vieira's user avatar

Pierre VieiraPierre Vieira

2,0724 gold badges21 silver badges39 bronze badges

Источник

Некоторые типы ошибок в работе с базой данных MySQL при импорте или экспорте базы данных.

Ошибка 1

При экспорте MySQL через phpMyAdmin возникала ошибка, которая приводила к невозможности выполнить сохранение база данных. Причина была в испортившихся таблицах, из-за которой и возникала ошибка.

Ошибка была следующего вида:

Не удалось создать резервную копию базы данных. Процесс завершился с ошибкой: ‘mysqldump: Got error: 1146: Table ‘site.wp_subscribe_reloaded_subscribers’ doesn’t exist when using LOCK TABLES

Решение

Через SSH зайти на VDS.

Использовать команду:

mysqlcheck -u MySQL_name -p MySQL_user_name

Ввести пароль от базы данных.

У меня был выведен список всех таблиц, где несуществующая таблица была показана с ошибкой. В самой базе данных MySQL её не было, а phpMyAdmin на неё все равно ругался.

MySQL_name.wp_statpress                           OK
MySQL_name.wp_subscribe_reloaded_subscribers
Error    : Table ‘MySQL_name.wp_subscribe_reloaded_subscribers’ doesn’t exist
status   : Operation failed
MySQL_name.wp_term_relationships                  OK

Ввести команду (подтвердить паролем):

Появится такая строка:

Нужно выбрать базу данных:

Показать таблицы в ней (Точка с запятой обязательна!):

Будут показаны все таблицы.

После этого удалил таблицу:

drop table wp_subscribe_reloaded_subscribers;

Появилась ошибка:

ERROR 1051 (42S02): Unknown table ‘wp_subscribe_reloaded_subscribers’

но при этом она была удалена и больше нигде не отображалась, а экспорт заработал.

Ошибка 2

Сообщение об ошибки возникло на CentOS с ISPmanager.

При создании базы данных с именем, которое когда-то существовало, возникала ошибка:
«Имя базы уже существует»

Имя базы было в таблице db в системной базе MySQL. Удаление записи оттуда решило эту проблему.

Ошибка 3

При импорте базы данных возникала следующая ошибка:

#1064 — You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘…..sql’ at line 1

В архиве базы данных находилось несколько файлов. Надо было разархивировать архив и заархивировать только файл базы данных.

Ошибка 4

You probably tried to upload a file that is too large. Please refer to documentation for a workaround for this limit.

Решение приведено статье ошибка при импорте в 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. woojin

    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. mcsweb

    Offline

    mcsweb

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

    Регистрация:
    25.01.2010
    Сообщения:
    10
    Симпатии:
    0
    Пол:
    Мужской

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

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

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

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

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

  5. woojin

    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 и чудо таки случилось!!! :yahoo:

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

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

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

    Дальше необходимо просто перенести все файлы с локального компьютера на сервер хостера и поправить файл 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. woojin

    Offline

    woojin

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

    Регистрация:
    31.05.2009
    Сообщения:
    3 206
    Симпатии:
    334
    Пол:
    Мужской

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

Поделиться этой страницей

Привет, ребята, я пытаюсь экспортировать свою базу данных из workbench mysql, но я получаю это от прогресса экспорта:

Запуск: mysqldump.exe —defaults-file = «c:usersuserappdatalocaltemptmp2h91wa.cnf» —user = root —host = localhost —protocol = tcp —port = 3306 — -default-character-set = utf8 -skip-triggers «mydb» mysqldump: Не удалось выполнить ‘SELECT COLUMN_NAME,
JSON_EXTRACT (HISTOGRAM, ‘$. «Количество заданных букв»‘)
FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = ‘mydb’ AND TABLE_NAME = ‘courses’; ‘: Неизвестная таблица’ column_statistics ‘в information_schema (1109)

Операция завершилась неудачно с exitcode 2 20:55:09 Экспорт C:UsersuserDocumentsdumpsmydb.sql завершился с 1 ошибкой

Есть ли у вас какие-либо идеи, что может пойти не так? Спасибо

Ответ 1

В MySql Workbench версии 8.0.13 выполните следующие действия:

  1. Перейти к Управлению/Экспорт данных
  2. Выберите схему для экспорта в списке «Таблицы для экспорта»
  3. Нажмите кнопку «Дополнительные параметры…» (вверху справа)
  4. Найдите вариант «Другая/статистика столбца»
  5. Установите значение 0
  6. Нажмите кнопку «Возврат» (вверху справа)

Теперь это должно сработать. К сожалению, вам придется делать это каждый раз, когда вы запускаете MySql Workbench.

Ответ 2

Также столкнулся с этой проблемой.
Решили следующим образом:
В меню Workbench перейдите на:

Изменить — Настройки — Администрирование

В поле «Путь к инструменту mysqldump» укажите путь к mysqldump.exe, в моем случае «C:Program FilesMySQLMySQL Server 5.7binmysqldump.exe», нажмите кнопку «ОК».

После этого ошибка больше не появлялась.

Ответ 3

У меня была та же проблема 5 минут назад.

Я исправил это, добавив в свою команду mysqldump --column-statistics=0.
Сделай это, и это должно сработать.

В моем случае это очень сложная задача, но вы должны понять.

enter image description here

Ответ 4

У меня тоже была та же проблема. Я могу решить эту проблему, отключив статистику столбцов в расширенных параметрах экспорта данных MySQL Workbench.

1: Нажмите на дополнительные параметры:
enter image description here

2: В другом разделе для столбца-статистики удалите TRUE и установите его равным 0, чтобы отключить его.
enter image description here

Теперь верните и экспортируйте данные.
Благодарю вас

Ответ 5

Это происходит из-за флага, который по умолчанию «включен» в mysqldump 8.

Это можно отключить, добавив —column-statistics = 0.

Синтаксис:

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

Для получения дополнительной информации перейдите по ссылке link

.Чтобы отключить статистику столбцов по умолчанию, вы можете добавить

[mysqldump]
column-statistics=0

в конфигурационный файл MySQL, такой как /etc/my.cnf или ~/.my.cnf.

Ответ 6

У меня была та же проблема, и я решил ее так:

измените настройки рабочего места:
Правка → Настройки → Администрирование

в свойстве «Путь к mysqldump Tool» укажите путь к вашему mysqldump.exe
Обычно он находится в «C:Program FilesMySQLMySQL Server 5.7binmysqldump.exe»

Ответ 7

Ошибка все еще в Workbench 8.0.16.

Исправление:

Вы можете редактировать wb_admin_export.py в модулях в каталоге программы Workbench. Ищите «skip_column_statistics = True» (вы найдете условное, не беспокойтесь), прокомментируйте эту строку и добавьте строку «skip_column_statistics = True» (без условного).

Обязательный параметр теперь будет добавляться всегда.

1 2008-04-07 17:05:41

  • madhot
  • Редкий гость
  • Неактивен
  • Откуда: Волгоград
  • Зарегистрирован: 2008-04-07
  • Сообщений: 5

Тема: Проблема с экспортом бд.

Я конечно извиняюсь, может подобная тема и существует, но я ненашёл на её не в инете не на форуме. кароче, дело вот в чём. у меня стоит денвер со всеми замутами. существует база данных. я её экспортировал, чтобы в дальнейшем импортнуть на хостинг, но решил проверить. уничтожил совсем бд, потом создал новую и импортнул весь дамп(структуру и данные). попробывал зайти на сайт, а он НЕ АЛЁ. поробывал укспортнуть с другими настройками, тоже самое, кароче, перепробывал всё, все возможности экспорта в Myadmin. дальше тоже самое проделывал с каждой таблицой в отдельности, непомагло. решил кое чё посмотреть, зашёл в папку mysql, дальше в папку с базами данных. заметил вот что, таблица, первоначальная, до экспорта весила 8.40 КБ, а после того как экспортнул и импортнул она стала весить 8.42 КБ. вот и незнаю в чём продлема. вот код экспортированной таблицы.

CREATE TABLE `re_country_spr` (
  `id` int(11) NOT NULL auto_increment,
  `name` tinyblob,
  `id_country` int(11) default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=227 ;

INSERT INTO `re_country_spr` VALUES (226, ‘Russia Fediration’, 0);

помогите кто-нибуть, почему при импорте таблицы обратно размер файлы базы данных увеличивается и она уже не читается сайтом вовсе?
да, и напоследок, я не полный нуб, но и не очень хорошо шарю.

2 Ответ от Hanut 2008-04-07 17:42:54

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Проблема с экспортом бд.

madhot
phpMyAdmin импортированные таблицы отображает?
Объясните по шагам, как конкретно вы экспортируете и импортируете.
Удаленная и созданная БД имеют одинаковые названия?

3 Ответ от madhot 2008-04-07 18:51:59

  • madhot
  • Редкий гость
  • Неактивен
  • Откуда: Волгоград
  • Зарегистрирован: 2008-04-07
  • Сообщений: 5

Re: Проблема с экспортом бд.

Hanut сказал:

madhot
phpMyAdmin импортированные таблицы отображает?
Объясните по шагам, как конкретно вы экспортируете и импортируете.
Удаленная и созданная БД имеют одинаковые названия?

да, конешно одинаковые название. таблицы отображаются. никаких ошибок не выдаёт. просто я к премеру открываю в майадмине бд, выбираю таблицу «re_country_spr», нажимаю экспорт (точне также всё выглядит после импорта).
http://imghost.onep.ru/show.php?img=50_0001.jpg.html
в столбце структура ставлю галки напротив  «Добавить значение AUTO_INCREMENT» и «Обратные кавычки в названиях таблиц и полей» (экперементировал с этим столбцом), SQL export compatibility выбирал тоже различные значения (впринципе большой разницы не увидел потом, так что оставил NONE), в столбце «Данные» тока отмечаю чтобы был просто экспорт данных, галки не ставлю ( сдесь тоже эксперементировал), далле, галачку напротив послать не ставлю, чтобы экспорт шёл в меню MyAdmin (ставил чтобы послать, но не вижу в этом смысла), нажимаю пошёл.
http://imghost.onep.ru/show.php?img=51_0002.jpg.html
Выходит это меню с извлечённым дампом:
http://imghost.onep.ru/show.php?img=53_0003.jpg.html
копирую весь текст. после, захожу вновь в меню таблицы «re_country_spr» и нижимаю уничтожить. после, в меню вновь выбираю свою бд и перехожу в меню SQL. Вставляю ране извлечённый дамп в окно и нижимаю пошёл.
http://imghost.onep.ru/show.php?img=54_0004.jpg.html
всё сделано, даблица созданна, данные внесены. зашёл, посмотрел структуру, всё точно также как и в первоначальной таблице. вот тока сайт не работает с этой таблицой, ну и воще с бд, да и таблица «re_country_spr.frm»  в папке дб стала больше весить. изначально она весила 8.40 КБ, а после этого всего стала 8.42. С чем это может быть связвнно и как сделать так, чтоб таблица осталась прежней. дело ещё вот в чём, я пробывал делать экспорт при помощи программы «MySQL Developer Studio», результат оставался тот же. помогите пожалуйста.

4 Ответ от madhot 2008-04-07 23:28:43

  • madhot
  • Редкий гость
  • Неактивен
  • Откуда: Волгоград
  • Зарегистрирован: 2008-04-07
  • Сообщений: 5

Re: Проблема с экспортом бд.

Даже знаете чё, вот вам эта таблица, поробуйте сами, экспортнуть, потом уничтожить и импортнуть. можеь и выйдет, да впринципе выйдет, вот тока файл увеличится в размере и таблица не подайдёт к сайту.
http://narod.ru/disk/63061000/data.zip
куда это скинуть надеюсь сами знаите. папка mysql/data/ создать папку с любым название и туды

5 Ответ от Hanut 2008-04-07 23:29:05

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Проблема с экспортом бд.

madhot
В вашем подробном описании нет никаких ошибок и действия совершенно правильные.
Проверьте привилегии пользователя, которым скрипт подключается к БД.

Увеличение .frm файла вероятно связано с фрагментацией данных — не думаю, что это имеет значение.

6 Ответ от madhot 2008-04-08 00:14:35 (изменено: madhot, 2008-04-08 00:30:21)

  • madhot
  • Редкий гость
  • Неактивен
  • Откуда: Волгоград
  • Зарегистрирован: 2008-04-07
  • Сообщений: 5

Re: Проблема с экспортом бд.

Hanut сказал:

madhot
В вашем подробном описании нет никаких ошибок и действия совершенно правильные.
Проверьте привилегии пользователя, которым скрипт подключается к БД.

Увеличение .frm файла вероятно связано с фрагментацией данных — не думаю, что это имеет значение.

дело не тока в этом файле, а воще со всеми файлами этой даблицы. фаил «re_country_spr.MYD» весил 76 байт, а становится 0 байт, фаил «re_country_spr.MYI» весил 2 кб, а становится 1 кб, ну и фаил, про каторый я уже изначально писал, «re_country_spr.frm» весил 8.40 кб, а становится 8.42 кб.
а насчёт привелегий, там вроде всё норм….
    $config[«useoledb»] = 1;
    $config[«dbtype»] = «mysql»;
    $config[«dbhost»] = «localhost:31011»;
    $config[«dbuname»] = «root»;
    $config[«dbpass»] = «»;
    $config[«dbname»] = «de»;

    $config[«table_prefix»] = «re_»;
я незнаю, проблема может немного в другом. дело в том, что движок с спёр с американского сайта (неважно как), версия причём триальная на 15 дней, но это я переписал. плюс ко всему этому половину файлов движка закодины zend*ом. может быть в них чтото скрыто. незнаю. что потдавалось переписке, что изменил, вбил базу РФ. и вот в самом конце, на тебе, такая проблема. да и впринце, если логически подумать, взял таблицу, экспортнул, уничтожил, импортнул заново и она не подходит. причём меняется в размерах, а структыра и данные остаются прежние……я даже незнаю, мистика какая то.
я бы несказал что я полный нуб, работать с sql немного умею, сам писал маленький двиган с бд, но это что-то невераятное. я пробывал и отдельно экспортировать структуру, и отдельно данные, так же по очериде вносил, беда остовалась.
может быть они создавали базу с помощью какой то дргуой проги, или ещё какие-нибуть замуты?

да, вот чё хотел спросить, Вы и Ваш сайт официальные от PHPMYADMIN или просто люди каторые хорошо разбираются?

7 Ответ от Hanut 2008-04-08 11:38:42

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Проблема с экспортом бд.

madhot
re_country_spr.MYD должен содержать данные, и если он пустой, значит данных в таблице нет. А вот почему они не вставляются — это не ясно, по идее, если произошла ошибка, то она должна была отобразиться.

Я пробовал ваши фалы таблиц и у меня все нормально работает, то есть данные можно экспортировать и импортировать заново.

Могу только предложить попробовать решить проблему кардинально, то есть установить полные версии элементов веб-сервера по данной статье «Инструментарий веб-разработчика» и попробовать работать с ними.
______________

Проект занимается переводом phpMyAdmin на русский язык и поддержкой пользователей. Существует с разрешения главного разработчика (Marc Delisle).

8 Ответ от madhot 2008-04-08 17:56:54

  • madhot
  • Редкий гость
  • Неактивен
  • Откуда: Волгоград
  • Зарегистрирован: 2008-04-07
  • Сообщений: 5

Re: Проблема с экспортом бд.

большое спасибо. буду пробывать «Инструментарий веб-разработчика». надеюсь мы ещё пересекёмся, приятно было пообщатся. еще раз спасибо.

9 Ответ от Vit 2008-05-17 13:35:47

  • Vit
  • Участник
  • Неактивен
  • Зарегистрирован: 2006-04-10
  • Сообщений: 41

Re: Проблема с экспортом бд.

Здравствуйте!

Помогите, пожалуйста разобраться с такой проблемой:

При экспорте получаю не дамп таблицы, а файл export.php. Но если не отмечать чекбокс «послать», в phpMyAdmin открывается окно с дампом.

Почему он не посылается?

10 Ответ от Hanut 2008-05-17 13:42:53

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Проблема с экспортом бд.

Vit
Это вне зависимости от того выбрано ли архивирование?
Укажите версию phpMyAdmin и версии элементов веб-сервера, а так же локальный сервер, или удаленный.

11 Ответ от Vit 2008-05-17 14:23:31

  • Vit
  • Участник
  • Неактивен
  • Зарегистрирован: 2006-04-10
  • Сообщений: 41

Re: Проблема с экспортом бд.

Hanut сказал:

Vit
Это вне зависимости от того выбрано ли архивирование?

Да.

Укажите версию phpMyAdmin

У меня два сайта, на одном — phpMyAdmin — 2.9.1.1-Debian-4, на другом — phpMyAdmin 2.6.4-pl2. На обоих одинаковые заморочки, может у меня с компьютером что-то?

и версии элементов веб-сервера,

Это что?

а так же локальный сервер, или удаленный.

Удаленный.

12 Ответ от Hanut 2008-05-17 14:53:56

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Проблема с экспортом бд.

Vit
Для начала попробуйте установить последнюю версию phpMyAdmin.

Принципиально проверить создание дампа с помощью phpMyAdmin, можно здесь:
http://pma.cihar.com/STABLE/
Пользователь root без пароля.

Элементы веб сервера — это PHP, Apache, MySQL.

13 Ответ от Vit 2008-05-17 16:04:29 (изменено: Hanut, 2008-05-17 21:23:55)

  • Vit
  • Участник
  • Неактивен
  • Зарегистрирован: 2006-04-10
  • Сообщений: 41

Re: Проблема с экспортом бд.

Hanut сказал:

Vit
Для начала попробуйте установить последнюю версию phpMyAdmin.

К сожалению, не имею возможности.

Происходит то же самое:
http://www.armatexx.eu/userfiles/images/image/Image00001.jpg
http://www.armatexx.eu/userfiles/images/image/Image00002.jpg
http://www.armatexx.eu/userfiles/images/image/Image00003.jpg

14 Ответ от Hanut 2008-05-17 16:14:24

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Проблема с экспортом бд.

Vit
У меня дамп сохраняется нормально, так что это проблемы браузера, вероятно. Попробуйте другой браузер.

15 Ответ от Vit 2008-05-17 16:44:40

  • Vit
  • Участник
  • Неактивен
  • Зарегистрирован: 2006-04-10
  • Сообщений: 41

Re: Проблема с экспортом бд.

Спасибо, никогда бы не догадался.

В IE не шло, а в Mozilla без проблем.

Я понимаю, что это уже не в тему, но может подскажете, где что исправить надо?

16 Ответ от Hanut 2008-05-17 17:46:04

  • Hanut
  • Hanut
  • Модератор
  • Неактивен
  • Откуда: Рига, Латвия
  • Зарегистрирован: 2006-07-02
  • Сообщений: 9,722

Re: Проблема с экспортом бд.

Vit
К сожалению, не могу ничего подсказать. Сам в недоумении, как такое могло получиться.

17 Ответ от Vit 2008-05-17 18:35:22

  • Vit
  • Участник
  • Неактивен
  • Зарегистрирован: 2006-04-10
  • Сообщений: 41

Re: Проблема с экспортом бд.

Нашел!

Если у кого-то случилась такая же беда — отключил надстройки IE и проблема исчезла.
Значит какая-то надстройка виновата. Буду искать.

Еше раз спасибо.

Я пытаюсь экспортировать свою базу данных из MySQL Workbench, но в процессе экспорта получаю следующее:

Running: mysqldump.exe
—defaults-file = «c:usersuserappdatalocaltemptmp2h91wa.cnf» —user=root —host=localhost —protocol=tcp —port=3306 —default-character-set=utf8 —skip-triggers «mydb» mysqldump: Couldn’t execute ‘SELECT COLUMN_NAME,
JSON_EXTRACT(HISTOGRAM, ‘$.»number-of-buckets-specified»‘)
FROM information_schema.COLUMN_STATISTICS WHERE
SCHEMA_NAME = ‘mydb’ AND TABLE_NAME = ‘courses’;’: Unknown table
‘column_statistics’ in information_schema (1109)
Operation failed with exitcode 2 20:55:09 Export of
C:UsersuserDocumentsdumpsmydb.sql has finished with 1 errors

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


Ответы
15

У меня была такая же проблема 5 минут назад.

Я исправил это, добавив в свой mysqldump команду —column-statistics=0.
Сделайте это, и это должно сработать.

В моем случае это задача phing, но вы должны уловить идею.

Это связано с флагом, который по умолчанию включен в mysqldump 8.

Это можно отключить, добавив —column-statistics=0.

Синтаксис:

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

Для получения дополнительной информации перейдите на эта ссылка.

Чтобы отключить статистику столбца по умолчанию, вы можете добавить:

[mysqldump]
column-statistics=0

В файл конфигурации MySQL, например /etc/my.cnf или ~/.my.cnf.

В MySql Workbench версии 8.0.13 выполните следующие действия:

  1. Перейти в Управление / Экспорт данных
  2. Выберите схему для экспорта в списке «Таблицы для экспорта».
  3. Нажмите кнопку «Дополнительные параметры …» (вверху справа).
  4. Найдите параметр «Другое / статистика-столбец».
  5. Установите значение 0
  6. Нажмите кнопку «Вернуться» (вверху справа).

Теперь должно работать. К сожалению, вам придется делать это каждый раз при запуске MySql Workbench.

Тоже столкнулся с этой проблемой.
Решили так:
В меню Workbench перейдите к:

Изменить — Настройки — Администрирование

В поле «Путь к инструменту mysqldump» прописываем путь к mysqldump.exe, в моем случае «C: Program Files MySQL Сервер MySQL 5.7 bin mysqldump.exe» нажимаем ОК.

После этого ошибка больше не появлялась.

У меня тоже была такая же проблема. Я могу решить эту проблему, отключив статистику столбцов в расширенных параметрах экспорта данных MySQL Workbench.

1: Нажмите на дополнительные параметры:

2: В другом разделе для статистики столбца удалите ИСТИНА и установите для него значение 0, чтобы отключить его.

Теперь верните и экспортируйте данные.
Спасибо

У меня была такая же проблема, и я решил ее так:

Отредактируйте настройки верстака:
Правка -> Настройки -> Администрирование

В свойстве «Путь к mysqldump Tool» укажите путь к вашему mysqldump.exe
Обычно он находится в «C: Program Files MySQL MySQL Server 5.7 bin mysqldump.exe».

Ошибка по-прежнему в Workbench 8.0.16.

Исправить:

Вы можете редактировать wb_admin_export.py в модулях в программном каталоге рабочей среды. Найдите «skip_column_statistics = True» (вы найдете условное выражение, не беспокойтесь), прокомментируйте эту строку и добавьте строку «skip_column_statistics = True» (без условного).

Обязательный параметр теперь будет всегда добавляться.

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

Я нашел это состояние в wb_admin_export.py вместо прокомментированного —column-statistics=0. вы можете удалить условие else False или изменить его на 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
True

Подводя итог тому, что я сделал из полезных комментариев @JustinLaureno и @ Mohd.Shaizad, протестированных на MySQL Workbench 8.0.18:

  • Перейдите к C:Program FilesMySQLMySQL Workbench 8.0 CEmodules
  • Отредактируйте файл wb_admin_export.py (для этого вам нужны права администратора)
  • изменить строку:
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
  • Перезапустите MySQL Workbench
  • Выполните экспорт

В версии 8 я изменил «wb_admin_export.py» и перезапустил рабочую среду. работает для меня

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

В Mysql-workbench версии 8.0.14 у вас нет возможности отключить столбец-статистика.

Но у вас есть возможность сделать это с помощью включение удаления-мастер-логов:
Mysql-workbench версии 8.0.22

  • —delete-master-logs имеет тот же эффект, что и SQL-команда «СБРОС МАСТЕР»
  • СБРОС МАСТЕРА удаляет все двоичные файлы журнала, перечисленные в индексном файле, сбрасывает двоичный индексный файл журнала, чтобы он был пустым, и создает новый двоичный файл журнала. Этот оператор предназначен для использования только при первом запуске мастера.

Я столкнулся с той же проблемой с последней версией MySQL workbench, я решил ее с помощью командной строки mysqldump

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

Замените USERNAME, REMOTE_HOST, DATABASE_NAME своими именами.

На MACOS просто перейдите на версию 8.0.13, это единственное, что помогло нам.

Следующая ссылка может помочь

Https://downloads.mysql.com/archives/workbench/

Если вы используете SSH-ключ для доступа к удаленной базе данных, сделайте следующее:

Шаг 1

brew install putty

Шаг 2

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

Шаг 3 — в рабочей среде MySQL

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

Надеюсь, это поможет кому-то, потому что потратил 3 часа нашего времени зря :)

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

Вопрос:

Я столкнулся с проблемой, связанной с экспортом базы данных. Прежде всего, я должен уточнить, что я использую MySQL Workbench 5.2.47. Процедура, которой я следовал до сих пор, заключается в следующем:

  1. Я следовал инструкциям http://mysqlworkbench.org/2012/07/migrating-from-ms-sql-server-to-mysql-using-workbench-migration-wizard/, чтобы создать соединение с моей MSSQL DB в чтобы превратить его в MySQL DB.

  2. Затем я также проверил, что мои данные импортированы в базу данных.

  3. Теперь я хочу экспортировать его в файл sql/или предпочтительно в файлы frm, myi, myd, чтобы разместить их на моем сервере.

Я пытался экспортировать их из

  • Администрирование сервера → Экспорт данных

  • Уже сменил пароль от безопасности (Пользователи и привилегии)

но я сталкиваюсь с проблемой

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

Я не знаю, что я могу делать неправильно, и я искал в Google, чтобы найти решение, но оно должно быть нормально экспортировано.

Любая другая информация будет предоставлена по запросу.

Спасибо.

Ответ №1

Я видел эту проблему, когда у вас нет разрешения LOCK TABLES. Вы увидите эту ошибку до того, как остальная часть доступа отклонит ошибки в журнале. Попробуйте отключить LOCK TABLES в расширенных настройках на панели Data Export на рабочем столе.

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

Ответ №2

Содержание

  1. Решение 1. Предоставьте правильный файл конфигурации для каждого вызова mysqldump.
  2. Решение 2. Предоставьте глобальный правильный файл конфигурации
  3. Решение 3 Просто вызовите mysqldump без параметров

Решение 1. Предоставьте правильный файл конфигурации для каждого вызова mysqldump.

Это скорее обходной путь, но он поможет вам достичь желаемого результата. Просто используйте предоставленную информацию, чтобы получить дамп MySQL-таблицы из CLI – в основном это просто копирование и вставка:

Как вы можете видеть из журнала, mysqldump имеет параметр –defaults-file. Этот файл может и будет содержать учетные данные подключения, такие как пароль. Очевидно, MySQLWorkbench не предоставляет пароль для этого файла (“используя пароль: НЕТ”).

Поэтому просто создайте файл с именем database.cnf и поместите его где-нибудь на свой компьютер (например, c:tempdatabase.cnf), содержащий такие учетные данные, как это:

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

Поскольку это также работает с любым другим параметром из командной строки, вы также можете добавить все ваши другие вещи, такие как –single -action и т.д. Теперь возьмем запись в вашем файле журнала:

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"

И замените параметр –defaults-extra-file, чтобы он указывал на ваш файл database.cnf, а также удалите информацию “Running:” и все параметры, которые вы уже указали в вашем database.cnf:

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

Затем откройте оболочку, перейдите в папку MySQLWorkbench и запустите команду, например:

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

Не забудьте направить вывод в файл!

Короче говоря: используйте инструмент CLI mysqldump, MySQLWorkbench делает то же самое, но не правильно.

Решение 2. Предоставьте глобальный правильный файл конфигурации

mysqldump также читает глобальный конфигурационный файл, если он существует в одном из этих мест:

  • C:WINDOWSmy.ini
  • C:WINDOWSmy.cnf
  • C:my.ini
  • C:my.cnf
  • c:Program FilesMySQLmy.ini
  • c:Program FilesMySQLmy.cnf

Таким образом, вы можете просто поместить информацию из отредактированного выше cnf файла в одно из этих мест и запустить команду mysqldump без параметра –defaults-file-option

Решение 3 Просто вызовите mysqldump без параметров

Это, пожалуй, самое сложное решение: my.cnf будет работать с любым параметром, который принимает mysqldump. Так почему бы просто не использовать это для настройки своего дампа? Просто добавьте все параметры в ваш my.cnf

[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

Теперь запустите mysqldump в командной строке/командной строке, без каких-либо параметров, и это хорошо:

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

Ответ №3

Пожалуйста, попробуйте это решение https://bugs.mysql.com/bug.php?id=91640.

На самом деле мы можем использовать расширенный параметр в Workbench для отключения статистики столбцов согласно qaru.site/questions/15849143/… – см. Ниже:

  1. Перейти в Управление/Экспорт данных
  2. Выберите схему для экспорта в списке “Таблицы для экспорта”
  3. Нажмите кнопку “Дополнительные параметры…” (вверху справа)
  4. Найдите опцию “Другое/столбец-статистика”
  5. Установите значение 0
  6. Нажмите кнопку “Вернуться” (вверху справа)

По словам автора этого поста: “К сожалению, вам придется делать это каждый раз, когда вы запускаете MySQL Workbench”.

Это работает для меня, может быть, это может помочь другим.

Ответ №4

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

Источник

Solution 1 — Provide correct config file to each mysqldump-call

This is more a workaround, but it will get you to the desired result. Just use the provided information to get a dump of your MySQL-Table from the CLI — basically it’s just copy & paste:

As you can see from the log mysqldump has the parameter —defaults-file. This file can and will contain connection credentials, like the password. Apparently MySQLWorkbench is not providing the password with this file («using password: NO»).

So just create a file named database.cnf and put it somewhere to your computer (e.g. c:tempdatabase.cnf) containing the credentials like this:

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

As this also works with any other parameter from the command line, you may also add all your other stuff like, —single-transaction etc.
Now take your log file entry:

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"

And replace the —defaults-extra-file parameter to point to your database.cnf — also remove the «Running:» info and every parameter you are already providing in your database.cnf:

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

Then open a Shell, go to your MySQLWorkbench-Folder and run the command, e.g:

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

Do not forget to route the output to a file!

Long story short: Use the CLI tool mysqldump, MySQLWorkbench is doing the same, but not the correct way.

Solution 2 — Provide a global correct config file

mysqldump also reads a global config file, if it exists in one of those locations:

  • C:WINDOWSmy.ini
  • C:WINDOWSmy.cnf
  • C:my.ini
  • C:my.cnf
  • c:Program FilesMySQLmy.ini
  • c:Program FilesMySQLmy.cnf

So you can just put the information from the above edited cnf-file to one of this locations and run the mysqldump-command without the —defaults-file-parameter

Solution 3 Just call mysqldump with no parameters

This is maybe the most sophisticated solution: The my.cnf will will work with any parameter that mysqldump accepts. So why don’t just use this to configure your dump? Just add all parameters to your my.cnf

[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

Now run mysqldump on the shell / command line, without any parameters, and you’re good:

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

Источник

Некоторые типы ошибок в работе с базой данных MySQL при импорте или экспорте базы данных.

Ошибка 1

При экспорте MySQL через phpMyAdmin возникала ошибка, которая приводила к невозможности выполнить сохранение база данных. Причина была в испортившихся таблицах, из-за которой и возникала ошибка.

Ошибка была следующего вида:

Не удалось создать резервную копию базы данных. Процесс завершился с ошибкой: ‘mysqldump: Got error: 1146: Table ‘site.wp_subscribe_reloaded_subscribers’ doesn’t exist when using LOCK TABLES

Решение

Через SSH зайти на VDS.

Использовать команду:

mysqlcheck -u MySQL_name -p MySQL_user_name

Ввести пароль от базы данных.

У меня был выведен список всех таблиц, где несуществующая таблица была показана с ошибкой. В самой базе данных MySQL её не было, а phpMyAdmin на неё все равно ругался.

MySQL_name.wp_statpress                           OK
MySQL_name.wp_subscribe_reloaded_subscribers
Error    : Table ‘MySQL_name.wp_subscribe_reloaded_subscribers’ doesn’t exist
status   : Operation failed
MySQL_name.wp_term_relationships                  OK

Ввести команду (подтвердить паролем):

Появится такая строка:

Нужно выбрать базу данных:

Показать таблицы в ней (Точка с запятой обязательна!):

Будут показаны все таблицы.

После этого удалил таблицу:

drop table wp_subscribe_reloaded_subscribers;

Появилась ошибка:

ERROR 1051 (42S02): Unknown table ‘wp_subscribe_reloaded_subscribers’

но при этом она была удалена и больше нигде не отображалась, а экспорт заработал.

Ошибка 2

Сообщение об ошибки возникло на CentOS с ISPmanager.

При создании базы данных с именем, которое когда-то существовало, возникала ошибка:
«Имя базы уже существует»

Имя базы было в таблице db в системной базе MySQL. Удаление записи оттуда решило эту проблему.

Ошибка 3

При импорте базы данных возникала следующая ошибка:

#1064 — You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘…..sql’ at line 1

В архиве базы данных находилось несколько файлов. Надо было разархивировать архив и заархивировать только файл базы данных.

Ошибка 4

You probably tried to upload a file that is too large. Please refer to documentation for a workaround for this limit.

Решение приведено статье ошибка при импорте в phpMyAdmin.

Источник

Привет, ребята, я пытаюсь экспортировать свою базу данных из workbench mysql, но я получаю это от прогресса экспорта:

Запуск: mysqldump.exe —defaults-file = «c:usersuserappdatalocaltemptmp2h91wa.cnf» —user = root —host = localhost —protocol = tcp —port = 3306 — -default-character-set = utf8 -skip-triggers «mydb» mysqldump: Не удалось выполнить ‘SELECT COLUMN_NAME,
JSON_EXTRACT (HISTOGRAM, ‘$. «Количество заданных букв»‘)
FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = ‘mydb’ AND TABLE_NAME = ‘courses’; ‘: Неизвестная таблица’ column_statistics ‘в information_schema (1109)

Операция завершилась неудачно с exitcode 2 20:55:09 Экспорт C:UsersuserDocumentsdumpsmydb.sql завершился с 1 ошибкой

Есть ли у вас какие-либо идеи, что может пойти не так? Спасибо

4b9b3361

Ответ 1

В MySql Workbench версии 8.0.13 выполните следующие действия:

  1. Перейти к Управлению/Экспорт данных
  2. Выберите схему для экспорта в списке «Таблицы для экспорта»
  3. Нажмите кнопку «Дополнительные параметры…» (вверху справа)
  4. Найдите вариант «Другая/статистика столбца»
  5. Установите значение 0
  6. Нажмите кнопку «Возврат» (вверху справа)

Теперь это должно сработать. К сожалению, вам придется делать это каждый раз, когда вы запускаете MySql Workbench.

Ответ 2

Также столкнулся с этой проблемой.
Решили следующим образом:
В меню Workbench перейдите на:

Изменить — Настройки — Администрирование

В поле «Путь к инструменту mysqldump» укажите путь к mysqldump.exe, в моем случае «C:Program FilesMySQLMySQL Server 5.7binmysqldump.exe», нажмите кнопку «ОК».

После этого ошибка больше не появлялась.

Ответ 3

У меня была та же проблема 5 минут назад.

Я исправил это, добавив в свою команду mysqldump --column-statistics=0.
Сделай это, и это должно сработать.

В моем случае это очень сложная задача, но вы должны понять.

enter image description here

Ответ 4

У меня тоже была та же проблема. Я могу решить эту проблему, отключив статистику столбцов в расширенных параметрах экспорта данных MySQL Workbench.

1: Нажмите на дополнительные параметры:
enter image description here

2: В другом разделе для столбца-статистики удалите TRUE и установите его равным 0, чтобы отключить его.
enter image description here

Теперь верните и экспортируйте данные.
Благодарю вас

Ответ 5

Это происходит из-за флага, который по умолчанию «включен» в mysqldump 8.

Это можно отключить, добавив —column-statistics = 0.

Синтаксис:

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

Для получения дополнительной информации перейдите по ссылке link

.Чтобы отключить статистику столбцов по умолчанию, вы можете добавить

[mysqldump]
column-statistics=0

в конфигурационный файл MySQL, такой как /etc/my.cnf или ~/.my.cnf.

Ответ 6

У меня была та же проблема, и я решил ее так:

измените настройки рабочего места:
Правка → Настройки → Администрирование

в свойстве «Путь к mysqldump Tool» укажите путь к вашему mysqldump.exe
Обычно он находится в «C:Program FilesMySQLMySQL Server 5.7binmysqldump.exe»

Ответ 7

Ошибка все еще в Workbench 8.0.16.

Исправление:

Вы можете редактировать wb_admin_export.py в модулях в каталоге программы Workbench. Ищите «skip_column_statistics = True» (вы найдете условное, не беспокойтесь), прокомментируйте эту строку и добавьте строку «skip_column_statistics = True» (без условного).

Обязательный параметр теперь будет добавляться всегда.

Источник

  • Ошибка экспозиции nikon d3200
  • Ошибка эксплорер ехе при запуске виндовс 10
  • Ошибка эксплойта код ошибки 31
  • Ошибка эксперта как вновь открывшееся обстоятельство
  • Ошибка эксперимента как найти