Distribution in Non-Mirror Mode
The diagram below represents a DAH run in non-mirror mode. The DAH distributes actions to several different child servers.
DAH system architecture (non-mirror mode)
The DAH uses either combinator or distributor virtual databases (VDBs) to distribute the actions to one or more specific Content component databases. The VDBs can map to one or more Content component databases, or to other virtual databases that you set up for the DAH. The way a VDB forwards actions depends on its type.
Combinator VDBs
A combinator virtual database forwards actions to all the databases that it represents. The VDB collates and sorts the results before it returns them.
Distributor VDBs
Distributor virtual databases map to a set of identical databases that contain identical data. You determine how the VDB distributes actions by using the DistributionMethod configuration parameter in the DAH configuration file. You can use one of the following methods:
-
Load balancing. The distributor VDB assigns each action to just one of the databases that it maps to. It uses a cumulative predictive algorithm to spread the action load efficiently. When this database responds with a result, the DAH forwards it to the client.
If a child server stops responding for any reason (for example, because of a hardware failure or network outage), the DAH marks it as down. DAH assigns incoming actions only to the available child servers, which saves the time that it takes to attempt to communicate with the failed child server.
-
Failover. The distributor VDB forwards incoming actions to the first database that you list in the virtual database MapsTo parameter. If this database stops responding for any reason (for example, because of a hardware failure or network outage), the DAH marks it as down. The DAH switches to the next database (the second one listed for the MapsTo parameter) and so on, and seamlessly continues to service client actions.
The DAH periodically checks child servers that are down. If it finds that a child server has come online again (for example, because the hardware has been rebooted or the network connection repaired), it adds it back into the list of active child servers.
-
For load balancing, this child server becomes a valid choice for actions again.
-
For failover, the first child server takes over as the sole destination for actions (because it has precedence over the child server that is currently serving results).