Поделиться через

Устранение проблем сопоставления сегментов с помощью класса 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 на портале Azure.
  2. Происходит событие географической отработки отказа. Чтобы продолжить, необходимо обновить имя сервера и имя базы данных диспетчера сопоставления сегментов в приложении, а затем обновить сведения о сопоставлении сегментов для всех сегментов в сопоставлении. В случае географической отработки отказа такую логику восстановления следует автоматизировать в рабочем процессе отработки отказа. Автоматизация действий по восстановлению гарантирует удобную управляемость для баз данных с поддержкой определения географического расположения и позволяет избежать выполнение действий пользователем вручную. Дополнительные сведения о вариантах восстановления базы данных в случае сбоя центра обработки данных см. в статьях Обзор обеспечения непрерывности бизнес-процессов с помощью базы данных SQL Azure и Восстановление базы данных SQL Azure или переход на базу данных-получатель при отказе.
  3. Сегмент или база данных ShardMapManager восстанавливается до более ранней версии. Чтобы узнать больше о восстановлении на определенный момент времени с помощью резервных копий, изучите раздел Восстановление базы данных Azure SQL с помощью создаваемых автоматически резервных копий.

Дополнительные сведения о средствах эластичной базы данных, входящей в базу данных 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 отсоединяет данный сегмент от сопоставления сегментов и удаляет сопоставления, связанные с ним.

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

Внимание

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

Этот пример удаляет сегменты из сопоставления сегментов.

rm.DetachShard(s.Location, customerMap);

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

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

Определение различий сопоставления

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

rm.DetectMappingDifferences(location, shardMapName);
  • Расположение указывает имя сервера и имя базы данных.
  • В параметре 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)
  • В параметре расположение указано имя сервера и имя базы данных присоединяемого сегмента.
  • В параметре 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. Аналогичным образом, если база данных восстанавливается до другого имени или расположения или до более ранней точки во времени, это может вызвать несогласованности в сопоставлениях сегментов. Диспетчер сопоставления сегментов обрабатывает распределение открытых подключений к нужной базе данных. Распределение основывается на данных в сопоставлении сегментов и значении ключа сегментирования, который является целевым объектом запроса приложения. После географической отработки отказа необходимо обновить эти сведения, добавив точное имя сервера, имя базы данных и сопоставление сегментов восстановленной базы данных.

Рекомендации

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

  1. Получите диспетчер восстановления из диспетчера сопоставления сегментов.
  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.