- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Audit
- Settings
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Authentication
- Integrations
- Classic Robots
- Troubleshooting
Schreibgeschütztes Orchestrator-Replikat
Der Orchestrator verwaltet ein schreibgeschütztes Replikat seiner Betriebsdatenbank mit Lese-/Schreibzugriff, um die Leistung zu verbessern. Einige schreibgeschützte Workloads werden auf das schreibgeschützte Replikat geleitet, um den Verbrauch von Schreibreplikaten zu optimieren. Dadurch können Daten schneller gelesen und geladen werden, was wiederum die Leistung Ihres Systems gewährleistet.
Als Ergebnis dieser Implementierung kann eine geringfügige Verzögerung zwischen den Schreib- und Leseaktionen auftreten. Dies ist zu erwarten und hat keine Auswirkungen auf die Verfügbarkeit von Daten.
Ein Beispiel für dieses Szenario ist das Abrufen eines Warteschlangenelements, sobald es hinzugefügt wurde: Wenn dies über die Schnittstelle ausgeführt wird, werden die neuen Warteschlangenelemente möglicherweise nicht sofort angezeigt, da eine leichte Asynchronität zwischen der Betriebsdatenbank (wo das Element geschrieben wird) und der und das Replikat (das zum Lesen des Elements aufgerufen wird). Sie können dies jedoch vermeiden, indem Sie die Aktivität Get Transaction Item anstelle von Get Queue Items verwenden, da erstere das Warteschlangenelement in ihrer Antwort einschließt.