HA configuration

An HA configuration is a redundant operating setup that keeps message processing going even when a failure occurs.

HA mode comparison

NONE

Single node

Runs on a single server. All processes run without any HA handling.

ACTIVE-STANDBY

Active-standby redundancy

The primary runs all processes while the standby checks periodically and promotes itself automatically on failure.

ACTIVE-ACTIVE

Active-active redundancy

Both nodes process at the same time and separate records by agent_id. You need two unified API keys.

Configuration methods

Active-Standby.
Multi Active (distributed processing).
Control based on a shared DB lock or leader election.

Essential considerations

A lock/key policy that prevents duplicate sends.
State consistency for in-flight records during failover.
The recovery order for unfinished items on restart.

Operational checklist

Run failover tests on a regular basis.
Include DB and network disconnection scenarios in your verification.
Monitor the delay/loss/duplication metrics at the moment of the switchover.

HA mode

Set the HA behavior with the ha.mode value in msgConfig.yml.

NONE (single node)

YAML

ha:
  mode: none

Runs on a single server. Every process runs with no separate HA handling.

ACTIVE-STANDBY

YAML

ha:
  mode: active-standby
  status: primary        # Primary: primary / Standby: secondary
  primary:
    host: 192.168.1.10
    port: 5000
  retryInterval: 10000
  initialDelay: 5000

Primary: runs every process normally
Standby: checks the Primary server periodically and is promoted automatically on failure

ACTIVE-ACTIVE

YAML

ha:
  mode: active-active
  id: E1                 # 노드 1: E1 / 노드 2: E2

Both nodes process at the same time, and records are separated by the agent_id field.

On MySQL 8.0+ / MariaDB 10.6+ / Oracle 11.2+, FOR UPDATE SKIP LOCKED lets the nodes process without colliding. For an Active-Active configuration, issue two separate unified API keys.