Config on PIGSTY

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

You can define different types of instances & clusters.

Identity: Parameters used for describing a PostgreSQL cluster
Primary: Define a single instance cluster.
Replica: Define a basic HA cluster with one primary & one replica.
Offline: Define a dedicated instance for OLAP/ETL/Interactive queries
Sync Standby: Enable synchronous commit to ensure no data loss.
Quorum Commit: Use quorum sync commit for an even higher consistency level.
Standby Cluster: Clone an existing cluster and follow it
Delayed Cluster: Clone an existing cluster for emergency data recovery
Citus Cluster: Define a Citus distributed database cluster
Major Version: Create postgres cluster with different major version

Primary

Let’s start with the simplest case, singleton meta:

Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Pigsty treats Infra & Database as Code. You can describe the infrastructure & database clusters through a declarative interface. All your essential work is to describe your need in the inventory, then materialize it with a simple idempotent playbook.

Inventory

Each pigsty deployment has a corresponding config inventory. It could be stored in a local git-managed file in YAML format or dynamically generated from CMDB or any ansible compatible format. Pigsty uses a monolith YAML config file as the default config inventory, which is pigsty.yml, located in the pigsty home directory.

Infra as Code

Mon, 01 Jan 0001 00:00:00 +0000

Infra as Code, Database as Code, Declarative API & Idempotent Playbooks, GitOPS works like a charm.

Pigsty provides a declarative interface: Describe everything in a config file, and Pigsty operates it to the desired state with idempotent playbooks. It works like Kubernetes CRDs & Operators but for databases and infrastructures on any nodes: bare metal or virtual machines.

Declare Module

Take the default config snippet as an example, which describes a node 10.10.10.10 with modules INFRA, NODE, ETCD, and PGSQL installed.