Мысли как обеспечить обратную совместимость базы данных и zero-downtime deployment

При обновлении версии приложения, работающего 24x7, важный показатель – нулевое время простоя (zero-downtime). Чтобы его достичь, разворачивание и «прогрев» новой версии выполняется параллельно с продолжающейся работой старой версии. Этот подход называется blue green deployment. Старая blue-версия приложения продолжает работать, пока новая green-версия не будет готова и не начнет полноценно работать. Только тогда blue-версия выводится из работы. Если даже что-то случится с green-версией в процессе подготовки, прогрева и начала работы, то можно просто выключить ее. Работоспособность системы будет по-прежнему обеспечивать blue-версия. При переходе на новую версию как правило выполняются изменения в базе данных приложения. Для подхода blue green deployment важно, чтобы эти изменения были обратно совместимыми, так как в случае проблем с green-версией, blue-версия должна продолжать работать с измененной базой данных.

А как быть если все же надо внести в структуру базы данных обратно не совместимые изменения? Как в этом случае обеспечить blue green и zero-downtime deployment?

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

Какие обратно несовместимые изменения в схеме базы данных могут произойти:

Рассмотрим их с помощью разбиение на обратно-совместимые шаги и требования к коду сервиса для каждого из вариантов.

1. Добавление нового NOT NULL поля таблицы

Если новое поле должно быть NOT NULL, то его нельзя сразу добавить в таблицу (если не задано default value), или если новое поле зависит функционально от других уже хранящихся в базе данных. Даже если таблица не содержит записей, добавление нового NOT NULL поля может привезти к отказу. Так как продолжает работать исходный вариант сервиса, который ничего не знает про новое поле и может попытаться добавить запись, не указав для него значения.

Возможный сценарий обновления в этом случае такой:

Если посмотреть внимательно, можно заметить, что на каждом шаге можно откатить версию приложения на одну версию назад (или даже не делать этого, если на шаге выполнялись только изменения в структуре базы данных). Изменение в базе данных на каждом шаге обратно-совместимы и не мешают работе предыдущей версии приложения.

2. Удаление поля таблицы

Сразу удалять поле таблицы нельзя, так как продолжает работать исходный вариант приложения, который пытается писать в него и читать из него. Сначала нужно сделать поле nullable и постепенно вывести из обращения.

Возможный сценарий обновления в этом случае такой:

3. Переименование типа поля таблицы

Сценарий обновления:

4. Изменение типа поля таблицы

Последовательность действий при изменении типа поля похож на изменение имени поля, но имеет свои особенности.

Возможный сценарий обновления:

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

Реализация описанных выше сценариев представляет определенные трудности.

Во всех трех случаях дополнительным источником ошибок будет человеческий фактор. Поэтому так важна аккуратность при первоначальном проектировании структуры данных, чтобы потом не пришлось обрабатывать обратно-несовместимые изменения, то есть проделывать всё выше перечисленное.