Mysql error or die: MySQL query shows die error in PHP

🍌 Полезные советы по устранению распространенных ошибок в MySQL – Information Security Squad

MySQL – широко используемая система управления реляционными базами данных (RDMS) с открытым исходным кодом, принадлежащая Oracle.

На протяжении многих лет он был выбором по умолчанию для веб-приложений и по-прежнему остается популярным по сравнению с другими механизмами баз данных.

См. также Как установить последний MySQL 8.0 на RHEL / CentOS и Fedora

MySQL был разработан и оптимизирован для веб-приложений – он является неотъемлемой частью основных веб-приложений, таких как Facebook, Twitter, Wikipedia, YouTube и многих других.

Ваш сайт или веб-приложение работают на MySQL?

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

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

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

Одной из распространенных ошибок подключения клиента к серверу в 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 не заблокирован брандмауэром или любой службой блокировки портов.

$ ps xa | grep mysqld | grep -v mysqld

4 способа узнать, какие порты прослушиваются в Linux

$ sudo netstat -tlpn | grep "mysql"

2. Не удается подключиться к серверу MySQL

Другая часто встречающаяся ошибка подключения -“(2003) Can’t connect to MySQL server on ‘server’ (10061)”,  что означает, что в сетевом соединении было отказано.

Здесь начнем с проверки того, что в системе работает сервер MySQL, как показано выше.

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

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

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

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

3. Доступ запрещен – ошибка в MySQL

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

Кроме того, учетная запись может также иметь учетные данные для аутентификации, такие как пароль.

Хотя существует много разных причин ошибок «Доступ запрещен», одна из распространенных причин связана с учетными записями MySQL, которые сервер разрешает использовать клиентским программам при подключении.

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

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

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

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

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

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

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

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

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

Вы можете столкнуться с этой ошибкой Lost Connection to MySQL Server по одной из следующих причин: плохое сетевое соединение, время ожидания соединения или проблема со значениями BLOB, которые больше, чем max_allowed_packet.

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

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

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

[mysqld]
connect_timeout=100
max_allowed_packet=500M

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

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

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

Если клиент MySQL обнаруживает ошибку «too many connections», это означает, что все доступные соединения используются другими клиентами.

Количество соединений (по умолчанию 151) контролируется системной переменной max_connections;

Вы можете устранить проблему, увеличив ее значение, чтобы разрешить больше подключений в файле конфигурации /etc/my.cnf.

[mysqld]
max_connections=1000

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

Если вы выполняете запрос с помощью клиентской программы MySQL и сталкиваетесь с рассматриваемой ошибкой -> Out of Memory MySQL, это означает, что в MySQL недостаточно памяти для хранения всего результата запроса.

Первый шаг – убедиться, что запрос правильный, если это так, то выполните следующие действия:

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

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

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

7. MySQL продолжает ломаться

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

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

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

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

Либо запустите следующую команду mysqladmin, чтобы узнать время безотказной работы сервера MySQL.

$ sudo mysqladmin version -p 

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

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

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

$ sudo mysqladmin -i 5 status
или
$ sudo mysqladmin -i 5 -r status

Исправление работы MySQL при поломке innoDB-таблиц / Хабр

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

