Skip to content
Snippets Groups Projects
Unverified Commit 9ce2eb92 authored by Sergey V's avatar Sergey V
Browse files

docs: improve versioning.md

parent d57b26d6
No related branches found
No related tags found
1 merge request!119Docs/versioning
Pipeline #6257 passed
# Версионирование
Данный документ описывает особенности изменения версий у схем данных и приложений, выполняющихся на сервере Picodata.
Данный документ описывает особенности изменения версий схем данных и приложений Picodata.
Версия схемы и версия приложения разделены и изменяются независимо друг от друга. Для версионирования схемы используется набор семантических правил [SemVer](https://semver.org/lang/ru/). Правила изменения версий приложения могут быть произвольными и задаваться по желанию пользователя, но при этом должно быть выполнено условие: у любых двух версий приложения с разной логикой должны быть разные пары **имя приложения** - **версия приложения**.
Версия схемы и версия приложения изменяются раздельно друг от друга. Для версионирования схемы используется набор семантических правил [SemVer](https://semver.org/lang/ru/). Правила изменения версий приложения могут быть произвольными и задаваться по желанию пользователя, но при этом должно быть выполнено условие: у любых двух версий приложения с разной логикой должны быть разные пары **имя приложения** - **версия приложения**.
Приложение должно работать только когда в кластере на всех мастер инстансах во всех репликасетах находится одна и та же версия приложения. Проверка версий запущенных приложений делается через журнал Raft. Каждое приложение при запуске ждет коммита своей версии в Raft log.
Приложение может работать только когда в кластере на всех активных инстансах во всех репликасетах загружена одна и та же версия приложения. Проверка версий запущенных приложений делается через журнал Raft. Каждое приложение при запуске ждет коммита своей версии в Raft log.
Версия схемы в кластере меняется только в большую сторону. Любые изменения схемы сопровождаются увеличением версии. Откатить версию нельзя (кроме восстановления из резервной копии).
Зависимость приложения от версии схемы задается явно двумя способами:
1. (Обязательно). В коде приложения. Если в приложении задана зависимость от схемы v3.2.1, то это приложение не должно запускаться, если в кластере и, соответственно, на инстансе не выполняется условие: 3.2.1 <= версия схемы < 4.0.0, за исключением случаев, описанных в следующем пункте. В случае обнаружения несовместимой версии схемы, Picodata должна моментально останавливать приложение и ждать, пока схема станет совместимой. При этом должно выводиться соответствующее сообщение в журнал.
1. (Обязательно). В коде приложения. Если в приложении задана зависимость от схемы v3.2.1, то это приложение не должно запускаться, если не выполняется условие: 3.2.1 <= версия схемы в кластере < 4.0.0, за исключением случаев, описанных в следующем пункте. В случае обнаружения несовместимой версии схемы Picodata должна останавливать приложение и ждать, пока схема станет совместимой. При этом должно выводиться соответствующее сообщение в журнал.
2. (Опционально). Глобально в кластере в реплицируемом через Raft хранилище конфигурации может быть задано множество вариантов совместимости любой версии схемы с любой версией приложения. Этот признак совместимости имеет приоритет над первым. Т.е. когда Picodata запускает приложение, сначала проверяется признак совместимости согласно глобальной кластерной конфигурации: если совместимо, то Picodata запускает приложение НЕЗАВИСИМО ОТ ПРАВИЛ SEMVER. Предполагается, что администратору может понадобиться задать совместимость таким образом при решении проблем, см. пример ниже.
Проверка совместимости версий включена по умолчанию, но её можно выключить в случае если пользователь отдаёт отчёт в своих действиях.
Проверка совместимости версий включена по умолчанию, но её можно отключить.
## Пример, когда нужно воспользоваться способом задания совместимости №2.
Выкатили новую версию приложения и новую обратно несовместимую версию схемы:
Развернули новую версию приложения и новую обратно несовместимую версию схемы:
```
APP APP_DEPENDS_ON_SCHEMA SCHEMA
было: v5 v1.2.3 v1.2.3
выкатили: v6 v2.0.0 v2.0.0
развернули: v6 v2.0.0 v2.0.0
```
После выкатки обнаружилось, что в приложении v6 критичный баг. Принято решение откатить приложение на v5. Но оно не запустится на схеме v2.0.0 даже если отключить проверку совместимости версий. Для решения проблемы схему меняют так, чтобы приложение v5 могло запуститься. Этим изменениям схемы присваивают версию v3.0.0. Глобально в кластерном конфиге задается совместимость app v5 и schema v3.0.0. После этого приложение v5 можно запустить в кластере с версией схемы v3.0.0, хотя приложение v5 было разработано и собрано в прошлом, когда про schema v3.0.0 еще не было известно.
После развертывания обнаружилось, что в приложении v6 критичный баг. Принято решение откатить приложение на v5. Но v5 не запустится на схеме v2.0.0 даже если отключить проверку совместимости версий. Для решения проблемы через административный API схему в кластере меняют так, чтобы приложение v5 смогло запуститься. Этим изменениям схемы присваивают версию v3.0.0. Глобально в кластерном конфиге задается совместимость app v5 и schema v3.0.0. После этого приложение v5 можно запустить в кластере с версией схемы v3.0.0, хотя приложение v5 было разработано и собрано в прошлом, когда про schema v3.0.0 еще не было известно.
## Алгоритм запуска инстанса.
1. Подключиться к Raft-группе (кластеру) и актуализировать журнал Raft.
1. Сформировать из глобальной конфигурации кластера параметры репликации для данного инстанса.
1. Проверить совместимость версии приложения и схемы в кластере. Если версии несовместимы, то написать об этом в журнал Raft.
1. Отправить в глобальную конфигурацию версию запускаемого приложения через журнал Raft.
1. Запустить Tarantool, даже если версия приложения несовместима со схемой.
1. Применить все изменения схемы из глобальной конфигурации кластера.
1. Если запускаемое приложение содержит обновления схемы, то применить эти обновления глобально в кластере.
1. Если версии совместимы, запустить приложение Picodata, иначе сделать запись в журнале и ждать пока версии станут совместимы.
1. Подключиться к кластеру и получить актуальную глобальную конфигурацию кластера.
2. Отправить в глобальную конфигурацию версию запускаемого приложения через журнал Raft.
3. Запустить Tarantool, даже если версия приложения несовместима со схемой.
4. Применить все изменения схемы из глобальной конфигурации кластера.
5. Если запускаемое приложение совместимо с версией схемы в кластере и содержит обновления схемы, то применить эти обновления глобально в кластере.
6. Если версии совместимы, запустить приложение, иначе сделать запись в журнале и ждать пока версии станут совместимы.
## Обновления и время простоя
Под временем простоя (downtime) подразумевается длительный промежуток времени, когда клиенты приложения Picodata не могут в полной мере пользоваться его функциями. Мероприятия, связанные со вводом резервных узлов в рамках отказоустойчивости (switchover, failover), происходят относительно быстро и не считаются простоем. Перезапуск репликасета Tarantool со снапшотами по 10 GB считается долгим, т.к. может занять более 10 минут, поэтому считается простоем.
Под временем простоя (downtime) подразумевается длительный промежуток времени, когда клиенты приложения не могут в полной мере пользоваться его функциями. Switchover, failover происходят относительно быстро и не считаются простоем. Перезапуск репликасета Tarantool со снапшотами по 10 GB считается долгим, т.к. может занять более 10 минут, поэтому считается простоем.
Существует два варианта обновления: простой и сложный.
Простой вариант. В этом варианте обновления будут проходить с простоем на время, пока все инстансы будут обновлены, перезапущены, и затем в них запустится Tarantool, который загрузит последнее сохраненное состояние БД из файла *.snap* и применит изменения из журнала последних операций (*.xlog*). Для выполнения такого обновления нужно обновить файлы приложения и перезапустить все инстансы в любом порядке: по одному или все сразу.
Простой вариант. Обновления будут проходить с простоем на время, пока все инстансы будут обновлены, перезапущены, и пока в них запустится Tarantool, который загрузит последнее сохраненное состояние БД из файла *.snap* и применит изменения из журнала операций (*.xlog*). Для выполнения такого обновления нужно обновить файлы приложения и перезапустить все инстансы в любом порядке: по одному или все сразу.
Сложный вариант состоит в обновлении приложения Picodata без простоя.
Сложный вариант состоит в обновлении приложения без простоя.
1. Потребуется в каждом репликасете остановить все инстансы, кроме одного. Рекомендуется останавливать резервные реплики и оставлять работать активную реплику.
1. Обновить файлы приложения на остановленных инстансах.
1. Запустить ранее остановленные инстансы.
1. Дождаться, пока Tarantool считает данные и запустится.
1. Остановить инстансы, на которых приложение еще не обновлено. При этом произойдет переключение switchover, запустятся новые версии приложения, обновится схема данных.
1. Обновить файлы приложения на оставшихся инстансах и запустить их.
1. В каждом репликасете остановить все инстансы, кроме одного. Рекомендуется останавливать резервные реплики и оставлять работать активные реплики.
2. Обновить файлы приложения на остановленных инстансах.
3. Запустить ранее остановленные инстансы.
4. Дождаться, пока Tarantool считает данные и запустится.
5. Остановить инстансы, на которых приложение еще не обновлено. При этом произойдет переключение switchover, запустятся новые версии приложения, обновится схема данных.
6. Обновить файлы приложения на оставшихся инстансах и запустить их.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment