Т.е. теоретически, должна некоторым образом обеспечиваться процедура отката с сохранением данных из новой структуры. Такой откат в общем случае требует ручного написания скриптов, а значит, в них тоже могут содержаться ошибки.
Как вы подобные ситуации обрабатываете, как их предотвращаете?
тестовые откаты на окружениях аналогичных проду, по сути процедера по своей идеи полностью идентична проверке процедуры восстановления чего-либо из бекапов.
Тестовые откаты на предпродуктивных средах - это, конечно, очень хорошо. Если вы убедите Dev выполнять двойную, а иногда тройную работу, большая часть которой пойдёт "в корзину" (факап не случился, процедура не пригодилась).
В реальной же жизни дев - "скорей, скорей! тяп-ляп и в продакшен".
Процедуре проверки восстанавливаемости бэкапов это, конечно, не аналогично.
Проверка восстанавливаемости легко автоматизируется (всегда полезно иметь где-либо свежий, восстановленный из бэкапа прод; хотя бы для финального тестирования разворачиваемости изменения на свежих продуктивных данных).
Откат изменений после наколбашивания данных в новую структуру - работа по подготовленному вручную скрипту.
Ближе - BCP тест, проведённый с потенциальной потерей данных и применением процедур проверки такой потери и восстановления из других источников.
Ни разу не видел, чтобы организация добровольно шла на такие проверки (хоть и в тестовой среде). Все проверки/переезды сервисов - в graceful режиме, пока связь между сайтами жива.
Если "чего" случилось, то для крутящегося вокруг базы приложения быстро откатиться и сделать это "автоматом" уже не получится. Как только прошла первая транзакция, данные уже относятся к обновлённой схеме БД, где даже в не изменившийся в структуре бд атрибут может иметь новую семантику (конечно, за такое надо по рукам, но команды разработчиков - они же сами с усами, да и поди отлови всех).
это в общем то и ест ьодна из задач - обеспечить контроль того чтобы изменения в структуре БД не были столь критичны и проходили в несколько этапов. Как именно обеспечить подобный контроль это уже десятый вопрос
По факту что наблюдал - часто прилетало, что и для _накатываемости_ изменений приходилось вручную править ввиду объёмов данных на продуктиве и конкурентной нагрузки (и чтобы была возможность провести изменения наживую - подчас требовались специальные знания, которых у разработчиков просто не было). Чего уж говорить про откаты при несовместимости структур.
Пара сценариев.
a) Поле увеличило размерность.
- Поменяли (сделали это даже online)
- Но вот где-то в интегрированной критически важной системе поле не расширили (её может вообще сторонняя организация делает, кстати).
- Прилетело увеличенное значение (хорошо, если текстовое, и просто интеграция сломалась, а может и числовое и пошло автоматическое округление и "баланс" поплыл... когда-нибудь... позже).
- Надо вертать в зад. А там уже значения, которые используют большую размерность. Потерять их - тоже не комильфо. Причём расширить тип колонки подчас можно лёгким мановением руки в онлайне. А вот уменьшить - уже с полной физической реорганизацией таблицы, что может уже потребовать существенного времени и не допускать модификации данных в процессе (т.е. имеем простой приложения).
b) Имеем CHAR поле, хранящее какой-либо признак/класс объекта ('Y', 'N'... 'A', 'B', 'C', 'D'…), на которое завязана внутренняя логика приложения. В какой-то момент список значений расширяется.
- БД дизайнер отметил это у себя в голове, в доках и спустил девелоперу.
- В БД вообще ничего не пришло! (если не ограничиваем список значений констраинтами, а может и в этом случае не придти, если просто поменялась семантика поля).
- По какой-то там причине релиз откатили.
Никакая автоматизированная система тут не поможет – будет просто не в курсе изменений природы данных. И уж точно не будет в курсе, что (и как) с этим делать.
Т.е. да, руками это всё правится, но это на каждый чих надо городить огород с огромной работой по тестированию (в одной из организаций, в которой работал, на одной из центральных баз, например, прилетало довольно часто по несколько изменений в день на прод).
Вот мне и интересно послушать Дмитрия про чудесные Deployment чудеса, которые им позволяют проводить "проверку новой версии на проде и быстро откатиться в случае чего" (мы же на sql.ru и говорим о приложениях, крутящихся вокруг DB?).
Что наблюдал чаще, Deployment - это дорога в один конец. Далее - хотфиксы или аккуратная ручная работа по "отскрёбыванию этого …".
Другое дело - постараться впихнуть скрипт наката в одну транзакцию и по факту ошибки всё разом откатить (соответственно никаких новых данных там пока нет).
Тут тебе и online, и быстрый откат (за определёнными исключениями).
