Использование класса RecoveryManager для устранения проблем с картой шардирования

Применимо к: База данных SQL Azure

Класс RecoveryManager предоставляет приложениям ADO.Net возможность легко обнаружить и исправить все несоответствия между глобальным сопоставлением сегментов (GSM) и локальным сопоставлением сегментов (LSM) в сегментированной среде базы данных.

GSM и LSM отслеживают сопоставление каждой базы данных в сегментированной среде. Иногда между GSM и LSM происходит разрыв. В этом случае используйте RecoveryManager класс для обнаружения и восстановления разрыва.

Класс RecoveryManager является частью масштабируемых облачных баз данных.

Определения терминов см. в статье Глоссарий по средствам работы с эластичными базами данных. Сведения о том, как ShardMapManager используется для управления данными в сегментируемом решении, см. в статье "Горизонтальное масштабирование баз данных" с помощью диспетчера карт сегментов.

Для чего используется диспетчер восстановления

В шардированной среде баз данных есть один арендатор на каждую базу данных и много баз данных на сервер. В среде также может быть несколько серверов. Каждая база данных сопоставляется в карте сегментов, чтобы вызовы направлялись к правильному серверу и базе данных. Базы данных отслеживаются по ключу сегментирования, а каждому серверу назначается диапазон значений ключа. Например, ключ сегментирования может представлять имена клиентов от "D" до "F". Сопоставление всех сегментов (также известных как базы данных) и их диапазоны сопоставления содержатся на глобальной карте сегментов (GSM). Каждая база данных также содержит карту c диапазонами сегментов. Она называется локальной картой сегментирования (LSM). Когда приложение подключается к сегменту, сопоставление кэшируется с приложением для быстрого извлечения данных. LSM используется для проверки кэшированных данных.

GSM и LSM могут выйти из синхронизации по следующим причинам:

1. Удаление сегмента, диапазон которого считается неиспользуемым, или переименование сегмента. Удаление шарда приводит к осиротевшему сопоставлению шарда. Переименование базы данных точно так же может привести к потере сопоставления сегментов. В зависимости от намерения изменения может потребоваться удалить сегмент или обновить расположение сегментов. Сведения о восстановлении удаленной базы данных см. в статье "Восстановление базы данных из резервной копии в базе данных SQL Azure".
2. Происходит событие геоотказоустойчивости. Чтобы продолжить, необходимо обновить имя сервера и имя базы данных менеджера карты фрагментов в приложении, а затем обновить данные отображения фрагментов для всех фрагментов в карте фрагментов. Если происходит геопереключение, такая логика восстановления должна быть автоматизирована в рамках процесса переключения. Автоматизация действий по восстановлению гарантирует удобную управляемость для баз данных с поддержкой определения географического расположения и позволяет избежать выполнение действий пользователем вручную. Дополнительные сведения о вариантах восстановления базы данных в случае сбоя центра обработки данных см. в руководстве по непрерывности бизнес-процессов в базе данных SQL Azure и руководстве по аварийному восстановлению — База данных SQL Azure.
3. Сегмент или ShardMapManager база данных восстанавливается до более ранней точки во времени. Чтобы узнать о восстановлении на определенный момент времени с использованием резервных копий, см. статью "Восстановление базы данных из резервной копии в Azure SQL Database".

Дополнительные сведения о средствах эластичной базы данных SQL Azure, георепликации и восстановлении см. в следующем разделе:

• Непрерывность бизнес-процессов в Базе данных SQL Azure
• Начало работы с средствами эластичных баз данных
• Горизонтальное масштабирование баз данных с помощью диспетчера карт сегментов

Извлечение RecoveryManager из ShardMapManager

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

 ShardMapManager smm = ShardMapManagerFactory.GetSqlShardMapManager(smmConnectionString,  
          ShardMapManagerLoadPolicy.Lazy);
          RecoveryManager rm = smm.GetRecoveryManager();

