Bonjour à tous, Actuellement, nous avons un cluster Sql sous MariaDB avec 3 machines, 1 master, 2 slave. Les écritures sont réalisées via un load balancer qui n'a qu'un backend, le master. Il y a tout un système géré avec MHA, je ne vais rentrer dans les détails. Pour les lectures, on passe par un load balancer avec 3 backend, les 2 slaves + le master. Il arrive par moment, que nous ayons beaucoup de données à synchroniser, il peut y avoir un décalage entre le master et les slaves. Ma question : nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture. Ma solution est-elle adaptée ? Si oui comme puis-je le justifier "officiellement" ? Alex.
Hello, De mon point de vue, tu n'as pas la garantie que les slaves soient synchros au meme moment non plus. En effet, si ce sont des VM (pas précisé) et que les disques ou les ressources aient des disponibilités différentes tu peux aboutir à une différence. Cependant, c'est un cas d'utilisation qui ne m'est pas encore vraiment arrivé et pour affirmer de manière certaine, il faudrait que je teste sur un jeu de test. Cordialement.
Les 3 machines sont identiques, 24 cpu, 132 Go de RAM, fusion-io. Il semblerait que nos ayons trop d'entrées dans nos tables (plusieurs millions), mm le parallel replication n'a pas corrigé le problème. Alex. On 27/05/15 10:16, Mihamina Rakotomandimby wrote:
Hello,
De mon point de vue, tu n'as pas la garantie que les slaves soient synchros au meme moment non plus. En effet, si ce sont des VM (pas précisé) et que les disques ou les ressources aient des disponibilités différentes tu peux aboutir à une différence.
Cependant, c'est un cas d'utilisation qui ne m'est pas encore vraiment arrivé et pour affirmer de manière certaine, il faudrait que je teste sur un jeu de test.
Cordialement. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut, as tu regardé du côté de chez Percona https://www.percona.com/ Il y a des tools pur l'analyse par exemple. Cordialement. Le 27/05/2015 10:18, Alexandre a écrit :
Les 3 machines sont identiques, 24 cpu, 132 Go de RAM, fusion-io. Il semblerait que nos ayons trop d'entrées dans nos tables (plusieurs millions), mm le parallel replication n'a pas corrigé le problème.
Alex.
On 27/05/15 10:16, Mihamina Rakotomandimby wrote:
Hello,
De mon point de vue, tu n'as pas la garantie que les slaves soient synchros au meme moment non plus. En effet, si ce sont des VM (pas précisé) et que les disques ou les ressources aient des disponibilités différentes tu peux aboutir à une différence.
Cependant, c'est un cas d'utilisation qui ne m'est pas encore vraiment arrivé et pour affirmer de manière certaine, il faudrait que je teste sur un jeu de test.
Cordialement. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le Wed, May 27, 2015 at 10:06:03AM +0200, Alexandre [infos@opendoc.net] a écrit: [...]
Ma question : nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture.
As-tu des "lecteurs" différents ? Si oui, il faudrait regarder si tu as la possibilité de conifgurer une forme de persistence pour que des requêtes successives venant d'un même client soient dirigées vers le même serveur. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Ma question : nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture.
A l'inverse, est-ce que ton load balancer ne saurait pas évaluer la fraicheur et ou la cohérence (mécanisme de quorum?) des données et du coup renvoyer vers le(s) bon(s) serveur(s) ? Le risque étant qu'il renvoie tout et tout le temps vers le master et donc les slaves ne servent plus à grand chose :-/ Je ne connais ni MariaDB ni MySQL en mode cluster ; donc c'est vraiment une réflexion à voix haute.
On 2015-05-27 10:18, Nicolas Steinmetz wrote:
Ma question : nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture.
A l'inverse, est-ce que ton load balancer ne saurait pas évaluer la fraicheur et ou la cohérence (mécanisme de quorum?) des données et du coup renvoyer vers le(s) bon(s) serveur(s) ? Le risque étant qu'il renvoie tout et tout le temps vers le master et donc les slaves ne servent plus à grand chose :-/
L'Etat de l'Art dans ces situation est d'avoir une limite de fraicheur sur tes slaves. Si ils sont plus de X secondes en retard, le LB les retire du pool, ils n'ont plus a servire de requetes, et donc ont plus de temps pour recuperer et rattraper le train. Une fois a jour, ils sont reintégrés dans le pool. A toi de voir ce que tu considere comme acceptable pour X : 3s, 10s, 30s ... -- Thomas Pedoussaut
J'y avais pensé, en plus c'est pas compliqué, mais on perd la notion de disponibilité. Si pendant un décalage, on perd le master, on a une coupure de service et non un service dégradé. Alex. On 27/05/15 10:51, Thomas Pedoussaut wrote:
On 2015-05-27 10:18, Nicolas Steinmetz wrote:
Ma question : nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture.
A l'inverse, est-ce que ton load balancer ne saurait pas évaluer la fraicheur et ou la cohérence (mécanisme de quorum?) des données et du coup renvoyer vers le(s) bon(s) serveur(s) ? Le risque étant qu'il renvoie tout et tout le temps vers le master et donc les slaves ne servent plus à grand chose :-/
L'Etat de l'Art dans ces situation est d'avoir une limite de fraicheur sur tes slaves. Si ils sont plus de X secondes en retard, le LB les retire du pool, ils n'ont plus a servire de requetes, et donc ont plus de temps pour recuperer et rattraper le train. Une fois a jour, ils sont reintégrés dans le pool.
A toi de voir ce que tu considere comme acceptable pour X : 3s, 10s, 30s ...
Salut, Sinon tout simplement deux comptes de lectures, un pouvant être désynchro et l'autre pour les lectures qui ont besoin de données fraiches à tout prix et donc qui tape le master directement. Aurélien Le 27 mai 2015 11:07, Alexandre <infos@opendoc.net> a écrit :
J'y avais pensé, en plus c'est pas compliqué, mais on perd la notion de disponibilité. Si pendant un décalage, on perd le master, on a une coupure de service et non un service dégradé.
Alex.
On 27/05/15 10:51, Thomas Pedoussaut wrote:
On 2015-05-27 10:18, Nicolas Steinmetz wrote:
Ma question :
nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture.
A l'inverse, est-ce que ton load balancer ne saurait pas évaluer la fraicheur et ou la cohérence (mécanisme de quorum?) des données et du coup renvoyer vers le(s) bon(s) serveur(s) ? Le risque étant qu'il renvoie tout et tout le temps vers le master et donc les slaves ne servent plus à grand chose :-/
L'Etat de l'Art dans ces situation est d'avoir une limite de fraicheur sur tes slaves. Si ils sont plus de X secondes en retard, le LB les retire du pool, ils n'ont plus a servire de requetes, et donc ont plus de temps pour recuperer et rattraper le train. Une fois a jour, ils sont reintégrés dans le pool.
A toi de voir ce que tu considere comme acceptable pour X : 3s, 10s, 30s ...
_______________________________________________
Liste de diffusion du FRsAG http://www.frsag.org/
Idéalement, la données fraiche on a besoin tout le temps, ce qui est impactant c'est d'avoir des sorties de traitements différents car à un moment T on a des données différentes en entrée. On 27/05/15 11:54, Aurélien Bras wrote:
Salut,
Sinon tout simplement deux comptes de lectures, un pouvant être désynchro et l'autre pour les lectures qui ont besoin de données fraiches à tout prix et donc qui tape le master directement.
Aurélien
Le 27 mai 2015 11:07, Alexandre <infos@opendoc.net <mailto:infos@opendoc.net>> a écrit :
J'y avais pensé, en plus c'est pas compliqué, mais on perd la notion de disponibilité. Si pendant un décalage, on perd le master, on a une coupure de service et non un service dégradé.
Alex.
On 27/05/15 10:51, Thomas Pedoussaut wrote:
On 2015-05-27 10:18, Nicolas Steinmetz wrote:
Ma question : nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture.
A l'inverse, est-ce que ton load balancer ne saurait pas évaluer la fraicheur et ou la cohérence (mécanisme de quorum?) des données et du coup renvoyer vers le(s) bon(s) serveur(s) ? Le risque étant qu'il renvoie tout et tout le temps vers le master et donc les slaves ne servent plus à grand chose :-/
L'Etat de l'Art dans ces situation est d'avoir une limite de fraicheur sur tes slaves. Si ils sont plus de X secondes en retard, le LB les retire du pool, ils n'ont plus a servire de requetes, et donc ont plus de temps pour recuperer et rattraper le train. Une fois a jour, ils sont reintégrés dans le pool.
A toi de voir ce que tu considere comme acceptable pour X : 3s, 10s, 30s ...
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, peux tu gérer ce cas au niveau applicatif ? Si oui, lors d'une écriture sur le master, tu peux récupérer sa position (unique) avec "SHOW MASTER STATUS", et la stocker dans une variable du batch ou dans un Redis par exemple. Puis, quand tu veux lire sur le slave, tu peux lui demander d'attendre que cette position soit répliqués sur lui-même, avant de lire: https://mariadb.com/kb/en/mariadb/master_pos_wait/ SELECT MASTER_POS_WAIT(log_name,log_pos[,timeout); Dans le même genre mais moins sûr et plus facile, avec SHOW SLAVE STATUS sur le slave tu peux vérifier la colonne Seconds_Behind_Master, si elle est à zéro c'est que tu es (surement) synchro avec le master. Tu as aussi le plugin de réplication semi-synchrone https://mariadb.com/kb/en/mariadb/semisynchronous-replication/ mais il ne résoudra pas du tout le problème. Mais il peut t'être utile quand même. Greg Le 27 mai 2015 13:18, Alexandre <infos@opendoc.net> a écrit :
Idéalement, la données fraiche on a besoin tout le temps, ce qui est impactant c'est d'avoir des sorties de traitements différents car à un moment T on a des données différentes en entrée.
On 27/05/15 11:54, Aurélien Bras wrote:
Salut,
Sinon tout simplement deux comptes de lectures, un pouvant être désynchro et l'autre pour les lectures qui ont besoin de données fraiches à tout prix et donc qui tape le master directement.
Aurélien
Le 27 mai 2015 11:07, Alexandre <infos@opendoc.net <mailto:infos@opendoc.net>> a écrit :
J'y avais pensé, en plus c'est pas compliqué, mais on perd la notion de disponibilité. Si pendant un décalage, on perd le master, on a une coupure de service et non un service dégradé.
Alex.
On 27/05/15 10:51, Thomas Pedoussaut wrote:
On 2015-05-27 10:18, Nicolas Steinmetz wrote:
Ma question : nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture.
A l'inverse, est-ce que ton load balancer ne saurait pas évaluer la fraicheur et ou la cohérence (mécanisme de quorum?) des données et du coup renvoyer vers le(s) bon(s) serveur(s) ? Le risque étant qu'il renvoie tout et tout le temps vers le master et donc les slaves ne servent plus à grand chose :-/
L'Etat de l'Art dans ces situation est d'avoir une limite de fraicheur sur tes slaves. Si ils sont plus de X secondes en retard, le LB les retire du pool, ils n'ont plus a servire de requetes, et donc ont plus de temps pour recuperer et rattraper le train. Une fois a jour, ils sont reintégrés dans le pool.
A toi de voir ce que tu considere comme acceptable pour X : 3s, 10s, 30s ...
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Greg
Hello, question bête mais avez-vous testé la réplication synchronisée de MariaDB ? (via “Galera Cluster”). Elle exploite un système de quorum et devrait maintenir l'intégrité des données sans problème. À voir ce que ça donne niveau perf. Le mercredi 27 mai 2015 à 10:06 +0200, Alexandre a écrit :
Bonjour à tous,
Actuellement, nous avons un cluster Sql sous MariaDB avec 3 machines, 1 master, 2 slave.
Les écritures sont réalisées via un load balancer qui n'a qu'un backend, le master. Il y a tout un système géré avec MHA, je ne vais rentrer dans les détails.
Pour les lectures, on passe par un load balancer avec 3 backend, les 2 slaves + le master.
Il arrive par moment, que nous ayons beaucoup de données à synchroniser, il peut y avoir un décalage entre le master et les slaves.
Ma question : nous sommes passé par un cluster SQL pour plus de disponibilité, mais nous avons perdu en "cohérence" des données. Dans notre contexte, ce n'est pas forcément grave qu'il y est un décalage, mais c'est impactant qu'il y a une "incohérence" des données. A un moment T, le master est à jour et pas les slaves, on a 1 chance sur 3, d'avoir une données différentes. Ma solution serait de retirer le master des backend de lecture.
Ma solution est-elle adaptée ? Si oui comme puis-je le justifier "officiellement" ?
Alex.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 27/05/2015 12:24, Olivier Bonvalet a écrit :
question bête mais avez-vous testé la réplication synchronisée de MariaDB ? (via “Galera Cluster”). Elle exploite un système de quorum et devrait maintenir l'intégrité des données sans problème.
À voir ce que ça donne niveau perf.
En terme de perfs, c'est désastreux. On avait pensé faire ça dans ma boite actuelle et on avait des perfs en lecture/écriture 10 fois moins bonnes. Sans compter que les id ne sont plus sous la forme d'un int qui s'incrémente de 1, ça peut ne pas passer sur certaines applis (c'était notre cas). Je pense que si tu veux faire de la réplication sur internet avec des sites très distants avec du gros cache pour la lecture ça peut valoir le coup, mais je suis pas dans ce cas de figure et je pense que sharder sa base est probablement une meilleure idée dans la plupart des cas. -- Benjamin Boudoir
Un bon HAProxy, avec l'agent check, ca peut répondre au besoin de detection d'un lag dans le cluster. Un exemple chez nos amis de Percona: https://www.percona.com/blog/2014/12/18/making-haproxy-1-5-replication-lag-a... Baptiste
Sacré Baptiste, toujours là pour nous vanter les mérites d'HAProxy ''), mais c'est justifié, je pense que c'est ca qu'il nous faut. Pas certain que je trouve quelque chose d'équivalent sur LVS (que nous utilisons). Merci à tous pour vos retours qui sont toujours de qualités. Alex. On 27/05/15 22:17, Baptiste wrote:
Un bon HAProxy, avec l'agent check, ca peut répondre au besoin de detection d'un lag dans le cluster. Un exemple chez nos amis de Percona: https://www.percona.com/blog/2014/12/18/making-haproxy-1-5-replication-lag-a...
Baptiste _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On nous avait fait le mm retour, ce que tu gagnes en cohérence tu le perds en perf ... On 27/05/15 17:15, Benjamin Boudoir wrote:
Le 27/05/2015 12:24, Olivier Bonvalet a écrit :
question bête mais avez-vous testé la réplication synchronisée de MariaDB ? (via “Galera Cluster”). Elle exploite un système de quorum et devrait maintenir l'intégrité des données sans problème.
À voir ce que ça donne niveau perf.
En terme de perfs, c'est désastreux. On avait pensé faire ça dans ma boite actuelle et on avait des perfs en lecture/écriture 10 fois moins bonnes. Sans compter que les id ne sont plus sous la forme d'un int qui s'incrémente de 1, ça peut ne pas passer sur certaines applis (c'était notre cas). Je pense que si tu veux faire de la réplication sur internet avec des sites très distants avec du gros cache pour la lecture ça peut valoir le coup, mais je suis pas dans ce cas de figure et je pense que sharder sa base est probablement une meilleure idée dans la plupart des cas.
participants (11)
-
Alexandre -
Antoine GANCEL -
Aurélien Bras -
Baptiste -
Benjamin Boudoir -
Dominique Rousseau -
Greg -
Mihamina Rakotomandimby -
Nicolas Steinmetz -
Olivier Bonvalet -
Thomas Pedoussaut