Secondary Server Nodes - optimize storage & costs with Axon

Cost optimization for Axon Server deployments without sacrificing performance is very important to our customers. The most commonly used technique is the optimization of storage for the events. To cater for this optimized storage, Axon Server Enterprise Edition (ASEE) provides the concept of multi-tiered storage - a secondary server node. This capability not only helps lower storage costs but also helps retain the performance and, in some cases, actually improvising it. 

This technique splits the storage of events across multiple nodes within an ASEE cluster. ASEE nodes have designated roles within a cluster:  Primary  / Backup and Messaging-Only. 

ASEE introduced a new role - Secondary since version 4.4, to cater for this split (also known as multi-tier) storage requirement. By designating a node as a “Secondary” node within a cluster, the storage of events is distributed between the “Primary” and “Secondary” nodes. 

How do the secondary server nodes in Axon Server work?

If you add a node to an existing cluster of nodes, event information starts transferring. This transfer enables the secondary nodes to catch up with the current event storage mark within the Primary nodes. The primary nodes will only start to delete the events from their storage once the secondary node has acknowledged that all information is present.

Once the catchup is complete, whenever a new event is created, the primary nodes will send it to the secondary node as well, for storage. An important aspect is that secondary nodes only receive events, they do not need to provide acknowledgment for the transaction to be committed.

The entire flow is laid out in the figure below. We first mark the node with a secondary role which triggers the process of that node receiving the events, storing it and acknowledging the catchup. Once the ack is received, the primary server nodes will start deleting those events. This enables the allocation of more expensive disks for the primary nodes for an optimal storage architecture.

server nodes

How do you assign a role to a node?

There are three ways you can assign a SECONDARY role to a node within a replication group: 

  1. The Axon Server EE UI Console. Navigate to the Replication Groups icon on the navigation menu of the console which will open up the replication group maintenance screen. The nodes can be added as a MESSAGING_ONLY role within a replication group.

  2. The add-node-to-replication-group command with the role option as SECONDARY.

      • $ java -jar axonserver-cli.jar add-node-to-replication-group -S http://[node]:[port] -n [node name] -g [replication-group-name] -r SECONDARY

      • Mandatory parameters
        -c refers to an existing replication group
        -n refers to the node name that should be a member of this replication group
        -r as SECONDARY refers to the role of this node within the replication group

      • Optional parameters
        -S if not supplied connects by default to http://localhost:8024. If supplied, it should  be any node serving the _admin context
        -t refers to the access token to authenticate at the server

  3. Axon Server EE provided REST API (http:[server]:[port]/swagger-ui.html) which offers the replication-group-rest-controller to help perform role maintenance operations.

Once you have defined secondary server nodes for a replication group, this definition will apply to all contexts that are defined in the replication group. You can configure the retention time per context (on the primary), so for some contexts, you may have a longer retention time than for others. As the old data still needs to be available at least one Secondary node needs to be up at all times. So it is recommended to have at least two Secondary nodes.

To conclude, secondary server nodes offer a better mechanism to optimize and save on your storage costs efficiency with ASEE deployments.

Would you like to learn more about Axon Server Enterprise? You can book a conversation with us through this link.

Vijay Nair
Architect, DDD, CQRS, and event sourcing evangelist. Vijay is author of "Practical Domain-Driven Design with Enterprise Java" and a prolific writer and presenter on DDD, CQRS, and event sourcing.
Vijay Nair

Share: