Resolução de problemas de replicação de pasta pública – Parte 2: Resolução de problemas de replicação de dados existentes
Artigo original publicado na segunda-feira, 28 de novembro de 2011
Publicação original no blog dos Estados Unidos: 20 de janeiro de 2006
Esta é a segunda publicação do blog sobre resolução de problemas de replicação de pasta pública. Na primeira publicação nós cobrimos a Resolução de problemas de replicação de novas mudanças. Esta postagem de blog cobre a Resolução de problemas de replicação de dados existentes e a última publicação nesta série irá cobrir a Resolução de problemas de exclusão de réplicas e problemas comuns. Para ter uma visão total, leia todo o material de referência!
Resolução de problemas de replicação de dados existentes
Quando novas mudanças replicam, mas o material antigo e não alterado não, há um problema de aterramento. A situação mais comum em que o aterramento ocorre é quando um novo armazenamento público é criado. O cenário mais comum de aterramento de conteúdo é quando um armazenamento público é adicionado à lista de réplica de uma pasta.
Quando você tem um problema de aterramento como esse, já pode ter lhe ocorrido que há uma solução fácil – é preciso apenas fazer uma mudança em todos os itens. Ao fazer isso, você contorna o processo de aterramento quebrado e replica tudo como novas mudanças. Apesar do fato de que eu criei ambas as ferramentas que normalmente são usadas para isso (PFDAVAdmin e ModifyItems), geralmente é melhor resolver o problema do processo de aterramento e corrigir a causa raiz. Se você apenas mudar tudo para fazer replicar, você pode terminar com o mesmo problema de aterramento no futuro, quando as réplicas saírem de sincronia novamente. Isso posto, vamos discutir sobre o aterramento. Para compreender o processo de aterramento, primeiro é necessário compreender como as mudanças são rastreadas.
Para cada pasta e mensagem no armazenamento é atribuído um Número de Alterações (CN) quando ela criada e toda vez que for modificada. Quando a replicação ocorre, os CNs em cada objeto são usados para determinar se esse objeto precisa ser replicado. Um grupo de CNs é chamado CNSet. O CNSet para uma determinada pasta em um servidor é chamado informação de status. Essa informação de status está incluída em cada mensagem de replicação. Cada mensagem tipo 0x2 contém o status de hierarquia para o servidor de envio. Da mesma forma, cada tipo de mensagem 0x4 contém a informação de status para aquela determinada pasta para o servidor de envio. Todos os outros tipos de mensagem de replicação contêm informações de status de suas respectivas pastas.
Quando um novo armazenamento público é montado pela primeira vez, ele envia uma solicitação de status (tipo 0x20) da hierarquia de todos os armazenamentos públicos existentes. Da mesma forma, quando um novo armazenamento é adicionado à lista de réplica de uma pasta, esse armazenamento irá enviar um 0x20 para todas as outras réplicas daquela pasta. Como toda mensagem de replicação, uma solicitação de status contém um CNSet de todos os CNs da pasta em questão (ou hierarquia) que o armazenamento de origem possui e solicita que os outros armazenamentos respondam se possuem CNs que o originador não possui. Observe que antes do Exchange 2003 Sp2, não foi pedido a nenhuma réplica que respondesse à solicitação de status, portanto, alguns armazenamentos irão ignorar as solicitações de status mesmo se sofreram mudanças que o armazenamento de origem não sofreu. Um servidor 2003 Sp2 solicitará respostas de todas as réplicas e responderá mesmo quando o servidor de origem não solicitar especificamente isso, enquanto possuir mudanças que o servidor de origem não possui. Isso pode melhorar muito as decisões feitas durante o processo de aterramento. A única questão sobre uma solicitação de status é que ela não contém qualquer dado para replicar - possui apenas uma lista de números de alteração. O outro armazenamento responde com mensagens de status (0x10), que listam seus próprios CNSets para a mesma pasta (ou hierarquia). Quando o servidor de origem recebe as mensagens 0x10, compara o CNSet contido dentro de seu próprio CNSet. Se o 0x10 contém mudanças que o armazenamento ainda não possui, o progresso de aterramento começa.
A primeira etapa no processo de aterramento é adicionar entradas da matriz de aterramento para a pasta em questão. Essas entradas possuem um CNSet que descreve as mudanças faltantes e um valor de tempo limite descrevendo quando o armazenamento solicitará os dados faltantes. O tempo limite do aterramento irá variar dependendo da situação. No caso de um novo armazenamento público ser posto online ou de uma nova réplica de uma pasta ser adicionada, o tempo limite inicial é de 15 minutos.
As entradas de aterramento podem ser adicionadas a matriz de aterramento durante o curso normal de operação. Considere uma situação onde um determinado armazenamento público tenha transmitido duas mudanças em duas mensagens 0x2 separadas. Vamos dizer que o administrador exclua a primeira mensagem 0x2 da fila, mas a segunda passa. Quando os outros servidores receberem esta 0x2, eles irão descobrir que o CNSet na informação de status contém CNs que eles não possuem. Como resultado, eles irão criar entradas de aterramento para este dado. As entradas de aterramento para dados faltantes que foram descobertas durante o curso normal de replicação iniciarão com um tempo limite de 6 horas se o dado estiver disponível no mesmo Grupo de Roteamento (RG) ou 12 horas se estiver disponível em um RG diferente. Cada vez que uma solicitação de aterramento é emitida, o próximo tempo limite será de 12 e depois 24 horas para solicitações entre RGs ou 24 e 48 horas para solicitações dentro do RG.
A cada cinco minutos, o armazenamento verificará se todas as entradas de aterramento atingiram seu tempo limite. Se atingiram, uma solicitação de aterramento (tipo 0x8) é emitida para os CNs faltantes, e o tempo limite é definido para o próximo intervalo. Uma solicitação de aterramento não é uma transmissão, ela é direcionada a cada servidor único - um dos servidores que indicaram anteriormente que possuíam CNs faltantes na informação de status enviada para o servidor de solicitação. Quando esse servidor recebe o 0x8 de entrada, ele imediatamente processa a solicitação e responde com uma ou mais respostas de aterramento (0x80000002 para hierarquia ou 0x80000004 para conteúdo), que contêm os dados atuais para os números de mudança solicitados. Assim como as solicitações de aterramento, as respostas de aterramento não são transmitidas - elas são enviadas apenas para o servidor solicitante.
Se o servidor solicitante processa com êxito a resposta de entrada de aterramento, os CNs contidos são limpos da matriz de aterramento naquele armazenamento. Na realidade, qualquer mensagem de entrada que contenha CNs pendentes na matriz de aterramento fará com que esses CNs sejam limpos da matriz.
Resolução de problemas
Como se pode ver, existem muitas perguntas para responder na resolução de problemas do processo de aterramento.
1. O armazenamento sabe que estão faltando dados?
Primeiro você deve determinar se o servidor percebe que outros armazenamentos possuem mudanças que ele precisa solicitar. Infelizmente, não há uma ferramenta ou uma utilidade suportada que irá permitir a você visualizar a matriz de aterramento diretamente para ver se há algo nela. No entanto, existem outras formas mais indiretas de descobrir isso.
Uma forma é aguardar. Se o servidor sabe que estão faltando dados, ele solicitará esses dados pelo menos uma vez a cada 24 ou 48 horas. Isso significa que você pode apenas ativar o logon e aguardar para ver se uma mensagem 0x8 é emitida. Se você não vir uma 0x8 para a pasta em questão, mas está vendo 0x8 em outras pastas, você pode ter atingido o limite de aterramento pendente, o qual iremos discutir brevemente.
Outra opção é certificar-se de que o servidor receba a informação de status mais atual. Lembre-se, o servidor apenas envia uma solicitação de status que você já adicionou à nova réplica. Depois disso, a única informação de status que ele receber será através do curso normal de replicação. Portanto, se sua tentativa inicial de obter status foi perdida porque a 0x20 ou a 0x10 em resposta foi perdida ou excluída, ele pode ficar lá indefinidamente e não perceber que está faltando algo. Existem várias formas de garantir que o servidor tenha recebido a informação de status para uma pasta.
- Vá para um servidor que possua todos os dados e faça uma mudança na pasta adicionando, excluindo ou modificando uma mensagem. Em caso de uma hierarquia, crie, exclua ou altere as propriedades de uma pasta. A 0x4 ou 0x2 resultante conterá a informação de status para aquela pasta ou hierarquia, respectivamente. Quando o servidor em que estão faltando os dados processar com êxito a mensagem de replicação de entrada, você saberá que ele processou todas as entradas adequadas na matriz de aterramento.
- Use a opção Sincronizar conteúdo no ESM do Exchange 2003. Essa é uma opção bem escondida, mas muito útil. Para localizá-la, vá para a árvore Pastas Públicas e para a pasta em questão. Destaque a pasta no painel esquerdo. No painel direito, clique na guia Status. Clique com o botão direito do mouse no servidor que possui todos os dados e escolha Sincronizar conteúdo. Isso faz duas coisas - faz com que o servidor emita uma solicitação de status 0x20 para a pasta e faz com que encerre o tempo limite imediatamente de qualquer entrada de aterramento. Observe que eu disse que você deve sincronizar o conteúdo do servidor que possui os dados. Você pode se perguntar o porquê de fazer isso, já que é o outro servidor que possui as entradas de aterramento que precisam ser encerradas. Lembre-se de que nesse ponto estamos apenas tentando garantir que o servidor sem os dados SAIBA que possui algo para aterrar. Para isso, podemos usar Sincronizar conteúdo do servidor que possui os dados para enviar um 0x20 para o servidor que não possui. Nesse caso, não estamos realmente interessados em ver uma resposta de status 0x10 para o 0x20. Apenas queremos que o armazenamento com conteúdo faltando receba uma mensagem de replicação para a pasta de um armazenamento com conteúdo, para que possa adicionar as entradas adequadas na matriz de aterramento. A 0x20 do servidor com os dados tem esse objetivo. Observe que no Exchange 2003 Sp2, Sincronizar conteúdo está agora disponível para a hierarquia clicando com o botão direito no próprio nó Pastas Públicas.
- Use o valor de registro Sinalizadores de replicação (KB813629). Se você colocar este valor em vigor, junto com o valor Habilitar mensagens de replicação na inicialização do KB321082, pode ser que o armazenamento envie uma solicitação de status 0x20 para cada pasta na inicialização. Novamente, você desejaria usar isso em um servidor que possui o conteúdo - o objetivo dessa etapa é fazer com que o servidor que possui conteúdo envie suas informações de status para o servidor que está com conteúdo faltante.
- Use o ESM 2003 para enviar uma resposta de aterramento. No Sp1 2003, você pode usar a opção Enviar hierarquia para enviar uma resposta de aterramento de hierarquia e a opção Enviar conteúdo para enviar uma resposta de aterramento de conteúdo da pasta. No Sp2 2003, ambas as opções se tornam Reenviar alterações. Isso envia uma resposta de aterramento para o intervalo de dados que você especificar, mas provavelmente você não especificará o intervalo completo de dados, uma vez que isso poderia satisfazer todas as entradas de aterramento pendentes e terminar voltando para o problema original. Em vez disso, especifique um intervalo de somente um dia ou dois. Isso faz com que um 0x80000002 ou um 0x80000004 vá para o servidor de destino, que novamente serve para o objetivo de fornecer informações de status para o armazenamento que possui os dados.
Uma vez que você usou uma dessas opções para forçar informações de status e verificou que o armazenamento com dados faltantes recebeu a mensagem de entrada verificando o log do aplicativo, você sabe que ele sabe que estão faltando dados.
2. O armazenamento solicita os dados faltantes?
Depois de você ter verificado que o armazenamento sabe que precisa aterrar alguns dados, ele emite uma solicitação de aterramento? Lembre-se disso depois de o armazenamento ter tentando aterrar os dados algumas vezes. Talvez você precise aguardar 24 ou 48 horas para a próxima solicitação de aterramento, pois esse será o intervalo de tempo limite mais longo para aterramentos dentro do site e entre sites, respectivamente. Existe apenas uma forma de acelerar isso, que é usar novamente o Sincronizar conteúdo, mas dessa vez a partir do servidor em que estão faltando os dados. Isso limitará o tempo imediatamente das entradas de aterramento para aquela pasta. No entanto, você ainda pode descobrir que o armazenamento não emite uma solicitação de aterramento para a pasta em que você está concentrado. Se for esse o caso, verifique o log de aplicativo pelas próximas 24 a 48 horas. Se o armazenamento está enviando solicitações de aterramento para outras pastas, mas não para a pasta que você deseja, ele pode ter atingido o limite de aterramento pendente.
Quando você passa por uma situação em que você adicionou réplicas de várias pastas em um novo armazenamento, e a replicação parece bem no início, mas vai diminuindo até parar nos dois dias seguintes, você provavelmente atingiu o limite de aterramento pendente. O limite de aterramento pendente é um mecanismo destinado para a aceleração da replicação. Por padrão, o armazenamento irá permitir apenas 50 solicitações de aterramento pendentes por vez. Quando tiver 50 pendentes, ele solicitará novamente essas 50 solicitações indefinidamente até que sejam realizadas. Uma vez que todas as entradas pendentes tenham sido realizadas, isso abre uma fenda no OBL para um novo conjunto de dados a ser solicitado. Isso significa que se 50 solicitações estão tendo problemas para serem realizadas por qualquer motivo, a replicação não pode continuar.
Se você estiver vendo esse comportamento, deve verificar o log de aplicativo para ver o que o armazenamento está solicitando. Você estará vendo mensagens 0x8 periódicas para as 50 solicitações de aterramento pendentes atuais e você descobrirá que nenhuma resposta de aterramento é recebida, que é o motivo pelo qual ainda estão pendentes. Nesse ponto, você deve alterar seu foco para resolver problemas de uma das pastas que o armazenamento está tentando aterrar atualmente, pois resolver o problema permitirá seguir para outras pastas.
Existe uma outra opção, que é aumentar o limite de aterramento pendente (OBL). Você pode fazer isso criando um valor de registro chamado Limite de aterramento pendente da replicação na chave de registro para aquele armazenamento. O valor máximo é de 5.000 decimal. No entanto, uma vez que você fizer isso, a comporta da replicação abrirá e será difícil determinar quais 50 pastas causaram a obstrução. Você precisará adiar a resolução de problemas até que as coisas se estabilizarem novamente. Geralmente, eu recomendo deixar o limite em 50 e corrigir o problema, em vez de trabalhar para aumentar o limite.
Se o OBL não parece ser o problema, e se você ainda não está vendo as mensagens 0x8 de saída para a pasta em questão, consulte "Problemas Comuns" na última publicação desta série.
3. O outro armazenamento responde à solicitação?
Quando você tiver uma solicitação de aterramento para se concentrar em, você precisa determinar se o aterramento de destino já obteve a solicitação. Verifique o log de aplicativo no servidor para a 0x8 de entrada. Você também pode pesquisar o log de aplicativo pela ID da mensagem mencionada no evento de saída do lado de envio. Se você não conseguir encontrar um sinal dele no log de aplicativo, use o rastreamento de mensagem para ver até que distância ele percorreu. Se ele recebeu a 0x8, deve responder quase imediatamente com uma ou mais mensagens 0x80000002 ou 0x80000004 (você frequentemente verá várias respostas de aterramento a uma única solicitação de aterramento, pois as mudanças não são enviadas em uma única mensagem). Claro, o tempo que leva para gerar as mensagens de resposta de aterramento irá variar com base nos dados da pasta e no limite de tamanho da mensagem de replicação. Por exemplo, se você definir o tamanho máximo da mensagem de replicação como 1 GB, o servidor de resposta poderia tentar empacotar toda a hierarquia em uma única resposta de aterramento, o que pode levar uma hora ou mais apenas para embalar!
4. O servidor solicitante obtém a resposta?
Agora é o momento de verificar o log de aplicativo no servidor de solicitação para ver se ele recebeu a resposta de aterramento. Caso contrário, rastreie a mensagem e veja quão longe ela foi. Se o servidor recebeu a resposta de aterramento e registrou no log do aplicativo, essa solicitação de aterramento foi realizada e deve poder continuar.
Como mencionado anteriormente, se você descobrir que o rastreamento de mensagem mostra que uma dessas mensagens foi entregue para o armazenamento, ainda que o log de aplicativo não mostre a mensagem de replicação em entrada, consulte "Problemas Comuns" na última publicação desta série.
Na próxima publicação do blog: Troubleshooting Replica Deletion and Common Problems..
Esta é uma publicação de blog traduzida. Você encontra o artigo original em Public Folder Replication Troubleshooting – Part 2: Troubleshooting the Replication of Existing Data