Mideye Server Clustering with Shared Database

Archived Documentation

This page documents Mideye Server version 5, which is no longer actively maintained. For current documentation, see Mideye Server v6.

Overview

Mideye Server clustering provides high availability by connecting multiple servers to the same database. Configuration changes propagate in real-time across all servers in the cluster.

Clustering requirements:

Component	Requirement
Database	Shared SQL Server or MySQL database
Cluster leader	One server designated for scheduled cleanup jobs
Manual sync	RADIUS servers and certificates require manual restart

---

To create a Mideye Server cluster, two or more Mideye Servers can be configured to use the same database. Changes made in any Mideye Server will propagate in real-time to the other servers.

There are two exceptions that require manual update on all servers

1. If a RADIUS-server is added or changed a manual restart of the service is required on all other servers.
2. When adding LDAPS or GUI certificates, these must be manually imported on all other servers.

Only one of the servers in a cluster should be configured to execute scheduled database cleanup.

Cluster settings

In case two or more Mideye Servers are configured to share the same database, only one of them should be configured to execute scheduled database cleanup (cluster leader).

In the server(s) not intended to be cluster learders, open as an administrator:

• Linux: /opt/mideyeserver/config/application-prod.yml
• Windows: C:\Program Files (x86)\Mideye Server 5\config\application-prod.yml

Navigate to the application section and add (or modify)

cluster-leader: false

See example below:

application:
    switch-host: primary.mideye.com
    switch-backup-host: secondary.mideye.com
    switch-port: XXXXX
    log-path: /opt/mideyeserver/log
    # In case the Mideye server is running in a cluster with
    # multiple instances against a clustered database
    # set this to false in the minion instances to prevent
    # potential deadlocks for scheduled cleanup jobs.
    # The default value is true as this is the commonly used setup.
    cluster-leader: false