artydev 13 янв в 13:56

Marzban: миграция с sqlite3 на MySQL

Простой

3 мин

Информационная безопасность*Программирование*MySQL*Сетевые технологии*

Туториал

-8

Комментарии 17

badangel 13 янв в 14:24

Я так пешком стал ходить, когда в автомобиле внезапно кончился бензин /s

MonkAlex 13 янв в 14:28

А бэкапы на sqlite делать не хотелось, зато после перехода начали делать на mysql? =)

artydev 13 янв в 14:33

Проблема в актуальности, бэкапы делались изначалось раз в сутки, после первого падения базы - стал делать их каждые 30 минут, но это все равно некотрая дельта потерь при восстановлении.

Проблема простая: откуда взять информацию за последние 30 минут?

MonkAlex 13 янв в 14:34

mysql как то решит эту проблему? Я не в курсе, в мелких личных проектах использую sqlite и тоже где то раз в сутки бэкаплю

artydev 13 янв в 14:45

Тоже использую sqlite в личных проектах и никаких проблем нет, тема поста скорее решает проблему конкретного сервиса/продукта (marzban - панель), в котром непонятное стечение абстоятельств приводит к повреждению файла (поймать ошибку не удалось)

am_i_dead 13 янв в 15:59

причина в том, что в sqlite данные повреждаются при многопоточной записи, а marzban как раз работает в многопоток и игнорирует механизм защиты данных, чтобы работало быстрее

connect_args={"check_same_thread": False}

MonkAlex 13 янв в 16:49

А по ссылке из статьи https://www.sqlite.org/faq.html#q21 заявляется что нельзя повредить файл штатной работой

Это какая то нештатная возможность питоновской либы?

UPD: похоже что marzban использует sqlalchemy, а у того поведение по умолчанию check_same_thread=False, что может быть важно для питоновской обвязки. За питоном где то есть ещё sqlite в каком-то виде, который в теории таки безопасен. Я запутался, кто тут что делает не так, но выглядит странно =)

am_i_dead 23 янв в 09:26

по дефолту в sqlalchemy check_same_thread=True, загуглил даже чтобы лишний раз убедиться, на хабр q/a даже есть вопрос, связанный с этой опцией, там как раз доступно описано, зачем она нужна и почему sqlite может корраптится если ее отключать. Marzban создает подключение просто по database_url и этому параметру, не используя пул соеденений, поэтому при достаточной нагрузке база может повредиться.

MonkAlex 23 янв в 10:18

https://gozargah.github.io/marzban/ru/docs/configuration ссылается на https://docs.sqlalchemy.org/en/20/core/engines.html#database-urls, те в свою очередь ссылаются на https://docs.sqlalchemy.org/en/20/dialects/sqlite.html а там написано:

The thread prohibition is known as “check same thread” and may be controlled using the sqlite3 parameter check_same_thread, which will disable or enable this check. SQLAlchemy’s default behavior here is to set check_same_thread to False automatically whenever a file-based database is in use, to establish compatibility with the default pool class QueuePool.
When a file-based database is specified, the dialect will use QueuePool as the source of connections. at the same time, the check_same_thread flag is set to False by default unless overridden.

Я не пользовался ничем из этого, просто поискал документацию. И да, информация с qa хабра для меня недостаточна, чтобы верить что это способ испортить БД. Было бы странно и слишком легко.

andreymal 13 янв в 18:09

Это не должно приводить к повреждению, если sqlalchemy использует пул соединений

am_i_dead 23 янв в 09:24

пул используется если база не sqlite

andreymal 23 янв в 13:50

Ну не знаю, в документации прямым текстом написано что используется даже для sqlite, и в коде Marzban я не вижу чтобы пул отключался

andreymal 13 янв в 14:39

после первого падения базы

То есть падение далеко не единственное? Кажется, вам надо не на mysql переходить, а проблемы с сервером чинить...

Использую sqlite3 в личных проектах разной степени нагруженности уже лет десять — ни разу ничего не падало

artydev 13 янв в 14:50

Сложно чинить проблему стороннего сервиса (marzban - панель), поэтому было принято решение о переходе на другую СУБД, с которой, по опыту сообщества - таких проблем нет