AggreGate Server has built-in High Availability Database Cluster engine that may perform database replication and load balancing in a generic database-independent way. This engine normally shares the same configuration on AggreGate Master and Failover servers. It is configured to:
| • | Monitor connections with several database servers. |
| • | Write any data generated by AggreGate Server to all databases. |
| • | Once certain data is requested by AggreGate Server, choose a less-loaded database to get data from. This ensures load balancing between database servers. |
| • | Once a certain database has been recovered after temporary failure or unavailability period, synchronize the data between the failed database and other (active) databases. |
Pros and Cons
Pros:
| • | Configuration is easy and database-independent. |
| • | Data is replicated to all database cluster nodes to unsure reliability. |
| • | Database servers load balancing upon read operations. |
Cons:
| • | Slight overhead of AggreGate Master server during database write operations. |
| • | All database nodes must use the same auth credentials. |
Below is the list of configuration changes required to set up AggreGate database replication.
Database Servers
| • | Set up two or more identical database servers. |
| • | Configure all servers to accept connections from IP addresses or host names of AggreGate Master and Failover servers. |
Master AggreGate Server
| • | Start Server Configurator. |
| • | Enable Database Clustering option in the Database tab. |
| • | Edit the Cluster Databases table by adding a record for each of the database servers. Make sure that you've specified correct URL of each database. |
| • | Make sure that Database Username, Database Password and Database Dialect settings in the Database tab match your databases. |
| • | Save global configuration and start the server. It should now connect to the database cluster. |
|
All databases in the cluster must use the same username/password pair for accepting AggreGate Server connections. |
Failover AggreGate Server
| • | Perform the same changes as on the Master server, i.e. enable Database Clustering and add records to the Cluster Databases table. |
Database Failure Handling
The database clustering engine performs periodic checks of each database's availability and integrity. If a certain database has failed it is disconnected from the cluster and marked as Not Active. The server does not attempt to perform further read/write operations with this database.
Database Activation and Synchronization
The server periodically checks availability of all inactive databases. If an inactive database appears to be alive, the server will automatically reactivate it. This process involves synchronizing data between reactivated database and other databases in the cluster, and thus, may take significant time and cause high consumption of server resources.
Viewing Database Cluster Status
To view the status of individual databases participating in the database cluster, open Cluster Databases table in the AggreGate Server global configuration. Active field in this table indicates whether a database is currently being used by the cluster.
Cluster Databases State Persistence
AggreGate remembers what cluster databases are active and persists this information between server restarts. The data is stored in OS-dependent way, e.g. in system registry (for Windows systems) or file (for Linux systems).
|
To make sure that cluster configuration file always matches remembered databases state, remove cluster databases only via server configurator utility or other AggreGate Server configuration methods. Do not remove database accounts from the database cluster configuration file by editing this file directly. |