Running RedHat SCL PostgreSQL with Puppet

On a test system for a customer I wanted to bring up a newer PostgreSQL version on CentOS 7 (same for RHEL 7). Software Collections (also for RedHat) gives you a neat distribution method that is not very invasive into your existing distribution. So you can install a PostgreSQL 9.4 under RHEL 7 without replacing any of the existing packages. This is a bit tricky in terms of paths, but just works.

I found a relatively simple way to install, configure and run such a SCL with Puppet, with just using the existing PostgreSQL module.

Have fun trying it out and let me know what you think.

Markus Frosch

Autor: Markus Frosch

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

Ein Buch über Icinga 2

Erscheint am 27. Juni 2016

 
41suqaLOyCL._SX336_BO1,204,203,200_April 2015, nach Monaten des Schwankens machten sich dann zwei verbliebene Möchtegernautoren doch auf ein Buch zum Thema Icinga 2 zu verfassen. Wir wollten ein sehr praxisnahes Werk mit vielen Beispielen wie und mit welchen Plugins etwas zu überwachen ist. Herausgekommen sind 344 Seiten von denen sich 100 mit Plugins und deren Verwendung in Icinga 2 befassen. Vorweg erfolgt eine generelle Einführung, die Vorstellung des neuen Webinterfaces Icingaweb 2 als auch eine ausführliche Erläuterung wie man lokale Werte wie Load bzw. CPU bei Windows oder Disk Usage mit NRPE/NSClient++, SSH und selbstverständlich mit dem neuen Icinga Agenten ermittelt.

Dem Kapitel über Plugins ist noch die Vorstellung einer fiktiven Firma vorangestellt. Diese betreibt ein zweigeteiltes Netzwerk mit einem internen Netz und eine durch Perimeter abgetrennte DMZ. Anhand dieses Beispiels wird eine verteilte Überwachung implementiert. Im internen Netz ist ein Icinga-Server (Master) für die Überwachung der dortig angesiedelten Server und Dienste zuständig. Für die DMZ wird ein weiterer Icinga-Server (Satellit) verwendet, der die ermittelten Ergebnisse an den Master meldet.

Diese Icinga-2-Infrastruktur wird dann im Folgenden benutzt, um eine Vielzahl von Diensten zu überwachen:

  • Host Erreichbarkeit
  • Zeitserver und lokale Zeit
  • Webservices incl. Apache und Ngnix
  • Domain Name Services
  • DHCP
  • Kerberos
  • Mailempfang und -versand
  • Proxy-Server
  • Generische Portüberwachung am Beispiel von Jabber
  • Javabasierte Application-Server
  • SAP
  • Kibana
  • Microsoft-Infrastrukturdienste: CIFS, Terminalservice, Domaincontroller, Exchange
  • Datenbanken: MySQL, PostgreSQL, MS SQL, Oracle
  • LDAP
  • Redis
  • Elasticsearch
  • VMware vSphere
  • Hardware: IPMI, HP, Oracle Solais, Thomas Krenn, Netzwerk, Festplatten
  • NetApp
  • Qnap

Das letzte Drittel ist Graphing mit PNP4Nagios und Graphite, Logmangement, Reporting und Businessprozessen gewidmet.

Teilbereiche werden von den beiden Autoren in einem Workshop vor der diesjährigen Open Source Monitoring Conference mit den Teilnehmern zusammen praktisch umgesetzt.

Lennart Betz

Autor: Lennart Betz

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

In Datenbanken Indizes benutzen Du sollst!

… hat Bernd schon verlauten lassen.

Das heißt aber nicht, dass pauschal jede Spalte jeder Tabelle indiziert gehört – und es funktioniert. Denn bei jeder Schreiboperation müssen auch alle betroffenen Indizes mit aktualisiert werden. Dies sollte berücksichtigt werden, wenn in eine Tabelle potenziell viel geschrieben wird, aber die Lesevorgänge sich in Grenzen halten. (Beispiel: Icinga 2 DB IDO)

