Show Menu
TÓPICOS×

Solução de problemas de replicação

Esta página fornece informações sobre como solucionar problemas de replicação.

Problema

A replicação (replicação não reversa) está falhando por algum motivo.

Resolução

Há vários motivos para a replicação falhar. Este artigo explica a abordagem que se pode adotar ao analisar essas questões.
As replicações estão sendo acionadas ao clicar no botão Ativar? Se NÃO, faça o seguinte:
  1. Vá para /crx/explorer e faça logon como administrador.
  2. Abra "Content Explorer"
  3. Verifique se existe um nó /bin/replicate ou /bin/replicate.json. Se o nó existir, exclua-o e salve-o.
As replicações estão sendo enfileiradas nas filas do agente de replicação?
Para verificar isso, acesse /etc/replication/agents.author.html e clique nos agentes de replicação para verificar.
Se uma fila de agente ou algumas filas de agente estiverem travadas:
  1. A fila mostra o status bloqueado ? Em caso afirmativo, a instância de publicação não está em execução ou não está totalmente responsiva? Verifique a instância de publicação para ver o que há de errado com ela (ou seja, verifique os registros e veja se há um erro OutOfMemory ou algum outro problema. Então, se for apenas lento, pegue os despejos de thread e analise-os.
  2. O status da fila mostra que a Fila está ativa - # pendente ? Basicamente, o trabalho de replicação pode estar preso em uma leitura de soquete aguardando a resposta da instância pública ou do dispatcher. Isso pode significar que a instância de publicação ou o dispatcher está com carga alta ou preso em um bloqueio. Tire lixeiras do autor e publique neste caso.
    • Abra os despejos de thread do autor em um analisador de despejo de thread, verifique se ele mostra que o trabalho de evento de sling do agente de replicação está preso em um soqueteRead.
    • Abra os despejos de thread da publicação em um analisador de despejo de thread, analise o que pode estar fazendo com que a instância de publicação não responda. Você deve ver um thread com POST /bin/receive em seu nome, que é o thread que recebe a replicação do autor.
Se todas as filas de agente estiverem travadas
  1. É possível que um determinado conteúdo não possa ser serializado em /var/Replication/data devido a danos no repositório ou a algum outro problema. Verifique se há um erro relacionado no logs/error.log. Para eliminar o item de replicação incorreto, faça o seguinte:
    1. Vá para https://<host>:<porta>/crx/de e faça logon como usuário administrador.
    2. Clique em "Ferramentas" no menu superior.
    3. Clique no botão de lupa.
    4. Selecione "XPath" como Tipo.
    5. Na caixa "Consulta", digite esta ordem de consulta /jcr:root/var/eventing/jobs//element(*,slingevent:Job) por @slingevent:created
    6. Clique em "Pesquisar"
    7. Nos resultados, os itens principais são os trabalhos de eventos de sling mais recentes. Clique em cada uma e localize as replicações presas que correspondem ao que aparece na parte superior da fila.
  2. Pode haver algo errado com o envio de filas de trabalho da estrutura de eventos. Tente reiniciar o pacote org.apache.sling.event no /system/console.
  3. Pode ser que o processamento de trabalho esteja completamente desligado. Você pode verificar isso em Console do Felix na guia Eventos do Sling. Verifique se ele é exibido - Apache Sling Event (O PROCESSAMENTO DE TAREFA ESTÁ DESATIVADO!)
    • Em caso afirmativo, marque a guia Configuração do Manipulador de eventos de trabalhos do Apache Sling no console do Felix. Pode ser que a caixa de seleção 'Processamento de trabalho ativado' esteja desmarcada. Se essa opção estiver marcada e ainda assim for exibida, verifique se há alguma sobreposição em /apps/system/config que esteja desativando o processamento da tarefa. Tente criar um nó osgi:config para jobmanager.enabled com um valor booliano para true e verifique novamente se a ativação foi iniciada e se não há mais trabalhos na fila.
  4. Também pode ser que a configuração DefaultJobManager fique em um estado inconsistente. Isso pode ocorrer quando alguém modifica manualmente a configuração do 'Apache Sling Job Event Handler' por meio do console OSG (por exemplo, desative e reative a propriedade 'Job Processing Enabled' e Salve a configuração).
    • Nesse ponto, a configuração DefaultJobManager armazenada em crx-quickstart/launchpad/config/org/apache/sling/event/impl/jobs/DefaultJobManager.config entra em um estado inconsistente. E mesmo que a propriedade "Manipulador de eventos de trabalhos do Apache Sling" mostre "Processamento de trabalhos ativado" para estar em estado marcado, quando se navega até a guia Eventos do Sling, ela mostra a mensagem - O PROCESSAMENTO DE TRABALHO ESTÁ DESATIVADO e a replicação não funciona.
    • Para resolver esse problema, é necessário navegar até a página Configuração do console do OSGi e excluir a configuração do "Apache Sling Job Event Handler". Em seguida, reinicie o nó mestre do cluster para obter a configuração de volta a um estado consistente. Isso deve corrigir o problema e a replicação começará a funcionar novamente.
Criar um Replication.log
Às vezes, pode ser muito útil definir todos os logs de replicação a serem adicionados em um arquivo de log separado no nível DEBUG. Para fazer isso:
  1. Acesse https://host:port/system/console/configMgr e faça logon como administrador.
  2. Localize a fábrica do Apache Sling Logging Logger e crie uma instância clicando no botão + à direita da configuração de fábrica. Isso criará um novo logger.
  3. Defina a configuração desta forma:
    • Nível de registro: DEPURAÇÃO
    • Caminho do arquivo de log: logs/replication.log
    • Categorias: com.day.cq.replication
  4. Se você suspeitar que o problema esteja relacionado ao envio de eventos/trabalhos de qualquer forma, você também poderá adicionar esse pacote java em categorias:org.apache.sling.event

Pausando Fila do Agente de Replicação

Às vezes, pode ser adequado pausar a fila de replicação para reduzir a carga no sistema do autor, sem desativá-la. Atualmente, isso só é possível por meio de uma hack de configuração temporária de uma porta inválida. A partir da versão 5.4, você pode ver o botão de pausa na fila do agente de replicação, ele tem algumas limitações
  1. O estado não é persistente, o que significa que se você reiniciar um servidor ou um pacote de replicação for reciclado, ele retornará ao estado de execução.
  2. A pausa fica ociosa por um período mais curto (OOB 1 hora após nenhuma atividade com replicação por outros processos) e não por um tempo mais longo. Porque há um recurso no sling que evita os encadeamentos ociosos. Basicamente, verifique se um thread de fila de trabalhos não está sendo utilizado por mais tempo, se for esse o caso, inicia os ciclos de limpeza. Devido ao ciclo de limpeza, ele interrompe o thread e, portanto, a configuração pausada é perdida. Como os trabalhos são persistentes, ele inicia um novo thread para processar a fila que não tem detalhes da configuração pausada. Devido a esta fila, o estado de execução é transformado.

As permissões da página não são replicadas na ativação do usuário

As permissões de página não são replicadas porque são armazenadas nos nós aos quais o acesso é concedido, não com o usuário.
Em geral, as permissões de página não devem ser replicadas do autor para publicação e não são, por padrão. Isso porque os direitos de acesso devem ser diferentes nesses dois ambientes. Portanto, é recomendável configurar ACLs na publicação separadamente do autor.

Fila de replicação bloqueada ao replicar informações de namespace do Autor para publicação

Em alguns casos, a fila de replicação é bloqueada ao tentar replicar informações do namespace da instância do autor para a instância de publicação. Isso ocorre porque o usuário de replicação não tem jcr:namespaceManagement privilégio. Para evitar esse problema, verifique se:
  • O usuário de replicação (conforme configurado na guia Transporte >Usuário) também existe na instância Publicar.
  • O usuário tem privilégios de leitura e gravação no caminho onde o conteúdo está instalado.
  • O usuário tem jcr:namespaceManagement privilégios no nível do repositório. Você pode conceder o privilégio da seguinte maneira:
  1. Faça logon no CRX/DE ( https://localhost:4502/crx/de/index.jsp ) como administrador.
  2. Clique na guia Controle de acesso.
  3. Selecione Repositório .
  4. Clique em Adicionar entrada (o ícone de adição).
  5. Insira o nome do usuário.
  6. Select jcr:namespaceManagement from the privileges list.
  7. Clique em OK.