MySQL/MariaDB Datenbank-Dienst

mysql -h mysql.hrz.tu-chemnitz.de -u datenbanknutzer -p datenbank

Service Level Agreement (SLA)

• Gegenstand
• Leistungsumfang
• Dienstbeauftragung
• Dienstnutzung
• Verfügbarkeit, Datensicherung und Wartung
• Probleme und Reaktionszeiten
• Laufzeiten, Änderung und Kündigung
• Gültigkeit

Diese Vereinbarung regelt den Umfang und die Bedingungen für die „Datenbank-Dienste“ zwischen dem Auftraggeber und dem URZ als Auftragnehmer.

Gegenstand

• Das URZ betreibt zentrale Datenbank-Server im Campusnetz, auf welchen Datenbanken von Auftraggebern angelegt und verwaltet werden und über die der Zugriff auf die Datenbanken möglich ist.
• Die Inanspruchnahme des Dienstes ist nur für dienstliche und ausbildungsbezogene Belange erlaubt. Eine private, insbesondere kommerzielle, Nutzung ist untersagt.
• Die Datenbank-Server sind durch die allgemein üblichen technischen Vorkehrungen vor missbräuchlichem Zugriff geschützt. Für Daten mit einem erhöhten Geheimhaltungsbedarf ist der Datenbank-Server nicht geeignet.

Leistungsumfang

• Das Erteilen eines Dienstauftrags bewirkt das Anlegen einer Datenbank für den Auftraggeber auf dem zentralen Datenbankserver.
• Außerdem werden die notwendigen Voraussetzungen für die ordnungsgemäße Nutzung der Datenbank getroffen.
• Die Verantwortung für den Inhalt und die Nutzung der Datenbank bleiben beim Auftraggeber.

Der Auftragnehmer erbringt insbesondere folgende Leistungen:

• Anlegen der Datenbank
• Anlegen der Datenbanknutzer-Accounts
• Einstellen der Zugriffsrechte
• regelmäßiges Sichern der Datenbank
• Gewährleisten eines sicheren und stabilen Betriebs des Datenbank-Servers

Dienstbeauftragung

• Beauftragen einer Datenbank erfolgt im IdM-Portal. Dabei werden die notwendigen Parameter zur Datenbank spezifiziert (Datenbankname, Laufzeit, etc.).
• Der Nutzer, der eine Datenbank anlegt, wird Eigentümer der Datenbank. Er ist zugleich Ansprechpartner für den Datenbank-Administrator des URZ.
• Eigentümer einer Datenbank ist eine Person mit gültigem Nutzerkennzeichen oder eine Nutzergruppe
• Eine Datenbank hat eine maximale Gültigkeit von 12 Monaten. Die Gültigkeitsdauer kann vom Datenbankeigentümer verlängert werden.
• Ein Auftraggeber kann über das Auftragsformular beliebig viele Datenbanken anlegen.

Dienstnutzung

• Innerhalb des Campusnetzes ist der Zugriff von allen Rechnern, auf denen eine Datenbank-Klientensoftware verfügbar ist, möglich.
• Ein Zugriff auf eine Datenbank von außerhalb des Campusnetzes der TU Chemnitz ist nur über den Webserver www.tu-chemnitz.de möglich (in Form einer Webapplikation), nicht über andere Datenbank-Klientensoftware.
• Die Konfiguration und Gültigkeit der Datenbanken kann von den Eigentümern im IdM-Portal modifiziert werden.
• Erfolgte nach Ablauf der Gültigkeit keine Verlängerung, wird die Ressource nach den aktuellen Aufbewahrungsrichtlinien des IdM-Portals gelöscht.
• Wenn der Eigentümer einer Datenbank mit seiner Anwendung die Funktionsfähigkeit des Datenbankservers massiv beeinträchtigt, sodass auch alle anderen Nutzer in ihrer Arbeit behindert werden, kann die betreffende Datenbank und/oder seine Anwendung gesperrt werden.

Verfügbarkeit, Datensicherung und Wartung

