Разное

Database error: Ошибка установки соединения с базой данных WordPress

Содержание

Ошибка установки соединения с базой данных WordPress

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

Эта ошибка будет выводиться на каждой странице вашего сайта и вы потеряете посетителей, а также доход, который могли получить. В этой статье мы рассмотрим почему возникает ошибка error establishing a database connection wordpress, а также способы борьбы с ней на хостинге и на VPS.

Содержание статьи:

Почему возникает ошибка error establishing a database connection wordpress

Ошибка установки соединения с базой данных wordpress или error establishing a database connection wordpress по-английски может возникать по многим причинам. Давайте сначала рассмотрим почему она может появляться на хостинге. Я раньше размещал свой сайт на хостинге и встречался с ней довольно часто. Тут может три причины:

  • База данных не создана. То есть, возможно, раньше она и была, но потом ее кто-то удалил и ее больше нет. Если база данных есть, но она пуста, то wordpress покажет сообщение что он неверно установлен и его нужно переустановить;
  • Данные доступа к базе данных в файле wp-config.php указаны неверно. Если хост, пользователь базы или его пароль неверны, то вы не сможете к ней подключиться;
  • Достигнут лимит подключений. Обычно, хостинги не хотят чтобы клиенты перенагружали общую базу данных и устанавливают лимит на количество подключений от одного клиента, например, 8. Когда у вас будет большая посещаемость этого станет явно недостаточно и вы будете видеть такую ошибку время от времени, казалось бы, совсем без причины.

На VPS две первые причины все еще актуальны, но к ним добавляется еще несколько, поскольку это ваш сервер и за его работу отвечаете только вы:

  • Сервис баз данных не запущен — из-за некоторых ошибок во время работы сервис mariadb или mysql может завершить свою работу и, естественно, что тогда база будет недоступной.
  • Если база данных размещена на другом сервере, то, возможно, этот сервер недоступен из сети или был отключен.

Что делать с error establishing a database connection

Теперь попробуем разобрать каждый из вариантов и попытаться понять что делать с error establishing a database connection, а также для предотвращения ее появления в будущем.

1. Базы данных нет

Если базы данных больше не существует, вы ее случайно стерли или ее стер хостер, то у вас есть два пути — либо установить WordPress заново, либо восстановить базу данных mysql из резервной копии. Все настройки базы данных находятся в файле wp-config.php, который находится в корневом каталоге сайта. Скорее всего, на хостинге у вас не будет доступа по SSH и придется довольствоваться FTP.

Вы можете посмотреть как называется база данных в нем:

Затем убедитесь, с помощью Phpmyadmin, что она есть и в ней есть данные:

2. Неверные настройки

Как я уже сказал, все настройки работы с базой данных находятся в файле wp-config.php. Вы можете посмотреть его содержимое через FTP или подключившись к серверу по SSH. Нужные нам параметры находятся в таких переменных:

  • DB_NAME — имя базы данных;
  • DB_USER — пользователь базы;
  • DB_PASSWORD — пароль базы;
  • DB_HOST — хост базы;

Проверить правильность ввода логина и пароля вы можете попытавшись войти с помощью них в Phpmyadmin:

Или используя консольную утилиту mysql если можете подключиться по ssh:

mysql -h хост -u пользователь -p имя_базы данных

Если проблема в данных аутентификации, то утилита выдаст ошибку и вы точно будете знать что неверно. Дальше останется найти правильные данные и указать их в файле wp-config.php. Если же данные верные, идем дальше.

3. Ограничения сервера

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

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

4. Сервис mysql не запущен

Эта проблема уже касается только VPS, поскольку на хостингах у вас нет доступа к таким службам и вы не сможете ничего сделать. На VPS вы можете делать все что угодно с любой службой. Чаще всего в качестве сервера баз данных используется MariaDB. Чтобы проверить запущена ли она в CentOS наберите:

systemctl status mariadb

В Ubuntu имя сервиса будет немного отличаться:

systemctl status mariadb-server

Если вы увидите надпись Iactive (dead) значит сервис не запущен. Почему? Это уже другой вопрос. Чтобы восстановить работоспособность сайта попробуйте запустить его:

systemctl start mariadb-server

