Активная георепликация
Область применения:
База данных SQL Azure
Активная георепликация — это функция, которая позволяет создавать непрерывно синхронизированные базы данных-получателя для чтения для базы данных-источника. Доступная для чтения база данных-получатель может находиться в том же регионе, что и база данных-источник, однако чаще всего эти базы данных находятся в разных регионах. Этот тип доступной для чтения базы данных-получателя также называется георепликой или георепликой.
Активная георепликация разработана в качестве решения для обеспечения непрерывности бизнес-процессов, которое позволяет выполнять быстрое аварийное восстановление отдельных баз данных в случае регионального или крупномасштабного простоя. После настройки георепликации вы можете инициировать географически распределенную отработку отказа во вторичную геореплику в другом регионе Azure. Географически распределенная отработка отказа инициируется программно приложением или вручную пользователем.
Примечание
Если нужно выполнить географическую отработку отказа экземпляров службы "Управляемый экземпляр SQL", см. статью Группы автоматической отработки отказа. Дополнительные сведения см. в статье Сравнение георепликации с группами отработки отказа. Управляемый экземпляр SQL Azure не поддерживает активную георепликацию.
Примечание
Сведения о переносе баз данных SQL из Azure для Германии с помощью активной георепликации см. в статье Миграция базы данных SQL с помощью активной георепликации.
Если приложению требуется стабильная конечная точка подключения и поддержка автоматической географически распределенной отработки отказа в дополнение к георепликации, используйте группы автоматической отработки отказа.
На следующей схеме показана типичная конфигурация геоизбыточного облачного приложения, использующего активную георепликацию.
Если в базе данных-источнике по какой-либо причине происходит сбой, вы можете инициировать географически распределенную отработку отказа в любую из баз данных-получателей. Когда база данных-получатель становится базой данных-источником, все остальные базы данных-получатели автоматически связываются с новой базой данных-источником.
Вы можете управлять георепликацией и инициировать географически распределенную отработку отказа с помощью следующих средств:
- портал Azure.
- PowerShell: отдельную базу данных;
- PowerShell: эластичный пул;
- Transact-SQL: отдельную базу данных или эластичный пул;
- REST API: отдельную базу данных;
Активная георепликация использует группу доступности AlwaysOn для асинхронной репликации журнала транзакций, созданного на первичной реплике, на все геореплики. Хотя в определенный момент времени база данных-получатель может немного отстать от базы данных-источника, данные в базе данных-получателе будут всегда согласованы с точки зрения транзакций. Другими словами, изменения, внесенные незафиксированными транзакциями, не будут видны.
Примечание
Активная георепликация реплицирует изменения путем потоковой передачи журнала транзакций базы данных с первичной реплики на вторичные реплики. Она не связана с репликацией транзакций, при которой изменения реплицируются путем выполнения команд на языке DML (INSERT, UPDATE и DELETE) на подписчиках.
Региональная избыточность, обеспечиваемая георепликацией, позволяет быстро восстанавливать приложения после необратимой потери всего региона Azure или его частей, вызванной стихийным бедствием, неисправимыми человеческими ошибками или вредоносными действиями. Сведения о целевой точке восстановления георепликации можно найти в разделе Общие сведения об обеспечении непрерывности бизнес-процессов.
На следующем рисунке показан пример активной георепликации, при которой база данных-источник находится в регионе "Центрально-северная часть США", а вторичная геореплика — в регионе "Центрально-южная часть США".
Активная георепликация может использоваться не только для аварийного восстановления, но и в следующих сценариях:
- Перенос баз данных: с помощью активной георепликации можно перенести базу данных с одного сервера на другой с минимальным временем простоя.
- Обновления приложения: при обновлении приложения вы можете создать дополнительную базу данных-получатель как резервную копию на случай сбоя.
Добавление избыточности баз данных между регионами — только часть решения для достижения полноценной непрерывности бизнес-процессов. Для комплексного восстановления приложения (службы) после катастрофического сбоя необходимо восстановить все компоненты, из которых состоит служба и все зависимые службы. К примерам этих компонентов относятся клиентское программное обеспечение (например, браузер с пользовательским кодом JavaScript), интерфейсные веб-серверы, хранилище и DNS. Очень важно, чтобы все компоненты были устойчивы к одинаковым сбоям и становились доступными в соответствии с целевым временем восстановления (RTO) вашего приложения. Следовательно, необходимо определить все зависимые службы и получить сведения о гарантиях и возможностях, которые они предоставляют. Затем необходимо выполнить соответствующие действия, чтобы обеспечить работу службы во время отработки отказа служб, от которых она зависит. Дополнительные сведения о проектировании решений для аварийного восстановления см. в статье о разработке облачных решений для аварийного восстановления с помощью активной георепликации.
Терминология и возможности активной георепликации
Автоматическая асинхронная репликация
Вторичную геореплику можно создать только для существующей базы данных. Вторичная геореплика может быть создана на любом логическом сервере за исключением сервера с базой данных-источником. После создания вторичная геореплика заполняется данными из базы данных-источника. Этот процесс называется заполнением. После создания и начального заполнения вторичной геореплики обновления базы данных-источника асинхронно и автоматически реплицируются во вторичную геореплику. Асинхронная репликация означает, что транзакции фиксируются в базе данных-источнике перед их репликацией.
Доступные для чтения вторичные геореплики
Приложение может получить доступ ко вторичной геореплике для выполнения запросов только для чтения с использованием тех же или других субъектов безопасности, которые применяются для доступа к базе данных-источнику. Дополнительные сведения см. в разделе Использование реплик только для чтения с целью разгрузить рабочие нагрузки от запросов только на чтение.
Важно!
Георепликацию можно использовать для создания вторичных реплик в том же регионе, в котором находится база данных-источник. Эти вторичные реплики могут использоваться для выполнения сценариев горизонтального масштабирования для чтения в том же регионе. Однако вторичная реплика в том же регионе не обеспечивает дополнительной устойчивости к катастрофическим ошибкам или крупномасштабным простоям, поэтому она не может использоваться в качестве цели отработки отказа при аварийном восстановлении. Кроме того, она не гарантирует изоляцию зоны доступности. Для изоляции зоны доступности используйте конфигурацию с избыточностью в пределах зоны на уровне служб "Критически важный для бизнеса" или "Премиум" или конфигурацию с избыточностью в пределах зоны на уровне служб "Общего назначения".
Запланированная географически распределенная отработка отказа
Запланированная географически распределенная отработка отказа приводит к смене ролей базы данных-источника и базы данных-получателя после завершения полной синхронизации данных. Запланированная отработка отказа не приводит к потере данных. Продолжительность запланированной географически распределенной отработки отказа зависит от размера журнала транзакций в базе данных-источнике, которую необходимо синхронизировать со вторичной георепликой. Запланированная географически распределенная отработка отказа предназначена для следующих сценариев:
- Тестирование аварийного восстановления (DR) в рабочей среде в случае, если потеря данных неприемлема.
- Перемещение базы данных в другой регион.
- Возвращение базы данных в основной регион после устранения сбоя (восстановление размещения).
Незапланированная географически распределенная отработка отказа
При незапланированной или принудительной географически распределенной отработке отказа вторичная геореплика немедленно переключается на основную роль без какой-либо синхронизации с базой данных-источником. Все транзакции, зафиксированные в базе данных-источнике, но еще не реплицированные в базу данных-получатель, теряются. Эта операция служит в качестве метода восстановления во время простоев, когда база данных-источник недоступна, но ее доступность должна быть быстро восстановлена. Когда исходная первичная база данных снова подключена, она будет автоматически повторно подключена, повторно добавлена с использованием текущих первичных данных и станет новой георепликой.
Важно!
После запланированной или незапланированной географически распределенной отработки отказа конечная точка подключения для новой базы данных-источника изменяется, так как новая база данных-источник теперь расположена на другом логическом сервере.
Несколько доступных для чтения вторичных геореплик
Для базы данных-источника можно создать до четырех вторичных геореплик. Если имеется только одна база данных-получатель и на ней происходит сбой, приложение подвергается более высокому риску, пока не будет создана новая база данных-получатель. Если существует несколько баз данных-получателей, то приложение остается защищенным даже при сбое одной из баз данных-получателей. Дополнительные базы данных-получатели также могут использоваться для горизонтального увеличения масштаба рабочих нагрузок только для чтения.
Совет
Если вы используете активную георепликацию, чтобы создать глобально распределенное приложение, и вам необходимо предоставить доступ только для чтения к данным, находящимся более чем в четырех регионах, вы можете создать базу данных-получатель для первой базы данных-получателя (цепочку), чтобы получить дополнительные геореплики. Задержка репликации для геореплик, объединенных в цепочку, может быть выше чем для геореплик, подключенных напрямую к базе данных-источнику. Настройка топологий для геореплик, объединенных в цепочку, может осуществляться только программным способом и не может выполняться на портале Azure.
Георепликация баз данных в эластичном пуле
Каждая вторичная геореплика может быть отдельной базой данных или базой данных в эластичном пуле. Выбор эластичного пула для каждой базы данных-получателя с георепликацией осуществляется отдельно и не зависит от конфигурации других реплик в топологии (источников или получателей). Каждый эластичный пул находится на одном логическом сервере. Так как имена баз данных на логическом сервере должны быть уникальными, несколько вторичных геореплик одной и той же базы данных-источника не могут совместно использовать эластичный пул.
Управляемые пользователем географически распределенная отработка отказа и восстановление размещения
Вторичная геореплика, которая завершила начальное заполнение, может быть явным образом переключена на основную роль (путем отработки отказа) приложением или пользователем. Во время простоя, когда первичная реплика недоступна, может использоваться только незапланированная географически распределенная отработка отказа. При этом вторичная геореплика немедленно становится новой первичной репликой. После устранения сбоя система автоматически превращает восстановленную первичную реплику во вторичную геореплику и синхронизирует ее с новой первичной репликой. Из-за асинхронной природы георепликации последние транзакции могут быть утеряны во время незапланированных географически распределенных отработок отказа, если в первичной реплике возникает сбой до того, как эти транзакции были реплицированы во вторичную геореплику. При отработке отказа первичной реплики с несколькими вторичными георепликами система автоматически перенастраивает отношения репликации и связывает оставшиеся вторичные геореплики с новой первичной репликой без какого-либо вмешательства пользователя. После устранения сбоя, который вызвал географически распределенную отработку отказа, желательно вернуть первичную реплику в исходный регион. Для этого можно вызвать запланированную географически распределенную отработку отказа.
Подготовка к географически распределенной отработке отказа
Чтобы гарантировать, что приложение сможет получить доступ к новой базе данных-источнику сразу же после географически распределенной отработки отказа, убедитесь в том, что проверка подлинности и сетевой доступ для сервера-получателя настроены правильно. Дополнительные сведения см. в разделе Безопасность базы данных SQL после аварийного восстановления. Кроме того, убедитесь, что политика хранения резервных копий для базы данных-получателя соответствует этой политике для базы данных-источника. Этот параметр не является частью базы данных и не реплицируется из базы данных-источника. По умолчанию для базы данных-получателя с георепликацией устанавливается период хранения для восстановления на определенный момент времени, равный 7 дням. Дополнительные сведения см. в статье Подробнее о резервном копировании базы данных SQL.
Важно!
Если база данных входит в состав группы отработки отказа, запустить отработку ее отказа с помощью команды отработки отказа георепликации нельзя. Используйте команду отработки отказа для группы. Если необходимо выполнить отработку отказа отдельной базы данных, сначала нужно удалить ее из группы отработки отказа. Дополнительные сведения см. в разделе Группы автоматической отработки отказа.
Настройка вторичной геореплики
Первичная реплика и вторичная геореплика должны иметь один и тот же уровень служб. Кроме того, настоятельно рекомендуется настроить для вторичной геореплики тот же уровень избыточности хранилища резервных копий и объем вычислительных ресурсов (единиц передачи данных или виртуальных ядер), что и для первичной реплики. Когда первичная реплика испытывает значительную рабочую нагрузку при записи, вторичная геореплика может не успевать за ней, если ее объем вычислительных ресурсов меньше. Это приведет к задержке репликации на вторичной геореплике и в конечном итоге может привести к недоступности вторичной геореплики. Чтобы исключить эти риски, активная георепликация будет уменьшать (ограничивать) скорость обработки журнала транзакций первичной реплики, если это необходимо для того, чтобы вторичные реплики успевали за ней.
Еще одним следствием несбалансированной конфигурации вторичной геореплики является то, что после отработки отказа производительность приложения может быть снижена из-за недостаточной емкости вычислительных ресурсов новой первичной реплики. В этом случае потребуется вертикально увеличить масштаб базы данных, так чтобы она имела достаточные ресурсы. Для этого может потребоваться длительное время, а в конце увеличения масштаба потребуется провести отработку отказа для высокодоступных систем, что может привести к прерыванию рабочих нагрузок приложения.
Если вы решите создать вторичную геореплику с более низким объемом вычислительных ресурсов, необходимо отслеживать частоту операций ввода-вывода журнала на первичной реплике с течением времени. Это позволяет оценить минимальный размер вычислительных ресурсов вторичной геореплики, необходимый для удовлетворения нагрузки репликации. Например, если уровень базы данных-источника — P6 (1000 DTU) и процент операций ввода-вывода журнала для нее равен 50 %, то уровень вторичной геореплики должен быть не ниже P4 (500 DTU). Чтобы получить исторические данные журнала ввода-вывода, используйте представление sys.resource_stats. Для получения последних данных об операциях ввода-вывода журнала с большей степенью детализации, которые лучше отражают краткие всплески активности, используйте представление sys.dm_db_resource_stats.
Совет
Отчет об ограничении операций ввода-вывода журнала транзакций на первичной реплике из-за меньшего объема вычислительных ресурсов во вторичной геореплике, формируется с помощью типа ожидания HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO. Этот отчет можно просмотреть в представлениях базы данных sys.dm_exec_requests и sys.dm_os_wait_stats.
Число операций ввода-вывода журнала транзакций на первичной реплике может ограничиваться по причинам, не связанным с меньшим объемом вычислительных ресурсов на вторичной геореплике. Подобное регулирование может иметь место даже в том случае, если вторичная геореплика имеет аналогичный или больший объем вычислительных ресурсов по сравнению с первичной репликой. Подробные сведения, включая сведения о типах ожидания при различных видах регулирования операций ввода-вывода журнала, см. в статье Управление скоростью журнала транзакций.
По умолчанию избыточность хранилища резервных копий вторичной геореплики аналогична избыточности хранилища резервных копий базы данных-источника. При настройке вторичной геореплики можно выбрать другую избыточность хранилища резервных копий. Резервные копии всегда создаются в базе данных-источнике. Если для вторичной геореплики выбрана другая избыточность хранилища резервных копий, то после отработки отказа при повышении уровня вторичной геореплики до уровня первичной реплики плата за резервные копии будет взиматься в соответствии с типом хранилища (RA-GRS, ZRS, LRS), выбранным для новой первичной реплики (предыдущей вторичной реплики), и резервные копии будут размещаться в этом хранилище.
Георепликация при наличии нескольких подписок
Чтобы создать вторичную геореплику в подписке, которая отличается от подписки первичной реплики (независимо от того, находятся ли эти подписки в одном и том же клиенте Azure Active Directory), выполните действия, описанные в этом разделе.
Добавьте IP-адрес клиентского компьютера, на котором выполняются указанные ниже команды T-SQL, в брандмауэры сервера как на сервере-источнике, так и на сервере-получателе. Чтобы проверить этот IP-адрес, выполните следующий запрос, подключившись к серверу-источнику с того же клиентского компьютера.
select client_net_address from sys.dm_exec_connections where session_id = @@SPID;Дополнительные сведения см. в разделе Настройка брандмауэра.
masterВ базе данных на сервере-источнике создайте имя входа для проверки подлинности SQL, выделенное для активной настройки георепликации. При необходимости измените имя пользователя и пароль.create login geodrsetup with password = 'ComplexPassword01';В той же базе данных создайте пользователя для входа и добавьте его в роль
dbmanager:create user geodrsetup for login geodrsetup; alter role dbmanager add member geodrsetup;Запишите значение SID для нового имени входа. Чтобы получить значение SID, выполните следующий запрос.
select sid from sys.sql_logins where name = 'geodrsetup';Подключитесь к базе данных-источнику (не базе
masterданных) и создайте пользователя для того же имени входа.create user geodrsetup for login geodrsetup;В той же базе данных добавьте пользователя к роли
db_owner.alter role db_owner add member geodrsetup;masterВ базе данных на сервере-получателе создайте то же имя входа, что и на сервере-источнике, используя то же имя, пароль и идентификатор безопасности. Замените шестнадцатеричное значение SID в примере команды ниже на значение, полученное на Шаге 4.create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E;В той же базе данных создайте пользователя для входа и добавьте его в роль
dbmanager.create user geodrsetup for login geodrsetup; alter role dbmanager add member geodrsetup;Подключитесь к
masterбазе данных на сервере-источнике с помощью новогоgeodrsetupимени входа и инициируйте создание георепликации на сервере-получателе. При необходимости измените имя базы данных и сервера-получателя. После выполнения команды можно отслеживать создание георепликации, запрашивая представление sys.dm_geo_replication_link_status в базе данных-источнике и представление sys.dm_operation_status вmasterбазе данных на сервере-источнике . Время, необходимое для создания вторичной геореплики, зависит от размера базы данных-источника.alter database [dbrep] add secondary on server [servername];После успешного создания вторичной геореплики можно удалить пользователей, имена входа и правила брандмауэра, созданные в ходе этой процедуры.
Примечание
Операции георепликации между подписками, в том числе настройки и географически распределенной отработки отказа, поддерживаются только при использовании команд REST API и T-SQL.
Добавление вторичной геореплики с помощью T-SQL при подключении к основному серверу через частную конечную точку не поддерживается. Если частная конечная точка настроена и общий доступ к сети разрешен, то добавление вторичной геореплики при подключении к серверу-источнику с общедоступного IP-адреса поддерживается. После добавления геореплики можно запретить доступ к общедоступной сети.
Создание вторичной геореплики на логическом сервере в другом клиенте Azure не поддерживается, если на первичном или вторичном логическом сервере активна (включена) только проверка подлинности Azure Active Directory для Azure SQL.
Синхронизация учетных данных и правил брандмауэра
При использовании общего доступа к сети для подключения к базе данных рекомендуется применять правила брандмауэра для IP-адресов на уровне базы данных для геореплицированных баз данных. Эти правила реплицируются в базу данных, что позволяет гарантировать, что на всех вторичных георепликах будут использоваться те же правила брандмауэра для IP-адресов, что и на первичной реплике. Такой подход избавляет клиентов от необходимости вручную настраивать и обслуживать правила брандмауэра на серверах, на которых размещаются базы данных-источники и базы данных-получатели. Точно так же, применение пользователей автономной базы данных для доступа к данным гарантирует, что база данных-источник и база данных-получатель всегда будут иметь одинаковые учетные данные проверки подлинности. Таким образом, после географической отработки отказа не возникнет никаких сбоев из-за несоответствия учетных данных проверки подлинности. Если вы используете имена входа и пользователей (а не пользователей автономной базы данных), выполните дополнительные действия для синхронизации имен входа с базой данных-получателем. Сведения о конфигурации см. в статье Настройка имен входа и пользователей.
Масштабирование базы данных-источника
Вы можете вертикально увеличивать или уменьшать масштаб вычислительных ресурсов базы данных-источника с переходом на другой размер вычисления (в рамках одного уровня служб) без отключения вторичных геореплик. При этом рекомендуется сначала вертикально увеличить масштаб вторичной геореплики, а затем вертикально увеличить масштаб первичной реплики. При вертикальном уменьшении масштаба действия следует выполнять в обратном порядке: сначала для первичной реплики, затем — для вторичной реплики.
Примечание
Если вы создали вторичную геореплику в рамках конфигурации группы отработки отказа, то вертикально уменьшать масштаб этой реплики не рекомендуется. Это необходимо для того, чтобы уровень данных обладал достаточной емкостью для обработки обычной рабочей нагрузки после географически распределенной отработки отказа.
Важно!
База данных-источник в группе отработки отказа не может масштабироваться до более высокого уровня служб (выпуска) без предварительного масштабирования базы данных-получателя до более высокого уровня. Например, если вы хотите вертикально увеличить масштаб первичной реплики с уровня "Общего назначения" до уровня "Критически важный для бизнеса", необходимо сначала масштабировать вторичную геореплику до уровня "Критически важный для бизнеса". При попытке масштабировать первичную реплику или вторичную геореплику с нарушением этого правила возникнет следующая ошибка:
The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.
Предотвращение потери критически важных данных
Из-за высокой задержки в глобальных сетях георепликация использует механизм асинхронной репликации. Асинхронная репликация делает неизбежной возможность потери данных при отказе первичной реплики. Чтобы защитить эти критические транзакции от потери данных, разработчик приложения может вызвать хранимую процедуру sp_wait_for_database_copy_sync сразу же после фиксации транзакции. Вызов sp_wait_for_database_copy_sync блокирует вызывающий поток, пока последняя зафиксированная транзакция не будет передана и журнал транзакций базы данных-получателя и зафиксирована в нем. Но вызов не дожидается воспроизведения (повторной обработки) транзакций в базе данных-получателе. Областью действия процедуры sp_wait_for_database_copy_sync является определенная связь георепликации. Эту процедуру может вызвать любой пользователь с правами подключения к базе данных-источнику.
Примечание
Процедура sp_wait_for_database_copy_sync предотвращает потерю данных после географически распределенной отработки отказа, но не гарантирует полную синхронизацию для доступа на чтение. Вызванная вызовом процедуры sp_wait_for_database_copy_sync задержка может быть продолжительной и зависит от размера еще не переданного журнала транзакций базы данных-источника во время вызова.
Отслеживание задержки георепликации
Чтобы отслеживать задержку, связанную с целевой точкой восстановления, используйте в базе данных-источнике столбец replication_lag_sec в разделе sys.dm_geo_replication_link_status. В нем указывается задержка в секундах между транзакциями, зафиксированными в базе данных-источнике и сохраненными в журнале транзакций базы данных-получателя. Например, если задержка составляет одну секунду, это означает, что в базе данных-источнике сейчас имеет место простой и запущена географически распределенная отработка отказа, при этом транзакции, зафиксированные за последнюю секунду, будут потеряны.
Чтобы измерить задержку при внесении изменений в базу данных-источник, которые были применены ко вторичной геореплике, сравните время last_commit во вторичной геореплике с аналогичным значением в базе данных-источнике.
Совет
Иногда параметру replication_lag_sec в базе данных-источнике бывает присвоено значение NULL. Это означает, что сейчас в базе данных-источнике нет сведений о том, насколько отстает от нее вторичная геореплика. Обычно это временное состояние, наступающее после перезапуска процесса. Если replication_lag_sec возвращает значение NULL в течение продолжительного периода времени, вы можете отправить предупреждение. Это может означать, что вторичная геореплика не может связаться с базой данных-источником из-за проблем с подключением.
Также существуют условия, которые могут привести к увеличению разницы между временем last_commit во вторичной геореплике и в базе данных-источнике. Например, если в базе данных-источнике выполняется фиксация после отсутствия изменений в течение длительного времени, то разница вырастет до большого значения, а затем быстро вернется к нулю. Если разница между этими двумя значениями остается слишком большой в течение длительного времени, можно отправить оповещение.
Программное управление активной георепликацией
Как уже говорилось ранее, активной георепликацией можно также управлять программно с помощью T-SQL, Azure PowerShell и REST API. В приведенных ниже таблицах описан доступный для этого набор команд. Активная георепликация включает в себя набор API-интерфейсов Azure Resource Manager для управления, в том числе REST API Базы данных SQL Azure и командлеты Azure PowerShell. Эти API поддерживают управление доступом Azure на основе ролей (Azure RBAC). Дополнительные сведения о том, как реализовать контроль доступа на основе ролей, см. в статье Управление доступом на основе ролей (Azure RBAC).
T-SQL: управление географически распределенной отработкой отказа для отдельных баз данных и баз данных в пуле
Важно!
Приведенные ниже команды T-SQL применяются только к активной георепликации и не применяются к группам отработки отказа. Поэтому они также не применяются к Управляемому экземпляру SQL, который поддерживает только группы отработки отказа.
| Команда | Описание |
|---|---|
| ALTER DATABASE | Используйте аргумент ADD SECONDARY ON SERVER, чтобы создать базу данных-получатель для существующей базы данных и начать репликацию данных. |
| ALTER DATABASE | Используйте аргумент FAILOVER или FORCE_FAILOVER_ALLOW_DATA_LOSS, чтобы задать базу данных-получатель в качестве базы данных-источника для запуска отработки отказа. |
| ALTER DATABASE | Используйте аргумент REMOVE SECONDARY ON SERVER, чтобы завершить репликацию данных между Базой данных SQL и указанной базой данных-получателем. |
| sys.geo_replication_links | Возвращает сведения о всех существующих связях репликации для каждой базы данных на сервере. |
| sys.dm_geo_replication_link_status | Получает время последней репликации, задержку при последней репликации и другие сведения о связи репликации для заданной базы данных. |
| sys.dm_operation_status | Показывает состояние всех операций с базой данных, включая изменения связей репликации. |
| sys.sp_wait_for_database_copy_sync | Приложение будет ожидать, пока все зафиксированные транзакции не будут записаны в журнал транзакций вторичной геореплики. |
PowerShell: управление географически распределенной отработкой отказа для отдельных баз данных и баз данных в пуле
Примечание
В этой статье предусмотрено использование модуля Azure Az PowerShell, который является рекомендуемым модулем PowerShell для взаимодействия с Azure. Чтобы начать работу с модулем Az PowerShell, ознакомьтесь со статьей Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.
Важно!
Модуль PowerShell Azure Resource Manager по-прежнему поддерживается базой данных SQL Azure, но вся будущая разработка сосредоточена на модуле Az.Sql. Сведения об этих командлетах см. в разделе AzureRM.Sql. Аргументы команд в модулях Az и AzureRm практически идентичны.
| Командлет | Описание |
|---|---|
| Get-AzSqlDatabase | Получает одну или несколько баз данных. |
| New-AzSqlDatabaseSecondary | Создает базу данных-получатель для существующей базы данных и начинает репликацию данных. |
| Set-AzSqlDatabaseSecondary | Преобразует базу данных-получатель в базу данных-источник для запуска отработки отказа. |
| Remove-AzSqlDatabaseSecondary | Завершает репликацию данных между базой данных SQL и указанной базой данных-получателем. |
| Get-AzSqlDatabaseReplicationLink | Получает связи георепликации для базы данных. |
Совет
Дополнительные сведения о примерах сценариев см. в статьях Настройка активной георепликации для отдельной базы данных SQL Azure с помощью PowerShell и Настройка активной георепликации для базы данных SQL Azure в пуле с помощью PowerShell.
REST API: управление географически распределенной отработкой отказа для отдельных баз данных и баз данных в пуле
| API | Описание |
|---|---|
| Создание или обновление базы данных (createMode=Restore) | Создает, обновляет или восстанавливает базу данных-источник или базу данных-получатель. |
| Получение, создание или обновление состояния базы данных | Возвращает состояние во время операции создания. |
| Задание базы данных-получателя в качестве базы данных-источника (плановая отработка отказа) | Задает базу данных-получатель в качестве базы данных-источник. Для этого выполняется отработка отказа из текущей базы данных-источник. Этот параметр не поддерживается в Управляемом экземпляре SQL. |
| Задание базы данных-получателя в качестве базы данных-источника (внеплановая отработка отказа) | Задает базу данных-получатель в качестве базы данных-источник. Для этого выполняется отработка отказа из текущей базы данных-источник. Эта операция может привести к потере данных. Этот параметр не поддерживается в Управляемом экземпляре SQL. |
| Получение связи репликации | Получает определенную связь репликации для заданной базы данных, участвующей в партнерстве георепликации. Извлекает сведения, отображаемые в представлении каталога sys.geo_replication_links. Этот параметр не поддерживается в Управляемом экземпляре SQL. |
| Replication Links - List By Database (Ссылки для репликации: вывод списка по базе данных) | Получает все связи репликации для заданной базы данных, участвующей в партнерстве георепликации. Извлекает сведения, отображаемые в представлении каталога sys.geo_replication_links. |
| Удаление связей репликации | Удаляет связь репликации базы данных. Невозможно выполнить во время отработки отказа. |
Дальнейшие действия
- Ознакомьтесь с примерами скриптов в следующих статьях:
- В Базе данных SQL Azure также поддерживаются группы автоматической отработки отказа. Дополнительные сведения см. в этой статье.
- Сведения об обеспечении непрерывности бизнес-процессов и возможные сценарии описаны в обзоре непрерывности бизнес-процессов.
- Чтобы узнать об автоматически создаваемых резервных копиях базы данных SQL Azure, ознакомьтесь с разделом Общие сведения об автоматическом резервном копировании базы данных SQL.
- Чтобы узнать об использовании автоматически создаваемых резервных копий для восстановления, ознакомьтесь с восстановлением базы данных из резервных копий, инициируемых службой.
- Дополнительные сведения о требованиях к проверке подлинности для новых сервера-источника и базы данных-источника см. в статье Безопасность базы данных SQL после аварийного восстановления.