MariaDB bei PC CADDIE — einfach erklärt

Handout für Techniker · Themenblock: MariaDB installieren und konfigurieren
💡 So funktioniert diese Seite: Links navigieren · jeder Befehl hat einen Kopieren-Knopf · Checkliste und Schritte lassen sich abhaken (bleibt beim Schließen erhalten) · in der Übung ist die Lösung erst nach Klick sichtbar · Dunkelmodus in der Seitenleiste. Neu: 📝 Notizfelder an jedem Schritt — und unter 💾 Export & Sichern alles als Datei sichern, als Protokoll kopieren oder als Handout mit euren Notizen exportieren.

Worum geht es überhaupt?

Heute (DBF-Dateien): PC CADDIE speichert alles in vielen einzelnen Dateien im DATEN-Ordner. Jeder Client greift über die Netzwerkfreigabe direkt auf diese Dateien zu.

Bild: Alle greifen selbst in denselben Aktenschrank. Wenn zwei gleichzeitig ziehen, klemmt es — kaputte Indexdateien, Reorganisieren nötig, langsam bei vielen Benutzern.

Morgen (MariaDB): Auf dem Server läuft ein Programm, das die Daten ganz allein verwaltet: der Datenbank-Dienst. Niemand fasst die Dateien mehr direkt an. Alle Clients stellen ihre Fragen über das Netzwerk an diesen Dienst.

Bild: Es gibt jetzt einen Bibliothekar. Nur er geht an den Schrank. Man klingelt bei ihm (Port 3306), nennt Name und Passwort, und er holt die Daten. Zwei gleichzeitig? Kein Problem — er regelt das.

Was sich für uns Techniker dadurch ändert:

Bisher (DBF)Künftig (MariaDB)
Client brauchtZugriff auf die DateifreigabeNetzwerkverbindung zum Dienst (TCP 3306) + Benutzer/Passwort
Bei Stromausfalloft kaputte IndexeDatenbank repariert sich selbst
BackupDateien kopierenDateien kopieren ist jetzt FALSCH (→ Stolperfallen)
Wenn es klemmtReorg laufen lassenError Log lesen, Dienst prüfen

Die zwei wichtigsten Dateien — nicht verwechseln

my.inipcc_path.ini
gehört zuMariaDB (dem Server)PC CADDIE (dem Client)
regeltwie der Bibliothekar arbeitet: Datenordner, Port, wer rein darf, Speicher, Zeichensatz, Logswie PC CADDIE den Bibliothekar findet: Servername, Port, Datenbank, Benutzer, Passwort
wird gelesen vonMariaDB-Dienst beim StartPC CADDIE beim Start
liegtbeim Server (Dienst zeigt mit --defaults-file darauf)im DATEN-Ordner
wenn sie fehltDienst läuft mit Werkseinstellungen weiterPC CADDIE findet die Datenbank nicht

Warum die my.ini kaum jemand kennt: Der Installer legt sie still selbst an (meist im data-Ordner) und trägt sie beim Dienst ein. Und bei DBF gab es schlicht keinen Server, den man einstellen musste. Einzige Berührung der beiden Dateien: Der Port muss in beiden derselbe sein, und host muss zur bind-address passen.

Die fünf Merksätze

  1. Zwei Schlösser: bind-address UND Firewall — beide müssen offen sein.
  2. „Access denied“ ist ein gutes Zeichen — der Netzwerkweg steht schon.
  3. SHOW VARIABLES glauben, nicht der ini-Datei (--defaults-file-Falle).
  4. Eine laufende Datenbank kopiert man nicht — Backup nur mit Werkzeug.
  5. Bei Fehlern immer zuerst das Error Log — raten kostet Stunden.

Bevor es losgeht: das Terminal

Wie man startet, wo man Befehle eingibt — und die zwei Eingabe-Welten

Für diesen Lernweg gibt es kein Setup zum Doppelklicken. Alle Schritte laufen bewusst von Hand im Terminal — nur so versteht man, was passiert. (Beim Kunden erledigt das später das Skript bzw. das Makro aus PC CADDIE. Nur die Dienst-Steuerung hat auch einen Klick-Weg: services.msc, siehe Schritt 5.)

So wird gestartet

  1. Windows-Taste drücken, powershell tippen.
  2. Rechts auf „Als Administrator ausführen“ klicken (oder Rechtsklick → Als Administrator ausführen).
  3. Die Nachfrage der Benutzerkontensteuerung mit Ja bestätigen.
  4. Es öffnet sich ein Fenster mit einer Zeile wie PS C:\Windows\system32> und einem blinkenden Cursor. Das ist die Eingabezeile.

Wichtig: Wir nutzen PowerShell, nicht die alte „Eingabeaufforderung“ (cmd). Alle Befehle hier sind für PowerShell geschrieben.

Woran erkennt man Administrator? Im Fenstertitel steht „Administrator: …“. Ohne Admin-Rechte scheitern Dienst-, Firewall- und Program-Files-Befehle mit „Zugriff verweigert“.

Befehle ausführen

Befehl hier per Kopieren-Knopf holen, im PowerShell-Fenster Rechtsklick (fügt ein) oder Strg+V, dann Enter.

Ganze Blöcke auf einmal? Ja! Alle Befehlsblöcke sind so gebaut, dass man sie komplett einfügen kann — die Zeilen laufen automatisch nacheinander. Drei Regeln dazu:

  1. Nach dem Einfügen einmal Enter — die letzte Zeile wartet oft noch darauf.
  2. Fragt ein Befehl nach einem Passwort (Enter password:), endet der Block dort absichtlich — Passwort von Hand tippen. (Deshalb steht so ein Befehl hier immer als letzte Zeile eines Blocks.)
  3. Kommt eine rote Meldung: erst lesen und beheben — die restlichen Zeilen sind trotzdem weitergelaufen.

Auch die SQL-Blöcke dürfen komplett ins MariaDB [(none)]>-Fenster eingefügt werden — inklusive exit am Ende.

Vier Kleinigkeiten, die alles leichter machen:

  • cd "C:\Ordner" wechselt in einen Ordner („change directory“). Wo man gerade steht, zeigt der Text vor dem >.
  • .\programm.exe heißt: „Starte das Programm aus dem Ordner, in dem ich gerade stehe.“ Das .\ gehört wirklich dazu.
  • Pfeiltaste ↑ holt den letzten Befehl zurück (praktisch bei Tippfehlern).
  • Tab-Taste vervollständigt Datei- und Ordnernamen automatisch.

Keine Angst vor Tippfehlern: Ein falscher Befehl gibt eine rote Fehlermeldung — mehr passiert nicht.

Die ZWEI Eingabe-Welten

PowerShellmariadb-Client
FürWindows-Befehle: Dienst, Dateien, FirewallSQL-Befehle an die Datenbank
EingabezeilePS C:\...>MariaDB [(none)]>
ReinWindows-Taste → powershell (als Admin)aus PowerShell heraus .\mariadb.exe -u root -p
RausFenster schließenexit + Enter → zurück in PowerShell
Besonderheit—jeder SQL-Befehl endet mit Strichpunkt ;

Deshalb trägt jeder Befehl ein Etikett: [PowerShell als Admin — Server] [mariadb-Client — Server] [PowerShell — zweiter PC]. Ein Befehl im falschen Fenster gibt nur eine Fehlermeldung — der häufigste Anfängerstolperer.

