AEM - Binary less replication
1 like730 views
The document discusses binary less replication in AEM, emphasizing its use cases and limitations, particularly in environments with shared datastores among instances. It explains how replication works using hashcode references instead of actual binaries and describes scenarios where this approach is beneficial, such as multiple data centers and disaster recovery instances. Additionally, it outlines the gateway instance method for replicating binaries while noting potential delays and the need for careful planning to handle failures.
AEM - Binary less replication
- 1. AEM – Binary less Replication Exploring binary less replication, its use cases & some special cases Ashokkumar T A | 17-Jan-2020
- 2. Binary less replication Binaries left out from the content being replicated • For assets, only its metadata gets replicated (usually) • Have shared datastore between author & all publish instances, so that binaries are accessible to publish instances • Can be leveraged if the architecture mandates having a shared datastore 2
- 3. How it works? • Replication package created with hashcode references instead of the actual binary • Receiver resolve hashcode references to the binary in its datastore • Hashcode references resolve on the receiver as both sender and receiver share a common datastore • If receiver not able to resolve, falls back on the default replication approach to get binaries replicated • Overall replication could still be successful even when binary less replication fails 3 Log statements with “FAILED PATHS START”, “FAILED PATHS END” denotes failure & log statements with “set using a reference” denotes success of binary less replication
- 4. Use cases Useful in setups using shared datastore across instances • All AEM instances (Author & all publishers) share common datastore • Keeping your Author separate, but all publishers share common datastore • Multiple data centers – Instances in each data center sharing common datastore • DR instances completely isolated from Primary environment 4
- 5. Special Case Author has a separate datastore and all publish instances share a common datastore 5 1. Designate one publish instance as a Gateway instance 2. Default replication to this gateway publish instance 3. Chain replicate from Gateway instance to all other publish instances 4. This ensures the binaries are replicated to shared datastore through the gateway instance before binary less replication kicks in
- 6. Replication through gateway instance Replication flow through a designated Gateway instance 6 Gateway instance approach can be used in any scenario where an isolated set of instance share a common datastore (Multiple data centers, DR environments, …)
- 7. Limitations Some of the limitation in using Gateway instance to use binary less replication • Introduces a delay as replication is now a 2 step process • New content visible on gateway instance before other publishers – Keep gateway instance internal (only for replication and not for serving live traffic) if possible • Replication status on author goes green as soon as replication to gateway instance is successful • Be ready to handle gateway instance failures (make another instance as gateway) 7
- 8. Final word Binary less is very useful when your architecture involves multiple instances sharing a common datastore… • Understand the holistic picture of your configuration (Data centers, DR approach, …) and plan replication configuration as appropriate • The gateway instance approach handles most if not all of the scenarios… But there are limitations. Validate the limitations and plan remedies if using this approach 8 More details at https://aem-musings.blogspot.com/2019/06/applying-binary-less-replication.html
- 9. Thank You 9 Feedback and suggestions welcome. Please write to [email protected]