Создание и использование активной георепликацииCreating and using active geo-replication

Активная георепликация — это компонент Базы данных SQL Azure, который позволяет создавать читаемые базы данных-получатели отдельных баз данных на сервере Базы данных SQL в одном и том же или другом центре обработки данных (регионе).Active geo-replication is Azure SQL Database feature that allows you to create readable secondary databases of individual databases on a SQL Database server in the same or different data center (region).

Примечание

Управляемый экземпляр не поддерживает активную георепликацию.Active geo-replication is not supported by managed instance. Дополнительные сведения о географической отработке отказа см. в статье Использование групп автоматической отработки отказа для включения прозрачной и согласованной отработки отказа в нескольких базах данных.For geographic failover of managed instances, use Auto-failover groups.

Активная георепликация разработана в качестве решения для обеспечения непрерывности бизнес-процессов, которое позволяет приложению выполнять быстрое аварийное восстановление отдельных баз данных в случае регионального сбоя или сбоя масштабирования.Active geo-replication is designed as a business continuity solution that allows the application to perform quick disaster recovery of individual databases in case of a regional disaster or large scale outage. Если георепликация включена, приложение может инициировать отработку отказа в базу данных-получатель в другом регионе Azure.If geo-replication is enabled, the application can initiate failover to a secondary database in a different Azure region. В одном или разных регионах поддерживается до четырех баз данных-получателей, которые также можно использовать для запросов на доступ только для чтения.Up to four secondaries are supported in the same or different regions, and the secondaries can also be used for read-only access queries. Отработка отказа должна инициироваться вручную приложением пользователя.The failover must be initiated manually by the application or the user. После отработки отказа у новой базы данных-источника будет другая конечная точка подключения.After failover, the new primary has a different connection end point. На следующей схеме показана типичная конфигурация геоизбыточного облачного приложения, использующего активную георепликацию.The following diagram illustrates a typical configuration of a geo-redundant cloud application using Active geo-replication.

активная георепликация

Важно!

В Базе данных SQL Azure также поддерживаются группы автоматической отработки отказа.SQL Database also supports auto-failover groups. Дополнительные сведения см. в этой статье.For more information, see using auto-failover groups. Кроме того, активная георепликация не поддерживается для баз данных, созданных в Управляемом экземпляре.Also, active geo-replication is not supported for databases created within a Managed Instance. Рассмотрите возможность использования групп отработки отказа с Управляемыми экземплярами.Consider using failover groups with Managed Instances.

Если по какой-либо причине произойдет сбой вашей базы данных-источника (или вам просто потребуется перевести ее в автономный режим), вы можете выполнить отработку отказа на любую из доступных баз данных-получателей.If for any reason your primary database fails, or simply needs to be taken offline, you can initiate failover to any of your secondary databases. При активации отработки отказа в одной из баз данных-получателей все прочие получатели автоматически связываются с новой базой данных-источником.When failover is activated to one of the secondary databases, all other secondaries are automatically linked to the new primary.

Вы можете управлять репликацией и отработкой отказа отдельной базы данных или набора баз данных на сервере или в эластичном пуле с помощью активной георепликации.You can manage replication and failover of an individual database or a set of databases on a server or in an elastic pool using active geo-replication. Для этого используйте:You can do that using:

Активная георепликация использует технологию SQL Server AlwaysOn для асинхронной репликации зафиксированных транзакций в базе данных-источнике в базы данных-получатели с помощью изоляции моментального снимка.Active geo-replication leverages the Always On technology of SQL Server to asynchronously replicate committed transactions on the primary database to a secondary database using snapshot isolation. Группы автоматической отработки отказа обеспечивают групповую семантику на основе активной георепликации, однако используется тот же механизм асинхронной репликации.Auto-failover groups provide the group semantics on top of active geo-replication but the same asynchronous replication mechanism is used. Хотя в любой момент база данных-получатель может немного отстать от базы данных-источника, в базе данных-получателе никогда не будет частично выполненных транзакций.While at any given point, the secondary database might be slightly behind the primary database, the secondary data is guaranteed to never have partial transactions. Избыточность в различных регионах позволяет быстро восстанавливать приложения после необратимой потери всего центра обработки данных или его частей, вызванной стихийным бедствием, неисправимыми человеческими ошибками или вредоносными действиями.Cross-region redundancy enables applications to quickly recover from a permanent loss of an entire datacenter or parts of a datacenter caused by natural disasters, catastrophic human errors, or malicious acts. Конкретные сведения о RPO можно найти в обзоре непрерывности бизнес-процессов.The specific RPO data can be found at Overview of Business Continuity.

Примечание

В случае сбоя сети между двумя регионами каждые 10 секунд выполняется попытка установить подключения.If there is a network failure between two regions, we retry every 10 seconds to re-establish connections.

Важно!

Чтобы гарантировать, что критическое изменение базы данных-источника реплицировано на дополнительную базу данных перед отработкой отказа, можно вызвать принудительную синхронизацию, что позволит обеспечить репликацию критически важных изменений (например, обновлений паролей).To guarantee that a critical change on the primary database is replicated to a secondary before you failover, you can force synchronization to ensure the replication of critical changes (for example, password updates). Принудительная синхронизация снизит производительность, так как будет блокировать вызывающий поток, пока все зафиксированные транзакции не будут реплицированы.Forced synchronization impacts performance because it blocks the calling thread until all committed transactions are replicated. Дополнительные сведения см. в статье sp_wait_for_database_copy_sync (база данных SQL Azure).For details, see sp_wait_for_database_copy_sync. Чтобы отследить задержку репликации между базой данных-источником и получателем, см. статью sys.dm_geo_replication_link_status (база данных SQL Azure).To monitor the replication lag between the primary database and geo-secondary, see sys.dm_geo_replication_link_status.

На следующем рисунке показан пример активной георепликации, настроенной с помощью базы данных-источника в северо-центральном регионе США и базы данных-получателя в центрально-южной части США.The following figure shows an example of active geo-replication configured with a primary in the North Central US region and secondary in the South Central US region.

Отношение георепликации

Так как базы данных-получатели доступны для чтения, они могут использоваться для разгрузки рабочих нагрузок только для чтения, например заданий для составления отчетов.Because the secondary databases are readable, they can be used to offload read-only workloads such as reporting jobs. Если вы используете активную георепликацию, вы можете создать базу данных-получатель в том же регионе, в котором расположена база данных-источник, однако устойчивость приложения к катастрофическим сбоям останется на прежнем уровне.If you are using active geo-replication, it is possible to create the secondary database in the same region with the primary, but it does not increase the application's resilience to catastrophic failures. Если вы используете группы автоматической отработки отказа, база данных-получатель всегда будет создаваться в другом регионе.If you are using auto-failover groups, your secondary database is always created in a different region.

Активная георепликация может использоваться не только для аварийного восстановления, но и в следующих сценариях:In addition to disaster recovery active geo-replication can be used in the following scenarios:

  • Перенос баз данных: с помощью активной георепликации можно перенести базу данных с одного сервера на другой с минимальным временем простоя.Database migration: You can use active geo-replication to migrate a database from one server to another online with minimum downtime.
  • Обновления приложения: при обновлении приложения вы можете создать дополнительную базу данных-получатель как резервную копию на случай сбоя.Application upgrades: You can create an extra secondary as a fail back copy during application upgrades.

Добавление избыточности баз данных между центрами обработки данных — только часть решения для достижения настоящей непрерывности бизнес-процессов.To achieve real business continuity, adding database redundancy between datacenters is only part of the solution. Для комплексного восстановления приложения (службы) после катастрофического сбоя необходимо восстановить все компоненты, из которых состоит служба и все зависимые службы.Recovering an application (service) end-to-end after a catastrophic failure requires recovery of all components that constitute the service and any dependent services. К примерам этих компонентов относятся клиентское программное обеспечение (например, браузер с пользовательским кодом JavaScript), интерфейсные веб-серверы, хранилище и DNS.Examples of these components include the client software (for example, a browser with a custom JavaScript), web front ends, storage, and DNS. Очень важно, чтобы все компоненты были устойчивы к одинаковым сбоям и становились доступными в соответствии с целевым временем восстановления (RTO) вашего приложения.It is critical that all components are resilient to the same failures and become available within the recovery time objective (RTO) of your application. Следовательно, необходимо определить все зависимые службы и получить сведения о гарантиях и возможностях, которые они предоставляют.Therefore, you need to identify all dependent services and understand the guarantees and capabilities they provide. Затем необходимо выполнить соответствующие действия, чтобы обеспечить работу службы во время отработки отказа служб, от которых она зависит.Then, you must take adequate steps to ensure that your service functions during the failover of the services on which it depends. Дополнительные сведения о проектировании решений для аварийного восстановления см. в статье о разработке облачных решений для аварийного восстановления с помощью активной георепликации.For more information about designing solutions for disaster recovery, see Designing Cloud Solutions for Disaster Recovery Using active geo-replication.

Терминология и возможности активной георепликацииActive geo-replication terminology and capabilities

  • Автоматическая асинхронная репликацияAutomatic Asynchronous Replication

    Базу данных-получатель можно создать, только добавив ее к существующей базе данных.You can only create a secondary database by adding to an existing database. Базу данных-получатель можно создать на любом сервере Базы данных SQL Azure.The secondary can be created in any Azure SQL Database server. После создания база данных-получатель заполняется данными, которые копируются из базы данных-источника.Once created, the secondary database is populated with the data copied from the primary database. Этот процесс называется заполнением.This process is known as seeding. После создания и начального заполнения базы данных-получателя обновления базы данных-источника асинхронно и автоматически реплицируются в базу данных-получателя.After secondary database has been created and seeded, updates to the primary database are asynchronously replicated to the secondary database automatically. Асинхронная репликация означает, что транзакции фиксируются в базе данных-источнике перед их репликацией в базу данных-получатель.Asynchronous replication means that transactions are committed on the primary database before they are replicated to the secondary database.

  • Базы данных-получатели, доступные для чтенияReadable secondary databases

    Приложение может получить доступ к базе данных-получателю только для чтения с использованием тех же или других субъектов безопасности, которые применяются для доступа к базе данных-источнику.An application can access a secondary database for read-only operations using the same or different security principals used for accessing the primary database. База данных-получатель работает в режиме изоляции моментальных снимков, чтобы гарантировать, что репликация обновлений базы данных-источника (воспроизведение журнала) не будет задерживаться из-за запросов, выполняемых на базе данных-получателе.The secondary databases operate in snapshot isolation mode to ensure replication of the updates of the primary (log replay) is not delayed by queries executed on the secondary.

