Partilhar via

Utilizar a classe RecoveryManager para corrigir problemas do mapa de partições horizontais

  • Artigo

Aplica-se a:Banco de Dados SQL do Azure

A classe RecoveryManager fornece aos aplicativos ADO.NET a capacidade de detetar e corrigir facilmente quaisquer inconsistências entre o mapa de fragmentos global (GSM) e o mapa de estilhaços local (LSM) em um ambiente de banco de dados fragmentado.

O GSM e o LSM rastreiam o mapeamento de cada banco de dados em um ambiente fragmentado. Ocasionalmente, ocorre uma pausa entre o GSM e o LSM. Nesse caso, use a classe RecoveryManager para detetar e reparar a quebra.

A classe RecoveryManager faz parte da biblioteca de cliente do Elastic Database.

Shard map

Para obter definições de termos, consulte Glossário de ferramentas do Elastic Database. Para entender como o ShardMapManager é usado para gerenciar dados em uma solução fragmentada, consulte Gerenciamento de mapas de estilhaços.

Por que usar o gerenciador de recuperação

Em um ambiente de banco de dados fragmentado, há um locatário por banco de dados e muitos bancos de dados por servidor. Também pode haver muitos servidores no ambiente. Cada banco de dados é mapeado no mapa de estilhaços, para que as chamadas possam ser roteadas para o servidor e o banco de dados corretos. Os bancos de dados são rastreados de acordo com uma chave de fragmentação e a cada fragmento é atribuído um intervalo de valores de chave. Por exemplo, uma chave de fragmentação pode representar os nomes dos clientes de "D" a "F". O mapeamento de todos os fragmentos (também conhecidos como bancos de dados) e seus intervalos de mapeamento estão contidos no mapa global de estilhaços (GSM). Cada banco de dados também contém um mapa dos intervalos contidos no estilhaço que é conhecido como o mapa de estilhaços local (LSM). Quando um aplicativo se conecta a um fragmento, o mapeamento é armazenado em cache com o aplicativo para recuperação rápida. O LSM é usado para validar dados armazenados em cache.

O GSM e o LSM podem ficar fora de sincronia pelos seguintes motivos:

  1. A eliminação de um fragmento cujo intervalo se acredita não estar mais em uso, ou a renomeação de um fragmento. A exclusão de um fragmento resulta em um mapeamento de fragmento órfão. Da mesma forma, um banco de dados renomeado pode causar um mapeamento de estilhaço órfão. Dependendo da intenção da alteração, o fragmento pode precisar ser removido ou o local do fragmento precisa ser atualizado. Para recuperar um banco de dados excluído, consulte Restaurar um banco de dados excluído.
  2. Ocorre um evento de failover geográfico. Para continuar, é necessário atualizar o nome do servidor e o nome do banco de dados do gerenciador de mapas de estilhaços no aplicativo e, em seguida, atualizar os detalhes de mapeamento de fragmentos para todos os fragmentos em um mapa de estilhaços. Se houver um failover geográfico, essa lógica de recuperação deve ser automatizada no fluxo de trabalho de failover. A automatização das ações de recuperação permite um gerenciamento sem atrito para bancos de dados habilitados geograficamente e evita ações humanas manuais. Para saber mais sobre as opções para recuperar um banco de dados se houver uma interrupção do data center, consulte Continuidade de negócios e recuperação de desastres.
  3. Um fragmento ou o banco de dados ShardMapManager é restaurado para um point-in-time anterior. Para saber mais sobre a recuperação point-in-time usando backups, consulte Recuperação usando backups.

Para obter mais informações sobre as ferramentas do Banco de Dados Elástico do Banco de Dados SQL do Azure, replicação geográfica e Restauração, consulte o seguinte:

Recuperando o RecoveryManager de um ShardMapManager

A primeira etapa é criar uma instância do RecoveryManager. O método GetRecoveryManager retorna o gerenciador de recuperação para a instância ShardMapManager atual. Para resolver quaisquer inconsistências no mapa de estilhaços, você deve primeiro recuperar o RecoveryManager para o mapa de estilhaços específico.

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

Neste exemplo, o RecoveryManager é inicializado a partir do ShardMapManager. O ShardMapManager que contém um ShardMap também já foi inicializado.

