Mysql workbench error while loading image

Не удается подключиться к серверу базы данных (mysql workbench)

Не могли бы вы помочь мне решить эту проблему?

Когда я пытаюсь щелкнуть «базу данных запросов» в меню базы данных в Workbench Mysql. это дает мне ошибку:

ОТВЕТЫ

Ответ 1

Вероятно, проблема связана с тем, что аутентификация сокета включена для пользователя root по умолчанию, когда пароль не задан, во время обновления до ubuntu 16.04.

Решение состоит в том, чтобы вернуться к аутентификации собственного пароля. Вы можете сделать это, войдя в MySQL, используя проверку сокетов, выполнив:

После входа в систему:

который вернется к исходной (старой по умолчанию) аутентификации пароля.

Теперь используйте пароль в качестве пароля, когда это требуется MySQL.

Ответ 2

Попробуйте открыть services.msc из окна поиска в меню «Пуск» и попробуйте вручную запустить службу MySQL.

Ответ 3

Похоже, есть много причин этой ошибки.

Моя причина/решение

В моем случае причина была в том, что мой сервер был настроен на прием соединений только от localhost. Я исправил это, выполнив следующую статью: Как включить удаленный доступ к серверу баз данных MySQL?. В моем файле my.cnf не было строки skip-networking , поэтому я просто изменил строку

Это позволяет устанавливать соединения с любого IP, а не только с 127.0.0.1.

Затем я создал пользователя MySql, который мог подключиться с моего клиентского компьютера, выполнив следующие команды терминала:

где 1.2.3.4 — это IP-адрес клиента, с которого вы пытаетесь подключиться. Если у вас действительно есть проблемы, вы можете использовать ‘%’ вместо ‘1.2.3.4’ , чтобы позволить пользователю подключаться с любого IP.

Другие причины

Ответ 4

Вы пытались определить, является ли это проблемой с Workbench или общей проблемой соединения? Попробуйте следующее:

• Откройте терминал
• Тип mysql -u root -p -h 127.0.0.1 -P 3306
• Если вы можете подключиться успешно, вы увидите приглашение mysql после ввода пароля (введите quit и Enter there to exit).

Сообщите, как это сработало.

Ответ 5

У меня была похожая проблема в Mac OS, и я смог ее исправить следующим образом:

Из терминала запустите:

Затем меня попросили ввести пароль. Я просто нажал Enter, так как пароль не был установлен.

Я получил сообщение следующим образом:

Добро пожаловать на монитор MySQL. Команды заканчиваются на; или g. Ваш идентификатор соединения MySQL — 181. Версия сервера: 8.0.11 Homebrew.

Если вам удалось войти в mysql>, выполните следующую команду:

Вы должны получить сообщение, подобное этому:

Запрос в порядке, затронуто 0 строк (0,19 с)

Теперь ваш пароль — » пароль «, а имя пользователя — » root «.

Ответ 6

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

Щелкните правой кнопкой мыши ярлык Workbench и выберите Run as Administrator . В окне свойств ярлыка вы можете нажать «Дополнительно» и поставить галочку рядом с надписью «Запуск от имени администратора», чтобы всегда запускать Workbench с правами администратора.

Ответ 7

Я некоторое время боролся с этой проблемой и делал несколько переустановок MySQL, прежде чем обнаруживать это.

Я знаю, что сервер MySQL работал нормально, потому что я мог получить доступ ко всей моей БД с помощью командной строки.

Надеюсь, это сработает для вас.

В MySQL Workbench (5.2.47 CE)

нажмите Экземпляры сервера Mange (нижний правый угол)

нажмите Соединение

в поле Соединение выберите:

Локальный экземпляр ($ ServerName) — [email protected]: 3306 ‘

нажмите Изменить выбранные.

под Параметры, Имя хоста измените localhost или 127.0.0.1 на имя NetBIOS

нажмите Проверить соединение

Если это сработает для вас, отлично. Если имя хоста не изменилось, то оно было.

Ответ 8

Ошибка возникает из-за того, что сервер mysql не запускается на вашем компьютере. Вы должны запустить его вручную. Выполните следующие действия:

Загрузите и установите сервер Wamp в соответствии со своей битовой версией (32 бит или 64 бит) на вашем компьютере (http://wampserver-64bit.en.softonic.com/). позволяет загружать сервер Wamp на 64-разрядный.

Как только вы его установили, вы можете дважды щелкнуть и запустить его.. (вы можете увидеть значок в правой руке панели задач. Возможно, он скрыт. Вы можете щелкнуть стрелку, которая показывает вам скрыть запуск приложений). Нажмите на значок и перейдите в Mysql

Затем перейдите в Сервис, и там вы можете найти Начать/возобновлять службы.

И теперь это делается. Откройте рабочий стол mysql и увидите. Он будет работать.

Ответ 9

Запустите команду ALTER USER. Обязательно смените пароль на надежный пароль по вашему выбору.

sudo mysql # Войдите в MySQL

Запустите приведенную ниже команду

Теперь вы можете получить к нему доступ, используя новый пароль.

Ответ 10

Чтобы быть в курсе последних версий и более поздних посетителей:

В настоящее время я работаю над win7 64bit с различными инструментами, включая python 2.7.4, как необходимое условие для google android.

Когда я обновил с WB 6.0.8-win32 до верхних версий, чтобы иметь 64-битную производительность, у меня были некоторые проблемы, например, на 6.3.5-winx64. У меня была ошибка в представлении деталей таблиц (неупорядоченное представление), что привело к понижению до 6.2.5-winx64.

В качестве пользователя GUI легкие функции пересылки вперед/назад и относительные элементы сервера db работали хорошо, но когда мы пытаемся Database>Connect to Database , у нас будет Not connected и будет ошибка python, если мы попытаемся выполнить запрос, однако DB серверная служба абсолютно запущена и работает хорошо, и эта проблема не с сервера, а с рабочего места. Чтобы решить эту проблему, мы должны использовать Query>Reconnect to Server , чтобы явно выбрать соединение с БД, а затем почти все выглядит хорошо (это может быть связано с моими множественными соединениями db, и я не смог найти какое-то решение для определения подключения по умолчанию в рабочем столе).

В качестве примечания: потому что я использую последнюю версию Xampp (даже в зависимостях от linux:)), в последнее время Xampp использует mariadb 10 вместо mysql 5.x приводит к тому, что версия файла mysql равна 10, может вызвать некоторые проблемы, такие как переадресация разработка процедур, которые могут быть решены с помощью mysql_upgrade.exe , но при попытке проверить соединение db wb сообщит о неправильной версии, однако это не критично и работает хорошо.

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

Ответ 11

Причина была в том, что я пытался использовать новейший MySQL Workbench 8.x для подключения к MySQL Server 5.1 (оба работают на Windows Server 2012).

Когда я удалил MySQL Workbench 8.x и установил MySQL Workbench 6.3.10, он успешно подключился к базе данных localhost

Ответ 12

Я тоже долгое время боролся с этой проблемой.

Я также набрал (очевидно) некоторый хороший SO Q/A.

Похоже, что сообщение, упомянутое в вопросе «user948950», может исходить из широкого круга причин: слишком большой файл журнала, неправильные значения файла mysql.ini, пробелы в пути к файлу, проблема безопасности /acl, старые записи в реестр и т.д.

Итак, после попытки за 3 часа исправить это. Я отказался и решил сделать старую старую переустановку.

Гэри Уильямс писал (а): Привет, ребята,

У меня была точно такая же проблема, и вот как я ее работаю для меня, начиная с нерабочей установки.

Остановите службу Windows для любой существующей установки mysql.

Как и при большинстве удалений, старые файлы остаются позади. Если ваш каталог это C:mysqletc, то удалите файлы innob и т.д., но оставьте сами каталоги, а также любые существующие базы данных в «данных». Если ваш каталог — C:Program Filesetc, удалите все mysql каталоги.

Теперь стоит запустить regedit, чтобы удалить старые записи реестра, а также удалить. Если нет, удалите их.

Хорошо использовать новый .msi-установщик (только для основных файлов), однако.

Не используйте свой путь установки по умолчанию! Некоторые гении устанавливают путь с пробелами в нем! Выберите пользовательскую установку и выберите разумный путь, т.е. C:mysql (примечание от Adrien: C:mysqldata для. данных)

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

Думаю, я все вспомнил.

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

FYI: я использовал следующую команду для импорта C:/ /My SQL Server x.x/bin/mysql -u root -p .sql» , например C:/mysql/MySQL Server 5.6/bin/mysql -u root -p mySupaCoolDb

Ответ 13

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

Я обнаружил, что моя причина в том, что после того, как мой компьютер снова сработает и снова проснется, служба mysql не работает. Мое решение: перезапустите службу с именем «mysql» и перезапустите верстак. Перезапуск службы занимает некоторое время, но он работает.

Ответ 14

Моя проблема заключалась в том, что сервер MySQL фактически не был установлен. Я запустил MySQL Installer, но он не установил сервер MySQL.

Я перезапущу установщика, нажмите «Добавить», а затем добавил сервер MySQL в список. Теперь он отлично работает.

