LINUX.ORG.RU

Быстро синхронизировать БД MySQL между 2-мя серверами?

 


0

1

Как лучше организовать процесс доработки сайта с БД MySQL ?

Есть 2 виртуалки:

  1. на одной прод-версия сайта + на ней же БД.
  2. Вторая виртуалка — просто копия первой: дев-версия.

То есть, сайт целиком на одной машине: и база, и сам код сайта.

Размер базы на текущий момент 2 Гб.

Разработчики на дев-версии могут как-то дорабатывать БД, менять её. Как потом быстро и безопасно внести их доработки в прод-версию БД?

Или, допустим, надо взять свежий вариант БД с прода для сайта дев. Как сделать это быстрее всего?

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

В общем, надеюсь, мой вопрос более-менее понятен.

Разработчики на дев-версии могут как-то дорабатывать БД, менять её. Как потом быстро и безопасно внести их доработки в прод-версию БД?

Есть такое понятие как «миграция».

При нормальной разработке изменения в схеме бд заносятся в файлик и комиттится в твою любимую систему версионирования (git, svn, cvs, mercurial, etc). Если дополнительно требуется произвести изменения в данных бд - туда же. Все это в одной транзакции, чтобы если кто-то сходил под себя, то на откат наделанного уходило 3 секунды машинного времени, а не 72 часа твоего.

Тогда тебе останется спулить этот файлик на проде и исполнить запросики из этого файлика (или даже нарисовать автоматизацию чтобы роботы все делали за тебя).

slowpony ★★★★★
()

Почитай что такое миграции и как в вашем фремворке это делается, вот пример для PHP и Doctrine https://www.doctrine-project.org/projects/doctrine-migrations/en/3.8/reference/managing-migrations.html#managing-migrations

Или, допустим, надо взять свежий вариант БД с прода для сайта дев.

ну в общем случае так делать не стоит но я понимаю что так «проще». В целом наверно не сложно написать скрипт кторый подтянет данные табличек нужных с прода.

Мы делали это так:

  • Собираешь раз недельку слепок продовой базы маскируя приватные данные и разваорачиваешь ее на деваке (прошлое в мусор конечно).

  • Накатываешь миграции актуальные для дева.

  • Накатываешь скрипт с данными нужными для дева.

Noob_Linux ★★★★
()
Ответ на: комментарий от truebin

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

Noob_Linux ★★★★
()

как выше написали, вам нужно внедрить миграции

а для простоты работы с продуктовой базой, настроить на dev окружение репликацию, и уже с нее «нарезать» базы данных для разработчиков, это уменьшит риски

gagarin0
()
Ответ на: комментарий от gagarin0

А, я правильно понимаю, что можно на дев-машине настроить репликацию БД с прод-машиной.

Прод-машина — master Дев-машина — slave.

И можно будет на деве прям работать с реплицированной БД, так?

Пока начинаю только работать с базами данных.

truebin
() автор топика
Ответ на: комментарий от truebin

можно будет на деве прям работать с реплицированной БД, так?

Нет не так.

Если ты начнешь работать с той самой базой куда реплицируешь прод то репликация отвалится нафиг.

Ты её держишь чтобы при создании бакапа для разрабов прод не стопать.

ya-betmen ★★★★★
()
Ответ на: комментарий от truebin

Это хорошо получается, пока высокой нагрузки нет. Бэкапы, надеюсь, делаешь во время самой низкой нагрузки на БД?

zimniy
()
Последнее исправление: zimniy (всего исправлений: 1)

Судя по твоему описанию, процесс разработки – какой-то лютый бардак. Как оно у вас организовано? Система контроля версий есть? Или код по FTP гоняете туда-сюда?

zimniy
()
Последнее исправление: zimniy (всего исправлений: 1)
Ответ на: комментарий от zimniy

Неа. Просто ежечасно запускается скрипт, который дёргает mysqldump.

Ок. Вы не могли бы порекомендовать хорошую книгу по mysql для админа СУБД?

В статьях по mysqldump я видел только параметры этой утилиты. Хм. И даже не думал, что она может привести БД к «несогласованному» состоянию.

