Назад | Перейти на главную страницу

Какое аварийное переключение поддерживает Sql azure автоматически?

Я немного смущен тем, как на самом деле работает аварийное переключение с SQL Azure и что нам нужно реализовать, а также то, что есть из коробки.

Я прочитал эту статью

https://azure.microsoft.com/en-us/blog/fault-tolerance-in-windows-azure-sql-database/

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

Все подключения к базам данных Windows Azure SQL Database управляются набором процессов шлюза с балансировкой нагрузки. Шлюз отвечает за прием входящих запросов на подключение к базе данных от клиентов и привязку их к узлу, на котором в настоящее время размещается первичная реплика базы данных. Шлюзы координируют свою работу с распределенной структурой, чтобы найти первичную реплику баз данных клиента. В случае переключения при отказе шлюзы повторно согласовывают привязку всех подключений, привязанных к отказавшему первичному серверу, к новому первичному серверу, как только он становится доступным.

А потом я прочитал эту статью

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-designing-cloud-solutions-for-disaster-recovery/?rnd=1

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

Итак, я неправильно это читаю? Первая статья (старая) устарела?

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

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

Оба они верны и охватывают два разных сценария использования одной и той же службы.