Вопрос или проблема
MariaDB [(none)]> show variables like '%skip_networking%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| skip_networking | OFF |
+-----------------+-------+
1 row in set (0.00 sec)
Когда я пытаюсь
mysql -uroot -p -h 192.168.0.30
Я получаю это
ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.0.30' (111 "Connection refused")
В файле
/etc/mysql/mariadb.conf.d/50-server.cnf
У меня это:
bind-address = 0.0.0.0
# skip-networking
Надеюсь, ты сможешь мне помочь.
Локальное соединение работает.
sudo netstat -ntlup | grep mysql
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 11580/mysqld
Я вижу “127.0.0.1:3306”, но не знаю, как это изменить.
Кредиты : https://stackoverflow.com/a/14779244/7499402
То, что отключено по умолчанию, это удаленный root
доступ. Если вы хотите это включить, выполните эту SQL-команду локально:
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;
FLUSH PRIVILEGES;
А потом найдите следующую строку и закомментируйте её в вашем файле my.cnf
, который обычно находится по адресу /etc/mysql/my.cnf
на системах Unix/OSX. Если это система Windows, вы можете найти её в директории установки MySQL, обычно что-то вроде C:\Program Files\MySQL\MySQL Server 5.5\
, и имя файла будет my.ini
.
Измените строку
bind-address = 127.0.0.1
на
#bind-address = 127.0.0.1
И перезапустите MySQL сервер для применения изменений.
У меня была такая же проблема, и я смог её решить, проверив эти аспекты:
Прежде всего, доступ к вашей базе данных с учетной записью, которая принимает удаленные соединения. Как упоминалось в других сообщениях, эта учетная запись должна содержать % в имени сервера вместо localhost.
Не знаю, является ли это безопасной практикой, но я думаю, что начать с этого нормально.
После этого вам следует проверить конфигурационные файлы из
- /etc/mysql
- /etc/mysql/mariadb.conf.d/
Мне пришлось сделать вывод из */etc/mysql/my.conf, потому что он включает эти строки
user@debian:/etc/mysql$ cat my.cnf
# Конфигурационный файл MariaDB
#
# Инструменты MariaDB/MySQL читают конфигурационные файлы в следующем порядке:
# 1. "/etc/mysql/mariadb.cnf" (этот файл) для установки глобальных значений по умолчанию,
# 2. "/etc/mysql/conf.d/*.cnf" для установки глобальных опций.
# 3. "/etc/mysql/mariadb.conf.d/*.cnf" для установки опций только для MariaDB.
# 4. "~/.my.cnf" для установки пользовательских опций.
[client-server]
# Импортируйте все .cnf файлы из конфигурационного каталога
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/
Дело в том, что вторая директория содержит эти файлы:
user@debian:/etc/mysql/mariadb.conf.d$ ls
50-client.cnf 50-mysql-clients.cnf 50-mysqld_safe.cnf 50-server.cnf
В которой логически, в 50-server.cnf содержатся строки, на которые ссылаются в постах, но которых больше нет в /etc/mysql/my.cnf.
Примечание: Вывод из этих команд был отредактирован для ясности ответа.
Просто закомментируйте строку bind-address и подключитесь к своей базе данных из удаленного терминала.
user@debian:/etc/mysql/mariadb.conf.d$ cat 50-server.cnf
#
# Эти группы читаются сервером MariaDB.
# Используйте это для опций, которые должны видеть только сервер (но не клиенты)
#
# Смотрите примеры серверных my.cnf файлов в /usr/share/mysql/
#
[server]
[mysqld]
# Вместо skip-networking по умолчанию сейчас прослушивает только
# localhost, что более совместимо и не менее безопасно.
#bind-address = 127.0.0.1
После этого моё удаленное соединение заработало. Надеюсь, это поможет.
Процесс mysqld
слушает на 127.0.0.1:3306
, как показано в выводе netstat
. Это объясняет, почему вы получаете ошибку connection refused
при подключении удаленно. Он принимает соединения только локально.
После проверки, что вы изменяете правильный конфигурационный файл, вам нужно перезапустить процесс mysqld.
Проблема заключается в расположении вашей конфигурации. Я не думаю, что /etc/mysql/mariadb.conf.d распознается mariadb.
Их документация, чтобы решить вашу проблему (https://mariadb.com/kb/en/mariadb/configuring-mariadb-for-remote-client-access/), предлагает вставить ваш bind-address в файл my.cnf:
* /etc/my.cnf (*nix/BSD)
* $MYSQL_HOME/my.cnf (*nix/BSD) *Примечательно /etc/mysql/my.cnf
* SYSCONFDIR/my.cnf (*nix/BSD)
* DATADIR\my.ini (Windows)
Я подозреваю, что вы сможете добавить вашу конфигурацию bind-address
в /etc/mysql/my.cnf.local, и это заставит mariadb слушать на 0.0.0.0.
Исходя из вашего вывода netstat, я думаю, что ваш дополнительный конфигурационный файл просто не распознается.
Для AWS Lightsail вы найдете конфигурационный файл здесь:
/opt/bitnami/mariadb/conf/my.cnf
Измените строку
bind-address = 127.0.0.1
на
#bind-address = 127.0.0.1
Примечание: Здесь вы позволяете любому IP-адресу получить удаленный доступ к вашей БД, если они получат данные пользователя БД. Убедитесь, что вы защищаете это с помощью группы безопасности или необходимого механизма безопасности.
Ответ или решение
Если у вас возникают проблемы с удалённым подключением к MariaDB, вам следует рассмотреть несколько аспектов конфигурации и безопасности. Ниже приведены рекомендации, которые помогут вам устранить ошибку подключения: ERROR 2003 (HY000): Can’t connect to MySQL server on ‘192.168.0.30’ (111 "Connection refused").
1. Параметр bind-address
Сначала проверьте, как настроен параметр bind-address
в вашем конфигурационном файле MariaDB. Судя по вашему описанию файловой системы, у вас установлен:
bind-address = 0.0.0.0
Этот параметр указывает серверу прослушивать подключения на всех интерфейсах. Это правильная настройка. Однако важно убедиться, что вы редактируете правильный конфигурационный файл. Обычно конфигурационные файлы находятся в следующих директориях:
/etc/mysql/my.cnf
/etc/mysql/mariadb.conf.d/50-server.cnf
Убедитесь, что вы редактируете именно тот файл, который использует ваш экземпляр MariaDB.
2. Проверка состояния службы MariaDB
Убедитесь, что служба MariaDB запущена и прослушивает правильный сетевой интерфейс. Вывели вы вывод команды:
sudo netstat -ntlp | grep mysql
Вы увидите:
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 11580/mysqld
Это говорит о том, что сервер MariaDB слушает только на 127.0.0.1
(localhost), и поэтому удалённое подключение действительно будет вызывать ошибку.
3. Изменение конфигурации и перезапуск сервера
Если вы изменили значение bind-address
на 0.0.0.0
и всё равно сталкиваетесь с проблемами, попробуйте следующие шаги:
- Убедитесь, что строка
#skip-networking
закомментирована, чтобы избежать конфликта. - Перезапустите службу MariaDB, чтобы изменения вступили в силу:
sudo systemctl restart mariadb
Или если используете другую систему управления службами:
sudo service mariadb restart
4. Проверка прав доступа пользователя
По умолчанию локальному пользователю (например, root) могут быть разрешены лишь локальные подключения. Вам потребуется удостовериться, что пользователь, с которым вы пытаетесь подключиться, имеет права на удалённое подключение. Выполните следующую команду в терминале, чтобы дать пользователю root
доступ к удаленному подключению:
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;
FLUSH PRIVILEGES;
Важно: Использование ‘%’ позволяет любому пользователю подключаться из любой сети. Рекомендуется ограничить доступ определенными IP-адресами для повышения безопасности.
5. Проверка брандмауэра
Убедитесь, что ваш брандмауэр (если он настроен) разрешает входящие соединения на порт 3306. Например, для iptables
это можно сделать так:
sudo iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
Если вы используете ufw
, команду можно выполнить так:
sudo ufw allow 3306/tcp
6. Проверка настроек сети
Если ваши попытки подключения по-прежнему не удаются, убедитесь, что удаленная машина действительно может достичь сервера. Используйте команду ping
или telnet
для проверки соединений:
ping 192.168.0.30
telnet 192.168.0.30 3306
Если ping
успешен, но telnet
возвращает ошибку, причина может заключаться в конфигурации брандмауэра или сетевых маршрутах.
Заключение
Следуя приведённым шагам, вы сможете устранить проблему подключения к MariaDB с удалённого хоста. Будьте внимательны к вопросам безопасности при настройке удалённого доступа и убедитесь, что ваши действия соответствуют лучшим практикам безопасности базы данных.