Discover in this article and video how BDR can be easily and quickly deployed on Kubernetes thanks to our Cloud Native BDR Operator.
BDR is a full mesh replication solution for PostgreSQL databases developed by 2ndQuadrant that provides both high availability and multi-master capabilities. It is now available for Kubernetes on Public and Private environments, thanks to 2ndQuadrant’s Cloud Native BDR Operator and our experience as Kubernetes Certified Service Provider (KCSP).
The BDR operator implements the WriteAnywhere architecture, made up by a BDR group having a minimum of 3 BDR nodes, preferably spread over multiple Kubernetes nodes. WriteAnywhere supports two ways of accessing a BDR database:
- Single master (or more properly “Lead master”), for high availability purposes
- Multi-master, for read/write scalability – if workloads are compatible with this access pattern
The operator makes available to application developers two Kubernetes services, pointing respectively to the first node of the cluster (lead master) and to any (multi-master), and continuously coordinates itself with the control plane to keep them updated, especially after disruptions (node failure) or planned events (scale up, scale down, or drain of a node).
As such, BDR integrates perfectly with Cloud Native applications that reside in the same Kubernetes cluster.
While in another article I will go through BDR’s unique fast switchover capability – after a failure of a node the operator switches applications to another node in < 1 second -, in this post we will showcase the deployment of BDR in a Kubernetes cluster and give you a quick taste of multi-master replication with both DDL and DML statements.
Using a local cluster in Kind (Kubernetes in Docker) for evaluation, the video guides you through the operator installation process via 2ndQuadrant’s customer portal and the subsequent deployment of a BDR group. It is important to note that a BDR group can be deployed through a YAML file – following the declarative configuration principle:
kubectl apply -f bdr-db.yaml
The manifest contains configuration of the BDR group, including the number of desired masters (3 is the minimum). Here is an excerpt:
# Example of BDR group using emptyDir volumes apiVersion: bdr.k8s.2ndq.io/v1alpha1 kind: BdrGroup metadata: name: bdr-database-emptydir spec: # BDR group configuration bdr: group: bdr-database database: app owner: app masters: 3 # PostgreSQL server configuration postgresql: # Example of configuration parameters for PostgreSQL parameters: ... # Example of host based authentication directives pg_hba: ... # Enable OmniDB enableOmniDB: true
The video continues by connecting to the first node of the group and then creating in the new database a table with a “CREATE TABLE” DDL statement.
The table, thanks to BDR’s native replication of DDL operations, is created almost instantaneously in the other nodes.
Then two records are inserted in the same table on the first server. These records, as expected in a real multi-master scenario, are replicated to the other nodes.
Of course, this is just an example of the potential of BDR’s multi-master capability. If you want to know more about BDR, I suggest that you look at some of the available webinars, starting with the latest overview from Simon Riggs recorded in January 2020.
If you are interested in knowing more about Cloud Native BDR and trying it out, please enquire about the “Cloud Native BDR Quickstart”. It is a great way to evaluate BDR for your applications in the Cloud.
Enjoy the video and … see you with the next blog article about Cloud Native BDR!