В этом примере RecoveryManager инициализируется из ShardMapManager. ShardMapManager, содержащий ShardMap, уже инициализирован.

Так как этот код приложения управляет самой картой сегментов, учетные данные, используемые в методе фабрики (в предыдущем примере), smmConnectionStringдолжны быть учетными данными, имеющими разрешения на чтение и запись в базе данных GSM, на которую ссылается строка подключения. Обычно эти учетные данные отличаются от учетных данных, используемых при открытии подключений для зависящей от данных маршрутизации. Дополнительные сведения см. в разделе "Учетные данные", используемые для доступа к клиентской библиотеке эластичной базы данных.

Удалите шарду из ShardMap после удаления шарды

Метод DetachShard отсоединяет данный шард от карты сегментов и удаляет сопоставления, связанные с этим шардом.

• Параметр location — это расположение сегментов, в частности имя сервера и имя базы данных, отсоединяемого сегмента.
• Параметр shardMapName — это имя карты сегментов. Он необходим, только если один и тот же диспетчер сопоставления сегментов управляет несколькими сопоставлениями сегментов. Необязательно.

Этот пример удаляет шарды из карты шардов.

rm.DetachShard(s.Location, customerMap);

Карта шардирования отражает расположение шарда в GSM до его удаления. Так как сегмент был удален, предполагается, что это было намеренно, и диапазон ключей сегментирования больше не используется. Если это не так, можно выполнить восстановление до точки во времени, Восстановить фрагмент из более ранней точки во времени. (В этом случае просмотрите следующий раздел, чтобы обнаружить несоответствия сегментов.) Сведения о восстановлении см. в статье "Восстановление базы данных из резервной копии в базе данных SQL Azure".

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

Обнаружение различий при сопоставлении

Метод DetectMappingDifferences выбирает и возвращает одну из карт шардов (локальную или глобальную) в качестве источника достоверности и согласует сопоставления на обеих картах шардов (GSM и LSM).

rm.DetectMappingDifferences(location, shardMapName);

• location определяет имя сервера и имя базы данных.
• Параметр shardMapName — это имя карты сегментов. Это требуется только, если один и тот же менеджер карт шардов управляет несколькими картами шардов. Необязательно.

Устранение различий в сопоставлении

Метод ResolveMappingDifferences выбирает одно из сопоставлений сегментов (локальное или глобальное) как источник истины и согласовывает сопоставления на обоих сопоставлениях сегментов (GSM и LSM).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);

• Параметр RecoveryToken перечисляет различия в сопоставлениях между GSM и LSM для конкретного сегмента.
• Перечисление MappingDifferenceResolution используется для указания метода для устранения разницы между сопоставлениями сегментов.
• MappingDifferenceResolution.KeepShardMapping рекомендуется, если LSM содержит точное сопоставление, использовать сопоставление в шарде. Обычно это происходит в случае отказа: сегмент теперь находится на новом сервере. Так как сначала фрагмент должен быть удален из GSM (с помощью метода RecoveryManager.DetachShard), сопоставление больше не существует на GSM. Следовательно, для повторного установления сопоставления шардов нужно использовать LSM.

Присоединение сегмента к ShardMap после восстановления сегмента

Метод AttachShard присоединяет заданный шард к сопоставлению шардов. Затем он обнаруживает несоответствия в карте сегментов и обновляет сопоставления, чтобы они соответствовали сегментам в точке восстановления сегментов. Предполагается, что база данных также переименована, чтобы отразить первоначальное имя базы данных (до восстановления шардирования), поскольку восстановление на указанный момент времени по умолчанию создает новую базу данных с добавленным временным штампом.

rm.AttachShard(location, shardMapName)

• Параметр location — это имя сервера и имя базы данных, присоединенного к сегменту.
• Параметр shardMapName — это имя карты сегментов. Это необходимо только в том случае, если один и тот же менеджер карт шардов управляет несколькими картами шардов. Необязательно.