Übungspfade

An den Standard aus Installations-Skript V2 angelehnt; liegt die ZIP-Datei woanders, Pfad anpassen:

WasPfad
ZIP-DateiC:\mariadb\mariadb-11.8.6-winx64.zip
ProgrammC:\Program Files\MariaDB
Datenordner (DATADIR)C:\PCCADDIE_MDB\MARIADB\data
DATEN-Ordner (für pcc_path.ini)C:\PCCADDIE_MDB\DATEN
DienstnameMariaDB-PCC

Wo Geheim-123 steht: durch ein echtes Passwort ersetzen (für die Übung ohne Leerzeichen und ohne Anführungszeichen). Vor dem Start auf einer Übungs-VM: Snapshot anlegen — dann ist jeder Zustand in einer Minute zurückgeholt.

Installation Schritt für Schritt

Mit allen Befehlen zum Kopieren — Haken setzen, wenn ein Schritt sitzt
0 von 12 erledigt

Schritt 1 — Vorher schauen

Ist schon eine MySQL/MariaDB da (Kassensysteme bringen oft eine mit)? Ist Port 3306 frei? Erst schauen, dann installieren — sonst zerschießt man womöglich die Software eines anderen Herstellers.

[PowerShell als Admin — Server] 
Get-Service | Where-Object { $_.Name -match 'maria|mysql' }
netstat -ano | findstr :3306

Was soll rauskommen: Beide Befehle geben nichts zurück. Nichts = frei = gut. Kommt etwas zurück: stoppen und klären (→ Offene Frage 3.1).

Schritt 2 — Programm auf den Server bringen

Das ZIP entpacken und das Programm nach Program Files legen (1–2 Minuten).

[PowerShell als Admin — Server] 
Expand-Archive "C:\mariadb\mariadb-11.8.6-winx64.zip" -DestinationPath "C:\temp\mdb"
New-Item -ItemType Directory "C:\Program Files\MariaDB" -Force
Copy-Item "C:\temp\mdb\mariadb-11.8.6-winx64\*" "C:\Program Files\MariaDB\" -Recurse

Was soll rauskommen: Keine roten Meldungen. Danach existiert C:\Program Files\MariaDB\bin mit u. a. mariadbd.exe (Server — das „d“ steht für Dienst) und mariadb.exe (Client).

Kontrolle (muss True ausgeben):

Test-Path "C:\Program Files\MariaDB\bin\mariadbd.exe"

C:\temp\mdb wird danach nicht mehr gebraucht und kann am Ende gelöscht werden.

Schritt 3 — Die Hausordnung verstehen (my.ini)

Die my.ini ist die wichtigste Datei der ganzen Installation. Sie sagt dem Dienst: wo die Daten liegen (datadir) · auf welcher Klingel er hört (port) · wer klingeln darf (bind-address) · welche Schrift er kann (utf8mb4 für ä ö ü ß) · wie viel Arbeitsspeicher er nutzen darf (innodb_buffer_pool_size) · wohin er sein Tagebuch schreibt (Error Log).

Das ist der Hausordnungs-Block — noch nirgends eintragen, nur bereithalten. Wohin er gehört, klärt Schritt 6, denn der Installationsbefehl in Schritt 4 legt selbst schon eine my.ini an — und nur die Datei zählt, auf die der Dienst wirklich zeigt.

[mysqld]
datadir=C:/PCCADDIE_MDB/MARIADB/data
port=3306
bind-address=0.0.0.0
character-set-server=utf8mb4
collation-server=utf8mb4_general_ci
innodb_buffer_pool_size=2G
log_error=C:/PCCADDIE_MDB/MARIADB/data/mariadb-error.log
slow_query_log=1
slow_query_log_file=C:/PCCADDIE_MDB/MARIADB/data/mariadb-slow.log
long_query_time=2
  • Pfade mit normalen Schrägstrichen / schreiben — Backslash wird hier falsch verstanden.
  • Datei ohne BOM speichern (BOM = unsichtbares Sonderzeichen mancher Editoren am Dateianfang). Notepad macht es automatisch richtig.
  • 2G passt für eine Übungs-VM ab 8 GB RAM. Beim Kunden gilt die RAM-Staffel (→ Standards) — auf Terminalservern deutlich weniger!

Schritt 4 — Datenordner und Dienst anlegen

Ein Befehl erledigt drei Dinge: Datenordner mit Systemtabellen erzeugen, Windows-Dienst MariaDB-PCC registrieren, root-Passwort setzen. (Ein Dienst ist ein Programm, das Windows beim Hochfahren von selbst startet — niemand muss angemeldet sein.)

[PowerShell als Admin — Server] 
New-Item -ItemType Directory "C:\PCCADDIE_MDB\MARIADB" -Force
cd "C:\Program Files\MariaDB\bin"
.\mariadb-install-db.exe --datadir="C:\PCCADDIE_MDB\MARIADB\data" --service=MariaDB-PCC --password=Geheim-123

Die erste Zeile legt die Überordner an — wichtig, denn mariadb-install-db.exe erzeugt nur den letzten Ordner (data) selbst, nicht die Zwischenordner. Fehlen sie: FATAL ERROR: Can't create data directory ... (one or more intermediate directories do not exist).

Was soll rauskommen: Mehrere Meldungszeilen, keine mit ERROR. Danach existiert der Datenordner — und darin bereits eine automatisch erzeugte my.ini (merken für Schritt 6!).

root bekommt dabei übrigens zwei Anmeldewege: das Passwort und die lokale „Windows-Anmeldung“ — Details in Schritt 6.

Hinweis: Der Befehl darf nur einmal erfolgreich laufen. Ein Abbruch mit FATAL ERROR zählt nicht — dann wurde nichts angelegt, nach der Korrektur einfach erneut ausführen. Nach einem erfolgreichen Lauf gilt: VM-Snapshot zurückspielen statt reparieren.

Schritt 5 — Dienst starten, stoppen, Autostart

[PowerShell als Admin — Server] 
Start-Service MariaDB-PCC
Get-Service MariaDB-PCC
Set-Service MariaDB-PCC -StartupType Automatic

Was soll rauskommen: Status: Running. Die dritte Zeile sorgt dafür, dass der Dienst nach jedem Neustart von selbst wieder läuft.

So steuert man ihn (jetzt und später im Support):

Stop-Service MariaDB-PCC      # Dienst beenden
Start-Service MariaDB-PCC     # Dienst starten
Restart-Service MariaDB-PCC   # neu starten (nach jeder my.ini-Änderung!)

Wer lieber klickt: Windows-Taste → services.msc → Enter → MariaDB-PCC suchen → Rechtsklick → Starten/Beenden/Neu starten.

Wenn der Dienst nicht startet: nicht raten — Tagebuch lesen:

Get-Content "C:\PCCADDIE_MDB\MARIADB\data\*.err" -Tail 40

(Der Stern findet die Logdatei auch, solange sie noch nach dem Rechnernamen benannt ist.) Dort steht fast immer der Grund: Tippfehler in der my.ini, Ordner fehlt, Port belegt.

