pixel
Seite wählen

NETWAYS Blog

Neues von den Influxdays EMEA 2021

von | Mai 20, 2021 |

Auf den influxdays kündigt Paul Dix, CTO von InfluxData, einen neuen Core names iOx für influxDB an. Dieser Schritt löst spontan Unsicherheit aus. Hier ein paar Fakten um die Gemüter zu beruhigen:

InfluxDB 2.x Open Source wird, so wie es jetzt existiert, parallel mit regelmäßigen Point-Releases weiterentwickelt.
InfluxDB IOx wird SQL, InfluxQL und Flux unterstützen.
InfluxDB IOx wird in einem zukünftigen Release ein optionales Speicher-Backend für InfluxDB werden.
Die Implementierung durch Rust und Apache Arrow soll eine höhere Sicherheit erreichen. Auf Grund verschiedener Optimierungen am Speicherverhalten soll die Datenmenge verringert und gleichzeitig die Abfragegeschwindigkeit erhöht werden.
InfluxDB Enterprise-Kunden werden in der zweiten Hälfte des Jahres 2021 über eine kommerziell unterstützte Version von InfluxDB IOx und InfluxDB Enterprise verfügen.

Das war nicht das einzige Thema auf der online abgehaltenen Konferenz.
In dem ausgewogenen Programm konnte man sich anschauen, wie man mittels Telegraf Daten in Richtung influxDB schreibt. In einem anderen Vortrag ging es um Dashboards, Alerts und Tasks.

Ein Highlight war für mich der Talk von Aengus Rooney, der zwar trotz des Titels „What’s New with Grafana and InfluxDB“ erstaunlich wenig Neuerungen gezeigt hat, jedoch mit einem längeren Hands-On die Möglichkeiten von Grafana anhand eines selbst erstellten Handels Terminals für Kraken/Bitcoin demonstriert hat.

Alle Aufzeichnungen der Konferenz werden ab 31. Mai veröffentlicht. Man findet sie, wie auch die Videos vergangener Konferenzen, auf den Seiten der influxdays und auf youtube.

Wer mehr über influx und die Möglichkeiten erfahren möchte kann sich auch bei NETWAYS im Rahmen eines zweitägigen Trainings informieren.

Christoph Niemann
Christoph Niemann
Senior Consultant
Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.
Lies mehr von Christoph und triff unser Team

PostgreSQL Einstieg unter openSUSE-Leap 15.2

von | Jan 21, 2021 |

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.
Lies mehr von Johannes und triff unser Team

Encoding „leicht gemacht“ mit PostgreSQL

von | Dez 10, 2020 |

In der Urzeit der Computerei passierte das alles in den USA. Und die Vereinigten Amerikaner haben seinerzeit wie üblich nicht über den Tellerrand geschaut, sondern ihren Zeichensatz an ihre Sprache angepasst (ASCII). Irgendwann „durften“ dann auch die Alliierten ran, und die Probleme kamen auf… dieser Zeit verdanken wir ISO-8859-1, WIN-1252 und wie sie alle heißen. Mittlerweile gibt es aber ja seit 30 Jahren Unicode, die Probleme sind also doch Schnee von gestern. Richtig?

PostgreSQL ist – aus guten Gründen – ein beliebtes Ziel für Migrationen. Und PostgreSQL ist von vorne bis hinten auf UTF-8 aufgestellt. Leider hat man es aber oft mit Altsystemen, Altdaten und Gammelcode zu tun, die irgendwie übernommen werden müssen.

So bestehen unfassbare Mengen an altem Perl-, Python-, PHP-, VBA-, … Code, der für frühe Access-, MySQL-, MS-SQL-, Oracle-, Sybase oder was auch immer für Datenbanken geschrieben wurde und mit Unicode nichts am Hut hat. (Einige dieser Systeme sind bis heute nicht wirklich gut darin…)

Gerne sind wir auch gezwungen, „Pseudo-CSV“ aus M$ Excel zu importieren (warum ist es „normal“, comma separated values mit Semikolon zu separieren?!?), und Microsoft tut sich bis heute immer noch schwer mit UTF-8.


~$ file importtest.win-1252.csv
importtest.win-1252.csv: ISO-8859 text, with CRLF line terminators

Betreiber solcher Software haben sich üblicherweise aus der Affäre gezogen, indem sie die Datenbank, auch bei Updates, immer wieder im alten, überholten Encoding betrieben haben. Jetzt steht also die Umstellung auf PostgreSQL an, und beim ersten Testimport von Altdaten kommt diese Meldung:


blog=# \COPY csvimport FROM importtest.win-1252.csv WITH (DELIMITER ';', FORMAT CSV);
ERROR: invalid byte sequence for encoding "UTF8": 0xfc
CONTEXT: COPY csvimport, line 1
blog=#

Viele Entwickler*innen werden jetzt reflexhaft ihre bewährte Methode benutzen wollen, und ja, ich kann, auch wenn mein DB-Cluster anders initialisiert wurde, genau das auch tun:


blog=# \h CREATE DATABASE
Command: CREATE DATABASE
Description: create a new database
Syntax:
CREATE DATABASE name
[ [ WITH ] [ OWNER [=] user_name ]
[ TEMPLATE [=] template ]
[ ENCODING [=] encoding ]
[ LOCALE [=] locale ]
[ LC_COLLATE [=] lc_collate ]
[ LC_CTYPE [=] lc_ctype ]
[ TABLESPACE [=] tablespace_name ]
[ ALLOW_CONNECTIONS [=] allowconn ]
[ CONNECTION LIMIT [=] connlimit ]
[ IS_TEMPLATE [=] istemplate ] ]

