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, j...@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-y...@lenhof.eu.org
[jean-y...@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 :)
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