Чаще всего сервер баз данных падает из-за нехватки памяти для работы движка innodb. Чтобы предотвратить такие падения в будущем можно сделать две вещи:

  • Удалить или остановить программы, потребляющие очень много памяти или увеличить количество памяти на сервере;
  • Настроить автоматический перезапуск MariaDB в случае, если она упала с помощью systemd. В этом случае вы даже не будете замечать, что были какие-либо проблемы и ошибка error establishing a database connection возникать не будет, но это только пока с памятью все не совсем уж плохо.

Чтобы заставить systemd следить за состоянием сервиса и перезапускать его по мере необходимости создайте файл /etc/systemd/system/mariadb.service.d/restart.conf и добавьте в него такое содержимое:

vi /etc/systemd/system/mariadb.service.d/restart.conf

[Service]
Restart=always

Затем обновите конфигурацию сервисов:

systemctl daemon-reload

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

systemctl show mariadb

Выводы

В этой статье мы разобрали почему возникает ошибка установки соединения с базой данных WordPress, а также как решить эту проблему чтобы она не повторялась и вы не теряли пользователей. Еще одним полезным моментом будет мониторинг, если вы настроите отслеживание работы сервера с помощью Nagios, Monit или Zabbix, то сможете сразу же узнать о возможных проблемах. Надеюсь, эта информация была полезной для вас.

Оцените статью:

Загрузка…

слишком много соединений / Блог компании Southbridge / Хабр

И снова ERROR 1040…

Техподдержка получает много жалоб на эту печально известную ошибку: ERROR 1040: Too many connections — слишком много соединений. Проблема очевидна: приложение или пользователи создают больше соединений, чем допускает сервер, то есть текущее число соединений превышает значение переменной max_connections.

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

Root-пользователь тоже не может подключиться! Почему?!

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

mysqld разрешает max_connections + 1 клиентских соединений. Дополнительное соединение зарезервировано для аккаунтов с привилегиями SUPER. Когда эти привилегии предоставляются администраторам, а не обычным пользователям (которым они и не нужны), администратор, у которого есть еще и привилегия PROCESS, может подключиться к серверу и использовать SHOW PROCESSLIST, чтобы диагностировать проблемы, даже если подключено максимальное число клиентов без привилегий.

Но куча людей дают привилегии SUPER своим пользователям приложения или скрипта — из-за требований приложения (опасно!) или незнания последствий, а потом зарезервированное соединение занимает обычный пользователь, а административный пользователь (обычно root) не может подключиться.

Как гарантировать доступ к экземпляру

Можно использовать хорошо известный хак с GDB, который советовал Ауримас лет 100 назад для ошибки 1040, но теперь есть решения получше. Правда сначала их надо включить.

С Percona Server 5.5.29 и выше и MySQL 8.0.14 и выше можно настроить еще один порт с дополнительным числом соединений. Приложение не будет использовать эти интерфейсы. Они только для администраторов баз данных и агентов мониторинга и проверки работоспособности (см. примечание ниже).

Настройка Percona Server

Начиная с Percona Server 5.5.29 можно просто добавить extra_port в my.cnf, и при следующем перезапуске порт будет доступен и будет ожидать данные по тому же bind_address, что и обычные соединения. Если не настроить переменную extra_port, дополнительного порта по умолчанию не будет.

Еще можно определить extra_max_connections, чтобы задать количество подключений, которое будет обрабатывать этот порт. Количество по умолчанию — 1.

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

результат

Кстати, extra_port удален в Percona Server 8.0.14 и выше, поскольку в MySQL Community реализован admin_port с теми же функциями. Так что отредактируйте my.cnf при апгрейде до Percona Server 8.0.14 или выше, если вы уже определили extra_port.

Как я уже сказал, для этого нужен MySQL 8.0.14, где применен WorkLog 12138.

Чтобы включить админский интерфейс, нужно определить admin_addres, который должен быть единственным и уникальным (без подстановочных символов) IPv4, IPv6, IPv4-сопоставленным адресом или именем хоста, по которому админский интерфейс будет ожидать передачи данных. Если эта переменная не определена, интерфейс не включен.

Еще можно определить порт, но это не обязательно. По умолчанию это порт 33062. Если этот порт свободен, это значение не нужно настраивать. Если настраиваете, то поместите обе переменные в раздел [mysqld] в my.cnf.

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

Еще одно различие — в документации Oracle сказано, что:

Число административных соединений не ограничено.

(А у нас значение по умолчанию — 1). Не уверен, что это значит, но я бы был осторожен, чтобы случайно не установить 1 млн соединений. Они, конечно, не ограничены, но ресурсы-то все равно потребляют.

Использование для мониторинга и проверок работоспособности

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

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

Обязательно устанавливайте только по одному соединению за раз для мониторинга и проверки работоспособности, чтобы не забивать extra_max_connections в Percona Server и не создать миллион потоков в MySQL. То есть скрипты не должны подключаться снова, если предыдущий запрос или подключение к базе данных еще активны.

Вот тот же пример, но с MySQL.

Для Percona Server 8.0.14 и выше процесс будет тем же, что и для MySQL Community.

Помогите! Мне нужно войти, но все порты заняты!

Если это та самая причина, по которой вы читаете этот пост, используйте безумный хак с GDB (без обид, Ауримас, просто выглядит рисково :-D) или завершите экземпляр. К счастью, экземпляр почти всегда можно аккуратно завершить с помощью SIGTERM (-15) вместо SIGKILL (-9). Так сервер выполнит чистую остановку, и у потоков будет шанс нормально завершить работу. Просто следуйте инструкциям:

1) Получите PID:

marcos.albe in ~/ pgrep -x mysqld;
650

2) Отправьте SIGTERM в этот PID:

marcos.albe in ~/ kill -15 650;

3) Следите в журнале ошибок, как выполняется завершение работы. Это будет выглядеть примерно так:

2019-07-11T13:43:28.421244Z 0 [Note] Giving 0 client threads a chance to die gracefully
2019-07-11T13:43:28.521238Z 0 [Note] Shutting down slave threads
2019-07-11T13:43:28.521272Z 0 [Note] Forcefully disconnecting 0 remaining clients

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

2019-07-11T13:43:31.292836Z 0 [Note] /opt/percona_server/5.7.26/bin/mysqld: Shutdown complete

Error establishing a database connection

Для тех, кто работает с движком WordPress достаточно долго, проблем с ошибками практически не возникает. Они уже понимают, откуда исходят неполадки и что с ними делать. Но для тех, кто только недавно начал использовать эту платформу, ошибка error establishing a database connection может показаться незнакомой. Что делать, если вы видите эту ошибку — читайте в этой статье.

Причины появления ошибки в WordPress

Ошибка при обращении к определенным файлам или страницам WordPress «Error establishing a database connection» переводится как — сбой при попытке обратиться к базе данных. Причин для неё может быть много. Возможно вы недавно изменили пароль или ввели какие-либо данные при авторизации неверно. Могут быть и более простые причины — в данный момент на сервере, где находится база данных ведутся профилактические работы. Не исключено, что некоторые файлы повреждены, поэтому вы видите на экране эту ошибку.

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

Устранение сбоев с базой данный WP

Для начала нужно установить, что ошибка возникает при попытке установить связь с БД через вашу админ-панель и через пользовательский интерфейс, то есть по домену вашего сайта без /wp-admin. Попытайтесь обратиться к базе с разных сторон. Если ошибка повторяется — значит с базой данных действительно проблемы. В этом случае их необходимо решить путем проверки настроек базы данных. Ошибка в этом случае говорит нам, что вы могли изменить хостинг компанию. Возможно, были также изменена информация о пользователе, но в файле wp-config.php изменений не произошло.

Вам необходимо сделать следующее:

  1. Откройте в менеджере файл wp-config.php. Можно подключиться по FTP;
  2. Откройте нужный каталог, в котором находится wp-config.php;
  3. В нем вы сможете увидеть свои данные для авторизации. Они будут выглядеть следующим образом: database password, database username.

    Сравнение данных в БД и в файле wp-config.php

В файле также есть префиксы, рассмотрим их значения.

  • Table_prefix — этот префикс относится к базе данных;
  • DB_HOST — имя сервера базы данных;
  • DB_USER — пользовательское имя, необходимое для входа;
  • DB_PASSWORD — пароль, которые нужен для входа;
  • DB_NAME — имя самой базы данных.

В том случае, если вы вводите данные для входа, отличающиеся от данных в файле wp-config.php, то вы будете встречать ошибку error establishing a database connection.

Восстановление базы данных WordPress

Если вы обратились к своему сайту с админ панели и с пользовательской стороны, но ошибка при этом уже другая, скорее всего вам необходимо попытаться восстановить базу данных, так как в ней произошли изменения. В этом случае ошибки будут продолжаться до тех пор, пока вы не исправите ситуацию. Платформа WordPress имеет собственный инструмент восстановления БД. Для того, чтобы активировать его, вы должны иметь свободный доступ к wp-config.php. Это можно сделать при помощи cPanel.

  1. Откройте файловый менеджер (File Manager) и пройдите по пути к нужной папке, где находится WordPress;
  2. Когда вы откроете WP, найдите там следующую строку «WP_ALLOW_REPAIR». Через запятую и проблем к ней нужно добавить слово «true»;

    Восстановление базы данных

  3. Проверьте снова доступ к базе данных.

При входе вы должны будете увидеть следующее окно, где будет 2 варианта восстановления. При этом необходимо знать, что пока вы добавили в настройках слово «true», к утилите восстановления БД, будет открыт доступ любому, даже не авторизованному пользователю.

Выбор способа восстановления БД

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

Другие способы проверить данные БД

Лучшим способом определить, что вводимая информация верна — проверить и сравнить их с информацией самой базы MySQL. Для этого откройте страницу MySQL Database и отыщите здесь нужный нам пункт Current Database. В нем находятся все существующие на вашем сайте БД и пользователи, которые имеют к ним доступ. Вам необходимо отыскать колонки Privileged Users и Database. После этого нужно сравнить данные в DB_USER и DB_NAME и в файлике wp-config.php.

Сравнение данных

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

Вы можете проверить наличие ошибки после каждого метода. Возможно вы уже исправили её и дополнительная информация окажется лишней для вас. Проверьте правильность вводимых данных и убедитесь, что ошибка error establishing a database connection вас больше не тревожит.

 

Восстановление баз exchange | Блог злобного админа



Главная » IT

Случилось на днях неприятное происшествие: в результате непредвиденного сбоя отключился диск с базой exchange 2010. В результате после восстановления диска база отказалась подключаться на сервере Exchange. Поэтому тема заметки «Восстановление баз exchange» в полевых условиях.

При попытке ручного подключения базы данных я получал ошибку:

Couldn't mount the database that you specified. Specified database: Mailbox Database; Error code: An Active Manager operation failed. Error: The database action failed. Error: Operation failed with message: MapiExceptionCallFailed: Unable to mount database. (hr=0x80004005, ec=-515)

Последовательность действий по восстановлению баз exchange

  1. Сделал резервную копию поврежденной базы данных. Процесс этот не быстрый, размер базы был более 400 гб. Но это следовало сделать, чтобы иметь возможность повторить процедуру восстановления базы если что-то пойдет не так.
  2. Проверил диск с базой данных на ошибки утилитой chkdsk.
  3. Проверяем базу с помощью утилиты eseutil. Она находится в подпапке bin папки куда установлен Exchange. Для проверки используем команду:
    eseutil /mh "d:\путькбд\базаданных.edb"
  4. В выводе команды ищем строку содержащую State: Dirty Shutdown. Это значит, что база данных не была корректно отмонтирована.
  5. Производим починку базы данных командой:
     eseutil /p "d:\путькбд\базаданных.edb"

    Процесс не быстрый, на моей базе в 400 Гб он занял около двух часов.

  6. После завершения повторяем команду из п.3. Вы должны увидеть State: Clean Shutdown. На всякий случай делаем копию восстановленной базы (на ваше усмотрение).
  7. Пробуем подключить базу в консоли Exchange, если все подключилось то на этом процедура закончена.
  8. Если база не подключается то необходимо проверить логи командой:
     eseutil /ml "d:\путьклогам\E00"

    Где E00-начальная последовательность именования лог-файлов. На моем сервере она была к примеру E01. Во время проверки необходимо убедится, что все лог файлы прошли без ошибок. Тем не менее, если статус БД в п.6 Clean Shutdown то можно смело удалить все логи.

  9. Если при этом база все-таки не монтируется попробуйте после удаления всех лог-файлов выполнить в консоли PowerShell Exchange команду:
     Mount-database "Name my database" -Force

На этом мое злоключение закончилось, база успешно подключилась. В качестве дополнительного материала могу привести ссылку: http://www.alexxhost.ru/2010/10/eseutil.html