Im folgenden möchte ich genauer auf die Anwendungsfälle von DB-Indizes eingehen. Zwecks Demonstration habe ich eine SQLite-DB mit folgendem Schema angelegt:

CREATE TABLE myheavytable0 (
  c0 INTEGER, c1 INTEGER, c2 INTEGER, c3 INTEGER, c4 INTEGER,
  c5 INTEGER, c6 INTEGER, c7 INTEGER, c8 INTEGER, c9 INTEGER
);
CREATE TABLE myheavytable1 (
  c0 INTEGER, c1 INTEGER, c2 INTEGER, c3 INTEGER, c4 INTEGER,
  c5 INTEGER, c6 INTEGER, c7 INTEGER, c8 INTEGER, c9 INTEGER
);

(2 Tabellen mit je 10 Ganzzahlen-Spalten)

Diese Tabellen habe ich mit je 10.000.000 Zeilen Zufallszahlen befüllt. Im übrigen ist die Indizierung numerischer Spalten potenziell besser als die Indizierung von Text-Spalten.

Anwendungsfall #1: Joins

Die Herstellung von Beziehungen zwischen verschiedenen Entitätsmengen mit Hilfe von Fremdschlüsseln ist bei relationalen Datenbanken das Tagesgeschäft. Es kann sich durchaus lohnen, die entsprechenden Spalten zu indizieren.

Zwecks Demonstration wird das Schema wie folgt ergänzt:

CREATE INDEX myheavyindex0c0 ON myheavytable0 (c0);
CREATE INDEX myheavyindex0c1 ON myheavytable0 (c1);
CREATE INDEX myheavyindex1c0 ON myheavytable1 (c0);
CREATE INDEX myheavyindex1c1 ON myheavytable1 (c1);

(Die ersten 2 Spalten beider Tabellen werden jeweils einzeln indiziert.)

Die Auswirkungen können mit Messungen der Ausführungszeiten folgender Abfragen veranschaulicht werden:

Abfrage Zeit
SELECT COUNT(*) FROM myheavytable0 m0 INNER JOIN myheavytable1 m1 ON m0.c2 = m1.c3 1m 6.519s
SELECT COUNT(*) FROM myheavytable0 m0 INNER JOIN myheavytable1 m1 ON m0.c0 = m1.c3 20.836s
SELECT COUNT(*) FROM myheavytable0 m0 INNER JOIN myheavytable1 m1 ON m0.c0 = m1.c1 4.468s

Daraus folgt: Werden 2 Tabellen mit Hilfe von je einer Spalte, von denen eine indiziert ist, gejoint, ist die Abfrage etwa 3x so schnell wie mit 2 nicht-indizierten Spalten. Sind beide Spalten indiziert, ist die Abfrage fast 15x so schnell.

Anwendungsfall #2: Verrechnung mehrerer Spalten

Manchmal müssen 2 Attribute einer Entität in einer Abfrage miteinander verrechnet werden. Viele Datenbanken bieten lobenswerterweise auch die Möglichkeit, Ausdrücke zu indizieren:

CREATE INDEX myheavyindex0e0 ON myheavytable0 (c4 + c5);
Abfrage Zeit
SELECT COUNT(*) FROM myheavytable0 WHERE c0 + c1 > 8000000 1.324s
SELECT COUNT(*) FROM myheavytable0 WHERE c4 + c5 > 8000000 0.513s

Daraus folgt: Wenn ein indizierter Ausdruck abgefragt wird, ist die Abfrage fast 3x so schnell wie wenn alle am Ausdruck beteiligten Spalten einzeln indiziert sind.

Anwendungsfall #3: Filter auf mehrere Spalten

Wenn abgefragte Daten häufig auf mehreren Spalten basierend gefiltert werden, kann es sich lohnen, diese Spalten zusammen zu Indizieren:

CREATE INDEX myheavyindex0m0 ON myheavytable0 (c6, c7);
Abfrage Zeit
SELECT COUNT(*) FROM myheavytable0 WHERE c0 < 8000000 AND c1 > 8000000 12.130s
SELECT COUNT(*) FROM myheavytable0 WHERE c6 < 8000000 AND c7 > 8000000 0.445s

