The client port is the port VoltDB client applications use to communicate with the database cluster nodes. By default, VoltDB uses port 21212 as the client port. You can change the client port. However, all client applications must then use the specified port when creating connections to the cluster nodes.

To specify a different client port in the --network YAML file, use the network.client.* properties. On the command line, use the --client flag when starting the VoltDB database. For example:

YAML:

network:
  client: 
    port: 12345

Command Line:

$ voltdb start --dir=~/mydb --client=12345

If you change the default client port, all client applications must also connect to the new port. The client interfaces for Java and C++ accept an additional, optional argument to the createConnection method for this purpose. The following examples demonstrate how to connect to an alternate port using the Java and C++ client interfaces.

Java

org.voltdb.client.Client voltclient;
voltclient = ClientFactory.createClient();
voltclient.createConnection("myserver",12345);  

C++

boost::shared_ptr<voltdb::Client> client = voltdb::Client::create();
client->createConnection("myserver", 12345);

The admin port is similar to the client port, it accepts and processes requests from applications. However, the admin port has the special feature that it continues to accept write requests when the database enters admin, or read-only, mode.

By default, VoltDB uses port 21211 on the default external network interface as the admin port. To specify a different admin port in the --network YAML file, use the network.admin.* properties. On the command line, use the --admin flag when starting the VoltDB database. For example:

YAML:

network:
  admin: 
    port: 2222

Command Line:

$ voltdb start --dir=~/mydb --admin=2222

A VoltDB cluster uses ports to communicate among the cluster nodes. This port is internal to VoltDB and should not be used by other applications. By default, the internal server port is port 3021 for all nodes in the cluster^[1]. To specify a different internal port in the --network YAML file, use the network.internal.* properties. On the command line, use the --internal flag when starting the VoltDB database. For example:

YAML:

network:
  internal: 
    port: 4000

Command Line:

$ voltdb start --dir=~/mydb --internal=4000

When metrics are enabled, the database uses the metrics port to return statistical data about the state of the database to calling applications, such as Prometheus. By default, the metrics port is 11781. To specify a different metrics port in the --network YAML file, use the network.metrics.* properties. On the command line, use the --metrics flag when starting the VoltDB database. For example:

YAML:

network:
  metrics: 
    port: 9090

Command Line:

$ voltdb start --dir=~/mydb --metrics=9090

During database replication, producer databases use a dedicated port to share data to their consumers. By default, the replication port is port 5555. To specify a different replication port in the --network YAML file, use the network.replication.* properties. On the command line, use the --replication flag when starting the VoltDB database. For example:

YAML:

network:
  replication: 
    port: 6666

Command Line:

$ voltdb start --dir=~/mydb --replication=6666

Note that if you set the replication port on the producer to something other than the default, you must notify the consumers of this change. The replica or other XDCR clusters must specify the port along with the network address or hostname in the deployment.dr.connection.source property when configuring the DR relationship. For example, if the server nyc2 has changed its replication port to 3333, another cluster in the XDCR relationship might have the following configuration:

deployment:
  dr:
    id: 1
    role: xdcr
    connection:
      source: nyc1,nyc2:3333

Finally, in some cloud environments, such as Kubernetes, remote clusters may not be able to access the producer cluster by its internal network interface. Consumers can specify the location of the producer in the DR configuration using a remapped IP address. But once they initialize contact with the producer, the producer sends a list of IP addresses to use for ongoing replication. By default, these are the internal addresses the producer cluster knows about.

You can tell the producer to advertise a different interface (and port) for this second phase by specifying the network.drpublic.* YAML properties or the --drpublic argument in the voltdb start command. If you do not specify a port, the internal replication port is used. For example:

YAML:

network:
  drpublic: 
    address: some.external.addr

Command Line:

$ voltdb start --drpublic=some.external.addr

When topics are enabled, the database uses the topics port to send and receive data to consumers and producers. By default, the topics port is port 9092. To specify a different topics port in the --network YAML file, use the network.topics.* properties. On the command line, use the --topics flag when starting the VoltDB database. For example:

YAML:

network:
  topics: 
    port: 9900

Command Line:

$ voltdb start --dir=~/mydb --topicsport=9900

In cases where the server's external interface is not directly accessible by outside services and you set up the necessary port forwarding, you can specify an alternative public interface for those services using either the network.topicspublic.* YAML properties or the --topicspublic flag. You can identify an alternative port for the server as well. For example:

YAML:

network:
  topicspublic: 
    address: myexternalserver
    port:9092

Command Line:

$ voltdb start --dir=~/mydb --topicspublic=myexternalserver:9092

VoltDB uses a version of Apache Zookeeper to communicate among supplementary functions that require coordination but are not directly tied to database transactions. Zookeeper provides reliable synchronization for functions such as command logging without interfering with the database's own internal communications.

VoltDB uses a network port bound to the local interface (127.0.0.1) to interact with Zookeeper. By default, 7181 is assigned as the Zookeeper port for VoltDB. To specify a different zookeeper port in the --network YAML file, use the network.zookeeper.port property. On the command line, use the --zookeeper flag when starting the VoltDB database.

It is also possible to specify a different network interface, like with other ports. However, accepting the default for the zookeeper network interface is recommended where possible. For example:

YAML:

network:
  zookeeper: 
    port: 2288

Command Line:

$ voltdb start --dir=~/mydb --zookeeper=2288

VoltDB lets you enable Transport Layer Security (TLS) — the recommended upgrade from Secure Socket Layer (SSL) encryption — for all of its externally-facing interfaces: the web port, client port, admin port, and replication (DR) port. When you enable TLS, you automatically enable encryption for the web port. You can then optionally enable encryption for the external ports (client and admin) and/or the replication port.

To enable TLS encryption you need an appropriate certificate. How you configure TLS depends on whether you create a local certificate or receive one from an authorized certificate provider, such as VeriSign, GeoTrust and others. If you use a commercial certificate, you only need to identify the certificate as the key store. If you create your own, you must specify both the key store and the trust store. (See the section on using TLS/SSL for security in the Using VoltDB manual for an example of creating your own certificate.)

You enable TLS encryption in the configuration using deployment.ssl and its subproperties. You specify the location and password for the key store and, for locally generated certificates, the trust store in separate properties like so:

deployment:
  ssl:
    keystore:
      path: /etc/mydb/keystore
      password: twiddledee
    truststore:
      path: /etc/mydb/truststore
      password: twiddledum

You can explicitly enable or disable TLS encryption by including the enable property. (For example, if you want to include the key store and trust store in the configuration but not turn on TLS during testing, you can set deployment.ssl.enabled to "false".) You can specify that the client and admin API ports are TLS encrypted by setting the deployment.ssl.external property to true. Similarly, you can enable TLS encryption for the DR port by setting the deployment.ssl.dr property to "true". For example, the following configuration sample, explicitly enables TLS for all externally-facing ports:

deployment:
  ssl:
    enabled: true
    external: true
    dr: true
    keystore:
      path: /etc/mydb/keystore
      password: twiddledee
    truststore:
      path: /etc/mydb/truststore
      password: twiddledum