• Die Datenbank-Dienste sind rund um die Uhr in Betrieb (7x24).
• Die Verfügbarkeit der Datenbank-Dienste wird durch Monitoring-Software ständig überwacht.
• Alle Datenbanken werden täglich ab 02:00 Uhr gesichert.
  • Zum Zeitpunkt des Datenbankabzugs (s. o.) ist jede einzelne Datenbank kurzfristig zum Schreiben gesperrt, Lesezugriffe sind davon nicht betroffen.
  • Entsprechend der Beschreibung des Backup-Dienstes werden die Datenbank-Dumps maximal sechs Monate aufbewahrt.
  • Der Eigentümer einer Datenbank hat keinen Zugriff zu den Dumps, er kann einen solchen Dump also nicht selbst zurückstellen. Er muss dieses über den Helpdesk des URZ ( support@…) beantragen.
• Planmäßige Wartungsarbeiten werden angekündigt.

Probleme und Reaktionszeiten

• Bei Fragen, Problemen oder Störungen wenden Sie sich bitte grundsätzlich an den Support des URZ: support@…

Laufzeiten, Änderung und Kündigung

• Mit dem Löschen einer Datenbank im IdM-Portal endet die Dienstnutzung automatisch.
• Der Eigentümer oder die Eigentümergruppe wird 1 Monat vor Ablauf der Gültigkeit einer Datenbank über den bevorstehenden Status per E-Mail informiert.
• Nach Ablauf der Gültigkeit wird der Zugriff auf die Datenbank gesperrt.
• 90 Tage nach Ablauf der Gültigkeit wird die Datenbank gelöscht.
• Scheidet der Eigentümer einer Datenbank aus der TU Chemnitz aus (Exmatrikulation bzw. Beendigung des Beschäftigungsverhältnisses) und soll die Datenbank erhalten bleiben, muss eine Übergabe erfolgen.

Gültigkeit

• Dieses Service Level Agreement wird mit seiner Veröffentlichung wirksam. Es gilt bis zu einer neueren Fassung, die sich durch geänderte Randbedingungen (z. B. durch hard- und softwaretechnische Veränderungen) ergeben kann.

FAQ – Häufig gestellte Fragen

• Was bietet mir der Datenbank-Service des URZ?
• Warum muss ich eine Gültigkeitsdauer angeben? Ich weiß doch noch nicht, wie lange ich die Datenbank benötige ...
• Warum wird das Passwort für meine Datenbanknutzer nicht akzeptiert?
• Wie kann ich nun mit meiner angelegten Datenbank arbeiten?
• Der Zugriff zu meiner Datenbank funktioniert nicht (mehr), möglicherweise habe ich das Passwort vergessen - was kann ich tun?
• Wo finde ich Informationen zu MySQL?
• Wie kann ich eine verschlüsselte Verbindung zum MySQL-Server aufbauen?

Was bietet mir der Datenbank-Service des URZ?

Jede(r) Angehörige der Universität kann sich mit diesem Dienst von seinem Arbeitsplatz aus eine MySQL-Datenbank zur eigenen Verwendung anlegen lassen. Er oder sie muss sich dabei um keinerlei technische Details kümmern („Auf welcher Platte ist genügend Platz für meine Datenbank?, „Welcher Rechner wäre dazu geeignet, welche Zugriffsrechte müssen eingestellt werden?“, „Wie geht das alles?“). Das erledigt dieser Dienst automatisch nach entsprechenden Anwendervorgaben. Das Erzeugen und Füllen der Datenbanktabellen müssen Dienstnutzende allerdings weiterhin selbst durchführen.

Dabei ist noch zu beachten:

• Die Inanspruchnahme dieses Dienstes ist nur für dienstliche und ausbildungsbezogene Belange erlaubt. Eine private, insbesondere kommerzielle, Nutzung ist untersagt.
• Voraussetzung für die Nutzung des Dienstes ist ein gültiges URZ-Nutzerkennzeichen. Dieses erhalten Sie bei Bedarf im Nutzerservice des URZ.

Warum muss ich eine Gültigkeitsdauer angeben? Ich weiß doch noch nicht, wie lange ich die Datenbank benötige ...

Es ist leider sehr menschlich, dass die Rückgabe von Ressourcen sehr oft vergessen wird, wenn das Projekt oder die Dinge selbst nicht mehr benötigt werden. Deshalb schützen wir uns mit der Definition eines zeitlichen Limits davor, mittelfristig nur noch „Müll“ zu verwalten.

