Объявление обработчика
Чтобы объявить обработчик мы используем оператор DECLARE HANDLER:
DECLARE action HANDLER FOR condition_value statement;
Если значение условия совпадает со значением condition_value, MySQL выполнит оператор statement и продолжит или завершит текущий блок кода, исходя из значения action.
action может принимать следующие значения:
- CONTINUE: исполнение блокированного кода (BEGIN … END) продолжается;
- EXIT: выполнение блокированного кода, в котором был объявлен обработчик, завершается.
condition_value задает конкретное условие или класс условия, которые активируют обработчик.
condition_value может принимать одно из следующих значений:
- код ошибки MySQL;
- стандартное значение SQLSTATE. Или это может быть условие SQLWARNING, NOTFOUND или SQLEXCEPTION, которое является сокращением для класса значений SQLSTATE. Условие NOTFOUND используется для курсора или оператора SELECT INTO variable_list;
- название условия, связанного либо с кодом ошибки MySQL, либо со значением SQLSTATE.
В качестве statement может использоваться простой оператор или составной оператор, вшитый с помощью ключевых слов BEGIN и END.
Служба mysqld не может запуститься так как порт 3306 используется другой программой
По умолчанию служба mysqld использует порт 3306 если этот порт использует другой процесс, то это является препятствием для запуска MySQL и в конечном счёте появляется рассматриваемая ошибка.
Для решения проблемы выясните, какая служба прослушивает порт 3306. Например, это можно сделать командой:
sudo lsof -Pn -iTCP:3306
А затем остановите эту служу и удалите её из автозагрузки.
Либо можно использовать альтернативный вариант — настроить службу mysqld прослушивать другой, отличный от дефолтного порта. Но это может повлечь необходимость явно указывать порт в любых приложениях, которые подключаются к СУБД MySQL.
Что делать с error establishing a database connection
Теперь попробуем разобрать каждый из вариантов и попытаться понять что делать с error establishing a database connection, а также для предотвращения ее появления в будущем.
1. Базы данных нет
Если базы данных больше не существует, вы ее случайно стерли или ее стер хостер, то у вас есть два пути — либо , либо восстановить базу данных mysql из резервной копии. Все настройки базы данных находятся в файле wp-config.php, который находится в корневом каталоге сайта. Скорее всего, на хостинге у вас не будет доступа по SSH и придется довольствоваться FTP.
Вы можете посмотреть как называется база данных в нем:
Затем убедитесь, с помощью Phpmyadmin, что она есть и в ней есть данные:
2. Неверные настройки
Как я уже сказал, все настройки работы с базой данных находятся в файле wp-config.php. Вы можете посмотреть его содержимое через FTP или подключившись к серверу по SSH. Нужные нам параметры находятся в таких переменных:
- DB_NAME — имя базы данных;
- DB_USER — пользователь базы;
- DB_PASSWORD — пароль базы;
- DB_HOST — хост базы;
Проверить правильность ввода логина и пароля вы можете попытавшись войти с помощью них в Phpmyadmin:
Или используя консольную утилиту mysql если можете подключиться по ssh:
Если проблема в данных аутентификации, то утилита выдаст ошибку и вы точно будете знать что неверно. Дальше останется найти правильные данные и указать их в файле wp-config.php. Если же данные верные, идем дальше.
3. Ограничения сервера
Если все выше перечисленное не помогло, а ошибка появляется то пропадает сама по себе, то, скорее всего, это признак того, что хостер установил ограничение на количество одновременных подключений к базе данных. Вы можете написать в техподдержку и лимит могут чуть увеличить. Но это не решение. Ваш сайт и дальше будет расти, вы же не думаете останавливаться на достигнутом? Тогда вам нужно переходить на новый хостинг, без таких ограничений, или сразу на VPS. Техподдержка может еще посоветовать вам оптимизировать скрипты, но вы же не будете переписывать WordPress?
Если сейчас нет возможности переходить на новый хостинг, можно настроить плагин кэширования WordPress, например, W3TC, это немного улучшит ситуацию, но не сильно и ненадолго.
4. Сервис mysql не запущен
Эта проблема уже касается только VPS, поскольку на хостингах у вас нет доступа к таким службам и вы не сможете ничего сделать. На VPS вы можете делать все что угодно с любой службой. Чаще всего в качестве сервера баз данных используется MariaDB. Чтобы проверить запущена ли она в CentOS наберите:
В Ubuntu имя сервиса будет немного отличаться:
Если вы увидите надпись Iactive (dead) значит сервис не запущен. Почему? Это уже другой вопрос. Чтобы восстановить работоспособность сайта попробуйте запустить его:
Чаще всего сервер баз данных падает из-за нехватки памяти для работы движка innodb. Чтобы предотвратить такие падения в будущем можно сделать две вещи:
- Удалить или остановить программы, потребляющие очень много памяти или увеличить количество памяти на сервере;
- Настроить автоматический перезапуск MariaDB в случае, если она упала с помощью systemd. В этом случае вы даже не будете замечать, что были какие-либо проблемы и ошибка error establishing a database connection возникать не будет, но это только пока с памятью все не совсем уж плохо.
Чтобы заставить systemd следить за состоянием сервиса и перезапускать его по мере необходимости создайте файл /etc/systemd/system/mariadb.service.d/restart.conf и добавьте в него такое содержимое:
Затем обновите конфигурацию сервисов:
Мы не вносили изменения в основной файл юнита потому, что он может быть перезаписан при обновлении, и все наши настройки пропадут, такой путь более безопасный. Проверить применилась ли конфигурация вы можете командой:
Понимание проблемы
WordPress использует две основные технологии: PHP и MySQL.
- PHP – это язык программирования. Файлы ядра WordPress написаны на нем.
- MySQL – это система управления базами данных (СУБД). WordPress использует базу данных MySQL для хранения содержимого сайта: записи, страницы, а заголовок сайта, макет виджетов и т. д.
Рассматриваемая в этой статье ошибка возникает, когда WordPress не может получить доступ к информации в базе данных с помощью команд PHP. Когда это происходит, WordPress выводит сообщение «Ошибка при установлении соединения с базой данных».
Несколько причин, из-за которых возникает эта ошибка:
- Неверные учетные данные для входа. Если пароль и изменились, WordPress не сможет получать информацию из базы данных.
- Поврежденные файлы WordPress. Это может возникать при обновлении плагинов, темы оформления и самого WordPress.
- Поврежденная база данных. Например, если вредоносный плагин повредил базу данных изнутри. А также вследствие хакерской атаки, сбоем в теме и т.д.
- Сервер базы данных не работает.
- Большой объем трафика. Из-за этого база данных не может отвечать на запросы. Например, если один из ваших постов стал «вирусным», и одновременно множество пользователей пытаются зайти на ваш сайт.
phpmyadmin
При открытии в браузере phpmyadmin получаете сообщение:
ErrorMySQL said: #1045 — Access denied for user ‘root’@’localhost’ (using password: NO)
Connection for controluser as defined in your configuration failed.
phpMyAdmin tried to connect to the MySQL server, and the server rejected the connection. You should check the host, username and password in your configuration and make sure that they correspond to the information given by the administrator of the MySQL server.
Ни логина, ни пароля вы не вводили, да и пхпадмин их нигде требовал, сразу выдавая сообщение об ошибке. Причина в том, что данные для авторизации берутся из конфигурационного файла config.inc.php Необходимо заменить в нем строчки
$cfg’Servers’$i’user’ = ‘root’; // MySQL user$cfg’Servers’$i’password’ = »; // MySQL password (only needed
$cfg’Servers’$i’user’ = ‘ЛОГИН’; $cfg’Servers’$i’password’ = ‘ПАРОЛЬ’
Сводная таблица
По вертикали расположены коды ошибок MySQL, которые возникают при работе с внешними ключами («нет ошибок» соответствует ситуации, когда сервер не генерирует ошибку, но и не создает внешний ключ). По горизонтали — идентификаторы причин, которые могут привести к ошибке. Плюсы на пересечении указывают какие причины приводят к той или иной ошибке.
А1 | А2 | А3 | А4 | А5 | А6 | А7 | Б1 | В1 | В2 | Г1 | Г2 | Г3 | Г4 | Г5 | |
MySQL error 1005 | + | + | + | + | + | + | + | + | |||||||
MySQL error 1022 | + | ||||||||||||||
MySQL error 1025 | + | + | + | ||||||||||||
MySQL error 1215 | + | + | + | + | + | ||||||||||
MySQL error 1217 | + | + | |||||||||||||
MySQL error 1239 | + | ||||||||||||||
MySQL error 1451 | + | + | |||||||||||||
MySQL error 1452 | + | + | |||||||||||||
нет ошибок | + | + |
P.S. Если ваш случай не рассмотрен в статье, то задавайте вопрос на форуме SQLinfo. Вам ответят, а статья будет расширена.
Все права на данную статью принадлежат порталу SQLInfo.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в бумажных изданиях допускается только с разрешения редакции.
Как изменить политику проверки пароля MySQL
Чтобы устранить ошибку MySQL ERROR 1819 (HY000), установите более низкую политику проверки пароля, как показано далее. Для этого выполните вход в mysql и запустите одну из следующих команд:
mysql> SET GLOBAL validate_password_policy=LOW; mysql> SET GLOBAL validate_password_policy=0;
После этого вы можете подтвердить уровень политики проверки пароля.
SHOW VARIABLES LIKE 'validate_password%';
Теперь вы можете продолжить и назначить относительно слабый пароль по своему желанию.
create user 'mial'@'localhost' IDENTIFIED BY 'mypassword';
Чтобы вернуться к уровню политики паролей «СРЕДНИЙ», просто вызовите команду:
SET GLOBAL validate_password_policy=MEDIUM;
Неверно указан хост для подключения
Для указания удалённого хоста используется опция -h. Из-за привычки указывать хост после имени пользователя через знак @ (как это делается, например, для SSH), либо указывать удалённый хост без опции -h, команда может оказаться неверной в том плане, что вместо подключения к удалённому хосту, вы пытаетесь подключиться, например, к своей собственной системе, на которой служба MySQL не установлена.
Следовательно, отредактируйте команду, используйте опцию -h или более длинный вариант —host=имя_хоста для указания хоста, к которому вы хотите подключиться.
Кстати, для указания имени пользователя используется опция -u. Если пароль отличается от стандартного, то используется опция -P (заглавная буква). Опция -p (прописная буква) используется для указания базы данных, которая выбирается для использования.
Пример команды:
mysql -h 127.0.0.1 -P 3306 -u root -p <database>
Служба mysqld по умолчанию не добавляется в автозагрузку на некоторых дистрибутивах
Помните, что на некоторых дистрибутивах (например, производных Arch Linux, на Kali Linux) даже после установки MySQL или MariaDB они не добавляются в автозагрузку и не запускаются по умолчанию.
Для запуска службы и её авто старта при последующих включениях компьютера выполните команды:
sudo systemctl start mysqld.service sudo systemctl enable mysqld.service
Методы устранения «MySQL error: Too many connections»
Основным методом устранения ошибки «MySQL error: Too many connections», конечно же, является оптимизация скриптов сайта, так как именно эта причина вызывает чаще всего данную ошибку. Также для каждой БД
мы рекомендуем создавать отдельного пользователя, это позволит изолировать сайты друг от друга.
Если же речь идет об атаке на сайт, то есть два варианта решения проблемы: временное отключение сайта, либо использование услуги защиты от DDOS-атак.
Следующий пункт — общая нагрузка на сервер БД. Если используется услуга ВЕБ хостинга, то решить эту проблему самостоятельно Вы не сможете. В этом случае нужно обратиться в техническую
поддержку хостинг-провайдера.
Говоря о хостинге VDS или выделенном сервере, здесь, прежде всего, нужно проверить, что установленный лимит max_user_connections значительно меньше значения max_connections
Также нужно
обратить внимание на общую нагрузку на VDS (сервер), если VDS (сервер) не справляется с нагрузкой, то количество одновременных подключений будет расти, что в итоге приведет к превышению лимитов. Стоит обратить внимание и на настройку сервисов VDS (сервера), если какой-то сервис можно оптимизировать, выделив больше ресурсов для MySQL, то это следует незамедлительно выполнить
Если
наличие свободных ресурсов позволяет увеличить значение max_user_connections и max_connections, то это также нужно сделать.
В случае отсутствия навыков решения проблемы «MySQL error: Too many connections» Вы всегда можете обратиться в нашу компанию и заказать администрирование сайта или сервера, что поможет
исправить данную проблему в минимальные сроки.
Что значит ошибка «MySQL error: Too many connections»
Итак, если при входе на сайт Вы видите надпись «MySQL error: Too many connections», то в большинстве случаев это говорит о том, что сайт превысил лимит на количество одновременных соединений к серверу баз данных MySQL. В остальных случаях это может говорить о превышении второго лимита, т.е. лимита на общее количество одновременных подключений к MySQL.
Для справки. Первый лимит регулируется параметром max_user_connections, а второй лимит — max_connections.
Если речь идет о ВЕБ хостинге с mysql, то возникновение ошибки по причине превышения лимита max_connections практически не возможно, поэтому такая ошибка будет возникать только на одном сайте,
даже если у Вас несколько сайтов на одном аккаунте, за исключением ситуаций, когда для всех баз данных указан один пользователь.
Если мы говорим о VDS хостинге или выделенном сервере, то здесь все зависит от настроек сервера MySQL. В том случае, если у Вас max_user_connections не значительно меньше max_connections, равно
или превышает этот параметр, то сбой в работе БД одного сайта повлияет на работу остальных сайтов.
Убедитесь, что служба MySQL/MariaDB настроена правильно
Если причина проблемы оказалась в том, что служба не запущена и после попытки запуска служба вновь оказалась неактивной, значит проблема может быть в неправильной настройке сервера MySQL/MariaDB.
Файлы конфигурации (настроек) MySQL и MariaDB могут размещаться в разных директориях, например:
- /etc/my.cnf
- /etc/mysql/my.cnf
- /var/lib/mysql/my.cnf
При этом в файлах могут быть установлены различные значения одной и той же настройки, что приводит к проблеме. Устраните противоречие, либо удалите или переименуйте один из файлов и попробуйте вновь запустить службу.
На что стоит обратить внимание в конфигурационных файлах
Если вы хотите сохранить оба конфигурационных файла, то проверьте, чтобы значение socket было одинаковым. Также для bind-address должен быть установлен правильный IP адрес. Если к этому серверу подключаются только приложения, которые запущены на этом же сервере, то в качестве значения bind-address нужно прописать localhost или 127.0.0.1
Backup файлов и базы данных
Любой хороший хостер заботится о резервных копиях сайтов клиентов. Хорошо если ошибка технического характера обнаружилась сразу, а не через несколько дней. То есть мы можем восстановить состояние ресурса на тот момент, когда он работал.
Единственный минус, что все изменения внесенные после даты восстановления сотрутся и придется проделывать действия заново. Заходим в BackUp в панели хостинга.
Раздел бэкапа
Сначала переходим в файловый архив, отмечаем папку сайта и выбираем дату когда он работал нормально и нажимаем синюю стрелочку.
восстановление файлов WP
Переходим в раздел Базы данных, отмечаем соответствующую сайту, так же выбираем дату и жмем синюю стрелочку.
Бекап БД
По окончании процессов, сайт должен заработать, если нет, то переходим к следующему крайнему методу.
Повреждены таблицы БД (Table is marked as crashed)
При возникновении ошибок вида «Warning: Table … is marked as crashed» необходимо выполнить восстановление таблиц.
Если на сервере установлен phpMyAdmin, можно выполнить восстановление с его помощью. Для этого перейдите в интерфейс PMA и кликните на нужную базу данных в меню слева. Отметьте в списке те таблицы, которые нужно восстановить (то есть таблицы, имена которых фигурируют в ошибках). В самом низу страницы нажмите на выпадающее меню «С отмеченными» и выберите вариант «Восстановить».
Для восстановления одной таблицы выполните команду:
mysqlcheck -r имя_базы имя_таблицы -uroot -p
Для восстановления всех таблиц в базе используйте:
mysqlcheck -r имя_базы -uroot -p
Вы также можете выполнить проверку всех таблиц в базе с помощью команды:
mysqlcheck -r -A -uroot -p
Почему не запускается MySQL сервер?
Если вы используете systemd для запуска сервисов, то получите такую ошибку:
failed to start mysql server или job for mysql failed because the control proccess exited
Из сообщения понято только то что что-то пошло не так, но что именно неизвестно. Чаще всего проблемы в работе MySQL могут вызвать такие причины:
- Синтаксические ошибки в конфигурационном файле;
- Неверные настройки;
- Недостаточное количество оперативной памяти на сервере;
- Проблемы с правами доступа;
- Сетевой порт уже занят;
- Таблицы баз данных повреждены;
Дальше мы рассмотрим основные пути решения этих проблем. Но сначала нам нужно выяснить почему не запускается программа. Гадать на кофейной гуще и перебирать все возможные методы решения можно очень долго, самым эффективным решением будет посмотреть какие ошибки выдает сама программа.
Errno 121
Такой результат возникает только в одном случае.
Б1. Неуникальное имя ограничения
Обратите внимание: речь не о имени внешнего ключа. Если при создании внешнего ключа вы указываете не обязательное ключевое слово CONSTRAINT, то идущий после него идентификатор должен быть уникальным в пределах базы данных
Примеры
create table t1 (a int, index(a)) engine=innodb;create table t2 (a int, CONSTRAINT q1 foreign key (a) references t1(a)) engine=innodb;create table t3 (a int, CONSTRAINT q1 foreign key (a) references t1(a)) engine=innodb;
ERROR 1005 (HY000): Cannot create table ‘test.t3’ (errno: 121)— в 5.7 будет другая ошибка
ERROR 1022 (23000): Cannot write; duplicate key in table ‘t3’show engine innodb status;————————
LATEST FOREIGN KEY ERROR————————161130 3:31:11 Error in foreign key constraint creation for table `test`.`t3`.
A foreign key constraint of name `test`.`q1`
already exists. (Note that internally InnoDB adds ‘databasename’in front of the user-defined constraint name.)
Note that InnoDB FOREIGN KEY system tables storeconstraint names as case-insensitive, with the
MySQL standard latin1_swedish_ci collation. If youcreate tables or databases whose names differ only in
the character case, then collisions in constraint
names can occur. Workaround: name your constraints
explicitly with unique names.———
Как получить больше данных об ошибке
После получения ошибки выполните SHOW ENGINE INNODB STATUS и смотрите содержимое секции LATEST FOREIGN KEY ERROR. Этот способ имеет следующие недостатки:
- требует привилегии SUPER
- содержит информацию о последней ошибке, связанной с внешними ключами, из-за чего нужно выполнять SHOW ENGINE INNODB STATUS сразу после возникновения ошибки, что не всегда удобно/возможно
- используются внутренние имена таблиц (например, ‘test.#sql-d88_b’), что затрудняет диагностику
- порой содержит мало полезной информации или таковая вообще отсутствует.
Альтернатива: использовать MariaDB версий больше 5.5.45 и 10.0.21, в которых сообщения об ошибках значительно улучшены и указывают причину возникновения ошибки.
Каков источник ошибки: Windows не может запустить SQL Server Ошибка 3417?
Эта проблема может возникнуть, когда есть —
- Изменения настроек Windows, намеренные или непреднамеренные (смещение папки SQL Server).
- Сжатие папки, содержащей файлы базы данных SQL.
- Сетевая учетная запись для папки данных несовместима.
- Повреждение файла базы данных SQL, например, из-за аппаратного сбоя, вторжения вирусов или внезапного отключения питания.
Эти причины ошибки не следует упускать из виду.
Подходы вручную: Windows не может запустить SQL Server, ошибка 3417
Иногда некоторые ошибки SQL-сервера говорят сами за себя, что означает, что если пользователь пытается правильно понять сообщение, то можно исправить ошибку вручную.В результате, чтобы решить эту проблему, пользователь должен либо восстановить резервную копию базы данных, либо восстановить базу данных, если она была повреждена. Перед этим вы также можете проверить, сжимается ли файл MDF или нет, чтобы исправить сообщение об ошибке SQL Server 3417. Давайте начнем с рассмотрения каждого метода устранения неполадок.
1. Необходимо распаковать файл MDF базы данных SQL
Проверьте, не сжимается ли основной файл базы данных (.mdf), если вы не можете его открыть. Если файл сжат, вам придется распаковать его. Для этого сделайте следующие шаги:
Перейти к Данные Microsoft SQL Server и найдите файлы db (MDF и NDF).
- Щелкните правой кнопкой мыши Папка данных SQL Server и выберите Характеристики. Откроется окно «Свойства» для Microsoft SQL Server. Затем выберите Advanced.
- Снимите флажок Компресс содержимое для экономии места на диске в Расширенные атрибуты появится диалоговое окно, затем щелкните Ok.
- В Характеристики диалоговое окно для Microsoft SQL Server появляется еще раз. Затем нажмите Ok после нажатия кнопки Применить. Нажмите Ok когда Подтвердить изменения атрибутов появится окно.
- Для продолжения нажмите Продолжать.
- Дайте время для корректировка атрибутов вступить в силу. Нажмите Ok после внесения изменений.
После выполнения этих процедур перезапустите службу SQL Server. Если проблема не исчезнет, используйте следующую ручную технику.
2. Проверьте разрешения папки.
Это исправление ошибки SQL 3417 предназначено для клиентов, у которых возникает ошибка при переносе папки на другой диск.
Убедитесь, что учетная запись, которая запускает службу SQL Server, имеет права доступа (сетевые разрешения) к папке файлов базы данных SQL. Если у вас нет доступа к папке, используйте эти процедуры, чтобы получить ее:
- Щелкните правой кнопкой мыши Файлы SQL папку и выберите Характеристики из меню.
- Выберите Вкладка Безопасность в поле «Свойства».
- Во всплывающем диалоговом окне под Группа или имена пользователей: в области выберите Сетевая служба учетная запись.
- Щелкните значок Кнопка ОК после выбора Флажок Полный доступ в разделе «Разрешения для аутентифицированных пользователей».
Убедитесь, что сейчас экземпляр SQL Server запускается без ошибок.
3. Используя файл резервной копии, восстановите базу данных.
Если проблема 3417 сохраняется в SQL Server 2017 или более ранних версиях, рассмотрите возможность восстановления базы данных из файла резервной копии. Убедитесь, что в резервной копии есть самая последняя копия базы данных SQL. В этом блоге вы узнаете, как восстановить базу данных из SQL Server. bak файл — Как сделать резервную копию и восстановить базы данных SQL Server различными подходами.
Профессиональный инструмент восстановления
Если код ошибки SQL 3417 не исправлен с помощью описанных выше процедур, вам необходимо восстановить базу данных. Программное обеспечение для восстановления DataHelp SQL лучше всего подходит для этого. Он может исправить как небольшие, так и серьезные повреждения MDF (первичный файл базы данных) и NDF (файл национальной базы данных) (вторичный файл базы данных). Эта проблема не возникнет в MS SQL Server после восстановления базы данных. Этот инструмент полезен для устранения неполадок SQL Server 3417 в различных версиях SQL Server, таких как SQL Server 2019, 2017, 2016, 2014, 2012, 2008/2008 R2, 2005 и 2000.
Заключение
При попытке запустить службу SQL Server вы можете получить ошибку SQL Server 3417. Если не удается вывести главную базу данных или базу данных tempdb в оперативный режим, папка, содержащая файлы базы данных (.mdf или .ndf), сжимается, или вы этого не делаете. есть права доступа к папке, возникает ошибка. Вы можете попытаться решить проблему, используя ручные обходные пути, описанные в этой статье. С другой стороны, ручное устранение проблемы SQL 3417 может занять много времени и привести к недоступности базы данных. Лучший способ — восстановить файл MDF и решить проблему с помощью специального решения для восстановления базы данных SQL, такого как DataHelp SQL Recovery Software.
Ошибка 2006: MySQL server has gone away
Ошибка MySQL server has gone away означает, что сервер закрыл соединение, что происходит, как правило, в двух случаях: превышение таймаута ожидания или получение сервером слишком большого пакета.
Конфигурационный файл может располагаться по различным путям, например:
/etc/my.cnf /etc/mysql/my.cnf /etc/mysql/mysql.conf.d/mysqld.cnf
Чтобы определить, в какой файл необходимо вносить изменения, можно использовать команду вида:
grep -Rl 'имя_параметра' /etc/* # Например: grep -Rl 'wait_timeout' /etc/* # или: grep -Rl 'max_allowed_packet' /etc/*
С ее помощью можно выяснить, в каких файлах прописан интересующий нас параметр, и изменить в них его значение.
Таймаут
Чтобы увеличить таймаут ожидания, необходимо скорректировать значение параметра .
Откройте конфигурационный файл с помощью редактора (укажите корректный путь к файлу):
nano /etc/mysql/my.cnf
Измените значение параметра wait_timeout на более высокое. Значение указывается в секундах, т.е. чтобы увеличить время ожидания, например, до 10 минут, необходимо указать 600:
wait_timeout = 600
После перезапустите службу MySQL:
# Debian / Ubuntu service mysql restart # CentOS service mysqld restart
Размер пакетов
В этом случае можно скорректировать максимально допустимый размер пакетов, увеличив параметр .
Откройте файл конфигурации (укажите корректный путь к файлу):
nano /etc/mysql/my.cnf
Измените значение параметра max_allowed_packet на более высокое (значение указывается в мегабайтах):
max_allowed_packet = 64M
И перезапустите службу:
# Debian / Ubuntu service mysql restart # CentOS service mysqld restart
Ошибка 1292: Incorrect date value
При попытке добавить данные в таблицу MySQL без указания даты может выдаваться ошибка:
ERROR 1292 (22007): Incorrect date value: '0000-00-00' for column 'columnname' at row 1
Из-за этой ошибки может нарушаться работа импорта в 1С.
Для решения проблемы необходимо:
1. Открыть файл
nano /etc/mysql/my.cnf
2. В строке, начинающейся с удалить следующие значения:
NO_ZERO_IN_DATE NO_ZERO_DATE STRICT_ALL_TABLES
3. Выполнить перезагрузку mysql-сервера:
sudo service mysql restart
Примечание:
Если строка вида отсутствует, необходимо:
1. В файл после параметра добавить строку:
sql-mode="ONLY_FULL_GROUP_BY,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
2. Выполнить перезагрузку mysql-сервера:
sudo service mysql restart
Нет ошибок
Внешний ключ не создается, и нет никаких ошибок. Это может происходить по следующим причинам:
В1. Дочерняя таблица не является InnoDB таблицей. В этом случае для совместимости с другими субд парсер MySQL просто проигнорирует конструкцию внешнего ключа.
Примеры
create table t1 (a int, index(a)) engine=innodb;create table t2 (a int, foreign key (a) references t1(a)) engine=myisam;
Query OK, rows affected (0.33 sec)
MariaDB test> show create table t2\G
*************************** 1. row ***************************
Table: t2Create Table: CREATE TABLE `t2` (
`a` int(11) DEFAULT NULL,
KEY `a` (`a`)) ENGINE=MyISAM DEFAULT CHARSET=latin11 row in set (0.00 sec)
В2. Не соответствует синтаксису MySQL. Стандарт SQL разрешает указывать внешний ключ сразу при объявлении колонки с помощью конструкции REFERENCES (например, … a int references t1(a), …), однако MySQL игнорирует такую форму записи. Единственный способ создать в нем внешний ключ — это использовать отдельный блок FOREIGN KEY:
CONSTRAINT symbol FOREIGN KEY
index_name (index_col_name, …)
REFERENCES tbl_name (index_col_name,…)
ON DELETE reference_option
ON UPDATE reference_option
reference_option:
RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT
Перенос базы на другой сервер.
У вас есть дамп (т.е. файл с расширением .sql) и при попытке его импортировать вы получаете ошибку 1064. Причины:
-
В различных версиях набор ключевых слов и синтаксис может немного отличаться. Наиболее распространенный случай: команда create table, в которой ключевое слово type было заменено на engine. Например, если вы получаете ошибку:
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 ‘TYPE=MyISAM CHARACTER SET `utf8`’ at line 29
Это означает, что вы переносите базу в пятую версию сервера MySQL, в котором ключевое слово TYPE не поддерживается и его нужно заменить на ENGINE.
Редко бываю случаи, когда перенос идет на старый (~3.23) сервер, который кодировки не поддерживает. Тогда ошибка будет иметь вид:
#1064 — You have an error in your SQL syntax near ‘DEFAULT CHARACTER SET cp1251 COLLATE cp1251_general_ci’ at line 1
Такое может произойти, если вы переносите базу с хостинга на локальный комп, где стоит древняя версия MySQL. Лучшим решением в данном случае будет не править дамп, а обновить MySQL.
-
Часто проблемы вызваны тем, что дамп делается неродными средствами MySQL (например, phpmyadmin) из-за чего в нем могут быть BOM-маркер, собственный синтаксис комментариев, завершения команды и т.д. Кроме того при использовании того же phpmyadmin возможна ситуация при которой из-за ограничения апача на размер передаваемого файла команда будет обрезана, что приведет к ошибке 1064.
Например, если вы получаете ошибку:#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 ‘CREATE TABLE `jos_banner` (
`bid` int(11) NOT NULL auto_increment,
`ci’ at line 1Значит ваш дамп содержит BOM-маркер. Это три байта в начале файла, помогающие программе определить что данный файл сохранен в кодировке UTF-8. Проблема в том, что MySQL пытается интерпретировать их как команду из-за чего возникает ошибка синтаксиса. Нужно открыть дамп в текстовом редакторе (например, Notepad++) и сохранить без BOM.
Для избежания подобных проблем при создании дампа и его импорте лучше пользоваться родными средствами MySQL, см http://sqlinfo.ru/forum/viewtopic.php?id=583
Несоответствие данных
В этой части собраны ошибки, которые возникают из-за нарушения ссылочной целостности, т.е. наличие в дочерней таблице записей, которым нет соответствия в родительской таблице.
Г1. Удаление родительской таблицы. Нельзя удалить родительскую таблицу при наличии внешнего ключа.
create table t1 (a int, index(a)) engine=innodb;create table t2 (a int, foreign key (a) references t1(a)) engine=innodb;drop table t1;
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails
Удаление следует понимать в расширенном варианте как удаление из множества InnoDB таблиц. Например, если мы сменим (alter table) движок родительской таблицы на MyISAM, то с точки зрения ограничения внешнего ключа родительская таблица перестанет существовать (т.к. она должна быть постоянной innodb таблицей):
alter table t1 engine=myisam;
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails
Сначала нужно удалить внешний ключ (или всю дочернюю таблицу, что удалит в том числе и внешний ключ). Если вы не знаете какие таблицы являются дочерними для заданной таблицы, то это можно определить через запрос к information_schema:
select table_name from information_schema.key_column_usage where table_schema = «test» and references_table_name = «t1»;
Г2. Изменение данных в родительской таблице. Если в определении внешнего ключа не задано действие при update/delete, то такие операции над родительской таблицей могут привести к несогласованности данных, т.е. появлению в дочерней таблице записей не имеющих соответствия в родительской таблице.
Примеры
create table t1 (a int, index(a)) engine=innodb;create table t2 (a int, foreign key (a) references t1(a)) engine=innodb;insert into t1 values(1);insert into t2 values(1);update t1 set a=2;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`test`.`t2`, CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`a`) REFERENCES `t1`(`a`))
Г3. Изменение данных в дочерней таблице. Если insert/update записи в дочерней таблицы приводит к несогласованности данных, то
Примеры
create table t1 (a int, index(a)) engine=innodb;create table t2 (a int, foreign key (a) references t1(a)) engine=innodb;insert into t2 values(15);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`test`.`t2`, CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`a`) REFERENCES `t1` (`a`))
Г4. Добавление внешнего ключа на не пустую таблицу. При попытке добавить внешний ключ на таблицу, в которой есть записи, не удовлетворяющие условию внешнего ключа (т.е. не имеющие соответствия в родительской таблице), будет ошибка:
Примеры
create table t1 (a int, index(a)) engine=innodb;create table t2 (a int, index(a)) engine=innodb;insert into t2 values(2);alter table t2 add foreign key (a) references t1(a);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`test`.`#sql-3f0_4`, CONSTRAINT `#sql-3f0_4_ibfk_1` FOREIGN KEY (`a`) REFERENCES `t1` (`a`))
Г5. Не уникальный ключ в родительской таблице. По стандарту SQL набор полей, на которые ссылается внешний ключ, должен быть уникальным. Однако, реализация внешних ключей в InnoDB позволяет иметь несколько «родителей». Из-за этого возникает трудно диагностируемая ошибка:
Примеры
create table t1 (a int, index(a)) engine=innodb;create table t2 (a int, index(a)) engine=innodb;insert into t1 values (1),(1);insert into t2 values(1);delete from t1 where a=1 limit 1;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`test`.`t2`, CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`a`) REFERENCES `t1`(`a`))
Почему возникает ошибка error establishing a database connection wordpress
Ошибка установки соединения с базой данных wordpress или error establishing a database connection wordpress по-английски может возникать по многим причинам. Давайте сначала рассмотрим почему она может появляться на хостинге. Я раньше размещал свой сайт на хостинге и встречался с ней довольно часто. Тут может три причины:
- База данных не создана. То есть, возможно, раньше она и была, но потом ее кто-то удалил и ее больше нет. Если база данных есть, но она пуста, то wordpress покажет сообщение что он неверно установлен и его нужно переустановить;
- Данные доступа к базе данных в файле wp-config.php указаны неверно. Если хост, пользователь базы или его пароль неверны, то вы не сможете к ней подключиться;
- Достигнут лимит подключений. Обычно, хостинги не хотят чтобы клиенты перенагружали общую базу данных и устанавливают лимит на количество подключений от одного клиента, например, 8. Когда у вас будет большая посещаемость этого станет явно недостаточно и вы будете видеть такую ошибку время от времени, казалось бы, совсем без причины.
На VPS две первые причины все еще актуальны, но к ним добавляется еще несколько, поскольку это ваш сервер и за его работу отвечаете только вы:
- Сервис баз данных не запущен — из-за некоторых ошибок во время работы сервис mariadb или mysql может завершить свою работу и, естественно, что тогда база будет недоступной.
- Если база данных размещена на другом сервере, то, возможно, этот сервер недоступен из сети или был отключен.
Запуск восстановления
Существует аварийный запуск (fix) восстановления контакта SQL и файлов стандартными средствами WordPress . По знакомой схеме открываем файл wp-config, в конец вставляем код.
Код восстановления WP
Не забываем сохранять изменения и закачивать обратно на хостинг через FileZilla.
Переходим по адресу site.ru/wp-admin/maint/repair.php где взамен site.ru доменное имя. Откроется страница на которой нажимаем Починить поврежденную базу данных.
Кнопка Починить
Начнется процесс, если он удачно закончился и error establishing a database connection пропала, то появится страница с успешными восстановленными таблицами, и с предупреждениями, что нужно удалить код вносимый ранее для запуска восстановления.
Результат работы