Какая БД не помрет в облачном диске?

Question

[Kapibara]

Есть у меня несколько локально хостящахся веб-сайтов для собственных нужд. И есть желание в любой момент иметь возможность в них что-то доработать.
Частично решил проблему переносом всего необходимого (файлы сайтов, ide, прочие инструменты) в облачный диск. И он отлично все синхронизирует между устройствами, и даже если я заберу ноут в место где нет интернета - на нем уже будут актуальные файлы. Единственное что не выживает в этом случае - база данных. Сейчас у меня все на MySQL, и постоянным перезаписыванием, перетеранием я пару раз получал мертвую БД.
Есть что посоветовать, что переживет такое непотребное обращение с собой? Поменять конфиги MySQL? Сменить движок БД?
Важно, чтобы была возможность работать с актуальной БД оффлайн.
Важно что может быть следующий сценарий:
На рабочем компе запущен сервер БД, он пишет изменения, они синхронизируются облачным диском с ноутом и другими утсройствами.
Не прекращая работу сервера БД на рабочем компе ноут увозится туда, где нет интернета. На ноуте запускается сервер БД, в базу пишутся новые изменения.
Ноут возвращается домой, изменения синхронизируются с рабочей машиной (где так и не погасал сервер БД).

Comments

[mayton2019]

Очень сложные какие-то у тебя условия. Но мне кажется что твоя проблема просто решается бэкапом.
Горячим или холодным. Кумулятивным. Инкрементальным. Неважно. Вот.
Для бэкапов свойственна eventual consistency, вот. Значит
когда-то ее состояние достигнет желаемого во времени. Вобщем я не вижу проблем.

[Akina]

может быть следующий сценарий

Всё описанное очень похоже на мастер-мастер репликацию.

Но подобный режим неминуемо будет создавать конфликты (одна и та же запись по-разному изменена на двух устройствах), требующие ручного "улаживания". Репликация же будет тупо херить более старые изменения. MySQL не имеет средств, позволяющих полноценно реализовать такой режим работы с правильным "разведением" конфликтов в автоматическом режиме. Однако если Вы будет избегать возникновения такого рода конфликтов, не вижу особой проблемы.

Answer 1

[Stalker_RED]

Если бд копируется просто как "папка с файлами", то да, она может сломаться, если она копируется в "неподходящий момент". Частично от этого можно спастись журналированием, но это не точно.

Чтобы не ломалась надо либо корректно останавливать ее перед копированием, либо использовать встроенные в БД средства репликации или синхронизации.

Важно, чтобы была возможность работать с актуальной БД оффлайн.

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

В какой-то момент может оказаться, что вам проще не изобретать велосипед, а применить какое-то проверенное взрослое решение - код в гите, докер-контейнеры, автоматический деплой, миграции для БД.
Порог входа конечно повыше чем просто забросить папку в дропбокс, но зато эти пункты уже можно вписывать в резюме :)