Skip to content

PostgreSQL 9.6, pgAdmin 4 und Barman 2.0 - Die Neuerungen und Installation unter Ubuntu 14.04 und 16.04

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.

postgres

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.

pgadmin4

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.

barman

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.

barman

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

Linux - SSH Login ohne Passwort mit SSH Schlüssel einrichten

Für die Wartung von Servern oder anderen sicheren Netzwerkverbindungen wird meistens SSH (Secure SHELL) verwendet.

Normalerweise erfolgt die Authentifizierung so einer Verbindung via Passwort. Viel sicherer ist eine Authentifizierung mit einem SSH Schlüssel. Für die Einrichtung einer sicheren Verbindung mit SSH Schlüssel sind nur wenige Handgriffe nötig.

Hier eine kurze Anleitung für das Umstellen von Passwort auf SSH Schlüssel Authentifizierung.

Vorraussetzung ist, dass das SSH Server Paket bereits installiert ist.

Schlüssel erzeugen

ssh-keygen -t rsa -b 4096

Generating public/private rsa key pair.

Enter file in which to save the key (/home/guenny/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/guenny/.ssh/id_rsa.

Your public key has been saved in /home/guenny/.ssh/id_rsa.pub.

The key fingerprint is:

a5:e2:b2:38:ff:a7:f5:de:03:dd:ss:6e:dd:c8:7d:11

The key's randomart image is:

+--[ RSA 4096]----+

|                 |

|                 |

|          .      |

|         oE      |

|     .  S ..     |

|    + o. ..      |

|. o. =.o.+ .     |

| = ..o+o+ o .    |

|. .o+oo.   .     |

+-----------------+

Schlüssel kopieren

sudo cat home/guenny/.ssh/id_rsa.pub >> /guenny/.ssh/authorized_keys

SSH Konfiguration sichern

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

SSH Konfiguration für Public Key Auth anpassen

sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config

sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config

sudo echo "DebianBanner no" >> /etc/ssh/sshd_config

Die Werte RSAAuthentication und PubkeyAuthentication sollten in den Standardeinstellungen bereits auf yes stehen

Konfiguration neu laden

sudo service ssh reload

Sobald die Konfiguration neu geladen wurde, ist es zwingend notwendig mit einer zweiten Verbindung zu testen, ob alles richtig konfiguriert wurde. Die bestehende Verbindung sollte dazu offen bleiben. 

Schlüssel auf andere Server kopieren 

Um Schlüssel auf andere Server zu kopieren kann der Befehl ssh-copy-id verwendet werden.

ssh-copy-id -i ~/.ssh/id_rsa.pub REMOTE_SERVER