Постоянное соединение с базой данных устанавливается в файле

Обновлено: 06.07.2024

Если вы занимаетесь разработкой своего сайта сначала на локальном компьютере, то при переносе на хостинг практически всегда столкнётесь с ошибкой установки соединения с базой данных, в английской версии WordPress она звучит так: Error establishing a database connection.

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

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

Убедитесь, что имеете исправную резервную копию вашего сайта до любых действий, которые будут предложены ниже в инструкции!

Проявляется ли проблема в wp-admin

Для этого нужно выполнить следующие шаги:

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

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

Проверка файла wp-config.php

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

Имейте в виду, что в константе DB_HOST не всегда будет значение localhost, это может быть и IP адрес сервера, либо же какой-то другой адрес, если вы используете хостинг от МастерХост, например. В любом случае, эту информацию вам нужно уточнить у вашего хостинг-провайдера, либо в личном кабинете вашего хостинга.

Но для большинства хостингов значение DB_HOST будет всё-таки localhost и чаще всего изменять его не придётся.

Проверка работоспособности MySQL сервера

Если у вас виртуальный сервер (VPS) и вы используете cPanel или ISPManager, то ссылка на phpMyAdmin будет на главной странице панели управления сервером.

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

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

Решения, которые помогли другим

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

Обновление настройки в wp_options

Имейте в виду, что таблица wp_options может называться иначе, если вы изменяли префикс таблиц WordPress. В этом случае, вместо wp_ укажите свой префикс.

Подключение под root к базе данных

Если всё пройдёт нормально и сайт заработает, тогда рекомендую зайти в phpMyAdmin, создать нового пользователя и указать логин и пароль нового пользователя в wp-config.php.

Никогда не работайте под учётной записью суперпользователя на вашем боевом сервере.

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

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

Странно, но я успешно захожу в phpmyadmin и в cyberpanel но нет доступа к редактирования файла wp-config то есть я его редактирую, но изменения не сохраняются. А если редактировать через терминал, то просто не дает сохранять изменения. ну и конечно же не дает устанавливать и обновлять плагины. Ввожу запрашиваемые имя и пароль, но ничего не подходит, хотя я ввожу имя и пароль копируя их из файла wp-config. Я что то делаю не так, или ошибка глубже?

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

В курсе рассматриваются требования платформы Bitrix Framework к хостингу, вопросы установки, настройки продукта а также вопросы инструментов и методов оптимизации серверов и баз данных для работы с системой

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

Рекомендуется ознакомиться с опытом настройки и тестирования серверов в блогах Александра Демидова и Дениса Шаромова, а так же с отзывами клиентов о хостингах в группе Черный и белый список хостингов социальной сети компании "1С-Битрикс".

Если ваш хостинг на Windows, то вам может быть полезна группа 1С-Битрикс на платформе Windows Server 2008 в социальной сети сайта "1С-Битрикс". В ней пользователи делятся опытом работы системы на IIS 7.

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

У нас часто спрашивают, сколько нужно заплатить

Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов - ничего из этого оплачивать не нужно.

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

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

уроке.

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат - это если общее число набранных Вами баллов отличается от максимального на 1-2%.

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла от 28.04.2021.

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

Это зависит от того, как происходит взаимодействие с веб-сервером. Существует три основных способа использования PHP сервером для генерации веб-страниц.

Первый способ заключается в том, чтобы использовать PHP как CGI-обёртку. При этом PHP-интерпретатор создаётся и уничтожается при каждом обращении к странице (PHP-скрипту). Поскольку интерпретатор уничтожается после каждого запроса к серверу, все используемые им ресурсы (в том числе и соединение с базой данных) закрываются. Следовательно, в этом случае вы не получите ничего от использования постоянных соединений - их просто нет.

Второй, и наиболее популярный способ - использовать PHP как модуль в сервере, который использует несколько процессов. В число таких серверов сейчас входит только Apache. В таком случае, можно выделить один процесс (родительский), который координирует работу всех остальных процессов (дочерних), которые фактически и выполняют работу по обслуживанию веб-страниц. При каждом обращении клиента к серверу запрос перенаправляется одному из дочерних процессов, который в данный момент не занят обслуживанием другого клиента. Это означает, что когда тот же самый клиент выполняет повторный запрос к серверу, он может быть обработан другим дочерним процессом, отличным от того, который был при первом обращении. После открытия постоянного соединения каждая последующая страница, требующая соединения с базой данных, может использовать уже установленное ранее соединение с SQL-сервером.

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