Kommt stattdessen eine rote Meldung „kein Objekt vorhanden“: Es gibt noch gar keine Logdatei — der Dienst ist nie angelaufen. Dann ins Windows-Ereignisprotokoll schauen:

Get-EventLog -LogName Application -Source MariaDB* -Newest 10

Schritt 6 — Die richtige my.ini finden, Hausordnung eintragen, beweisen dass sie gilt

An diesem Schritt scheitern die meisten — deshalb ausführlich.

Das Problem: Auf einem Server können mehrere my.ini-Dateien herumliegen. Der Dienst liest aber nur eine. Ändert man die falsche, passiert — gar nichts. Keine Fehlermeldung, die Änderung wirkt einfach nicht.

Die Lösung: Am Dienst klebt ein „Zettel“, der sagt, welche Datei er liest. Den Zettel ansehen:

[PowerShell als Admin — Server] 
sc.exe qc MariaDB-PCC

(Wirklich sc.exe mit .exe tippen — das nackte sc ist in PowerShell ein ganz anderer Befehl.)

SERVICE_NAME: MariaDB-PCC
        ...
        BINARY_PATH_NAME : "C:\Program Files\MariaDB\bin\mariadbd.exe"
                           "--defaults-file=C:\PCCADDIE_MDB\MARIADB\data\my.ini"
                           "MariaDB-PCC"

Die Zeile BINARY_PATH_NAME ist der Zettel. Entscheidend: --defaults-file=... — genau DAS ist die Datei, die der Dienst liest. Alle anderen my.ini-Dateien sind ihm egal.

  • Fall A — --defaults-file steht da (Normalfall nach Schritt 4): diese Datei öffnen und die Hausordnung dort eintragen.
  • Fall B — keins da: Der Dienst sucht an Standardorten; in der Praxis nimmt er C:\Program Files\MariaDB\my.ini. Die Datei dann dort anlegen (Notepad fragt „Datei erstellen?“ → Ja).

Datei öffnen (den Pfad aus der eigenen sc-Ausgabe verwenden!):

notepad "C:\PCCADDIE_MDB\MARIADB\data\my.ini"

Den [mysqld]-Abschnitt so umbauen, dass er aussieht wie der Hausordnungs-Block aus Schritt 3. Regeln: nur ein Abschnitt [mysqld] · jede Einstellung nur einmal (bei Doppelung gewinnt die letzte Zeile) · speichern (Strg+S), schließen.

Eine my.ini-Änderung wirkt erst nach einem Dienst-Neustart — der Bibliothekar liest die Hausordnung nur beim Arbeitsbeginn:

Restart-Service MariaDB-PCC

Jetzt der Beweis. Nicht der Datei glauben, sondern den laufenden Dienst fragen. Dazu in die zweite Welt wechseln, den mariadb-Client:

cd "C:\Program Files\MariaDB\bin"
.\mariadb.exe -u root -p

(-u root = als Benutzer root anmelden, -p = nach dem Passwort fragen.) Es erscheint Enter password: — Passwort tippen, Enter. Beim Tippen erscheint nichts, auch keine Sternchen — normal. Danach wechselt die Eingabezeile zu MariaDB [(none)]>.

Windows-Überraschung: Lokal kommst du hier oft auch ohne Passwort rein (einfach Enter drücken). Kein Bug: Seit MariaDB 10.11 hat root auf Windows zwei Türen — das Passwort oder die „Windows-Anmeldung“ (GSSAPI). Wer lokal als der Windows-Admin angemeldet ist, der installiert hat, wird ohne DB-Passwort durchgelassen. Übers Netzwerk gilt das nicht — dort zählt das Passwort. Nachschauen:

SHOW CREATE USER 'root'@'localhost';

Steht dort ... OR gssapi, ist die zweite Tür aktiv. Behalten (praktisch für den Support vor Ort — man kommt am Server immer rein) oder abschalten (streng, nur noch Passwort: ALTER USER 'root'@'localhost' IDENTIFIED BY 'Geheim-123';) — das entscheidet Standards-Punkt 2 beim Treffen.

[mariadb-Client — Server] 
SHOW VARIABLES LIKE 'datadir';
SHOW VARIABLES LIKE 'port';
SHOW VARIABLES LIKE 'bind_address';
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
exit
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| character_set_server | utf8mb4 |
+----------------------+---------+

Vergleichen: datadir = unser Pfad? port = 3306? bind_address = 0.0.0.0? character_set_server = utf8mb4? Buffer Pool in Bytes (2147483648 = 2 GB). Stimmt alles → die Hausordnung gilt bewiesenermaßen. Stimmt etwas nicht → falsche Datei erwischt → zurück zu sc.exe qc.

Schritt 7 — Datenbank „pcc“ und Benutzer anlegen

Die Datenbank ist das Regal für PC CADDIE. Dazu ein eigener Benutzer — besser als der Generalschlüssel root (→ Standards, Punkt 2). Wieder in den mariadb-Client (.\mariadb.exe -u root -p), dann:

[mariadb-Client — Server] 
CREATE DATABASE pcc CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'pccuser'@'%' IDENTIFIED BY 'Geheim-456';
GRANT ALL PRIVILEGES ON pcc.* TO 'pccuser'@'%';
FLUSH PRIVILEGES;
SHOW DATABASES;
exit

Übersetzt: Regal pcc anlegen · Benutzer pccuser anlegen · ihm alle Rechte nur am Regal pcc geben (pcc.* = alle Tabellen darin) · Rechte sofort übernehmen · zur Kontrolle alle Regale anzeigen.

Was soll rauskommen: nach jedem Befehl Query OK; SHOW DATABASES listet u. a. pcc. Das '%' heißt „darf von jedem Rechner aus kommen“ — bei reinen Terminalservern wäre 'localhost' die sicherere Wahl.

Schritt 8 — Tür fürs Netzwerk öffnen: ZWEI Schlösser

  1. bind-address — hört der Dienst überhaupt nach draußen? (127.0.0.1 = nur der Server selbst, 0.0.0.0 = alle Netzwerkkarten). Steht in der Hausordnung bereits auf 0.0.0.0.
  2. Windows-Firewall — lässt sie Anrufer auf Port 3306 durch? Regel anlegen:
[PowerShell als Admin — Server] 
New-NetFirewallRule -DisplayName "MariaDB PC CADDIE (3306)" -Direction Inbound -Protocol TCP -LocalPort 3306 -Action Allow -Profile Domain,Private

Was soll rauskommen: ein Block mit Regeldaten, Enabled: True. (Warum nur Domäne+Privat → Netzwerk & Firewall, Profil-Falle.)

Dann prüfen, dass der Dienst wirklich nach draußen lauscht:

netstat -ano | findstr :3306

Was soll rauskommen: 0.0.0.0:3306 mit ABHÖREN (bzw. LISTENING). Steht dort 127.0.0.1:3306 → Dienst hört nur nach innen → bind-address prüfen, Dienst neu starten.

Hinweis IPv6: 0.0.0.0 heißt „alle IPv4-Adressen“. Zeigt netstat stattdessen [::]:3306, lauscht der Dienst über IPv6 — das passiert, wenn bind-address fehlt oder auf * steht. Auch damit kommen Clients an; nur nicht wundern.

Beide Schlösser müssen offen sein. Eines vergessen = „geht nicht“, und man sucht am falschen.