Daraus folgt: Bei zusammen indizierten Spalten ist die Abfrage 27x so schnell wie bei einzeln indizierten.

Fazit

Bei Nutzung von Indizes hängt viel vom Einzelfall ab. Im Zweifelsfall sollte ein Fachmann zu Rate gezogen werden.

Alexander Klimov

Autor: Alexander Klimov

Alexander hat Ende 2013 mit einem Praktikum bei NETWAYS gestartet. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 und seiner Ausbildung bei uns friedliche Wege.

Nachgestellte Leerzeichen und String-Vergleiche in Datenbanken

Für Datenbanken die sich an den SQL-92-Standard halten, gilt für Vergleiche von character strings nach Abschnitt 8.2 Generals Rules #3, dass die zu vergleichenden Strings, vor dem Vergleich auf die selbe Länge gebracht werden müssen. Der eventuell kürzere String wird demnach nach rechts auf die Länge des zu vergleichenden Strings mit Hilfe eines pad character, meist dem Leerzeichen, aufgefüllt.

Unter character strings fallen die Typen char (character) und varchar (character varying). Diese Typen ähneln einander, werden aber auf unterschiedliche Weise gespeichert und abgerufen.
char-Werte werden beim Speichern nach rechts mit Leerzeichen bis auf die deklarierte Länge aufgefüllt, welche beim Abrufen aber wieder entfernt werden. Bei char-Werten mit einer maximalen Anzahl von vier Zeichen beispielweise, kann man deshalb nicht zwischen 'abc' und 'abc ' unterscheiden.
Im Gegensatz dazu werden varchar-Werte nur mit so vielen Zeichen wie erforderlich zuzüglich der Information über die Länge gespeichert. varchar-Werte werden beim Speichern nicht aufgefüllt. Somit werden auch Leerzeichen beim Speichern und Abrufen beibehalten.

Und jetzt? Jetzt wollen wir versuchen aus den varchar-Werten 'abc' und 'abc ' nur 'abc ' zu selektieren.

Als Erstes brauchen wir natürlich eine Datenbank mit den gewünschten Daten (hier in MySQL):

CREATE DATABASE playground;
USE playground;
CREATE TABLE pad (string varchar(5));
INSERT INTO pad VALUES('abc');
INSERT INTO pad VALUES('abc ');
INSERT INTO pad VALUES('abc  ');

Als Nächstes überprüfen wir, ob – wie im Standard definiert – bei varchar-Werten Leerzeichen beim Speichern und Abrufen beibehalten werden:

SET sql_mode = PIPES_AS_CONCAT;
 
SELECT '"' || string || '"', LENGTH(string) FROM pad;
 
+----------------------+----------------+
| '"' || string || '"' | LENGTH(string) |
+----------------------+----------------+
| "abc"                |              3 |
| "abc "               |              4 |
| "abc  "              |              5 |
+----------------------+----------------+

Das sieht doch gut aus. Nun zurück zur eigentlichen Aufgabe: Wir wollen aus diesen Daten nur 'abc ' selektieren:

SELECT '"' || string || '"', LENGTH(string) FROM pad WHERE string = 'abc ';
 
+----------------------+----------------+
| '"' || string || '"' | LENGTH(string) |
+----------------------+----------------+
| "abc"                |              3 |
| "abc "               |              4 |
| "abc  "              |              5 |
+----------------------+----------------+

Irgendwie nicht richtig. Oder doch? Wie eingangs erwähnt, tritt hier die Regel für Vergleiche von character strings aus dem SQL-92-Standard in Kraft: Der kürzere zu vergleichende String wird nach rechts mit Leerzeichen aufgefüllt. Wenn 'abc' mit 'abc ' verglichen wird, wird eigentlich 'abc ' mit 'abc ' verglichen, oder 'abc' mit 'abc' – wer weiß das schon so genau :).

