cockroach start

On this page

This page explains the cockroach start command, which you use to start a new multi-node cluster or add nodes to an existing cluster.

Synopsis

Start a node to be part of a new multi-node cluster:

$ cockroach start <flags, including --join>

Initialize a new multi-node cluster:

$ cockroach init <flags>

Add a node to an existing cluster:

$ cockroach start <flags, including --join>

View help:

$ cockroach start --help

Flags

The cockroach start command supports the following general-use, networking, security, and logging flags.

Many flags have useful defaults that can be overridden by specifying the flags explicitly. If you specify flags explicitly, however, be sure to do so each time the node is restarted, as they will not be remembered. The one exception is the --join flag, which is stored in a node's data directory. We still recommend specifying the --join flag every time, as this will allow nodes to rejoin the cluster even if their data directory was destroyed.

General

Networking

Security

Locality

The --locality flag accepts arbitrary key-value pairs that describe the location of the node. Locality might include region, country, availability zone, etc. The key-value pairs should be ordered into locality tiers from most inclusive to least inclusive (e.g., region before availability zone as in region=eu,zone=paris), and the keys and order of key-value pairs must be the same on all nodes. It's typically better to include more pairs than fewer.

• CockroachDB spreads the replicas of each piece of data across as diverse a set of localities as possible, with the order determining the priority. Locality can also be used to influence the location of data replicas in various ways using replication zones.

• When there is high latency between nodes (e.g., cross-availability zone deployments), CockroachDB uses locality to move range leases closer to the current workload, reducing network round trips and improving read performance, also known as "follow-the-workload". In a deployment across more than 3 availability zones, however, to ensure that all data benefits from "follow-the-workload", you must increase your replication factor to match the total number of availability zones.

• Locality is also a prerequisite for using the table partitioning and Node Map enterprise features.

Example

# Locality flag for nodes in US East availability zone:
--locality=region=us,zone=us-east

# Locality flag for nodes in US Central availability zone:
--locality=region=us,zone=us-central

# Locality flag for nodes in US West availability zone:
--locality=region=us,zone=us-west

Storage

Storage engine

New in v20.1: The --storage-engine flag is used to choose the storage engine used by the node. Note that this setting applies to all stores on the node, including the temp store.

Supported options:

• default: Checks which engine type was last used for this node's store directory (Pebble or RocksDB), and uses that engine. If more than one store is specified, the previous engine type of the first store is used. If the check fails for any reason, or if the store directory does not exist yet, RocksDB is used.
• rocksdb: Uses the RocksDB storage engine.
• pebble: Uses the experimental Pebble storage engine. Pebble is intended to be bidirectionally compatible with the RocksDB on-disk format. Pebble differs from RocksDB in that it is written in Go and implements a subset of RocksDB's large feature set.

Store

The --store flag supports the following fields. Note that commas are used to separate fields, and so are forbidden in all field values.

Logging

By default, cockroach start writes all messages to log files, and prints nothing to stderr. However, you can control the process's logging behavior with the following flags:

Defaults

cockroach start uses the equivalent values for these logging flags by default:

• --log-dir=<first store dir>/logs
• --logtostderr=NONE

This means, by default, CockroachDB writes all messages to log files, and never prints to stderr.

Standard output

When you run cockroach start, some helpful details are printed to the standard output:

CockroachDB node starting at 
build:               CCL v20.1.17 @ 2021-05-17 00:00:00 (go1.12.6)
webui:               http://localhost:8080
sql:                 postgresql://root@localhost:26257?sslmode=disable
RPC client flags:    cockroach <client cmd> --host=localhost:26257 --insecure
logs:                /Users/<username>/node1/logs
temp dir:            /Users/<username>/node1/cockroach-temp242232154
external I/O path:   /Users/<username>/node1/extern
store[0]:            path=/Users/<username>/node1
status:              initialized new cluster
clusterID:           8a681a16-9623-4fc1-a537-77e9255daafd
nodeID:              1

Known limitations

After a node has initially joined a cluster, it is not possible to add additional stores to the node. Stopping the node and restarting it with additional stores causes the node to not reconnect to the cluster.

To work around this limitation, decommission the node, remove its data directory, and then run cockroach start to join the cluster again as a new node.

Tracking GitHub Issue

Examples

Start a multi-node cluster

To start a multi-node cluster, run the cockroach start command for each node, setting the --join flag to the addresses of the initial nodes.

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.

$ cockroach start \
--certs-dir=certs \
--advertise-addr=<node1 address> \
--join=<node1 address>,<node2 address>,<node3 address> \
--cache=.25 \
--max-sql-memory=.25

$ cockroach start \
--certs-dir=certs \
--advertise-addr=<node2 address> \
--join=<node1 address>,<node2 address>,<node3 address> \
--cache=.25 \
--max-sql-memory=.25

$ cockroach start \
--certs-dir=certs \
--advertise-addr=<node3 address> \
--join=<node1 address>,<node2 address>,<node3 address> \
--cache=.25 \
--max-sql-memory=.25

$ cockroach start \
--insecure \
--advertise-addr=<node1 address> \
--join=<node1 address>,<node2 address>,<node3 address> \
--cache=.25 \
--max-sql-memory=.25

$ cockroach start \
--insecure \
--advertise-addr=<node2 address> \
--join=<node1 address>,<node2 address>,<node3 address> \
--cache=.25 \
--max-sql-memory=.25

$ cockroach start \
--insecure \
--advertise-addr=<node3 address> \
--join=<node1 address>,<node2 address>,<node3 address> \
--cache=.25 \
--max-sql-memory=.25

