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 <in...@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/
