Могу ли я запустить mysql поверх glusterfs?

Я недавно играл с glusterfs.

Я хочу попробовать запустить mysqld поверх glusterfs точно так же, как это возможно для запуска MySQL поверх DRBD.

Я знаком с репликацией MySQL и преимуществами ее использования вместо этого подхода, а также знаю о MongoDB и других решениях NoSQL.

Тем не менее, это было бы простым решением для нескольких конкретных проектов, над которыми я работаю, если бы я мог оставить MySQL как есть и воспроизвести базовую файловую систему.

Возможно ли это, и если это возможно, то где я могу узнать, как это сделать?

Я выяснил это методом проб и ошибок из-за достаточно долгой задержки без ответов.

Ответ: да, я могу запустить mysqld поверх glusterfs.

Я установил это в Ubuntu и вкратце вот шаги:

Установить Ubuntu
Установите и настройте glusterfs
Установить mysql-server
Настройте /etc/mysql/my.cnf для установки datadir / mnt / glusterfs вместо / var / lib / mysql
Настроить базы данных
Настроить AppAmor чтобы позволить вышеуказанному работать (или отключить аппамор)

Настоящая проблема заключается в том, как MySQL обрабатывает блокировки.

Однако вы можете передать все это glusterfs для обработки, чтобы многие процессы mysqld (работающие на отдельных узлах) могли обращаться к одним и тем же файлам базы данных на / mnt / glusterfs. Вы должны это внимательно прочитать.

Отключить кеш запросов, включить внешнюю блокировку и отключить задержку записи.

Попытался сделать это на кластере K8. MySQL работает внутри контейнера, GlusterFS устанавливается непосредственно на узел (неконтейнерный). Контейнер MySQL имел привязку, настроенную на то, чтобы всегда работать на том же узле, что и GFS, монтируя том с использованием собственного драйвера тома GFS K8.

Произошла случайная высокая задержка для сайтов WordPress даже при включенном кешировании NGINX FastCGI (PHP-FPM). После переключения на том hostPath для контейнера MySQL проблемы с задержкой исчезли.

Я не думаю, что это возможно. Ричард, ссылка, которую вы предоставили, говорит о MyIsam, и они говорят, что это в любом случае не рекомендуется. Я где-то читал (не помню где), что использование файлов innoDB, совместно используемых несколькими узлами, приведет к повреждению данных.

Я не знаю, почему вы хотите получить доступ к одним и тем же файлам БД из разных серверных процессов MySQL, но если причина в производительности, вам следует взглянуть на Galera.

http://www.codership.com/content/using-galera-cluster

Интегрирован в Maria DB и Percona XTRA DB Cluster

Теоретически можно. На практике, особенно в отношении производительности, руководство Gluster предполагает, что он не предназначен для использования для репликации файлов БД или других систем мелкозернистого ввода-вывода.

Смотрите официальный обзор Gluster здесь:

http://docs.gluster.org/en/latest/Install-Guide/Overview/#is-gluster-going-to-work-for-me-and-what-i-need-it-to-do

Подойдет ли мне Gluster и для чего он нужен?

... С другой стороны, добавив достаточное количество серверов Gluster в микс, некоторые люди увидели у нас лучшую производительность, чем другие решения, из-за горизонтального масштабирования технологии - Gluster не поддерживает так называемые «структурированные данные», то есть живые , Базы данных SQL. Конечно, можно было бы использовать Gluster для резервного копирования и восстановления базы данных - Gluster традиционно лучше работает при использовании файлов размером не менее 16 КБ (с оптимальным соотношением около 128 КБ или около того).

Еще раз, если вы хотите репликацию MySQL, я предлагаю:

Используйте традиционную репликацию MySQL Master / Slave https://dev.mysql.com/doc/refman/5.7/en/replication.html
Используйте кластер Codership Galera, который сегодня реализован во всех разновидностях MySQL, таких как Oracle MySQL или MariaDB.