Я переносил старый сервер с apache2 + mysql под ubuntu на новый сервер с debian (wheezy). Миграция работает нормально, пока базы данных хранятся локально (в нашем случае / srv / mysql), но когда я пытаюсь переместить их в наше централизованное хранилище, работающее по NFS и создавая символические ссылки на перемещенные файлы, mysql, похоже, не находит базы данных в все. Я не получаю ошибок от mysql, просто кажется, что такой базы данных нет.
Это макет / srv / mysql (несколько примеров):
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
Как я создаю символические ссылки:
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
После этого mysql больше не видит database_dir_1, но его можно полностью просмотреть из cli.
Крепления для / mnt / centralstorage выглядят так:
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)
И экспорт на центральный сервер:
/srv/storage 192.168.12.30(rw,async,no_subtree_check,no_root_squash)
(все имена и тому подобное были изменены)
Кто-нибудь видит какие-либо проблемы с настройкой?
С уважением, FrontSlash
Edit1:
После некоторой помощи от @Fox проблема, похоже, связана с подключением NFS. Кто-нибудь видит какие-либо проблемы в конфигурации nfs, о которой я писал выше? Если вам понадобится дополнительная информация, я отправлю ее.
Edit2:
Сделал быстрый тест, экспортировал новую папку на сервере NFS, / srv / temp, с теми же настройками, что и два других экспорта.
Смонтировал это на сервере sql с помощью fstab вместо предыдущего запущенного сценария запуска.
Скрипт просто сделал
mount $host:$dir $mnt_dir/$mmount
Который произвел это крепление:
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)
Крепление fstab:
192.168.12.222:/srv/temp /mnt/temp nfs rw,sync,hard,intr 0 0
Произведено это:
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)
И вот что странно: теперь переместите каталог базы данных в папку / mnt / temp и создайте ссылку на нее, это работает. Я продолжу исследовать.
Edit3: Решение добавлено в качестве ответа, у nfs-kernel-server была опция --manage-gids в / etc / nfs-kernel-server, которая влияла на вторичные группы для пользователя mysql.
Вы не указываете, какой движок вы используете, но позвольте мне предположить, что это InnoDB (поскольку в наши дни это довольно стандартно), а затем в Документы MySQL
(Использование реальных символических ссылок никогда не поддерживалось для таблиц InnoDB.)
и
Предложение DATA DIRECTORY - это поддерживаемая альтернатива использованию символических ссылок, что всегда было проблематично и никогда не поддерживалось для отдельных таблиц InnoDB.
Вероятно, вы могли бы создать файлы .isl вручную (но тест перед тем, как сделать это вживую).
И есть одно предупреждение, которое может быть интересно:
Не помещайте таблицы MySQL на том, смонтированный по NFS. NFS использует протокол передачи сообщений для записи в файлы, что может вызвать несогласованность данных, если сетевые сообщения потеряны или получены не по порядку.
Изменить: хорошо ... это был неправильный ответ, поскольку это не InnoDB. Но я сохраню его на случай, если кто-то еще придет сюда в поисках решения InnoDB.
Есть еще чтение по MySQL и символическим ссылкам.
Особенно интересно могло бы быть
Если вы не используете символические ссылки, запустите mysqld с
--skip-symbolic-linksпараметр, гарантирующий, что никто не сможет использовать mysqld для удаления или переименования файла вне каталога данных.
Поскольку это может быть по умолчанию в Debian. (Я не знаю.)
Edit2: Хорошо, лучший способ проверки:
SHOW VARIABLES LIKE 'have_symlink';
Еще одна причина не получать базы данных из-за пределов data-dir это AppArmor или аналогичная мера безопасности.
кстати стоило бы проверить, связано ли это с NFS - если символические ссылки на совершенно другую часть локальной файловой системы (или, лучше сказать, на другую файловую систему вообще) работают, это в NFS, если нет, то в символических ссылках ...
Спасибо за помощь @Fox и @Sven, теперь я решил проблему.
Это был параметр nfs-kernel-server, / etc / defaults / nfs-kernel-server содержал параметр --manage-gids, который запрещает использование дополнительных групп. Таким образом, хотя у пользователя mysql были правильные разрешения через вторичную группу, разрешения на стороне nfs-сервера были неправильными.
Надеюсь, кто-то еще, у кого возникла проблема, увидит это, прежде чем потратит несколько часов!
С уважением, FrontSlash