1) Failover for High Availability in a Single Datacenter
Here a primary MongoDB will be used for Read/Write. So the multiple Oak instances accessing a MongoDB replica set within a single data center.
This setup helps for high availability and redundancy in the event of a hardware or network failure
Major advantages are:
2) Failover Across Multiple Datacenters
Here multiple Data Centers are involved. Primary MongoDB will be replicated to secondary systems. So multiple Oak instances accessing a MongoDB replica set across multiple data centers. In this configuration, MongoDB replication provides the same high availability and redundancy as compared to the previous configuration but it also includes the ability to handle a data center outage.
- Scalability
- High availability
- Redundancy
- Automated failover of data layer
2) Failover Across Multiple Datacenters
Here multiple Data Centers are involved. Primary MongoDB will be replicated to secondary systems. So multiple Oak instances accessing a MongoDB replica set across multiple data centers. In this configuration, MongoDB replication provides the same high availability and redundancy as compared to the previous configuration but it also includes the ability to handle a data center outage.
Major advantages are
Always remember this. Adobe highly recommends TarMK as the default persistence technology for both the AEM Author and Publish instances.
Footnotes:
What is MongoMK Arbiter? Why we need an Arbiter?
In software, the CAP theorem says, "If there are an equal number of servers on either side of the partition, the database cannot maintain CAP (Consistency, Availability, and Partition tolerance). An Arbiter is specifically designed to create an -imbalance- or majority on one side so that a primary can be elected in this case."
As per MongoDB site(https://docs.mongodb.com/v3.4/tutorial/add-replica-set-arbiter/) "Arbiters are MongoDB instances that are part of a replica set but do not hold data. Arbiters participate in elections in order to break ties. If a replica set has an even number of members, add an arbiter. Arbiters have minimal resource requirements and do not require dedicated hardware. You can deploy an arbiter on an application server or a monitoring host."
If you get an even number of nodes on both sides, MongoDB will not elect a primary and your set will not accept writes.
- Scalability
- High availability
- Redundancy
- Automated failover of data layer
Always remember this. Adobe highly recommends TarMK as the default persistence technology for both the AEM Author and Publish instances.
Footnotes:
What is MongoMK Arbiter? Why we need an Arbiter?
In software, the CAP theorem says, "If there are an equal number of servers on either side of the partition, the database cannot maintain CAP (Consistency, Availability, and Partition tolerance). An Arbiter is specifically designed to create an -imbalance- or majority on one side so that a primary can be elected in this case."
As per MongoDB site(https://docs.mongodb.com/v3.4/tutorial/add-replica-set-arbiter/) "Arbiters are MongoDB instances that are part of a replica set but do not hold data. Arbiters participate in elections in order to break ties. If a replica set has an even number of members, add an arbiter. Arbiters have minimal resource requirements and do not require dedicated hardware. You can deploy an arbiter on an application server or a monitoring host."
If you get an even number of nodes on both sides, MongoDB will not elect a primary and your set will not accept writes.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.