- Вопрос или проблема
- EDIT: Следующее описание — это мой первоначальный вопрос, но пока я не решил проблему, подумал, что, возможно, следует изменить настройки внутри созданного POD mysql вместо конфигурационных файлов mysql на моем локальном компьютере. Но когда я пытаюсь внести какие-либо изменения внутри POD mysql, я получаю ошибки command not found!
- Ответ или решение
- Причины ошибки и способы её устранения
- Заключение
Вопрос или проблема
EDIT
: Следующее описание — это мой первоначальный вопрос, но пока я не решил проблему, подумал, что, возможно, следует изменить настройки внутри созданного POD mysql
вместо конфигурационных файлов mysql
на моем локальном компьютере. Но когда я пытаюсь внести какие-либо изменения внутри POD mysql
, я получаю ошибки command not found
!
Я пытался развернуть образ mysql
на моем локальном Kubernetes
, который работает на кластере Kind
, следующим образом:
Я попробовал kubectl create secret generic mysql-secret --from-literal MYSQL_KEY=11111
и создал mysql-server
следующим образом:
mysql-secret Opaque 1 3d21h
Это файл mysql-pv.yaml
:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 20Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
Я выполнил kubectl apply -f mysql-pv.yaml
, и он был успешно создан.
Это файл `mysql-depl.yaml`:
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
containers:
- image: mysql
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: MYSQL_KEY
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
---
apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
ports:
- port: 3306
selector:
app: mysql
clusterIP: None
Я выполнил kubectl apply -f mysql-depl.yaml
, и оно было успешно создано.
Но когда я хочу запустить mysql
внутри соответствующего ему pod, используя команды kubectl exec -it <mysql-pod-name> sh
, а затем mysql -p
, он запрашивает пароль, и после ввода пароля (11111
) я получаю:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
Это содержимое /etc/mysql/my.cnf
:
#
# Конфигурационный файл сервера базы данных MySQL.
#
# Вы можете скопировать это в один из:
# - "/etc/mysql/my.cnf" для установки глобальных опций,
# - "~/.my.cnf" для установки специфичных для пользователя опций.
#
# Можно использовать все длинные опции, которые поддерживает программа.
# Запустите программу с --help, чтобы получить список доступных опций, и с
# --print-defaults, чтобы увидеть, какие из них она действительно поймет и использует.
#
# Для объяснений смотрите
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
#
# * ВАЖНО: Дополнительные настройки, которые могут переопределить эти настройки!
# Файлы должны заканчиваться на '.cnf', в противном случае они будут проигнорированы.
#
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
Внутри /etc/mysql/conf.d/
есть два файла. mysql.cnf
выглядит следующим образом:
[mysql]
socket = /var/run/mysqld/mysqld.sock
[client]
socket = /var/run/mysqld/mysqld.sock
И mysqldump.cnf
выглядит следующим образом:
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
Также внутри каталога /etc/mysql/mysql.conf.d/
есть два файла, mysql.cnf
:
#
# Конфигурационный файл клиента базы данных MySQL
#
# Ссылка на https://dev.mysql.com/doc/refman/en/mysql-command-options.html
[mysql]
socket = /var/run/mysqld/mysqld.sock
[client]
socket = /var/run/mysqld/mysqld.sock
И mysqld.cnf
:
#
# Конфигурационный файл сервера базы данных MySQL.
#
# Можно использовать все длинные опции, которые поддерживает программа.
# Запустите программу с --help, чтобы получить список доступных опций, и с
# --print-defaults, чтобы увидеть, какие из них она действительно поймет и использует.
#
# Для объяснений смотрите
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html
# Здесь записи для некоторых конкретных программ
# Следующие значения предположительно будут использоваться, если у вас есть как минимум 32M оперативной памяти
[mysqld]
#
# * Базовые настройки
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
datadir = /var/lib/mysql
# Если MySQL работает как репликация-слейв, это должно быть
# изменено. Смотрите https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_tmpdir
# tmpdir = /tmp
#
# Вместо убирания сетевых подключений, сейчас мы по умолчанию слушаем только на
# localhost, что более совместимо и не менее безопасно.
bind-address = 127.0.0.1
mysqlx-bind-address = 127.0.0.1
#
# * Тонкая настройка
#
key_buffer_size = 16M
# max_allowed_packet = 64M
# thread_stack = 256K
# thread_cache_size = -1
# Это заменяет сценарий запуска и проверяет таблицы MyISAM, если это необходимо
# в первый раз, когда они используются
myisam-recover-options = BACKUP
# max_connections = 151
# table_open_cache = 4000
#
# * Логирование и репликация
#
# Оба местоположения ротации с использованием cronjob.
#
# Логировать все запросы
# Обратите внимание, что этот тип логов убивает производительность.
# general_log_file = /var/log/mysql/query.log
# general_log = 1
#
# Лог ошибок - должно быть очень мало записей.
#
log_error = /var/log/mysql/error.log
#
# Здесь вы способны видеть запросы с особенно длительными временными задержками
# slow_query_log = 1
# slow_query_log_file = /var/log/mysql/mysql-slow.log
# long_query_time = 2
# log-queries-not-using-indexes
#
# Следующее может использоваться как легкий способ воспроизведения резервных копий логов или для репликации.
# Заметьте: если вы настраиваете репликацию-слейв, смотрите README.Debian для
# других настроек, которые могут потребоваться изменить.
# server-id = 1
# log_bin = /var/log/mysql/mysql-bin.log
# binlog_expire_logs_seconds = 2592000
max_binlog_size = 100M
# binlog_do_db = include_database_name
# binlog_ignore_db = include_database_name
Кроме того, у меня есть следующие файлы в /var/run/mysqld/
:
mysqld.pid mysqld.sock mysqld.sock.lock mysqlx.sock mysqlx.sock.lock
Я думаю, что вы забыли переменную окружения пароля для контейнера mysql. Пожалуйста, еще раз проверьте этот шаг.
Эта ошибка может возникнуть, если символическая ссылка сломана между файлом сокета (mysql.sock) на физическом хранилище и /var/run/mysqld/mysqld.sock в контейнере.
Ваше физическое хранилище смонтировано в /var/lib/mysql, поэтому вы найдете файл mysql.sock в /var/lib/mysql/mysql.sock в контейнере.
Если это так:
-
войдите в контейнер mysql, чтобы получить командную строку bash
-
выполните ‘ln -s /var/lib/mysql/mysql.sock /var/run/mysqld/mysqld.sock’
-
затем попробуйте выполнить mysql -u -p …и т.д. для входа
Возможно, вам придется выполнить ‘flush hosts’, если ваш mysql workbench по-прежнему показывает ошибки.
Ответ или решение
Ошибка "ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)" указывает на проблему с подключением к серверу MySQL через сокет. Эта проблема может возникать по нескольким причинам, особенно в контексте использования контейнеризированной среды, такой как Kubernetes, на Kind-кластере.
Причины ошибки и способы её устранения
-
Сервер MySQL не запущен:
- Убедитесь, что сервер MySQL запущен внутри вашего Pod. Используйте команду
kubectl logs <mysql-pod-name>
для проверки журналов контейнера MySQL на наличие ошибок или причин отказа в запуске.
- Убедитесь, что сервер MySQL запущен внутри вашего Pod. Используйте команду
-
Сокет MySQL отсутствует или размещен в другом месте:
- По умолчанию MySQL ожидает, что сокет будет находиться в
/var/run/mysqld/mysqld.sock
. Однако в зависимости от конфигурации ваш сокет может располагаться в другом месте, например, в/var/lib/mysql/mysql.sock
. - Выполните команду
kubectl exec -it <mysql-pod-name> -- ls /var/lib/mysql
для проверки, где реально расположен сокет.
- По умолчанию MySQL ожидает, что сокет будет находиться в
-
Создание символьной ссылки для сокета:
- Если сокет действительно расположен в другого местоположении (например,
/var/lib/mysql/mysql.sock
), создайте символическую ссылку:kubectl exec -it <mysql-pod-name> -- ln -s /var/lib/mysql/mysql.sock /var/run/mysqld/mysqld.sock
- Если сокет действительно расположен в другого местоположении (например,
-
Проблемы с конфигурацией my.cnf:
- Убедитесь, что ваша конфигурация определяет правильный путь к сокету. Это можно уточнить в файлах конфигурации внутри Pod:
/etc/mysql/my.cnf
,/etc/mysql/conf.d/
,/etc/mysql/mysql.conf.d/
. - Отредактируйте настройки, если пути не совпадают. Например, измените параметр
socket
на фактическое местоположение сокета.
- Убедитесь, что ваша конфигурация определяет правильный путь к сокету. Это можно уточнить в файлах конфигурации внутри Pod:
-
Проблемы с правами доступа:
- Проверьте права доступа к файлам сокета: они должны соответствовать пользователю и группе MySQL. Используйте команду
ls -l /var/run/mysqld/
и удостоверьтесь, что права доступа корректны.
- Проверьте права доступа к файлам сокета: они должны соответствовать пользователю и группе MySQL. Используйте команду
-
Неправильные переменные окружения:
- Проверьте правильность настройки переменных среды, особенно
MYSQL_ROOT_PASSWORD
. Сделайте это с помощьюkubectl describe secret mysql-secret
.
- Проверьте правильность настройки переменных среды, особенно
-
Предложения по тестированию и отладке:
- После выполнения вышеуказанных шагов, попробуйте снова войти в контейнер и выполнить команду
mysql -p
, используя пароль11111
. - Если проблема сохраняется, перезапустите Pod MySQL:
kubectl delete pod <mysql-pod-name>
.
- После выполнения вышеуказанных шагов, попробуйте снова войти в контейнер и выполнить команду
Заключение
В случае использования сетевых контейнеров и Kubernetes, ошибки подключения к MySQL могут быть вызваны, как неправильной настройкой, так и ошибками в конфигурации или инициализации. Важно внимательно следить за журналами и настройками, чтобы понять коренную причину проблемы. Для получения более подробной помощи, рассмотрите возможность использования различных инструментов мониторинга kube-кластера для диагностирования проблем как с сетью, так и с ресурсами.
Это руководство поможет эффективно разобраться с проблемой, следуя шагам по устранению неполадок и проверкам конфигурации. Подробный подход и внимание к деталям позволят быстро устранить любые возникшие ошибки.