Ответ 15

В моем случае я только что установил MySQL Workbench, но после удаления MySQL Workbench и установки установщика MySQL он одинаков как для 32-разрядных, так и для 64-разрядных, после чего он работает как чудо. Надеюсь, это может быть полезно.

Источник

Ошибка в MySQL Workbench «Error Code: 1175». Причины и как исправить

Приветствую Вас на сайте Info-Comp.ru! Сегодня мы рассмотрим ситуацию, когда в среде MySQL Workbench при выполнении запроса на обновление (UPDATE) или удаление (DELETE) возникает ошибка «Error Code: 1175. You are using safe update mode». Мы поговорим о причинах возникновения этой ошибки, а также о том, как устранить эту ошибку.

Причины возникновения ошибки «Error Code: 1175» в MySQL Workbench

Данная ошибка в основном возникает, если Вы хотите обновить или удалить абсолютно все записи из таблицы, при этом вообще не указывая условие WHERE, или Вы указываете условие WHERE, но в нем нет предиката с участием первичного ключа.

Дело в том, что по умолчанию в MySQL включен режим «Безопасных обновлений» – Safe Updates Mode.

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

Сделано это для того, чтобы уберечь начинающих от случайных изменений данных в таблицах во время операций UPDATE или DELETE, так как иногда некоторые пользователи просто забывают написать условие WHERE и запускают запрос на выполнение, и тем самым вносят изменения абсолютно во все записи таблицы, что достаточно часто не является их целью.

Как исправить ошибку «Error Code: 1175» в MySQL Workbench

Данную ошибку достаточно легко устранить, так как это всего лишь ограничение, реализованное в целях безопасности.

Давайте рассмотрим способы устранения ошибки «Error Code: 1175» в MySQL Workbench.

Исходные данные

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

Заметка! Начинающим программистам рекомендую почитать мою книгу «SQL код», которая поможет Вам изучить язык SQL как стандарт, в ней рассматриваются все базовые конструкции языка SQL, приводится много примеров и скриншотов.

И допустим, у нас появилась задача обновить столбец price у всех записей этой таблицы. Давайте попытаемся это сделать, написав следующий запрос.

Как видите, у нас возникла ошибка «Error Code: 1175. You are using safe update mode», а данные нам все равно нужно обновить, поэтому давайте исправим эту ситуацию.

Способ 1 – Отключение режима безопасных обновлений

Самым очевидным способом решения проблемы является отключение режима безопасных обновлений.

Например, для отключения этого режима на время сеанса можно использовать следующую инструкцию.

Или зайти в настройки MySQL Workbench «Edit -> Preferences -> SQL Editor» и снять галочку «Save Updates», тем самым режим безопасных обновлений будет отключен насовсем (чтобы изменения вступили в силу, необходимо перезапустить MySQL Workbench, т.е. переподключиться к MySQL Server).

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

Способ 2 – Использование в условии первичного ключа

Чтобы не трогать сам режим, мы можем просто выполнить требования, которые накладывает данный режим.

Например, в условии WHERE использовать ключ. Для решения нашей задачи мы можем указать product_id > 0.

Мы видим, что запрос успешно выполнился, и все записи обновлены.

Способ 3 – Использование оператора LIMIT

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

В данном случае также запрос выполнился успешно.

На сегодня это все, надеюсь, материал был Вам полезен, пока!

Источник

MySQL — система управления базами данных (СУБД) с открытым исходным кодом от компании Oracle. Она была разработана и оптимизирована специально для работы веб-приложений. MySQL является неотъемлемой частью таких веб-сервисов, как Facebook, Twitter, Wikipedia, YouTube и многих других.

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

Не удаётся подключиться к локальному серверу

Одной из распространённых ошибок подключения клиента к серверу является «ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)».

Эта ошибка означает, что на хосте не запущен сервер MySQL (mysqld) или вы указали неправильное имя файла сокета Unix или порт TCP/IP при попытке подключения.

Убедитесь, что сервер работает. Проверьте процесс с именем mysqld на хосте сервера, используя команды ps или grep, как показано ниже.

$ ps xa | grep mysqld | grep -v mysqld

Если эти команды не показывают выходных данных, то сервер БД не работает. Поэтому клиент не может подключиться к нему. Чтобы запустить сервер, выполните команду systemctl.

$ sudo systemctl start mysql        #Debian/Ubuntu
$ sudo systemctl start mysqld       #RHEL/CentOS/Fedora

Чтобы проверить состояние службы MySQL, используйте следующую команду:

