Il faut en effet savoir quelles données sont hébergées sur le serveur et quelle sont leur criticité, une réplication synchrone en master/master (ex: Galera) ou semi-synchrone en master/slave (existe sous MariaDB mais il me semble que c'est en beta) diminuera les performances en utilisation normale et rendra plus complexe la gestion "de base".
Si c'est une base de données stockant des informations de paiement/facturation il est en effet important d'avoir un clone en temps réel de la base de prod car perdre des données dans ce type d'environnement n'est pas acceptable mais si les données qui seraient perdues en cas de perte du master sont principalement des stats de visite et des commentaires sur un site web, c'est déjà bien plus acceptable.
Dans le post initial, il est aussi question d'une alternative a Oracle Flashback, il est possible d'avoir un miroir "dans le temps" d'un serveur en utilisant de la réplication master/slave avec un délai au niveau de l'application du binlog. Ça peut être fait avec l'outil "pt-slave-delay" de Percona Toolkit ou sur les versions récentes de MySQL 5.6+ avec "CHANGE MASTER TO ... MASTER_DELAY" qui est prévu pour être backporté sur MariaDB 10.1.
Pour ceux qui ne connaissent pas encore, il y à un nouveau produit de MariaDB qui viens de sortir : Maxscale ; c'est un proxy SQL un peu à la manière de Varnish pour le web qui permet entre autres de faire du cache, du load balancing, du read/write splitting, du sharding (envoyer en fonction de la requête vers un/des serveur(s) spécifique(s)), loguer certaines requêtes, rewrite de requêtes. Je n'ai pas encore testé mais sur le papier c'est très sympa et ça n'à pas l'air trop complexe à utiliser.
Le 20/01/2015 14:15, jr@captainadmin.com a écrit :
Pour un PRA 2h, il faut monter une infra similaire sur un autre site et pouvoir la lancer ou effectuer une bascule dessus une fois que ton analyse montrera l'indisponibilité complète de la production. 1- tu détectes l'incident 2- analyse et visuel du niveau d'impact 3- résolution soit avec une restauration partielle soit en basculant sur ton système "PRA" qui fonctionne sur un autre site.
Dans quasiment tous les cas de résolution, si tu dois respecter 2h entre la détection et la résolution, il faut que ton infra soit dupliquée et fonctionnelle dans un environnement indépendant. Il faudra effectuer des bascules régulières pour vérifier le bon fonctionnement du PRA en cas de panne importante.
Le 20-01-2015 14:05, Dominique Rousseau a écrit :
Le Tue, Jan 20, 2015 at 12:32:33PM +0100, jean-yves@lenhof.eu.org [jean-yves@lenhof.eu.org] a écrit: [...]
On me demande en effet une disponibilité à 99% sur une année et un PRA exécutable en 2h (99% sur une infra VMWARE ne me parait pas si difficle, mais c'est plus ce dernier point de 2h qui me tracasse le plus, deux heures en pleine nuit, cela va très vite entre le réveil, la prise d'appels, le diagnostic et ensuite seulement l'action !).
Pour la HA, y'a eu plein de réponses. Ton plus gros problème, c'est ton histoire de « PRA exécutable en 2h ». Ça couvre quoi ? La boulette humaine qui supprime des données ? La destruction totale de la salle machine hébergeant le cluster ? Il faut avoir mis en route la restauration d'une sauvegarde en 2h, et tant pis si tous les délais sont explosés parcequ'elle met 8h à se charger ? Bref, c'est très vague de parler de PRA sans en préciser le périmètre :)