Примечание

Если в базе данных-источнике есть обновления схем, воспроизведение журнала в базе данных-получателе откладывается.The log replay is delayed on the secondary database if there are schema updates on the Primary. Для последнего требуется заблокировать схему базы данных-получателя.The latter requires a schema lock on the secondary database.

Важно!

Георепликацию можно использовать для создания базы данных-получателя в том же регионе, что и первичная реплика.You can use geo-replication to create a secondary database in the same region as the primary. Этот вторичный сервер можно использовать для балансировки нагрузки рабочих нагрузок только для чтения в том же регионе.You can use this secondary to load-balance a read-only workloads in the same region. Однако база данных-получатель в том же регионе не предоставляет дополнительную устойчивость к сбоям и, следовательно, не является подходящей целью отработки отказа для аварийного восстановления.However, a secondary database in the same region does not provide additional fault resilience and therefore is not a suitable failover target for disaster recovery. Кроме того, она не гарантирует изоляцию зоны доступности.It will also not guarantee availability zone isolation. Используйте уровень служб "критически важный для бизнеса" или "Премиум" с избыточной конфигурацией зоны для обеспечения изоляции зоны доступности.Use Business critical or Premium service tier with zone redundant configuration to achieve availability zone isolation.

  • Плановая отработка отказаPlanned failover

    Плановая отработка отказа переключает роли первичной и базы данных-получателя после завершения полной синхронизации.Planned failover switches the roles of primary and secondary databases after the full synchronization is completed. Это оперативная операция, которая не приводит к утрате данных.It is an online operation that does not result in data loss. Время операции зависит от размера журнала транзакций в первичной реплике, которая должна быть синхронизирована.The time of the operation depends on the size of the transaction log on the primary that needs to be synchronized. Плановая отработка отказа предназначена для следующих сценариев: (а) для выполнения анализа аварийного восстановления в рабочей среде в случае неприемлемой потери данных; (б) перемещение базы данных в другой регион; и (c) для возврата базы данных в основной регион после устранения сбоя (восстановления размещения).Planned failover is designed for following scenarios: (a) to perform DR drills in production when the data loss is not acceptable; (b) to relocate the database to a different region; and (c) to return the database to the primary region after the outage has been mitigated (failback).

  • Незапланированная отработка отказаUnplanned failover

    При незапланированной или принудительной отработке отказа база данных-получатель немедленно переключается на основную роль без какой-либо синхронизации с базой данных-источником.Unplanned or forced failover immediately switches the secondary to the primary role without any synchronization with the primary. Все транзакции, зафиксированные в базе данных-источнике, но не реплицированные на базу данных-получатель, будут потеряны.Any transactions committed to the primary but not replicated to the secondary will be lost. Эта операция разработана в качестве метода восстановления во время простоя, когда база данных-источник недоступна, но ее доступность должна быть быстро восстановлена.This operation is designed as a recovery method during outages when the primary is not accessible, but the database availability must be quickly restored. Когда исходный первичный сервер возвращается в оперативный режим, он автоматически повторно подключится и станет новым получателем.When the original primary is back online it will automatically re-connect and become a new secondary. Все несинхронизированные транзакции до отработки отказа будут сохранены в файле резервной копии, но не будут синхронизированы с новым первичным сервером во избежание конфликтов.All unsynchronized transactions before the failover will be preserved in the backup file but will not be synchronized with the new primary to avoid conflicts. Эти транзакции необходимо объединить вручную с самой последней версией базы данных источника.These transactions will have to be manually merged with the most recent version of the primary database.

  • Несколько баз данных-получателейMultiple readable secondaries

    Для каждой базы данных-источника можно создать до 4 баз данных-получателей.Up to 4 secondary databases can be created for each primary. Если же имеется только одна база данных-получатель и на ней происходит сбой, приложение подвергается более высокому риску, пока не будет создана новая база данных-получатель.If there is only one secondary database, and it fails, the application is exposed to higher risk until a new secondary database is created. Если существует несколько баз данных-получателей, то приложение остается защищенным даже при сбое одной из баз данных-получателей.If multiple secondary databases exist, the application remains protected even if one of the secondary databases fails. Дополнительные базы данных-получатели также могут использоваться для масштабирования рабочих нагрузок только для чтения.The additional secondaries can also be used to scale out the read-only workloads

    Примечание

    Если вы используете активную георепликацию, чтобы создать глобально распределенное приложение, и вам необходимо предоставить к данным доступ только для чтения более чем в четырех регионах, вы можете создать базу данных-получатель первой базы данных-получателя (цепочку).If you are using active geo-replication to build a globally distributed application and need to provide read-only access to data in more than four regions, you can create secondary of a secondary (a process known as chaining). Это гарантирует виртуально неограниченное масштабирование репликации базы данных.This way you can achieve virtually unlimited scale of database replication. Кроме того, эта цепочка снижает нагрузку репликации в базе данных-источнике.In addition, chaining reduces the overhead of replication from the primary database. Недостатком является увеличенная задержка репликации в конечных базах данных-получателях.The trade-off is the increased replication lag on the leaf-most secondary databases.

  • Георепликация баз данных в эластичном пулеGeo-replication of databases in an elastic pool

    Каждая база данных-получатель может отдельно участвовать в эластичном пуле или вообще не участвовать в каком-либо эластичном пуле.Each secondary database can separately participate in an elastic pool or not be in any elastic pool at all. Выбор пула для каждой базы данных-получателя осуществляется отдельно и не зависит от конфигурации других баз данных-получателей (источников или получателей).The pool choice for each secondary database is separate and does not depend upon the configuration of any other secondary database (whether primary or secondary). Каждый эластичный пул содержится в одном регионе, поэтому несколько баз данных-получателей в одной топологии никогда не могут совместно использовать один эластичный пул.Each elastic pool is contained within a single region, therefore multiple secondary databases in the same topology can never share an elastic pool.

  • Управляемые пользователем отработка отказа и восстановление размещенияUser-controlled failover and failback

    Приложение или пользователь может в любой момент явным образом использовать базу данных-получатель в качестве базы данных-источника.A secondary database can explicitly be switched to the primary role at any time by the application or the user. Во время настоящего сбоя следует использовать параметр "unplanned", при котором база данных-получатель будет немедленно повышена до базы данных-источника.During a real outage the “unplanned” option should be used, which immediately promotes a secondary to be the primary. Когда работоспособность вышедшей из строя базы данных-источника будет восстановлена и она снова станет доступной, система автоматически пометит ее как базу данных-получатель и синхронизирует с новой базой данных-источником.When the failed primary recovers and is available again, the system automatically marks the recovered primary as a secondary and bring it up-to-date with the new primary. Из-за асинхронного характера репликации во время внеплановой отработки отказа может быть потерян небольшой объем данных, если сбой базы данных-источника произойдет до того, как будет выполнена репликация самых последних изменений в базу данных-получатель.Due to the asynchronous nature of replication, a small amount of data can be lost during unplanned failovers if a primary fails before it replicates the most recent changes to the secondary. При сбое базы данных-источника с несколькими базами данных-получателями система автоматически перенастраивает отношения репликации и связывает оставшиеся базы данных-получатели с новой развернутой базой данных-источником без вмешательства пользователя.When a primary with multiple secondaries fails over, the system automatically reconfigures the replication relationships and links the remaining secondaries to the newly promoted primary without requiring any user intervention. После устранения сбоя, который вызвал отработку отказа, желательно вернуть приложение в основной регион.After the outage that caused the failover is mitigated, it may be desirable to return the application to the primary region. Для этого необходимо вызвать команду отработки отказа с параметром "planned".To do that, the failover command should be invoked with the “planned” option.

