Внедрение восстановления базы данных в Azure Service Fabric

Question

Упрощенное приложение для подключения к базе данных моей компании сегодня утром привело к отказу от нашей вторичной базы данных. В наших Azure App Services это был простой шаг по изменению строки подключения в конфигурации, однако я не смог найти простой способ изменить эти параметры в наших сервисах Service Fabric без повторного развертывания.

Я рассматриваю варианты, позволяющие отказоустойчиво во время выполнения этих служб для вторичной базы данных, но не знают, что такое «лучшие практики». Пара вариантов у меня есть:

1. я мог бы создать запись DNS для нашего сервера базы данных, я управлять, а затем просто переключиться, что на новое имя сервера, когда мне нужно, чтобы при сбое.

2. У меня может быть какой-то отдых api, чтобы вызвать мои службы приложений, которые вернутся независимо от того, нужно ли переходить во вторичную базу данных.

Любые другие идеи? Я хотел бы сделать переход на вторичный ресурс настолько плавным, насколько это возможно, поэтому это можно сделать быстро.

Answer 1

Вы считали, что вы вставляете в свою конфигурацию приложения как свои первичные, так и вторичные строки подключения базы данных и записываете код, который автоматически переключается между ними, если он обнаруживает проблему? Оба из представленных вами вариантов ставят человека на путь, а это означает, что ваши пользователи будут испытывать время простоя, пока человек не устранит проблему (возможно, человек спит или в отпуске или в отпуске и сном).

В сервисе Ткань, применение (и система) обновления всегда rolling upgrades. Преимущество прокатных линий заключается в предотвращении глобальных перебоев в работе. Например, предположим, что в какой-то момент вы обновили свою конфигурацию с помощью неправильной строки подключения. Глобальное изменение конфигурации может быть быстрым и легким, но теперь у вас есть глобальные сбои и некоторые расстроенные клиенты. Скользящее обновление могло бы поймать ошибку в первом домене обновления и затем отбросить назад, так что только часть вашего приложения была бы затронута.

Вы можете выполнить обновление только для конфигурации. Здесь вы вносите изменения в свой config package, а затем создаете differential upgrade package, так что только изменения конфигурации исчезают, и ваш процесс обслуживания не должен перезапускаться.

Answer 2

Просто опубликуйте обновление к моей проблеме здесь. В SQL Azure теперь есть автоматические группы отказоустойчивости. Это описано here