5. PostgreSQL – Multi-Release, Multi-Cluster#

_images/240px-Postgresql_elephant.svg.png

In diesem kleinen Projekt soll ein flexibler „PostgreSQL Datenbankserver“ eingerichtet werden.

Datenbankserver meint an dieser Stelle, dass der (Linux-)Rechner (oder VM) nur einen wesentlichen Zweck hat: er soll eine oder mehrere PostgreSQL Cluster [1] beherbergen.

Als Beispiel stelle man sich ein Produkt vor, das eine PostgreSQL-Datenbank braucht und das weiter entwickelt wird und regelmäßig von den neuen Features und Releases des Datenbanksystems profitieren soll.

Folgende Szene soll unser Datenbankserver dabei abbilden:

2 Cluster für die aktuelle Produktions-DB mit PostgreSQL Release 10.

2 Cluster für nue Test-DB mit PostgreSQL Release 11.

4 Cluster für die aktuelle Entwicklungs-DB mit PostgreSQL Release 12.

2 Cluster für die Future-Feature-DB mit PostgreSQL Release 13.

Wir könnten das Problem via Docker, Kubernetes oder auch VMs via KVM angehen. Das führt aber sicher zu sehr viel größeren Lösungen, als z.B. für die Entwicklung ein paar Cluster einzurichten.

Für die Lösung der Aufgabe soll ergo eine Standard-Linux-Distribution eingesetzt werden (hier: Debian 10 und Suse Leap 15.2) und ein paar Python-Skripts.

5.1. What is PostgreSQL?#

Diese Frage wird in [PG_About] wie folgt beantwortet:

PostgreSQL is a powerful, open source object-relational database system that uses and extends the SQL language combined with many features that safely store and scale the most complicated data workloads. The origins of PostgreSQL date back to 1986 as part of the POSTGRES project at the University of California at Berkeley and has more than 30 years of active development on the core platform.

PostgreSQL has earned a strong reputation for its proven architecture, reliability, data integrity, robust feature set, extensibility, and the dedication of the open source community behind the software to consistently deliver performant and innovative solutions. PostgreSQL runs on all major operating systems, has been ACID-compliant since 2001, and has powerful add-ons such as the popular PostGIS geospatial database extender. It is no surprise that PostgreSQL has become the open source relational database of choice for many people and organisations.

Dem ist nichts hinzuzufügen.

5.2. Versionen#

Ein Ziel ist die parallele Installation von Clustern verschiedener Releases. Bevor ein Release, eine Version definiert werden kann, muss bekannt sein, welche Versionen aktuell existieren (Januar 2021).

Es sind dies die folgenden:

Version	Current minor	Supported	First Release	Final Release
16	16.0	Yes	September 14, 2023	November 9, 2028
15	15.4	Yes	October 13, 2022	November 11, 2027
14	14.9	Yes	September 30, 2021	November 12, 2026
13	13.12	Yes	September 24, 2020	November 13, 2025
12	12.16	Yes	October 3, 2019	November 14, 2024
11	11.21	Yes	October 18, 2018	November 9, 2023

5.3. Software Installation#

In der Regel stellen die großen Linux-Distributionen genau eine Version von Hause aus zur Verfügung und zwar genau die, die mit der Linux-Distribution aktuell ist.

Warnung

Insbesondere für RedHat 7 Installation kann die PostgreSQL-Version sehr alt sein.

Glücklicherweise gibt es für jede Distribution dezidierte Repositories, die es ermöglichen, alle aktuellen PostgreSQL-Versionen zu installieren.

5.3.1. Debian#

Unter Debian (Buster) müssen folgende Aktionen durchgeführt werden, um an alle PostgreSQL-Versionen zu kommen

# Erstelle eine neue Repository Konfiguration:
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

# Importiere den "signing key":
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

# Update der Paketliste
sudo apt-get update

# Installiere die Releases, z.B.
sudo apt-get -y install postgresql-12
sudo apt-get -y install postgresql-13
sudo apt-get -y install postgresql-14
sudo apt-get -y install postgresql-15

Debian unterscheidet sich in Bezug auf PostgreSQL gegenüber den anderen Distributionen in einigen Punkten:

Mit der Software-Installation wird auch schon ein „default-Cluster“ (hier mit Namen „main“) erstellt.

Die Server sind sptestens nach dem nächsten Reboot aktiv, so dass man sich gegen den/die Server verbinden kann. Es werden die default Ports 5432, 5433, … benutzt.

