alexeyvgОчень лысыйЧто за писание работы тестеров в боевую базу? Мало ли что там кодеры накодят, и, при доступе на прод, этот код там что-то похерит ненароком?Не тестеров, а пользователей.

Вы подготовили версию, она должна утром появиться на компах 10 000 сотрудников.
Но вам стрёмно, 10 000!!! Вас же порвут, а вдруг что то не так? Вы думаете, "а не залить ли эту версию на компы отдела маркетинга, всё равно их никто не слушает, да и их всего сотня? Если что, откатим."
Ясно, я просто не до конца понял идею. Оно, конечно, прикольно, но несмотря на все согласования и пути минимизации, возможные издержки выглядят гораздо более внушительными, нежели предполагаемый профит. Я имею в виду в случае размещения в одной базе. Тем не менее, скорее всего условный "маркетинг" меняет лишь ограниченное количество данных. Посему, возможно, получится держать "маркетологов" в отдельной базе, куда подливать данные из постоянно изменяемых больших таблиц репликацией, а то, что они там нагерерируют, время от времени сливать в основную боевую базу провереным скриптом. А утром пересобирать для них новую базу из свежено бэкапа с основного прода.

alexeyvgОчень лысыйПосему, возможно, получится держать "маркетологов" в отдельной базе, куда подливать данные из постоянно изменяемых больших таблиц репликацией, а то, что они там нагерерируют, время от времени сливать в основную боевую базу провереным скриптом. А утром пересобирать для них новую базу из свежено бэкапа с основного прода.Я про этот вариант писал, и не только я.
Но это черезмерно сложно для такой задачи. Сделать для тестирования распределённую систему из продакшена и теста - нереально, это будет по стоимости сравнимо с созданием всей системы.
Для очень больших и ответственных систем, которые уже сделаны распределёнными, можно (и обязательно нужно) предусматривать работу разных частей системы в разных версиях, это при той же сложности хотя бы даст дополнительные плюсы, эта адская работа хотя бы не будет сделана только для тестирования.
На самом деле, в общем случае реализовать такую схему, как я описал, не так уж трудно и дорого, если база не слишком сложная по структуре и таблиц в ней не сотни. Ибо она не является в полном смысле слова распределённой системой. Другое дело, что если восстановление из бэкапа будет занимать несколько дней, то тогда, конечно, не вариант. Но поставить диагноз по фотографии, не видя исходный солюшен, понятно, задача неблагодарная.

alexeyvgAlex1975пропущено...


Может в каких-то не сильно больших системах где десяток транзакций в секунду и можно реализовать.
Но в больших тяжело. Я даже представить боюсь трудозатраты и количество багов которые огребем при реализации такой схемы. А все для того чтобы исключить гипотетическую вероятность того что кто-то через процедуры сможет покосить много не своих данных.Мало того, непонятна идея Очень лысый, как можно таким образом уберечь данные.
Кривая процедура накосячит в данных, и они перенесутся репликацией в рабочую базу.
Результат тот же, но с адской работой и дополнительными ошибками от самой распределённой схемы.
Ну я реплицировать предполагал из боевой в тестовую наоборот. Но оно, конечно, не для всякого случая подойдёт и вообще уже подсказали хороший вариант, так что извините, если что не так.