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

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

далеко не у всех в ней ПД хранится.

И где же ПД юзеров хранятся у не только лишь всех?

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

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

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

Нук расскажи как разрабы ток в слейв бд писать будут?

Редко какой сайт может похвастать тем, что у него нет данных пользователя, которые он не захочет никому показывать.

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

PS: Видел тут в магазине, висит экран на стене, его видят все в очереди на кассу, на экране список покупок текущего покупателя с ценами. А когда покупатель карту сканирует свою, то на этом же экране, на весь магазин отображаются его ФИО и номер телефона. А вы про ПД будете говорить.

в общем случае, у автора должна быть такая цепочка:

1. с прода настроена репликация на slave

2. со слейва забирается дамп при помощи вот этой утилиты https://github.com/josacar/triki

   В этой утилите можно задать правила обфускации данных для дампа

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

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

Разрабы работают не с dev версией, а каждый со своей собственной локальной версией базы у себя на рабочем компьютере. Сайт должен работать полностью локально у каждого разраба, вплоть до прописывания в /etc/hosts домена сайта на 127.0.0.1. Все изменения схемы люди пишут в файлик. Когда приходит время выкатывать релиз, эти изменения объединяются руками и после небольшого ревью (лучше всей командой сразу) накатываются на dev для тестирования. dev в этом смысле по сути получается как staging. Чтобы люди при этом не мешали друг другу пусть возьмут за практику словами предупреждать коллег, что вот сейчас будут что-то менять в такой-то таблице, в маленькой команде это избавит от 90% проблем с несовместимыми изменениями.

На dev перед внесением изменений развертывается бэкап базы сайта, с нуля, заодно и проверишь работоспособный бэкап или нет. Далее накатывается новый код сервиса (пхп или что там у вас), все в том же порядке, в каком будет идти апгрейд основного сервера.

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

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

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

Когда приходит время выкатывать релиз, эти изменения объединяются руками и после небольшого ревью (лучше всей командой сразу)

Разруливать конфликты тоже всей командой?

Какие еще изменения схемы в файликах, какие еще «словами предупреждать коллег»? Что за бред?

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

Это только расширит такой список. Что за бред х2 ?

Систему контроля версий внедрить обязательно!

Вот с этого начинать и надо. А потом внедрять CI/CD с пулл/мердж-реквестами, пайплайнами и графиками деплоев. Да, даже для команды в 2-3 разраба. И это не на случай чп, это для нормальной, продуктивной работы.

в нормальных ынтерпрайзах (дада, жава-мир) придуман liquibase, который обеспечивает единообразие схем БД на всех окружениях

а вытаскивать с прода в дев можно бэкапом

Да, конфликты разруливать всей командой. Типа неделю работают каждый самостоятельно, потом перед релизом день-два все вместе разруливают конфликты на dev. При постоянном общении между разрабами когда каждый знает что делают другие это будет нормально работать для 3-5 человек, я такое видел. С системой контроля версий конечно, но использовать ее можно на самом базовом уровне.

Разруливать конфликты тоже всей командой?

У нас был ответственный, который раз в неделю, по четвергам(готовил раньше, в четверги релизы выкатывались), готовил релиз из всех скинутых ему файлов(sql конечно имеется в виду) от коллег. А потом, перекрестясь, старший админ, в 7 утра, отправлял всё это в прод кнопкой F5 в файле открытом в IDE. Конечно там были транзакции и всё что положено, но случались и факапы, например из-за забытого триггера. тогда всех имели без вазелина, с вопросом «как вы могли такое допустить? и что нам сделать, чтобы такого больше не случилось?»

я как раз часто видел, что в банках не маскировали базы, так как слишком муторно и долго/дорого, а защищаемся просто через NDA )

HAHA classic.png

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

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

риск что разрабы увидят пд зачастую гораздо дешевле, чем разработка маскирования, ну ты же наверняка видел какие копеечные штрафы назначают)