mysql fatal error что это
Устраняем типичные ошибки в MySQL
Авторизуйтесь
Устраняем типичные ошибки в MySQL
MySQL — система управления базами данных (СУБД) с открытым исходным кодом от компании Oracle. Она была разработана и оптимизирована специально для работы веб-приложений. MySQL является неотъемлемой частью таких веб-сервисов, как Facebook, Twitter, Wikipedia, YouTube и многих других.
Эта статья расскажет, как определять, с чем связаны частые ошибки на сервере MySQL, и устранять их.
Не удаётся подключиться к локальному серверу
Одной из распространённых ошибок подключения клиента к серверу является «ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)».
Эта ошибка означает, что на хосте не запущен сервер MySQL ( mysqld ) или вы указали неправильное имя файла сокета Unix или порт TCP/IP при попытке подключения.
Убедитесь, что сервер работает. Проверьте процесс с именем mysqld на хосте сервера, используя команды ps или grep, как показано ниже.
Если эти команды не показывают выходных данных, то сервер БД не работает. Поэтому клиент не может подключиться к нему. Чтобы запустить сервер, выполните команду systemctl.
Чтобы проверить состояние службы MySQL, используйте следующую команду:
Если в результате выполнения команды произошла ошибка службы MySQL, вы можете попробовать перезапустить службу и ещё раз проверить её состояние.
Если сервер работает (как показано) и вы по-прежнему видите эту ошибку, вам следует проверить, не заблокирован ли порт TCP/IP брандмауэром или любой другой службой блокировки портов.
Не удаётся подключиться к серверу MySQL
Ещё одна похожая и часто встречающаяся ошибка подключения — «(2003) Can’t connect to MySQL server on ‘server’ (10061)». Это означает, что в сетевом соединении было отказано.
Следует проверить, работает ли в системе сервер MySQL (смотрите выше) и на тот ли порт вы подключаетесь (как найти порт, можно посмотреть выше).
Похожие частые ошибки, с которыми вы можете столкнуться при попытке подключиться к серверу MySQL:
Ошибки запрета доступа в MySQL
В MySQL учётная запись (УЗ) определяется именем пользователя и клиентским хостом, с которого пользователь может подключиться. УЗ может также иметь данные для аутентификации (например, пароль).
Причин для запрета доступа может быть много. Одна из них связана с учётными записями MySQL, которые сервер разрешает использовать клиентским программам при подключении. Это означает, что имя пользователя, указанное в соединении, может не иметь прав доступа к базе данных.
В MySQL есть возможность создавать учётные записи, позволяющие пользователям клиентских программ подключаться к серверу и получать доступ к данным. Поэтому при ошибке доступа проверьте разрешение УЗ на подключение к серверу через клиентскую программу.
Увидеть разрешённые привилегии учётной записи можно, выполнив в консоли команду SHOW GRANTS
Входим в консоль (пример для Unix, для Windows консоль можно найти в стартовом меню):
В консоли вводим команду:
Дать привилегии конкретному пользователю в БД по IP-адресу можно, используя следующие команды:
Ошибки запрещённого доступа могут также возникнуть из-за проблем с подключением к MySQL (см. выше).
Потеря соединения с сервером MySQL
С этой ошибкой можно столкнуться по одной из следующих причин:
В первом случае убедитесь, что у вас стабильное сетевое подключение (особенно, если подключаетесь удалённо).
В случае с размером BLOB нужно установить более высокое значение для max_allowed_packet в файле конфигурации /etc/my.cnf в разделах [mysqld] или [client] как показано ниже.
Если файл конфигурации недоступен, это значение можно установить с помощью следующей команды.
Слишком много подключений
Недостаточно памяти
Если такая ошибка возникла, это может означать, что в MySQL недостаточно памяти для хранения всего результата запроса.
Сначала нужно убедиться, что запрос правильный. Если это так, то нужно выполнить одно из следующих действий:
Также может помочь MySQL Tuner. Это полезный скрипт, который подключается к работающему серверу MySQL и даёт рекомендации по настройке для более высокой производительности.
MySQL продолжает «падать»
Если такая проблема возникает, необходимо выяснить, заключается она в сервере или в клиенте. Обратите внимание, что многие сбои сервера вызваны повреждёнными файлами данных или индексными файлами.
Вы можете проверить состояние сервера, чтобы определить, как долго он работал.
Кроме того, можно остановить сервер, сделать отладку MySQL и снова запустить службу. Для отображения статистики процессов MySQL во время выполнения других процессов откройте окно командной строки и введите следующее:
Заключение
Самое важное при диагностике — понять, что именно вызвало ошибку. Следующие шаги помогут вам в этом:
Ordnung muß sein. Ordnung über alles (18+)
Инструменты пользователя
Инструменты сайта
Боковая панель
Навигация
Линкшэринг
socialite Display:icon facebook twitter
ALARM!
Добавить новую страницу
Реклама
Содержание
Ошибки
Foreign key / Внешние ключи / Ошибка #1217
Теория в другом месте. Только фикс.
Текст ошибки может быть разным
В mysql cli отключаем проверку внешних ключей, делаем нужный запрос, включаем обратно.
Run ‘systemctl daemon-reload’ to reload units
Warning: The unit file, source configuration file or drop-ins of mariadb.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.
Can’t init tc log
MySQL “Got an error reading communication packet” errors
Can’t create a new thread (errno 11)
Не работает phpmyadmin под root’ом. Для MySQL 127.0.0.1 и localhost это разные хосты.
Добавляем отдельного пользователя для администрирования
что-то там с sudo и unix_socket, не разбирался пока, но вариант рабочий.
mysqldump: Couldn’t execute ‘show events’
Ошибка mysqldump: Couldn’t execute ‘show events’: Cannot proceed because system tables used by Event Scheduler were found damaged at server start после перехода на MariaDB с MySQL 56 на cPanel сервере
mysql_upgrade по рекомендациям тоже не работает с ошибкой mysqldump: Got error: 1102: Incorrect database name ‘#mysql50#.config'» when selecting the database
И мне помог не cPanel, а Plesk
В /var/lib/mysql/ был каталог с точкой в имени.
Чтобы его найти выполним команду
Решение
Удалить/перенести каталог в другой место, выполнить mysql_upgrade.
Индексы FULLTEXT поддерживаются в таблицах InnoDB только начиная с MYSQL 5.6, поэтому попробуйте обновить MYSQL и после этого изменить команду таблицы
Waiting for table metadata lock
No directory, logging in with HOME=/
Подобная ошибка была в Debian с репозиторием dotdeb.
Надо поправить /etc/passwd
Can’t create thread to kill server (errno= 11)
Т.е. key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections в итоге получается больше чем RAM на сервере.
Can’t create a new thread (errno 11)
Ошибка похожа на Can’t create thread to kill server и также связана с лимитами.
В данном случае нужно увеличить количество открытых файлов и количество процессов ( nofile и nproc ).
По-умолчанию open files равен 1024.
Проверим, чтобы удостовериться
Добавляем в файл /etc/security/limits.conf
Либо устанавливаем лимит только для mysql
Нашёл рекомендацию добавить лимиты в отдельный файл 99-mysql.conf в каталоге /etc/security/limits.d/
unknown variable ‘default-tmp-storage-engine=MyISAM’
Вот такая ошибка может возникнуть если бездумно копировать из разных блогов советы бывалых админов
default-tmp-storage-engine появился только в MySQL 5.6 и если использовать опцию в версии 5.5, то MySQL не запустится.
Host ‘a.b.c.d’ is blocked because of many connection errors; unblock with ‘myscladmin flush-hosts’
Ошибка возникает после 10 (по-умолчанию) неудачных соединений с базой.
Fatal error: Uncaught exception ‘Exception’ with message ‘Error: Can’t open file: ‘./ocr/oc_product.frm’ (errno: 24)
В логе mariadb.log нечто подобное
Текущее использование открытых файлов можно посмотреть так:
InnoDB: mmap(137363456 bytes) failed; errno 12
Правильный UTF-8
а потом трахбах и deprecated
И опять убунта. Что за чудо система. Не даёт скучать. Сиди чини её нескончаемые баги. Впрочем ничего нового.
И всё начинает работать. До следующего адового бага. Продакшен реди итиху мать.
/usr/sbin/mysqld: Error on realpath() on ‘/var/lib/mysql-files’ (Error 2)
Баг после апгрейда встретился только в Ubuntu
ЕМНИП нужно просто создать каталог /var/lib/mysql-files
‘ERROR 1214 (HY000) at line 784: The used table type doesn’t support FULLTEXT indexes ‘
FULLTEXT INDEX раньше работал только с MyISAM. С версии 5.6 доступен в InnoDB.
Так что либо апгрейд либо ALTER TABLE `yourtable` ENGINE = MyISAM;
Got an error from unknown thread, /builddir/build/BUILD /storage/myisam/mi_write.c:226
Также в логах может быть что-то вроде Incorrect key file for table ‘xyz.MYI’; try to repair it
Скорее всего нет инодов или кончилось место или недоступен tmpdir в mysql.
mysqldump: Got error: (Errcode: 24) when using LOCK TABLES
Узнал о крутой утилите perror. По коду ошибки покажет, что не так.
Error Number: 1364
Через tcpdump выловил ошибку в php-fpm
Виной всему старый код и новый (5.7) MySQL.
Для этого нужно добавить в my.cnf
Можно также вынести в отдельный файл /etc/mysql/conf.d/disable_strict_mode.cnf
Проверить sql_mode
Проверяем логи. Если есть нечто подобное
то значит так оно и есть. Выключаем innodb_force_recovery и всё снова работает.
error: ‘Access denied for user ‘debian-sys-maint’@’localhost’ (using password: YES)’
Смотрим пароль пользователя debian-sys-maint в файле /etc/mysql/debian.cnf
Выполняем 2 SQL запроса, чтобы вернуть гражданину debian-sys-maint его привилегии
Перезапускаем MySQL сервер
open-files-limit в MariaDB
И вносим следующие правки
Данные новшества однако документированы. Так что надо просто внимательнее читать release notes и changelog.
Решение в сети, которое якобы некоторым помогает
Бытует мнение, что виной всему Apparmor т.к. нигде кроме Ubuntu ошибка эта не встречалась
Можно попробовать добавить в /etc/apparmor.d/usr.sbin.mysqld
надо проверить
unknown option ‘—skip-locking’
Опцию –skip-locking убрали в MySQL 5.5.
Решение: заменить skip-locking на skip-external-locking
Mysql fatal error что это
Обсуждаем
Одна из распостраненных задач, которые доводится решать в системном администрировании — это обеспечение стабильной работы сервера баз данных. Чаще всего в этой роли выступает Mysql. Есть и другие, postgresql тоже отличный сервер, хотя он используется обычно для не коробочных проектов, для индивидуальных разработок. Например, для приложений на python часто применяется. Но большинство популярных коробочных CMS, таких как WordPress, DLE, Joomla, работают в связке с базой данных Mysql. Поэтому я хочу рассмотреть решение проблем Mysql, возникающих у многих вебмастеров.
К примеру, частая проблема — это «Ошибка подключения к базе данных». Так например ругается wordpress, когда не может установить связь с БД. Чаще всего это случается когда Mysql просто выключается. Такое может происходить например при нехватке ресурсов, допустим на серверах минимальных тарифов и конфигураций, даже под небольшой нагрузкой.
Выглядит это примерно следующим образом.
Ошибка mysql: «Fatal error: cannot allocate memory…»
В логах mysql звучит оно чаще всего именно так. Обычно что-то вроде
InnoDB: Fatal error: cannot allocate memory for the buffer pool
При этом всём, сервер не будет показывать явную нехватку памяти. Именно это и заводит обычно разбирающихся с проблемой в тупик. Чаще всего это бывает, когда на сервере 1-2 гб памяти.
Происходит при этом интересная вещь. Mysql аккуратно убивается ядром системы. Для того, чтобы системе хватило памяти на саму себя и другие процессы. Обычно это конечно неоправданно, ибо на сервере нет других столь же ресурсоёмких процессов, как mysql или mariadb. Не всегда причина в этом, но это наиболее частая, типичная картина при регулярных падениях базы данных сайта.
Убедиться в том можно посмотрев в системный лог /var/log/messages либо /var/log/syslog — в зависимости от семейства OS. Там будут сообщения о том, что сработал OOMKiller и выключил mysql.
Как это происходит:
Чаще всего, с mysql за потребление памяти конкурирует Apache. Скажем, на сервере 1 гб памяти. Из них, скажем, в норме mysql использует 200, апач 100 и ядро OS и вся остальная система 100. В сумме 400 мегабайт занято, всё хорошо, система работает стабильно. Тут начинается час пик, на сайт идёт трафик. Апач начинает есть 200 мб памяти, mysql 500, а ОС все так же 100. В сумме — 800. А у нас на сервере 1 gb, всё хорошо, проблем быть не должно. Но по-умолчанию политика 50%. Ядро видит, что mysql взяло 500, не дожидается что пока оно съест ещё больше, и убивает его. А иначе вероятна ситуация, что процесс съест память, и система умрёт сама. Для защиты от этого и предназначен сей механизм.
Отсюда и возникают проблемы с базой данных. Обычно вебмастера «лечат» это обычной перезагрузкой сервера. Что и логично — всё перезагрузили, память переспределилась, потребление меньше — система работает. Но буквально через считанные минуты под нагрузкой всё может повториться. Те кто продвинутей, понимают, что дёргать весь сервер смысла нет. Можно перезапускать процессы.
Что же тут делать чтобы избежать падений?
Логичный вариант — добавить оперативной памяти на сервер. Но многие скажут — да как же, у нас и так всего 800 из одного гб используется, какой смысл добавлять ещё? И будут правы.
Можно не добавлять. Особенно если сайты у вас не такие уж и посещаемые, вы уверены, что нагрузка там не такая уж большая и вашего 1 gb должно хватать. И действительно, это лечится. Многие уже догадались, что нужно лишь изменить политику распределения памяти в ядре.
Дело в том, что в ядре Linux есть параметры, отвечающие за выделение памяти процессам. По-умолчанию задана политика, когда на процесс не может быть выделено более 50% доступной машине памяти. И есть там такая штука, которая прибивает процессы, требующие большего объема памяти, чем указано в этой политике. Называется она OOMKiller. OOM = Out Of Memory — классическая аббревиатура, обозначающая нехватку памяти. А в логах ещё обычно пишут «cannot allocate memory».
Итак, за это отвечают два параметра:
vm.overcommit_ratio = 50
vm.overcommit_memory = 0
Именно такие значения они имеют по-умолчанию. Нам же нужно их изменить следующим образом:
vm.overcommit_ratio = 90
vm.overcommit_memory = 2
Я не буду вдаваться в подробности и объяснения по второму параметру. Кому нужна эта информация может ознакомиться здесь.
Переопределять эти параметры нужно в файле /etc/sysctl.conf. Но прежде, нужно сделать ещё одну важную вещь, без которой вы можете сильно навредить системе. Перед тем как назначить такие значения ядру, необходимо убедиться в том, что на вашем сервере есть swap. То есть файл или раздел подкачки. И если нет, то нужно его создать. Он необходим для распределения памяти согласно заданным параметрам ядра.
Как проверить наличие swap и создать его
Для этого нужно лишь взглянуть на менеджер процессов в вашей системе. Обычно это top:
На скрине отмечена информация о свопе. А точнее, о его отсутствии.
В нем это гораздо наглядней и понятней:
Как видите, нижняя строка — Swp — 0. Это значит, что в системе свопа нет. Скорей всего ваш случай. Только у вас строка Mem над ней будет выглядеть иначе, поскольку у вас скорей всего будет меньше памяти. А если говорить конкретно об этом сервере, откуда я сделал скрин — то для него отсутствие свопа не проблема, ибо на нём памяти более чем достаточно и её нехватки не предвидится ( Кстати, такой мощный сервер с 24 гб памяти и 6 ядрами, 600 GB SSD стоит всего 15 евро в месяц )
Если же своп у вас уже есть, то выглядеть это будет примерно вот так:
Создаем свопфайл
Вообще, на большинстве серверов обычно своп создается по умолчанию, при установке системы. Под него выделяется отдельный раздел диска. Но поскольку вебмастера чаще имеют дело с VPS, то если он не был создан хостером при создании VPS, возможности создать его отдельным разделом уже нет. Или это довольно сложно и не нужно. Удобно и достаточно создать swap-файл.
Делается это следующим образом:
dd if=/dev/zero of=/swapfile bs=1M count=1024
По завершении команда выдаст отчет о том что сколько-то данных было записано и с какой скоростью.
Теперь нужно этот файл инициализировать и подключить в качестве свопа.
chmod 0600 /swapfile
Теперь нужно прописать его в таблицу файловых систем, чтобы после перезагрузки сервера он подключался автоматически.
Для этого добавим строку в файл /etc/fstab такого содержания:
/swapfile swap swap defaults 0 0
В приниципе после перезагрузки у нас своп теперь появится. Но чтобы подключить его в первый раз сразу и без перезагрузки мы можем дать такую команду:
Эта команда перечитает файл /etc/fstab и подключит наш новый своп. Теперь можем снова смотреть в htop, и увидим что он появился.
Меняем параметры ядра Linux, политику распределения памяти
Для этого открываем файл /etc/sysctl.conf и дописываем строки
vm.overcommit_ratio = 90
vm.overcommit_memory = 2
Если вы этого ещё не сделали.
Эта команда перечитает файл sysctl.conf и принудительно задаст наши параметры из него, о чём и отрапортует после выполнения.
На этом всё. Теперь ни mysql, ни любой другой процесс не будет убиваться ядром при большем потреблении памяти. Своп мы создали в качестве страховки, он как бы дополняет и продолжает основную память системы, является используемым резервом.
Оптимизация параметров mysql
Однако не всегда всего вышеописанного может быть достаточно для стабильной работы mysql. Часто есть необходимость также изменить параметры самого mysql. Ибо в его конфигурации также есть много параметров, отвечающих за использование памяти. Это всевозможные кэши, пулы и буферы.
Ну а мне за сим остаётся только пожелать вашим серверам, базам данных и сайтам стабильной и быстрой работы. А также без лишней скромности напомнить, что в случае проблем с mysql или mariadb, (или даже postgresql чего доброго) вы всегда можете обращаться по контактам к автору сего опуса.
Fatal error: Uncaught Error: Call to undefined function mysql_connect() — как исправить
PHP 7 является новой версией языка программирования. Её предшественницей считается PHP 5, т. к. 6 версия так и не была выпущена для общего пользования в связи с возникшими во время разработки проблемами. Но это отдельная тема, а сегодня мы разберем, когда при переводе сайта с PHP 5 на PHP 7 возникает ошибка Fatal error: Uncaught Error: Call to undefined function mysql_connect(), и как её исправить, чтобы наш ресурс заработал быстрее, стабильнее и надежнее.
С чем связана ошибка Fatal error
Ошибка, начинающаяся словами «Fatal error: Uncaught Error:», вызывает прекращение работы скрипта. В нашем случае она вместе с рядом других часто появляется при переводе старого сайта с PHP 5 на PHP 7. Выскакивают либо сообщения с уведомлениями об ошибках, либо просто висит белый экран. Здесь есть 2 пути – либо вернуть все назад, переключившись в панели управления хостингом, либо проявить настойчивость, разобраться с этой ошибкой и работать уже с новой версией PHP. Итак, давайте посмотрим, с чем же конкретно связана наша ошибка.
Как видно из самого названия ошибки, проблема связана с тем, что новые версии PHP (начиная с v. 5.5.0) не осуществляют поддержку оригинального расширения MySQL, в связи с чем сайт не собирает и не отправляет данные из БД. В этом случае разработчики предлагают перейти на расширения PDO или MySQLi. Попробуем выполнить несколько простых действий по переходу на MySQLi. Также пользователи иногда сталкиваются с ошибкой Error CertEnroll, возникающей в процессе создания запроса на выпуск сертификата на сайте “Росказна”.
Создание резервных копий сайта
Прежде чем предпринимать какие-либо серьезные попытки исправить Fatal error: Uncaught Error: Call to undefined function mysql_connect, необходимо создать резервные копии своего сайта и БД. Также для того, чтобы была неограниченная возможность экспериментировать, добавляем на хостинге еще один сайт и копируем туда файлы, в которые будем вносить различные корректировки. Подобный подход поможет избежать последствий необдуманных или неосторожных действий с данными – мы их уже не потеряем, т. к. они дополнительно хранятся в резервных копиях. Это актуально при решении различных задач, например, при отладке кода на JavaScript иногда приходится решать ошибку TypeError: Cannot read property ‘xxx’ of undefined.
Настройка журнала ошибок
Переводим сайт на MySQLi
Итак, вначале вносим коррективы в конструкцию, при помощи которой сайт подключается к базе данных. Открываем действующую запись.
В конструкцию, отвечающую за запросы, также вносим изменения. Берем действующую запись.
Теперь выглядит так.
Измененная конструкция, отвечающая за запросы
Открываем следующие популярные функции:
И везде производим замену mysql на mysqli. Наша картина выглядит следующим образом.
Теперь сбор и отправка информации из БД должны осуществляться без сбоев.
CP1251 и PHP 7 – как расшифровать непонятный набор символов
Исправляем ситуацию в сайте, написанном при помощи CP1251
Проблемы с компьютером возникают нередко, и многие из них нужно научиться устранять самостоятельно. Например, это такие ситуации, как ошибка html5 Video file not found при просмотре видеороликов в сети или ошибки 0x0001, 0x0003 в дополнительной утилите Nvidia GeForce Experience.
Заключение
В этой статье мы рассмотрели, почему при переводе сайта с PHP 5 на PHP 7 возникает ошибка Fatal error: Uncaught Error: Call to undefined function mysql_connect(), и рассмотрели пути ее решения. Сложного в этом ничего нет, были внесены небольшие коррективы в конструкции, отвечающие за подключение к БД и за запросы. Также коснулись ситуации, когда сайт написан с использованием старой кодировки CP1251. Надеюсь, что предложенные варианты помогут вам исправить ситуацию и без проблем работать на PHP 7.