Inconsistência no repositório

Sintomas

É exibida uma das seguintes mensagens no arquivo de log:
WARN org.apache.jackrabbit.core.query.lucene.DocId$UUIDDocId -
        Unknown parent node with id ...ERROR ... failed to read bundle: ...

Causa

Esses problemas podem ter várias causas. As possíveis causas (dependendo da versão do CRX) são:

A causa mais comum é a modificação simultânea usando a mesma sessão. Nesse caso, o arquivo CRX error.log provavelmente contém pelo menos um ConcurrentModificationException.

Análise, Resolução

Esses sintomas indicam que o índice (e possivelmente também o workspace) pode ser inconsistente.

Normalmente, o impacto de uma inconsistência é baixo. Um dos problemas é que o arquivo de log é preenchido com mensagens de erro devido a uma inconsistência.

Tipos de inconsistências

  • Filho órfão
    • Mensagem de erro: NodeState CHILD_UUID references inexistent parent quid PARENT_UUID
    • Mensagem de verificação de consistência: ConsistencyCheck: Not repairable: Node
      CHILD_UUID has unknown parent:
      PARENT_UUID (ConsistencyCheck.java, line 116)
    • Solução atual: Use o console do CRX (consulte esse artigo)
  • Pai referenciando filho inexistente
  • Filho fazendo referência a pai inválido
    • Mensagem de erro: ChildNode has invalid parent quid: INVALID_PARENT_UUID (instead of VALID_PARENT_UUID)
    • Solução atual: Use o console do CRX (consulte esse artigo)
  • Pai não referenciando filho existente
    • Mensagem de erro: javax.jcr.ItemNotFoundException: failed to build path of CHILD_UUID: PARENT_UUID has no child entry for CHILD_UUID
    • Solução atual: Use o console do CRX (consulte este artigo)
  • Existe um nó
  • Inconsistência no índice de pesquisa
  • Inconsistência de pesquisa
    • Mensagem de erro: "Caused by: javax.jcr.ItemNotFoundException: 59192bc8-ce8b-4ed7-af8e-018f6aa2d496" where "org.apache.jackrabbit.core.query.lucene.RowIteratorImpl$RowImpl.getNode" can be seen in the stack trace.
    • Solução atual: verifique e corrija a consistência de índice de pesquisa adhocenable="false" href="#Search_Index_Consistency_Check_and_Fix">
  • Inconsistência relacionada à versão
    • Pilha de mensagem de erro mostra que está relacionada ao código org.apache.jackrabbit.core.version.InternalXAVersionManager
    • Solução atual: consulte esse artigo
  • Arquivo não encontrado
    • Mensagem de erro: ERROR TarPersistenceManager: Failed to read bundle: [quid]: java.io.IOException: File not found: nnnnn (TarPersistenceManager.java, line 1194)
      java.io.IOException: File not found: nnnnn
    • Solução atual: verifique se é possível encontrar esse arquivo em um backup (data_nnnnn.tar) ou remova o index_*.tar para reconstruí-lo na reinicialização.

Reparação do seu índice de pesquisa

As inconsistências do índice de pesquisa podem acontecer devido ao seguinte:

  • Desligamento com erros do processo java durante uma operação de gravação. Isso seria um comando kill -9 no Linux ou Unix e um comando kill do processo de gerenciador de tarefas no sistema operacional Windows.
  • Alguns bugs antigos no CRX que foram corrigidos nos últimos hotfixes CQ e CRX (para CRX2.2, 2.3 e 2.4). Para evitar isso, mantenha-se atualizado sobre os hotfixes do CRX para evitar tais problemas.  Se acha que não tem o hotfix mais recente, envie um tíquete de suporte ao suporte da Adobe para solicitar a correção mais recente.

Há duas maneiras de corrigir inconsistências no índice de pesquisa:

  • Execute uma verificação e correção de consistência do índice de pesquisa
  • Recrie seu índice de pesquisa

Verificação e correção de consistência do índice de pesquisa

Você pode executar uma verificação de consistência de índice na inicialização. No workspace.xml, adicione dois parâmetros no elemento <SearchIndex class="...">:

<param name="enableConsistencyCheck" value="true"/>
<param name="forceConsistencyCheck" value="true"/>

Um terceiro parâmetro controla se os erros devem ser reparados ou se devem ser apenas registrados:

<param name="autoRepair" value="false"/> <!-- default is true -->

Exemplo

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler">
    <param name="path" value="${wsp.home}/index"/>
    <param name="enableConsistencyCheck" value="true"/>
    <param name="forceConsistencyCheck" value="true"/>
    <param name="autoRepair" value="true"/>
</SearchIndex>

Recriação do índice de pesquisa

A recriação do índice de pesquisa corrigirá todas as inconsistências do índice de pesquisa. No entanto, isso demora consideravelmente mais do que a verificação e correção da consistência do índice de pesquisa.  Devido a isso, tenha cuidado ao planejar uma reconstrução do índice de pesquisa e, se você não puder ficar muito tempo inativo, considere fazer uma verificação e corrigi-la.