В этом примере добавляется шард к карте шардов, которая была недавно восстановлена до более ранней временной точки. Так как фрагмент (а именно сопоставление для фрагмента в LSM) восстановлен, он потенциально не согласуется с соответствующей записью фрагмента в GSM. Вне этого примера кода сегмент был восстановлен и переименован в исходное имя базы данных. Так как оно было восстановлено, предполагается, что сопоставление в LSM является доверенным сопоставлением.

rm.AttachShard(s.Location, customerMap);
var gs = rm.DetectMappingDifferences(s.Location);
   foreach (RecoveryToken g in gs)
    {
    rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
    }

Обновление расположений шардов после аварийного переключения (восстановление) шардов

Если происходит георезервирование, вторичная база данных становится доступной для записи и становится новой основной базой данных. Имя сервера и потенциально база данных (в зависимости от конфигурации) может отличаться от исходной первичной базы данных. Поэтому необходимо исправить сопоставляемые записи для сегмента в GSM и LSM. Аналогичным образом, если база данных восстанавливается с другим именем или в другое расположение, или восстанавливается до более ранней точки во времени, это может вызвать несогласованности в картах шардирования. Диспетчер карт сегментов обрабатывает распределение открытых подключений к нужной базе данных. Распределение основывается на данных в карте сегментов и значении ключа шардирования, который является целью запроса приложения. После геопереключения эти сведения необходимо обновить, указав точные имя сервера, имя базы данных и сопоставление шардов восстановленной базы данных.

Лучшие практики

Гео-фэловером и восстановлением обычно управляет облачный администратор приложения, который сознательно использует функции обеспечения непрерывности бизнеса в базе данных Azure SQL. Для планирования непрерывности бизнес-процессов требуются процессы, процедуры и меры, обеспечивающие непрерывность выполнения бизнес-операций. Методы, доступные в RecoveryManager классе, должны использоваться в этом рабочем потоке, чтобы обеспечить актуальность GSM и LSM на основе предпринятых действий восстановления. Чтобы GSM и LSM отражали точную информацию после события отказа, выполните пять приведенных ниже основных шагов. Код приложения для выполнения этих действий можно интегрировать в существующие средства и рабочий процесс.

1. Получите RecoveryManager из ShardMapManager.
2. Отсоедините старый шард от сопоставления шардов.
3. Присоедините новый шар к сопоставлению шардов, включая новое расположение шарда.
4. Выявите несоответствия в сопоставлении между GSM и LSM.
5. Устраните различия между GSM и LSM, ориентируясь на LSM.

В этом примере выполняются следующие действия.

1. Удаляет шарды из карты шардов, которые указывают на их расположение до события переключения.

2. Присоединяет сегменты к карте сегментов, отражающую новые расположения сегментов (параметр Configuration.SecondaryServer — это новое имя сервера, но то же имя базы данных).

3. Получение маркеров восстановления для каждого шарда путем обнаружения различий сопоставления между GSM и LSM.

4. Устраняет несоответствия, доверяясь сопоставлению из LSM каждого шарда.

   var shards = smm.GetShards();
   foreach (shard s in shards)
   {
     if (s.Location.Server == Configuration.PrimaryServer)
         {
          ShardLocation slNew = new ShardLocation(Configuration.SecondaryServer, s.Location.Database);
          rm.DetachShard(s.Location);
          rm.AttachShard(slNew);
          var gs = rm.DetectMappingDifferences(slNew);
          foreach (RecoveryToken g in gs)
            {
               rm.ResolveMappingDifferences(g, MappingDifferenceResolution.KeepShardMapping);
            }
        }
    }
   

Связанный контент

Еще не используете средства эластичных баз данных? Ознакомьтесь с нашим руководством по началу работы. Возникшие вопросы вы можете задать нам на странице вопросов Microsoft Q&A по Базе данных SQL. Что касается запросов новых функций, вы можете поделиться новыми идеями или проголосовать за существующие на форуме отзывов по Базе данных SQL.