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 - Dstat Monitor vereint netstat, vmstat, iostat und ifstat

Aktuelle Messdaten sind bei jedem System interessant, egal ob Linux oder Windows. Bei ersterem gibt es für eine schnelle Überprüfung diverser Messwerte nützliche Kommandozeilen Tools.

Da wäre vmstat für RAM und CPU Werte, iostat für Schreib- und Lesezugriffe, netstat für den Netzwerkverbindungen und ifstat für den Netzwerkdurchsatz.

Beim Einsatz aller Tools erhält der Anwender verschiedene und verteilte Ausgaben. Viel praktischer wäre eine Gesamtausgabe alle überwachten Daten.

Dstat 

Hier kommt Dstat ins Spiel. Das kleine Programm vereint wichtige Tools unter einer Haube und erlaubt es den Überblick über die Systemwerte zu behalten.

Installiert ist das Programm mit einem Befehl

sudo apt-get install dstat 

Gleiches gilt für den ersten Start, hier müssen nicht zwingend weitere Parameter angegeben werden, ein einfaches "dstat" genügt

dstat

Neben der Standardausgabe beherrscht das Tool noch einiges mehr. Die volle Befehlspalette kann mit "dstat --help" abgerufen werden. Hier ein paar Befehle in der Übersicht

  • -l  --> load stats aktivieren
  • -m --> memory stats aktivieren
  • -s --> swap stats aktivieren
  • -nocolor --> no colors
  • -s --> swap stats aktivieren
  • --socket --> socket stats aktivieren
  • --tcp --> tcp stats aktivieren
  • --udp --> udp stats aktivieren
  • --unix --> unix stats aktivieren
  • --vm --> vm stats aktivieren
  • --output --> in Datei speichern

Neben üblichen Kommandos stehen Plugins zur Verfügung, welche wichtige Funktionen bündeln. Plugins lassen sich mit "ls -l /usr/share/dstat" auflisten. Brauchbare wären beispielsweise

  • -top_mem
  • -top_cpu
  • -freespace
  • -disk-util

So lassen sich schnell einfache Befehle zusammenstellen, die für den Alltag nützlich sind. Hier zwei Beispiele

dstat -c -s -l --proc-count --top-mem

dstat –output stats.csv -cdnm

3 gute Quellen für Linux Befehle, Beispiele oder Codeschnipsel

Im Linux Bereich zählt nicht der Klick auf irgendwelche Fenster, sondern eher der Konsolenbefehl. Oft kommt es vor, dass die Shell Befehle nicht sofort parat sind oder die Ausführung eines Kommandos durchaus lang und verwirrend wird.

Wie so oft im Leben, machen es in diesem Fall Beispiele dem Anwender oftmals leichter, den Ausdruck nachvollziehen zu können. Darum möchte ich hier drei Webseiten vorstellen, die Codebeispiele für Shellbefehle auflisten, das Kommando selbst erklären oder einfach als Nachschlagewerk dienen.

So praktisch diese folgenden Tipps auch sein mögen, der gute "man" Befehl führt in den meisten Fällen am schnellsten zum Erfolg.

commandlinefu

Die Webseite commandlinefu.com versteht sich als Sammelstelle für die häufigsten und praktischsten Shell Befehle.  Die Anwender können ihre besten Kommandos einstellen oder für vorhandene voten.

So entstehen nützliche Best of Listen. Der beliebteste Befehl zurzeit ist "sudo !!", dieser führt den letzten Befehl mit root Rechten aus.

commandlinefu

ExplainShell

Bei ExplainShell handelt es sich in diesem Sinne nicht um ein User Repository, sondern eine visuelle Aufschlüsselung der vorhandenen Manuals. So lassen sich lange Befehlsketten in die einzelnen Kommandos aufschlüsseln. Um die Sammlung möglichst vollständig zu halten, wurden 29761 Manpages eingelesen.

explainshell

linux-commands-examples

Eine weitere Seite, welche zahlreiche Linux Befehle samt Beispielen listet, ist linux-commands-examples.com. Hier kann entweder nach dem gewünschten Begriff, inklusive Beispiel, gesucht oder per Liste auf die zahlreichen Beispiele zugegriffen werden.

Linux_befehle_beispiele