Seite wählen

NETWAYS Blog

PostgreSQL Einstieg unter openSUSE-Leap 15.2

da die meisten User sich zwar mit MySQL oder MariaDB auskennen, werde ich heute mal auf PostgreSQL eingehen, wie man dieses Paket installiert und ein paar Kommandos zur Verwaltung einer Datenbank.
PostgeSQL ist von den Kommandos ähnlich wie zum Beispiel MariaDB. Sie wird auch als ein freies, objektrelationales Datenbankmanagementsystem (ORDBMS) betitelt, somit auch Opensource ist.

Installation unter openSUSE-Leap 15.2:

Pakete sind in den offiziellen Repositories zu finden, die bei dem Setup von openSUSE-Leap gesetzt werden.

# sudo zypper in postgresql postgresql-server

Da da der Dienst von PostgreSQL nicht automatisch gestartet wird, wie z.B bei Debian basierten Linux-Distributionen muß dieser noch gestartet werden

# sudo systemctl start postgresql

Am besten prüft man nochmal ob der Dienst auch fehlerfrei läuft

# sudo systemctl status postgresql
● postgresql.service - PostgreSQL database server
 Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled)
 Active: active (running) since Tue 2020-11-03 08:31:17 UTC; 4h 23min ago
 Main PID: 1460 (postgres)
 Tasks: 8
 CGroup: /system.slice/postgresql.service
 ├─1460 /usr/lib/postgresql12/bin/postgres -D /var/lib/pgsql/data
 ├─1461 postgres: logger 
 ├─1463 postgres: checkpointer 
 ├─1464 postgres: background writer 
 ├─1465 postgres: walwriter 
 ├─1466 postgres: autovacuum launcher 
 ├─1467 postgres: stats collector 
 └─1468 postgres: logical replication launcher

