1. (Обязательно). В коде приложения. Если в приложении задана зависимость от схемы v3.2.1, то это приложение не должно запускаться, если в кластере и, соответственно, на инстансе не выполняется уcловие: 3.2.1 <= версия схемы < 4.0.0, за исключением случаев, описанных в следующем пункте. В случае обнаружeния несовместимой версии схемы, Picodata должна моментально останавливать приложение и ждать, пока схема станет совместимой. При этом должно выводиться соответствующее сообщение в журнал.
2. (Опционально). Глобально в кластере в реплицируемом через Raft хранилище конфигурации может быть задано множество вариантов совместимости любой версии схемы с любой версией приложения. Этот признак совместимости имеет приоритет над первым. Т.е. когда Picodata запускает приложение, сначала проверяется признак совместимости согласно глобальной кластерной конфигурации: если совместимо, то Picodata запускает приложение НЕЗАВИСИМО ОТ ПРАВИЛ SEMVER. Предполагается, что администратору может понадобиться задать совместимость таким образом при решении проблем, см. пример ниже.
Проверка совместимости версий включена по умолчанию, но её можно выключить в случае если пользователь отдаёт отчёт в своих действиях.
Проверка совместимости версий включена по умолчанию, но ее можно выключить в случае если пользователь отдает отчет в своих действиях.
### Явное задание совместимости версий приложения и схемы
Приведём пример, когда нужно воспользоваться явным способом задания совместимости между приложением и схемой данных. Это и есть _опциональный_ способ, указанный выше.
Приведем пример, когда нужно воспользоваться явным способом задания совместимости между приложением и схемой данных. Это и есть _опциональный_ способ, указанный выше.
Выпущена новая версия приложения и новая обратно несовместимая версия схемы:
...
...
@@ -30,7 +30,7 @@
стало: 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. Но оно не запустится на схеме v2.0.0 даже если отключить проверку совместимости версий. Для решения проблемы схему меняют так, чтобы приложение v5 могло запуститься. Этим изменениям схемы присваивают версию v3.0.0. Глобально в конфигурации кластера задается совместимость app v5 и schema v3.0.0. После этого приложение v5 можно запустить в кластере с версией схемы v3.0.0, хотя приложение v5 было разработано и собрано в прошлом, когда про схему v3.0.0 еще не было известно.
### Алгоритм запуска инстанса.
1. Подключиться к Raft-группе (кластеру) и актуализировать журнал Raft.
...
...
@@ -47,9 +47,9 @@
Под временем простоя (downtime) подразумевается длительный промежуток времени, когда клиенты приложения Picodata не могут в полной мере пользоваться его функциями. Мероприятия, связанные со вводом резервных узлов в рамках отказоустойчивости (switchover, failover), происходят относительно быстро и не считаются простоем. Перезапуск репликасета Tarantool со снапшотами по 10 GB считается долгим, т.к. может занять более 10 минут, поэтому считается простоем.
Существует два варианта обновления: простой и сложный.
Простой вариант. В этом варианте обновления будут проходить с простоем на время, пока все инстансы будут обновлены, перезапущены, и затем в них запустится Tarantool, который загрузит последнее сохраненное состояние БД из файла *.snap* и применит изменения из журнала последних операций (*.xlog*). Для выполнения такого обновления нужно обновить файлы приложения и перезапустить все инстансы в любом порядке: по одному или все сразу.
__Простой вариант__. В этом варианте обновления будут проходить с простоем на время, пока все инстансы будут обновлены, перезапущены, и затем в них запустится Tarantool, который загрузит последнее сохраненное состояние БД из файла *.snap* и применит изменения из журнала последних операций (*.xlog*). Для выполнения такого обновления нужно обновить файлы приложения и перезапустить все инстансы в любом порядке: по одному или все сразу.
Сложный вариант состоит в обновлении приложения Picodata без простоя.
__Сложный вариант__ состоит в обновлении приложения Picodata без простоя.
1. Потребуется в каждом репликасете остановить все инстансы, кроме одного. Рекомендуется останавливать резервные реплики и оставлять работать активную реплику.
1. Обновить файлы приложения на остановленных инстансах.