Ответ содержится в повышении эффективности. Постоянные соединения полезны в том случае, если при открытии большого количества SQL-соединений возникает ощутимая нагрузка на сервер. То, насколько велика эта нагрузка, зависит от многих факторов. Например, от того, какая именно база данных используется, находится ли она на том же компьютере что и ваш веб-сервер, насколько загружена машина, на которой установлен SQL-сервер, и так далее. В случае, если затраты на установку соединения велики, постоянные соединения могут вам существенно помочь. Они позволяют дочернему процессу на протяжении всего жизненного цикла использовать одно и то же соединение вместо того, чтобы создавать его при обработке каждой страницы, которая взаимодействует с SQL-сервером. Это означает, что каждый дочерний процесс, открывший постоянное соединение, будет иметь своё собственное соединение с сервером. Например, если у вас запущено 20 дочерних процессов, которые выполнили скрипт, использовавший постоянное соединение с SQL-сервером, вы получите 20 различных соединений с SQL-сервером, по одному на каждый дочерний процесс.

Следует заметить, что этот подход имеет некоторые недостатки: если вы используете базу данных с ограниченным количеством возможных подключений, оно может быть превышено количеством запрашиваемых дочерними процессами постоянных соединений. Например, если ваша база данных позволяет 16 одновременных соединений, и во время нагрузки на сервер 17 дочерних процессов попробуют открыть соединение, одна из попыток потерпит неудачу. Если в вашем коде содержатся ошибки, не позволяющие закрывать соединение (например, бесконечные циклы), база данных с 32 одновременными подключениями вскоре может оказаться заблокированной. Информацию о том, как обрабатывать открытые и неиспользуемые соединения, вы можете найти в документации к вашей базе данных.

Есть ещё два дополнительных предостережения, которые следует помнить при работе с постоянными соединениями. В случае, если скрипт блокирует таблицу и по каким-либо причинам не может её освободить, при использовании постоянного соединения все последующие скрипты, которые используют это соединение будут блокированы бесконечно долго и могут потребовать рестарта веб-сервера или сервера баз данных. Второе предостережение заключается в том, что открытые транзакции, если они не были закрыты до завершения работы скрипта, будут продолжены в следующем скрипте, использующем это же постоянное соединение. Исходя из этого, вы можете использовать функцию register_shutdown_function() для указания простой функции, которая снимает блокировку таблиц или отката ваших транзакций. Ещё лучше избежать этих проблем полностью, не используя постоянные соединения в скриптах, которые используют блокировку таблиц или транзакции (при этом вы всё ещё можете использовать их где-то в другом месте).

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

+ существенно уменьшить потребление оперативной памяти при обработке статических файлов
- увеличить производительность PHP
- уменьшить число соединений к базе данных
+ снять зависимость производительности системы от медленных каналов пользователей
- защитить систему от медленных каналов пользователей и ускорить время выполнения запросов к базе данных
+ уменьшить число запросов к Back-end за счет самостоятельной обработки статических файлов

3. Если веб-сервер сам передает данные пользователю после их создания, то

+ число обработанных веб-сервером запросов напрямую зависит от скорости Интернет-канала посетителей сайта
- число обработанных запросов зависит только от производительности процессоров
- число обработанных запросов очень несущественно зависит от скорости Интернет-канала пользователя

4. Определите, где и как выполняется PHP-скрипт

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

5. В результате построения двухуровневой архитектуры и выполнения ряда рекомендаций мы должны получить следующие результаты

- система стабилизирована по расходу памяти при запуске; Front-End и Back-End занимают заранее отведенный объем памяти, а при увеличении нагрузки будут использовать виртуальную память
+ возможно безопасное использование постоянного соединения с базой данных без опасения превысить число возможных соединений; в памяти все время находится установленное число Back-end процессов, готовых к обработке запросов и с установленным соединением с базой данных;
+ пользователи комфортно работают со сжатыми страницами
+ использование процессорных ресурсов ограничено числом одновременно работающих процессов Back-end в соответствии с MaxClients; не начнется регрессия производительности;
+ процессорные ресурсы существенно высвобождены за счет прекомпиляции PHP-кода
+ в стрессовой ситуации система будет стабильно и равномерно обрабатывать запросы, Back-end не будет увеличивать число одновременно выполняемых процессов выше установленного лимита MaxClients, Front-end будет принимать все запросы от пользователей и ожидать освобождения процессов Back-end

6. Использование общего веб-сервера для обработки PHP программ и статических файлов

- неэффективное решение из-за наличия задержек при определении типа файлов: статические или PHP программы
+ неэффективное решение из-за большого и неэффективного использования оперативной памяти веб-сервером для обработки статических файлов
- это лучшее решение для обеспечения оптимального расходования оперативной памяти

7. Значение MaxClients надо подбирать так, чтобы

+ даже при стрессовых нагрузках запущенные процессы Back-end потребляли в среднем не более 90% процессорных ресурсов
+ объем используемой памяти процессами Back-end никогда не превышал объем свободной оперативной памяти
+ MaxClients должен быть меньше или равен максимальному числа соединений с базой данных
- число процессов Back-end было всегда больше максимального одновременного числа запросов к сайту

