Чи можна запустити mysqld поверх glusterfs?

Я нещодавно грав з глюстерфами.

Що я хочу спробувати - це запустити mysqld поверх glusterfs аналогічним чином, як це можливо, запустити MySQL поверх DRBD .

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

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

Чи можливо це, і якщо це де я можу дізнатися як?

Через досить тривалу затримку, без відповідей, я дізнався шляхом спроб та помилок.

Відповідь: Так, я можу запустити mysqld поверх glusterfs.

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

• Встановіть Ubuntu
• Встановлення та налаштування glusterfs
• Встановити mysql-сервер
• Налаштуйте /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, пропоную:

1. Використовуйте традиційну реплікацію MySQL Master / Slave https://dev.mysql.com/doc/refman/5.7/uk/replication.html

2. Використовуйте кластер Codership Galera, який сьогодні реалізується в усіх ароматах MySQL, таких як Oracle MySQL або MariaDB