Risoluzione dei problemi di replica

Questa pagina fornisce informazioni su come risolvere i problemi di replica.

Problema

La replica (replica non inversa) non riesce per qualche motivo.

Risoluzione

Ci sono varie ragioni per cui la replica non riesce. Questo articolo spiega l'approccio che si potrebbe adottare quando si analizzano questi problemi.

Le replicazioni vengono attivate quando si fa clic sul pulsante Attiva? In caso contrario, procedere come segue:

1. Vai a /crx/explorer e accedi come amministratore.
2. Apri "Esplora contenuti"
3. Vedi se esiste un nodo /bin/replicate o /bin/replicate.json. Se il nodo esiste, eliminalo e salva.

Le replicazioni vengono messe in coda nelle code degli agenti di replica?

Controlla questo andando a /etc/replication/agents.author.html, quindi fai clic sugli agenti di replica da controllare.

Se una coda dell'agente o alcune code dell'agente sono bloccate:

1. Visualizza la coda bloccato stato? In caso affermativo, l’istanza di pubblicazione non è in esecuzione o non risponde completamente? Controlla l'istanza di pubblicazione per vedere cosa c'è che non va (ad es. controlla i log, e vedi se c'è un errore OutOfMemory o qualche altro problema. Poi se è solo generalmente lento allora prendere i dump di thread e analizzarli.

2. Viene visualizzato lo stato della coda? La coda è attiva - # in sospeso? In sostanza, il processo di replica potrebbe essere bloccato in una lettura del socket in attesa della risposta dell'istanza o del dispatcher di pubblicazione. Ciò potrebbe significare che l’istanza o il dispatcher di pubblicazione è sotto carico elevato o bloccato in un blocco. Prendi i dump di thread dall'autore e pubblica in questo caso.

   • Apri i dump di thread dall'autore in un analizzatore di dump di thread, controlla se mostra che il processo di sling eventing dell'agente di replica è bloccato in un socketRead.
   • Apri i dump di thread da publish in un analizzatore di dump di thread, analizza cosa potrebbe causare la mancata risposta dell'istanza di pubblicazione. Dovresti visualizzare un thread con POST /bin/receive nel suo nome, ovvero il thread che riceve la replica dall'autore.

Se tutte le code dell'agente sono bloccate

1. È possibile che un certo contenuto non possa essere serializzato sotto /var/replication/data a causa di corruzione dell'archivio o di qualche altro problema. Controlla logs/error.log per un errore correlato. Per eliminare l'elemento di replica non valido, procedi come segue:

   1. Vai su https://<host>:<port>/crx/de e accedi come utente amministratore.
   2. Fai clic su "Strumenti" dal menu principale.
   3. Fare clic sul pulsante della lente d'ingrandimento.
   4. Selezionare "XPath" come Tipo.
   5. Nella casella "Query" inserisci questa query /jcr:root/var/eventing/jobs//element(*,slingevent:Job) ordine di @slingevent:created
   6. Fai clic su "Cerca"
   7. Nei risultati gli elementi principali sono gli ultimi lavori di eventing sling. Fai clic su ciascuna e trova le repliche bloccate che corrispondono a ciò che viene visualizzato nella parte superiore della coda.

2. Ci potrebbe essere qualcosa di sbagliato nell'alleggerire le code di lavoro del framework degli eventi. Prova a riavviare il bundle org.apache.sling.event in/system/console.

3. Potrebbe essere che l'elaborazione dei processi sia completamente disattivata. Puoi controllarlo sotto la console Felix nella scheda Sling Eventing. Controlla se viene visualizzato - Evento Sling Apache (L'ELABORAZIONE DEL PROCESSO È DISATTIVATA!)

   • Se sì, allora controlla Apache Sling Job Event Handler sotto la scheda Configuration in Felix Console. Potrebbe essere che la casella di controllo "Elaborazione processo abilitata" sia deselezionata. Se è selezionato e visualizza ancora che 'l'elaborazione del processo è disabilitata', quindi controlla se c'è una sovrapposizione sotto /apps/system/config che sta disabilitando l'elaborazione del processo. Prova a creare un nodo osgi:config per jobmanager.enabled con un valore booleano su true e controlla nuovamente se l'attivazione è iniziata e non ci sono più processi in coda.