8. Для стабилизации системы по расходу памяти и для ограничения числа одновременно запущенных процессов Back-end нужно установить

- MinSpareServers
+ MaxClients
- StartServers

9. Какие возможности MySQL стоит использовать для улучшения производительности?

+ отложенные транзакции для InnoDB (innodb_flush_log_at_trx_commit)
+ при использовании InnoDB обязательно конфигурировать переменные innodb_*
+ многопотоковую (multithreading) сборку MySQL

10. Статические файлы на веб-сайте это

+ компактный веб-сервер или кэширующий прокси-сервер
- обычный веб-сервер Apache с подключенным обработчиком PHP

12. При настройке Oracle желательно

+ использовать отложенные транзакции (Enhanced COMMIT) для Oracle 10g R2
+ использовать протокол IPC, если Oracle размещен на той же машине, что и веб-сервер
+ использовать постоянное соединение при правильно настроенной двухуровневой архитектуре FrontEnd/BackEnd

13. Back-end это

- обычный веб-сервер Apache, только с неустановленным обработчиком PHP
- прокси-сервер или облегченный веб-сервер без PHP
- база данных MySQL/Oracle/MSSQL
+ обычный веб-сервер Apache с установленным обработчиком PHP

14. Какой тип таблиц MySQL рекомендуется использовать для улучшения производительности при больших нагрузках?

+ InnoDB
- MyISAM

15. Время ожидания между Front-end и Back-end должно быть достаточно большим, чтобы

+ чтобы дождаться освобождения процессов Back-end, если все они заняты обработкой текущих запросов
+ дождаться завершения работы длительных запросов к Back-end
- чтобы передать всю страницу пользователю на медленных каналах

16. Если на сервере одновременно запускается много процессов веб-сервера, то возможно

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

17. Сжатие страниц модулем компрессии позволяет

- снизить нагрузку на процессоры
- ускорить работу PHP прекомпилятора и сделать работу пользователей более комфортной
- ускорить установку обновления программного продукта по технологии SiteUpdate
+ ускорить загрузку страниц пользователями сайта

18. Чтобы обеспечить передачу реального IP адреса с Front-end в Back-end, необходимо

+ встроенные библиотеки PHP для данного типа базы данных
- собственный обработчик соединений Битрикс для данного типа базы данных

20. Порядок работы Back-end

+ получает запросы от Front-end и передает готовые (сгенерированные) страницы Front-end для передачи их пользователям
- получает запросы от пользователей, обрабатывает и передает данные Front-end для передачи их пользователям
- получает запросы от Front-end и передает готовые страницы и статические файлы Front-end для передачи их пользователям
- получает запросы от Front-end и передает готовые страницы и статические файлы пользователям

21. Тип соединения с базой данных устанавливается

- в любом месте продукта конструкцией define("DBPersistent", true);
- в файле dbconn.php конструкцией define("DBPersistent", yes);
+ в файле /bitrix/php_interface/dbconn.php константой DBPersistent

22. Постоянное соединение с базой данных предпочтительнее, потому что

+ соединение к базе данных всегда открыто и тратится меньше времени и ресурсов на повторное открытие соединений
- SQL запросы исполняются быстрее
- база данных потребляет меньше оперативной памяти и больше памяти остается для кэширования данных

23. Соединение с базой данных по имени localhost позволяет

+ соединиться с базой данных без использования стека TCP/IP, что ускоряет работу
+ гарантированно соединиться с базой данных, установленной на локальной машине

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

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

Ответ содержится в повышении эффективности. Постоянные соединения полезны в том случае, если при открытии большого количества SQL-соединений возникает ощутимая нагрузка на сервер. То, насколько велика эта нагрузка, зависит от многих факторов. Например, от того, какая именно база данных используется, находится ли она на том же компьютере что и ваш веб-сервер, насколько загружена машина, на которой установлен SQL-сервер, и так далее. В случае, если затраты на установку соединения велики, постоянные соединения могут вам существенно помочь. Они позволяют дочернему процессу на протяжении всего жизненного цикла использовать одно и то же соединение вместо того, чтобы создавать его при обработке каждой страницы, которая взаимодействует с SQL-сервером. Это означает, что каждый дочерний процесс, открывший постоянное соединение, будет иметь свое собственное соединение с сервером. Например, если у вас запущено 20 дочерних процессов, которые выполнили скрипт, использовавший постоянное соединение с SQL-сервером, вы получите 20 различных соединений с SQL-сервером, по одному на каждый дочерний процесс.

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

Смотрите также fbsql_pconnect() , ibase_pconnect() , ifx_pconnect() , ingres_pconnect() , msql_pconnect() , mssql_pconnect() , mysql_pconnect() , ociplogon() , odbc_pconnect() , oci_pconnect() , pfsockopen() , pg_pconnect() и sybase_pconnect() .

Читайте также: