ITrig

PostgreSQL 9.6, pgAdmin 4 und Barman 2.0 sind pünktlich zum neuen Quartal fertig geworden, quasi ein Rundumschlag, doch eins nach dem anderen.

PostgreSQL 9.6 - jetzt auch parallel

Beim neuen Datenbank Server 9.6 verstecken sich die Neuerungen wie so oft im Detail.
So wurden parallele Queries eingeführt. Diese sind in den Standardeinstellungen noch nicht aktiv und müssen erst aktiviert werden. Ich werde das Thema später kurz anreisen.
Das bekannte autovacuum wurde verbessert und die Unterstützung für  multi-CPU-socket Server optimiert. Die Volltextsuche hat Verbesserungen erhalten und arbeitet effizienter.
Eine vollständige List der Neuerungen kann den Release Notes entnommen werden.

Installation PostgreSQL 9.6 unter Ubuntu 14.04 oder 16.04

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" >> /etc/apt/sources.list.d/pgdg.list'
wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O - | sudo apt-key add -
sudo apt-get update
sudo apt-get install postgresql-9.6

Kleine Anmerkung, das Paket postgresql-contrib-9.6 wird durch diesen Befehl mit installiert und muss nicht extra installiert werden.

Parallele Queries aktivieren

Wie bereits in der Einführung erwähnt, beherrscht PostgreSQL 9.6 parallele Queries. Hier ein kurzer Einblick in dieses Thema

Aktuelle Einstellungen anzeigen

sudo cat /etc/postgresql/9.6/main/postgresql.conf |grep max_parallel_workers_per_gather

    #max_parallel_workers_per_gather = 0    # taken from max_worker_processes

Anzahl der Workers auf 2 erhöhen

Wie oben zu sehen ist, ist die Einstellung nicht aktiv, mit dem folgenden Befehl soll das geändert werden.

sed -i 's/#max_parallel_workers_per_gather = 0/max_parallel_workers_per_gather = 2/g' /etc/postgresql/9.6/main/postgresql.conf

Weitere (wichtige) Werte in Zusammenhang mit parallelen Queries

Neben der Anzahl der Worker gibt es noch weitere Einstellungen, hier eine Auflistung der verfügbaren Optionen.

• min_parallel_relation_size = 8MB: Sets the minimum size of relations to be considered for parallel scan
• parallel_setup_cost = 1000.0: Sets the planner's estimate of the cost of launching parallel worker processes
• parallel_tuple_cost = 0.1: Sets the planner's estimate of the cost of transferring one tuple from a parallel worker process to another process
• force_parallel_mode = off: Allows the use of parallel queries for testing purposes even in cases where no performance benefit is expected

Kleiner Hinweis, die Konfiguration lässt sich natürlich auch direkt in der Postgres Konsole anpassen. Hierzu gab es auch schon einen Artikel (PostreSQL und ALTER SYSTEM)

sudo su postgres
psql
postgres=# SET max_parallel_workers_per_gather TO 8;

Test der parallelen Queries

Das Verhalten der Workers kann mit einer einfachen Testdatenbank überprüft werden

sudo su postgres
psql

postgres=# CREATE TABLE paralleltest (i int);
CREATE TABLE
postgres=# INSERT INTO paralleltest SELECT generate_series(1,1000000);
postgres=# ANALYZE paralleltest;
postgres=# EXPLAIN ANALYZE SELECT * FROM paralleltest WHERE i=1;

----------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..10633.43 rows=1 width=4) (actual time=22.542..413.352 rows=1 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on paralleltest  (cost=0.00..9633.33 rows=1 width=4) (actual time=213.560..343.765 rows=0 loops=3)
         Filter: (i = 1)
         Rows Removed by Filter: 333333
 Planning time: 9.629 ms
 Execution time: 416.070 ms
(8 rows)

Weitere Details und Analysen können mit der Verwendung verschiedener Einstellungen erreicht werden. Infos dazu hier.

Fazit

Abschließend kann gesagt werden, dass mit parallelen Queries ein Geschwindigkeitsvorteil gegeben ist, bei anderen Neurungen fehlt mit der praktische Test um Aussagen treffen zu können. Ein Update auf die neueste Version steht somit außer Frage.

---

---

pgAdmin 4 - alles neu macht der Herbst

Ich hatte ja bereits über die pgAdmin 4 Beta berichtet und möchte darum nicht mehr ausführlich auf das PostgreSQL Verwaltungs-Tool eingehen, sondern auf den vorhandnen pgAdmin Artikel verweisen.
Weitere Neurungen sind in pgAdmin seit der Beta nicht eingeflossen, Einstellungen und Funktionen lassen sich der offiziellen Dokumentation entnehmen.

Installation pgAdmin4

Da zum jetzigen Zeitpunkt noch kein Debian Paket zur Verfügung steht, erfolgt die Installation via PIP

sudo apt-get install python-pip
sudo apt-get install libpq-dev
sudo apt-get install python-dev
wget https://ftp.postgresql.org/pub/pgadmin3/pgadmin4/v1.0/pip/pgadmin4-1.0-py2-none-any.whl
pip install pgadmin4-1.0-py2-none-any.whl

Alternativ kann pgAdmin4 auch im Bundle mit PostgreSQL 9.6 heruntergeladen werden.

---

---

Barman 2.0 Disaster Recovery für PostgreSQL

Zeitgleich mit PostgreSQL wurde die Disaster Recovery Barman veröffentlicht. Das Administrationswerkzeug ermöglicht die Sicherung und Wiederherstellung mehrerer Datenbank Server.

Neu an der Version 2.0 ist die Unterstützung für einen reinen Streaming-Modus.
Möglich wurde dies durch die Integration bzw. Unterstützung der pg_basebackup und pg_receivexlog Funktion.
Diese Neuerungen ermöglichen nun eine Datenbank Sicherung von Docker-Containern.

Die Installation läuft einfach ab, für eine korrekte Konfiguration sind ein paar mehr Schritte notwendig.

Installation

Installation unter Ubuntu 14.04

sudo apt-get install python-argcomplete python-argh python-dateutil python-psycopg2
wget http://downloads.sourceforge.net/project/pgbarman/2.0/barman_2.0-1.wheezy%2B1_all.deb
sudo dpkg -i barman_2.0-1.wheezy%2B1_all.deb

Installation unter Ubuntu 16.04

sudo apt-get install python-argcomplete python-argh python-dateutil python-psycopg2
wget http://downloads.sourceforge.net/project/pgbarman/2.0/barman_2.0-1.xenial%2B1_all.deb
sudo dpkg -i barman_2.0-1.xenial%2B1_all.deb

Konfiguration Barman 2.0

Die Hauptkonfiguration erfolgt über die Dateien barman.conf und postgresql.conf.
Das die Einrichtung etwas komplexer ist und auf den gewünschten Sicherungstyp zugeschnitten werden muss, verweise ich schon hier auf die ausführliche Dokumentation mit Schritt für Schritt Anleitung.

Beispielkonfiguration

Nutzer einrichten

sudo su postgres
createuser -W --replication streaming_barman

createuser -W --replication barman

Das vergebene Passwort und der Nutzernamen müssen nun in einem Connection File beim Barman Benutzer hinterlegt werden

sudo echo "dbserverip:5432:postgres:streaming_barman:passwort" > /home/streaming_barman/.pgpass
sudo echo "dbserverip:5432:postgres:barman:passwort" > /home/barman/.pgpass

Berechtigungen müssen ebenfalls gesetzt werden

sudo chmod 600 /home/barman/.pgpass && sudo chmod 600 /home/streaming_barman/.pgpass

Konfiguration PostgreSQL für Barmann

sed -i 's/#archive_mode = off/archive_mode = on/g' /etc/postgresql/9.6/main/postgresql.conf
sed -i 's/#wal_level = minimal/wal_level = replica/g' /etc/postgresql/9.6/main/postgresql.conf
sed -i 's/#archive_mode = off/archive_mode = on/g' /etc/postgresql/9.6/main/postgresql.conf
sed -i 's/#wal_level = minimal/wal_level = replica/g' /etc/postgresql/9.6/main/postgresql.conf
sed -i 's/#max_wal_senders = 0/max_wal_senders = 2/g' /etc/postgresql/9.6/main/postgresql.conf
sed -i 's/#max_replication_slots = 0/max_replication_slots = 2/g' /etc/postgresql/9.6/main/postgresql.conf

Einstellung in der barman.conf

[streaming]
description =  "DB Sicherung Streaming)"
conninfo = host=dbserverip user=barman dbname=postgres
streaming_conninfo = host=dbserverip user=streaming_barman
backup_method = postgres
streaming_archiver = on
slot_name = barman
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 7 days
wal_retention_policy = main

Test der Verbindung

sudo su barman
$ psql -U streaming_barman -h dbserverip -c "IDENTIFY_SYSTEM" replication=1

Password for user streaming_barman:
      systemid       | timeline |  xlogpos   | dbname
---------------------+----------+------------+--------
 6336160320851389899 |        1 | 0/370001B0 |
(1 row)

Hier ein Beispiel für die Konfiguration von SSH

sudo su barman
ssh-keygen -t rsa

sudo su postgres
ssh-keygen -t rsa

Test der Verbindung

ssh barman@dbserverip -C true
ssh postgres@dbserverip -C true

Wal Slot anlegen

sudo su barman
barman receive-wal --create-slot streaming

Das Archive Kommando muss noch in der postgresql.conf angepasst werden

sudo nano /etc/postgresql/9.6/main/postgresql.conf
archive_command = 'rsync -a %p barman@dbserverip:/var/lib/barman/pg/incoming/%f'

Test der Konfiguration

sudo su barman
barman switch-xlog --force pg

Ein Barman Funktionstest kann mit barman check durchgeführt werden

barman check streaming

Server streaming:
        WAL archive: FAILED (please make sure WAL shipping is setup)
        PostgreSQL: OK
        superuser: OK
        PostgreSQL streaming: OK
        wal_level: OK
        replication slot: OK
        directories: OK
        retention policy settings: OK
        backup maximum age: OK (no last_backup_maximum_age provided)
        compression settings: OK
        failed backups: OK (there are 0 failed backups)
        minimum redundancy requirements: OK (have 0 backups, expected at least 0)
        pg_basebackup: OK
        pg_basebackup compatible: OK
        pg_basebackup supports tablespaces mapping: OK
        pg_receivexlog: OK
        pg_receivexlog compatible: OK
        receive-wal running: OK
        archiver errors: OK
       

Manuell starten lässt sich ein Backup mit folgendem Befehl

sudo su barman
barman backup streaming

Starting backup using postgres method for server streaming in /var/lib/barman/streaming/base/20161002T214709
Backup start at xlog location: 0/39000060 (000000010000000000000039, 00000060)
Copying files.

Fazit

Trotz des etwas höherem Aufwands bei der Einrichtung des Sicherungstools barman, macht sich dieses spätestens beim nächsten Serverausfall bezahlt. Mit der Unterstützung für Docker Container arbeitet das Sicherungsprogramm am Puls der Zeit und hat somit sein dasein voll und ganz verdient.

Viel Erfolg