Я (быть может, как и вы) — разработчик сайтов, и мне, чтобы все мои наработки не потерялись нужен SVN. А так как я работаю не один, то еще, как минимум, и общая БД. Несколько лет назад мы приобрели NAS-сервер Synology DS-101 (Tom`s Guide или Nix), устроили там хранилище, включили базу (правда, MySQL4). Несколько лет служил он нам верой и правдой, пережил приход пьяных электриков (когда нас сначала подключили на 380В, а потом спохватились — почти все погорело), но вот… несколько недель назад база не хотела загружаться. Пришлось исправлять.

Все бы ничего, если бы этот случай не повторился…

В первый раз на сервер в срочном порядке была залита новая прошивка, разрешающая доступ по telnet. Не забываем, там очень сильно урезанный линукс — Linux version 2.4.22-uc0 — установка чего-либо производится через telnet, а по SSH система требует рута, под которым не пускает. После пары часов была выявлена проблема — не запускается именно демон mysqld. Попытавшись вручную запустить mysqld, вылезала ошибка, она же собственно была и в логах, следующего содержания:

100209 14:04:59 mysqld started

100209 14:05:00 [Warning] Setting lower_case_table_names=2 because file system for /volume1/@database/mysql/ is case insensitive

InnoDB: Database page corruption on disk or a failed

InnoDB: file read of page 5.

InnoDB: You may have to recover from a backup.

100209 14:05:00 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex (...большой дамп ~ на 16КБ. ..)InnoDB: End of page dump

100209 14:05:04 InnoDB: Page checksum 2825884538, prior-to-4.0.14-form checksum 2024336829

InnoDB: stored checksum 1598293605, prior-to-4.0.14-form stored checksum 2024336829

InnoDB: Page lsn 0 2531807, low 4 bytes of lsn at page end 2531807

InnoDB: Page number (if stored to page already) 5,

InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0

InnoDB: Database page corruption on disk or a failed

InnoDB: file read of page 5.

InnoDB: You may have to recover from a backup.

InnoDB: It is also possible that your operating

InnoDB: system has corrupted its own file cache

InnoDB: and rebooting your computer removes the

InnoDB: error.

InnoDB: If the corrupt page is an index page

InnoDB: you can also try to fix the corruption

InnoDB: by dumping, dropping, and reimporting

InnoDB: the corrupt table. You can use CHECK

InnoDB: TABLE to scan your table for corruption.

InnoDB: See also dev.mysql.com/doc/mysql/en/Forcing_recovery.html

InnoDB: about forcing recovery.

InnoDB: Ending processing because of a corrupt database page.

100209 14:05:04 mysqld ended

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

Полазив по интернету, нашлось два пути решения данной проблемы:

Первый и Официальный — dev.mysql.com

Второй и менее официальный — mysqlperformanceblog.com

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

mysqld --innodb_force_recovery=4

таким образом, мы даем понять серверу, чтобы он:

Prevent insert buffer merge operations. If they would cause a crash, do not do them. Do not calculate table statistics.

(Предотвращать операции слияния вставки буфера. Если они вызывают аварию, не выполнять их. Не считать статистику таблиц)

Если короче — то чтобы сдампить таблицы, и перераспределить место на диске под таблицы innodb.

С этим параметром сервер запускается, но CHECK TABLE показывает OK. OPTIMIZE TABLE для innodb-таблиц не поддерживается движком.

Нужно каким-либо образом обратиться к таблицам innodb (например, создать INSERT-запрос) — mysqld перераспределит место. После перераспределения места мы сможем запустить демон myslqd в нормальном режиме, т.е. просто перезапустив NAS-сервер (это в нашем случае). Не могу сказать, что какие-либо данные недоступны — сдампил без ошибок и проблем. Возможно, в таком случае мы все же что-то теряем — пусть меня поправят специалисты.

Второй вариант (с майэскулперформансблога) представляет собой запуск демона с innodb_force_recovery=1, создание <new_table> c движком MyISAM и попытку загнать туда все записи из таблицы с innodb. Вкратце описывается это так:

CREATE TABLE <new_table> LIKE <crashed_table>;

INSERT INTO <new_table> SELECT * FROM <crashed_table>;

И переименовываем.

Если же нужно найти именно те строки, на которых он рубится, используется метод нескольких вставок (INSERT IGNORE) в новую таблицу с лимитом. Там все подробно расписано.

Надеюсь, эта маленькая статья кому-то поможет в похожей ситуации, потому как мне первый раз понадобилось достаточно большое время, чтобы все исправить. У меня было время — у вас его может не быть. Также призываю специалистов по MySQL включиться в обсуждение данного вопроса — почему innodb падает.

Миграция на MySQL 8: проблемы и решения

27 Сентябрь 2018

MySQL 8 migration: issues and solutions

В начале этого года состоялся релиз новой 8 ветки сервера баз данных MySQL. Нумерация была измененена в связи с новыми принципами версионирования MySQL и, по факту, новый выпуск представляет собой версию 5.8.

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

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

Итак, вы решили использовать MySQL 8. Опустим здесь сам процесс установки или обновления предыдущей инсталляции — в целом они стандартны и практически не отличаются от процедур применяемых ранее.

В распоряжении автора была последняя доступная на момент написания статьи версия MySQL 8 развёрнутая в среде FreeBSD 11.2.

root@zotum:~ # mysql --version
mysql  Ver 8.0.12 for FreeBSD11.2 on amd64 (Source distribution)
root@zotum:~ # uname -v
FreeBSD 11.2-RELEASE-p3 #0: Thu Sep  6 07:14:16 UTC 2018     [email protected]:/usr/obj/usr/src/sys/GENERIC

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

root@zotum:~ # php --version
PHP 7.2.10 (cli) (built: Sep 24 2018 00:28:21) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.10, Copyright (c) 1999-2018, by Zend Technologies

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

Первым же отмеченным отличием MySQL 8 стало изменение схемы аутентификации по умолчанию. Вместо привычной mysql_native_password её место заняла новая caching_sha2_password в качестве Preferred Authentication Plugin, которая декларируется как более безопасная и надёжая альтернатива старой схемы.

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

mysqli_real_connect(): The server requested authentication method unknown to the client [caching_sha2_password]
mysqli_real_connect(): (HY000/2054): The server requested authentication method unknown to the client

Однако, в настоящее время все стандартные драйверы PHP, к примеру, популярный PDO, за исключением девелоперского расширения mysql_xdevapi её не поддерживают. Реализация новой схемы ожидается в выпуске PHP 7.3.

В этой связи, рекомендуется предпринять ряд действий для обеспечения работы текущих версий софта. Первым может стать измнение схемы аутентификации по умолчанию на её традиционный вариант в файле конфигурации MySQL my.cnf путём добавления в секцию [mysqld] соответветствующего параметра.

root@zotum:~ # cat /usr/local/etc/mysql/my.cnf
# $FreeBSD: head/databases/mysql80-server/files/my.cnf.sample.in 469734 2018-05-12 15:35:25Z mmokhi $
...
[mysqld]
...
default_authentication_plugin   = mysql_native_password
...

Далее, если вы уже добавили пользователей с новой схемой аутентификации, а, по меньшей мере один из них — root, точно был добавлен на этапе инсталляции, то следует изменить им схему на традиционный вариант.

root@zotum:~ # mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1745
Server version: 8. 0.12 Source distribution

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

root@localhost [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
Query OK, 0 rows affected (0.01 sec)
...

Вторым моментом, с которым некоторым придётся столкнуться, это появление ключевых и зарезервированных слов, которые нельзя использовать без экранирования знаком ` (backtick или знак акцента).

Их актуальный список можно получить непосредственно из базы со схемой данных MySQL information_schema.

...
root@localhost [(none)]> USE information_schema;
Database changed
root@localhost [information_schema]> SELECT WORD FROM INFORMATION_SCHEMA.KEYWORDS WHERE RESERVED = 1;
. ..

В случае, если в SQL-коде в наименовании таблиц и/или полей встретится неэкранированное слово из данного списка, это приведёт к ошибке.

SQLSTATE[42000]: Syntax error or access violation: 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 'groups WHERE deleted = 0 AND uid = 2 ORDER BY gname ASC' at line 1

В данном случае, было использовано зарезервированное слово groups.

Безусловно, экранирование имён полей и таблиц при помощи ` является хорошим тоном оформле

PHP — Ошибка переноса Laravel mysql

Недавно я отформатировал свой Mac Book Pro, после клонирования проекта из github и установки необходимых мне вещей, таких как MySql и Sequel Pro, я попытался перенести информацию базы данных, но у меня появляется эта ошибка:

   Illuminate\Database\QueryException  : SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER' (SQL: select * from information_schema. tables where table_schema = fisica and table_name = migrations)

Exception trace:

1   PDOException::("SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'")

Версии:

Mysql 8.0.11

Ларавел 5.6.12

PHP 7.1.14 (cli)

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=fisica
DB_USERNAME=xxx
DB_PASSWORD=xxx

Я создал базу данных из Sequel PRO GUI

18

Решение

Я наконец нашел решения несколько дней назад и вспомнил этот пост.
в config/database.php файл в теге mysql, режимы sql должны быть добавлены, чтобы пропустить эту ошибку. https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sql-mode-full

Мой массив MySQL закончился так:

    'mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
'unix_socket' => env('DB_SOCKET', ''),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'strict' => true,
'engine' => null,
'modes'  => [
'ONLY_FULL_GROUP_BY',
'STRICT_TRANS_TABLES',
'NO_ZERO_IN_DATE',
'NO_ZERO_DATE',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_ENGINE_SUBSTITUTION',
],
],

44

Другие решения

При чтении документации по mysql 8. 0 похоже, что NO_AUTO_CREATE_USER был удален из sql-режима. Я подозреваю, что ваш my.cnf ссылается на это и должен быть удален из вашего conf и любых настроек mysql внутри, а ваш mysqld перезапущен.

Имейте в виду, я не обновился до MySQL 8.0 и просто читал документацию. Я счастлив, используя 5.6.

https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html

Использование GRANT для создания пользователей. Вместо этого используйте CREATE USER. Следование этой практике делает режим SQL NO_AUTO_CREATE_USER несущественным для операторов GRANT, поэтому он также удаляется.

1

По сути, вы должны добавить этот код в конце каждое из ваших соединений с драйвером mysql

'modes' => [
'ONLY_FULL_GROUP_BY',
'STRICT_TRANS_TABLES',
'NO_ZERO_IN_DATE',
'NO_ZERO_DATE',
'ERROR_FOR_DIVISION_BY_ZERO',
'NO_ENGINE_SUBSTITUTION',
],

1

Моя проблема заключалась в неправильном имени базы данных в конфиге.

-1

Исправляем Error MySQL connect

Ошибка Error MySQL connect возникает по причине того, что невозможно соединиться с mysql сервером. Так же, часто php возвращает похожую ошибку:
Access denied for user 'bd'@'localhost' (using password: YES) in db.php on line 6. Connection error!, что говорит о том, что не получается подключиться к базе данных. Ошибка Error MySQL connect вызывается если: сервер MySQL не доступен, либо вы не можете к нему подключиться, т.е. логин, пароль или адрес сервера указаны не верно. Еще раз убедитесь, что данные введены верно и нет никаких опечаток.

Если у вас есть SSH доступ, попробуйте перезагрузить SQL. Для этого авторизуйтесь в системе с правами администратора и выполните команду
# service mysqld restart

Если MySQL сервер на Debian или Ubuntu Linux, то команда будет
/etc/init.d/mysql restart

или же
systemctl restart mysqld. service

Узнать состояние mysql — вместо команды restart выполните команду status.
Более подробно читайте тут: Error connecting mysql server

Итак, подитожим:

• первым делом проверяйте, верны ли доступы к БД — сервер, логин, пароль, юзер.
• Если эта ошибка появилась на хостинге и сайт работал до этого нормально — пишите в поддержку — что то не так сервером БД. Может быть так что на хостинге ведутся тех.работы.
• Если ошибка Error MySQL connect появляется на сервере, проверяйте статус БД, перезагружайте.
• Используете виртуальный сервер, типа Open Server — перезагрузите его.

У движков есть файл конфигурации, где указываются доступы к MySQL. Приведем 6 самых распространенных движков.

Файл конфигурации 1С-Битрикс

\bitrix\php_interface\dbconn.php

Файл конфигурации MODX

\core\config\config. inc.php

Файл конфигурации WordPress

\wp-config.php в корне сайта

Файл конфигурации Drupal

\sites\default\settings.php

Файл конфигурации Joomla!

\configuration.php в корне сайта

Файл конфигурации Opencart

В Opencart за подключение к MySQL отвечают файлы config.php и admin/config.php в корне сайта

[РЕШЕНО] MySQL — ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

На вновь установленном сервере с Oracle MySQL 5.7 при создании пользователя может возникнуть ошибка ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

Давайте разберемся откуда она появилась и как её устранить.

Корень проблемы кроется в активированном по умолчанию плагине validate_password которому не нравятся даже такого рода пароли ‘Gi7he9Whugb0’, что довольно странно, ведь пароль достаточно стойкий.

Посмотрим активирован ли плагин:

mysql -u root -p

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE'validate%';

+-------------------+---------------+
 | PLUGIN_NAME       | PLUGIN_STATUS |
 +-------------------+---------------+
 | validate_password | ACTIVE        |
 +-------------------+---------------+
 1 row in set (0.01 sec)

Как мы видим, плагин активирован. Посмотрим на настройки плагина:

mysql> SHOW GLOBAL VARIABLES LIKE 'validate_password%';

+--------------------------------------+--------+
 | Variable_name                        | Value  |
 +--------------------------------------+--------+
 | validate_password_check_user_name    | OFF    |
 | validate_password_dictionary_file    |        |
 | validate_password_length             | 8      |
 | validate_password_mixed_case_count   | 1      |
 | validate_password_number_count       | 1      |
 | validate_password_policy             | MEDIUM |
 | validate_password_special_char_count | 1      |
 +--------------------------------------+--------+
 7 rows in set (0. 07 sec)

Что же MySQL не понравилось в нашем пароле ?
А не понравилось то, что в соответствии с настройкой validate_password_special_char_count в пароле должен быть хотя бы один спецсимвол, например восклицательный знак (!).

Самым правильным решением будет конечно соблюдение установленных правил при генерации пароля, но если хочется немного их подправить, то давайте сделаем это:

mysql> SET GLOBAL validate_password_special_char_count = 0;

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

Если Вас устраивает такая политика, то не забудьте добавить в /etc/mysql/my.cnf в секцию [mysqld] настройку validate_password_special_char_count=0

sudo nano /etc/mysql/my.cnf

[mysqld] 
validate_password_special_char_count=0

Если Вы хотите, чтобы никто не смог выгрузить плагин validate_password, то в /etc/mysql/my.cnf в секцию [mysqld] нужно добавить настройку validate-password=FORCE_PLUS_PERMANENT

sudo nano /etc/mysql/my.cnf

[mysqld] 
validate-password=FORCE_PLUS_PERMANENT

Если Вы хотите отключить плагин на совсем, то набираем следующее:

mysql> UNINSTALL PLUGIN validate_password;

Для повторной активации плагина выполните:

mysql> INSTALL PLUGIN validate_password SONAME 'validate_password.so';

Если есть вопросы, то пишем в комментариях.

Также можете помочь проекту, заранее всем СПАСИБО!!!

.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

0
0
vote

Рейтинг статьи

Устранение ошибок mysqldump в Amazon RDS для MySQL или MariaDB

Я использую инстанс БД Amazon Relational Database Service (Amazon RDS), на котором работает MySQL или MariaDB. Я использую mysqldump для импорта или экспорта данных и получаю сообщение об ошибке. Как мне найти и устранить эту ошибку?

Краткое описание

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

• Не удалось выполнить FLUSH TABLES с ошибками READ LOCK
• Max_allowed_packet ошибок
• Привилегии SUPER и ошибки DEFINER
• Ошибки потери или прерывания соединения

Разрешение

Не удалось выполнить FLUSH TABLES с ошибкой READ LOCK

При использовании параметра —master-data с mysqldump для экспорта данных вы можете получить ошибку, подобную следующей:

«mysqldump: Не удалось выполнить ‘FLUSH TABLES WITH READ LOCK’: доступ запрещен для пользователя ‘user’ @ ‘%’ (с использованием пароля: ДА)» (1045) «

Опция —master-data получает FLUSH TABLES WITH READ LOCK .Для этого требуются привилегии SUPER , которых нет у главного пользователя Amazon RDS, а Amazon RDS не поддерживает GLOBAL READ LOCK . Когда MySQL запускает оператор CHANGE MASTER TO для получения информации журнала, имя и положение (координаты) двоичного файла журнала записываются в файл mysqldump. Для получения дополнительной информации см. Документацию MySQL для ER_ACCESS_DENIED_ERROR.

Чтобы устранить эту ошибку, удалите параметр —master-data . Когда вы удаляете эту опцию, вам не дается точная позиция журнала в mysqldump.Чтобы обойти эту проблему, либо используйте mysqldump, когда ваше приложение остановлено, либо возьмите mysqldump из реплики чтения Amazon RDS. Это позволяет вам получить точную позицию журнала, выполнив SHOW SLAVE STATUS, потому что остановка реплики подтверждает, что позиции бинарного журнала не меняются. Выполните следующие действия, чтобы создать mysqldump из реплики чтения Amazon RDS MySQL этого инстанса БД RDS.

1. Установите значение для хранения двоичного журнала.

2. Остановите репликацию, выполнив следующую команду на реплике чтения:

  ВЫЗОВ mysql.rds_stop_replication;  

3. Возьмите mysqldump без —master-data = 2 из читаемой реплики.

4. Запустите SHOW SLAVE STATUS на реплике и запишите Master_Log_File и Exec_Master_Log_Pos .

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

  ВЫЗОВ mysql.rds_start_replication;  

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

Max_allowed_packet ошибок

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

«Ошибка 2020: размер пакета превышает ‘max_allowed_packet’ байтов при выгрузке таблицы ‘tb_name` в строке: XX»

Эта ошибка возникает, когда команда mysqldump запрашивает пакет, размер которого превышает значение параметра max_allowed_packet , установленного для вашего экземпляра БД RDS.Дополнительные сведения см. В документации MySQL для пакета слишком большой.

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

  $ mysqldump --max_allowed_packet = 1G ......  

Привилегии SUPER и ошибки DEFINER

При использовании mysqldump для импорта данных в экземпляр БД RDS, на котором выполняется MySQL или MariaDB, вы можете получить ошибку, подобную следующей:

«ОШИБКА 1227 (42000) в строке XX: Доступ запрещен; вам необходимы (по крайней мере, одна из) привилегия SUPER для этой операции»

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

Ошибки потери или прерывания соединения

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

«mysqldump: ошибка 2013: потеряно соединение с сервером mysql во время запроса при сбросе таблицы»

—или —

«mysqldump: прервано соединение XXXXXX с базой данных: ‘db_name’ user: ‘master_user’ host: ‘XXXXXXX’ (Истекло время ожидания записи коммуникационных пакетов)»

Дополнительную информацию о причине и устранении этой ошибки см. В разделе Как устранить ошибку «Сервер MySQL ушел» при подключении к моему инстансу БД MySQL Amazon RDS?

Вам нужна оплата или техническая поддержка?

Общие сообщения об ошибках MySQL в сценариях или программах PHP

MySQL — журнал ошибок | Учебник mysql

Пример

Журнал ошибок заполняется информацией о запуске и остановке, а также о критических событиях, обнаруженных сервером.

Ниже приводится пример его содержания:

Переменная log_error содержит путь к файлу журнала для регистрации ошибок.

При отсутствии записи в файле конфигурации для log_error система по умолчанию установит свои значения на @@ hostname .err в datadir . Обратите внимание, что log_error не является динамической переменной. Таким образом, изменения выполняются посредством изменений файлов cnf или ini и перезапуска сервера (или путем просмотра «Очистка и переименование файла журнала ошибок» в ссылке на страницу руководства внизу).

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

Глобальная переменная log_warnings устанавливает уровень детализации, который зависит от версии сервера. Следующий фрагмент иллюстрирует:

  ВЫБРАТЬ @@ log_warnings; - запишите свои предыдущие настройки
УСТАНОВИТЬ GLOBAL log_warnings = 2; - установка выше 1 увеличивает производительность (см. версию сервера)
  

log_warnings , как показано выше, является динамической переменной.

Изменения файла конфигурации в файлах cnf и ini могут выглядеть следующим образом.

  [mysqld]
log_error = /path/to/CurrentError.log
log_warnings = 2
  

MySQL 5.7.2 расширил уровень детализации предупреждений до 3 и добавил GLOBAL log_error_verbosity . Опять же, это было введено в 5.7.2. Его можно установить динамически и проверить как переменную или установить с помощью настроек файла конфигурации cnf или ini .

Начиная с MySQL 5.7.2:

  [mysqld]
log_error = / путь / к / CurrentError.журнал
log_warnings = 2
log_error_verbosity = 3
  

См. Страницу руководства MySQL, озаглавленную «Журнал ошибок», специально для очистки и переименования файла журнала ошибок, и раздел «Подробность журнала ошибок » с версиями, относящимися к log_warnings и error_log_verbosity .

MySQL.таблица пользователей повреждена. «Байки ленивого толстого DBA

»

Привет, друзья,

Во время работы с одним из клиентов для его новой установки я столкнулся со странной проблемой при запуске демона MYSQL (5.7.20) на RHEL6, когда служба MYSQLD не запускалась с ошибками, указанными ниже, или проблемами, зарегистрированными в журналах ошибок.

[root @ dixitlab ~] # service mysqld start
Не удалось запустить демон MySQL.
Запуск mysqld: [ FAILED ]

Фрагмент журнала ошибок:

2017-11-15T10: 21: 03.957212Z 0 [Примечание] InnoDB: Размер файла ‘./ibtmp1’ теперь составляет 12 МБ.
2017-11-15T10: 21: 11.147615Z 0 [Примечание] InnoDB: найдено 96 сегментов отката повторного выполнения. 96 активных сегментов отката повторного выполнения.
2017-11-15T10: 21: 11.147902Z 0 [Примечание] InnoDB: 32 сегмента отката без повторения активны.
2017-11-15T10: 21: 11.2

Z 0 [Примечание] InnoDB: создание системных таблиц sys_virtual.
2017-11-15T10: 21: 11.300921Z 0 [Примечание] InnoDB: создана sys_virtual таблица
2017-11-15T10: 21: 11.301245Z 0 [Примечание] InnoDB: ожидание начала очистки
2017-11-15T10: 21 : 11.354201Z 0 [Примечание] InnoDB: 5.7.20 запущен; порядковый номер журнала 0
2017-11-15T10: 21: 11.354623Z 0 [Примечание] Плагин «FEDERATED» отключен.
2017-11-15T10: 21: 11.354976Z 0 [Примечание] InnoDB: page_cleaner: предполагаемый цикл 1000 мс занял 9560 мс. Настройки могут быть неоптимальными. (сброшено = 0 и выселено = 0, в течение времени.)
2017-11-15T10: 21: 11.355390Z 0 [Примечание] InnoDB: загрузка пулов буферов из / var / lib / mysql / ib_buffer_pool
2017-11 -15T10: 21: 11.569467Z 0 [Предупреждение] Подключаемый модуль системной таблицы должен быть транзакционным.
2017-11-15T10: 21: 11.570388Z 0 [Примечание] Переменные генератора uuid, current_pid: 29102, server_start_time: 1510741261, bytes_sent: 0,
2017-11-15T10: 21: 11.570971Z 0 [Примечание] Создан uuid: ‘b3e664f7-c9ee-11e7-9b23-000c29593ffb’, server_start_time: 8191484773744281275, bytes_sent: 442
2017-11-15T10: 21: 11.571109Z 0 [Предупреждение] Существующий UUID не найден, поэтому мы предполагаем, что это первый раз что этот сервер был запущен. Создание нового UUID: b3e664f7-c9ee-11e7-9b23-000c29593ffb.
2017-11-15T10: 21: 11.573332Z 0 [Предупреждение] Таблица Gtid не готова к использованию. Таблица «mysql.gtid_executed» не может быть открыта.
2017-11-15T10: 21: 11.573745Z 0 [Предупреждение] Не удалось настроить SSL из-за следующей ошибки библиотеки SSL: контекст SSL невозможно использовать без сертификата и закрытого ключа
2017-11-15T10: 21: 11.574116Z 0 [Примечание] Имя хоста сервера (адрес привязки): ‘*’; порт: 3306
2017-11-15T10: 21: 11.574540Z 0 [Примечание] IPv6 доступен.
2017-11-15T10: 21: 11.574745Z 0 [Примечание] — «::» преобразуется в «::»;
2017-11-15T10: 21: 11.574891Z 0 [Примечание] Серверный сокет создан на IP: ‘::’.

2017-11-15T10: 21: 11.580607Z 0 [ОШИБКА] Неустранимая ошибка: таблица mysql.user повреждена. Пожалуйста, запустите mysql_upgrade.
2017-11-15T10: 21: 11.580879Z 0 [ОШИБКА] Отмена

Итак, взглянув на журнал ошибок, становится совершенно ясно, что запуск завершился с ошибкой «Неустранимая ошибка», которая, в свою очередь, привела к сбою всего процесса запуска для экземпляра с сообщением об ошибке «Таблица mysql.user повреждена» . В то же время он дает решение или исправление для запуска mysql_upgrade , но, поскольку экземпляр не запустился, было невозможно выполнить команду.

Вот что произошло, когда я попытался выполнить mysql_upgrade

bash-4.1 $ mysql_upgrade
mysql_upgrade: Получена ошибка: 2002: Не удается подключиться к локальному серверу MySQL через сокет ‘/var/lib/mysql/mysql.sock’ (2) при подключении к серверу MySQL. Обнаружен процесс обновления
ошибка и больше не будет.

******* РЕШЕНИЕ *********
Чтобы избежать этой тупиковой ситуации, я запустил сервер с опцией skip-grant-tables.
Это можно сделать, добавив строку «skip-grant-tables» в файл my.cnf (файл конфигурации) в разделе [mysqld].

bash-4.1 $ su —
Пароль:
[root @ dixitlab ~] #
[root @ dixitlab ~] # vi /etc/my.cnf

[mysqld]
#
# Удалить ведущий # и установить количество RAM для наиболее важных данных
# cache в MySQL. Начните с 70% от общего объема ОЗУ для выделенного сервера, иначе 10%.
# innodb_buffer_pool_size = 128M
#
# Удалите ведущие #, чтобы включить очень важную опцию целостности данных: запись
# изменений в двоичный журнал между резервными копиями.
# log_bin
#
# Удалите начальные символы #, чтобы установить параметры, которые в основном полезны для серверов отчетов.
# Настройки сервера по умолчанию быстрее для транзакций и быстрых SELECT.
# При необходимости отрегулируйте размеры, поэкспериментируйте, чтобы найти оптимальные значения.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
datadir = / var / lib / mysql
socket = / var / lib / mysql / mysql.sock
innodb_data_file9: auto12data_file1: auto12data_file -таблицы

А теперь попробуем запустить сервер mysql.

[root @ dixitlab ~] # service mysqld start
Запуск mysqld: [OK]
[root @ dixitlab ~] #

Бум! Это сработало. Теперь быстро попробуйте запустить шаг mysql_upgrade, чтобы исправить первоначальную проблему.

-bash-4.1 $ mysql_upgrade
Проверка необходимости обновления.
Проверка версии сервера.
Выполняются запросы для обновления сервера MySQL.
Проверка системной базы данных.
mysql.columns_priv ОК
mysql.db OK
mysql.engine_cost OK
mysql.event OK
mysql.func OK
mysql.general_log OK
mysql.gtid_executed OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help.help_topic OK
mysql.host OK
mysql.innodb_index_stats OK
mysql.innodb_table_stats OK
mysql.ndb_binlog_index OK
mysql.plugin OK
mysql.proc OK
mysql.procs9.server_cost OK
mysql.servers OK
mysql.slave_master_info OK
mysql.slave_relay_log_info OK
mysql.slave_worker_info OK
mysql.slow_log OK
mysql.slow_log OK
mysql.tables, mysql.slow_log
mysql.tablestime_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.user OK
Обновление схемы sys.
Проверка баз данных.
sys.sys_config OK
Процесс обновления успешно завершен.
Проверяем, требуется ли обновление.
-bash-4.1 $
-bash-4.1

$

Теперь, когда это будет сделано, давайте отменим изменения, которые мы внесли в файл конфигурации, и удалим запись skip-grant-table из my.cnf и перезапустите службу MYSQLD.

[root @ dixitlab ~] # vi /etc/my.cnf
[root @ dixitlab ~] #
[root @ dixitlab ~] #
[root @ dixitlab ~] # перезапуск службы sqld
sqld: неопознанная служба
[root @dixitlab ~] # перезапуск службы mysqld
Остановка mysqld: [OK]
Запуск mysqld: [OK]
[root @ dixitlab ~] #

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

баш-4.1 $
bash-4.1 $ mysql
Добро пожаловать в монитор MySQL. Команды заканчиваются на; или \ g.
Ваш идентификатор подключения MySQL: 5
Версия сервера: 5.7.20 Сервер сообщества MySQL (GPL)

Авторские права (c) 2000, 2017, Oracle и / или ее дочерние компании. Все права защищены.

Oracle является зарегистрированным товарным знаком Oracle Corporation и / или ее дочерних компаний
. Другие названия могут быть товарными знаками соответствующих владельцев
.

Введите «help;» или «\ h» для получения справки. Введите «\ c», чтобы очистить текущий оператор ввода.

MySQL>

Надеюсь, это поможет
Прашант Диксит

Нравится:

Нравится Загрузка …

Связанные

Эта запись была опубликована 15 ноября 2017 г. в 16:22 и находится в разделе «Дополнительно».
Метки: mysql. Вы можете следить за любыми ответами на эту запись через канал RSS 2.0.

Вы можете оставить отзыв или откликнуться со своего сайта.

Тайм-аут запроса в MySQL Workbench | Код ошибки: 2013.Потеряно соединение с сервером MySQL во время запроса

4 ноября 2017 г. | Размещено в SQL

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

Выпуск

Я пытался выполнить запрос к моей локальной установке SQL (независимо от того, что MAMP управляет и предоставляет), используя MySQL Workbench 6.3 для Mac, но продолжал получать ошибку тайм-аута.

Сам запрос не был слишком сложным, но я использовал агрегатные функции, группировку по и объединение для консолидации набора данных. Я работаю с отчетными данными по дистанционному обучению для всех колледжей и университетов США за 2012-2015 годы, поэтому в этом объединении участвовала таблица из 7K строк, а в другом — 25K строк, так что это не несущественно, но и не БОЛЬШОЙ уровень данных.

 ВЫБРАТЬ
STABBR как Государство,
EFDELEV как Уровень,
SUM (EFDETOT) как Total_Distance,
СУММ (EFDEEXC) как Exclusive_Distance,
СУММ (EFDESOM) как Some_Distance,
СУММ (EFDENON) как None_Distance

FROM hd2012 LEFT JOIN ef2012a_dist_rv
НА hd2012.UNITID = ef2012a_dist_rv.UNITID
ГРУППА ПО Состояние, Уровень; 

Сначала я поискал в Google код ошибки, но это довольно общий код ошибки, поэтому было сложно сказать, было ли это ограничением SQL или СУБД Workbench. Я прочитал несколько сообщений, в которых предлагалось изменить некоторые файлы .conf для базовой установки MySQL, и я слишком долго шел по этому пути, прежде чем попробовать что-то в самом Workbench.

Оказывается, есть настройки тайм-аута для СУБД, которые вы расширяете, чтобы убедиться, что она ждет достаточно времени для возврата данных вашим запросом.Благодаря этому конкретному ответу на StackOverflow, но описание «практических рекомендаций», на которое он ссылается, больше не действует, отсюда и это сообщение в блоге.

Исправление

В настройках мне помогли быстрые настройки. Как и следовало ожидать, СУБД имеет настройки для управления подключением к серверу SQL. В моем случае их было слишком мало для моих длительных запросов.

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

Другое исправление

По состоянию на 27.08.2018 я немного поработал с запросами, которые давали такой медленный результат, и понял, что некоторое простое индексирование сократило время запроса с ~ 50 секунд до 0,227 секунды. Вы можете найти более подробную информацию об этом здесь.

Если вы ищете способ остановить ошибку тайм-аута, теперь у вас есть два варианта. Однако теперь я понимаю, что большая часть моей проблемы не имела ничего общего с MySQL Workbench и все, что связано с тем, как я построил базовую базу данных 🙂 Однако варианты всегда хороши, так что удачи!

Общие ошибки при использовании MySQL

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

Сервер MySQL пропал. Ошибка

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

Наиболее частая причина исчезновения сервера MySQL Ошибка
в том, что время ожидания сервера истекло, и соединение было закрыто. По умолчанию
сервер закрывает соединение через 8 часов, если ничего не произошло. Вы
можно изменить ограничение по времени, установив переменную wait_timeout , когда
вы запускаете mysqld .

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

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

В этом случае обычно можно получить следующие коды ошибок
(какой вы получите, зависит от ОС):

Вы также получите эту ошибку, если кто-то убьет запущенный поток с помощью
kill # threadid # .

Вы можете проверить, что MySQL не умер, выполнив mysqladmin
версия и проверка времени безотказной работы. Если проблема в том, что mysqld
разбился вы должны сосредоточиться на поиске причины сбоя.В этом случае вам следует начать с проверки того, выдает ли запрос снова.
снова убьет MySQL. См. Раздел A.4.1.

Вы также можете получить эти ошибки, если отправите запрос на сервер,
неправильный или слишком большой. Если mysqld получает слишком большой пакет
или вышла из строя, предполагается, что с клиентом что-то пошло не так, и
закрывает соединение. Если вам нужны большие запросы (например, если вы
работая с большими столбцами BLOB ), вы можете увеличить лимит запроса на
запуск mysqld с опцией -O max_allowed_packet = #
(по умолчанию 1M).Дополнительная память выделяется по запросу, поэтому mysqld будет
используйте больше памяти только при выполнении большого запроса или когда mysqld должен
вернуть большую строку результата!

Если вы хотите отправить отчет об этой проблеме, убедитесь, что
вы включаете следующую информацию:

• Включите информацию, если MySQL умер или нет. (Вы можете найти это в
  файл hostname.err . См. Раздел A.4.1.

• Если конкретный запрос убивает mysqld и задействованные таблицы, где
  проверил с CHECK TABLE перед тем, как сделать запрос, можете ли вы сделать
  тестовый пример для этого? Раздел D.1.6.

• Каково значение переменной wait_timeout на сервере MySQL?
  переменных mysqladmin дает вам значение этого

• Вы пробовали запустить mysqld с —log и проверить,
  выданный запрос появляется в журнале?

Раздел 1.6.2.2.

Не удается подключиться к [локальному] серверу MySQL Ошибка

Клиент MySQL в Unix может подключиться к серверу mysqld двумя способами.
разными способами: сокеты Unix, которые подключаются через файл в файле
система (по умолчанию / tmp / mysqld.sock ) или TCP / IP, который соединяет
через номер порта. Сокеты Unix быстрее TCP / IP, но могут только
использоваться при подключении к серверу на том же компьютере. Сокеты Unix
используются, если вы не укажете имя хоста или если вы укажете специальный
имя хоста localhost .

В Windows, если сервер mysqld работает на 9x / Me, вы можете
подключаться только через TCP / IP. Если сервер работает на NT / 2000 / XP и
mysqld запускается с —enable-named-pipe , вы
также может подключаться к именованным каналам.Имя именованного канала — MySQL.
Если вы не укажете имя хоста при подключении к mysqld , MySQL
клиент сначала попытается подключиться к именованному каналу, и если этого не произойдет
работать он будет подключаться к порту TCP / IP. Вы можете принудительно использовать именованные
трубы в Windows с помощью . в качестве имени хоста.

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

Начните с проверки (с помощью ps или диспетчера задач в Windows), что
на вашем сервере запущен процесс с именем mysqld ! Если там
это не какой-либо процесс mysqld , вам следует запустить его. См. Раздел 2.4.2.

Если запущен процесс mysqld , вы можете проверить сервер с помощью
пробуя эти разные соединения (номер порта и путь к сокету
конечно, может быть иначе в вашей настройке):

 shell> mysqladmin version
оболочка> переменные mysqladmin
shell> mysqladmin -h `hostname` переменные версии
оболочка> mysqladmin -h `hostname` --port = 3306 version
shell> mysqladmin -h 'ip для версии вашего хоста'
оболочка> mysqladmin --socket = / tmp / mysql.sock version 

Обратите внимание на использование обратных кавычек, а не прямых кавычек с именем хоста
команда; это приводит к выводу имени хоста (то есть текущего
hostname) для замены в команду mysqladmin .

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

• mysqld не запущен.

• Вы работаете в системе, использующей MIT-pthreads.Если вы работаете в системе, в которой нет собственных потоков,
  mysqld использует пакет MIT-pthreads. См. Раздел 2.2.2. Однако,
  не все версии MIT-pthreads поддерживают сокеты Unix. В системе
  без поддержки сокетов вы всегда должны явно указывать имя хоста
  при подключении к серверу. Попробуйте использовать эту команду, чтобы проверить
  подключение к серверу:

   shell> mysqladmin -h `hostname` version 

• Кто-то удалил сокет Unix, который использует mysqld (по умолчанию
  / tmp / mysqld.носок ). У вас может быть задание cron , которое удаляет
  сокет MySQL (например, задание по удалению старых файлов
  из каталога / tmp ). Вы всегда можете запустить mysqladmin
  версия и убедитесь, что сокет mysqladmin пытается использовать
  действительно существует. Исправление в этом случае — изменить задание cron на
  не удаляйте mysqld.sock или размещайте сокет в другом месте. См. Раздел A.4.5.

• Вы запустили сервер mysqld с
  параметр —socket = / path / to / socket .Если поменять розетку
  путь к серверу, вы также должны уведомить клиентов MySQL
  о новом пути. Вы можете сделать это, указав путь к сокету
  как аргумент клиенту. См. Раздел A.4.5.

• Вы используете Linux, и один поток умер (дамп памяти). В этом случае
  вы должны убить остальные mysqld потоков (например, с помощью
  mysql_zap script), прежде чем вы сможете запустить новый MySQL
  сервер. См. Раздел A.4.1.

• Возможно, у вас нет прав на чтение и запись в каталог, содержащий
  файл сокета или сам файл сокета.В этом случае вы либо
  измените привилегию для каталога / файла или перезапустите
  mysqld , чтобы он использовал каталог, к которому вы можете получить доступ.

Если вы получаете сообщение об ошибке Не удается подключиться к серверу MySQL на
some_hostname , вы можете попробовать следующее, чтобы узнать, что
проблема:

• Проверьте, работает ли сервер, выполнив telnet your-host-name
  tcp-ip-port-number и пару раз нажмите Enter. Если там
  это сервер MySQL, работающий на этом порту, вы должны получить
  ответ, который включает номер версии запущенного MySQL
  сервер.Если вы получаете сообщение об ошибке типа telnet: невозможно подключиться к
  удаленный хост: соединение отклонено , сервер не запущен на
  данный порт.

• Попробуйте подключиться к демону mysqld на локальном компьютере и проверьте
  порт TCP / IP, который настроен для использования mysqld (переменная порт ) с
  переменные mysqladmin .

• Убедитесь, что ваш сервер mysqld не запущен с
  — опция пропуска сети .

Хост «…» заблокирован. Ошибка

. Если вы получаете такую ​​ошибку:

 Хост «имя хоста» заблокирован из-за множества ошибок соединения.
Разблокировка с помощью mysqladmin flush-hosts 

означает, что mysqld получил много ( max_connect_errors )
запросов на подключение от хоста ‘hostname’ , которые были прерваны
посередине. После max_connect_errors неудачных запросов, mysqld
предполагает, что что-то не так (например, атака взломщика), и
блокирует сайт от дальнейших подключений, пока кто-нибудь не выполнит команду
mysqladmin flush-hosts .

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

 shell> safe_mysqld -O max_connect_errors = 10000 & 

Обратите внимание, что если вы получаете это сообщение об ошибке для данного хоста, вы должны сначала
проверьте, что с подключениями TCP / IP все в порядке
хост. Если ваши TCP / IP-соединения не работают, это не поможет вам
увеличьте значение переменной max_connect_errors !

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

Если вы получаете сообщение об ошибке Слишком много подключений при попытке подключения
в MySQL это означает, что уже существует max_connections
клиенты, подключенные к серверу mysqld .

Если вам нужно больше подключений, чем установлено по умолчанию (100), вам следует перезапустить
mysqld с большим значением для переменной max_connections .

Обратите внимание, что mysqld действительно позволяет ( max_connections +1)
клиентов для подключения. Последнее соединение зарезервировано для пользователя с
процесс привилегия. Не давая эту привилегию нормальному
пользователи (им это не нужно), администратор с этим правом
можете войти в систему и использовать SHOW PROCESSLIST , чтобы узнать, что может быть
неправильно.См. Раздел 4.5.6.

Максимальное количество подключений к MySQL зависит от того, насколько хорошо
библиотека потоков находится на данной платформе. Linux или Solaris должны быть
способен поддерживать 500-1000 одновременных подключений, в зависимости от того, сколько
RAM у вас есть и чем занимаются ваши клиенты.

Невозможно выполнить откат некоторых нетранзакционных измененных таблиц Ошибка

Если вы получили сообщение об ошибке / предупреждение: Предупреждение: некоторые нетранзакционные
измененные таблицы не удалось откатить при попытке выполнить
ROLLBACK , это означает, что некоторые из таблиц, которые вы использовали в
транзакция не поддерживает транзакции.Эти нетранзакционные таблицы
не будет затронут оператором ROLLBACK .

Обычно это происходит, когда вы пытаетесь создать
таблица типа, который не поддерживается вашим двоичным файлом mysqld .
Если mysqld не поддерживает тип таблицы (или если тип таблицы
отключено параметром запуска), вместо этого будет создан тип таблицы
с типом таблицы, который больше всего соответствует запрошенной,
наверное MyISAM .

Вы можете проверить тип таблицы для таблицы, выполнив:

ПОКАЗАТЬ СОСТОЯНИЕ ТАБЛИЦЫ КАК ‘table_name’ .См. Раздел 4.5.6.2.

Вы можете проверить расширения, которые поддерживает ваш двоичный файл mysqld , выполнив:

показать такие переменные, как ‘have_%’ . См. Раздел 4.5.6.4.

Если вы выполните запрос и получите что-то вроде следующей ошибки:

 mysql: Недостаточно памяти в строке 42, 'malloc.c'
mysql: требуется 8136 байт (8 КБ), используемая память: 12481367 байт (12189 КБ)
ОШИБКА 2008: клиенту MySQL не хватает памяти 

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

Чтобы устранить проблему, сначала проверьте правильность вашего запроса. Это
разумно, что он должен возвращать столько строк? Если так,
вы можете использовать mysql —quick , который использует mysql_use_result ()
для получения набора результатов. Это снижает нагрузку на клиента (но
подробнее на сервере).

Когда клиент MySQL или сервер mysqld получает пакет большего размера
чем max_allowed_packet байт, он выдает Пакет слишком большой
ошибка и закрывает соединение.

В MySQL 3.23 самый большой возможный пакет — 16M (из-за ограничений в
клиент / серверный протокол). В MySQL 4.0.1 и выше это ограничено только
объем памяти на вашем сервере (до теоретического
максимум 2G).

Пакет связи — это один оператор SQL, отправляемый на сервер MySQL.
или одна строка, которая отправляется клиенту.

Когда клиент MySQL или сервер mysqld получает пакет большего размера
чем max_allowed_packet байт, он также выдает пакет
большая ошибка и закрывает соединение.С некоторыми клиентами вы также можете
получить Потеряно соединение с сервером MySQL во время запроса Ошибка , если
пакет связи слишком велик.

Обратите внимание, что и клиент, и сервер имеют свои собственные
max_allowed_packet переменная. Если вы хотите обрабатывать большие пакеты,
вы должны увеличить эту переменную как на клиенте, так и на сервере.

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

Если вы используете клиент mysql , вы можете указать больший
buffer, запустив клиента с mysql —set-variable = max_allowed_packet = 8M . У других клиентов есть другие методы для установки этой переменной.

Вы можете использовать файл опций, чтобы установить max_allowed_packet на большее
размер в mysqld . Например, если вы планируете хранить
во всю длину MEDIUMBLOB в таблицу, вам нужно будет начать
сервер с опцией set-variable = max_allowed_packet = 16M .

Также могут возникнуть странные проблемы с большими пакетами, если вы используете
большие капли, но вы не предоставили mysqld доступ к достаточному объему памяти
для обработки запроса. Если вы подозреваете, что это так, попробуйте добавить
ulimit -d 256000 до начала safe_mysqld скрипта
и перезапустите mysqld .

Ошибка связи / соединение прервано

Начиная с MySQL 3.23.40 вы получаете только Aborted
connection ошибка, если вы запускаете mysqld с —warnings .

Если вы обнаружите в журнале ошибок, например, следующие ошибки (см.
Раздел 4.9.1):

 010301 14:38:23 Прервано соединение 854 с db: 'users' user: 'josh' 

это означает, что произошло одно из следующих событий:

• Клиентская программа не вызывала mysql_close () перед выходом.

• Клиент спал более wait_timeout или
  interactive_timeout без выполнения каких-либо запросов. См. Раздел 4.5.6.4.

• Клиентская программа внезапно завершилась в середине передачи.

Когда это происходит, серверная переменная Aborted_clients становится
увеличился.

Переменная сервера Aborted_connects увеличивается на единицу:

• Когда пакет подключения не содержит нужной информации

• Когда у пользователя нет прав для подключения к базе данных

• Когда пользователь использует неправильный пароль

• Когда для получения требуется более connect_timeout секунд
  пакет подключения

Обратите внимание, что это может означать, что кто-то пытается проникнуть в
ваша база данных!

См. Раздел 4.5.6.4.

Другие причины проблем с прерванными клиентами / прерванными соединениями.

• Использование дуплексного протокола Ethernet, как половинного, так и полного с
  Linux. Эта ошибка есть во многих драйверах Ethernet для Linux. Вы должны проверить
  для этой ошибки путем передачи огромного файла по ftp между этими двумя
  машины. Если передача идет в режиме пакетной паузы-пакетной паузы …,
  у вас синдром дуплекса Linux. Единственное решение
  эта проблема заключается в переключении как полудуплексного, так и полнодуплексного режима на концентраторах
  и переключатели.

• Некоторая проблема с библиотекой потоков, которая вызывает прерывания при чтении.

• Плохо настроен TCP / IP.

• Неисправные сети Ethernet, концентраторы, коммутаторы, кабели … Это можно диагностировать
  правильно только заменой фурнитуры.

• max_allowed_packet слишком мал или запросы требуют больше памяти
  чем вы выделили для mysqld . См. Раздел A.2.8.

Эта ошибка возникает в более старых версиях MySQL, когда временный
таблица становится больше tmp_table_size байт.Чтобы избежать этого
проблема, вы можете использовать параметр -O tmp_table_size = # для
mysqld , чтобы увеличить размер временной таблицы или использовать SQL
параметр SQL_BIG_TABLES перед тем, как выдать проблемный
запрос. См. Раздел 5.5.6.

Вы также можете запустить mysqld с опцией —big-tables .
Это точно так же, как использование SQL_BIG_TABLES для всех запросов.

В MySQL версии 3.23 временные таблицы в памяти будут автоматически
преобразованы в дисковую таблицу MyISAM после того, как размер таблицы станет
больше tmp_table_size .

Невозможно создать / записать в файл Ошибка

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

 Невозможно создать / записать в файл '\\ sqla3fe_0.ism'. 

это означает, что MySQL не может создать временный файл для
набор результатов в данном временном каталоге. (Эта ошибка
типичное сообщение об ошибке в Windows, и сообщение об ошибке Unix похоже.)
Исправление — запустить mysqld с —tmpdir = path или добавить в свой вариант
файл:

 [mysqld]
tmpdir = C: / temp 

при условии, что каталог c: \\ temp существует.См. Раздел 4.1.2.

Проверьте также код ошибки, который вы получаете с perror . Одна причина
также может быть ошибка переполнения диска:

 shell> perror 28
Код ошибки 28: На устройстве не осталось места 

Команды не синхронизированы Ошибка в клиенте

Если вы получаете команд рассинхронизировано; вы не можете запустить эту команду сейчас
в вашем клиентском коде вы вызываете клиентские функции в неправильном порядке!

Это может произойти, например, если вы используете mysql_use_result () и
попробуйте выполнить новый запрос до того, как вы вызвали mysql_free_result () .Это также может произойти, если вы попытаетесь выполнить два запроса, которые возвращают данные без
mysql_use_result () или mysql_store_result () между ними.

Если вы получили следующую ошибку:

Обнаружен неверный пароль для пользователя: ‘some_user @ some_host’; игнорирование пользователя

означает, что при запуске mysqld или при перезагрузке
таблицы разрешений, он нашел запись в таблице пользователя с
неверный пароль. В результате запись просто игнорируется
система разрешений.

Возможные причины и способы устранения этой проблемы:

• Возможно, вы используете новую версию mysqld со старым
  пользователь таблица.
  Вы можете проверить это, выполнив mysqlshow mysql user , чтобы узнать,
  поле пароля короче 16 символов. Если да, вы можете исправить это
  условие, запустив сценарий scripts / add_long_password .

• У пользователя старый пароль (8 символов), и вы не запустили
  mysqld с опцией —old-protocol .Обновите пользователя в таблице user новым паролем или
  перезапустите mysqld с —old-protocol .

• Вы указали пароль в таблице пользователь , не используя
  ПАРОЛЬ () функция. Используйте mysql для обновления пользователя в
  пользователь таблица с новым паролем. Обязательно используйте ПАРОЛЬ ()
  функция:

   mysql> ОБНОВЛЕНИЕ пользователя SET пароль = ПАРОЛЬ ('ваш пароль')
      -> ГДЕ пользователь = 'XXX'; 

Таблица «xxx» не существует Ошибка

Если вы получаете сообщение об ошибке Таблица «xxx» не существует или Не удается
find file: ‘xxx’ (errno: 2) , это означает, что таблица не существует
в текущей базе данных с именем xxx .

Обратите внимание, что поскольку MySQL использует каталоги и файлы для хранения баз данных и
таблицы, базы данных и имена таблиц — с учетом регистра !
(В Windows имена баз данных и таблиц не чувствительны к регистру, но все
ссылки на данную таблицу в запросе должны использовать тот же регистр!)

Вы можете проверить, какие таблицы у вас есть в текущей базе данных, с помощью
ПОКАЗАТЬ ТАБЛИЦЫ . См. Раздел 4.5.6.

Не удается инициализировать набор символов xxx Ошибка

Если вы получаете сообщение об ошибке, например:

 MySQL Connection Failed: Can't initialize character set xxx 

, это означает одно из следующих событий:

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

  В этом случае вам нужно перекомпилировать клиент с
  —with-charset = xxx или —with-extra-charsets = xxx . См. Раздел 2.3.3.

  Все стандартные двоичные файлы MySQL скомпилированы с
  —with-extra-character-sets = complex , что включает поддержку
  все многобайтовые наборы символов. См. Раздел 4.6.1.

• Набор символов — это простой набор символов, который не компилируется в
  mysqld и файлы определения набора символов не на месте
  где клиент рассчитывает их найти.

  В этом случае вам необходимо:

  • Перекомпилировать клиент с поддержкой набора символов. См. Раздел 2.3.3.

  • Укажите клиенту, где находятся файлы определения набора символов. Для многих
    клиентов, вы можете сделать это с помощью
    —character-sets-dir = path-to-charset-dir option.

  • Скопируйте файлы определения символов в путь, по которому их ожидает клиент
    быть.

Если вы получите ERROR ‘… ‘не найден (errno: 23) , Не удается открыть
file: … (errno: 24) , или любая другая ошибка с errno 23 или
errno 24 из MySQL, это означает, что вы не распределили
достаточно файловых дескрипторов для MySQL. Вы можете использовать
perror утилита для получения описания номера ошибки
означает:

 оболочка> perror 23
Переполнение таблицы файлов
оболочка> перрор 24
Слишком много открытых файлов
оболочка> perror 11
Ресурс временно недоступен 

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

Чтобы указать mysqld , что нужно открывать меньше файлов за раз, вы можете сделать
уменьшите размер кэша таблицы, используя параметр -O table_cache = 32 для
safe_mysqld (значение по умолчанию 64). Снижение стоимости
max_connections также уменьшит количество открытых файлов (
значение по умолчанию — 90).

Чтобы изменить количество файловых дескрипторов, доступных для mysqld , вы
можно использовать параметр —open-files-limit = # от до safe_mysqld или
-O open-files-limit = # от до mysqld .См. Раздел 4.5.6.4.
Самый простой способ сделать это — добавить параметр в файл параметров. См. Раздел 4.1.2. Если у вас старая версия mysqld ,
не поддерживает это, вы можете отредактировать сценарий safe_mysqld . Там
это закомментированная строка ulimit -n 256 в скрипте. Вы можете
удалите символ ‘#’ , чтобы раскомментировать эту строку, и измените
число 256, чтобы повлиять на количество файловых дескрипторов, доступных для
mysqld .

ulimit (и open-files-limit ) может увеличить количество
файловых дескрипторов, но только до предела, налагаемого операционным
система.