Then run the cockroach init command against any node to perform a one-time cluster initialization:

$ cockroach init \
--certs-dir=certs \
--host=<address of any node>

$ cockroach init \
--insecure \
--host=<address of any node>

Start a multi-node cluster across private networks

Scenario:

• You have a cluster that spans GCE and AWS.
• The nodes on each cloud can reach each other on private addresses, but the private addresses aren't reachable from the other cloud.

Approach:

1. Start each node on GCE with --locality set to describe its location, --locality-advertise-addr set to advertise its private address to other nodes in on GCE, --advertise-addr set to advertise its public address to nodes on AWS, and --join set to the public addresses of 3-5 of the initial nodes:

   $ cockroach start \
   --certs-dir=certs \
   --locality=cloud=gce \
   --locality-advertise-addr=cloud=gce@<private address of node> \
   --advertise-addr=<public address of node> \
   --join=<public address of node1>,<public address of node2>,<public address of node3> \
   --cache=.25 \
   --max-sql-memory=.25
   

2. Start each node on AWS with --locality set to describe its location, --locality-advertise-addr set to advertise its private address to other nodes on AWS, --advertise-addr set to advertise its public address to nodes on GCE, and --join set to the public addresses of 3-5 of the initial nodes:

   $ cockroach start \
   --certs-dir=certs \
   --locality=cloud=aws \
   --locality-advertise-addr=cloud=aws@<private address of node> \
   --advertise-addr=<public address of node> \
   --join=<public address of node1>,<public address of node2>,<public address of node3> \
   --cache=.25 \
   --max-sql-memory=.25
   

3. Run the cockroach init command against any node to perform a one-time cluster initialization:

   $ cockroach init \
   --certs-dir=certs \
   --host=<address of any node>
   

Add a node to a cluster

To add a node to an existing cluster, run the cockroach start command, setting the --join flag to the same addresses you used when starting the cluster:

$ cockroach start \
--certs-dir=certs \
--advertise-addr=<node4 address> \
--join=<node1 address>,<node2 address>,<node3 address> \
--cache=.25 \
--max-sql-memory=.25

$ cockroach start \
--insecure \
--advertise-addr=<node4 address> \
--join=<node1 address>,<node2 address>,<node3 address> \
--cache=.25 \
--max-sql-memory=.25

Create a table with node locality information

Start a three-node cluster with locality information specified in the cockroach start commands:

$ cockroach start --insecure --port=26257 --http-port=26258 --store=cockroach-data/1 --cache=256MiB --locality=region=eu-west-1,cloud=aws,zone=eu-west-1a

$ cockroach start --insecure --port=26259 --http-port=26260 --store=cockroach-data/2 --cache=256MiB --join=localhost:26257 --locality=region=eu-west-1,cloud=aws,zone=eu-west-1b

$ cockroach start --insecure --port=26261 --http-port=26262 --store=cockroach-data/3 --cache=256MiB --join=localhost:26257 --locality=region=eu-west-1,cloud=aws,zone=eu-west-1c

You can use the crdb_internal.locality_value built-in function to return the current node's locality information from inside a SQL shell. The example below uses the output of crdb_internal.locality_value('zone') as the DEFAULT value to use for the zone column of new rows. Other available locality keys for the running three-node cluster include region and cloud.

$ cockroach sql --insecure

> CREATE TABLE charges (
  zone STRING NOT NULL DEFAULT crdb_internal.locality_value('zone'),
  id INT PRIMARY KEY NOT NULL
);

> INSERT INTO charges (id) VALUES (1);

> SELECT * FROM charges WHERE id = 1;

     zone    | id
+------------+----+
  eu-west-1a |  1
(1 row)

The zone column has the zone of the node on which the row was created.

In a separate terminal window, open a SQL shell to a different node on the cluster:

$ cockroach sql --insecure --port 26259

> INSERT INTO charges (id) VALUES (2);

> SELECT * FROM charges WHERE id = 2;

     zone    | id
+------------+----+
  eu-west-1b |  2
(1 row)

In a separate terminal window, open a SQL shell to the third node:

$ cockroach sql --insecure --port 26261

> INSERT INTO charges (id) VALUES (3);

> SELECT * FROM charges WHERE id = 3;

     zone    | id
+------------+----+
  eu-west-1c |  3
(1 row)

Start a cluster with separate RPC and SQL networks

Separating the network addresses used for intra-cluster RPC traffic and application SQL connections can provide an additional level of protection against security issues as a form of defense in depth. This separation is accomplished with a combination of the --sql-addr flag and firewall rules or other network-level access control (which must be maintained outside of CockroachDB).

For example, suppose you want to use port 26257 for SQL connections and 26258 for intra-cluster traffic. Set up firewall rules so that the CockroachDB nodes can reach each other on port 26258, but other machines cannot. Start the CockroachDB processes as follows:

$ cockroach start --sql-addr=:26257 --listen-addr=:26258 --join=node1:26258,node2:26258,node3:26258 --certs-dir=~/cockroach-certs

Note the use of port 26258 (the value for listen-addr, not sql-addr) in the --join flag. Also, if your environment requires the use of the --advertise-addr flag, you should probably also use the --advertise-sql-addr flag when using a separate SQL address.

Clusters using this configuration with client certificate authentication may also wish to use split client CA certificates.

See also

• Initialize a Cluster
• Manual Deployment
• Orchestrated Deployment
• Local Deployment
• Other Cockroach Commands

Was this helpful?