Planejamento da reconstrução de índice

Como o tempo necessário para reconstruir seu índice depende de diferentes fatores (como o número total de nós, tamanhos de arquivo de ativos e tipos de arquivo de ativos), você deve testar primeiro a reconstrução em um ambiente de não produção. Use o teste de não produção para calcular quanto tempo uma janela de interrupção será necessária na produção. Pequenos repositórios no tamanho de 2 a 10 GB podem levar de 30 minutos a 6 horas e maiores podem levar de 6 horas a 2 dias.

Como reconstruir o índice

Para reconstruir seu índice de pesquisa, faça o seguinte:

  1. Interrompa o CRX (ou CQ)
  2. Faça backup e exclua os seguintes diretórios em seu repositório: crx-quickstart/repository/workspaces/crx.default/index/ e crx-quickstart/repository/repository/index/
  3. Inicie o CRX (ou CQ), isso iniciará a reconstrução.  No CRX2.2, monitore logs/crx/error.log e no CRX2.3 monitore logs/error.log para visualizar o progresso.  A indexação foi concluída quando a instância do CRX está acessível.

Verificação e correção de consistência do Gerenciador de persistência do workspace

Se isso não ajudar e imprimir erros que não podem ser reparados, é provável que os dados do espaço de trabalho estejam inconsistentes.

Os gerenciadores de persistência podem verificar a consistência do repositório e corrigir problemas na inicialização. Para ativar a verificação de consistência e corrigir problemas automaticamente, inclua os seguintes parâmetros no repository.xml e no workspace.xml dentro de cada elemento <PersistenceManager class="...">, e reinicie o CRX.

Em uma instalação padrão do CQ5.2.X, esses arquivos podem ser encontrados em crx-quickstart/repository/workspaces/*/workspace.xml e crx-quickstart/server/runtime/0/_crx/WEB-INF/repository.xml.

No CQ5.3, repository.xml pode ser encontrado em crx-quickstart/repository/repository.xml.

Exemplo

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="consistencyCheck" value="true" />
    <param name="consistencyFix" value="true" />
</PersistenceManager>

A verificação e a correção (gerenciador de persistência ou índice) será executada na próxima inicialização. Após a conclusão da verificação de consistência, desative as configurações relevantes, caso contrário, a verificação de consistência sempre será executada ao inicializar o CRX.

Se apenas consistencyCheck estiver ativado, será criado um arquivo inconsistentBundleIds.txt no diretório do workspace.

Se apenas consistencyFix estiver ativado, o arquivo inconsistentBundleIds.txt será lido e esses nós serão corrigidos. O arquivo será excluído se tudo puder ser corrigido.

Correção de inconsistências em um cluster

Ao executar uma correção de consistência em um ambiente clusterizado, execute-a somente em um nó do cluster. Não inicie outros nós de cluster enquanto a correção de consistência estiver em execução. Após a conclusão, os outros nós do cluster podem ser iniciados.

Correção rápida de inconsistências

A verificação de consistência é lenta porque analisa todos os nós. Para reduzir o tempo de manutenção, execute a verificação de consistência em uma cópia do repositório e, em seguida, apenas corrija os nós corrompidos. Siga as etapas a seguir para fazer isso:

  • Copie o repositório usando o recurso Online Backup
  • Execute a verificação de consistência e corrija (conforme descrito acima) na cópia do repositório, possivelmente em uma máquina diferente
  • No arquivo de log do CRX, localize os UUIDs dos nós corrompidos
  • No repositório original, execute a verificação de consistência e corrija apenas esses nós

Para limitar a verificação de consistência e corrigir uma lista de nós, inclua os UUIDs desses nós na opção de configuração "consistencyCheckUUIDs":

Exemplo

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
    <param name="consistencyCheck" value="true" />
    <param name="consistencyCheckUUIDs" value="ea9cb12f-8a8f-4820-88b1-6d1c496a07cd,741c905c-cfb0-422f-acd4-e0a9cbde46c6" />
    <param name="consistencyFix" value="true" />
</PersistenceManager>

Impedindo corrupções do repositório

A partir do CRX 2.2, você pode adicionar este parâmetro jvm à inicialização do CRX/CQ5 para evitar corrupções:
-Dorg.apache.jackrabbit.core.state.validatehierarchy=true

Se estiver usando o servidor CQSE de início rápido, poderá adicionar o parâmetro à variável JVM_OPTS , por exemplo:

crx-quickstart\server\server.bat (Windows):
set JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true

ou crx-quickstart/server/start (Mac & Linux):
export JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true

Observação:

Uso da propriedade do sistema validateheirarchy causa uma pequena degradação do desempenho das operações de salvamento de sessão no repositório.  Ao planejar o uso deste recurso, sugerimos executar o teste antes para ver seu impacto.  Isso se aplica principalmente se tiver um aplicativo pesado para gravação.

Observação:

Desative a otimização de tar quando a verificação de consistência é executada para evitar a execução de otimização de tar e verificação de consistência em paralelo.  

Versões afetadas

1.X, 2.X

Logotipo da Adobe

Fazer logon em sua conta