Bonjour,

je plussois les propos de Frédéric concernant MySQL, Galera cluster est vraiment galère en conditions réels.
Par contre, une réplication simple sur le moteur InnoDB fonctionne juste à merveille, et encore mieux avec les GTIDs (MariaDB 10 et MySQL 5.6). Des scripts comme MHA (1) fonctionnent parfaitement tant qu'il n'y a pas de réplication en cascade (master --> master/slave ---> slaves). Evites MyISAM.
MHA te permet une bascule d'un ensemble master-slaves en moins d'une minute, automatique ou à la demande.

En solution confort (et donc €€) tu trouveras MySQL Cluster qui n'a rien à voir avec MySQL mais qui est la solution number one si tu as le budget ET si tes données tiennent toutes en RAM. Donc à oublier si ce sont les mêmes données que pour Frédéric qui parle de tera-octets.

Au cas où, la config qui va bien sur un master MySQL:
innodb_flush_log_at_trx_commit  = 1
sync_binlog                     = 1

et la config pour un slave MySQL qui n'a pas les GTIDs (si la réplic est en GTID, tu peux laisser les valeurs par défaut) :
relay_log_recovery          = ON
sync_relay_log              = 1
sync_relay_log_info         = 1
sync_master_info            = 1

Je suis en plein dedans et c'est ce qui explique que je suis en train de mettre à jour 10 masters et 30 slaves en MariaDB 10.0.


Greg


Le 20 janvier 2015 13:14, Frederic de Villamil <frederic@de-villamil.com> a écrit :
>
> On 20 Jan 2015, at 13:02, Pierre DOLIDON <sn4ky@sn4ky.net> wrote:
>
> En ce qui concerne du mysql-like, regarde du côté de galera cluster.
>
> Sinon, tu peux envisager une réplication mysql master-master, et faire pointer les appli sur une IP gérée par un keepalived ou quelque chose comme ça.
>
> évidemment, il faut supervision l'ensemble et vérifier que les synchros sont opérationnelles entre les 2 mysql.

Bonjour,

Je vais répondre pour MySQL.

Concernant Galera, j’en ai 3 clusters en prod dont un de 1T et un de 18T (une seule base à chaque fois) et la solution porte particulièrement bien son nom. Le seul intérêt est la réplication synchrone et l’écriture sur n’importe quel node si tu en as vraiment besoin, pour tout le reste, c’est une horreur.

Concernant la réplication master / master, ce n’est pas forcément une idée géniale parce que ça appuie pas mal sur les I/O et tout le monde ne peut pas mettre 20T en SSD sur ses machines.

J’ai en revanche pas mal d’expérience avec de la réplication master / slave multi site, VIP et fail over automatique. Le truc est de trigger un script qui effectue un reset sur le slave pour le transformer en master quand la bascule se fait. Ça marche (bien), et j’ai tenu 6 ans avec ça (et des trucs bien plus exotiques, dont du master / multi slave derrière un haproxy, une IP de lecture, une d’écriture, retrait du pool dès que le seconds_behind_master > 0 et un fail over en lecture sur le master). Ça demande un peu de tuning, mais ça a pas mal d’avantages, le principal étant d’être gratuit.

Une fois encore ton problème en termes de PRA va être le transfert de données. Le problème n’est pas tant d’expérience la perte d’un noeud qu’un drop / delete malheureux ou une corruption de données. Et là, ça devient franchement compliqué d’avoir une GTR courte sur de gros volumes (on parle, une fois encore, de Tera de données). Et Xtrabackup est loin d’être parfait pour du backup / restore à chaud (j’ai perdu 20h y’a pas longtemps parce qu’il n’arrivait pas à prendre le lock exclusif sur la base qu’il dupliquait).

Mes deux cents,
Fred

--
Frederic de Villamil / @fdevillamil
http://t37.net


_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/




--
Greg