truebin
() автор топика
Ответ на: комментарий от zimniy

Разработка — да, бардак. Конкретно на этом проекте только внедряется система контроля версий. Увы.

Ну, что ж. Я просто хотел бы немного прояснить ситуацию для себя. У меня в распоряжении база данных.

truebin
() автор топика
Ответ на: комментарий от truebin

Неа. Просто ежечасно запускается скрипт, который дёргает mysqldump.

Такое себе, но «окэй». Оно у тебя точно всё нужное бэкапит?

Ок. Вы не могли бы порекомендовать хорошую книгу по mysql для админа СУБД?

Я – не могу. Немного не мой профиль. Но, думаю, кто-то подскажет.

…даже не думал, что она может привести БД к «несогласованному» состоянию.

Скорее, пока бэкап не снимется, у тебя может глючить сайт. БД оно, емнип, не портит.

zimniy
()

В общем случае никак.

Если кто-то там меняет базу руками, то ему же придётся аналогичные действия повторить и на проде. Минус в том, что в случае инцидента неясно что конкретно менялось. Выше посоветовали миграции, это как раз автоматизированный запуск всего что нужно поменять, записанный в файле.

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

neumond
()
Ответ на: комментарий от truebin

Конкретно на этом проекте только внедряется система контроля версий.

Если можешь – меняй проект. Иначе наплачешься.

У меня в распоряжении база данных.

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

zimniy
()
Ответ на: комментарий от ya-betmen

Хорошие вопросы. Вы имеете в виду, сколько запросов идёт к базе сейчас за единицу времени? А хз, пока не знаю, как промониторить.

Вот вы идею подогнали про мониторинг кол-ва запросов к БД.

truebin
() автор топика
Ответ на: комментарий от neumond

Выше посоветовали миграции, это как раз автоматизированный запуск всего что нужно поменять, записанный в файле.

НЯП, это единственный способ не делать голову с БД в процессе разаработки.

Быстрее всего разрабатывать без дева. Сразу в прод.

Не учи человека плохому, пожалуйста.

zimniy
()

Нужен третий сервер. staging. На него у разработчиков доступа не будет. Все обновления перед продом накатываются туда, чтобы удостовериться, что они нормально работают. Также на нём постоянно тестируются скрипты восстановления из бэкапа, чтобы убедиться, что они работают.

Разработчики на дев-версии могут как-то дорабатывать БД, менять её. Как потом быстро и безопасно внести их доработки в прод-версию БД?

Все доработки должны быть оформлены в виде одного или нескольких файлов с SQL командами, которые меняют структуру БД. Это называется сценарии миграции БД. Есть инструменты вроде flyway для частичной автоматизации этого процесса, но можно и руками делать.

Или, допустим, надо взять свежий вариант БД с прода для сайта дев. Как сделать это быстрее всего?

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

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

Так нельзя делать.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от truebin

Каждый раз делается полный дапм БД

Всякие триггеры, хранимые процедуры и тому подобное – бэкапятся?

Ты дамп разворачивать и сравнивать с исходной БД пробовал? Бэкапы, которые не проверяются на консистентность – нафиг не нужны. Считай, что их нет.

Архив gz весит 300 Мб.

Советую выбрать другой упаковщик. Gzip однопоточный. Вряд ли у тебя вместо него подставлен pigz.

zimniy
()
Ответ на: комментарий от vbr

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

Можно только схему снимать и потом заполнять её фейковыми данными.

zimniy
()
Ответ на: комментарий от vbr

А проверить, как миграции локально накатываются, до того, как разрабы положат стейджинг?

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

zimniy
()
Последнее исправление: zimniy (всего исправлений: 1)
Ответ на: комментарий от zimniy

Эм. Откуда мы тут знаем, насколько проект важен. Если там два реальных пользователя, и те зашли по ошибке из гугла, то кого колышет сразу в прод или не сразу в прод? Цепочки дев-стейджинг-прод это способ сильно усложнить себе жизнь и всё равно словить инцидент при финальной раскатке в прод. Если команда это трёх человек и никто выделенно не занимается только тестированием, а тупо сидят пилят дев, то это маскарад безопасности.