Como esse código de aplicativo manipula o próprio mapa de estilhaços, as credenciais usadas no método de fábrica (no exemplo anterior, smmConnectionString) devem ser credenciais que tenham permissões de leitura-gravação no banco de dados GSM referenciado pela cadeia de conexão. Essas credenciais geralmente são diferentes das credenciais usadas para abrir conexões para roteamento dependente de dados. Para obter mais informações, consulte Usando credenciais no cliente de banco de dados elástico.

Removendo um fragmento do ShardMap depois que um fragmento é excluído

O método DetachShard separa o fragmento fornecido do mapa de estilhaços e exclui mapeamentos associados ao fragmento.

  • O parâmetro location é o local do estilhaço, especificamente o nome do servidor e o nome do banco de dados, do fragmento que está sendo desanexado.
  • O parâmetro shardMapName é o nome do mapa de estilhaços. Isso só é necessário quando vários mapas de estilhaços são gerenciados pelo mesmo gerenciador de mapas de estilhaços. Opcional.

Importante

Use essa técnica somente se tiver certeza de que o intervalo para o mapeamento atualizado está vazio. Os métodos acima não verificam os dados para o intervalo que está sendo movido, por isso é melhor incluir verificações em seu código.

Este exemplo remove fragmentos do mapa de estilhaços.

rm.DetachShard(s.Location, customerMap);

O mapa de estilhaços reflete a localização do estilhaço no GSM antes da exclusão do fragmento. Como o estilhaço foi excluído, supõe-se que isso foi intencional e o intervalo de chaves de fragmentação não está mais em uso. Caso contrário, você pode executar a restauração point-in-time. para recuperar o fragmento de um point-in-time anterior. (Nesse caso, revise a seção a seguir para detetar inconsistências de estilhaços.) Para recuperar, consulte Recuperação point-in-time.

Como se presume que a exclusão do banco de dados foi intencional, a ação de limpeza administrativa final é excluir a entrada para o fragmento no gerenciador de mapa de estilhaços. Isso impede que o aplicativo grave informações inadvertidamente em um intervalo que não é esperado.

Para detetar diferenças de mapeamento

O método DetectMappingDifferences seleciona e retorna um dos mapas de estilhaços (local ou global) como a fonte da verdade e reconcilia mapeamentos em ambos os mapas de estilhaços (GSM e LSM).

rm.DetectMappingDifferences(location, shardMapName);
  • O local especifica o nome do servidor e o nome do banco de dados.
  • O parâmetro shardMapName é o nome do mapa de estilhaços. Isso só é necessário se vários mapas de estilhaços forem gerenciados pelo mesmo gerenciador de mapas de estilhaços. Opcional.

Para resolver diferenças de mapeamento

O método ResolveMappingDifferences seleciona um dos mapas de estilhaços (local ou global) como a fonte da verdade e reconcilia mapeamentos em ambos os mapas de estilhaços (GSM e LSM).

ResolveMappingDifferences (RecoveryToken, MappingDifferenceResolution.KeepShardMapping);
  • O parâmetro RecoveryToken enumera as diferenças nos mapeamentos entre o GSM e o LSM para o fragmento específico.
  • A enumeração MappingDifferenceResolution é usada para indicar o método para resolver a diferença entre os mapeamentos de estilhaço.
  • MappingDifferenceResolution.KeepShardMapping é recomendado que, quando o LSM contiver o mapeamento preciso e, portanto, o mapeamento no fragmento deve ser usado. Este é normalmente o caso se houver um failover: o fragmento agora reside em um novo servidor. Como o estilhaço deve primeiro ser removido do GSM (usando o método RecoveryManager.DetachShard), um mapeamento não existe mais no GSM. Portanto, o LSM deve ser usado para restabelecer o mapeamento de estilhaços.

Anexar um fragmento ao ShardMap depois que um fragmento for restaurado

O método AttachShard anexa o fragmento dado ao mapa de estilhaços. Em seguida, ele deteta quaisquer inconsistências no mapa de estilhaços e atualiza os mapeamentos para corresponder ao fragmento no ponto da restauração do estilhaço. Supõe-se que o banco de dados também seja renomeado para refletir o nome do banco de dados original (antes que o fragmento tenha sido restaurado), uma vez que a restauração point-in-time assume como padrão um novo banco de dados anexado com o carimbo de data/hora.

rm.AttachShard(location, shardMapName)
  • O parâmetro location é o nome do servidor e o nome do banco de dados do fragmento que está sendo anexado.
  • O parâmetro shardMapName é o nome do mapa de estilhaços. Isso só é necessário quando vários mapas de estilhaços são gerenciados pelo mesmo gerenciador de mapas de estilhaços. Opcional.

Este exemplo adiciona um fragmento ao mapa de estilhaços que foi restaurado recentemente a partir de um point-in-time anterior. Uma vez que o fragmento (ou seja, o mapeamento para o fragmento no LSM) foi restaurado, é potencialmente inconsistente com a entrada do fragmento no GSM. Fora deste código de exemplo, o fragmento foi restaurado e renomeado para o nome original do banco de dados. Uma vez que foi restaurado, supõe-se que o mapeamento no LSM é o mapeamento confiável.

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

Atualizando locais de estilhaços após um failover geográfico (restauração) dos fragmentos

Se houver um failover geográfico, o banco de dados secundário será tornado acessível por gravação e se tornará o novo banco de dados primário. O nome do servidor e, potencialmente, o banco de dados (dependendo da sua configuração), pode ser diferente do primário original. Portanto, as entradas de mapeamento para o fragmento no GSM e LSM devem ser corrigidas. Da mesma forma, se o banco de dados for restaurado para um nome ou local diferente, ou para um ponto anterior no tempo, isso poderá causar inconsistências nos mapas de estilhaços. O Shard Map Manager lida com a distribuição de conexões abertas para o banco de dados correto. A distribuição é baseada nos dados no mapa de estilhaços e no valor da chave de fragmentação que é o destino da solicitação de aplicativos. Após um failover geográfico, essas informações devem ser atualizadas com o nome preciso do servidor, o nome do banco de dados e o mapeamento de estilhaços do banco de dados recuperado.

Melhores práticas

Geofailover e recuperação são operações normalmente gerenciadas por um administrador de nuvem do aplicativo que utiliza intencionalmente os recursos de continuidade de negócios do Banco de Dados SQL do Azure. O planejamento de continuidade de negócios requer processos, procedimentos e medidas para garantir que as operações de negócios possam continuar sem interrupção. Os métodos disponíveis como parte da classe RecoveryManager devem ser usados dentro desse fluxo de trabalho para garantir que o GSM e o LSM sejam mantidos atualizados com base na ação de recuperação executada. Há cinco etapas básicas para garantir corretamente que o GSM e o LSM reflitam as informações precisas após um evento de failover. O código do aplicativo para executar essas etapas pode ser integrado às ferramentas e ao fluxo de trabalho existentes.

  1. Recupere o RecoveryManager do ShardMapManager.
  2. Separe o fragmento antigo do mapa de estilhaços.
  3. Anexe o novo fragmento ao mapa do estilhaço, incluindo a nova localização do fragmento.
  4. Detetar inconsistências no mapeamento entre o GSM e LSM.
  5. Resolva as diferenças entre o GSM e o LSM, confiando no LSM.

Este exemplo executa as seguintes etapas:

  1. Remove fragmentos do Mapa de estilhaços que refletem locais de estilhaços antes do evento de failover.

  2. Anexa fragmentos ao Mapa de estilhaços refletindo os novos locais de fragmentos (o parâmetro "Configuration.SecondaryServer" é o novo nome do servidor, mas o mesmo nome do banco de dados).

  3. Recupera os tokens de recuperação detetando diferenças de mapeamento entre o GSM e o LSM para cada fragmento.

  4. Resolve as inconsistências confiando no mapeamento do LSM de cada fragmento.

    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);
         }
     }
 }

Recursos adicionais

Ainda não está usando ferramentas de banco de dados elástico? Consulte o nosso Guia de Introdução. Para dúvidas, entre em contato conosco na página de perguntas e respostas da Microsoft para o Banco de dados SQL e para solicitações de recursos, adicione novas ideias ou vote em ideias existentes no fórum de comentários do Banco de dados SQL.