Seite 2 - MySQL

Unverschlüsselte Verbindungen zwischen Anwendungsserver und Datenbank sind in produktiven Magento-Umgebungen ein unterschätztes Risiko: Wer Zugriff auf das Netzwerksegment zwischen Webserver und Datenbankserver bekommt, liest Kundendaten, Sessions und Zugangsdaten im Klartext mit. Dieser Artikel zeigt, wie man MySQL-Verbindungen server- und clientseitig konsequent mit TLS absichert, Zertifikate sauber verwaltet und die typischen Fallstricke vermeidet, die bei Multi-Store-Setups mit mehreren Anwendungsservern auftreten.

Trigger-basierte Werkzeuge wie pt-online-schema-change lösen viele Probleme, erzeugen aber auf jeder einzelnen Schreiboperation zusätzlichen synchronen Aufwand. gh-ost, von GitHub entwickelt, verfolgt einen grundlegend anderen Ansatz: Es liest Änderungen asynchron aus dem MySQL-Binärlog, genau wie ein regulärer Replica-Server, und wendet sie auf eine Ghost-Tabelle an. Bei Tabellen mit sehr hoher, konstanter Schreiblast macht dieser Unterschied den entscheidenden Unterschied zwischen einer unbemerkten Migration und einer, die den produktiven Betrieb spürbar verlangsamt.

Sobald mehrere Knoten in einer Group Replication gleichzeitig Schreibzugriffe akzeptieren, entscheidet die Certification-based Conflict Detection darüber, welche Transaktion gewinnt und welche zurückgerollt wird. Wer diesen Mechanismus nicht versteht, baut Anwendungen, die im Multi-Primary-Betrieb regelmäßig an scheinbar zufälligen Rollbacks scheitern.

Read Replicas versprechen mehr Lesekapazität ohne größere Hardware, doch wer Leseanfragen blind auf Replicas verteilt, handelt sich veraltete Daten und schwer reproduzierbare Bugs ein. Erst ein bewusstes Read/Write-Splitting mit klarer Konsistenzstrategie macht MySQL Read Replicas zu einem verlässlichen Baustein der Skalierung.

Die Performance Schema misst, was in einer laufenden MySQL-Instanz tatsächlich passiert: welche Statements wie oft und wie lange laufen, an welchen Waits sie hängen und in welcher Stage sie ihre Zeit verbringen. Wer teure Query-Muster in einem Magento-Shop systematisch statt zufällig finden will, kommt an dieser Instrumentierung nicht vorbei.

Magento erlaubt mehrere Websites, Stores und Store-Views in einer einzigen Datenbank, doch mit wachsender Anzahl an Mandanten stellt sich die Frage, ob dieses Multi-Store-Schema noch trägt oder ob getrennte Datenbanken pro Mandant die bessere Architektur sind. Die Antwort haengt von Attributanzahl, Traffic-Verteilung und Team-Struktur ab, nicht von einer pauschalen Best Practice.

JSON-Spalten geben einer relationalen Datenbank genau die Modellierungsfreiheit, die sonst als Argument fuer einen NoSQL-Wechsel dient, ohne auf Transaktionen, Joins und referentielle Integritaet zu verzichten. Wer JSONB in PostgreSQL oder JSON in MySQL richtig indiziert, abfragt und validiert, deckt viele semi-strukturierte Anwendungsfaelle innerhalb der bestehenden Datenbank ab.

Datumsfunktionen sind einer der Bereiche, in denen sich Datenbanken am staerksten unterscheiden, obwohl die zugrunde liegende Aufgabe simpel wirkt. Dieser Artikel vergleicht Datumsarithmetik, Formatierung, Zeitzonenbehandlung und Extraktion einzelner Datumsteile in PostgreSQL, MySQL, SQL Server und Oracle anhand konkreter, lauffaehiger Beispiele.

Ein Trigger, der bei jedem INSERT eine zusätzliche Prüfung oder Protokollierung übernimmt, wirkt auf den ersten Blick harmlos und praktisch. Erst unter Last zeigt sich, dass Trigger synchron im selben Transaktionskontext laufen und dabei Lock-Zeiten verlängern, Deadlock-Risiken erhöhen und Fehler erzeugen können, die sich kaum zurückverfolgen lassen. Gerade auf häufig geänderten Tabellen eines Magento-Shops, etwa beim Bestand oder bei Bestellungen, entscheidet die Wahl zwischen Trigger, Event Scheduler und Anwendungslogik direkt über die Stabilität unter Last.

Eine einzelne offen gebliebene Transaktion kann den Undo-Log von InnoDB unkontrolliert wachsen lassen, Sperren über Minuten halten und Replikation verzögern, ohne dass eine einzige Fehlermeldung erscheint. Dieser Artikel erklärt, wie Long-Running Transactions in MySQL entstehen, wie man sie mit information_schema.innodb_trx zuverlässig aufspürt und mit welchen Timeout- und Batch-Strategien man sie im Anwendungscode von vornherein verhindert.