Студийный сервер определяет Ьеап-компонент, называемый обновителем базы данных. Он содержит список объектов обновления, каждый из которых представляет атомарное изменение базы данных. Каждое обновление базы данных знает свою версию и умеет применять себя к базе данных.
В процессе запуска обновитель базы данных проверяет текущую версию базы по таблице. Если таблица не обнаружена, он считает, что обновлений не существует или они уже были успешно применены. Соответственно самое первое обновление инициализирует таблицу версий и заносит в нее одну запись с номером версии и полем блокировки. Чтобы исключить одновременные обновления, обновитель базы данных сначала обновляет эту запись с установлением блокировки. Если установить блокировку не удается, то обновитель считает, что другой компьютер в сети уже занимается обновлением.
Мы использовали механизм миграции для применения как простых, так и относительно сложных изменений. Например, в одном из простых изменений мы добавили индексы для пары полей, влияющих на производительность. С другой стороны, нам пришлось изрядно поволноваться при преобразовании всех таблиц MylSAM к типу InnoDB (Му-ISAM, принятый по умолчанию тип таблиц в MySQL, не поддерживает транзакций и целостности ссылок, поддерживаемых типом InnoDB; если бы мы знали об этом до выпуска первой версии, то сразу воспользовались бы типом InnoDB). Так как базы данных при развертывании уже были заполнены реальными данными, нам пришлось использовать серию команд ALTER TABLE. Все прекрасно сработало.
После выпуска нескольких начальных версий было опубликовано около 10 обновлений. Все они прошли успешно.
No related posts.