Even the best databases out there can encounter issues. It can be an OOM, a genuine bug, or simply the host machine being shut down. Regardless, while starting GraphDB again after such an event is very easy, it’s much better if this isn’t a manual operation. Deploying GraphDB directly from the command line is not the best option.
It is always recommended to run high-availability environments with the GraphDB cluster. However, even in these cases, the specifics of deploying GraphDB are an open question. Here, we would describe Ontotext’s three preferred methods for running GraphDB, in order of resilience.
Kubernetes is a powerful resource orchestration platform, which allows you to easily deploy, monitor and update a system. Naturally, automatic restarts on failure come out of the box. It’s popular for CI/CD and has the benefits of being open-source and having a huge ecosystem. This is complemented by Helm, a templating engine, which allows you to quickly make replicable Kubernetes deployment.
Ontotext offers an open-source Helm chart that allows your Kubernetes-enabled cluster to be set up quickly. The main configurations that you will need to do are related to the particular Kubernetes service provider and storage medium. Even if you don’t have Helm on your target environment, you can run Helm locally and render the chart, providing you with the necessary Kubernetes configurations.
The downside of Kubernetes is that you need time investment to understand the technology and set up your cluster. Even with services like AKS, there is a barrier to entry.
As Helm and Kubernetes are rather complicated, you should refer to our graphdb-helm project for a better understanding.
Peeling a layer from the stack, you can use GraphDB directly with Docker and Compose. Docker is the most popular OS virtualization layer. GraphDB ships with an official Docker image. Docker gives you the benefit of a repeatable and consistent image from which to run your application.
There are two ways to make sure your container restarts if there is a failure of any sort. For raw Docker, this is controlled by the –restart flag. This would mean that the container is started when it fails, or if the Docker engine itself restarts.
docker run -d –restart unless-stopped ontotext/graphdb
Pure Docker gives you a way to launch individual containers. For starting a number of containers in orchestration, you are better off using Compose. Its syntax is also much more convenient for providing configurations to the services you run.
version: '3.6' services: graphdb: image: ontotext/graphdb:latest restart: always ports: - "7200:7200" environment: GDB_JAVA_OPTS: "-Xmx6g -Xms1G"
Of course, if you can’t install Docker on your machine, you will have to fall back to something else. All major operating systems provide a way to run a process as a service. This makes the system more fragile than Docker, but requires no additional software at all. Those systems are usually not interoperable, so you would need a specific setup for your own server. One of the more popular ways to do this is Linux and systemd.
[Unit] Description="Service Description" #[example] - Graphdb worker After=network.target [Service] Group="your user name" #graphdb User="your user group" #graphdb Restart=on-failure RestartSec=5s TimeoutStopSec=600 Environment=JAVA_HOME=<your java home> #/usr/lib/jvm/java-11-oracle #Example GDB_JAVA_OPTS Environment="GDB_JAVA_OPTS=-XX:+TieredCompilation \ -Xmx31G \ -Xms31G" # Tomcat process exits with status 143 when kill is successful SuccessExitStatus=143 #Start ExecStart="<path to graphdb>"# /opt/graphdb/dist/bin/graphdb,example optoions: -Dgraphdb.home=/opt/graphdb/instances/worker -Dgraphdb.connectors.chains.collections=true [Install] WantedBy=multi-user.target
Regardless of which way you use to run GraphDB, we will be happy to help you at every part of your journey.