Problemen met replicatie oplossen troubleshooting-replication
Deze pagina biedt informatie over hoe u problemen met replicatie kunt oplossen.
Probleem problem
De replicatie (niet-omgekeerde replicatie) ontbreekt om één of andere reden.
Resolutie resolution
Er zijn diverse redenen voor replicatie om te ontbreken. In dit artikel wordt uitgelegd welke aanpak u kunt volgen bij het analyseren van deze kwesties.
worden de replicaties teweeggebracht bij allen wanneer het klikken van de Activate knoop? Als NIET dan het volgende doet:
- Ga naar /crx/explorer en login als admin.
- "Content Explorer" openen
- Zie of bestaat een knoop /bin/replicate of /bin/replicate.json. Als het knooppunt bestaat, verwijdert u het en slaat u het op.
worden de replicaties een rij gevormd in de rijen van de replicatieagent?
Controleer dit door naar /etc/replication/agents.author.html te gaan dan de replicatieagenten klikken om te controleren.
als één agentenrij of een paar agentenrijen vast zijn:
-
Toon de rij geblokkeerde status? Zo ja, wordt de publicatie-instantie dan niet uitgevoerd of reageert deze niet? Controleer de publicatie-instantie om te zien wat er mis is. Dat wil zeggen, controleer de logboeken en controleer of er een fout OutOfMemory of een ander probleem is. Als het slechts langzaam is, dan neem draaddumps en analyseer hen.
-
Toon de rijstatus Rij actief - # hangend is? De replicatietaak kan in feite vastzitten in een socket die wacht tot de publicatie-instantie of Dispatcher reageert. Dit kan betekenen dat de publicatie-instantie of Dispatcher onder hoge druk staat of vastzit in een vergrendeling. Neem draaddumps van auteur en publiceer in dit geval.
- Open de draaddumps van auteur in een analysator van de draadstortplaats, controleer of het toont dat de sling van de replicatieagent de gebeurtenisbaan in socketRead vastzit.
- Open de draaddumps van publiceren in een analysator van de draadstortplaats, analyseer wat zou kunnen veroorzaken publiceer instantie om niet te antwoorden. U zou een draad met POST /bin/receive in zijn naam moeten zien die de draad is die de replicatie van auteur ontvangt.
als alle agentenrijen geplakt zijn
-
Het is mogelijk dat een bepaald stuk inhoud niet onder /var/replication/data kan in series worden vervaardigd toe te schrijven aan de corruptie van de bewaarplaats of een andere kwestie. Ga naar logs/error.log voor een verwante fout. Ga als volgt te werk om het slechte replicatiepunt te wissen:
- Ga naar https://<host>:<port>/crx/de en meld u aan als beheerder.
- Klik op "Gereedschappen" in het bovenste menu.
- Klik op de vergrootglasknop.
- Selecteer XPath als Type.
- Voer in het vak "Query" deze query/jcr:root/var/eventing/jobs//element({0,slingevent:Job)-volgorde in door @slingevent:created*
- Klik op Zoeken.
- In de resultaten zijn de belangrijkste items de meest recente slingerende taken. Klik op elke kopie en zoek de geplakte replicaties die overeenkomen met wat boven in de wachtrij wordt weergegeven.
-
Er kan iets mis zijn met het sling van de baanrijen van het gebeurteniskader. Start de bundel org.apache.sling.event opnieuw in de map/system/console.
-
Het kan zijn dat de verwerking van taken is uitgeschakeld. U kunt dat controleren onder Felix Console op het tabblad Gebeurtenis. Controleren of het scherm wordt weergegeven - Apache Sling Event (JOB PROCESSING IS UITGESCHAKELD!)
- Als dat het geval is, schakelt u Apache Sling Job Event Handler in op het tabblad Configuration in Felix Console. Mogelijk is het selectievakje 'Taakverwerking ingeschakeld' uitgeschakeld. Als dat wordt gecontroleerd en nog steeds wordt weergegeven dat 'taakverwerking is uitgeschakeld', controleert u of er sprake is van een overlay onder /apps/system/config die de taakverwerking uitschakelt. Probeer een osgi:config-knooppunt voor jobmanager.enabled met een booleaanse waarde voor true te maken en controleer opnieuw of de activering is gestart en er geen taken meer in de wachtrij staan.
-
Het zou ook het geval kunnen zijn dat de configuratie DefaultJobManager in een inconsistente staat krijgt. Dit kan gebeuren wanneer iemand handmatig de configuratie van de 'Apache Sling Job Event Handler' wijzigt via de OSGiconsole (Schakel bijvoorbeeld de eigenschap 'Job Processing Enabled' uit en schakel deze weer in en sla de configuratie op).
- Op dit punt wordt de configuratie DefaultJobManager die in crx-quickstart/launchpad/config/org/apache/sling/event/impl/jobs/DefaultJobManager.config wordt opgeslagen in een inconsistente staat. En alhoewel het bezit van de Gebeurtenis van de Baan van de "Apache het Verdelen van de Baan van de Gebeurtenis"om in gecontroleerde staat toont te zijn toegelaten, wanneer men aan het Verschuivende lusje van de Gebeurtenis navigeert, toont het het bericht - DE VERWERKING VAN DE TAAK WORDT UITGESCHAKELD en de replicatie werkt niet.
- Om deze kwestie op te lossen, navigeer aan de pagina van de Configuratie van de console OSGi en schrap de "Apache Sling de Handler van de Gebeurtenis van de Baan"configuratie. Dan begin de Hoofdknoop van de cluster opnieuw om de configuratie terug in een verenigbare staat te krijgen. Dit zou de kwestie moeten bevestigen en de replicatie begint opnieuw te werken.
creeer een replication.log
Soms is het nuttig om al replicatieregistreren te plaatsen om in een afzonderlijk logboekdossier op het niveau van DEBUG worden toegevoegd. Dit doet u als volgt:
-
Ga naar https://host:port/system/console/configMgr en meld u aan als beheerder.
-
Zoek de Apache Sling Logging Logger-fabriek en maak een instantie door op de knop + rechts van de fabrieksconfiguratie te klikken. Hiermee maakt u een nieuw logbestand.
-
Stel de configuratie als volgt in:
- Logniveau: FOUTOPSPORING
- Logbestandspad: logs/replication.log
- Categorieën: com.day.cq.replication
-
Als u vermoedt dat het probleem te maken heeft met sling-gebeurtenissen/taken, kunt u dit Java™-pakket ook toevoegen onder categorieën:org.apache.sling.event
Wachtrij replicatieagent pauzeren pausing-replication-agent-queue
Soms kan het geschikt zijn om de replicatiewachtrij te pauzeren om de belasting van het auteursysteem te verminderen zonder deze uit te schakelen. Momenteel, is dit slechts mogelijk door een hack van tijdelijk het vormen van een ongeldige haven. Vanaf 5.4 kon u pauzeknoop in replicatieagentenrij zien het één of andere beperking heeft
- De status blijft niet bestaan. Dit betekent dat als u een server opnieuw opstart of een replicatiebundel wordt gerecycled, de status weer actief wordt.
- De pauze is nutteloos voor een kortere periode (OOB 1 uur na geen activiteiten met replicatie door andere draden) en niet voor een langere tijd. Omdat er een functie in sling is die nutteloze draden vermijdt. Controleer in feite of een thread voor een taakwachtrij langer ongebruikt is, als dit het geval is, of er opschoningscycli zijn. Vanwege het opschoonprogramma stopt het de thread en daardoor gaat de gepauzeerde instelling verloren. Omdat de banen worden voortgeduurd, stelt het een nieuwe draad in werking om de rij te verwerken die geen details van de gepauzeerde configuratie heeft. Vanwege deze wachtrij wordt deze status ingeschakeld.
Paginamachtigingen worden niet herhaald bij activering van de gebruiker page-permissions-are-not-replicated-on-user-activation
Paginamachtigingen worden niet gerepliceerd omdat ze worden opgeslagen onder de knooppunten waartoe toegang wordt verleend, niet met de gebruiker.
In het algemeen moeten paginamachtigingen niet door de auteur worden gerepliceerd om te publiceren en zijn ze niet standaard. Dit komt omdat toegangsrechten in deze twee omgevingen verschillend zouden moeten zijn. Daarom adviseert de Adobe dat u ACLs bij publiceert, gescheiden van auteur vormt.
Replicatiereeks geblokkeerd tijdens replicatie van naamruimtegegevens van Auteur naar Publish replication-queue-blocked-when-replicating-namespace-information-from-author-to-publish
Soms wordt de replicatiewachtrij geblokkeerd wanneer wordt geprobeerd naamruimtegegevens te repliceren van de auteurinstantie naar de publicatieinstantie. Dit gebeurt omdat de replicatiegebruiker geen jcr:namespaceManagement
bevoegdheid heeft. Om dit probleem te voorkomen, moet u ervoor zorgen dat:
- De replicatiegebruiker (zoals die onder wordt gevormd Vervoertab>Gebruiker) bestaat ook op de instantie van Publish.
- De gebruiker heeft lees- en schrijfrechten op het pad waar de inhoud is geïnstalleerd.
- De gebruiker heeft
jcr:namespaceManagement
bevoegdheden op het niveau van de gegevensopslagruimte. U kunt deze bevoegdheid als volgt toekennen:
- Meld u aan bij CRX/DE (
https://localhost:4502/crx/de/index.jsp
) als beheerder. - Klik het Controle van de Toegang tabel.
- Selecteer Bewaarplaats.
- Klik toevoegen Ingang (het plusteken).
- Voer de naam van de gebruiker in.
- Selecteer
jcr:namespaceManagement
in de lijst met bevoegdheden. - Klik OK.