Подготовка базы данных-получателя к отработке отказаPreparing secondary database for failover

Чтобы убедиться, что приложение может немедленно получить доступ к новой первичной базе данных-источнику после отработки отказа, убедитесь, что требования к проверке подлинности для сервера-получателя и базы данныеTo ensure that your application can immediately access the new primary after failover, ensure the authentication requirements for your secondary server and database are properly configured. Дополнительные сведения см. в разделе Безопасность базы данных SQL после аварийного восстановления.For details, see SQL Database security after disaster recovery. Чтобы обеспечить соответствие после отработки отказа, убедитесь, что политика хранения резервных копий в базе данных-получателе соответствует основной.To guarantee compliance after failover, make sure that the backup retention policy on the secondary database matches that of the primary. Эти параметры не являются частью базы данных и не реплицируются.These settings are not part of the database and are not replicated. По умолчанию для базы данных-получателя будет настроен период хранения PITR по умолчанию 7 дней.By default, the secondary will be configured with a default PITR retention period of seven days. Дополнительные сведения см. в статье Подробнее о резервном копировании базы данных SQL.For details, see SQL Database automated backups.

Важно!

Если ваша база данных является членом группы отработки отказа, вы не сможете инициировать ее отработку отказа с помощью команды фаиовер георепликации.If your database is a member of a failover group, you cannot initiate its failover using the geo-replication faiover command. Рассмотрите возможность использования команды отработки отказа для группы.Consider using failover command for the group. Если необходимо выполнить отработку отказа отдельной базы данных, сначала необходимо удалить ее из группы отработки отказа.If you need to failover an individual database, you must remove it from the failover group first. Дополнительные сведения см. в разделе группы отработки отказа .See failover groups for details.

