Bonjour la liste,
sur le papier, Galera Cluster semble parfait pour remplacer un ensemble de master-slaves sans avoir les coûts d'un NDB.
En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo.
Alors j'aimerais avoir des retours d'expériences, savoir si ça vaut le coup que j'investisse encore du temps ou si elle est encore clairement immature pour de la prod. Sachant qu'un cluster Galera coûte plus cher en terme de ressources dans certains cas, parce qu'il faut minimum 3 serveurs ce qui n'est pas le cas pour une partie de mon archi qui ne comprend qu'un master + un slave.
Aussi, avec l'arrivée des GTIDs, élire un slave master et reconfigurer les slaves devient très simple: STOP SLAVE; CHANGE MASTER TO MASTER_HOST="new_master"; START SLAVE;
Avez vous des retours en conditions réels ?
Bonjour,
Quelle est la version de Galera Cluster utilisée ? MySQL (5.5 ou 5.6) ? Ou MariaDB (5.5 ou 10) ?
Jocelyn
Le 28/11/2014 09:31, Greg a écrit :
Bonjour la liste,
sur le papier, Galera Cluster semble parfait pour remplacer un ensemble de master-slaves sans avoir les coûts d'un NDB.
En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo.
Alors j'aimerais avoir des retours d'expériences, savoir si ça vaut le coup que j'investisse encore du temps ou si elle est encore clairement immature pour de la prod. Sachant qu'un cluster Galera coûte plus cher en terme de ressources dans certains cas, parce qu'il faut minimum 3 serveurs ce qui n'est pas le cas pour une partie de mon archi qui ne comprend qu'un master + un slave.
Aussi, avec l'arrivée des GTIDs, élire un slave master et reconfigurer les slaves devient très simple: STOP SLAVE; CHANGE MASTER TO MASTER_HOST="new_master"; START SLAVE;
Avez vous des retours en conditions réels ?
Greg
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour.
En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo.
Lorsque je l'avais test, et il y a déjà un moment dans MariaDB, je n'ai pas remarque de segfault.
Peux tu effectivement nous en dire plus sur les versions que tu utilises, et aussi ce que tu as téléchargé, sur quel OS, etc ... ?
Cdlt
Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat "oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB" etc ...
Ce qui m'intéresse c'est un retour d'expérience en production.
Le 28 novembre 2014 10:36, Alexandre Legrix alex@bragonux.net a écrit :
Bonjour.
En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo.
Lorsque je l'avais test, et il y a déjà un moment dans MariaDB, je n'ai pas remarque de segfault.
Peux tu effectivement nous en dire plus sur les versions que tu utilises, et aussi ce que tu as téléchargé, sur quel OS, etc ... ?
Cdlt
On 11/28/14 10:44, Greg wrote:
Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat "oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB" etc ...
Ce qui m'intéresse c'est un retour d'expérience en production.
Ok alors sans entrer dans un debat de clocher puisque tu ne veux pas parler de version ... (Chose que je trouve débile, soit dit en passant) Sur des Gentoo (et/ou Debian) (Je ne dis pas la version) configurées aux petits oignons, avec des MariaDB (sans dire la version) Galera (pas de version du patch) dernière version de l’époque (mais je dis pas la date) (puisqu'on ne doit pas parler de version ....) , ça marchait en production sans segfault ! avec un datadir d'environ 20Gb
Tu vois a quel point c'est ridicule de ne pas vouloir donner de versions ?
</fin>
OK admettons alors voilà les versions : Debian Wheezy (à jour) MariaDB 5.5.40 et 10.1.1 (une seule version par Cluster) Du coup, c'est Galera 25.3.5.
Il faut que j'essayer avec MariaDB 10.0.15 qui est plus stable.
Le segfault était du à un problème avec des binlogs, je ne sais pas pourquoi. En supprimant tous les binlogs, je n'avais plus de segfault. En supprimant les options wsrep_% dans la config mysql et avant de supprimer ces binlogs, je n'avais plus les segfault. C'est donc le plugin Galera qui faisait segfaulter mysqld.
Sinon, c'est curieux, mais j'ai reçu des retours négatifs off-list, et uniquement off-list... - Le problème des écritures simultanées sur plusieurs nodes, qui causent des deadlocks, revient à chaque fois - On m'a aussi signalé des problèmes de synchro de nodes. - ce n'est visiblement pas adapté aux taux d'écritures trop élevés - finalement la gestion d'un ensemble master-slaves semble plus fiable et plus facile à gérer en cas de crash d'une ou plusieurs nodes - les quelques success-stories concernent des clusters avec un fort taux de lecture
Je vais continuer ma maquette, cette fois avec la version 10.0.15 de MariaDB, et ferais des tests supplémentaires sur la charge.
Bon week-end !
Le 28 novembre 2014 10:50, Alexandre Legrix alex@bragonux.net a écrit :
On 11/28/14 10:44, Greg wrote:
Je ne souhaite pas préciser les versions pour ne pas rentrer dans un débat "oui mais avec telle version de Percona ça marche par contre du coup tu n'auras pas la feature X de MariaDB" etc ...
Ce qui m'intéresse c'est un retour d'expérience en production.
Ok alors sans entrer dans un debat de clocher puisque tu ne veux pas parler de version ... (Chose que je trouve débile, soit dit en passant) Sur des Gentoo (et/ou Debian) (Je ne dis pas la version) configurées aux petits oignons, avec des MariaDB (sans dire la version) Galera (pas de version du patch) dernière version de l’époque (mais je dis pas la date) (puisqu'on ne doit pas parler de version ....) , ça marchait en production sans segfault ! avec un datadir d'environ 20Gb
Tu vois a quel point c'est ridicule de ne pas vouloir donner de versions ?
</fin>
Bonsoir.
Franchement, le point le plus gênant dans ce système de cluster, c'est l'effet "dominos" quand il y a un problème de synchro (encore plus quand on se retrouve avec une erreur humaine et des tables créées en MyISAM, alors là, c'est une boucherie), en 5 mins, tout le cluster tombe, et t'as gagné un bootstrap-pxc...
Je ne te cache pas que je suis d'accord avec les points que tu as résumé, ça représente mes 4 derniers mois à travailler sur cette techno.
Bonne soirée et bon weekend !
On 11/28/2014 07:02 PM, Greg wrote:
OK admettons alors voilà les versions : Debian Wheezy (à jour) MariaDB 5.5.40 et 10.1.1 (une seule version par Cluster) Du coup, c'est Galera 25.3.5.
Il faut que j'essayer avec MariaDB 10.0.15 qui est plus stable.
Le segfault était du à un problème avec des binlogs, je ne sais pas pourquoi. En supprimant tous les binlogs, je n'avais plus de segfault. En supprimant les options wsrep_% dans la config mysql et avant de supprimer ces binlogs, je n'avais plus les segfault. C'est donc le plugin Galera qui faisait segfaulter mysqld.
Sinon, c'est curieux, mais j'ai reçu des retours négatifs off-list, et uniquement off-list...
- Le problème des écritures simultanées sur plusieurs nodes, qui
causent des deadlocks, revient à chaque fois
- On m'a aussi signalé des problèmes de synchro de nodes.
- ce n'est visiblement pas adapté aux taux d'écritures trop élevés
- finalement la gestion d'un ensemble master-slaves semble plus fiable
et plus facile à gérer en cas de crash d'une ou plusieurs nodes
- les quelques success-stories concernent des clusters avec un fort
taux de lecture
Je vais continuer ma maquette, cette fois avec la version 10.0.15 de MariaDB, et ferais des tests supplémentaires sur la charge.
Bon week-end !
Le 28 novembre 2014 10:50, Alexandre Legrix <alex@bragonux.net mailto:alex@bragonux.net> a écrit :
On 11/28/14 10:44, Greg wrote: > Je ne souhaite pas préciser les versions pour ne pas rentrer dans un > débat "oui mais avec telle version de Percona ça marche par contre du > coup tu n'auras pas la feature X de MariaDB" etc ... > > Ce qui m'intéresse c'est un retour d'expérience en production. > Ok alors sans entrer dans un debat de clocher puisque tu ne veux pas parler de version ... (Chose que je trouve débile, soit dit en passant) Sur des Gentoo (et/ou Debian) (Je ne dis pas la version) configurées aux petits oignons, avec des MariaDB (sans dire la version) Galera (pas de version du patch) dernière version de l’époque (mais je dis pas la date) (puisqu'on ne doit pas parler de version ....) , ça marchait en production sans segfault ! avec un datadir d'environ 20Gb Tu vois a quel point c'est ridicule de ne pas vouloir donner de versions ? </fin>-- Greg
Liste de diffusion du FRsAG http://www.frsag.org/
Voici un retour d'expérience en prod que j'ai interrogé le mois dernier http://alx-communication.over-blog.com/article-le-fournisseur-d-acces-a-inte... Il te manquera sans doute des précisions techniques, mais au cas où je peux faire remonter tes questions à Codership
Véro
Le 28/11/2014 09:31, Greg a écrit :
Bonjour la liste,
sur le papier, Galera Cluster semble parfait pour remplacer un ensemble de master-slaves sans avoir les coûts d'un NDB.
En pratique, sur une maquette avec des vrais serveurs physiques et des vrais données venant de la prod, je me prends des segfault, des arrêts brutaux de mysqld, et une resynchro plutot aléatoire ... alors que cette solution est vendue pour améliorer la haute-dispo.
Alors j'aimerais avoir des retours d'expériences, savoir si ça vaut le coup que j'investisse encore du temps ou si elle est encore clairement immature pour de la prod. Sachant qu'un cluster Galera coûte plus cher en terme de ressources dans certains cas, parce qu'il faut minimum 3 serveurs ce qui n'est pas le cas pour une partie de mon archi qui ne comprend qu'un master + un slave.
Aussi, avec l'arrivée des GTIDs, élire un slave master et reconfigurer les slaves devient très simple: STOP SLAVE; CHANGE MASTER TO MASTER_HOST="new_master"; START SLAVE;
Avez vous des retours en conditions réels ?
Greg
Liste de diffusion du FRsAG http://www.frsag.org/
--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. http://www.avast.com
-
Alexandre Legrix -
Cyril Lavier -
Greg -
jocelyn fournier -
veronique Loquet - AL'X Communication