Nach Ablauf des festgelegten Gültigkeitszeitraums kann der Verantwortliche für eine Datenbank natürlich die Gültigkeit verlängern - und das so oft wie gewünscht. In jedem Fall ist eine Aktivität des Nutzers notwendig, mit der er indirekt bestätigt, dass die Ressourcen auch wirklich noch in Benutzung sind.

Warum wird das Passwort für meine Datenbanknutzer nicht akzeptiert?

Wir haben uns aus Sicherheitsgründen dafür entschieden, die Passworte der Datenbanknutzer nach den gleichen Verfahren auf Nicht-Einfachheit zu prüfen, wie das mit den Passworten der Nutzerkennzeichen erfolgt. Deshalb müssen unter anderem folgende Regeln beachtet werden (siehe auch Hinweise zur Wahl des Passworts):

• Ein Passwort ist mindestens acht Zeichen lang und enthält:
  • Sonderzeichen
  • gemischte Groß-/Kleinschreibung
  • Ziffern
• Es sollte nicht bestehen aus:
  • Namen (Vornamen, Familiennamen, Eigennamen, Produktnamen, …), auch nicht in veränderter Schreibweise (gemischte Gross-/Kleinschreibung, rückwärts, angehangene/eingemischte Ziffern, …)
  • Worten, die in Wörterbüchern (auch fremdsprachigen) vorkommen können
  • Informationen, die mit Ihrer Person zusammenhängen (Geburtsdatum, Name der/des Frau/Mannes, Freundin/Freundes, Oma/Opas, Wohnort, bevorzugte Urlaubsorte/-gegenden, bevorzugte Getränke/Speisen …)
• Am besten eignen sich die Anfangsbuchstaben von leicht zu merkenden Sätzen: (Diese Beispiele bitte nicht verwenden, sie dienen nur der Veranschaulichung.)
  • NsvmPzk! (Niemand sollte versuchen mein Passwort zu knacken!)
  • ..,-fidM (Punkt, Punkt, Komma, Strich, fertig ist das Mondgesicht)
  • MmKla4sk (Man müsste Klavier spielen können)
• Sonderzeichen, die nur durch Fingerakrobatik auf der Tastatur zu erreichen sind bzw. erst nach Umstellen des Tastaturtreibers zur Verfügung stehen (bei einigen Systemen ist die Tastatur zum Login-Zeitpunkt anders belegt als während der Arbeit mit dem System), sollten nicht verwendet werden. Dazu gehören insbesondere 'ä', 'ö', 'ü', 'ß', 'Ä', 'Ö', 'Ü', '#', ':', '~', '@', '\' und das Leerzeichen.

Wie kann ich nun mit meiner angelegten Datenbank arbeiten?

Dazu gibt es verschiedene Möglichkeiten:

neben dem Kommandozeilenklienten (mysql [optionen]) empfehlen wir vor allem die Webschnittstelle phpMyAdmin.

Der Zugriff zu meiner Datenbank funktioniert nicht (mehr), möglicherweise habe ich das Passwort vergessen - was kann ich tun?

Die Passworte der Datenbanknutzer werden innerhalb des MySQL-Systems nur verschlüsselt abgespeichert, d. h. auch bei bestem Willen kann der Datenbankadministrator kein Passwort eines Datenbanknutzers verraten. Es besteht in diesem Fall nur die Möglichkeit, ein neues Passwort zu setzen – allerdings kann das nur der Administrator nutzen. Wenden Sie sich bitte per E-Mail an unseren Helpdesk: support@…. Alles Weitere wird dann inviduell vereinbart.

Wo finde ich Informationen zu MySQL?

Auf der Webseite des Datenbank-Service des URZ sind entsprechende Links gesammelt.

Wie kann ich eine verschlüsselte Verbindung zum MySQL-Server aufbauen?

Der gegenwärtig installierte MySQL-Server (>=Version 5) ist für SSL-Verbindungen vorbereitet (sowohl „SSL“ als auch „OpenSSL“). Damit auch auf der Klientenseite die Verschlüsselung aktiv ist, muss der mysql-Klient mit der Option --ssl-ca=/etc/pki/tls/certs/ca-bundle.crt gestartet werden.

