Как развернуть изменения базы данных на живом сервере?

Question

У меня есть сценарий, который является частью моего процесса развертывания для отправки изменений БД на рабочий сервер.Если скрипт по какой-то причине повреждает мои данные (плохое обновление), восстановить его сложно.

Один из способов решить эту проблему - закрыть приложение для пользователей во время обновления, поэтому, если возникнет проблема, просто вернитесь к резервной копии, которую я сделал перед развертыванием.

Но я слышал о других, которые развертывают и поддерживают работу своего сайта ... как бы вы поступили так, и если бы вы потерпели неудачу, как вы могли бы восстановить данные, поступившие после того, как вы сделали резервную копию доразвертывание

Answer 1

В общем, это сложная проблема, как и во многих других аспектах администрирования баз данных.Есть три основных способа решения этой проблемы:

1. Избегайте сбоев любой ценой.
2. Блокируйте все (и сделайте обновление очень быстрым).
3. Все нормальнопотерять данные.

Если у вас сложная система, изолируйте ваши компоненты в соответствии с этими или аналогичными категориями.

У вас есть промежуточная система для тестирования обновлений.Этапная система является более или менее копией производственной системы;это отдельно от тестовой системы.Еще одна вещь - иметь систему аудита или ведения журналов, к которой вы можете обратиться, если вам нужно воспроизвести данные.

Реальная проблема в том, что вы заметите намного позже, что ваше обновление было ошибочным.Тогда вы совершенно облажались.

Answer 2

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

Для простых веб-сайтов, на которых работает только pgsql, вы можете отключить клиентов и запустить все обновление за одну большую транзакцию. Если какая-то часть выходит из строя, все откатывается назад, как будто вы никогда ничего не делали. К сожалению, это не работает точно так же для других БД, но с флэшбэком или как его называет оракул, вы можете получить нечто подобное.

Для более крупных и сложных веб-сайтов, работающих поверх реплицированного набора серверов БД, все становится намного сложнее и быстрее. Там, где я работал, мы использовали Slony, и не очень приятно играть с другими, когда вы развертываете изменения DDL, и вы в значительной степени ДОЛЖНЫ отключить всех пользователей во время развертывания DDL. Однако время простоя измеряется для нас минутами, даже если размер баз данных достигает 1 ТБ.