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