Das CLuster-Verzeichnis und die Konfiguration für das Cluster sind Debian-typisch getrennt.

5.3.2. Suse Leap#

Für Suse SLES (12, 15) steht je Version ein Repository-Eintrag zur Verfügung [2] .

Für unsere Tests wird Suse Leap 15.2 eingesetzt und die Installation der verschiedenen PostgreSQL-Softwareversionen ist wie folgt möglich:

Repository

sudo zypper addrepo https://download.opensuse.org/repositories/server:/database:/postgresql/openSUSE_Leap_15.2/server:database:postgresql.repo

Refresh
```
sudo zypper refresh
```

Server-Versionen installieren

sudo zypper install postgresql10-server

sudo zypper install postgresql11-server

sudo zypper install postgresql12-server

sudo zypper install postgresql13-server

5.4. Kanonische Cluster#

Bemerkung

Das Vorgehen, die Strukturen, Verzeichnisse und Skripts sind unabhängig von der Linux-Distribution auch wenn die Beispiele primär in einer Debian-Buster VM getestet wurden.

Es ist hier das Ziel unabhängig von der Distribution die PostgreSQL DB-Cluster immer auf die selbe Art einzurichten und diese auch immer an den selben Stellen wiederzufinden:

Alle Cluster liegen unter dem Verzeichnis /db/postgres.

Für jede Version gibt es unterhalb von /db/postgres ein Unterverzeichnis mit der Versions-Nummer, z.B. 10, 11, … . Alle Cluster einer Version liegen unterhalb des Versionsverzeichnisses.

Die Basis-Cluster-Kongiguration liegt unter /db/postgres/config.

Python-Scripte die aus der Basis-Cluster-Kongiguration die Cluster erstellen liegen unter /db/postgres/tpg.

Damit ist die Struktur im Wesentlichen festgelegt

postgres@ddbref:~$ tree -d -L 2 /db
/db
└── postgres
    ├── 10
    ├── 11
    ├── 12
    ├── 13
    ├── 14
    ├── 15
    ├── bin
    ├── config
    └── tpg

5.4.1. DB-Haupt-Verzeichnis#

Um das Haupt-Verzeichnis bequem einrichten zu können, wollen wir uns an dieser Stelle Ansible zu Hilfe nehmen:

Inverntory Datei

In einer Inventory-Datei legen wir fest, bei welche Servern (hier IP-Adressen) es sich um DB-Server handelt:
```
[postgres]
192.168.122.112
```

Playbook

In dem sogenannten Playbook werden diese (dieser) Server eingechtet, z.B. kann das wie folgt aussehen:

-   hosts: postgres
    vars:
      pg_root: /db/postgres

    become: True
    become_user: root
    become_method: sudo

    tasks:

    - name: install postgresql
      apt:
        pkg: ['postgresql-10', 'postgresql-11', 'postgresql-12', 'postgresql-13', ]

    - name: install python3 pip
      apt:
        pkg: ['python3-pip',  ]

    - name: install python modules
      shell: "/usr/bin/pip3 install distro pydantic psycopg2_binary"

    - name: Ensure group "postgres" exists
      group:
        name: postgres
        state: present

    - name: Creating home directory
      file:
        path: /db/postgres
        state: directory

    - name: "Add the user 'postgres'to primary group of 'postgres' and set home dir"
      user:
        name: postgres
        group: postgres
        state: present
        shell: /bin/bash
        system: yes
        home: /db/postgres

    - name: Database root directory rights
      file:
        path: /db/postgres
        state: directory
        owner: postgres
        group: postgres
        mode: 0700

    - name: Creates release directories
      file:
        path: "{{ item }}"
        state: directory
        owner: postgres
        group: postgres
        mode: 0700
      with_items:
      - "{{ pg_root }}/10"
      - "{{ pg_root }}/11"
      - "{{ pg_root }}/12"
      - "{{ pg_root }}/13"


    - name: Creates config and bin directories
      file:
        path: "{{ item }}"
        state: directory
        owner: postgres
        group: postgres
        mode: 0755
      with_items:
      - "{{ pg_root }}/bin"
      - "{{ pg_root }}/tpg"
      - "{{ pg_root }}/config"
      - "{{ pg_root }}/config/new"
      - "{{ pg_root }}/config/test"
      - "{{ pg_root }}/config/production"
      - "{{ pg_root }}/config/explore"