Не учи человека плохому, пожалуйста.

Аналогичное могу сказать. Сейчас он там полгода будет разворачивать CI и всякие стейджинги за бесплатно, а мог бы пофиксить самый противный баг, получить деняк и взять следующий проект. Зависит кто заказчик и что ему надо на самом деле.

neumond
()
Ответ на: комментарий от neumond

Зависит кто заказчик и что ему надо на самом деле.

Тут согласен. ТС, отпишись что ли.

BTW, учить человека работать по принципу: тут наговняю, тут соплей накину, а тут сделаю хорошо – это плохо. Человек может в итоге никогда хорошо и не делать. А с ним другие люди работают. С другой стороны – я при таком подходе без работы не останусь, но копаться в таких сопливо-говёных проектах – никакого удовольствия.

zimniy
()
Ответ на: комментарий от neumond

Цепочки дев-стейджинг-прод это способ сильно усложнить себе жизнь и всё равно словить инцидент при финальной раскатке в прод.

Оно ощутимо снижает вероятность инцидента в проде, если используется по назначению. Профанацию можно устроить где угодно.

zimniy
()
Ответ на: комментарий от zimniy

Ну так, умеренно. Основная уверенность может исходить из автотестов например. Все эти дополнительные версии нужны чтобы кто-то руками сидел кликал бесконечно и ломал насколько сможет. Дев бывает нужен чтобы вся команда поголовно свои локальные сервера не поднимала, особенно фронты и мобилки. Даже чисто прод можно раскатывать частями, развернули на 10% нагрузки, смотрим метрики, развернули ещё, смотрим метрики, и так до 100%.

neumond
()
Ответ на: комментарий от neumond

Основная уверенность может исходить из автотестов например.

У человека даже гита на проекте нет, как я понял, а ты про автотесты) Они тоже на 100% проблему не решают, так как тестами может быть покрыто не всё, если они, вообще, есть.

Все эти дополнительные версии нужны чтобы кто-то руками сидел кликал бесконечно и ломал насколько сможет. Дев бывает нужен чтобы вся команда поголовно свои локальные сервера не поднимала, особенно фронты и мобилки.

Спасибо, я в курсе. В том числе и для перечисленного использую.

Даже чисто прод можно раскатывать частями, развернули на 10% нагрузки, смотрим метрики, развернули ещё, смотрим метрики, и так до 100%.

Это можно и нужно автоматизировать. Человек может ошибиться в интерпретации метрик. Сам подход всецело одобряю.

zimniy
()

Размер базы на текущий момент 2 Гб.

С таким размером проще тупо копировать файлы, это займёт либо около 20 секунд (если там hdd), либо около 1-5 секунд (если ssd). Т.е. выключаешь базу, делаешь полную копию её состояния с прода на дев, запускаешь.

Всякие хитрости вроде репликаций и бекапов без остановкии базы нужны только если объём так что его быстро не скопируешь.

А у тебя - проще именно так, одним махом решишь практически все возможные проблемы (кроме одной: большой размер базы не поддерживается).

Разумеется это не вручную а скриптами надо сделать, чтоб нажал кнопку и она склонировалась.

Разработчики на дев-версии могут как-то дорабатывать БД, менять её. Как потом быстро и безопасно внести их доработки в прод-версию БД?

Тут лучше вручную делать и проверять перед внесением изменений ещё раз что всё хорошо.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)

Как потом быстро и безопасно внести их доработки в прод-версию БД?

dev -> prod: миграции аля phinx.

надо взять свежий вариант БД с прода для сайта дев. Как сделать это быстрее всего?

prod -> dev: дамп данных аля штатный mysqldump c ключами --single-transaction (если есть innoDB таблицы) и --skip-lock-tables (если есть MyISAM таблицы). Если используется и то и другое то укажите оба ключа:

mysqldump -u root -p --single-transaction --skip-lock-tables dbname | gzip -9 > /home/user/dump.sql.gz

таким образом дамп будет снапшотом базы в момент создания которого не блокируются работа с базой для пользователей. И не важно какая там у вас нагрузка (судя по уровню вопросов - небольшая), данная рекомендация проверена на базах с нагрузкой до 10 млн запросов в сутки.