4. È anche possibile che la configurazione di DefaultJobManager si trovi in uno stato incoerente. Questo può accadere quando qualcuno modifica manualmente la configurazione di 'Apache Sling Job Event Handler' tramite l'OSGiconsole (ad esempio, disattiva e riattiva la proprietà 'Job Processing Enabled' e salva la configurazione).

   • A questo punto la configurazione DefaultJobManager memorizzata in crx-quickstart/launchpad/config/org/apache/sling/event/impl/jobs/DefaultJobManager.config si trova in uno stato incoerente. E anche se la proprietà 'Apache Sling Job Event Handler' mostra che 'Job Processing Enabled' è in stato selezionato, quando si passa alla scheda Sling Eventing, mostra il messaggio - JOB PROCESSING IS DISABLED e la replica non funziona.
   • Per risolvere questo problema, è necessario passare alla pagina Configurazione della console OSGi ed eliminare la configurazione "Apache Sling Job Event Handler". Quindi riavvia il nodo principale del cluster per riportare la configurazione in uno stato coerente. Questo dovrebbe risolvere il problema e la replica inizierà a funzionare di nuovo.

Creare un file replication.log

A volte può essere molto utile impostare tutte le registrazioni di replica da aggiungere in un file di log separato a livello di DEBUG. Per effettuare questo collegamento:

1. Vai su https://host:port/system/console/configMgr e accedi come amministratore.

2. Trova la fabbrica del logger di registrazione Apache Sling e crea un’istanza facendo clic sul pulsante + a destra della configurazione di fabbrica. Verrà creato un nuovo logger di registrazione.

3. Imposta la configurazione come segue:

   • Livello di log: DEBUG
   • Percorso file di registro: logs/replication.log
   • Categorie: com.day.cq.replication

4. Se sospetti che il problema sia correlato all'evento o ai lavori di sling in qualsiasi modo, puoi anche aggiungere questo pacchetto java in categories:org.apache.sling.event

Sospensione della coda dell'agente di replica

A volte potrebbe essere opportuno mettere in pausa la coda di replica per ridurre il carico sul sistema di authoring, senza disattivarlo. Attualmente questo è possibile solo tramite un hack di configurazione temporanea di una porta non valida. A partire da 5.4 è possibile vedere il pulsante di pausa nella coda dell'agente di replica ha alcune limitazioni

1. Lo stato non viene mantenuto, il che significa che se si riavvia un server o un bundle di replica viene riciclato, ritorna allo stato di esecuzione.
2. La pausa è inattiva per un periodo più breve (OOB 1 ora dopo nessuna attività con replica da parte di altri thread) e non per un periodo di tempo più lungo. Perché c'è una funzione in sling che evita i thread inattivi. In pratica, controlla se un thread della coda di lavoro è stato inutilizzato per un periodo di tempo più lungo, se così facendo si innesca i cicli di pulizia. A causa del ciclo di pulizia arresta il thread e quindi l'impostazione sospesa viene persa. Dal momento che i processi sono persistenti, avvia un nuovo thread per elaborare la coda che non ha dettagli della configurazione sospesa. A causa di questa coda si trasforma in stato di esecuzione.

Le autorizzazioni di pagina non vengono replicate all'attivazione dell'utente

Le autorizzazioni di pagina non vengono replicate perché sono memorizzate sotto i nodi a cui è concesso l'accesso, non con l'utente.

In generale, le autorizzazioni della pagina non devono essere replicate dall'autore per la pubblicazione e non sono per impostazione predefinita. Questo perché i diritti di accesso devono essere diversi in questi due ambienti. Pertanto si consiglia di configurare le ACL al momento della pubblicazione separatamente dall'autore.

Coda di replica bloccata durante la replica delle informazioni sullo spazio dei nomi da Author a Publish

In alcuni casi la coda di replica viene bloccata quando si tenta di replicare le informazioni sullo spazio dei nomi dall'istanza dell'autore all'istanza di pubblicazione. Questo accade perché l'utente di replica non ha jcr:namespaceManagement privilegio. Per evitare questo problema, assicurati che:

• L'utente di replica (come configurato in Trasporti tab>User) esiste anche nell'istanza Publish.
• L'utente dispone dei privilegi di lettura e scrittura nel percorso in cui è installato il contenuto.
• L'utente ha jcr:namespaceManagement a livello di archivio. Puoi concedere il privilegio come segue:

1. Accedi a CRX/DE ( https://localhost:4502/crx/de/index.jsp) come amministratore.
2. Fai clic sul pulsante Controllo degli accessi scheda .
3. Seleziona Archivio.
4. Fai clic su Aggiungi voce (l’icona più).
5. Immettere il nome dell'utente.
6. Seleziona jcr:namespaceManagement dall'elenco dei privilegi.
7. Fai clic su OK.

Risorse Business.Adobe.com

Style System Personalized Experiences Content As A Service Version History Digital Rights Management Content Management System