$ sudo systemctl status mysql       #Debian/Ubuntu
$ sudo systemctl status mysqld      #RHEL/CentOS/Fedora

Если в результате выполнения команды произошла ошибка службы MySQL, вы можете попробовать перезапустить службу и ещё раз проверить её состояние.

$ sudo systemctl restart mysql
$ sudo systemctl status mysql

Если сервер работает (как показано) и вы по-прежнему видите эту ошибку, вам следует проверить, не заблокирован ли порт TCP/IP брандмауэром или любой другой службой блокировки портов.

Для поиска порта, который прослушивается сервером, используйте команду netstat.

$ sudo netstat -tlpn | grep "mysql"

Ещё одна похожая и часто встречающаяся ошибка подключения — «(2003) Can’t connect to MySQL server on ‘server’ (10061)». Это означает, что в сетевом соединении было отказано.

Следует проверить, работает ли в системе сервер MySQL (смотрите выше) и на тот ли порт вы подключаетесь (как найти порт, можно посмотреть выше).

Похожие частые ошибки, с которыми вы можете столкнуться при попытке подключиться к серверу MySQL:

ERROR 2003: Cannot connect to MySQL server on 'host_name' (111)
ERROR 2002: Cannot connect to local MySQL server through socket '/tmp/mysql.sock' (111)

Ошибки запрета доступа в MySQL

В MySQL учётная запись (УЗ) определяется именем пользователя и клиентским хостом, с которого пользователь может подключиться. УЗ может также иметь данные для аутентификации (например, пароль).

Причин для запрета доступа может быть много. Одна из них связана с учётными записями MySQL, которые сервер разрешает использовать клиентским программам при подключении. Это означает, что имя пользователя, указанное в соединении, может не иметь прав доступа к базе данных.

В MySQL есть возможность создавать учётные записи, позволяющие пользователям клиентских программ подключаться к серверу и получать доступ к данным. Поэтому при ошибке доступа проверьте разрешение УЗ на подключение к серверу через клиентскую программу.

Увидеть разрешённые привилегии учётной записи можно, выполнив в консоли команду SHOW GRANTS
Входим в консоль (пример для Unix, для Windows консоль можно найти в стартовом меню):

В консоли вводим команду:

> SHOW GRANTS FOR 'tecmint'@'localhost';

Дать привилегии конкретному пользователю в БД по IP-адресу можно, используя следующие команды:

> grant all privileges on *.test_db to 'tecmint'@'192.168.0.100';
> flush privileges;

Ошибки запрещённого доступа могут также возникнуть из-за проблем с подключением к MySQL (см. выше).

Потеря соединения с сервером MySQL

С этой ошибкой можно столкнуться по одной из следующих причин:

• плохое сетевое соединение;
• истекло время ожидания соединения;
• размер BLOB  больше, чем max_allowed_packet.

В первом случае убедитесь, что у вас стабильное сетевое подключение (особенно, если подключаетесь удалённо).

Если проблема с тайм-аутом соединения (особенно при первоначальном соединении MySQL с сервером), увеличьте значение параметра connect_timeout.

В случае с размером BLOB нужно установить более высокое значение для max_allowed_packet в файле конфигурации /etc/my.cnf в разделах [mysqld] или [client] как показано ниже.

[mysqld]
connect_timeout=100
max_allowed_packet=500M

Если файл конфигурации недоступен, это значение можно установить с помощью следующей команды.

> SET GLOBAL connect_timeout=100;
> SET GLOBAL max_allowed_packet=524288000;

Слишком много подключений

Эта ошибка означает, что все доступные соединения используются клиентскими программами. Количество соединений (по умолчанию 151) контролируется системной переменной max_connections. Устранить проблему можно, увеличив значение переменной в файле конфигурации /etc/my.cnf.

[mysqld]
max_connections=1000

Недостаточно памяти

Если такая ошибка возникла, это может означать, что в MySQL недостаточно памяти для хранения всего результата запроса.

Сначала нужно убедиться, что запрос правильный. Если это так, то нужно выполнить одно из следующих действий:

• если клиент MySQL используется напрямую, запустите его с ключом --quick switch, чтобы отключить кешированные результаты;
• если вы используете драйвер MyODBC, пользовательский интерфейс (UI) имеет расширенную вкладку с опциями. Отметьте галочкой «Do not cache result» (не кешировать результат).

Также может помочь MySQL Tuner. Это полезный скрипт, который подключается к работающему серверу MySQL и даёт рекомендации по настройке для более высокой производительности.

$ sudo apt-get install mysqltuner     #Debian/Ubuntu
$ sudo yum install mysqltuner         #RHEL/CentOS/Fedora
$ mysqltuner