Настройка базы данных-получателяConfiguring secondary database

База данных-источник и база данных-получатель должны иметь один и тот же уровень служб.Both primary and secondary databases are required to have the same service tier. Кроме того, настоятельно рекомендуем создавать базу данных-источник и базу данных-получатель с одинаковым объемом вычислительных ресурсов (DTU или виртуальных ядер).It is also strongly recommended that secondary database is created with the same compute size (DTUs or vCores) as the primary. Если база данных-источник испытывает значительную рабочую нагрузку при записи, вторичная с меньшим размером вычислений может не поддерживаться.If the primary database is experiencing a heavy write workload, a secondary with lower compute size may not be able to keep up with it. Это приведет к задержке повтора во вторичной и потенциально недоступности.It will cause the redo lag on the secondary and potential unavailability. Такое несоответствие может привести к потере большого объема данных, если потребуется применение принудительной отработки отказа.A secondary database that is lagging behind the primary also risks a large data loss should a forced failover be required. Чтобы устранить эти риски, эффективная активная Георепликация будет регулировать частоту ведения журнала базы данных-источника, чтобы разрешить ее вторичные реплики.To mitigate these risks, effective active geo-replication will throttle the primary's log rate to allow its secondaries to catch up. Другим следствием несбалансированной вторичной конфигурации является то, что после отработки отказа производительность приложения снизится из-за недостаточной емкости вычислений нового первичного сервера.The other consequence of an imbalanced secondary configuration is that after failover the application’s performance will suffer due to insufficient compute capacity of the new primary. Потребуется выполнить обновление до более высокого уровня, что будет невозможно до тех пор, пока сбой не будет устранен.It will be required to upgrade to a higher compute to the necessary level, which will not be possible until the outage is mitigated.

Важно!

Опубликованная RPO = 5 секунд не может быть гарантирована, пока для базы данных-получателя не будет настроен тот же размер вычислений, что и у первичного.The published RPO = 5 sec cannot be guaranteed unless the secondary database is configured with the same compute size as the primary.

Если вы решите создать базу данных-получатель с более низким объемом вычислительных ресурсов, воспользуйтесь диаграммой журнала операций ввода-вывода в процентах на портале Azure. Это удобный способ рассчитать минимальный объем вычислительных ресурсов базы данных-получателя, необходимый, чтобы выдержать нагрузку репликации.If you decide to create the secondary with lower compute size, the log IO percentage chart on Azure portal provides a good way to estimate the minimal compute size of the secondary that is required to sustain the replication load. Например, если уровень базы данных-источника — P6 (1000 DTU) и процент операций ввода-вывода для нее равен 50 %, то уровень базы-данных получателя должен быть не менее P4 (500 DTU).For example, if your Primary database is P6 (1000 DTU) and its log IO percent is 50% the secondary needs to be at least P4 (500 DTU). Данные журнала операций ввода-вывода также можно получить с помощью представления базы данных sys.resource_stats или sys.dm_db_resource_stats.You can also retrieve the log IO data using sys.resource_stats or sys.dm_db_resource_stats database views. Регулирование передается в виде HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO состояния ожидания в представлениях базы данных sys. dm_exec_requests и sys. dm_os_wait_stats .The throttling is reported as a HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO wait state in the sys.dm_exec_requests and sys.dm_os_wait_stats database views.

Дополнительные сведения об объеме вычислительных ресурсов Базы данных SQL см. в статье с описанием уровней служб Базы данных SQL.For more information on the SQL Database compute sizes, see What are SQL Database Service Tiers.

Хранение учетных данных и правил брандмауэра в синхронизацииKeeping credentials and firewall rules in sync

Мы рекомендуем использовать правила брандмауэра IP на уровне базы данных для геореплицированных баз данных, чтобы эти правила можно было реплицировать вместе с базой данных, чтобы убедиться, что все базы данных-получатели имеют те же правила брандмауэра IP, что и первичная реплика.We recommend using database-level IP firewall rules for geo-replicated databases so these rules can be replicated with the database to ensure all secondary databases have the same IP firewall rules as the primary. Такой подход избавляет клиентов от необходимости вручную настраивать и обслуживать правила брандмауэра на серверах, на которых размещаются как базы данных-источники, так и базы данных-получатели.This approach eliminates the need for customers to manually configure and maintain firewall rules on servers hosting both the primary and secondary databases. Аналогично, в случае получения доступа к данным с помощью пользователей автономной базы данных базы данных-источники и базы данных-получатели всегда используют одни и те же учетные данные. Поэтому при отработке отказа можно избежать нарушений в работе из-за несоответствия имен для входа или паролей.Similarly, using contained database users for data access ensures both primary and secondary databases always have the same user credentials so during a failover, there is no disruptions due to mismatches with logins and passwords. Благодаря добавлению Azure Active Directory клиенты могут управлять доступом пользователей к базам данных-источникам и базам данных-получателям, и им не нужно управлять учетными данными для баз данных.With the addition of Azure Active Directory, customers can manage user access to both primary and secondary databases and eliminating the need for managing credentials in databases altogether.

