Мои разработчики в проекте хотят, чтобы dev db на dev-сервере синхронизировалась с live db на живых серверах, что я считаю плохой идеей. Несмотря на это, как лучше всего развернуть кодовую базу + базу данных для жизни? Пока я использую rsync для данных и простой экспорт / импорт для базы данных. Окончательная установка состоит из сервера разработки и 2 серверов Live (один в США, один в Европе для HA / LB). Был предложен кластер MariaDB, но я не уверен, хочу ли я ввести в эту настройку репликацию с несколькими мастерами. Тем более, что 2 Live сервера разделены таким большим расстоянием. Кроме того, мне нужно каким-то образом суметь предоставить им live db up2date для сервера разработки, потому что разработка, очевидно, не может заставить db жить, когда он старый (тогда в промежутке между экспортом / импортом будут отсутствовать записи). Может я здесь не вижу деревьев в лесу, и это довольно просто. Что вы предлагаете мне сделать?
Поскольку это начало превращаться в обмен комментариями, я подумал, что напишу это как следует.
Во-первых, это довольно распространенное требование (часто) синхронизировать базу данных prod с dev, так что разработка идет против чего-то приближающегося к реальности. А наоборот? Не уверен, что когда-либо видел такое, и определенно не стал бы этого делать.
Вы правы, заметив, что часто изменения схемы или содержимого базы данных требуют обновлений базы данных prod, чтобы они совпадали с изменениями кода, которые переносятся в процессе разработки. Но разумный процесс выпуска справляется с этим путем разработки процедур для обновления схемы, загрузки нового содержимого и / или изменения существующего содержимого и развертывания этих процедур во время публикации кода.
В наиболее регулируемой среде, в которой я работал, изменения буквально сценарий - один разработчик создает длинный документ-ответ на изменение-тест-ответ, в котором очень подробно говорится, что нужно ввести, что будет видно, как это следует тестировать и какие результаты требуются. Сценарий подписывается вторым разработчиком, чтобы подтвердить, что он был протестирован в чистой тестовой среде, и выполняется третий разработчик, у которого есть не работал над процессом. Это гарантирует, что никто не будет умничать и не сойдет с трассы, когда случится что-то странное. Часто четвертый разработчик подпишет сценарий, чтобы сказать, что он подтвердил все, что, как утверждалось, было видно и сделано.
В сценарии также указывается проверенная процедура возврата, и она выполняется третьим разработчиком, если в какой-либо момент ответы не соответствуют ожидаемым в сценарии. Если вся процедура проходит проверку, среда prod обычно повторно синхронизируется в среды разработки и тестирования.
Я не говорю, что весь этот процесс подходит для вашей среды; только это для некоторых людей. Но вы, похоже, хотели знать, как обрабатываются изменения схемы и содержимого, кроме слепой синхронизации разработчика с продуктом, поэтому я надеюсь, что это проливает свет на это. Если вы все-таки завершите развертывание, синхронизируя dev с продуктом, убедитесь, что ваши резервные копии актуальны, а процедуры восстановления хорошо протестированы. Они вам понадобятся.