Schritt 9 — Vom ZWEITEN PC testen

Ein Test auf dem Server selbst beweist nichts über das Netzwerk. Also auf einen zweiten Rechner im selben Netz wechseln. Vorher den Servernamen herausfinden — auf dem Server:

hostname

Die Ausgabe (z. B. SRV-GOLF) ersetzt unten überall SERVERNAME.

[PowerShell — zweiter PC] (Admin nicht nötig) 
ping SERVERNAME
Test-NetConnection SERVERNAME -Port 3306

Was soll rauskommen: ping antwortet (= Name wird gefunden), und TcpTestSucceeded : True (= Tür ist offen). False → Leiter in „Netzwerk & Firewall“ abarbeiten.

Hinweis: Schlägt nur ping fehl, muss nichts kaputt sein — viele Server blocken Ping (ICMP). Entscheidend ist allein der Port-Test.

Der Vollbeweis ist ein echter Login. Dafür braucht der zweite PC das Client-Programm — einmal den kompletten Ordner bin vom Server rüberkopieren (USB/Freigabe), dann:

cd "<Pfad zum kopierten bin-Ordner>"
.\mariadb.exe -u pccuser -p -h SERVERNAME -P 3306 --protocol=TCP -e "SELECT 1;"

(-h = Host/Servername · -P = Port, großes P! · --protocol=TCP erzwingt den echten Netzwerkweg · -e führt den SQL-Befehl direkt aus.)

Was soll rauskommen: eine Mini-Tabelle mit 1. Kommt Access denied — gute Nachricht: Netzwerkweg funktioniert, nur Benutzer/Passwort falsch.

Schritt 10 — PC CADDIE die Adresse geben (pcc_path.ini)

Kleine Datei, mit der PC CADDIE die Datenbank findet. Sie liegt zentral im DATEN-Ordner — dem Ordner, den alle Clients ohnehin nutzen.

[PowerShell als Admin — Server] 
New-Item -ItemType Directory "C:\PCCADDIE_MDB\DATEN" -Force
notepad "C:\PCCADDIE_MDB\DATEN\pcc_path.ini"

Notepad fragt „Datei erstellen?“ → Ja. Inhalt einfügen:

[mariadb]
schema=pcc
host=localhost
port=3306
user=root
password=HIER-BASE64
[database]
system=mariadb
tablesql=all

Das Passwort steht dort Base64-verpackt (das ist keine Verschlüsselung, nur eine Verpackung). So wird es erzeugt:

[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("Geheim-123"))

Die Ausgabe anstelle von HIER-BASE64 eintragen, speichern.

Achtung, wichtigste Zeile: host=. localhost stimmt nur, wenn PC CADDIE auf demselben Rechner läuft (Terminalserver). Bei Server+Clients oder getrenntem DB-Server muss dort der Servername stehen — sonst sucht jeder Client die Datenbank bei sich selbst.

Schritt 11 — Virenscanner-Ausnahmen

Der Scanner darf den Datenordner nicht anfassen, sonst bremst er die Datenbank oder beschädigt sie (er sperrt Dateien, während die Datenbank schreibt). Beim Windows Defender per Befehl:

[PowerShell als Admin — Server] 
Add-MpPreference -ExclusionPath "C:\PCCADDIE_MDB\MARIADB\data"
Add-MpPreference -ExclusionProcess "mariadbd.exe"
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess

Die dritte Zeile zeigt zur Kontrolle, was eingetragen ist. Bei Fremd-Virenscannern (Sophos, Kaspersky …) geht das nur in deren Verwaltung — bei zentral verwalteten Lösungen gewinnt die Firmen-Richtlinie: dort eintragen lassen und hinterher prüfen.

Schritt 12 — Abschlussprüfung

Server neu starten und beweisen, dass alles von allein wiederkommt. Achtung: startet den Rechner sofort neu — beim Kunden nur nach Absprache!

[PowerShell als Admin — Server] 
Restart-Computer

Nach dem Hochfahren (wieder PowerShell als Admin):

Get-Service MariaDB-PCC
netstat -ano | findstr :3306
Get-Content "C:\PCCADDIE_MDB\MARIADB\data\mariadb-error.log" -Tail 20

Running? 0.0.0.0:3306? Keine Fehler im Log? Dann der Umlaut-Test — einmal in den mariadb-Client (.\mariadb.exe -u root -p):

[mariadb-Client — Server] 
USE pcc;
CREATE TABLE umlauttest (name VARCHAR(50));
INSERT INTO umlauttest VALUES ('Müller-Lüdenscheidt äöüß');
SELECT * FROM umlauttest;
DROP TABLE umlauttest;
exit

Kommt der Name exakt so zurück, stimmen Zeichensatz und Übertragung. Erst jetzt ist die Installation fertig.

Netzwerk und Firewall — genauer durchleuchtet

Welche Firewall wann zählt, welche Richtung offen sein muss — und die Fehlersuch-Leiter

Das Bild: Ein Telefonanruf

Eine Datenbankverbindung ist wie ein Anruf: Der Client ruft an (Richtung: rein zum Server, Port 3306), der Server nimmt ab, und die Antworten laufen im selben Gespräch zurück. Firewalls merken sich laufende Gespräche („zustandsbehaftet“) — für die Antwort braucht es darum keine eigene Regel.

Die Richtungs-Frage, klar beantwortet:

  • Auf dem Server: genau eine eingehende Regel für TCP 3306. Fertig.
  • Von innen nach außen: nichts nötig. Windows lässt ausgehenden Verkehr standardmäßig zu.
  • Auf den Clients: normalerweise gar nichts zu tun. Nur wenn ein Kunde ausgehenden Verkehr absichtlich einschränkt (sehr selten), braucht der Client eine ausgehende Freigabe für 3306.

Drei Orte, an denen eine Firewall sitzen kann

OrtWann relevant?Was tun?
Windows-Firewall auf dem Serverimmereingehende Regel für 3306 (Schritt 8)
Windows-Firewall auf dem Clientfast nie (ausgehend standardmäßig offen)nur bei ausgehend gesperrten Umgebungen: Freigabe 3306
Hardware-Firewall / Routernur wenn der Verkehr durch sie hindurch musszwischen den Zonen 3306 erlauben

Das Entscheidende: Stehen Server und Clients im selben Netz (gleicher Switch, gleiches Subnetz — der Normalfall im Golfclub), läuft der Verkehr an der Hardware-Firewall vorbei — sie sieht ihn gar nicht. Dann zählt nur die Windows-Firewall des Servers.

Die Hardware-Firewall wird erst relevant, wenn der Verkehr eine Netzgrenze überquert: getrennte Netze/VLANs (z. B. Kassen-/Gastro-Netz vom Büro-Netz getrennt) · TS- und DB-Server in verschiedenen Netzen · Standortkopplung über VPN · Cloudserver. Dann muss auf dem Gerät zwischen den Netzen TCP 3306 von den Client-Netzen zum DB-Server erlaubt sein.

Niemals: Port 3306 am Router ins Internet öffnen (Portweiterleitung). Für Cloud- und Fernzugriff gilt: VPN — die Clients sind dann „wie im internen Netz“, und es bleibt bei der einen Regel.

Die Profil-Falle der Windows-Firewall

