репликация и обновление структуры
Модератор: kdv
репликация и обновление структуры
в общем есть 2 БД с репликой
реплика работает на ура каждые 10 минут
базы обновляются скриптами в принципе все автоматизированно , но вчера вот пришлось ручками , причина в структуре добавилась таблица и она заполнялась скриптом на основании других данных (типа рефакторинг) соответсвенно это дело сразу пошло в реплику и дошло до филиала , там оно застряло т.к. сруктура не позвояла.
соответсвенно просто запустить обновление в филиале я уже не мог чтобы он не насоздовал линшнии записи, пришлось вручную разделить обновление, изменить структуру, прогнать реплику, а потом уже запустить скрипт обновление данных.
вот высказался, внимае вопрос : как умные люди делают подобные действия (обновление структуры влияющие на реплику) при рабочей репликации?
реплика работает на ура каждые 10 минут
базы обновляются скриптами в принципе все автоматизированно , но вчера вот пришлось ручками , причина в структуре добавилась таблица и она заполнялась скриптом на основании других данных (типа рефакторинг) соответсвенно это дело сразу пошло в реплику и дошло до филиала , там оно застряло т.к. сруктура не позвояла.
соответсвенно просто запустить обновление в филиале я уже не мог чтобы он не насоздовал линшнии записи, пришлось вручную разделить обновление, изменить структуру, прогнать реплику, а потом уже запустить скрипт обновление данных.
вот высказался, внимае вопрос : как умные люди делают подобные действия (обновление структуры влияющие на реплику) при рабочей репликации?
ну там растояние далекое и связь отсутсвует =(
реплика по жпрс идет.
плюс обновление такого маштаба только в нерабочее время.
для себя то решение придумал, что если такое еще ра повторится, то обновление надо делать в 3 этапа размазаных по времени.
1, обновляется структура везде (но нигде не используется)
2, на одном филиале заливаются данными и структура начинает использоваться
3, прсле прохода реплики во втором месте заливаются данными (те что работали без структуры в премежутке между 2 и 3) и тоже начинает использоваться структура.
в общем итоге рефакторинг на рабочем ПО вещь страшная, можно было и костыликами обойтись, но лучше день потерять , потом за 5 минут долететь =)
реплика по жпрс идет.
плюс обновление такого маштаба только в нерабочее время.
для себя то решение придумал, что если такое еще ра повторится, то обновление надо делать в 3 этапа размазаных по времени.
1, обновляется структура везде (но нигде не используется)
2, на одном филиале заливаются данными и структура начинает использоваться
3, прсле прохода реплики во втором месте заливаются данными (те что работали без структуры в премежутке между 2 и 3) и тоже начинает использоваться структура.
в общем итоге рефакторинг на рабочем ПО вещь страшная, можно было и костыликами обойтись, но лучше день потерять , потом за 5 минут долететь =)
ну с этим согласен, я структуру меняю пока только для более удобной отчетности , так что данные пошли по филиалам, но новый отчеты я не дал и все хорошо, пока не проведу полного обновления никто ничего и не узнает.
есть правда еще вариант
делать скрипт обновления филиало-зависимым тогда
1, обновляю в первом месте и структуру и данные которые этого филиала (те что пришли сюда по реплики не трогаем)
эти данные сразу уйдут в реплику и там втанут така как не подходят по структуре.
2, меняем струкруру на втором и данные этого филиала, тут сразу реплика войдет и обновленые данные пойдут по реплике в первое место.
наверно так оптимальние, но все рано нельзя долгий промежуток между обновлениями, так как реплика будет стоять и ждать.
есть правда еще вариант
делать скрипт обновления филиало-зависимым тогда
1, обновляю в первом месте и структуру и данные которые этого филиала (те что пришли сюда по реплики не трогаем)
эти данные сразу уйдут в реплику и там втанут така как не подходят по структуре.
2, меняем струкруру на втором и данные этого филиала, тут сразу реплика войдет и обновленые данные пойдут по реплике в первое место.
наверно так оптимальние, но все рано нельзя долгий промежуток между обновлениями, так как реплика будет стоять и ждать.