Clusters

Viewing clusters

When you create a cluster, from the Clusters view, you will see a list of all your currently provisioned clusters, as well as any clusters that have been deleted within the last four hours. For each cluster, you will see the cluster name, type (shared, public or private), cluster ID, provider, region, type, KurrentDB version, status, and date of creation, as well as a set of icons for performing common actions, and a menu with additional actions.

Details tab

When you select a cluster from the Clusters list, you will see the cluster details page, which includes the cluster Name, ID, provisioning status, and date of creation.

Provider tab

The Provider tab contains details about the cloud provider, region, type (F1, C4, M8, etc), cluster topology (single node, three node multi zone), disk type, size, and any provider specific details.

Network tab

The Network tab contains details about the network configuration, including the Network ID, link to the Network details page, network type (public, private).

For public clusters, the network tab also includes the IP Access List ID and a link to the IP Access List.

Database tab

The Database tab contains details about version of KurrentDB running on the cluster and the health status of the cluster. The Version field shows the major release version of KurrentDB, and Tag shows the specific patch version.

Addresses tab

The Addresses tab contains addresses for accessing the cluster UI, as well as URIs for gRPC and TCP clients.

Issues tab

The Issues tab contains a list of operational issues that have been detected for the cluster, such as if cluster nodes out of sync, high system load or memory usage, low disk space, etc.

You can click on an issue to be taken to the specific issue details page. Additional information on issues can be found in the section.

Notifications tab

The Notifications tab contains details about provisioning errors, or errors encountered while upgrading or resizing a cluster. Additional information on notifications can be found in the section.

Connecting to a cluster

As mentioned above, the Addresses tab of a cluster details section contains the addresses to use for accessing the cluster UI, as well as URIs for gRPC and TCP clients. You will also see a button labeled Connect to <Cluster Name>. When clicked, a modal will appear that will first check if the cluster is reachable.

If it is, you will get a list of options for connecting to the cluster, including a link to the cluster UI, as well as links to the official KurrentDB client libraries for a variety of languages.

If there are issues connecting to the cluster, you will see some diagnostic information indicating some possible reasons why the connection may be failing.

For example, if the cluster is private and no peering has been established

Another example of a public cluster that is not reachable

If you are having trouble connecting to a cluster, see the section of the FAQ for more information, and contact our support team if you need assistance.

DNS names

The format for the DNS name of a cluster follows the pattern <cluster-id>.mesdb.eventstore.cloud.

This name resolves to IP addresses of all the cluster nodes or to the IP address of a single instance, depending on the deployment topology. For public clusters, the name resolves to the public IP addresses of the cluster nodes. For private clusters, the name resolves to the private IP addresses of the cluster nodes.

Each cluster node has its own DNS name, which can be used for accessing individual nodes for node-specific operations like stats collection or scavenging.

Public Clusters: The node DNS names follow the pattern <cluster-id>-<node-id>p.mesdb.eventstore.cloud. The p suffix on the hostname is used for public cluster nodes to indicate that the node is a public node.
Private Clusters: The node DNS names follow the pattern <cluster-id>-<node-id>.mesdb.eventstore.cloud.

Additional DNS names for Public Clusters

Public cluster nodes also have a DNS name that follows the same pattern as private clusters, <cluster-id>-<node-id>.mesdb.eventstore.cloud. This name resolves to the private IP address of the node and is used for internal communication between the nodes. It is not accessible from the public internet.

You can always check the /gossip endpoint from any node to see the list of names clients can use to connect to the individual nodes.

TLS certificates

Kurrent Cloud provisions secure KurrentDB clusters with TLS enabled for HTTP and gRPC using certificates issued by Let's Encrypt. We automatically renew the certificates before they expire and replace the certificates on all cluster nodes. This is all done with zero impact to client connections or cluster availability.

We do not support using third party certificates or offer private certificate authorities.

Changing the default passwords

Every KurrentDB cluster starts with two default users: $admin and $ops. When you create a cluster, those users have the default password changeit. It is strongly recommended that the first thing you do after creating a cluster is to change the passwords for these users, particularly for clusters that are publically accessible. See the section of the KurrentDB documentation for details of how to .

Limitation

While the enterprise version of KurrentDB supports authentications methods such as x509 certificates, LDAP, and OAuth, Kurrent Cloud Managed Clusters only support basic authentication.

Resizing cluster nodes

Clusters can be scaled up or down on-demand to optimize for cost or performance through the Cloud Console and the Kurrent Cloud CLI. When you resize a cluster, the compute instances that make up the cluster are resized. You can resize a cluster to a larger or smaller node size, but you cannot change the topology of the cluster.

Resize operation overview

For multi-node clusters, resizes are done in a rolling fashion, meaning that the cluster is available throughout the resize operation.

Before a resize starts, the cluster health is verified. If there are any issues with the cluster, such as a node is down or is too far out of sync with the cluster, the resize operation will not be allowed to begin. To minimize impact to clients, the two follower nodes are resized one at a time, then before resizing the leader node, the leader is resigned and a leader election is initiated to ensure the final node can be resized without disruption.

Nodes are stopped one at a time, compute instance type is changed, and the node is started again. Once a node has been resized, before proceeding to the next node, the cluster must return to a consistent state before the next node is resized. If any cluster node does not return to a healthy state, the resize operation is aborted and the Cloud team is alerted.

Client connections during resizes

When a cluster node is resized, clients that are connected to that node will be disconnected and automatically reconnect to another node. If the nodePreference connection parameter is set to leader, the client will reconnect to the new leader once one has been elected.

For single-node instances, the resize operation requires downtime because the compute instance must be stopped. For larger databases, once the node is started again, KurrentDB may take several minutes or more to become available.

How to resize a cluster

Upgrading KurrentDB version

The KurrentDB version of a cluster can be changed on-demand to any compatible version that is in support through the Cloud Console and the Kurrent Cloud CLI. You can upgrade to the latest patch release or to a new major version.

Tips

If a cluster's current version of KurrentDB is compatible with an older version, you can use the upgrade process to downgrade to that older version.

Upgrade process overview

When upgrading a three-node cluster, the upgrade is done in a rolling fashion, meaning that the cluster is available throughout the upgrade process.

Before an upgrade is started, the cluster health is verified. If there are any issues with the cluster, such as a node is down or is too far out of sync with the cluster, the upgrade operation will not be allowed to begin. To minimize impact to clients, the two follower nodes are upgraded one at a time, then before upgrading the leader node, the leader is resigned and a leader election is initiated to ensure the final node can be upgraded without disruption.

Nodes are stopped one at a time, compute instance type is changed, and the node is started again. Once a node has been upgraded, before proceeding to the next node, the cluster must return to a consistent state before the next node is upgraded. If any cluster node does not return to a healthy state, the upgrade operation is aborted and the Cloud team is alerted.

Client connections during upgrades

When a cluster node is upgraded, clients that are connected to that node will be disconnected and automatically reconnect to another node. If the nodePreference connection parameter is set to leader, the client will reconnect to the new leader once one has been elected.

Upgrading a single-node instance, on the other hand, does require downtime because the KurrentDB service must be restarted. For larger databases, KurrentDB may take several minutes or more to become available.

Expanding disks

Disks can be expanded on-demand, to accommodate database growth, through the Cloud Console and the Kurrent Cloud CLI

See also the cloud for general guidance.