Contents
An HA installation requires two components:
Two or more clusters with matching Kinetica installations registered with KAgent
Note
If KAgent is not installed, consult Upgrading Kinetica (No KAgent - On Premise) for more information.
Two nodes (across the clusters) have RabbitMQ installed
The KAgent UI
Log into the KAgent service with a web browser:
http://<kagent-host>:8081
On the Clusters page, click Rings.
On the Rings page, next to the ring containing your clusters, click Enable HA.
Select a mode:
Click Enable. The High Availability package will be installed on each cluster and automatically configured.
Click Close. The current HA mode will be listed on the Rings page.
Tip
Click Enable HA at any point to change the HA mode; the database will automatically be reconfigured after enabling a different mode.
Any client API connection made to an HA cluster ring should be configured to fail over from one cluster to another. For more information on the HA failover modes, consult Failover Modes. The enabled failover mode (active/active or active/passive) is governed by whether a primary URL is specified or implied as follows:
Important
The database will auto-discover clusters in HA rings associated with the provided URL(s) and append each cluster's head node URL to the list of URLs available for failover.
To instantiate a Kinetica connection object with failover in C++, pass a comma-delimited list of head node URLs to the constructor:
gpudb::GPUdb gpudb("http://172.1.2.3:9191,http://172.1.2.4:9191,http://172.1.2.5:9191");
In this case, a cluster will be chosen randomly from the given list for the initial connection. Subsequent requests through the instantiated connection object will go to the same cluster.
Important
If you provide a single URL to the gpudb
class object, the failover mode
will instead be Active/Passive and the URL will be treated as the primary
URL.
To designate a cluster from the list to always attempt to go to first, specify a primary URL:
gpudb::GPUdb::Options options = gpudb::GPUdb::Options().setPrimaryUrl("http://172.1.2.4:9191");
gpudb::GPUdb gpudb("http://172.1.2.3:9191,http://172.1.2.4:9191,http://172.1.2.5:9191", options);
In either case, if the current cluster has a failure, the connector will randomly choose a failover cluster from the list to send further requests. If no operational clusters are found, an error will be returned.
To instantiate a Kinetica connection object with failover in Java, pass a comma-delimited list of head node URLs to the constructor:
GPUdb gpudb = new GPUdb("http://172.1.2.3:9191,http://172.1.2.4:9191,http://172.1.2.5:9191");
In this case, a cluster will be chosen randomly from the given list for the initial connection. Subsequent requests through the instantiated connection object will go to the same cluster.
Important
If you provide a single URL to the gpudb
class object, the failover mode
will instead be Active/Passive and the URL will be treated as the primary
URL.
To designate a cluster from the list to always attempt to go to first, specify a primary URL:
GPUdb.Options options = new GPUdb.Options().setPrimaryUrl("http://172.1.2.4:9191");
GPUdb gpudb = new GPUdb("http://172.1.2.3:9191,http://172.1.2.4:9191,http://172.1.2.5:9191", options);
In either case, if the current cluster has a failure, the connector will randomly choose a failover cluster from the list to send further requests. If no operational clusters are found, an error will be returned.
To instantiate a Kinetica connection object with failover in Python, pass a comma-delimited list of head node URLs to the constructor:
kinetica = gpudb.GPUdb(host=['http://172.1.2.3:9191','http://172.1.2.4:9191','http://172.1.2.5:9191'])
In this case, a cluster will be chosen randomly from the given list for the initial connection. Subsequent requests through the instantiated connection object will go to the same cluster.
To designate a cluster from the list to always attempt to go to first, specify a primary host:
kinetica = gpudb.GPUdb(host=['http://172.1.2.3:9191','http://172.1.2.4:9191','http://172.1.2.5:9191'], primary_host='http://172.1.2.3:9191')
In either case, if the current cluster has a failure, the connector will randomly choose a failover cluster from the list to send further requests. If no operational clusters are found, an error will be returned.
Any Kinetica connectors used to interface with an HA cluster ring should also be configured to fail over from one cluster to another.
See Failover Connections for the ODBC/JDBC failover configuration.
Once HA has been configured, several commands are available to aid in the management of the cluster. Run the following service with one of the commands from the table below:
service gpudb-ha <command>
Command | Description |
---|---|
all-start |
Starts the gpudb , gpudb-ha , and gpudb-mq services. |
all-status |
Displays the status of the gpudb , gpudb-ha , and gpudb-mq services. |
all-stop |
Stops the gpudb , gpudb-ha , and gpudb-mq services. |
backup-restart |
Restarts the backup processor service. |
backup-start |
Starts the backup processor service. |
backup-status |
Displays the status of the backup processor service. |
backup-stop |
Stops the backup processor service. |
gpudb-start |
Starts the gpudb and gpudb-ha services. |
gpudb-status |
Displays the status of the gpudb and gpudb-ha services. |
gpudb-stop |
Stops the gpudb and gpudb-ha services. |
ha-restart |
Restarts the gpudb-ha service. |
ha-start |
Starts the gpudb-ha service. |
ha-status |
Displays the status of the gpudb-ha service. |
ha-stop |
Stops the gpudb-ha service. |
mq-restart |
Restarts the gpudb-mq service. |
mq-status |
Displays the status of the gpudb-mq service. |
mq-start |
Starts the gpudb-mq service. |
mq-stop |
Stops the gpudb-mq service. |
restart |
Restarts the gpudb-ha and backup processor services. |
start |
Starts the gpudb-ha and backup processor services. |
status |
Displays the status of the gpudb-ha and backup processor services. |
stop |
Stops the gpudb-ha and backup processor services. |