Обновление или понижение уровня базы данных источникаUpgrading or downgrading primary database

Вы можете повышать или понижать объем вычислительных ресурсов базы данных-источника (в рамках одного уровня служб, а не между уровнем общего назначения и критически важным для бизнеса) без отключения каких-либо баз данных-получателей.You can upgrade or downgrade a primary database to a different compute size (within the same service tier, not between General Purpose and Business Critical) without disconnecting any secondary databases. При повышении рекомендуется сначала повысить уровень производительности базы данных-получателя, а затем — уровень базы данных-источника.When upgrading, we recommend that you upgrade the secondary database first, and then upgrade the primary. При понижении следует действовать в обратном порядке: сначала нужно понизить уровень производительности базы данных-источника, а после этого — базы данных-получателя.When downgrading, reverse the order: downgrade the primary first, and then downgrade the secondary. Когда вы повышаете или понижаете базу данных до следующего уровня служб, особенно важно выполнять рекомендацию выше.When you upgrade or downgrade the database to a different service tier, this recommendation is enforced.

Примечание

Если вы создали базу данных-получатель как часть конфигурации группы отработки отказа, понижение ее уровня не рекомендуется.If you created secondary database as part of the failover group configuration it is not recommended to downgrade the secondary database. Это необходимо, чтобы обеспечить достаточную емкость уровня данных для обработки регулярных рабочих нагрузок после активации отработки отказа.This is to ensure your data tier has sufficient capacity to process your regular workload after failover is activated.

Важно!

База данных-источник в группе отработки отказа не может масштабироваться до более высокого уровня, если база данных-получатель сначала не масштабируется до более высокого уровня.The primary database in a failover group can't scale to a higher tier unless the secondary database is first scaled to the higher tier. Если вы попытаетесь масштабировать базу данных-источник до масштабирования базы данных-получателя, может появиться следующее сообщение об ошибке:If you try to scale the primary database before the secondary database is scaled, you might receive the following error:

Error message: 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.

Предотвращение потери важных данныхPreventing the loss of critical data

Из-за высокой задержки глобальных сетей непрерывная копия использует механизм асинхронной репликации.Due to the high latency of wide area networks, continuous copy uses an asynchronous replication mechanism. Ввиду асинхронной репликации потеря данных в случае сбоя неизбежна.Asynchronous replication makes some data loss unavoidable if a failure occurs. Тем не менее для некоторых приложений терять данные недопустимо.However, some applications may require no data loss. Чтобы защитить эти критические обновления, разработчик приложения сразу же после фиксации транзакции может вызывать системную процедуру sp_wait_for_database_copy_sync.To protect these critical updates, an application developer can call the sp_wait_for_database_copy_sync system procedure immediately after committing the transaction. Вызов sp_wait_for_database_copy_sync блокирует вызывающий поток до передачи последней зафиксированной транзакции в базе данных-получателе.Calling sp_wait_for_database_copy_sync blocks the calling thread until the last committed transaction has been transmitted to the secondary database. Но вызов не дожидается воспроизведения и фиксации переданных транзакций в базе данных-получателе.However, it does not wait for the transmitted transactions to be replayed and committed on the secondary. sp_wait_for_database_copy_sync ограничена конкретной связью непрерывной копии.sp_wait_for_database_copy_sync is scoped to a specific continuous copy link. Эту процедуру может вызвать любой пользователь с правами подключения к базе данных-источнику.Any user with the connection rights to the primary database can call this procedure.

Примечание

Процедура sp_wait_for_database_copy_sync предотвращает потерю данных после отработки отказа, но не гарантирует полную синхронизацию для доступа на чтение.sp_wait_for_database_copy_sync prevents data loss after failover, but does not guarantee full synchronization for read access. Вызов процедуры sp_wait_for_database_copy_sync может привести к значительной задержке, которая будет зависеть от размера журнала транзакций во время вызова.The delay caused by a sp_wait_for_database_copy_sync procedure call can be significant and depends on the size of the transaction log at the time of the call.

Задержка георепликации при мониторингеMonitoring geo-replication lag

Чтобы отслеживать задержку в отношении RPO, используйте столбец replication_lag_sec sys. dm_geo_replication_link_status в базе данных источника.To monitor lag with respect to RPO, use replication_lag_sec column of sys.dm_geo_replication_link_status on the primary database. Он показывает задержку в секундах между транзакциями, зафиксированными в базе данных-источнике и сохраненной на сервере-получателе.It shows lag in seconds between the transactions committed on the primary and persisted on the secondary. Например:E.g. Если значение запаздывания равно 1 секунде, это означает, что в данный момент на источнике влияет сбой, и инициируется отработка отказа, одна секунда последних переходов не будет сохранена.if the value of the lag is 1 second, it means if the primary is impacted by an outage at this moment and failover is initiated, 1 second of the most recent transitions will not be saved.