Windows sortiert jedes Netzwerk in ein Profil: Domäne, Privat oder Öffentlich. Unsere Regel gilt nur für Domäne+Privat. Hält Windows das Kundennetz fälschlich für „Öffentlich“ (passiert nach Netzwerkwechseln gern), ist die Regel wirkungslos — obwohl sie existiert.

[PowerShell als Admin — Server] 
Get-NetConnectionProfile

Steht bei NetworkCategory Public, obwohl es das interne Kundennetz ist (Server in der Domäne → sollte DomainAuthenticated sein):

Set-NetConnectionProfile -InterfaceIndex <Zahl aus der Spalte InterfaceIndex> -NetworkCategory Private

Ping reicht nicht

ping testet nur „Rechner erreichbar?“ — mit einer anderen Technik (ICMP), nicht über Port 3306. Es kann ping klappen und 3306 zu sein, und umgekehrt — und viele Server blocken Ping komplett, dann schlägt ping fehl, obwohl alles läuft. Der echte Türtest ist immer:

Test-NetConnection SERVERNAME -Port 3306

Die Leiter: Client kommt nicht dran — der Reihe nach prüfen

  1. Läuft der Dienst? [Server] Get-Service MariaDB-PCC → Running?
  2. Hört er nach draußen? [Server] netstat -ano | findstr :3306 → 0.0.0.0:3306? (127.0.0.1 → bind-address falsch)
  3. Kommt man durch? [Client] Test-NetConnection SERVERNAME -Port 3306 → True? (False → Firewallregel? Profil-Falle? Namensauflösung: ping SERVERNAME)
  4. Darf man rein? [Client] Login testen → „Access denied“ = Netzweg OK, nur Benutzer/Passwort falsch — gutes Zeichen!

Dazu: Der Client muss den Servernamen auflösen können (DNS). Deshalb braucht der Server festen Namen und feste IP. Wird der Server umbenannt, verlieren alle Clients die Datenbank.

Checkliste: MariaDB für PC CADDIE installieren

Entwurf V0.1 — Lücken „___“ werden beim Treffen mit den beschlossenen Standards gefüllt. Haken bleiben lokal gespeichert.
0 erledigt

1. Vorbereitung

2. Installation

3. Konfiguration (my.ini)

4. Datenbank und Benutzer

5. Netzwerk (entfällt bei reinem Terminalserver)

6. PC CADDIE anbinden

7. Schutz und Betrieb

8. Abschluss

Praktische Übung: „Kein Arbeitsplatz kommt mehr an die Datenbank!“

Dauer ca. 10–15 Minuten · Lernziel: nicht raten, sondern die Leiter abarbeiten
Teil 1 — Vorbereitung durch den Moderator (vorab, nicht für Teilnehmer)

Ausgangslage: fertige Installation (Dienst läuft, Firewallregel existiert, Verbindung vom zweiten PC hat funktioniert). Jetzt heimlich den Fehler einbauen:

[PowerShell als Admin — Server]

1. Die my.ini öffnen, die der Dienst wirklich liest (Pfad zeigt sc.exe qc MariaDB-PCC hinter --defaults-file=):

notepad "C:\PCCADDIE_MDB\MARIADB\data\my.ini"

2. Die Zeile ändern:

bind-address=127.0.0.1

3. Speichern, Dienst neu starten:

Restart-Service MariaDB-PCC

4. Kontrolle, dass der Fehler „scharf“ ist:

netstat -ano | findstr :3306

→ muss jetzt 127.0.0.1:3306 zeigen. Lokal funktioniert weiterhin alles — vom zweiten PC nicht mehr. Genau das macht den Fall gemein: Firewallregel ist da, Dienst läuft, trotzdem kommt kein Client rein.

Teil 2 — Die Aufgabe

Der Golfclub Grünheide ruft an:
„Seit heute Morgen startet PC CADDIE an keinem Arbeitsplatz mehr — Fehler ‚Datenbank nicht erreichbar‘. Am Server selbst haben wir nichts gemacht, da läuft auch alles: Der Dienst ist grün, und wenn wir uns direkt am Server anmelden, funktioniert PC CADDIE dort einwandfrei. Gestern Abend hat ein Kollege noch ‚etwas an der Konfiguration aufgeräumt‘.“

Aufgabe: Findet die Ursache und behebt sie. Nicht raten — arbeitet die Leiter ab und sagt bei jeder Stufe, was ihr prüft, womit und was das Ergebnis bedeutet.

Hilfsmittel: die Leiter (Dienst? → Lauscht er nach draußen? → Kommt man durch? → Darf man rein?) — siehe „Netzwerk & Firewall“.

🔍 Lösungsweg anzeigen (Spickzettel — erst nach der Übung öffnen!)

Stufe 1 — Läuft der Dienst? [Server]

Get-Service MariaDB-PCC

→ Running. Also nicht die Ursache. (Passt zur Kundenaussage.)

Stufe 2 — Hört er nach draußen? [Server]

netstat -ano | findstr :3306

→ 127.0.0.1:3306 — Treffer! Der Dienst lauscht nur nach innen. Wer sauber arbeitet, hat den Fehler nach zwei Befehlen.

Typischer Irrweg (ruhig zulassen): Viele springen zuerst zur Firewall. Dort ist alles in Ordnung — die Regel existiert. Lernmoment: Die Firewall kann eine Tür nur öffnen, an der auch jemand lauscht.

Stufe 3 — Gegenprobe vom Client [Client]

Test-NetConnection SERVERNAME -Port 3306

→ TcpTestSucceeded : False, obwohl die Firewallregel da ist. Bestätigt: Es liegt am Server selbst.

Stufe 4 — Beweis und Ursache [Server, mariadb-Client]

.\mariadb.exe -u root -p -e "SHOW VARIABLES LIKE 'bind_address';"

→ 127.0.0.1. Blick in die my.ini (welche? → sc.exe qc MariaDB-PCC!): Da hat „der Kollege beim Aufräumen“ die bind-address verstellt.

Behebung: my.ini auf bind-address=0.0.0.0 zurücksetzen, Restart-Service MariaDB-PCC, netstat zeigt wieder 0.0.0.0:3306, Client-Test → True. Gelöst.

Abschlussfrage an die Runde: „Warum hat die Firewallregel nicht geholfen?“ — Es gibt zwei Schlösser; die Firewall war offen, aber der Dienst hat nur nach innen gelauscht.

😈 Gemeine Variante für schnelle Gruppen (Moderator)

my.ini korrekt auf 0.0.0.0 lassen, aber den Dienst auf eine andere Konfigurationsdatei umbiegen:

[PowerShell als Admin — Server] 
Copy-Item "C:\PCCADDIE_MDB\MARIADB\data\my.ini" "C:\Program Files\MariaDB\falsch.ini"
notepad "C:\Program Files\MariaDB\falsch.ini"

→ dort bind-address=127.0.0.1 setzen, dann:

sc.exe --% config MariaDB-PCC binPath= "\"C:\Program Files\MariaDB\bin\mariadbd.exe\" \"--defaults-file=C:\Program Files\MariaDB\falsch.ini\" \"MariaDB-PCC\""
Restart-Service MariaDB-PCC

(Das --% sagt PowerShell: alles danach unverändert an sc.exe durchreichen — nötig wegen der verschachtelten Anführungszeichen.)