MySQL продолжает «падать»

Если такая проблема возникает, необходимо выяснить, заключается она в сервере или в клиенте. Обратите внимание, что многие сбои сервера вызваны повреждёнными файлами данных или индексными файлами.

Вы можете проверить состояние сервера, чтобы определить, как долго он работал.

$ sudo systemctl status mysql       #Debian/Ubuntu
$ sudo systemctl status mysqld      #RHEL/CentOS/Fedora

Чтобы узнать время безотказной работы сервера, запустите команду mysqladmin.

$ sudo mysqladmin version -p 

Кроме того, можно остановить сервер, сделать отладку MySQL и снова запустить службу. Для отображения статистики процессов MySQL во время выполнения других процессов откройте окно командной строки и введите следующее:

$ sudo mysqladmin -i 5 status

Или

$ sudo mysqladmin -i 5 -r status

Заключение

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

• Первый и самый важный шаг — просмотреть журналы MySQL, которые хранятся в каталоге /var/log/mysql/. Вы можете использовать утилиты командной строки вроде tail для чтения файлов журнала.
• Если служба MySQL не запускается, проверьте её состояние с помощью systemctl. Или используйте команду journalctl (с флагом -xe) в systemd.
• Вы также можете проверить файл системного журнала (например, /var/log/messages) на предмет обнаружения ошибок.
• Попробуйте использовать такие инструменты, как Mytop, glances, top, ps или htop, чтобы проверить, какая программа использует весь ресурс процессора или блокирует машину. Они также помогут определить нехватку памяти, дискового пространства, файловых дескрипторов или какого-либо другого важного ресурса.
• Если проблема в каком-либо процессе, можно попытаться его принудительно остановить, а затем запустить (при необходимости).
• Если вы уверены, что проблемы именно на стороне сервера, можете выполнить команды: mysqladmin -u root ping или mysqladmin -u root processlist, чтобы получить от него ответ.
• Если при подключении проблема не связана с сервером, проверьте, нормально ли работает клиент. Попробуйте получить какие-либо его выходные данные для устранения неполадок.

Перевод статьи «Useful Tips to Troubleshoot Common Errors in MySQL»

Hi,

I am facing «ORA-22288: file or LOB operation FILEOPEN failed» error while running apex_epg_config step. But all the steps before that (i.e. APEX Install [@apexins users users temp /i/] and change admin password) went all fine.
I am trying to install APEX 4.1 on «Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 — 64bit Production».

I went through [url https://forums.oracle.com/forums/thread.jspa?messageID=9673913]this thread. But I am not passing /apex directory (apex directory is under «C:/Ash/Technical/Database/Oracle/apex4.1») , here is the outcome:

C:AshTechnicalDatabaseOracleapex4.1apex>
11:33:41 sys@dev10db> @apex_epg_config.sql C:/Ash/Technical/Database/Oracle/apex4.1

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.21

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.03

Directory created.

Elapsed: 00:00:00.03
declare
*
ERROR at line 1:
ORA-22288: file or LOB operation FILEOPEN failed
No such file or directory
ORA-06512: at "SYS.XMLTYPE", line 296
ORA-06512: at line 18


Elapsed: 00:00:00.04

Commit complete.

Elapsed: 00:00:00.00

PL/SQL procedure successfully completed.

Elapsed: 00:00:01.14
declare
*
ERROR at line 1:
ORA-31001: Invalid resource handle or path name "/images"
ORA-06512: at "XDB.DBMS_XDB", line 473
ORA-06512: at line 37


Elapsed: 00:00:00.17
timing for: Load Images
Elapsed: 00:00:01.42

Session altered.

Elapsed: 00:00:00.00

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.48

Commit complete.

Elapsed: 00:00:00.01

Session altered.

Elapsed: 00:00:00.01

Directory dropped.

Elapsed: 00:00:00.07

I am installing from my windows XP, but the db server is on Linux.

Error above (line 18) is actually on this line of «apex_epg_config_core.sql» (my db charset is UTF8)
filelist_xml xmltype := xmltype(bfilename(upload_directory_name,file_list),nls_charset_id(‘AL32UTF8’));

The error clearly suggest that the there is an issue with access my directory or file in that directory.
And I believe the 2nd error «ORA-31001: Invalid resource handle or path name «/images»», will go itself once the first one is resolved.

I went through the documentation and other forum threads, but I am stuck with this EPG install, it may be very silly thing that I may be missing, but any help in this matter would be highly appreciated.

Thanks,
Ash

Edited by: ash0602 on Sep 5, 2011 5:19 PM