Ich habe einen älteren Server, auf dem Apache2 + MySQL unter Ubuntu läuft, auf einen neuen Server migriert, auf dem Debian (Wheezy) läuft. Die Migration funktioniert einwandfrei, solange die Datenbanken lokal gespeichert sind (in unserem Fall /srv/mysql), aber wenn ich versuche, sie auf unseren zentralen Speicher mit NFS zu verschieben und symbolische Links zu den verschobenen Dateien zu erstellen, scheint MySQL die Datenbanken überhaupt nicht zu finden. Ich erhalte keine Fehler von MySQL, es scheint nur zu glauben, dass es keine solche Datenbank gibt.
Dies ist das Layout von /srv/mysql (einige Beispiele):
user@server:/srv/mysql# ls -al
total 135440
drwxr-xr-x 50 mysql mysql 4096 May 22 09:59 .
drwxr-xr-x 7 root root 4096 May 22 09:59 ..
drwxrwx--- 2 mysql mysql 4096 May 21 20:13 database_dir_1
drwx------ 2 mysql mysql 4096 May 21 19:07 database_dir_2
drwxrwx--- 2 mysql mysql 4096 May 21 20:15 database_dir_3
drwx------ 2 mysql mysql 4096 May 21 20:15 database_dir_4
drwxrwx--- 2 mysql mysql 4096 May 21 20:15 database_dir_5
So erstelle ich symbolische Links:
mv /srv/mysql/database_dir_1 /mnt/centralstorage/customer1/db/database_dir_1
ln -s /mnt/centralstorage/customer1/db/database_dir_1 /srv/mysql/database_dir_1
ls -al /srv/mysql/
drwxrwx--- 1 root root 28 May 21 20:13 database_dir_1 -> /mnt/centralstorage/customer1/db/database_dir_1
Danach sieht MySQL „database_dir_1“ nicht mehr, es ist jedoch über die Befehlszeile vollständig durchsuchbar.
Die Mounts für /mnt/centralstorage sehen folgendermaßen aus:
192.168.12.222:/srv/storage/customers on /mnt/centralstorage/ type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.12.222,mountvers=3,mountport=49535,mountproto=udp,local_lock=none,addr=192.168.12.222)
Und der Export auf dem zentralen Server:
/srv/storage 192.168.12.30(rw,async,no_subtree_check,no_root_squash)
(alle Namen usw. wurden geändert)
Sieht jemand Probleme mit der Einrichtung?
Mit freundlichen Grüßen, FrontSlash
Bearbeitung1:
Nach etwas Hilfe von @Fox scheint das Problem an der NFS-Verbindung zu liegen. Sieht jemand Probleme in der NFS-Konfiguration, die ich oben gepostet habe? Wenn Sie weitere Informationen benötigen, werde ich sie posten.
Bearbeitung2:
Habe einen schnellen Test gemacht und einen neuen Ordner auf dem NFS-Server, /srv/temp, mit denselben Einstellungen wie bei den anderen beiden Exporten exportiert.
Habe dies mit fstab auf dem SQL-Server gemountet, anstelle des zuvor ausgeführten Startskripts.
Das Skript hat einfach
mount $host:$dir $mnt_dir/$mmount
Das Ergebnis ist diese Halterung:
192.168.12.222:/srv/storage/customers on /mnt/centralstorage/ type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.12.222,mountvers=3,mountport=49535,mountproto=udp,local_lock=none,addr=192.168.12.222)
Die fstab-Einbindung:
192.168.12.222:/srv/temp /mnt/temp nfs rw,sync,hard,intr 0 0
Das hier hat es hervorgebracht:
192.168.12.222:/srv/temp on /mnt/temp type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.12.222,mountvers=3,mountport=49535,mountproto=udp,local_lock=none,addr=192.168.12.222)
Und jetzt kommt der seltsame Teil: Wenn man das Datenbankverzeichnis in den Ordner /mnt/temp verschiebt und einen Link dazu erstellt, funktioniert es. Ich werde weiter nachforschen.
Edit3: Lösung als Antwort hinzugefügt, nfs-kernel-server hatte die Option --manage-gids in /etc/nfs-kernel-server, die sekundäre Gruppen für den MySQL-Benutzer beeinflusste.
Antwort1
Sie geben nicht an, welche Engine Sie verwenden, aber ich gehe davon aus, dass es InnoDB ist (da dies heutzutage so ziemlich Standard ist), dann inMySQL-Dokumente
(Die Verwendung tatsächlicher symbolischer Links wurde für InnoDB-Tabellen nie unterstützt.)
Und
Die DATA DIRECTORY-Klausel ist eine unterstützte Alternative zur Verwendung symbolischer Links, die immer problematisch war und für einzelne InnoDB-Tabellen nie unterstützt wurde.
Sie könnten die .isl-Dateien wahrscheinlich auch manuell erstellen (aberprüfenbevor ich das live mache).
Und es gibt eine Warnung, die von Interesse sein könnte:
Platzieren Sie MySQL-Tabellen nicht auf einem per NFS bereitgestellten Datenträger. NFS verwendet zum Schreiben in Dateien ein Nachrichtenübermittlungsprotokoll. Dies kann zu Dateninkonsistenzen führen, wenn Netzwerknachrichten verloren gehen oder in der falschen Reihenfolge empfangen werden.
Edit: Na gut, das war nicht die richtige Antwort, da es nicht InnoDB ist. Aber ich behalte es für den Fall, dass jemand anders hierher kommt und nach einer InnoDB-Lösung sucht.
Es gibt noch weitereLektürezu MySQL und symbolischen Links.
Besonders interessant könnte sein
Wenn Sie keine symbolischen Links verwenden, starten Sie mysqld mit der
--skip-symbolic-linksOption, um sicherzustellen, dass niemand mysqld verwenden kann, um eine Datei außerhalb des Datenverzeichnisses abzulegen oder umzubenennen.
Da dies die Standardeinstellung unter Debian sein könnte. (Ich weiß es nicht.)
Edit2: Ok, eine bessere Möglichkeit zur Überprüfung:
SHOW VARIABLES LIKE 'have_symlink';
Ein weiterer Grund, keine Datenbanken von außerhalb abzurufen, data-dirist AppArmor oder eine ähnliche Sicherheitsmaßnahme.
übrigens wäre es einen Test wert, ob es mit NFS zusammenhängt – wenn symbolische Links zu einem völlig anderen Teil des lokalen Dateisystems (oder besser noch zu einem anderen Dateisystem) funktionieren, liegt es an NFS, wenn nicht, liegt es an symbolischen Links …
Antwort2
Danke für die Hilfe @Fox und @Sven, ich habe das Problem jetzt gelöst.
Es war eine Einstellung des NFS-Kernel-Servers. /etc/defaults/nfs-kernel-server enthielt die Option --manage-gids, die die Verwendung sekundärer Gruppen unterbricht. Während der MySQL-Benutzer über eine sekundäre Gruppe die richtigen Berechtigungen hatte, waren die Berechtigungen auf der Seite des NFS-Servers falsch.
Hoffe, dass jemand anderes mit dem Problem dies sieht, bevor er ein paar Stunden verschwendet!
Mit freundlichen Grüßen, FrontSlash