TeamCity 2018.1 allows you to set up a “running builds node.” The node handles data coming in from the build agents. There’s also the “read-only node” for handling disaster recovery scenarios.
TeamCity 2018.2 expands this setup further, making it possible to delegate polling of version control systems to a secondary node.
Currently, it may seem a little complicated, but our intention is simple. We want to have a scalable architecture where you can add more nodes to the cluster so that all the nodes are uniform and can perform all the tasks in an interchangeable way. The only exception will be the main TeamCity server where we configure the cluster. Upgrade, licensing, and diagnostics are also handled by the main TeamCity server.
As a step towards this uniformity, there is no “read-only node” anymore, and it is now called a “secondary node.”
The secondary node is just a TeamCity server started with the additional nodeId argument:
TEAMCITY_SERVER_OPTS=-Dteamcity.server.nodeId=<some id> teamcity-server.bat|sh start
See our documentation on how to configure and start a secondary node.
By default, the secondary node acts as a read-only node. It does not change any data, but only shows the user interface in read-only mode. This setup is well-suited for disaster recovery tasks.
Using the Nodes configuration page of the main TeamCity server, it is now possible to delegate VCS repositories polling responsibility to this secondary node. After that, the secondary server will handle all VCS polling related tasks and commit hooks. In some scenarios, this can greatly reduce the CPU load of the main TeamCity server.
Note that if there are existing commit hooks on the main server, you do not need to change anything. The main server will accept the hook and delegate its processing to the secondary node.
Right now, the secondary node cannot handle data from agents like the running builds node can. But this will change in the future versions of TeamCity. Agents’ data handling will be another responsibility for the secondary node.