#azure-service-fabric #service-fabric-stateful
#azure-service-fabric #service-fabric-с сохранением состояния
Вопрос:
Я заметил, что при обновлении моего приложения, содержащего service fabric с отслеживанием состояния, при необходимости будет продвигать старые версии в primary, чтобы очистить путь для обновления домена.
Это приводит к проблемам, когда выталкивается версия, не совместимая с обратной совместимостью. Например, допустим, мои службы запрашивают базу данных, поскольку они повышаются до основного. Если я нажимаю более старую версию, в которой отсутствует недавно добавленный столбец базы данных, роли базы данных возвращаются к этой версии и удаляют столбец. Затем во время обновления fabric пытается продвинуть старый экземпляр в primary, но это не удается, потому что старый экземпляр ищет столбец, которого больше нет в базе данных. Это приводит к сбою всего обновления.
Есть ли способ обновить приложение, но избежать того, чтобы fabric продвигал текущую (перед развертыванием) версию моей службы на основную?
Комментарии:
1. Мой подход обычно заключается в том, чтобы вносить изменения только для переадресации базы данных, поэтапно, чтобы избежать прерывания изменений. Например, не удаляйте (старый) столбец в развертывании базы данных до тех пор, пока текущая и следующая версии кода больше не будут полагаться на него. Недостатком этого подхода является то, что нужно не забывать выполнять очистку!
2. Это сложно в тяжелом магазине функциональных возможностей, где среды видят много разных ветвей решения. Я склоняюсь к использованию ServiceTypeHealthPolicyMap, чтобы разрешить неработающие службы, чтобы обновления были успешными, а новые экземпляры были исправными.
3. Если миграция базы данных не прерывается, то это не должно вызывать проблем между ветвями — во всяком случае, вы могли бы использовать такой подход для этого преимущества. Однако я не знаю вашей конкретной настройки, поэтому трудно точно сказать.
4. мы используем проект базы данных .net для синхронизации схемы БД с выпуском. Возможно, мы сможем настроить его так, чтобы не удалять столбцы, но все же это не так просто, как «текущая версия кода» и «следующая версия кода», когда в одном спринте есть десятки ветвей функций без присущего хронологического порядка.
5. Просто для полноты картины — мой комментарий «текущие и следующие версии кода» относится к тому, что активно для одного развертывания в одной среде.