YugabyteDB operates with a two-server architecture: YB-TServers handle the data, while YB-Masters manage the metadata.
YB-TServer
and one for YB-Master
, to manage a database! Amusingly, that was a claim made by a YugabyteDB competitor in a recent “roachy” blog post.
YB-TServer
and YB-Master
servers can run on a single node:
[root@yugabytedb ~]# IP=$(hostname -I | awk '{print $1}')
[root@yugabytedb ~]# yb-master --master_addresses=$IP:7100 --fs_data_dirs="/root/disk1" --replication_factor=1 &
[1] 1324
[root@yugabytedb ~]# yb-tserver --tserver_master_addrs=$IP:7100 --rpc_bind_addresses=$IP --fs_data_dirs=/root/disk1 &
[2] 1378
[root@yugabytedb ~]# 2025-03-28 20:01:41.240 UTC [1473] LOG: YugaByte is ENABLED in PostgreSQL. Transactions are enabled.
2025-03-28 20:01:41.257 UTC [1473] LOG: pgaudit extension initialized
2025-03-28 20:01:41.350 UTC [1473] LOG: redirecting log output to logging collector process
2025-03-28 20:01:41.350 UTC [1473] HINT: Future log output will appear in directory "/root/disk1/yb-data/tserver/logs".
[root@yugabytedb ~]# ysqlsh -h $IP
ysqlsh (15.2-YB-2.25.1.0-b0)
Type "help" for help.
yugabyte=# \! [ "$(ps -e | grep -E 'yb-master|yb-tserver' | wc -l)" -eq 2 ] && echo "Both yb-master and yb-tserver are running on a single
server!!!" || echo "Process count is not 2."
Both yb-master and yb-tserver are running on a single server!!!
YB-TServer
and YB-Master
servers.
[root@yugabytedb ~]# yugabyted start --advertise_address=$IP > start.log
[root@yugabytedb ~]# ysqlsh -h $IP
ysqlsh (15.2-YB-2.25.1.0-b0)
Type "help" for help.
yugabyte=# \! [ "$(ps -e | grep -E 'yb-master|yb-tserver' | wc -l)" -eq 2 ] && echo "yugabyted also runs both yb-master and yb-tserver are running on a single server!" || echo "Process count is not 2."
yugabyted also runs both yb-master and yb-tserver are running on a single server!
YB-TServer
and YB-Master
processes on every node in the cluster to ensure high availability and scalability. However, in larger deployments, you have the flexibility to run YB-Master
on dedicated nodes for improved performance and fault tolerance. For the tech enthusiasts (i.e., nerds) out there…
YugabyteDB actually operates with a single binary: YB-Server
, which can function as either a master or a TServer. The YB-Master
and YB-TServer
binaries are simply symlinks to YB-Server
, with the appropriate flags set.
From a technical perspective, this design allows for efficient resource provisioning for each role. The control plane (master) requires CPU resources to manage metadata and coordination tasks, which can lead to contention in large clusters where the master leader acts as a noisy neighbor. Deploying masters on separate nodes helps mitigate this impact.
This approach aligns with key design principles, including Separation of Concerns, Modular Design, Layered Architecture, Command-Query Separation, Domain-Driven Design, and Microservices Architecture.
Have Fun!
