Risoluzione dei problemi relativi alla replica troubleshooting-replication
Questa pagina fornisce informazioni su come risolvere i problemi di replica.
Problema problem
La replica (replica non inversa) non riesce per qualche motivo.
Risoluzione resolution
Esistono diversi motivi per cui la replica non riesce. Questo articolo spiega l’approccio che si potrebbe adottare quando si analizzano questi problemi.
Le repliche vengono attivate quando si fa clic sul pulsante Attiva? Se NON lo è, eseguire le operazioni seguenti:
- Vai a
/crx/explorere accedi comeadmin. - Apri “Esplora contenuti”
- Verificare se esiste un nodo
/bin/replicateo/bin/replicate.json. Se il nodo esiste, eliminalo e salvalo.
Le repliche vengono messe in coda nelle code dell’agente di replica?
Controllare l’operazione accedendo a /etc/replication/agents.author.html, quindi fare clic sugli agenti di replica da controllare.
Se una o più code di agenti sono bloccate:
-
La coda mostra lo stato bloccato? In caso affermativo, l’istanza Publish non è in esecuzione o non risponde? Controlla l’istanza Publish per vedere cosa c’è di sbagliato. In altre parole, controlla i registri e verifica se è presente un errore OutOfMemory o un altro problema. Se è semplicemente lento, prendi le immagini thread e analizzale.
-
Lo stato della coda indica che la coda è attiva - n. in sospeso? Il processo di replica potrebbe essere bloccato in un socket letto in attesa della risposta dell’istanza Publish o di Dispatcher. Ciò potrebbe significare che l’istanza Publish o Dispatcher è sotto un carico elevato o è bloccata in un blocco. In questo caso, prendi le immagini thread da authoring e pubblica.
- Apri le immagini thread dall’autore in un analizzatore di immagini thread, verifica se il processo di eventi sling dell’agente di replica è bloccato in un socketRead.
- Apri le immagini thread da Publish in un analizzatore di immagini thread e analizza cosa potrebbe causare la mancata risposta dell’istanza Publish. Dovrebbe essere presente un thread il cui nome contiene POST
/bin/receive. Questo è il thread che riceve la replica dall’autore.
Se tutte le code dell’agente sono bloccate
-
È possibile che un determinato contenuto non possa essere serializzato in /var/replication/data a causa di un danneggiamento dell’archivio o per altri problemi. Controlla logs/error.log per un errore correlato. Per cancellare l’elemento di replica non valido, effettua le seguenti operazioni:
- Vai a
https://<host>:<port>/crx/dee accedi come utente amministratore. - Fare clic su Strumenti nel menu principale.
- Fare clic sul pulsante della lente di ingrandimento.
- Selezionare “XPath” come Tipo.
- Nella casella “Query” immettere la query
/jcr:root/var/eventing/jobs//element(*,slingevent:Job) order by @slingevent:created - Fare clic su “Search” (Cerca).
- Nei risultati, gli elementi principali sono gli ultimi sette processi con eventi. Fai clic su ciascuna replica e trova le repliche bloccate corrispondenti a quelle visualizzate nella parte superiore della coda.
- Vai a
-
Potrebbe essersi verificato un errore con le code dei processi del framework eventi Sling. Provare a riavviare il bundle
org.apache.sling.eventin/system/console. -
È possibile che l’elaborazione del processo sia disattivata. Puoi verificarlo in Felix Console nella scheda Evento di Sling. Controlla se viene visualizzato - Evento Apache Sling (L’ELABORAZIONE DEL PROCESSO È DISABILITATA!)
- In caso affermativo, controlla Apache Sling Job Event Handler nella scheda Configuration della console Felix. È possibile deselezionare la casella di controllo ‘Elaborazione processo abilitata’. Se questa opzione è selezionata e viene comunque visualizzato il messaggio ‘Elaborazione processo disabilitata’, verificare se è presente una sovrapposizione in
/apps/system/configche disabilita l’elaborazione del processo. Provare a creare un nodoosgi:configperjobmanager.enabledcon un valore booleano ditruee verificare di nuovo se l’attivazione è iniziata e non sono presenti altri processi in coda.
- In caso affermativo, controlla Apache Sling Job Event Handler nella scheda Configuration della console Felix. È possibile deselezionare la casella di controllo ‘Elaborazione processo abilitata’. Se questa opzione è selezionata e viene comunque visualizzato il messaggio ‘Elaborazione processo disabilitata’, verificare se è presente una sovrapposizione in
-
È inoltre possibile che la configurazione di DefaultJobManager entri in uno stato incoerente. Questo può accadere quando qualcuno modifica manualmente la configurazione “Apache Sling Job Event Handler” tramite la console OSGi (ad esempio, disabilita e riabilita la proprietà “Job Processing Enabled” e salva la configurazione).
- A questo punto, la configurazione DefaultJobManager archiviata in
crx-quickstart/launchpad/config/org/apache/sling/event/impl/jobs/DefaultJobManager.configentra in uno stato incoerente. E anche se la proprietà “Apache Sling Job Event Handler” mostra che “Elaborazione del processo abilitata” è in stato selezionato, quando si passa alla scheda Evento Sling, viene visualizzato il messaggio - ELABORAZIONE DEL PROCESSO DISABILITATA e la replica non funziona. - Per risolvere questo problema, accedi alla pagina Configurazione della console OSGi ed elimina la configurazione “Apache Sling Job Event Handler”. Riavviare quindi il nodo Master del cluster per riportare la configurazione in uno stato coerente. Questo dovrebbe risolvere il problema e far ripartire la replica.
- A questo punto, la configurazione DefaultJobManager archiviata in
Creare un replication.log
A volte è utile impostare tutte le registrazioni di replica da aggiungere in un file di registro separato a livello di DEBUG. Per effettuare questo collegamento:
-
Vai a
https://<host>:<port>/system/console/configMgre accedi come utente amministratore. -
Trovare la factory del logger di registrazione Apache Sling e creare un’istanza facendo clic sul pulsante + a destra della configurazione di fabbrica. Verrà creato un nuovo logger di registrazione.
-
Imposta la configurazione come segue:
- Livello registro:
DEBUG - Percorso file di registro:
logs/replication.log - Categorie:
com.day.cq.replication
- Livello registro:
-
Se si sospetta che il problema sia correlato in qualche modo a sette eventi/processi, è possibile aggiungere anche questo pacchetto Java; in
categories:org.apache.sling.event.
Sospensione coda agente di replica pausing-replication-agent-queue
A volte può essere opportuno mettere in pausa la coda di replica per ridurre il carico sul sistema di authoring, senza disabilitarla. Attualmente, ciò è possibile solo tramite un hack di configurazione temporanea di una porta non valida. Dalla versione 5.4 in poi, nella coda dell’agente di replica era presente un pulsante di pausa con alcune limitazioni:
- Lo stato non è persistente. In altre parole, se si riavvia un server o un bundle di replica viene riciclato, viene ripristinato lo stato di esecuzione.
- La pausa è inattiva per un periodo più breve (OOB 1 ora dopo nessuna attività con replica da parte di altri thread). Questo perché esiste una funzione in Sling che evita i thread inattivi. Verificare se un thread della coda processi è rimasto inutilizzato per molto tempo. In tal caso, si avviano i cicli di pulizia. A causa del ciclo di pulizia, il thread viene arrestato e l’impostazione di pausa viene quindi persa. Poiché i processi sono persistenti, viene avviato un nuovo thread per elaborare la coda, che non dispone dei dettagli della configurazione in pausa. Per questo motivo, la coda entra in uno stato di esecuzione.
Le autorizzazioni pagina non vengono replicate al momento dell’attivazione dell’utente page-permissions-are-not-replicated-on-user-activation
Le autorizzazioni di pagina non vengono replicate perché sono memorizzate nei nodi a cui è concesso l’accesso, non con l’utente.
In generale, le autorizzazioni di pagina non devono essere replicate dall’autore alla pubblicazione e non sono per impostazione predefinita. Questo perché i diritti di accesso dovrebbero essere diversi in questi due ambienti. Pertanto, Adobe consiglia di configurare gli ACL in fase di pubblicazione, separatamente da Author.
Coda di replica bloccata durante la replica delle informazioni sullo spazio dei nomi da Author a Publish replication-queue-blocked-when-replicating-namespace-information-from-author-to-publish
A volte la coda di replica viene bloccata quando si tenta di replicare le informazioni sullo spazio dei nomi dall’istanza di authoring all’istanza di pubblicazione. Ciò si verifica perché l’utente di replica non dispone del privilegio jcr:namespaceManagement. Per evitare questo problema, assicurati che:
- L’utente di replica (configurato nella scheda Trasporto>Utente) esiste anche nell’istanza di pubblicazione.
- L’utente dispone dei privilegi di lettura e scrittura nel percorso in cui viene installato il contenuto.
- L’utente dispone del privilegio
jcr:namespaceManagementa livello di repository. È possibile concedere il privilegio nel modo seguente:
- Accedere a CRX/DE (
https://<host>:<port>/crx/de/index.jsp) come amministratore. - Fare clic sulla scheda Controllo di accesso.
- Seleziona Archivio.
- Fai clic su Aggiungi voce (icona più).
- Immettere il nome dell’utente.
- Selezionare
jcr:namespaceManagementdall’elenco dei privilegi. - Fai clic su OK.