Skip to main content
Once you’ve , it’s simple to run an insecure multi-node cluster locally.
To try CockroachDB Cloud instead of running CockroachDB yourself, refer to the .

Before you begin

  • Make sure you have already .
  • For quick SQL testing or app development, consider instead.
  • Running multiple nodes on a single host is useful for testing CockroachDB, but it’s not suitable for production. To run a physically distributed cluster, refer to or , and review the .
Reusing a previously initialized store when starting a new cluster is not recommended. If the store is incompatible with either the new CockroachDB binary or the new cluster configuration, this can lead to panics or other problems when starting a cluster. Instead, either move or delete the previous store directory before starting the cockroach process. An example of an incompatible configuration is if the new cluster is started with the --start-single-node flag, which disables replication, when the cluster configuration in the store has replication enabled.The store directory is cockroach-data/ in the same directory as the cockroach command by default, or the location passed to the --store flag otherwise. For details about configuring the store location, refer to .

Step 1. Start the cluster

This section shows how to start a cluster interactively. In production, operators usually use a process manager like systemd to start and manage the cockroach process on each node. Refer to .
  1. Use the command to start the node1 in the foreground:
The --background flag is not recommended. If you decide to start nodes in the background, you must also pass the --pid-file argument. To stop a cockroach process running in the background, extract the process ID from the PID file and pass it to the command to stop the node.In production, operators usually use a process manager like systemd to start and manage the cockroach process on each node. Refer to .
You’ll see a message like the following:
  1. Take a moment to understand the you used:
    • The --insecure flag makes communication unencrypted.
    • Since this is a purely local cluster, --listen-addr=localhost:26257 and --http-addr=localhost:8080 tell the node to listen only on localhost, with port 26257 used for internal and client traffic and port 8080 used for HTTP requests from the DB Console.
    • The --store flag indicates the location where the node’s data and logs are stored.
    • The --join flag specifies the addresses and ports of the nodes that will initially comprise your cluster. You’ll use this exact --join flag when starting other nodes as well. For a cluster in a single region, set 3-5 --join addresses. Each starting node will attempt to contact one of the join hosts. In case a join host cannot be reached, the node will try another address on the list until it can join the gossip network.
  2. In new terminal windows, start node2 and node3:
    These commands are the same as before but with unique --store, --listen-addr, and --http-addr flags.
  3. Use the command to perform a one-time initialization of the cluster, sending the request to any node on the --join list:
    You’ll see the following message:
    At this point, each node also prints helpful to its log, and to STDOUT in the terminal window where the node was started. For example, the following command retrieves node1’s startup details:
    The output will look something like this:

Step 2. Use the built-in SQL client

Now that your cluster is live, you can use any node as a SQL gateway. To test this out, let’s use CockroachDB’s built-in SQL client.
  1. In a new terminal, run the command and connect to node1:
    To exit the SQL shell at any time, you can use the \q command:
  2. Run some basic :
  3. In a new terminal window, open a new SQL shell and connect to node2:
In a real deployment, all nodes would likely use the default port 26257, and so you wouldn’t need to set the port portion of --host.
  1. Run the same SELECT query as before:
    As you can see, node 1 and node 2 behaved identically as SQL gateways.
  2. Exit all SQL shell sessions by issuing the \q command in the terminals where they are running:

Step 3. Run a sample workload

CockroachDB also comes with a number of for simulating client traffic. Let’s run the workload based on CockroachDB’s sample vehicle-sharing application, .
  1. Load the initial dataset:
  2. Run the workload for 5 minutes:

Step 4. Access the DB Console

The CockroachDB gives you insight into the overall health of your cluster as well as the performance of the client workload.
  1. Go to http://localhost:8080.
  2. On the , notice that three nodes are live, with an identical replica count on each node: DB Console This demonstrates CockroachDB’s of data via the Raft consensus protocol.
Capacity metrics can be incorrect when running multiple nodes on a single machine. For more details, see this .
  1. Click to access a variety of time series dashboards, including graphs of SQL queries and service latency over time: DB Console
  2. Use the , , and pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively.

Step 5. Simulate node maintenance

  1. In a new terminal, gracefully shut down a node. This is normally done prior to node maintenance: Get the process IDs of the nodes:
    Gracefully shut down node3, specifying its process ID:
  2. In the DB Console, despite one node being “suspect”, notice the continued SQL traffic: DB Console
  3. Go to the terminal window for node3 and restart it:

Step 6. Scale the cluster

Adding capacity is as simple as starting more nodes with cockroach start.
  1. In new terminal windows, start two more nodes:
    Again, these commands are the same as before but with unique --store, --listen-addr, and --http-addr flags.
  2. In the DB Console Cluster Overview page, confirm that the cluster now has five nodes. DB Console At first, the replica count will be lower for node4 and node5. Very soon, however, you’ll see those numbers even out across all nodes, indicating that data is being to utilize the additional capacity of the new nodes.

Step 7. Stop the cluster

  1. When you’re done with your test cluster, stop the nodes. Get the process IDs of the nodes:
    Gracefully shut down each node by sending the SIGTERM signal to the cockroach process:
    Repeat this command for each node.
For node4 and node5, the shutdown process will take longer (about a minute each) and will eventually force the nodes to stop. Because only two of the five nodes are now running, the cluster has lost quorum and is no longer operational.
  1. To restart the cluster at a later time, run the same cockroach start commands as earlier from the directory containing the nodes’ data stores.
  2. If you do not plan to restart the cluster, you may want to remove the nodes’ data stores:

What’s next?

  • Create a CockroachDB Cloud account where you can for CockroachDB installations
  • for your preferred language
  • Learn more about and the
  • Further explore CockroachDB capabilities like , , , and