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