MariaDB Tabellen via Symlink

M

McGregory

Benutzer
Beiträge
6
Hallo Zusammen,

vielleicht hat dies bereits jemand erfolgreich hinbekommen, ich scheitere leider daran.

Kurze Erklärung zum Vorhaben: Es handelt sich um ein Projekt mit einem CMS, welches über verschiedene Domains und verschiedenen Datenbankinhalten betrieben wird. Module, Coredateien oder Themen werden über Symlinks realisiert und somit auf Codebasis zentralisiert.

Die beiden Projekte sollen jedoch die gleichen User beinhalten. Die Tabellenstruktur hier ist auch überschaubar klein und sollte zumindest Applikationsseitig keinerlei Probleme durch inkonsistente IDs/Verknüpfungen verursachen.

Nun gibt es da viele Lösung so etwas synchron zu halten, eine theoretisch ziemlich einfache (so ließt es sich zumindest überall) jedoch würde ich hier favorisieren.

Die Datenbanktabellen via Symlink verknüpfen. https://dev.mysql.com/doc/refman/5.7/en ... ables.html

So einfach das klingt, es klappt irgendwie nicht.

Der Wert "have_symlinks" ist in MySQL aktiviert, die Tabelle ist MyISAM, beide Datenbanken können vom selbigen DB-User aufgerufen werden und auch die Tabellen habe ich auf testweise 777 gesetzt.
Alle 3 Dateien der mysql habe ich verlinkt, als der MySQL heruntergefahren war.

In PhpMyAdmin erhalte ich für diese Tabelle (die mit dem Symlink) den Status "In Bearbeitung" und bei jeglich durchgeführten Aktion (z.B. Inhalt anzeigen) die Meldung "wrong create option"

repair table gibt selbigen fehler aus.

Ich habe die Symlinks sowohl an zwei verschiedenen Datenbanken, als auch mit einem anderen prefix in der selben Datenbank probiert. Beides verhält sich gleich.

Vielleicht hat jemand bereits so etwas gemacht?
 
Werbung:
Ein einfaches Beispiel findest du auf der offiziellem Seite, welche ich mit angegeben habe ;)

shell> cd /path/to/datadir/db1
shell> ln -s tbl1.frm tbl2.frm
shell> ln -s tbl1.MYD tbl2.MYD
shell> ln -s tbl1.MYI tbl2
 
Nett. Aber außer "wir machen mal eben schnell die DB kapott" sehe ich keinen weiteren Sinn in dieser Aktion. Was spricht gegen einen normalen VIEW?
 
weil ich prinzipiell der Meinung bin, daß JEDE manuelle Manipulation im DATA-Verzeichniss einer DB zu unterlassen ist. MySQL läuft auf unterschiedlichen Plattformen und Filesystemen (so wie auch z.B. PostgreSQL), nicht jedes Filesystem kennt z.B. Symlinks. Was soll z.B. bei einem Backup/Restore mit solch einem Gefrickel passieren, was bei einer Replikation? MySQL ist eh extrem wackelig mit unterschiedlichen Filesystemen (Groß/Kleinschreibung z.B.), da muß man nicht auch noch solche Spielchen machen.
 
Was willst Du überhaupt erreichen? Warum kann die Software nicht einfach direkt und sauber auf den Datenbankserver zugreifen?
 
Gerne erkläre ich es Anhand eines praktischen Beispiels.

Es gibt zwei getrennte Datenbanken, dessen Inhalt ein ganz anderer ist. Beide nutzen jedoch die selbe Software und die selbe (Datenbank-) Struktur.
Beide Datenbanken sollen den gleichen User-Datenbestand haben.

Registriert sich ein Benutzer über Seite A, so kann er sich ebenso auf Seite B einloggen und umgekehrt. Die Software hat leider keine Möglichkeit z.B. so etwas über einen zentralen Dienst zu realisieren.

Daher: Installation A nutzt die für diese Seite eingerichtete Tabellen, Installation B ebenso mit der Ausnahme, dass die User Tabelle auf die Datenbank A symlinkt.
Die Usertabelle aus Datenbank A bleibt somit die zentrale Tabelle mit den Benutzern, auch wenn sich jemand auf Seite B registriert.

Eine alternative wäre es ein db-sync tool zu nutzen, welche beide Tabellen-Inhalte mit über eine Checksumme prüft und synchronisiert, doch wie eingangs erwähnt erschien mir die oben genannten Lösung laut der offiziellen Doku als anfangs einfach. Praktische Erfahrungen haben hierzu aber wohl wenige.
 
Zuletzt bearbeitet:
Mit der Methode kannst dir die Tabelle aber zerschießen. Der Server weiß ja nicht, dass er nicht alleine dort ändert.
D.h. Bei gleichzeitigem Zugriff kann es passieren, dass plötzlich Müll drinnen steht und die Anwendung nicht mehr lauffähig ist.

Korrekt wäre es, die Tabelle zu replizieren oder eine saubere Zwischenschicht einzufügen und den Anwendung nicht direkt auf die DB zugreifen zu lassen, sondern über eine Serviceschnittstelle.
 
Werbung:
Zurück
Oben