Puis-je exécuter mysqld sur glusterfs?

J'ai joué avec des glusterfs récemment.

Ce que je veux essayer, c'est d'exécuter mysqld sur les glusterfs de la même manière qu'il est possible d'exécuter MySQL sur DRBD .

Je connais la réplication MySQL et les avantages de l'utiliser au lieu de cette approche et je connais également MongoDB et d'autres solutions NoSQL.

Cependant, ce serait une solution facile à quelques projets spécifiques que j'ai à venir si je pouvais laisser MySQL tel quel et répliquer le système de fichiers sous-jacent.

Est-ce possible et si c'est le cas, où puis-je savoir comment?

En raison d'un délai raisonnablement long sans réponse, je l'ai découvert par essais et erreurs.

La réponse est: oui, je peux exécuter mysqld sur glusterfs.

J'ai configuré cela sur Ubuntu et voici brièvement les étapes:

• Installez Ubuntu
• Installer et configurer glusterfs
• Installer mysql-server
• Configurez /etc/mysql/my.cnf pour définir datadir / mnt / glusterfs au lieu de / var / lib / mysql
• Configurer les bases de données
• Configurer AppAmor pour permettre à ce qui précède de fonctionner (ou désactiver l'appamor)

Le vrai problème vient de la façon dont MySQL gère les verrous.

Cependant, vous pouvez transmettre tout cela à glusterfs pour que de nombreux processus mysqld (exécutés sur des nœuds séparés) puissent accéder aux mêmes fichiers de base de données sur / mnt / glusterfs. Vous devez lire ceci attentivement .

• Désactivez le cache de requêtes, activez le verrouillage externe et désactivez les délais d'écriture .

A tenté cela sur un cluster K8. MySQL fonctionnant à l'intérieur d'un conteneur, GlusterFS installé directement sur le nœud (non conteneurisé). Le conteneur MySQL avait une affinité définie pour toujours s'exécuter sur le même nœud que GFS, en montant le volume à l'aide du pilote de volume GFS natif de K8.

Latence élevée aléatoire expérimentée pour les sites WordPress, même avec la mise en cache NGINX FastCGI (PHP-FPM) activée. Passé au volume hostPath pour le conteneur MySQL, les problèmes de latence ont disparu.

Je ne pense pas que ce soit possible. Richard, le lien que vous avez fourni parle de MyIsam et ils disent que ce n'est pas recommandé de toute façon. J'ai lu quelque part (je ne me souviens pas où) que l'utilisation de fichiers innoDB partagés par plusieurs nœuds entraînerait une corruption des données.

Je ne sais pas pourquoi vous souhaitez accéder aux mêmes fichiers DB à partir de différents processus de serveur MySQL mais si la raison est la performance, vous devriez jeter un œil à Galera.

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

Intégré dans Maria DB et Percona XTRA DB Cluster

En théorie, vous le pouvez. Dans la pratique et en particulier en ce qui concerne les performances, le manuel Gluster suggère qu'il n'est pas destiné à être utilisé pour répliquer des fichiers DB ou d'autres systèmes d'E / S à grain fin.

Voir l'aperçu officiel de Gluster ici:

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

Est-ce que Gluster va travailler pour moi et ce que j'en ai besoin?

... D'un autre côté, en ajoutant suffisamment de serveurs Gluster dans le mélange, certaines personnes ont vu de meilleures performances avec nous que d'autres solutions en raison de la nature évolutive de la technologie - Gluster ne prend pas en charge les soi-disant «données structurées», c'est-à-dire en direct , Bases de données SQL. Bien sûr, utiliser Gluster pour sauvegarder et restaurer la base de données serait bien - Gluster est traditionnellement meilleur lorsque vous utilisez des tailles de fichier d'au moins 16 Ko (avec un sweet spot autour de 128 Ko environ).

Encore une fois, si vous voulez avoir une réplication MySQL, je vous suggère:

1. Utilisez la réplication MySQL maître / esclave traditionnelle https://dev.mysql.com/doc/refman/5.7/en/replication.html

2. Utilisez le cluster Codership Galera qui est aujourd'hui implémenté dans toutes les versions de MySQL comme Oracle MySQL ou MariaDB