Jetzt führt die normale Fehlersuche ins Leere: Die my.ini, die alle anschauen, ist korrekt — trotzdem lauscht der Dienst nur auf 127.0.0.1. Gelöst erst, wenn jemand sc.exe qc MariaDB-PCC ausführt und sieht, dass der Dienst eine ganz andere Datei liest. Lernmoment: Merksatz 3.

Rückbau (Original-binPath vorher mit sc.exe qc notieren!):

sc.exe --% config MariaDB-PCC binPath= "\"C:\Program Files\MariaDB\bin\mariadbd.exe\" \"--defaults-file=C:\PCCADDIE_MDB\MARIADB\data\my.ini\" \"MariaDB-PCC\""
Restart-Service MariaDB-PCC
Remove-Item "C:\Program Files\MariaDB\falsch.ini"

Merkzettel für den Moderator

  • Vorher VM-Snapshot! Dann ist jeder Zustand in einer Minute zurückgeholt.
  • Beide Varianten einmal selbst durchspielen — inklusive Rückbau.
  • Wenn die Gruppe festhängt: nicht die Lösung sagen, sondern die nächste Leiterstufe als Frage stellen („Woher wisst ihr, dass der Dienst nach draußen lauscht?“).
  • Zeitrahmen: Variante 1 ca. 10 min, Variante 2 nur bei Restzeit.

Beim Treffen zu klären — künftige Standards

Haken = entschieden · ins Feld den Beschluss eintragen · am Ende alles mit einem Klick als Text kopieren
0 entschieden
1. Passwörter (wichtigster Punkt — blockiert Cloud-Rollout)
Das Skript setzt bei jedem Kunden dasselbe root-Passwort. Pro Kunde ein eigenes? Wo abgelegt (Passwort-Manager)? (V2: Passwort komplexer, aber weiterhin überall gleich und im Klartext im Skript.)
2. root oder eigener Benutzer?
Braucht PC CADDIE nur Lesen/Schreiben, oder auch CREATE/ALTER bei Programm-Updates? → Entwicklung fragen. Und (Praxisfund vom Testlauf): roots zweite Tür „Windows-Anmeldung“ (GSSAPI — lokal ohne Passwort) behalten oder abschalten?
3. MSI oder ZIP als Standardverfahren?
Skript nutzt MSI, die Schulung den ZIP-Weg (bewusst, wegen voller Kontrolle).
4. Version und Update-Strategie
11.8 LTS festnageln? Wer entscheidet Updates, wie oft?
5. Pfade
V2-Vorentscheidung: Programm fest nach C:\Program Files\MariaDB, Datenordner wählbar neben DATEN (z. B. T:\PCCADDIE_MDB\MARIADB\data). Bestätigen? Heißt der Basisordner überall PCCADDIE_MDB? Datenordner immer lokal, nie Netzlaufwerk — das Skript prüft das bisher nicht.
6. Port
Fest 3306? Was, wenn belegt (fremdes MySQL) — 3307 oder abbrechen?
7. bind-address und host je Szenario
Kundenszenariohost in pcc_path.inibind-addressFirewall-Regel
Terminalserver (alles auf einer Maschine)localhost127.0.0.1 reichtkeine nötig
Server + Clients im NetzSERVERNAME0.0.0.0ja
TS- und DB-Server getrenntDB-SERVERNAME0.0.0.0ja, zwischen TS und DB
Cloudserverje nach Aufbau0.0.0.0ja, streng eingeschränkt + VPN
8. Sortierung (Collation)
utf8mb4 ist gesetzt — aber welche Sortierung? Müller/Mueller/Muller- und ß-Test; muss zum alten DBF-Verhalten passen (Mitglieder-/Startlisten).
9. RAM-Staffel
Dedizierter DB-Server: 50–70 %. Terminalserver: deutlich weniger (RDP-Sitzungen!). Vorschlag Staffel: 8 GB → 1–2 GB · 16 GB → 4 GB · 32 GB → 8 GB.
10. Logs
Error Log fester Name. Slow Query Log dauerhaft an? Wer räumt Logdateien auf?
11. Virenscanner-Ausnahmen
Verbindliche Liste festlegen (data-Ordner, mariadbd.exe, Backup-Ziel) + Prüfschritt.
12. Cloud-Kunden: Verschlüsselung
Kann PC CADDIE TLS — oder ist VPN Pflicht? → Entwicklung fragen.
13. Automatisierung: Woher kennt das Makro den Servernamen?
Skript schreibt heute stur host=localhost in die pcc_path.ini — falsch für Server/Client und getrennten DB-Server.
14. Skript nachbessern
Unbeaufsichtigter Modus · Exit-Code 3010 nicht als Fehler · Passwort nicht fest verdrahtet · my.ini erzeugen · Datenpfad gegen Netzlaufwerke absichern · prüfen, dass das Skript auf dem DB-Server läuft.

Stolperfallen, an die selten jemand denkt

Randthemen mit großem Schadenspotenzial
  • Die Backup-Falle. Bisher galt: DATEN-Ordner kopieren = Sicherung. Bei einer laufenden MariaDB ist eine Dateikopie des data-Ordners unbrauchbar (halb geschriebene Dateien). Die vorhandene Kundensicherung sichert ab dem Umstieg stillschweigend Schrott. Backup ist ein eigener Themenblock — der Warnhinweis gehört trotzdem in die Installations-Checkliste.
  • Startreihenfolge. Die Datenbank muss laufen, bevor PC CADDIE startet. Einmal absichtlich testen: Was zeigt PC CADDIE, wenn die DB weg ist? Dieses Fehlerbild wird der häufigste Support-Anruf.
  • Rückweg offenhalten. Solange die Migration nicht abgenommen ist: DBF-Dateien nicht anfassen. (Grenzthema zum Themenblock Migration.)
  • Brauchen die Clients etwas? Vermutlich bringt PC CADDIE die Verbindungs-DLL selbst mit — prüfen! Sonst fehlt in der Checkliste ein Abschnitt „Client-Voraussetzungen“. → Entwicklung fragen.
  • Dienstkonto. Unter welchem Windows-Konto läuft der Dienst (LocalSystem)? Reicht das, oder eingeschränktes Konto?
  • Platte voll = Datenbank steht. Daten und Logs wachsen. Wer merkt das beim Kunden, bevor es knallt?
  • Doku pro Kunde. Version, Pfade, Port, Benutzer, Passwortablage — wohin damit?
  • Monitoring (Zukunft). Wird ein DB-Ausfall bemerkt, bevor der Kunde anruft?

Für die Demo beim Treffen

  • VM-Snapshots vorher/nachher anlegen; Übung vorab einmal durchspielen.
  • Zweiten Rechner/VM für den Verbindungstest bereithalten.
  • Vorschlag Ablauf (ca. 45 min): 10 min Erklärung mit dem Bibliothekar-Bild · 15 min Live-Installation (Schritte 1–7 per Copy-Paste) · 5 min Netzwerk öffnen + Test vom zweiten PC · 10 min Übung Fehlersuche · 5 min Standards abstimmen.

Offene Fragen (Detail)

Vollständige Fragenliste mit Hintergründen — Kurzfassung siehe „Standards fürs Treffen“