Offensichtlich erledigt das Playbook ein paar Dinge mehr, als die Hauptverzeichnisse anzulegen:

Zeile 13:

Die geplanten PostgreSQL Versionen werden installiert.
Zeile 15-21:

Die Sripte, die später benötigt werden, setzen python3 voraus und einige Module.
Zeile 27:

Das besagter Haupt-Verzeichnis wird angelegt: /db/postgres.
Zeile 32:

Der User postgres bekommt sein neues Home-Verzeichnis unter /db/postgres.
Zeile 49 ff.:

Für jede Version wird ein eigenens Basis-Verzeichnis für alle Cluster dieser Version angelegt.
Zeile 63 ff.:

Die Verzeichnisse für Scripte und Cluster-Konfiguration werden erstellt.

5.4.2. Cluster Software#

Die Scripte, mit denen die Cluster verwaltet werden können, werden in /db/postgres/tpg installiert, z.B. mit einer Erweiterung des Ansible- Playbooks (sofern das tar-file tpg.tgz unter ./templates selbige enthält):

- name: "Upzipping scripts"
  unarchive:
    src: "templates/tpg.tgz"
    dest: "{{ pg_root }}/tpg"

Mit dieser Erweiterung richtet das Playbook folgende tpg-Software-Kollektion ein

postgres@ddbref:/db/postgres
$ ll tpg
total 16
-rwxr-xr-- 1 postgres postgres  571 Feb  3 18:30 tpg_admin
-rwxr-xr-- 1 postgres postgres 1448 Jan 31 14:57 tpg_cluster
-rwxr-xr-- 1 postgres postgres 2902 Jan 31 14:57 tpg_db
drwxr-xr-x 7 postgres postgres 4096 Feb  4 09:46 tpglib

5.5. Cluster by Example#

Es sind jetzt alle Voraussetzungen zum Anlegen beliebiger PostgreSQL-Server-Cluster vorhanden:

PostgreSQL Software in den Versionen 10 .. 13

Das Postgres-Hauptverzeichniss ist angelegt

Die tpg-Software-Kollektion ist installiert.

Im folgenden werden einige Beispiele dokumentieren, die letztendlich den eingangs geschilderten Anwendungsfall realisieren (siehe Cluster-Beispiel).

5.6. Minimal-Cluster#

Die Cluster werden prinzipiell in einer „DSL“ (domain specfic language) definiert. Um den Ansatz zu einfach wie möglich zu machen, wurde „JSON“ als Beschreibungssprache gewählt.

5.6.1. Definition#

Die erste Definition sieht deshalb wie folgt aus:

{
  "cluster_name": "cl_prod01",
  "encoding": "UTF8",
  "locale": "de_DE.UTF8",
  "pg_release": "10",
  "port": "5541",
  "comment": "cl_prod01"
}

Die Einträge haben folgende Bedeutung:

Zeile 3: der Name des Clusters

Jedes Cluster hat einen Namen, welcher so gewählt werden muss, dass er als Dateiname problemlos verwendet werden kann.

Dieser Name wird beim Anlegen des Clusters teil des Pfades unter dem das Cluster gespeichert wird.

Zeile 4 und 5: encoding, locale

Das sind originäre PostgreSQL-Parameter, die in der Konfiguration gesetzt werden können und/oder besser schon beim Anlegen des Clusters definiert werden.

Zeile 6: pg_release

Dieser Parameter legt zum einen fest, mit welcher PostgreSQL-Version das Cluster anglegt wird, und zum anderen unter welchem Release-Verzeichnis im DB-Hauptverzeichnis das Cluster abgelegt wird.

Zeile 7: Server Port

Für jeden Client das A-und-O: auf welchem Port ist der Server dieses Clusters errichbar.

Warnung

Natürlich muss für jedes Cluster ein eigner Port definiert sein.

Zeile 8: Kommentar

Das ist eine Möglichkeit den Zweck des Clusters zu beschreiben.

5.6.2. Test#

Was schief gehen kann, geht schief.

Bevor mit der neuen Definition ein Cluster angelegt wird, kann es getestet werden. Dabe werden zumindest einige grobe Schnitzer gefunden.

Warnung

Cluster-Operationen ist Chef-Sache, ergo von root zu erledigen.

So gehts:

Schreibe die Cluster-Konfiguration in das Testverzeichnis

postgres@ddbref:/db/postgres/config
$ ls -1 test/10_cl_prod01.json
test/10_cl_prod01.json