SQL-Statements korrekt schreiben

Nicht vollständige oder unrichtige Einträge in Datenbanken haben ihre Ursache häufig in syntaktisch unkorrekten SQL-Statements beim Eintragen (Datenbank-Transaktionen). Auf solche Fehler reagiert heute verbreitete Datenbankserver-Software unterschiedlich, mitunter sogar abhängig von der jeweiligen Software-Version. Üblicherweise folgen eine Fehlermeldung und der sofortige Abbruch, aber auch eine Ausführung „nach bestem Wissen und Gewissen” trotz Syntaxfehler in der Transaktion ist denkbar.

Letzteres Verhalten ist natürlich besonders tückisch, weil zwar „irgendetwas“ in die Datenbank eingetragen wird, aber möglicherweise nicht das Richtige. Programmierer oder Programmiererin sind aber der Meinung, dass der gewünschte Eintrag in die Datenbank so wie gedacht erfolgte, da ja keine Fehlermeldung angezeigt wurde.

Ein Beispiel für ein versionsabhängiges Verhalten ist die Datenbank-Software MariaDB: Ab der Version 10.2.4 wurde auf dem Datenbankserver der SQL-Modus STRICT_TRANS_TABLES standardmäßig aktiviert. Dadurch bewirken Syntaxfehler in Datenbanktransaktionen, wie zum Beispiel INSERT oder UPDATE, nun Fehlermeldungen und Abbruch, während der Datenbankserver in den Vorgängerversionen häufig versuchte, solche Statements mit „best effort“ auszuführen.

Eine anschauliche Beschreibung des Problems inklusive einleuchtender Beispiele bietet der Artikel eines Braunschweiger Bloggers.

Was bedeutet das nun für den Programmierer?

Die generelle Empfehlung lautet: Bitte halten Sie sich strikt an den (My)SQL-Standard!

Dazu gehören zum Beispiel folgende Maßnahmen (Checkliste):

• Achten Sie bei INSERT- oder UPDATE-Operationen immer darauf, die korrekten Datentypen zu verwenden und bei Zuweisungen an Felder die Feldlänge zu beachten.
• Ordnen Sie bei INSERT-Operationen allen Spalten einen Wert zu, sofern Sie bei der Spaltendefinition keinen Standardwert angegeben haben.
  • Alternativ können Sie beim Erzeugen einer Tabelle mit CREATE TABLE … allen Spalten der Tabelle einen entsprechenden Standardwert zuordnen.
• Aufgepasst beim „Datumsformat mit Zeitzone“: Dieses Datumsformat war schon immer ungültig (Beispiel: '2019-11-13T07:09:10+0200'), jedoch hat der alte nicht standardkonforme SQL-Modus einfach die Zeitzone abgeschnitten und ignoriert. Mit aktiviertem STRICT_TRANS_TABLES werden solche Datumsformate nicht mehr vom Server akzeptiert. Bitte setzen Sie das Datumsformat immer in der Zeitzone, die Sie für die aktuelle SQL-Sitzung eingestellt haben (SESSION.time_zone).

Im Folgenden wird ein praktisches Szenario gezeigt, das so mit deaktiviertem STRICT_TRANS_TABLES funktionieren würde, mit aktiviertem aber nicht mehr! Bitte fassen Sie dieses tatsächlich als Beispiel auf - man kann daran nicht alle denkbaren Situationen darstellen, die bei aktiviertem STRICT_TRANS_TABLES-Mode eintreten können. Aber es zeigt typische Verhaltensweisen und gibt hilfreiche praktische Hinweise für die Programmierung eigener Datenbank-Anwendungen.

Zunächst erzeugen wir eine Tabelle mit vier Spalten; nur die Spalte vorname erhält einen Defaultwert zugewiesen:

CREATE TABLE kontaktliste
(
  id INT NOT NULL AUTO_INCREMENT,
  name VARCHAR (16),
  vorname VARCHAR (16) DEFAULT NULL,
  abteilung INT,
  PRIMARY KEY (id)
);

Soll anschließend zum Beispiel ein INSERT (nur) für das Feld name erfolgen, genügt es, nur diesem Feld einen Wert zuzuweisen:

INSERT INTO kontaktliste SET name="Berger";
               // Klappt, da für vorname beim create table . . . , für abteilung vom Server ein Default gesetzt

Großzügig: Der MariaDB-Server kompensiert unsere Nachlässigkeit und trägt, da nichts angegeben wurde, für die Spalte abteilung einen Default-Wert ein. Dankeschön ;)

Nun erzeugen wir einen weiteren Eintrag, bei dem das Feld name einen zu langen Eintrag (mehr als 16 Zeichen) erhält:

INSERT INTO kontaktliste SET name="Müller-Lüdenscheidt", vorname="Annette", abteilung=4;
               // funktioniert scheinbar, wobei nur 16 Zeichen des Namens eingetragen werden! :-(

Es funktioniert, aber der einzutragende Name wird einfach nach 16 Zeichen "abgeschnitten", denn wir hatten für das Feld name eine Länge von 16 Zeichen vereinbart. Ein Blick in die Datenbank bestätigt uns das:

SELECT * FROM kontaktliste;
+----+------------------+---------+-----------+
| id | name             | vorname | abteilung |
+----+------------------+---------+-----------+
|  1 | Berger           |         |         0 |
|  2 | Müller-Lüdensche | Annette |         4 |
+----+------------------+---------+-----------+

Dieses Verhalten ist sogar schlecht, weil der Programmierer davon ausgeht, dass alles geklappt hat, denn er erhält ja keinen Fehler. Stattdessen steht die einzutragende Zeichenkette zwar in der Datenbank, aber leider unvollständig.

Als Nächstes durchlaufen wir das gleiche Szenario noch einmal, aber mit aktiviertem STRICT_TRANS_TABLES-Mode. Die strengere SQL-Syntaxprüfung bewirkt Folgendes:

INSERT INTO kontaktliste SET name="Berger";
  ERROR 1364: Field ‚abteilung‘ doesn’t have a default value
               // Klappt nicht: insert unvollständig, denn für abteilung wird ein Default benötigt!

Der Server schimpft nun korrekterweise: Wir haben vorname nirgends einen Default-Wert gegeben. Und mit aktiviertem STRICT_TRANS_TABLES ist der Server auch nicht mehr nachsichtig mit uns, insofern, dass er den Default automatisch setzt!

Gehen wir weiter zur zweiten Anweisung:

INSERT INTO kontaktliste SET name="Müller-Lüdenscheidt", vorname="Annette", abteilung=4;
  ERROR 1406: Data too long for column 'name' at row 1
               // Aha! Nun weigert sich der Server, den zu langen Namen einzutragen.

Tatsächlich streikt jetzt der Server und trägt die Zeichenkette mit 19 Zeichen Länge nicht in das Feld mit erlaubten 16 Zeichen ein. Recht hat er.

Fazit: Der STRICT_TRANS_TABLES-Mode sorgt dafür, dass Unexaktheiten in der SQL-Syntax sofort bemerkt werden. Das kann im Einzelfall sogar wünschenswert sein, wie man am Beispiel mit dem Eintragen einer zu langen Zeichenkette gesehen hat.

Indem man einfach korrekte SQL-Statements verwendet, ist das Problem leicht zu umgehen. Erinnern Sie sich bitte an die oben aufgeführte Checkliste. Unser Beispiel müssen wir somit nur ein klein wenig ändern, und schon klappt alles:

CREATE TABLE kontaktliste
(
  id INT NOT NULL AUTO_INCREMENT,
  name VARCHAR (64) DEFAULT NULL,            // alle Spalten erhalten DEFAULT Wert, und
  vorname VARCHAR (64) DEFAULT NULL,         // Felder name und vorname mit Länge von 64 Zeichen 
  abteilung INT DEFAULT 0, 
  PRIMARY KEY (id)
);

Wir haben den Feldern eine ausreichende Länge und allen Spalten einen Default-Wert gegeben. Alternativ kann man den/die Default-Wert(e) in den (späteren) INSERT- oder UPDATE-Operationen setzen. Nachteil: Sie müssen dann bei jedem(!) INSERT/UPDATE daran denken. Wie auch immer - nun funktionieren die beiden INSERTs aus unserem Beispiel perfekt. That's it.