Это по-прежнему плохая идея? Я знаю, что старые версии MySQL плохо работали с NFS. Думаю, проблема связана с использованием fsnc () и / или O_DIRECT. Если проблемы в основном решены, существуют ли общие подводные камни / ошибки, особенно вокруг большой (несколько таблиц с десятками миллионов записей) базы данных InnoDB, которая может видеть до 20-50 операций чтения / сек.
Первая хорошая новость для вас - это то, что сейчас больше информации в эфирном пространстве, чем вы задавали тот же вопрос раньше, чем год назад. Я знаю это по горькому опыту.
Официальная линия Netapp заключается в том, что MySQL поддерживается всеми тремя протоколами.
ONTAP MySQL Enterprise NFS iSCSI FCP
7G 5.X Supported Supported Supported
7G 4.X Supported Supported Supported
MySQL Enterprise versions 4.X and 5.X are supported on all NetApp fabric
attached storage models running any release of Data ONTAP 7G for any server
platform supported by MySQL that is listed in the NetApp host compatibility
matrix for each protocol.
Вторая хорошая новость заключается в том, что вы не сказали MyISAM. В противном случае это была бы совсем другая и более мрачная история, состоящая из паршивой работы и никакой вспомогательной информации. Здесь нет большого выбора, кроме как использовать iSCSI или FCP на основе блоков. Не то, чтобы они не работали отлично, но они немного отличаются от файловых.
Вместо этого NetApp опубликовал несколько Тесты OLTP MySQL 5.0 по всем трем протоколам хранения. Результаты показывают, что механизмы InnoDB работают хорошо и соответствуют различиям протоколов, наблюдаемым в Oracle. FCP вышел вперед по производительности. В то время как iSCSI отставал от FCP на 9%, а NFS на 16%. Это не такая большая разница, как мы ожидали.
Еще полезнее то, что в том же документе подробно описаны конкретные шаги NFS и InnoDB, которые они предприняли для достижения этой контрольной цифры. К ним относятся изменение innodb_buffer_pool_size, innodb_flush_method, Таймаут кэширования атрибутов NFS, no_atime_update на исходном томе и (как сказал Ричард выше) указание разных точек монтирования для журналов.
Лично я бы не рекомендовал хранить журналы в другом хранилище, например, на локальном диске. Журналы тесно связаны с любыми данными, которые уже записаны на диск. Если вы полностью разделите их, вы можете подготовиться к падению. Более того, если вы хотите делать снимки, смените машину, на которой работает MySQL, или ваши локальные диски окажутся менее надежными, чем файлер.
С учетом всего сказанного, следующее лучшее, что вы можете сделать - это пососать и посмотреть. Настройте среду на основе лучших практик, изложенных в документе, и выполните несколько тестов с вашими собственными данными. Оцените, как он работает по сравнению с вашими локальными дисками сегодня.
-
NB: первая ссылка СЕЙЧАС ограничена. Вы не говорите, являетесь ли вы уже клиентом NetApp. Тем не менее, вы все равно сможете просмотреть вторую ссылку.
NFS4 было бы лучше, если бы вы могли его использовать. Я бы хоть монтировал без промедления. Вам также следует подумать об указании местоположения файлов журнала на локальных дисках. Если у вас нет локального хранилища (как это обычно бывает с виртуальной машиной), вы можете попытаться хранить журналы в точке подключения, которая маршрутизируется через другой сетевой интерфейс, чем ваше основное хранилище.
Лично я бы использовал iSCSI вместо NFS при монтировании диска из NetApp для MySQL. Невероятно эффективный, и вы получаете прямой доступ файловой системы к LUN.
Производительность фиксации MySQL InnoDB во многом зависит от того, насколько быстро базовый ввод-вывод может синхронизировать данные с диском; на это сильно влияет сетевая задержка, поэтому запуск MySQL через NFS будет иметь огромное значение, независимо от того, что это за сервер. Даже если ваша сеть работает максимально быстро, она все равно будет намного медленнее, чем локальный диск (я предполагаю, что ваш локальный диск будет здесь рейд-контроллером с батарейным питанием).
С другой стороны, производительность чтения в основном зависит от того, какая часть базы данных умещается в оперативной памяти. Если вы можете разместить всю базу данных в ОЗУ (или большую ее часть, в зависимости от шаблонов использования), тогда производительность будет очень хорошей, так как вы просто установите свой innodb_buffer_pool больше, чем данные, и теоретически чтение не будет когда-либо нужно было делать на NFS.
Пока вы не используете berkleydb, MySQL / InnoDB отлично работает с NFS. Я не уверен, что написано в документации NetApp NFS, но если вы смонтируете том NFS с параметром async, то приложение не будет заблокировано в ожидании записи на диск.