Kundenszenarien, die jede Antwort überstehen muss:

KürzelSzenarioBesonderheit
AServer/Client im LANDB auf Server, Clients greifen übers Netz zu
BTerminalserver, alles auf einer MaschineRAM-Konkurrenz mit RDP-Sessions
CCloudserverZugriff über WAN, Latenz, Sicherheit
DTS und DB getrenntzwei Maschinen, Firewall dazwischen

1. Kritisch — vor dem Rollout

1.1 Root-Passwort bei allen Kunden identisch. Fest im Skript, kombiniert mit offenem Port 3306: Wer das Passwort eines Kunden kennt, kommt bei jedem rein. Pro Installation generieren? Wo dokumentieren? Support-Zugang nur auf localhost? Ohne Antwort kein Cloud-Rollout.

1.2 Version. 11.8.6 liegt vor. Eine LTS für alle? Wer entscheidet Updates? Umgang mit fremden MySQL/MariaDB-Beständen? Minor-Updates automatisch?

1.3 MSI oder ZIP.

MSIZIP
Installationein Aufrufmehrere Schritte
DeinstallationSystemsteuerungOrdner löschen, Dienst manuell entfernen
KonfigurationInstaller schreibt my.ini selbstkomplett selbst
Kontrollebegrenztvollständig
Mehrere Instanzenumständlichproblemlos
UpdateMSI-UpgradeOrdner tauschen

2. Benutzer und Rechte

2.1 PC CADDIE als root? Skript legt keinen Anwendungsbenutzer an, pcc_path.ini enthält user=root → Vollzugriff auf alles inkl. Systemdatenbank. Dedizierter pccuser nur auf pcc.*? Braucht PC CADDIE CREATE/ALTER (Updates)? Getrennte Benutzer für Anwendung, Backup, Support? '%' oder Client-Subnetze?

2.2 Passwortablage. Base64 in der pcc_path.ini ist Kodierung, keine Verschlüsselung — und die Datei liegt im für alle erreichbaren DATEN-Ordner. Bewusst akzeptieren? NTFS-Rechte? Audit-Problem?

3. Installation und Pfade

3.1 Vorhandene Installationen. Skript prüft weder Port noch fremde Dienste. Ausweichport 3307? Abbrechen und melden? Fremde Instanz mitbenutzen?

3.2 Pfade. V2-Vorentscheidung: Programm fest C:\Program Files\MariaDB, Datadir neben DATEN (T:\PCCADDIE_MDB\MARIADB\data). Bestätigen? Basisordner-Name? Was bei PC CADDIE auf D:?

3.3 license.json-Suche. Durchsucht alle Laufwerke inkl. Netzlaufwerke (langsam); der Filter '*DATENlicense.json' matcht vermutlich nie — nur der Fallback greift. Netzlaufwerke ausnehmen? Pfad vom Makro übergeben statt suchen?

3.4 Dienstname fest. MariaDB-PCC → nur eine Instanz pro Server. Mehrere Clubs/Mandanten: mehrere Instanzen oder mehrere Schemas?

4. Netzwerk

4.1 bind-address je Szenario. B: 127.0.0.1 genügt. A/D: 0.0.0.0. C: 0.0.0.0 + strenge Firewall. Pro Szenario festlegen oder immer 0.0.0.0?

4.2 host=localhost fest verdrahtet. Falsch für A und D. Woher kennt das Makro den Servernamen? Name oder IP? Zentrale oder Client-eigene ini?

4.3 Port. Fest 3306? Abweichender Port bei Cloud = Scheinsicherheit?

4.4 Firewallregeln. Skript legt keine an. Profile? RemoteAddress bei C/D? Zentrale Firewall-Richtlinie?

4.5 Verschlüsselung. Cloud ohne TLS/VPN = Klartext übers Internet. Kann PC CADDIE TLS? Zertifikate? Muss geklärt werden.

5. Zeichensatz und Sortierung

5.1 utf8mb4 serverseitig festnageln (Skript setzt nur die DB, keinen Server-Default).

5.2 Collation:

CollationVerhalten
utf8mb4_general_cischnell, Umlaut-Sortierung teils unerwartet
utf8mb4_unicode_cikorrekte Sprachsortierung, minimal langsamer
utf8mb4_uca1400_ai_cineuer Unicode-Standard ab MariaDB 11.4

Müller/Mueller/Muller? ß vs. ss? Case-insensitive Suche? Muss zum ADS-Verhalten passen — vor dem Treffen mit Namensliste praktisch testen.

6. Speicher und Performance

6.1 Buffer Pool. Default 128 MB ist zu wenig. 50–70 % RAM gilt nur für dedizierte DB-Server — auf Terminalservern gefährlich. Staffel festlegen. Wie groß werden PCC-Datenbanken real?

6.2 Weitere Parameter. innodb_flush_log_at_trx_commit (1 sicher / 2 schneller)? max_connections (wie viele Verbindungen öffnet ein Client)? innodb_file_per_table aktivieren?

7. Logs und Betrieb

7.1 Error Log fester Name statt <hostname>.err. 7.2 Slow Query Log dauerhaft an? Ab welcher Laufzeit? Wer wertet aus? 7.3 Logrotation: Windows rotiert nichts — wer räumt auf? 7.4 Binärlog: für Point-in-Time-Recovery, kostet Platz — mit Themenblock Backup abstimmen.

8. Virenscanner

data rekursiv, mariadbd.exe als Prozess, Backup-Ziel. Auch tmp? Wie beim Kunden dokumentieren? Wer setzt es bei zentral verwaltetem AV um? Wie wird geprüft, ob der Ausschluss wirklich greift?

9. Anmerkungen zu den Skript-Versionen

Zwei Versionen: pcc_mariadb_inst_.ps1 (V1) und pcc_mariadb_inst.ps1 (V2, 19.07.2026). Gleicher Ablauf, drei gezielte Änderungen (Zeilenangaben = V2; am lebenden System noch nicht verifiziert).

PunktV1V2Bedeutung
InstallationspfadC:\MariaDB / wählbarfest C:\Program Files\MariaDB (Z. 42, 526)Trennung Programm/Daten
Datenpfadimmer <INSTALLDIR>\dataDialog, Vorschlag <Basis>\MARIADB\data neben DATENnur der Datenort variabel
root-Passwortpccaddie.Pcc#maria!DB (Z. 39)komplexer, aber weiter überall gleich
BeispielpfadeC:\PCCADDIE\...T:\PCCADDIE_MDB\...neue Ordnerkonvention, Laufwerk T:

Unverändert: host=localhost fest (Z. 749) · user=root (Z. 751) · keine my.ini/Firewall/Collation · Suchfilter-Bug (Z. 548) · Netzlaufwerke in der Suche (Z. 537) · Exit 3010 = Abbruch (Z. 640–645) · BOM bei Set-Content (Z. 760) · interaktive Prompts.