Obezyan
()
Ответ на: комментарий от zimniy

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

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

vbr ★★★★★
()
Ответ на: комментарий от firkax

С таким размером проще тупо копировать файлы,

@truebin вот этот совет тоже не слушайте, это вредный совет

вам написали много букв в этом посте, сосредоточьте свое внимание на двух топиках:

  1. репликация
  2. миграция
gagarin0
()
Ответ на: комментарий от gagarin0

Репликация и миграция нуждаются в настройке, в них может что-то сломаться а у него не будет компетенции починить. С копированием же файлов справится кто угодно, и никакие его потребности при этом не окажутся нарушенными. Что за мания засовывать сложные механизмы туда где они не нужны?

firkax ★★★★★
()
Ответ на: комментарий от firkax

У вас просто мало опыта, либо много опыта, но как админа локалхоста.

Что за мания засовывать сложные механизмы туда где они не нужны?

А действовать нужно по ситуации

gagarin0
()
Последнее исправление: gagarin0 (всего исправлений: 2)
Ответ на: комментарий от vbr

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

А как разработчику отлавливать баги случившиеся на проде? Без данных это в большинстве случаев невозможно. Мы частенько брали бэкап на тот час, когда случилась проблема(например если в заказ не подтянулась оплата) и по логам(ага, триггеры писали полные логи изменений в таблицах), построчно буквально восстанавливали причину.

Loki13 ★★★★★
()
Последнее исправление: Loki13 (всего исправлений: 1)
Ответ на: комментарий от zimniy

Всякие триггеры, хранимые процедуры и тому подобное – бэкапятся?

mysqldump -u USER -pPASSWORD DATABASE | gzip > /path/to/outputfile.sql.gz

Я такой командой пользуюсь. Еще я смотрел таблицы базы через phpMyAdmin. И все пока.

Дамп разворачивал на тестовой машине – чисто визуально – вроде, норм.

Ты дамп разворачивать и сравнивать с исходной БД пробовал? Бэкапы, которые не проверяются на консистентность – нафиг не нужны. Считай, что их нет.

А как сравнивать с исходной БД ? Серьезно, как?

truebin
() автор топика
Ответ на: комментарий от rtxtxtrx

Хорошо. Как лучше сделать тогда?

Сейчас база и код сайта на одной машине. Берем, делаем отдельно сервер MySQL, на нем будут 2 базы: продовская и дев.

И делаем 2 машины еще, на которых будет запускаться код сайта. на первой машине будет прод, на второй будет дев. Обе машины коннектятся по сети к общему серверу MySQL, но каждая к своей базе. Да?

truebin
() автор топика
Ответ на: комментарий от gagarin0

У меня всё норм с опытом, а вот у автора очевидный локалхост и ему все эти сложности не нужны. Репликация у него будет постоянно рассыпаться, потому что на дев базе что-то меняют в схеме, а в прод базе меняются данные.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от vbr

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

Откуда ты знаешь что у него там персональные данные?

firkax ★★★★★
()
Ответ на: комментарий от zimniy

Архив gz весит 300 Мб.

Советую выбрать другой упаковщик. Gzip однопоточный. Вряд ли у тебя вместо него подставлен pigz.

Это чтобы вместо 5 секунд он запаковывался 1 секунду? Правда, учитывая что данные ему даёт mysqldump, скорее всего ничего не ускорится т.к. узкое место он а не архиватор.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Утечка ПД юзеров - это неприятная, но мелочь. А вот если там, например, закупочные цены товаров, то их спокойно и без палева можно сливать конкурентам за долю малую на регулярной основе. Плюс история заказов как статистика популярности товарных групп в разрезе сезонности/ценообразования - с получения таких данных от продавцов на своих площадках маркетплейсы/торговые сети продавливают СТМ, а тут еще и данные стороннего продавца.

Это только навскидку что первое на ум приходит. Косвенные данные вообще нет смысла обсуждать - это раздолье для любого датамайнера или просто штатного маркетолога.

t3n3t
()