Nov 03 08:31:15 opensuse-leap systemd[1]: Starting PostgreSQL database server...
Nov 03 08:31:15 opensuse-leap postgresql-script[1437]: Initializing PostgreSQL 12.4 at location /var/lib/pgsql/data
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.186 UTC [1460]LOG: starting PostgreSQL 12.4 on x86_64-suse-linux-gnu, compiled by gcc (SUSE L>
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.187 UTC [1460]LOG: listening on IPv6 address "::1", port 5432
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.187 UTC [1460]LOG: listening on IPv4 address "127.0.0.1", port 5432
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.193 UTC [1460]LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.204 UTC [1460]LOG: listening on Unix socket "/tmp/.s.PGSQL.5432"
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.221 UTC [1460]LOG: redirecting log output to logging collector process
Nov 03 08:31:17 opensuse-leap postgresql-script[1437]: 2020-11-03 08:31:17.221 UTC [1460]HINT: Future log output will appear in directory "log".
Nov 03 08:31:17 opensuse-leap systemd[1]: Started PostgreSQL database server.

Da wir jetzt wissen, das der Dienst ordnungsgemäß läuft, können wir loslegen, mit dem anlegen von der Datenbank und Tabellen.

PostgreSQL wird vom System-User postgres verwaltet, der alle Rechte hat, um z.B. Datenbanken oder auch Datenbankbenutzer anzulegen. Da dieser User ohne Passwort konfiguriert ist, was unter MariaDB oder MySQL teilweise auch so ist, sollte man dem User sicherheitstechnisch ein Passwort konfigurieren.

# sudo passwd postgres

Passwort nach Aufforderung eingeben und erneut wiederholen.

Unter PostgreSQL gibt es genauso ein Shell wie bei z.B. MySQL und in diese kommt man wie folgt:

# sudo -u postgres psql

Um diese Shell wieder zu verlassen

\q

eingeben

Anlegen vom User der Datenbanken verwalten darf

 # sudo sudo -u postgres createuser -P -d NUTZERNAME

Der Schalter -P <password> -d <create databases>

Anlegen von einer Datenbank

# sudo -u postgres createdb -O username DATABASENAME

Löschen einer Datenbank

# sudo -u postgress dropdb DATABASE

In der postgresql Shell sieht das anders aus

postgres=# CREATE DATABASE my_music;

Wechseln zwischen den Datenbanken

\c DATENBANK

Ein Tabelle mit den Spalten anlegen

postgres=# CREATE TABLE cds ( id int, interpreter varchar(100), album varchar(100), release date );

Daten in die Tabelle der Datenbank schreiben

INSERT INTO cds VALUES ( 1, 'Pretty Maids', 'Future World', '1987-04-12' );

Ausgeben der Daten

my_music=# select * from cds;
 id | interpreter  |       album        |  release   
----+--------------+--------------------+------------
  1 | Pretty Maids | Future World       | 1987-04-12
  2 | Metallica    | Ride the Lightning | 1984-04-12
(2 rows)

Als kleine Einführung in PostgreSQL sollte das erst mal ausreichen,  für mehr Wissen darüber bieten wir von NETWAYS auch eine PostgreSQL Schulung an.

Dann viel Spaß bei ausprobieren von PostgreSQL auf openSUSE.

 

Johannes Carraro
Johannes Carraro
Senior Systems Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Team Operations als Senior Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

Warum wir in den NETWAYS-PostgreSQL-Trainings eigentlich nur „psql“ nutzen

Wieder einmal PostgreSQL Schlung (Fundamentals und Advanced) durchgeführt.
Wieder einmal wurde nach GUIs gefragt.
Wieder einmal haben wir uns dann letztlich doch fast auf psql beschränkt.

Warum ist das so?

 

GUI vs. TUI – the eternal battle

GUIs werden i. A. als „benutzerfreundlicher“ dargestellt.

Ich persönlich wiederum finde es ganz schrecklich, dauernd zur Maus greifen zu müssen, um irgendeine Aktion auszulösen, für die die Entwickler keinen oder einen grauenhaften Shortcut konfiguriert haben… für mich sind GUIs also eher weniger benutzerfreundlich.

Mir ist auch klar, dass es beileibe nicht jedem Menschen so geht, und die Gewöhnung spielt dabei sicher auch eine enorme Rolle.

„The usual suspects“: die üblicherweise genannten Gründe pro GUI/TUI

GUI:

  • intuitiver zu bedienen
  • „gewohnte“ Optik
  • bessere Übersicht über Ergebnisse von Queries

TUI:

  • steht vom Funktionsumfang dem GUI kaum nach
  • funktioniert auch bei langsamer Verbindung („Zug“)
  • kann gescriptet werden

Es gibt aber einige durchaus schwerwiegende Gründe, warum ich bei Trainings so einen großen Wert auf psql lege.

„The killer arguments“: warum psql elementar ist

Die Lernschwelle ist bei GUIs unnötig hoch

  • Jedes GUI sieht letztlich (ein wenig) anders aus und es gibt einfach zu viele
  • Um eine erste Verbindung herzustellen, muss im GUI erst ein Server definiert werden, mit jeder Menge Parametern, u.a. einer Netzwerkverbindung
    • dafür muss aber erst ein Konfigurationsparameter (listen_addresses=) gesetzt werden, was wiederum erst deutlich nach dem ersten „Reinschnuppern“ behandelt wird…
    • Im Terminal hingegen (wo ich ja gerade den DB-Server installiert habe) komme ich per psql direkt an die DB (wenn ich der OS-User postgres bin…)
  • Objekte anschauen („Erste Schritte“):
    • TUI: nach Eingabe von psql kann ich einfach z.B. \dt eingeben und bekomme alle Tabellen gelistet, \d nachnamen zeigt mir instant die Tabellenstruktur, dazu Indexe, Primär-/Fremdschlüssel etc. an
    • in allen GUIs muss ich dafür erst durch einen Baum klicken, in pgAdmin4 z.B. Servergruppe -> Server -> Datenbank -> Schemas -> ‚public‘ -> Tabellen

Die (online-)Trainings-VMs sind nur per ssh und Webinterface erreichbar

  • um da per GUI dranzukommen, müssten also die Teilnehmer erstmal Software auf ihren (privaten oder dienstlichen) PCs installieren…

Viel entscheidender ist aber m.E.:

psql ist für den PostgreSQL-DBA, was vi für den U\*\*X-Admin ist:

  • auf jeder PostgreSQL-Maschine verfügbar
  • minimalistisch, aber gleichzeitig unglaublich leistungsfähig
  • ich muss das sowieso zu nennenswerten Teilen beherrschen, z.B.
    • für den Fall, dass mir die Firewall einen Streich spielt
    • wenn ich mal als Superuser in die DB will/muss (max_connections= ausgeschöpft)
    • um Dinge zu scripten

Wenn mir jemand erzählt, er oder sie sei UNIX-Admin, dann aber einen nano benutzt, bin ich sofort (zurückhaltend ausgedrückt) skeptisch.

Ähnlich ist es mit psql. Ich muss (als DBA) sowieso wissen, wie ich damit z.B. Objekte anzeigen, DDL einspielen, ggfs. mal eine Stored procedure umschreiben etc. pp. kann. Wenn ich die Software also sowieso (halbwegs) beherrschen muss, kann ich sie doch auch gleich benutzen? Ich sehe nur wenige Szenarien, in denen ein(e) DBA von einem GUI profitieren würde.

Ein(e) AnalystIn hingegen wird die DB wahrscheinlich eher direkt an ein Reporting-Tool oder M$ Excel anbinden wollen.

Bleibt der/die (SQL-) EntwicklerIn. Ja, fair enough, da sehe auch ich gewissen Charme (üblicherweise F5 drücken, um das SQL im Fenster (erneut) laufen zu lassen). Auf der anderen Seite ist derselbe Effekt in psql durch Eingabe von \e zu erreichen, und da kommt ein vi. Der ist ja bekanntlich minimalistisch, aber… 😉

Und ob man DDL jetzt per GUI erzeugen sollte, darüber scheiden sich ja auch die Geister… IMHO eher nicht.

Fazit:

„I never leave the house without it!“

psql ist der vi(m) der PostgreSQL-Welt. Unfassbar flexibel und leistungsfähig, immer verfügbar und dadurch absolutes „Pflichtprogramm“.

P.S.

Ich habe mal jemanden kennengelernt, der eine U\*\*X-Consulting-Firma betrieb und lt. eigener Aussage nur Menschen anstellte, die den ed beherrschen. So weit würde ich dann auch nicht gehen… 😉

P.P.S.

Vielleicht hat die Abneigung gegen TUIs was mit Oracles SQL*Plus (TM) zu tun? Wäre absolut nachvollziehbar, das fasse ich auch nur mit der Kneifzange an…

 

Über den Author:

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.

Milano – PostgreSQL Conference Europe 2019

It has been a while since one of us visited a PostgreSQL Conference. So when the opportunity arose Lennart and I took it. Additionally, it is somewhat of a special pgconf this year, because the conference is held where it originated, Italy. With over 500 attendees the conference set a new all time record. It is going to be a good one. Numerous talks, a lot of variety and gaining more insight into the postgres community. That being said, these talks can by no means be summarized in one blog post, that is why I have decided to bring you my just personal highlights. If you are interested in talks not mentioned here, I highly recommend checking out the official pgconf.eu website, where at least most slides of speakers can be found.

#PostGIS #PgConfEU Slides now online here https://t.co/YgDVHC420V https://t.co/ze26KYWiZh

— Paul Ramsey (@pwramsey) October 16, 2019

Paul Ramseys talk about PostGIS was the first one that spiked my attention. Having used PostGIS before without extensive knowledge, the add-on seemed pretty mundane, but little did I know. And I mean that. Little did I know of the extend of PostGIS or GIS as a whole. Let me try to give you the just of it. There was a phrase that he used a few times that somehow stuck: GIS without the GIS. To be just that PostGIS without the GIS the workload of low-performance scripts had to be moved to more efficient SQL. Additionally, spatial middleware from the database to the web had to go. Lastly, PostGIS had to be build in a way that provides developer with direct access to a GIS analytical engine. After giving everyone a basic introduction with the some example problems and queries to solve them. Well, he told us everything about PostGIS or atleast a lot. SFSQL, OSS, ISO, Indexing, Spatial Joins, the list is long. 189 Slides, If you will.

Applications developers are certainly enjoying ORM talk by Louise Grandjonc @louisemeta pic.twitter.com/9iE4MxRelk

— PGConf Europe (@pgconfeu) October 17, 2019

Next up in my little list of talks I really enjoyed was Wonderful SQL features your ORMs can use (or not) by Louise Grandjonc. She went through various ORMs (Object Relationship Mapper) during her talk like Django, SQLAlchemy, activerecord and Sequel and used them for a little project of hers. With scripts she aggregated Data regarding pop music lyrics and used this data as an example for various queries.

More Than a Query Language: SQL in the 21st Century was the title of the talk I want to tell you about next. Markus Winand talked a lot of history here. He looked at the very beginning and saw how SQL evolved and changed in many ways. A lot of empathisis was put on SQL having been bound to the idea of an relational data model for too long and that not necessarily beening the case today anymore. While jumping through the timeline of SQL development and explaining various features in the process he validated his claim.

I think it was a great event. I really liked the variety of topics and I hope even though I just mentioned a few, you got some insight into the event. PostgreSQL has an awesome community and having that conference as a platform to exchange experience, help and learn from eachother is just great

Alexander Stoll
Alexander Stoll
Consultant

Alex hat seine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS Professional Services abgeschlossen und ist nun im Consulting tätig. Vereinzelt kommt es auch vor das er an Programmierprojekten mitarbeitet. Auch privat setzt er sich sehr viel mit Informationstechnologie auseinander, aber jenseits davon ist auch viel Zeit für Fußballabende, Handwerkerprojekte und das ein oder andere Buch.

Neu im NETWAYS Trainings-Portfolio: PostgreSQL

Ihr liebt sie! Zweimal in Folge, 2017 und 2018, wurde PostgreSQL “DBMS of the Year” im DB-Engines Ranking. Na klar nehmen wir für all ihre Fans und solche, die es werden wollen, die freie, objektrelationale Datenbank PostgreSQL in unser Schulungs-Portfolio auf.

PostgreSQL steht für Zuverlässigkeit, Flexibilität und viele fortgeschrittene Features. Deswegen entwickelt es sich immer mehr zur Alternative zu anderen Open-Source-Datenbanken wie MySQL/MariaDB, aber auch den großen, kommerziellen Systemen.

Für einen stabilen, stressfreien Betrieb

Die Schulung „PostgreSQL Fundamentals“ richtet sich an Administratoren, die an einem stabilen, wartungsarmen Betrieb einer PostgreSQL-Datenbank interessiert sind. Fundamentals-Inhalte sind unter anderem Entwicklungs- und Release-Zyklus, Beschaffung und Installation, (G)UIs, grundlegende Konfiguration, Backup und Restore, Replikation und (Hoch)Verfügbarkeit und vieles weitere.

PostgreSQL als „Data Center“

Die Schulung „PostgreSQL Advanced“ richtet sich an Datenbank-Architekten und -Designer sowie Entwickler, aber auch DevOps, die ihre Kunden aus ebenjenen Bereichen beraten wollen. Advanced-Inhalte sind, grob skizziert, Performance, PostgreSQL als „Data Center“ und Programmierung und Design.

Im Schulungs-Paket enthalten sind wie immer umfangreiche Schulungsunterlagen, ein Notebook für die Dauer des Trainings, sowie unsere legendäre Rund-um-sorglos-Verpflegung mittags, abends und in allen Pausen.

 

TRAININGS DETAILS

PostgreSQL Schulung (Fundamentals): 4. Juni / 10. September / 19. November 2019

PostgreSQL Advanced: 6. August / 22. Oktober / 3. Dezember 2019

 

Weitere Informationen & Anmeldung
www.netways.de/trainings
training@netways.de

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.
https://gist.github.com/lazyfrosch/1926b17d1d605bfb819e899ef6bd4b63
Have fun trying it out and let me know what you think.