siehe auch hier.

Ah, da ist es ja, [ ENCODING [=] encoding ] als „Weg des geringsten Widerstands“. Dann ist das doch normal, oder nicht?! Ja, kann man so machen, ist dann nur kacke und man hat eine Top-Gelegenheit verpasst! Besser ist es, die Gelegenheit zu nutzen und hier und jetzt den Weg auf UTF-8 einzuleiten. Dafür reicht es, das client_encoding für den Import anzupassen:


blog=# SHOW client_encoding ;
client_encoding
-----------------
UTF8
(1 row)
blog=# SET client_encoding TO 'win-1252';
blog=# \COPY csvimport FROM importtest.win-1252.csv WITH (DELIMITER ';', FORMAT CSV);
blog=#

Gut! Das hat schonmal geklappt. Dann schauen wir doch mal, wie das in der Tabelle aussieht:


blog=# SELECT * FROM csvimport ;
id | spalte1 | spalte2
----+-----------------------------+----------------------------
1 | Dies ist eine ▒bliche Datei | [NULL]
2 | mit M▒ll von M$ Excel | [NULL]
3 | [NULL] | und leeren Spalten (w▒rg).
(3 rows)

Pfui bah! Genau das wollten wir doch vermeiden!!!

Alles ist gut, unser client_encoding ist ja noch kaputt:


blog=# RESET client_encoding;
blog=# SELECT * FROM csvimport ;
id | spalte1 | spalte2
----+-----------------------------+----------------------------
1 | Dies ist eine übliche Datei | [NULL]
2 | mit Müll von M$ Excel | [NULL]
3 | [NULL] | und leeren Spalten (würg).
(3 rows)

Und wenn das Refakturieren aller beteiligten Komponenten gerade nicht opportun ist, kann das client_encoding z.B. per Rolle (User) gesetzt werden:


blog=# CREATE ROLE legacy_import LOGIN;
blog=# ALTER ROLE legacy_import SET client_encoding TO 'win-1252';

Alles, was von dieser Rolle nun geschrieben wird, verarbeitet PostgreSQL nun intern zu UTF-8. Alles, was die Rolle liest, wird in WIN-1252 umgewandelt. Alle modernen Clients können aber mit Unicode arbeiten, so dass einer Transition statt einer reinen Migration jetzt „nur noch“ Code im Wege steht, keine Daten mehr.

P.S.: Es gibt natürlich noch weitere Möglichkeiten, das Encoding pro Client festzulegen, z.B. die Umgebungsvariable PGCLIENTENCODING.

 

Über den Autor:

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.
Lennart Betz
Lennart Betz
Senior Consultant
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.
Lies mehr von Lennart und triff unser Team

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

von | Okt 8, 2020 | , , ,

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.
Philipp Dorschner
Philipp Dorschner
Technical Service Manager
Nach seiner Ausbildung zum Fachinformatiker bei der NETWAYS Professional Services GmbH wuchs das Interesse an Development und organisatorischen Themen. Heute unterstützt Philipp die Kollegen aus PS-Services als hybrider Mitarbeiter. Fünfzig Prozent seiner Zeit als Technical Service Manager und die anderen fünfzig Prozent als interner Entwickler. Als Ausgleich zu seiner Arbeit im Büro verbringt er seine Freizeit meistens beim Sport oder trifft sich mit Freunden.
Lies mehr von Philipp und triff unser Team

Alle User in MySQL anzeigen

von | Aug 5, 2020 | , ,

Oftmals wachsen Datenbankinstallationen im Laufe der Zeit und man legt immer wieder für neue Projekte neue Datenbanknutzer an. Um hier den Überblick zu behalten, zeige ich kurz, wie man sich die jeweiligen Nutzer anzeigen lassen kann.

Voraussetzungen:

  • Command line/Terminal
  • MySQL oder MariaDB installiert
  • Benutzer in MySQL:Benutzer mit Sudo- oder Root-Rechten

Bei der Installation von MySQL wird bei der Installation als erster Benutzer der Root-Benutzer erstellt – der MYSQL-Administrator. Der Root-Benutzer ist berechtigt, alles in der MySQL-Datenbank zu tun – Eine einfache und zuverlässige Möglichkeit, die MySQL-Sicherheit zu erhöhen, besteht darin, Benutzer mit eingeschränkten Berechtigungsbeschränkungen für die Datenbank zu erstellen.

Wenn Sie Zugriff auf Ihren Server haben, müssen Sie die MySQL-Konsole aufrufen. Dafür benötigen wir Root-Rechte. Geben Sie dies in die Befehlszeile ein:

sudo mysql -u root -p

root@galeria-1:~# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 78
Server version: 10.4.13-MariaDB-1:10.4.13+maria~bionic-log mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

Dann müssen Sie Ihr MySQL-Root-Passwort eingeben. Es sollte sich vom System-Root-Passwort unterscheiden. Sobald Sie in der MySQL-Konsole root sind, können Sie Abfragen und Befehle ausführen. MySQL-Benutzer anzeigen: Jetzt können Sie alle Benutzer in MySQL mit dem folgenden MySQL-Befehl auflisten:

MariaDB [(none)]> SELECT user FROM mysql.user;
+-------------+
| User |
+-------------+
| mariadb.sys |
| mysql |
| root |
| testuser | 
+-------------+
4 rows in set (0.004 sec)
MariaDB [(none)]>

Trainings

Web Services

Events