Довольно часто случается, что компания, пережившая аварию, вызвавшую повреждение данных, но не имеющая действительных резервных копий для восстановления и возможности выполнить отработку отказа на избыточную вторичную реплику, просто запускает восстановление (repair), а затем немедленно снова начинает работать в продуктивной среде.
<Представьте здесь мем на эксперта, сочетающую вопли О, НЕТ! ОЙ! О, БОЖЕ! качает головой НЕЕЕЕЕТ!>
За эти годы я провёл бесчисленное множество занятий и конференционных сессий, посвящённых повреждениям данных, тому, как они возникают, как выполнять проверки согласованности, использовать DBCC CHECKDB и запускать восстановление. Когда я говорю о восстановлении, я объясняю, что если вам пришлось запустить REPAIR_ALLOW_DATA_LOSS, и это действительно привело к удалению записей данных, вам необходимо заново инициализировать любые затронутые топологии репликации и проверить любые затронутые ограничения. Всё это задокументировано в Books Online, но это не значит, что люди читают это и знают — lol!
То, чего нет в Books Online, и что я обязательно поясняю слушателям, — это то, что восстановление направлено исключительно на придание базе данных структурной согласованности — оно ничего не знает о связях данных между таблицами (защищённых ограничениями или просто присущих в схеме данных). Это означает, что после восстановления с потерей данных связи между данными в базе данных вполне могут быть нарушены.
Затем я всегда спрашиваю аудиторию: «У скольких из вас есть инструмент проверки согласованности данных приложения, который вы можете запустить, чтобы проверить все бизнес-правила и связи, от которых зависит приложение? Более того, у скольких из вас вообще есть способ проверить, что приложение работает правильно после запуска восстановления или развёртывания нового кода?»
Каждый раз, когда я спрашиваю, возможно (редко) поднимается одна или две руки из группы в 30 или аудитории в 50 и более человек. У меня никогда не было более двух, и обычно не поднимается ни одной.
Люди просто не задумываются об этом. Они предполагают, что если восстановление выполнилось правильно, то они могут продолжать работу, и всё будет функционировать. Нет.
Призыв к действию:
У вас действительно должен быть какой-либо способ проверить, что ваше приложение работает с корректными данными. В противном случае, в лучшем случае оно выйдет из строя, но в худшем — продолжит работать ошибочно — возможно, с неверными результатами, которые повлияют на ваш бизнес.
Это в основном означает, что требуемые связи должны быть формализованы в виде ограничений и/или кода, который проверяет правильность требуемых связей (если их нельзя выразить как реляционные ограничения).
Если у вас стороннее приложение, может быть трудно или невозможно убедить поставщика предоставить такой инструмент, особенно если он явно не поддерживает запуск восстановления в своей базе данных.
Альтернатива: иметь надёжную стратегию резервного копирования и восстановления (backup-and-restore) и/или решение для отработки отказа.
Суть: Ваш бизнес зависит от приложений, работающих в уровне данных, и вам нужно максимально убедиться, что они работают с корректными данными.
Комментариев нет:
Отправить комментарий