Георепликация SQL Azure для целей, отличных от redunancy
Я просто провожу небольшое исследование о том, как создать крупномасштабное, глобально доступное приложение на Azure.
там уже много технологий, чтобы получить ваше приложение как можно ближе к потребителю.
- CDN пограничные серверы для статического контента, общего по всему миру.
- облачные службы в разных регионах, используя диспетчер трафика для маршрутизации доменного имени на ближайший хост приложения.
немного я немного смущает база данных. При использовании SQL Azure необходимо указать регион для его размещения. Если мой экземпляр SQL Azure находится в Западной Европе (Амстердам), но мои клиенты находятся в Австралии и получают доступ к приложению через экземпляр в Австралии (Новый Южный Уэльс), между приложением и базой данных будет некоторая задержка.
все ссылки, которые я видел о репликации Geo, похоже, находятся в контексте настройки избыточности Master-Slave. Но мне интересно это возможно иметь Мастер-Мастер установки, где каждый экземпляр приложения разговаривает с собственным экземпляром SQL Azure master в том же Гео-регионе, а затем sql azure будет заботиться о двунаправленной репликации между ними.
2 ответов
активная Георепликация для базы данных SQL Azure:
функция активной георепликации реализует механизм обеспечения избыточности базы данных в одном регионе Microsoft Azure или в разных регионах (георепликация). Активная Георепликация асинхронно реплицирует совершенные транзакции из базы данных до четырех копий базы данных на разных серверах. Исходная база данных становится основной базой данных непрерывное копирование. Каждая непрерывная копия называется активной базой данных-получателем. База данных-источник асинхронно реплицирует зафиксированные транзакции в каждую из активных баз данных-получателей. Хотя в любой момент активные вторичные данные могут немного отставать от базы данных-источника, гарантируется, что активные вторичные данные всегда будут согласовываться с изменениями, внесенными в базу данных-источник. Активная георепликация поддерживает до четырех активных вторичных, или до три активных вторичных и один автономный вторичный.
одним из основных преимуществ активной георепликации является то, что она обеспечивает решение аварийного восстановления на уровне базы данных. С помощью активной георепликации можно настроить пользовательскую базу данных на уровне службы Premium для репликации транзакций в базы данных на разных серверах баз данных Microsoft Azure SQL в одном или разных регионах. Резервирование кросс-региона позволяет применения взять от постоянной потери a центр обработки данных, вызванный стихийными бедствиями, катастрофическими человеческими ошибками или вредоносными актами.
еще одним ключевым преимуществом является то, что active базы данных-получатели читабельный. Таким образом активный вторичный может выступать в качестве балансировщика нагрузки для чтения рабочих нагрузок, таких как отчеты. Хотя можно создать активный вторичный сервер в другом регионе для аварийного восстановления, можно также иметь активный вторичный сервер в том же регионе на другом сервере. Оба активных получателей может быть используется для балансировки рабочих нагрузок только для чтения, обслуживающих клиентов, распределенных по нескольким регионам.
обратите внимание, что мастер-мастер нигде не упоминалось. Репликичитабельный, никогда не записывается. Поэтому вопрос действительно спорный, так как SQL Azure просто не поддерживает то, что вы хотите.
альтернативой будет шардинг уровня приложения и подключение каждого клиента к базе данных близости, но это предполагает, что данные не связаны (австралийские клиенты не посмотрите на южноамериканские предметы). См.ответ здесь.
вы также можете исследовать такие вещи, как Кассандра, который поддерживает то, что вы хотите, но является основным сдвигом парадигмы, и вам нужно будет разместить его и управлять им.
но вы также должны спросить: требуется ли master-master DB для достижения низкой задержки? Are пишет происходит так часто в вашем приложении? Задержка чтения может быть легко улучшена, поэтому у вас есть кэширование и CDNs для. Думать обо всех австралийских пользователях читать этот вопрос. Подается с георепликация базы данных для восстановления, не из БД master-master. См.как StackOverflow масштабирует SQL Server.
предостережение: я не работал с SQL Azure в этом отношении, но я много работал с гео-репликацией.
из того, что я могу сказать, вы правильно говорите, что Активный Гео-Репликации встроенная в Azure-это односторонняя копия-у вас есть главная база данных в одном месте, которая разделяет транзакции с другими базами данных, доступными только для чтения.
чтобы получить полную двустороннюю репликацию, это очень сложная задача. Этот возможности для условий отказа огромны и чрезвычайно трудны для того чтобы испытать. Вот почему трудно найти много людей, предлагающих двустороннюю репликацию с транзакционными базами данных - даже если у вас есть те же данные в ваших базах данных, они будут иметь разные истории транзакций и не будут точно отражать друг друга. Затем, когда вам нужно решить, какая база данных является авторитетной, все начинает усложняться быстро.
однако это не обязательно мешает нам возможность реализации практические двусторонняя репликация. Когда вы знаете свои собственные данные и понимаете, что нужно реплицировать, а что нет, вам больше не нужно решать репликацию как абстрактную проблему, поэтому вы можете создавать вокруг данных, которые у вас есть. Если вы планируете работать в таком масштабе, вы будете использовать много очередей уже для передачи данных вокруг места. Возьмем очень простой пример, если ваша служба помещает данные в очередь для база данных, чтобы иметь возможность забрать его, а затем вытащить его для хранения, было бы нетрудно поместить те же данные в очереди передачи в другие географические регионы во время обработки, которая сбрасывает его в базу данных.
в конечном итоге вам нужно спросить себя, сколько миллионов пользователей у вас есть и сколько гигабайт данных они будут толкать в ваши базы данных. Если эти цифры довольно низки, то двусторонняя репликация почти наверняка не нужна и слишком много думает об этом, вероятно, преждевременная оптимизация.