Чтобы измерить задержку в отношении изменений в базе данных-источнике, которые были применены к вторичной реплике, т. е. доступной для чтения из базы данных-получателя, Сравните last_commitное время на сервере-получателе с тем же значением в базе данных-источнике.To measure lag with respect to changes on the primary database that have been applied on the secondary, i.e. available to read from the secondary, compare last_commit time on the secondary database with the same value on the primary database.

Примечание

Иногда replication_lag_sec в базе данных-источнике имеет значение null. Это означает, что в настоящее время первичный сервер не знает, насколько далеко.Sometimes replication_lag_sec on the primary database has a NULL value, which means that the primary does not currently know how far the secondary is. Обычно это происходит после перезапуска процесса и должно быть переходным условием.This typically happens after process restarts and should be a transient condition. Рассмотрите возможность предупреждения приложения, если replication_lag_sec возвращает значение NULL в течение продолжительного периода времени.Consider alerting the application if the replication_lag_sec returns NULL for an extended period of time. Это означает, что база данных-получатель не может обмениваться данными с источником в связи с постоянной ошибкой подключения.It would indicate that the secondary database cannot communicate with the primary due to a permanent connectivity failure. Существуют также условия, которые могут привести к увеличению разницы между last_commitным временем на сервере-получателе и в базе данных-источнике.There are also conditions that could cause the difference between last_commit time on the secondary and on the primary database to become large. Например:E.g. Если фиксация выполняется на первичном протяжении в течение длительного периода без изменений, разница перейдет до большого значения, прежде чем быстро возвращать значение 0.if a commit is made on the primary after a long period of no changes, the difference will jump up to a large value before quickly returning to 0. Рассмотрите ситуацию ошибки, когда разница между этими двумя значениями остается большой в течение длительного времени.Consider it an error condition when the difference between these two values remains large for a long time.

Программное управление активной георепликациейProgrammatically managing active geo-replication

Как уже говорилось ранее, активной георепликацией можно также управлять программно с помощью Azure PowerShell и REST API.As discussed previously, active geo-replication can also be managed programmatically using Azure PowerShell and the REST API. В приведенных ниже таблицах описан доступный для этого набор команд.The following tables describe the set of commands available. Активная георепликация включает в себя набор API-интерфейсов Azure Resource Manager для управления, в том числе REST API Базы данных SQL Azure и командлеты Azure PowerShell.Active geo-replication includes a set of Azure Resource Manager APIs for management, including the Azure SQL Database REST API and Azure PowerShell cmdlets. Эти интерфейсы API требуют использования групп ресурсов и поддерживают безопасность на основе ролей (RBAC).These APIs require the use of resource groups and support role-based security (RBAC). Дополнительные сведения о том, как реализовать контроль доступа на основе ролей, см. в статье Использование управления доступом на основе ролей для контроля доступа к ресурсам в подписке Azure.For more information on how to implement access roles, see Azure Role-Based Access Control.

T-SQL: Управление отработкой отказа для баз данных в одной и в составе пулаT-SQL: Manage failover of single and pooled databases

Важно!

Приведенные ниже команды Transact-SQL применяются только к активной георепликации — они неприменимы к группам отработки отказа.These Transact-SQL commands only apply to active geo-replication and do not apply to failover groups. Как таковые, они также не применяются к Управляемым экземплярам, так как они поддерживают только группы отработки отказа.As such, they also do not apply to Managed Instances, as they only support failover groups.

КомандаCommand Description (Описание)Description
ALTER DATABASEALTER DATABASE Используйте аргумент ADD SECONDARY ON SERVER, чтобы создать базу данных-получатель для существующей базы данных и начать репликацию данных.Use ADD SECONDARY ON SERVER argument to create a secondary database for an existing database and starts data replication
ALTER DATABASEALTER DATABASE Используйте аргумент FAILOVER или FORCE_FAILOVER_ALLOW_DATA_LOSS, чтобы задать базу данных-получатель в качестве базы данных-источника для запуска отработки отказа.Use FAILOVER or FORCE_FAILOVER_ALLOW_DATA_LOSS to switch a secondary database to be primary to initiate failover
ALTER DATABASEALTER DATABASE Используйте аргумент REMOVE SECONDARY ON SERVER, чтобы завершить репликацию данных между базой данных SQL и указанной базой данных-получателем.Use REMOVE SECONDARY ON SERVER to terminate a data replication between a SQL Database and the specified secondary database.
sys.geo_replication_linkssys.geo_replication_links Возвращает сведения о всех существующих связях репликации для каждой базы данных на сервере Базы данных SQL Azure.Returns information about all existing replication links for each database on the Azure SQL Database server.
sys.dm_geo_replication_link_statussys.dm_geo_replication_link_status Получает время последней репликации, задержку при последней репликации и другие сведения о связи репликации для заданной базы данных SQL.Gets the last replication time, last replication lag, and other information about the replication link for a given SQL database.
sys.dm_operation_statussys.dm_operation_status Показывает состояние всех операций с базой данных, включая состояние связей репликации.Shows the status for all database operations including the status of the replication links.
sp_wait_for_database_copy_syncsp_wait_for_database_copy_sync Указывает приложению ждать, пока все зафиксированные транзакции не будут реплицированы и подтверждены активной базой данных-получателем.causes the application to wait until all committed transactions are replicated and acknowledged by the active secondary database.

