Estou migrando um servidor antigo rodando Apache2 + mysql no Ubuntu para um novo servidor rodando Debian (wheezy). A migração funciona bem enquanto os bancos de dados são armazenados localmente (no nosso caso/srv/mysql), mas quando tento movê-los para nosso armazenamento centralizado executando o NFS e criando links simbólicos para os arquivos movidos, o mysql parece não encontrar os bancos de dados em todos. Não recebo erros do mysql, apenas parece acreditar que não existe tal banco de dados.
Este é o layout de /srv/mysql (alguns exemplos):
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
Como crio links 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
Depois disso, o mysql não vê mais o database_dir_1, mas é totalmente navegável a partir do CLI.
As montagens para /mnt/centralstorage são assim:
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)
E a exportação no servidor central:
/srv/storage 192.168.12.30(rw,async,no_subtree_check,no_root_squash)
(todos os nomes e afins foram alterados)
Alguém vê algum problema com a configuração?
Atenciosamente, FrontSlash
Editar1:
Após alguma ajuda do @Fox, o problema parece ser a conexão NFS. Alguém vê algum problema na configuração do nfs que postei acima? Se precisar de mais informações eu postarei.
Editar2:
Fiz um teste rápido, exportei uma nova pasta no servidor NFS, /srv/temp, com as mesmas configurações das outras duas exportações.
Montei isso no servidor sql com fstab em vez do script de inicialização anterior que foi executado.
O script simplesmente fez um
mount $host:$dir $mnt_dir/$mmount
Que produziu esta montagem:
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)
A montagem fstab:
192.168.12.222:/srv/temp /mnt/temp nfs rw,sync,hard,intr 0 0
Produzido isto:
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)
E aqui está a parte estranha, agora movendo o diretório do banco de dados para a pasta /mnt/temp e criando um link para isso, funciona. Vou continuar explorando.
Edit3: Solução adicionada como resposta, nfs-kernel-server tinha a opção --manage-gids em /etc/nfs-kernel-server que afetava grupos secundários para o usuário mysql.
Responder1
Você não declara qual mecanismo está usando, mas deixe-me presumir que seja o InnoDB (já que é praticamente padrão atualmente), então emDocumentos MySQL
(O uso de links simbólicos reais nunca foi suportado para tabelas InnoDB.)
e
A cláusula DATA DIRECTORY é uma alternativa suportada ao uso de links simbólicos, que sempre foi problemática e nunca foi suportada para tabelas individuais do InnoDB.
Você provavelmente poderia criar os arquivos .isl manualmente (mastesteantes de fazer isso ao vivo).
E há um aviso que pode ser interessante:
Não coloque tabelas MySQL em um volume montado em NFS. O NFS usa um protocolo de passagem de mensagens para gravar em arquivos, o que pode causar inconsistência de dados se as mensagens de rede forem perdidas ou recebidas fora de ordem.
Editar: tudo bem então... esta não foi a resposta correta, pois não é InnoDB. Mas vou guardá-lo caso alguém chegue aqui procurando uma solução InnoDB.
Há maisleiturano MySQL e links simbólicos.
Especialmente interessante pode ser
Se você não estiver usando links simbólicos, inicie o mysqld com a
--skip-symbolic-linksopção para garantir que ninguém possa usar o mysqld para descartar ou renomear um arquivo fora do diretório de dados.
Como isso poderia ser o padrão no Debian. (Não sei.)
Edit2: Ok, uma maneira melhor de verificar:
SHOW VARIABLES LIKE 'have_symlink';
Outro motivo para não coletar bancos de dados de fora data-diré o AppArmor, ou medida de segurança semelhante.
por falar nisso. valeria a pena testar, se estiver relacionado ao NFS - se links simbólicos para uma parte completamente diferente do fs local (ou melhor, fs diferente) funcionarem, está no NFS, se não, está em links simbólicos ...
Responder2
Obrigado pela ajuda @Fox e @Sven, agora resolvi o problema.
Era uma configuração nfs-kernel-server, /etc/defaults/nfs-kernel-server continha a opção --manage-gids que interrompe o uso de grupos secundários. Portanto, embora o usuário mysql tivesse as permissões corretas através de um grupo secundário, as permissões do lado do servidor nfs estavam erradas.
Espero que outra pessoa com o problema veja isso antes de perder algumas horas!
Atenciosamente, FrontSlash