Führe den Test aus

Aufruf

teg@ddbref:~$ sudo python3 /db/postgres/tpg/tpg_cluster -t -c 10_cl_prod01.json
  ddbref - logging is enabled => /var/log/postgresql/tpg_cluster_2021-02-04.log
pg_release='10' cluster_name='cl_prod01' port=5541 encoding='UTF8' locale='de_DE.UTF8'

Congratulation. This is a valid configuration!

Es wurde keine Offensichtlichen Fehler festgestellt.

Bemerkung

Der Parameter „-t“ veranlasst das Scrupt tpg_cluster im Verzeichnis /db/postgres/config/test die mit „-c“ angegebene Dateu zu suchen.

Ein fehlerhafter Aufruf als Beispiel

teg@ddbref:~$ sudo python3 /db/postgres/tpg/tpg_cluster -t -c 10_cl_prod01.jsonx
  ddbref - logging is enabled => /var/log/postgresql/tpg_cluster_2021-02-04.log
Traceback (most recent call last):
  File "/db/postgres/tpg/tpg_cluster", line 59, in <module>
    main()
  File "/db/postgres/tpg/tpg_cluster", line 53, in main
    pg_cluster_test(ARGS.cfgname)
  File "/db/postgres/tpg/tpglib/pgif.py", line 30, in pg_cluster_test
    test_obj = test_class_hash[dname](cfg_name=cfg_file_name, cfg_sub_dir="test")
  File "/db/postgres/tpg/tpglib/pgcluster.py", line 180, in __init__
    with open(cfg_name, "rt") as ifh:
FileNotFoundError: [Errno 2] No such file or directory: '/db/postgres/config/test/10_cl_prod01.jsonx

5.6.3. Anlegen#

Die Konfiguration ist von „test“ nach „new“ zu übernehmen

postgres@ddbref:/db/postgres/config
$ cp test/10_cl_prod01.json ./new

postgres@ddbref:/db/postgres/config
$ ls -1 new/10_cl_prod01.json
new/10_cl_prod01.json

Erstelle Cluster als root

teg@ddbref:~$ sudo python3 /db/postgres/tpg/tpg_cluster -n -c 10_cl_prod01.json
  ddbref - logging is enabled => /var/log/postgresql/tpg_cluster_2021-02-04.log

5.6.4. Ergebnis#

Was ist nun das Ergebnis dieses kleine Script-Aufrufs?

Cluster-Server

Es wurde eine komplete Server-Installation durchgeführt und zwar im DB-Hauptverzeichnis, im entsprechenden Release-Unterverzeichnis:
```
/db/postgres/10/cl_prod01
```
Allerdings wird an dieser Stelle noch ein Unterverzeichnis pg eingefügt
```
/db/postgres/10/cl_prod01/pg
```
Damit ist es leicht möglich den Cluster-Hauptpfad auf ein eigenens Device zu mounten, bevor die Cluster-Installation erfolgt.

Cluster-Pfad

Der komplete Cluster-Pfad hat folgende Struktur

/db/postgres/10/cl_prod01/pg
├── _archiv
├── base
├── global
├── log
├── pg_commit_ts
├── pg_dynshmem
├── pg_logical
├── pg_multixact
├── pg_notify
├── pg_replslot
├── pg_serial
├── pg_snapshots
├── pg_stat
├── pg_stat_tmp
├── pg_subtrans
├── pg_tblspc
├── pg_twophase
├── pg_wal
├── pg_xact
├── tpg_export
└── tpg_ts

Cluster-Konfiguration: Anpassungen

Es werden wenige Änderungen gegenüber dem default durchgeführt
```
postgres@ddbref:/db/postgres/10/cl_prod01/pg
$ diff postgresql.conf _archiv/postgresql.conf_2021-02-09_16\:04
64d63
< port = 5541
352d350
< logging_collector = on
359d356
< log_directory = log
```
Die Port-Anpassung war notwendig wegen der Definition.

Es wird allerdings auch das Logging in eine Log-Datei aktiviert.
Konfigurations-Archiv

Oftmals ist nach kurzer Zeit niemandem mehr bekannt, was eigentlich genau angepasst wurde. Um dieses Problem abzumildern, wird bei der Cluster- Installation ein Archiv-Verzeichnis angelegt, in welchem das Original mit Zeitstempel abgelegt wird.

Bemerkung

Besser ist natürlich ein Change-Managment mit Versionsverwaltung.