Kommt man trotzdem auf das gewünschte Ergebnis? Klar, mit einem Zaubertrick:

SELECT '"' || string || '"', LENGTH(string) FROM pad WHERE BINARY string = 'abc ';
 
+----------------------+----------------+
| '"' || string || '"' | LENGTH(string) |
+----------------------+----------------+
| "abc "               |              4 |
+----------------------+----------------+

Gibt’s Ausnahmen? Ja! Bei PostgreSQL sind bei Vergleichen von varchar-Werten nachgestellte Leerzeichen signifikant.

Eric Lippmann

Autor: Eric Lippmann

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

OSDC 2014: Der Countdown läuft – nur noch 43 Tage

Wer bin ich?
Wo komme ich her?
Wo gehe ich hin?
Und wohin geht die Reise für PostgreSQL?

Fragen über Fragen, denen sich Michael Renner teilweise in seinem Vortrag annimmt.

OSDC? Noch nie gehört…

Das ist aber schade und fast schon ein unentschuldbares Versäumnis!
Aber wir holen das nach:

Die Open Source Data Center Conference (kurz OSDC) ist unsere internationale Konferenz zum Thema Open Source Software in Rechenzentren und großen IT-Umgebungen. 2014 findet sie zum sechsten Mal statt und bietet mit dem Schwerpunktthema Agile Infrastructures ganz besonders erfahrenen Administratoren und Architekten ein Forum zum Austausch und die Gelegenheit zur Aneignung des aktuellsten Know-Hows für die tägliche Praxis. Diesmal treffen wir uns dafür in Berlin!
Workshops am Vortag der Konferenz und das im Anschluss an die Veranstaltung stattfindende Puppet Camp komplettieren dabei das Rundum-sorglos-Paket für Teilnehmer, die gar nicht genug Wissen in sich aufsaugen können.

Eva Häusler

Autor: Eva Häusler

Eva ist bei NETWAYS für das Marketing zuständig. Gerüchten zufolge wurde sie vor etwa einem Jahrzehnt in einer Kiste Braunschweiger Honigkuchen von Niedersachsen nach Franken geschmuggelt und wird seitdem hier in Geiselhaft gehalten. Nach einem Germanistikstudium mit begleitenden Ausflügen in die Nürnberger Literaturszene, hat sie bei NETWAYS in der Eventabteilung angefangen. Inzwischen kommt ihre geballte Wortgewalt im Marketing nutzbringend zum Einsatz.

Und das war die PGConf.DE 2013

PostgreSQL Elephant Kollege Lennart und ich haben letzte Woche einen Abstecher nach Oberhausen gemacht, um an der deutschsprachigen PostgreSQL Konferenz 2013 teil zu nehmen.

In über 20 Vorträgen gab es viele Neuigkeiten zu PostgreSQL, der Community und einigen Projekten für und mit PostgreSQL. Wie auch an unseren Konferenzen zu spüren wächst das internationale Interesse an deutschen Konferenzen immer mehr, und so gab es auch viele englischsprachige Vorträge.

Aus einigen Vorträgen war zu entnehmen dass viele viele Anwender an Performance-Problemen scheitern, die meist auf grundsätzliche Index-Probleme, fehlende Tuningeinstellungen oder sogar schlecht durchdachte Anwendungen zurückzuführen sind.

Einige Unternehmen waren anwesend und berichteten von Ihren positiven Erfahrungen bei, Einsatz von PostgreSQL und der Migration von anderen RDBMS.

Es ist immer wieder eine Freude viele bekannte Gesichter zu treffen und sich über den neuesten “IT Tratsch” auszutauschen.

Wer uns auf einer Konferenz entdeckt, darf übrigens gerne Hallo sagen, wir beißen nicht! 😉 Wir haben auch Steckbrief-Bilder zum einprägen!

Hier noch ein paar Vortrags-Empfehlungen:

The PostgreSQL name and logo are trademarks of The PostgreSQL Community Association of Canada. (source)

Markus Frosch

Autor: Markus Frosch

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.