ОШИБКА 2002 (HY000): Не удается подключиться к локальному серверу MySQL через сокет ‘/var/run/mysqld/mysqld.sock’ (2)

Вопрос или проблема

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 в контейнере.

Если это так:

  1. войдите в контейнер mysql, чтобы получить командную строку bash

  2. выполните ‘ln -s /var/lib/mysql/mysql.sock /var/run/mysqld/mysqld.sock’

  3. затем попробуйте выполнить 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-кластере.

Причины ошибки и способы её устранения

  1. Сервер MySQL не запущен:

    • Убедитесь, что сервер MySQL запущен внутри вашего Pod. Используйте команду kubectl logs <mysql-pod-name> для проверки журналов контейнера MySQL на наличие ошибок или причин отказа в запуске.
  2. Сокет MySQL отсутствует или размещен в другом месте:

    • По умолчанию MySQL ожидает, что сокет будет находиться в /var/run/mysqld/mysqld.sock. Однако в зависимости от конфигурации ваш сокет может располагаться в другом месте, например, в /var/lib/mysql/mysql.sock.
    • Выполните команду kubectl exec -it <mysql-pod-name> -- ls /var/lib/mysql для проверки, где реально расположен сокет.
  3. Создание символьной ссылки для сокета:

    • Если сокет действительно расположен в другого местоположении (например, /var/lib/mysql/mysql.sock), создайте символическую ссылку:
      kubectl exec -it <mysql-pod-name> -- ln -s /var/lib/mysql/mysql.sock /var/run/mysqld/mysqld.sock
  4. Проблемы с конфигурацией my.cnf:

    • Убедитесь, что ваша конфигурация определяет правильный путь к сокету. Это можно уточнить в файлах конфигурации внутри Pod: /etc/mysql/my.cnf, /etc/mysql/conf.d/, /etc/mysql/mysql.conf.d/.
    • Отредактируйте настройки, если пути не совпадают. Например, измените параметр socket на фактическое местоположение сокета.
  5. Проблемы с правами доступа:

    • Проверьте права доступа к файлам сокета: они должны соответствовать пользователю и группе MySQL. Используйте команду ls -l /var/run/mysqld/ и удостоверьтесь, что права доступа корректны.
  6. Неправильные переменные окружения:

    • Проверьте правильность настройки переменных среды, особенно MYSQL_ROOT_PASSWORD. Сделайте это с помощью kubectl describe secret mysql-secret.
  7. Предложения по тестированию и отладке:

    • После выполнения вышеуказанных шагов, попробуйте снова войти в контейнер и выполнить команду mysql -p, используя пароль 11111.
    • Если проблема сохраняется, перезапустите Pod MySQL: kubectl delete pod <mysql-pod-name>.

Заключение

В случае использования сетевых контейнеров и Kubernetes, ошибки подключения к MySQL могут быть вызваны, как неправильной настройкой, так и ошибками в конфигурации или инициализации. Важно внимательно следить за журналами и настройками, чтобы понять коренную причину проблемы. Для получения более подробной помощи, рассмотрите возможность использования различных инструментов мониторинга kube-кластера для диагностирования проблем как с сетью, так и с ресурсами.

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

Оцените материал
Добавить комментарий

Капча загружается...