Sql Azure Database Mirroring для отработки отказа диспетчера трафика

Я пришел к выводу, что Sql Data Sync не идеален для моей стратегии отработки отказа MAWS и Sql Azure.

Активная георепликация для базы данных SQL Azure оказывается лучшим вариантом.

Вот некоторые моменты, которые я рассмотрел против Sql Data Sync.

1. Моя база данных с 450 таблицами и более чем 8 миллионами записей достаточно велика, чтобы внести дополнительную сложность и стоимость настройки, выполнения и поддержки двунаправленной или односторонней синхронизации данных Sql.

2. Sql Data Sync, похоже, не слишком сильно ориентирован на идею зеркального отображения больших баз данных между центрами обработки данных. С такими ограничениями, как 100 таблиц на группу синхронизации Azure.

3. Правильная настройка Sql Data Sync для моей базы данных потребует времени, потому что она включает в себя распространение 450 таблиц по нескольким меньшим и управляемым группам синхронизации с хорошо настроенными частотами синхронизации, и каждая из них протестирована, чтобы гарантировать, что синхронизация происходит без конфликтов. Требуется глубокий анализ базы данных, чтобы правильные таблицы были сгруппированы вместе, чтобы избежать конфликтов внешних ключей в целевой базе данных:

   http://www.mssqltips.com/sqlservertip/3062/understanding-sql-data-sync-for-sql-server/

4. Похоже, что Sql Data Sync не является моделью синхронизации транзакций:

Стратегия отработки отказа / резервного копирования SQL Azure для веб-приложения

5. Предварительная версия функции SQL Data Sync существует уже более 2 лет, последнее обновление было выпущено в декабре 2012 г.

6. Sql Data Sync имеет неотъемлемые проблемы при работе с большой схемой. Это было испытано на собственном опыте с моей схемой базы данных.

http://social.msdn.microsoft.com/forums/azure/en-US/9c679a74-9a7c-48e7-b4c9-95f6f7cfafd9/sql-azure-data-sync-refresh-schema-not-working

7. Подчеркивая первый пункт, двусторонняя репликация между центрами обработки данных - сложная задача и, как правило, не рекомендуется без интуитивного знания данных и схемы базы данных. В итоге можно было создать петли синхронизации.

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

http://www.mssqltips.com/sqlservertip/3062/understanding-sql-data-sync-for-sql-server/

9. Sql Data Sync удваивает таблицы, создавая еще большую схему, добавленную к моим 450 таблицам.

Что касается использования активной георепликации для базы данных SQL Azure, при отработке отказа можно просто разорвать отношения непрерывного копирования на активном вторичном сервере, чтобы он стал на чтение-запись.

Из http://msdn.microsoft.com/en-us/library/azure/dn741331.aspx

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

Что касается моего SLA для базы данных, у меня есть следующие сценарии.

1. Восстановление после случайного повреждения или удаления данных: Sql Azure Premium предлагает бесплатное автоматическое восстановление на определенный момент времени из коробки, поэтому нет необходимости настраивать ночное резервное копирование в хранилище BLOB-объектов. http://azure.microsoft.com/blog/2014/10/01/azure-sql-database-point-in-time-restore/.

2. Мониторинг соответствия нормативным требованиям, понимание активности базы данных и понимание расхождений и аномалий: Sql Azure предлагает аудит базы данных по многим аспектам http://azure.microsoft.com/en-us/documentation/articles/sql-database-auditing-get-start/

3. Межрегиональное резервирование для восстановления после необратимой потери центра обработки данных, вызванной стихийными бедствиями, катастрофическими человеческими ошибками или злонамеренным действием: Sql Azure предлагает активную георепликацию http://msdn.microsoft.com/en-us/library/azure/dn741339.aspx