Last week, while running a workload consisting of 200 different queries, we noticed right away that a CPU imbalance was causing a performance issue. Looking at the first graph, below, you can see right away that one of the three CockroachDB nodes was operating at near 100% CPU. Not ideal.
At the time we installed that cluster, we utilized version 21.1.11 of CockroachDB, which was the most current. Now fast forward in time to November 16 — version 21.2.0 has just been released, with a new feature called Admission Control. From the docs for this new feature, one scenario where Admission Control can help is when
CockroachDB + GeoServer = Horizontally Scalable Spatial Apps
CockroachDB is a relational database that looks very much like PostgreSQL but with the added benefits of horizontal scalability, zero-downtime upgrades, and the ability to survive the loss of a node, an availability zone, or even an entire cloud region. With its recently added spatial capabilities, which are very closely aligned with PostGIS, developers of spatial applications now have an option for when they need a scale out data store. GeoServer is a popular open-source server that allows users to edit and display spatial data. GeoServer is OGC compliant and interoperable with commonly used mapping software such as OpenLayers, Leaflet.js, MapBox, and Google Earth.
If you're curious about how to integrate these two technologies, please read on. The process is very much like adding PostgreSQL as a vector data source, with the exception of the two details I'll elaborate on below. First, you need to log into the CockroachDB instance via a SQL client as a user with "admin" credentials, then make the following change:
Back up CockroachDB to S3 via HTTPS Proxy
When running your production workloads on CockroachDB, you'll want to take regular backups. CockroachDB is frequently deployed into a cloud, such as EC2, GCP, or Azure, and these cloud environments consistently offer a highly durable "blob store". That, coupled with how well CockroachDB's backup/restore works with these blob stores, makes them an excellent choice of backup target. In certain cases, organizations may choose to limit outbound traffic from their workloads running in the cloud, so they may deploy a proxy to manage these HTTP and/or HTTPS requests. Having just configured this myself, I figure sharing it here would make sense.
In my case, I'm running a three-node cluster right on my MacBook Pro, so I'm cheating a little bit in that it's not running in the cloud. Still, for the purposes of this experiment, I think it's okay. I should note that, in that startup procedure, the one shown on the link to the docs, you need to add this step prior to starting each of the three cockroach processes: