He estado migrando un servidor antiguo que ejecuta apache2 + mysql en ubuntu a un servidor nuevo que ejecuta Debian (wheezy). La migración funciona bien mientras las bases de datos se almacenan localmente (en nuestro caso /srv/mysql), pero cuando intento moverlas a nuestro almacenamiento centralizado ejecutando NFS y creando enlaces simbólicos a los archivos movidos, mysql no parece encontrar las bases de datos en todo. No recibo errores de mysql, simplemente parece creer que no existe tal base de datos.
Este es el diseño de /srv/mysql (algunos ejemplos):
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
Cómo creo enlaces simbólicos:
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
Después de esto, mysql ya no ve el directorio_base de datos_1, pero se puede navegar completamente desde cli.
Los montajes para /mnt/centralstorage se ven así:
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)
Y la exportación en el servidor central:
/srv/storage 192.168.12.30(rw,async,no_subtree_check,no_root_squash)
(todos los nombres y demás han sido cambiados)
¿Alguien ve algún problema con la configuración?
Con respecto a FrontSlash.
Editar1:
Después de un poco de ayuda de @Fox, el problema parece ser la conexión NFS. ¿Alguien ve algún problema en la configuración de nfs que publiqué arriba? Si necesitas más información la publicaré.
Editar2:
Hice una prueba rápida, exporté una nueva carpeta en el servidor NFS, /srv/temp, con la misma configuración que las otras dos exportaciones.
Monté esto en el servidor SQL con fstab en lugar del script de inicio anterior que se ejecutó.
El guión simplemente hizo un
mount $host:$dir $mnt_dir/$mmount
Que produjo esta montura:
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)
El soporte fstab:
192.168.12.222:/srv/temp /mnt/temp nfs rw,sync,hard,intr 0 0
Produjo esto:
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)
Y aquí está la parte extraña, ahora mover el directorio de la base de datos a la carpeta /mnt/temp y crear un enlace a esto, funciona. Seguiré explorando.
Edit3: Solución agregada como respuesta, nfs-kernel-server tenía la opción --manage-gids en /etc/nfs-kernel-server que afectaba a los grupos secundarios para el usuario de mysql.
Respuesta1
No indicas qué motor estás usando, pero déjame suponer que es InnoDB (ya que es bastante estándar hoy en día), entonces enDocumentos MySQL
(El uso de enlaces simbólicos reales nunca ha sido compatible con tablas InnoDB).
y
La cláusula DATA DIRECTORY es una alternativa compatible al uso de enlaces simbólicos, que siempre ha sido problemática y nunca fue compatible con tablas InnoDB individuales.
Probablemente puedas crear los archivos .isl a mano (peropruebaantes de hacerlo en vivo).
Y hay una advertencia que puede resultar de interés:
No coloque tablas MySQL en un volumen montado en NFS. NFS utiliza un protocolo de paso de mensajes para escribir en archivos, lo que podría causar inconsistencia en los datos si los mensajes de red se pierden o se reciben fuera de orden.
Editar: está bien entonces... esta no fue la respuesta correcta, ya que no es InnoDB. Pero lo guardaré por si alguien más llega aquí buscando una solución InnoDB.
Hay máslecturaen MySQL y enlaces simbólicos.
Especialmente interesante podría ser
Si no está utilizando enlaces simbólicos, inicie mysqld con la
--skip-symbolic-linksopción para asegurarse de que nadie pueda usar mysqld para eliminar o cambiar el nombre de un archivo fuera del directorio de datos.
Ya que eso podría ser el valor predeterminado en Debian. (No lo sé.)
Edit2: Ok, una mejor manera de verificar:
SHOW VARIABLES LIKE 'have_symlink';
Otra razón para no recuperar bases de datos externas data-dires AppArmor o una medida de seguridad similar.
por cierto. valdría la pena probarlo, si está relacionado con NFS: si los enlaces simbólicos a una parte completamente diferente de fs local (o mejor, fs diferentes) funcionan, está en NFS, si no es así, está en enlaces simbólicos...
Respuesta2
Gracias por la ayuda @Fox y @Sven, ya he resuelto el problema.
Era una configuración de nfs-kernel-server, /etc/defaults/nfs-kernel-server contenía la opción --manage-gids que interrumpe el uso de grupos secundarios. Entonces, si bien el usuario de MySQL tenía los permisos correctos a través de un grupo secundario, los permisos del lado del servidor nfs eran incorrectos.
¡Espero que alguien más con el problema vea esto antes de perder unas cuantas horas!
Con respecto a FrontSlash.