Как поднять контейнер mysql через wsl?

Question

[KoRNeT46RuS]

История такая, что работам с проектом под линуксом. Ради интереса решил попробовать поднять проект на Windows через wsl. Поставил докер и все остальное. Поднимаются все контейнеры кроме mysql
Логи пишут:

2026-03-21T11:05:46.313797Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2026-03-21T11:05:46.314010Z 0 [ERROR] Aborting

Настройки контейнера:

mysql:
    image: mysql:5.7
    restart: always
    command: --sql-mode="" --secure-file-priv=""
    environment:
      MYSQL_ROOT_PASSWORD: '${MYSQL_PASSWORD}'
      MYSQL_DATABASE: keaz
    volumes:
      - ./data/docker-files/mysql-db:/var/lib/mysql
      - ./data/docker-files/mysql-export:/tmp/mysql-export
      - /etc/localtime:/etc/localtime/:ro
    healthcheck:
      test: [ "CMD", "mysqladmin", "ping", "-p${MYSQL_PASSWORD}" ]
      retries: 3
      timeout: 5s
    ports:
      - 3306:3306

Пробовал rm -rf /var/lib/mysql/*
Пробовал ковычки в настройках контейнера.
Пробовал права больше давать на папку.
Нефига не помогает. Если кто сталкивался, подскажите, как решить проблему, я уже честно говоря хз как быть

Comments

[сергей кузьмин]

разберитесь с volumes

[KoRNeT46RuS]

сергей кузьмин, странно если закомментить
- ./data/docker-files/mysql-db:/var/lib/mysql
другая проблема
2026-03-21T15:51:47.426605Z 4 [Note] Aborted connection 4 to db: 'database' user: 'root' host: '10.103.0.2' (Got an error reading communication packets)

Но опять же почему не догоняю

[shurshur]

KoRNeT46RuS, докер можно отлаживать, но это может быть довольно сложно для непосвящённых.

Можно попробовать переопределить entrypoint и/или command контейнера на /bin/sh и цикл, чтобы он запускался без реального mysqld, затем с помощью docker exec зайти внутрь и изучить этот самый /var/lib/mysql.

Можно изучить контейнер с помощью docker inspect, проверив, что реально там было создано и откуда смонтированы конкретные каталоги.

Можно изучить образ контейнера также с помощью docker inspect.

Если не указать volume, а он декларирован в используемом образе, то volume всё равно будет использоваться, только создан анонимный в хранилище volume докера (см. docker volume ls). Это, кстати, довольно проблемное архитектурное решение в docker: если специально не следить, то контейнеры могут создавать неявным образом volume без внятных названий, которые занимают место и могут оставаться от каких-нить старых контейнеров. А ещё можно внезапно обнаружить, что если прогнать docker system prune или docker volume prune, то могут быть удалены живые данные реально нужного контейнера. Поэтому я придерживаюсь мнения, что следует явно прокидывать все volume и лучше прям из каталога проекта, чтобы их наличие было очевидным, назначение понятным, занимаемое место более прозрачным.

Но в случае с Windows ещё и не стоит использовать volume с ntfs, лучше в нативной линуксовой fs. Мало ли какие проблемы вылезут с правами или другими несовместимостями.

Насчёт проблемы коннекта к базе - я бы посоветовал попробовать зайти в контейнер (docker exec) и попробовть подключиться штатным mysql изнутри. Только вместо коннекта к хосту localhost следует явно указать 127.0.0.1. Потому что localhost в mysql - это мнемоническое название способа подключения через unix-сокет, не через inet-сокет на 127.0.0.1.

Также глянуть в логах mysql, возможно там будет какая-то информция о проблеме.

Вообще, подобного рода проблемы коннекта к базе могут быть вызваны сильной несовместимостью клиентской версии с серверной. Например, если взять древний php 5.x с дреней же версией php-mysql и попытаться подключаться к современному mysql - ничего хорошего не выйдет.

Answer 1

[Пума Тайланд]

rm -rf /var/lib/mysql/* внутри контейнера тут не поможет, потому что /var/lib/mysql у тебя примонтирован с хоста и для --initialize каталог должен быть полностью пустым. Если данные не нужны, удали именно хостовую папку:

rm -rf ./data/docker-files/mysql-db && mkdir ./data/docker-files/mysql-db

и пересоздай контейнер. На будущее для MySQL под WSL проще использовать именованный volume вместо bind mount — с ними таких проблем нет.

Comments

[KoRNeT46RuS]

не прокатило. хз

[Пума Тайланд]

Видимо WSL2 с bind mount не дружит. Попробуй named volume: mysql-data:/var/lib/mysql вместо пути, и volumes: mysql-data: в конце compose.

[KoRNeT46RuS]

Пума Тайланд, не прикол другой. Короче wsl по умолчанию открывает в "Пользователях" винды каталог, я просто перенес проект в home именно от корня подсистемы и все заработало

[Пума Тайланд]

KoRNeT46RuS, ну да, в home это ext4 — mysql с NTFS mount'ом работает через раз.

Answer 2

[VoidVolker]

Просто поставьте сразу нормальный VirtualBox и не тратьте своё время на решение проблем этого огрызка. Далее ставите полноценный дебиан, а в нём уже одной командой легко ставите mariadb и всё сразу работает без проблем.

sudo apt-get install mariadb-server mariadb-client 

Если так сильно хочется докер — то он точно так же легко ставится и без проблем используется.

Comments

[Adamos]

Лучше дуалбут, чтобы потом легче было выкинуть ненужную винду ;)

[VoidVolker]

Adamos, ага, и с любым рандомным обновлением получить кирпич и пытаться разобраться и восстановить. Что может пойти не так? Так что если не нужна графика — виртуалки самое то.

[KoRNeT46RuS]

да не вариант. Просто наткнулся на статью про использование wsl и хотелось поднять проект, который заточен под линукс на винде. Чтобы не делать отдельный ноутбук с линуксом. Но походу не судьба такого решения

[VoidVolker]

KoRNeT46RuS,

да не вариант. Просто наткнулся на статью про использование wsl и хотелось поднять проект, который заточен под линукс на винде. Чтобы не делать отдельный ноутбук с линуксом. Но походу не судьба такого решения

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

[Adamos]

VoidVolker, да, наверное, вы правы. Я-то выкинул с машины винду еще до того, как ее обновления стали ломать чужие загрузчики, современные реалии не учел.

[VoidVolker]

Adamos, нынче и в линуксе так-то тоже обновления прекрасно умеют ломать мультизагрузу, да (убунта такая убунта). Раньше-то был Acronis Boot Loader, что великолепно разруливал мультизагрузку.

[Adamos]

VoidVolker, даже не слышал про такое.
Хотя и сам пользуюсь Убунтой лет пятнадцать, и у подопечных она живет без переустановки с 14.04 до 24.04.
А уж Дебиан на серверах и вовсе сломать можно только с большим желанием это сделать.

[VoidVolker]

Adamos, ну вот, а мне попался такой случай у знакомого, когда убунта обновилась и поломала двойной загрузчик (вторая была винда). В убунте частенько бывают косяки, когда обновление что-нибудь да сломает, а обновление дистрибутива вообще лотерея (ну или мне просто так везло). А дебиан - да, топ.

[Adamos]

VoidVolker, я слышал рассказы о косячной убунте - исключительно от людей, которые ставят себе не-LTS версии по привычке гнаться за "свежаком".
Сам в тестеры к Канониклу не записывался, мне система нужна для работы. Проблемы при обновлении - разве что криво вставшие видео-дрова, у которых рассинхронизировалась версия ядра дров и системы. Но и такого давненько не припомню. Впрочем, геймерские ноуты, например - не моя сфера. Да и не для Линуксов они, конечно.