Postgres-XL is an all-purpose fully ACID open source multi node scalable SQL database solution, based on PostgreSQL.

This operator allows for creating multiple multi container, multi process, distributed databases using Postgres-XL. It is based upon the chart postgres-xl-helm and docker image postgres-xl-docker image.

For a graph description of the connections structure see here.

If using clusters created by the operator, please make sure you read the sections about persistence, backup and restore.

See: Postgres-XL documentation

1. Global Transaction Manager (GTM) - Single pod StatefulSet - provides transaction management for the entire cluster. The data stored in the GTM is part of the database persistence and should be backed up.
2. Coordinator - Multi-pod StatefulSet - Database external connections entry point (i.e. where I connect my client to). These pods provide transparent concurrency and integrity of transactions globally. Applications can choose any Coordinator to connect to, they work together. Any Coordinator provides the same view of the database, with the same data, as if it was one PostgreSQL database. The data stored in the coordinator is part of the DB data and should be backed up.
3. Datanode - Multi-pod StatefulSet - All table data is stored here. A table may be replicated or distributed between datanodes. Since query work is done on the datanodes, the scale and capacity of the db will be determined by the number of datanodes. The data stored in the datanode is part of the DB data and should be backed up.
4. GTM Proxy (optional) - A helper transaction manager. Gtm proxy groups connections and interactions between gtm and other Postgres-XL components to reduce both the number of interactions and the size of messages. Performance tests have shown greater performance with high concurrency workloads as a result.

To connect to the database, please connect to the db main service (which is the coordinator service), example:

kubectl port-forward svc/[release-name]-[cluster-name]-svc

1. A Kubernetes cluster with helm 3 is required.
2. kubectl create namespace <namespace name>
3. Clone this repo
4. cd operations && ./crd-create.sh && cd ../
5. helm3 install pgxlo chart --namespace <namespace name>

1. cd operations && ./postgres-xl-cluster-create-modify.sh
2. Follow instructions

1. A Kubernetes cluster with helm 3 is required.
2. kubectl create namespace <namespace name>
3. Clone this repo
4. Change the following variables in operations/common/vars.sh if required

5. cd operations && ./crd-create.sh && cd ../

6. change chart/values.yaml as required

7. helm3 install pgxlo chart --namespace <namespace name>

1. cd operations.
2. copy one of the examples into a new file in custom-resource-examples/postgres-xl-cluster and edit spec.data as required.
3. ./postgres-xl-cluster-create-modify.sh.
4. follow on screen instructions.

1. cd operations.
2. ./postgres-xl-cluster-delete.sh.
3. Select required cluster name to delete.

1. cd operations.
2. ./postgres-xl-cluster-list.sh.

Clusters are controlled via the CLUSTER_RESOURCE in custom-resources/postgres-xl-cluster.yaml so it can be copied, altered and applied as required.

The custom resource metadata.name is used for cluster names and formatted as RELEASE_NAME-metadata.name.

spec.data accepts the following values:

[STS] = datanodes or coordinators or proxies or gtm

Example: datanodes.count = 32

The implementation in this chart relies on StatefulSets to maintain data persistence between recoveries and restarts. To do so, one must define the pvc argument in the values. If you do not define the pvc argument, the data will be lost on any case of restart/recover/fail.

To define a persistent database you must define all three pvcs for each of the stateful sets, (below are recommended test values, where x is the size of each datanode)

datanodes.pvc:
  resources:
      requests:
        storage: [x]Gi
gtm.pvc:
  resources:
      requests:
        storage: 100Mi
coordinators.pvc:
  resources:
      requests:
        storage: 100Mi

Once these are defined, the DB will recover when any of datanode/coordinator/proxy/gtm are restarted.

See more about persistence in Stateful Sets here and here.

In order to keep to kubernetes principles, this helm chart allows to specify the persistent volume claim class for the workers, coordinators and gtm. This data will persist between restarts. The persistent volumes created will be prefixed by datastore-

Information about StorageClasses can be found here

In order to make a copy of the database one must copy all the data of each and every coordinator and datanode. This means that, when relying on this type of persistence one must:

1. Create a backup solution using a specified persistent storage class, and allow the backend to keep copies of the data between restarts.
2. You cannot decrease the number of executing datanodes as data may be lost. Scaling up requires the redistribution of tables, information about such operations can be found here.
3. Coordinators must not be scaled to less than 1 as one replica is used to rebuild others when scaled up.

Enabling replication will create a replicated copy of the gtm, all datanodes and one coordinator. To fail-over this standby cluster can be promoted to a master cluster by running the following:

1. cd operations && ./postgres-xl-cluster-unlink-standby-promote.sh
2. Follow instructions

More about replication and high availability.

a pod will be considered healthy if it can pass,

1. pg_isready.
2. Connect to the gtm, datanodes (all), and coordinators (all).

1. Periodic sql can be run by the controller to verify cluster is working correctly.

Postgres-XL FAQ

Benchmarks:

1. https://www.2ndquadrant.com/en/blog/postgres-xl-scalability-for-loading-data/
2. https://www.2ndquadrant.com/en/blog/benchmarking-postgres-xl/

The data in the DB will persist only when all datanodes, coordinators and gtm disks are safely restored. This helm chart does not deal with partial restores.

It is free software, released under the MIT licence, and may be redistributed under the terms specified in LICENSE.

1. Setup a kubernetes cluster and make sure you can connect with kubectl as this uses your kube config for authorisation.
2. Install rust.
3. Clone this repo.
4. Change operations/common/vars.sh if required. These are the global values applied to all clusters which are:

This application must be running when performing any operations by running the following:

1. cd operations
2. ./run.sh

• Adding a new parameter if required into a custom resource involves adding it to yaml_structs/$resource_type and mapping it to structs in src/structs.rs
• Templates in the templates directory are created from the context by gtmpl-rust so any other required kubernetes resources can be added to those sub folders but only one YAML document per file.

• openssl for kube-rs, config sha, and cert generation is currently being used for compliance.
• Preferably rusttls can be used in the future for performance gains.
• To run sql inside a pod get the password with export PGPASSWORD="$(cat "${PASSWORD_SECRET_MOUNT_PATH}"/"${PGUSER}")"