PowerShell: Управление отработкой отказа для баз данных в одной и в составе пулаPowerShell: Manage failover of single and pooled databases

Примечание

Эта статья была изменена и теперь содержит сведения о новом модуле Az для Azure PowerShell.This article has been updated to use the new Azure PowerShell Az module. Вы по-прежнему можете использовать модуль AzureRM, исправления ошибок для которого будут продолжать выпускаться как минимум до декабря 2020 г.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Дополнительные сведения о совместимости модуля Az с AzureRM см. в статье Introducing the new Azure PowerShell Az module (Знакомство с новым модулем Az для Azure PowerShell).To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Инструкции по установке модуля Az см. в статье об установке Azure PowerShell.For Az module installation instructions, see Install Azure PowerShell.

Важно!

Модуль PowerShell Azure Resource Manager по-прежнему поддерживается базой данных SQL Azure, но вся будущая разработка предназначена для модуля AZ. SQL.The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. Эти командлеты см. в разделе AzureRM. SQL.For these cmdlets, see AzureRM.Sql. Аргументы для команд в модуле AZ и в модулях AzureRm существенно идентичны.The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

КомандлетCmdlet Description (Описание)Description
Get-AzSqlDatabaseGet-AzSqlDatabase Получает одну или несколько баз данных.Gets one or more databases.
New-AzSqlDatabaseSecondaryNew-AzSqlDatabaseSecondary Создает базу данных-получатель для существующей базы данных и начинает репликацию данных.Creates a secondary database for an existing database and starts data replication.
Set-AzSqlDatabaseSecondarySet-AzSqlDatabaseSecondary Преобразует базу данных-получатель в базу данных-источник для запуска отработки отказа.Switches a secondary database to be primary to initiate failover.
Remove-AzSqlDatabaseSecondaryRemove-AzSqlDatabaseSecondary Завершает репликацию данных между базой данных SQL и указанной базой данных-получателем.Terminates data replication between a SQL Database and the specified secondary database.
Get-AzSqlDatabaseReplicationLinkGet-AzSqlDatabaseReplicationLink Получает связи георепликации между базой данных SQL Azure и группой ресурсов или SQL Server.Gets the geo-replication links between an Azure SQL Database and a resource group or SQL Server.

REST API: Управление отработкой отказа для баз данных в одной и в составе пулаREST API: Manage failover of single and pooled databases

APIAPI Description (Описание)Description
Создание или обновление базы данных (createMode=Restore)Create or Update Database (createMode=Restore) Создает, обновляет или восстанавливает базу данных-источник или базу данных-получатель.Creates, updates, or restores a primary or a secondary database.
Получение, создание или обновление состояния базы данныхGet Create or Update Database Status Возвращает состояние во время операции создания.Returns the status during a create operation.
Задание базы данных-получателя в качестве базы данных-источника (плановая отработка отказа)Set Secondary Database as Primary (Planned Failover) Задает базу данных-получатель в качестве базы данных-источник. Для этого выполняется отработка отказа из текущей базы данных-источник.Sets which secondary database is primary by failing over from the current primary database. Этот параметр не поддерживается в Управляемом экземпляре.This option is not supported for Managed Instance.
Задание базы данных-получателя в качестве базы данных-источника (внеплановая отработка отказа)Set Secondary Database as Primary (Unplanned Failover) Задает базу данных-получатель в качестве базы данных-источник. Для этого выполняется отработка отказа из текущей базы данных-источник.Sets which secondary database is primary by failing over from the current primary database. Эта операция может привести к потере данных.This operation might result in data loss. Этот параметр не поддерживается в Управляемом экземпляре.This option is not supported for Managed Instance.
Получение связи репликацииGet Replication Link Получает определенную связь репликации для заданной базы данных SQL, участвующей в партнерстве георепликации.Gets a specific replication link for a given SQL database in a geo-replication partnership. Извлекает сведения, отображаемые в представлении каталога sys.geo_replication_links.It retrieves the information visible in the sys.geo_replication_links catalog view. Этот параметр не поддерживается в Управляемом экземпляре.This option is not supported for Managed Instance.
Replication Links - List By Database (Ссылки для репликации: вывод списка по базе данных)Replication Links - List By Database Получает все связи репликации для заданной базы данных SQL, участвующей в партнерстве георепликации.Gets all replication links for a given SQL database in a geo-replication partnership. Извлекает сведения, отображаемые в представлении каталога sys.geo_replication_links.It retrieves the information visible in the sys.geo_replication_links catalog view.
Удаление связей репликацииDelete Replication Link Удаляет связь репликации базы данных.Deletes a database replication link. Невозможно выполнить во время отработки отказа.Cannot be done during failover.

Дальнейшие действияNext steps