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 <in...@opendoc.net
<mailto: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/

Répondre à