Le 18/05/2015 16:33, Jeremie Le Hen a écrit :
Une idée pour avoir le meilleur des deux mondes ?
Si tu l'as, garde là pour toi et vend là, tu deviendras riche ;).
OK, donc on est d'accords. Reliability, simplicity, cost, pick two.
Trève de plaisanterie, comme je disais dans l'autre mail que j'ai envoyé
aujourd'hui dans ce même thread, tu peux peut-être utiliser les deux :
- réplication synchrone pour les base de données
- réplication asynchrone (zfs send/recv, rsync, whatever) pour le reste
De toute façon, pour une base de données, il faudra obligatoirement
répliquer le journal de façon synchrone pour ne pas perdre de données.
Tu peux peut-être créer un setup qui ne réplique que le journal (il
existe d'ailleurs peut-être des technos native avec ta base de données
permettant de faire ça, ou alors tu devras le faire en mettant le
journal sur un device spécifique tu répliques à l'aide de DRBD ou HAST),
et ensuite lors d'un failover tu le rejoues au dessus de la dernière
synchro (asynchrone) du fichier data de la base de données.
Mais bon voilà, rien qu'à lire le bloc de texte ci-dessus, ça sent le
truc compliqué. Je ne dis pas que ce n'est pas à faire, mais il faut
vraiment que ce soit justifié et pas uniquement pour la performance
technique (jeu de mot intentionel). Cela étant dit, si tu veux faire un
truc dans ce genre avec du MySQL ou du MariaDB, je suis sûr que certains
outils Percona existent pour simplifier le tout. Mais ça reste
complexe.
Donc mon cas particulier, je ne maîtrise pas ce que mon client fait de sa VM, ce qui m'oblige à faire du synchrone, tant pis pour la perf. Ce qui finalement, n'interdit pas de le faire le mieux possible. Quid de l'incidence de stockage SSD ou hybrid par exemple ?
Donc, on en revient à DRBD. Je vous laisse décider si HAST est mieux ou moins bien, perso, j'ai eu suffisamment d'emmerdes avec DRBD pour considérer que je connais pas trop mal le produit maintenant.
CQFD ?
Julien
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/