Neu durch V2:

  1. Datadir auf Netzlaufwerk möglich. Ist T: die gemappte Freigabe, scheitert der erhöhte Installer (1603), der Dienst (LocalSystem) sieht gemappte Laufwerke nie, und Datadir auf SMB ist nicht supported. → Skript muss UNC/gemappte Pfade ablehnen und den Ausführungsort prüfen.
  2. Ohne license.json landet die pcc_path.ini in C:\Program Files\DATEN — Ordner wird sogar angelegt (Z. 590, 730–738). Vermutlich unbeabsichtigt.
  3. 32-bit-PowerShell liefert Program Files (x86) als Installationsziel (RMM-Agenten!).
  4. Passwort-Sonderzeichen #/!: in Base64 ok; im Klartext in einer my.ini wäre # ein Kommentarzeichen.
  5. Positiv: my.ini liegt mit V2 einheitlich unter <DATADIR>\my.ini — der Ort, den der Support kennen muss.

Runbook: Manuelle Installation (ZIP) — Referenz

Kompakte Befehlsreferenz. Die geführte Version mit Erklärungen: „Installation Schritt für Schritt“.

0 · Ausgangslage

Get-Service | Where-Object { $_.Name -match 'maria|mysql' }
Test-NetConnection localhost -Port 3306

Beides leer bzw. False. Altbestand → Offene Frage 3.1.

1 · Entpacken

Expand-Archive C:\mariadb\mariadb-11.8.6-winx64.zip -DestinationPath C:\temp\mdb
New-Item -ItemType Directory "C:\Program Files\MariaDB" -Force
Copy-Item C:\temp\mdb\mariadb-11.8.6-winx64\* "C:\Program Files\MariaDB\" -Recurse

Im ZIP ist keine my.ini enthalten — Konfiguration entsteht komplett selbst. mysql*-Programme sind nur Aliase der mariadb*-Programme; die mariadb*-Namen verwenden.

2 · my.ini (Referenzblock, erweitert)

[mysqld]
datadir                 = C:/PCCADDIE_MDB/MARIADB/data
port                    = 3306
bind-address            = 0.0.0.0
character-set-server    = utf8mb4
collation-server        = utf8mb4_general_ci
innodb_buffer_pool_size = 2G
innodb_file_per_table   = 1
innodb_flush_log_at_trx_commit = 1
max_connections         = 200
log_error               = C:/PCCADDIE_MDB/MARIADB/data/mariadb-error.log
slow_query_log          = 1
slow_query_log_file     = C:/PCCADDIE_MDB/MARIADB/data/mariadb-slow.log
long_query_time         = 2

[client]
port                    = 3306
default-character-set   = utf8mb4

Schrägstriche / in Pfaden; ohne BOM speichern (PowerShell Set-Content -Encoding UTF8 schreibt in 5.1 mit BOM!). Jeder Wert ist eine offene Standard-Entscheidung.

3 · Initialisieren + Dienst

New-Item -ItemType Directory "C:\PCCADDIE_MDB\MARIADB" -Force
cd "C:\Program Files\MariaDB\bin"
.\mariadb-install-db.exe --datadir="C:\PCCADDIE_MDB\MARIADB\data" --service=MariaDB-PCC --password=<StarkesPasswort>

Überordner zuerst anlegen — das Tool erzeugt nur den letzten Ordner (data) selbst.

Legt Systemtabellen, Dienst und root-Passwort an — und in der Regel eine minimale my.ini im data-Ordner, auf die der Dienst per --defaults-file zeigt. Einstellungen dann in diese Datei.

sc.exe qc MariaDB-PCC

Steht ein --defaults-file im BINARY_PATH_NAME, wird ausschließlich diese Datei gelesen. Ohne: Suchreihenfolge %WINDIR%\my.ini → C:\my.ini → <INSTALLDIR>\my.ini → <INSTALLDIR>\data\my.ini. Gegencheck der gelesenen Werte:

.\my_print_defaults.exe --defaults-file="C:\PCCADDIE_MDB\MARIADB\data\my.ini" mysqld

4 · Dienststeuerung

Start-Service MariaDB-PCC
Set-Service MariaDB-PCC -StartupType Automatic
Restart-Service MariaDB-PCC
Stop-Service MariaDB-PCC

Startet er nicht: Error Log lesen; ergänzend Ereignisprotokoll (Fehler vor dem Öffnen des Logs, z. B. Syntaxfehler in der my.ini):

Get-Content "C:\PCCADDIE_MDB\MARIADB\data\*.err" -Tail 40
Get-EventLog -LogName Application -Source MariaDB* -Newest 10

5 · Verifizieren

.\mariadb.exe -u root -p -e "SELECT VERSION(); SHOW VARIABLES LIKE 'datadir'; SHOW VARIABLES LIKE 'bind_address'; SHOW VARIABLES LIKE 'port'; SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'collation_server'; SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW VARIABLES LIKE 'log_error';"

Nicht überspringen — nur diese Ausgabe beweist, dass die my.ini gelesen wurde.

6 · Datenbank + Benutzer

CREATE DATABASE pcc CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'pccuser'@'%' IDENTIFIED BY '<StarkesPasswort>';
GRANT ALL PRIVILEGES ON pcc.* TO 'pccuser'@'%';
FLUSH PRIVILEGES;

'%' = jeder Host; bei reinen Terminalservern besser 'localhost'.

7 · Netzwerk

New-NetFirewallRule -DisplayName "MariaDB PC CADDIE (3306)" -Direction Inbound -Protocol TCP -LocalPort 3306 -Action Allow -Profile Domain,Private

-Profile Public bewusst weglassen; bei Cloud zusätzlich -RemoteAddress einschränken. Kontrolle:

netstat -ano | findstr :3306

0.0.0.0:3306 = alle Interfaces · 127.0.0.1:3306 = nur lokal.

8 · Client-Test

Test-NetConnection <SERVERNAME> -Port 3306
.\mariadb.exe -u pccuser -p -h <SERVERNAME> -P 3306 --protocol=TCP -e "SELECT 1"

--protocol=TCP ist wichtig: sonst weicht der Client bei -h localhost auf Named Pipes aus und testet gerade nicht den TCP-Weg.

9 · Virenscanner

Ausschlüsse: data-Ordner rekursiv · mariadbd.exe als Prozess · Backup-Ziel. Bei zentral verwaltetem AV über die Konsole — und hinterher prüfen, ob der Ausschluss aktiv ist.

10 · pcc_path.ini

[mariadb]
schema=pcc
host=localhost
port=3306
user=root
password=<base64>

[database]
system=mariadb
tablesql=all

host=localhost nur bei Terminalserver; sonst Servername/IP. Base64 erzeugen:

[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("<Passwort>"))

Export & Sichern

Haken, Beschlüsse und Notizen liegen nur im Browser dieses Rechners — hier sicherst du sie weg oder machst ein Dokument daraus.

💾 Sichern & Wiederherstellen

Speichert den kompletten Stand (alle Haken, Beschlüsse, Notizen) als kleine Datei — z. B. auf die Freigabe. Auf jedem anderen Rechner/Browser über „Wiederherstellen“ wieder einspielbar. So geht nichts verloren.

📋 Protokoll-Text

Alle Standards-Beschlüsse und alle Notizen als Text in die Zwischenablage — fürs Protokoll des Treffens oder eine Mail an die Kollegen.

📄 Neues Handout erzeugen

Baut aus der Schritt-für-Schritt-Anleitung plus euren Notizen und Beschlüssen ein eigenständiges Dokument (HTML-Datei im Download-Ordner — im Browser öffnen, bei Bedarf drucken oder als PDF sichern).