systemd-Integration

Selbstverständlich will der neue PostgreSQL-Cluster-Server mit Standard-Mitteln gestartet und beendert werden.

Zu dem Zweck wird ein entsprechendes Unit-File erstellt und auch „enabled“.

Der Server wird bei der Cluster-Einrichtung aber (noch) nicht gestart.

Ein Start sieht wie folgt aus:

sudo systemctl start tpg-postgresql-10-cl_prod01

Ein zweites Kommando zeigt uns, dass der Server läuft

$ sudo systemctl status tpg-postgresql-10-cl_prod01
● tpg-postgresql-10-cl_prod01.service - PostgreSQL database server -- 10  cl_prod01  5541
  Loaded: loaded (/lib/systemd/system/tpg-postgresql-10-cl_prod01.service; enabled; vendor preset: ena
  Active: active (running) since Tue 2021-02-09 16:05:24 CET; 1h 2min ago
    Docs: man:pg_ctl(1)
  Process: 2523 ExecStart=/usr/lib/postgresql/10/bin/pg_ctl start -D /db/postgres/10/cl_prod01/pg (code
Main PID: 2526 (postgres)
    Tasks: 8 (limit: 2359)
  Memory: 16.6M
  CGroup: /system.slice/tpg-postgresql-10-cl_prod01.service
          ├─2526 /usr/lib/postgresql/10/bin/postgres -D /db/postgres/10/cl_prod01/pg
          ├─2527 postgres: logger process
          ├─2529 postgres: checkpointer process
          ├─2530 postgres: writer process
          ├─2531 postgres: wal writer process
          ├─2532 postgres: autovacuum launcher process
          ├─2533 postgres: stats collector process
          └─2534 postgres: bgworker: logical replication launcher

Feb 09 16:05:23 ddbref systemd[1]: Starting PostgreSQL database server -- 10  cl_prod01  5541...

Log-Ausgaben

Eine weitere Möglichkeit, die korrekte Arbeitsweise zu überprüfen, ist ein Blick in die Log-Datei

postgres@ddbref:/db/postgres/10/cl_prod01/pg
$ cat log/postgresql-2021-02-09_160523.log
2021-02-09 16:05:23.987 CET [2528] LOG:  database system was shut down at 2021-02-09 16:04:47 CET
2021-02-09 16:05:23.992 CET [2526] LOG:  database system is ready to accept connections

Test-Connect

Die Log-Datei informiert, dass man sich mit dem Server jezt verbinden kann

postgres@ddbref:/db/postgres
$ psql -p 5541
psql (13.1 (Debian 13.1-1.pgdg100+1), server 10.15 (Debian 10.15-1.pgdg100+1))
Type "help" for help.

postgres=# \l
                                List of databases
  Name    |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges
-----------+----------+----------+------------+------------+-----------------------
postgres  | postgres | UTF8     | de_DE.UTF8 | de_DE.UTF8 |
template0 | postgres | UTF8     | de_DE.UTF8 | de_DE.UTF8 | =c/postgres          +
          |          |          |            |            | postgres=CTc/postgres
template1 | postgres | UTF8     | de_DE.UTF8 | de_DE.UTF8 | =c/postgres          +
          |          |          |            |            | postgres=CTc/postgres
(3 rows)

5.7. Kompletter Use Case#

Um alle PostgreSQL-Cluster zu erstellen, die eingangs dargestellt wurden (siehe Cluster-Beispiel), muß man nur die Vorgehensweise beim Minimal-Cluster vervielfachen.

Der wesentliche Schritt ist die Erstellung alle Definitionen: für jedes Cluster wird eine eignen JSON-Datei editiert

10_cl_prod01.json
10_cl_prod02.json
11_cl_test01.json
11_cl_test02.json
12_cl_dvp01.json
12_cl_dvp02.json
12_cl_dvp03.json
12_cl_dvp04.json
13_cl_edge01.json
13_cl_edge02.json

5.7.1. Definition#

Der Inhalt dieser Datein an einem Stück:

postgres@ddbref:/db/postgres/config/test
$ cat *.json
{
    "pg_release": "10",
    "cluster_name": "cl_prod01",
    "port": 5541,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_prod01"
}{
    "pg_release": "10",
    "cluster_name": "cl_prod02",
    "port": 5542,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_prod02"
}{
    "pg_release": "11",
    "cluster_name": "cl_test01",
    "port": 5641,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_test01"
}{
    "pg_release": "11",
    "cluster_name": "cl_test02",
    "port": 5642,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_test02"
}{
    "pg_release": "12",
    "cluster_name": "cl_dvp01",
    "port": 5741,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_dvp01"
}{
    "pg_release": "12",
    "cluster_name": "cl_dvp02",
    "port": 5742,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_dvp02"
}{
    "pg_release": "12",
    "cluster_name": "cl_dvp03",
    "port": 5744,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_dvp03"
}{
    "pg_release": "12",
    "cluster_name": "cl_dvp04",
    "port": 5744,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_dvp04"
}{
    "pg_release": "13",
    "cluster_name": "cl_edge01",
    "port": 5841,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_edge01"
}{
    "pg_release": "13",
    "cluster_name": "cl_edge02",
    "port": 5842,
    "encoding": "UTF8",
    "locale": "de_DE.UTF8",
    "comment": "cluster cl_edge02"
}

5.7.2. Cluster in Massen#

Ein kleines bash-Skript erstellt alle Cluster:

#!/usr/bin/env bash

/db/postgres/tpg/tpg_cluster  -n -c 10_cl_prod01.json
/db/postgres/tpg/tpg_cluster  -n -c 10_cl_prod02.json

/db/postgres/tpg/tpg_cluster  -n -c 11_cl_test01.json
/db/postgres/tpg/tpg_cluster  -n -c 11_cl_test02.json

/db/postgres/tpg/tpg_cluster  -n -c 12_cl_dvp01.json
/db/postgres/tpg/tpg_cluster  -n -c 12_cl_dvp02.json
/db/postgres/tpg/tpg_cluster  -n -c 12_cl_dvp03.json
/db/postgres/tpg/tpg_cluster  -n -c 12_cl_dvp04.json

/db/postgres/tpg/tpg_cluster  -n -c 13_cl_edge01.json
/db/postgres/tpg/tpg_cluster  -n -c 13_cl_edge02.json

Warnung

Dieses Skript muss als root/sudo laufen.

Nach dem Durchlauf des Skriptes sind alle Cluster eingerichtet

postgres@ddbref:/db/postgres
$ tree -d -L 2 ??
10
├── cl_prod01
│   └── pg
└── cl_prod02
    └── pg
11
├── cl_test01
│   └── pg
└── cl_test02
    └── pg
12
├── cl_dvp01
│   └── pg
├── cl_dvp02
│   └── pg
├── cl_dvp03
│   └── pg
└── cl_dvp04
    └── pg
13
├── cl_edge01
│   └── pg
└── cl_edge02
    └── pg

5.8. Nächste Schritte#

Natürlich sind mit dieser Vorgehensweise mehr oder weniger nur „Standard-Cluster“ erstellt. Erweiterungen sind in vielen Richtungen möglich:

Einrichtung von Datenbänken innerhalb eines Clusters

Bemerkung

Diese Funktion ist implementiert aber hier noch nicht dargestellt.

Cluster-Tuning

Revers-Dokumentation

Aus einem vorhandenen „kanonischen Cluster“ lassen sich die DSL-Konfigurationen revers erstellen mit dem Tool „tpg_admin“.

Festlegung der WAL-Archivierung für PITR.

Skalierbarkeit und Ausfallsicherung

Integration in ein PostgreSQL „Self-Service“.

Je nach Bedarf oder Gelegenheit wird in Zukunft die obigen Punkte ausgebaut.

5.9. Referenzen#

Referencen

[PG_About]
What is PostgreSQL? -> https://www.postgresql.org/about/
URLs
1. https://www.postgresql.org/about/

Footnotes

PostgreSQL – Multi-Release, Multi-Cluster

Kapitel

5. PostgreSQL – Multi-Release, Multi-Cluster#

5.1. What is PostgreSQL?#

5.2. Versionen#

5.3. Software Installation#

5.3.1. Debian#

5.3.2. Suse Leap#

5.4. Kanonische Cluster#

5.4.1. DB-Haupt-Verzeichnis#

5.4.2. Cluster Software#

5.5. Cluster by Example#

5.6. Minimal-Cluster#

5.6.1. Definition#

5.6.2. Test#

5.6.3. Anlegen#

5.6.4. Ergebnis#

5.7. Kompletter Use Case#

5.7.1. Definition#

5.7.2. Cluster in Massen#

5.8. Nächste Schritte#

5.9. Referenzen#