Я перенес старый сервер с 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
Редактировать1:
После некоторой помощи от @Fox проблема, похоже, в соединении NFS. Кто-нибудь видит какие-либо проблемы в конфигурации nfs, которую я разместил выше? Если вам нужна дополнительная информация, я ее размещу.
Редактировать2:
Провел быстрый тест, экспортировал новую папку на 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 и создаю ссылку на нее, все работает. Я продолжу изучать.
Редактирование 3: Решение добавлено в качестве ответа: у nfs-kernel-server есть опция --manage-gids в /etc/nfs-kernel-server, которая влияет на вторичные группы для пользователя mysql.
решение1
Вы не указали, какой движок вы используете, но позвольте мне предположить, что это InnoDB (так как это довольно стандартно в наши дни), тогда вДокументация MySQL
(Использование реальных символических ссылок никогда не поддерживалось для таблиц InnoDB.)
и
Предложение DATA DIRECTORY является поддерживаемой альтернативой использованию символических ссылок, которые всегда были проблематичны и никогда не поддерживались для отдельных таблиц InnoDB.
Вы, вероятно, могли бы создать файлы .isl вручную (нотестпрежде чем сделать это в прямом эфире).
И есть одно предупреждение, которое может представлять интерес:
Не размещайте таблицы MySQL на смонтированном томе NFS. NFS использует протокол передачи сообщений для записи в файлы, что может привести к несогласованности данных, если сетевые сообщения будут потеряны или получены не в том порядке.
Редактировать: хорошо тогда... это был неверный ответ, так как это не InnoDB. Но я сохраню его на случай, если кто-то еще зайдет сюда в поисках решения InnoDB.
Есть ещечтениео MySQL и символических ссылках.
Особенно интересным может быть
Если вы не используете символические ссылки, запустите mysqld с этой
--skip-symbolic-linksопцией, чтобы гарантировать, что никто не сможет использовать mysqld для удаления или переименования файла за пределами каталога данных.
Так как это может быть значением по умолчанию в Debian. (Я не знаю.)
Редактирование 2: Хорошо, вот лучший способ проверки:
SHOW VARIABLES LIKE 'have_symlink';
Еще одной причиной, по которой не следует загружать базы данных извне, data-dirявляется AppArmor или аналогичная мера безопасности.
кстати, стоило бы проверить, связано ли это с NFS - если симлинки на совершенно другую часть локальной файловой системы (или лучше вообще на другую файловую систему) работают, то дело в NFS, если нет, то дело в симлинках...
решение2
Спасибо за помощь @Fox и @Sven, теперь я решил проблему.
Это была настройка nfs-kernel-server, /etc/defaults/nfs-kernel-server содержал опцию --manage-gids, которая нарушает использование вторичных групп. Таким образом, хотя у пользователя mysql были правильные разрешения через вторичную группу, разрешения на стороне nfs-server были неправильными.
Надеюсь, кто-то еще с такой же проблемой увидит это, прежде чем тратить зря несколько часов!
С уважением, FrontSlash