Bonjour,
Pouvez-vous m'orienter sur les solutions de Haute Disponibilité et de PRA disponibles sur les Bases de données suivantes : - SQL Server - MySQL - PostgreSQL
Exemple typique de solution robuste disponible chez l'un des concurrents, Oracle (écarté du fait de son coût et de ses problèmes de licensing sur des environnements virtuels VMWARE), Oracle Dataguard !
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 !).
De plus les fonctionnalités équivalentes à celle de Flashback d'Oracle pourraient aussi être un point intéressant à regarder pour le projet en question...
Cordialement,
JY
Bonjour Jean-Yves,
En ce qui concerne SQL Server, il existe la fonction mirroring de base qui te permet d'assurer de la haut dispo, sinon si tous tes serveurs sont virtualisé (sous Vmware ou Hyper-v) la solution Veeam peut être intéressante à étudier pour ces notions de répliqua. Toujours sur Vmware la fonction FT (Fault Tolerence) permet d'avoir de la très haute dispo mais avec pas mal de contrainte. Après tout dépend des SLA que tu (ou tes utilisateurs) souhaite(ent) ceci risque d'orienter tes choix d'architectures.
Cordialement
Cyrille
Le 20 janvier 2015 12:32, jean-yves@lenhof.eu.org a écrit :
Bonjour,
Pouvez-vous m'orienter sur les solutions de Haute Disponibilité et de PRA disponibles sur les Bases de données suivantes :
- SQL Server
- MySQL
- PostgreSQL
Exemple typique de solution robuste disponible chez l'un des concurrents, Oracle (écarté du fait de son coût et de ses problèmes de licensing sur des environnements virtuels VMWARE), Oracle Dataguard !
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 !).
De plus les fonctionnalités équivalentes à celle de Flashback d'Oracle pourraient aussi être un point intéressant à regarder pour le projet en question...
Cordialement,
JY _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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.
Le 20/01/2015 12:47, Cyrille Verger a écrit :
Bonjour Jean-Yves,
En ce qui concerne SQL Server, il existe la fonction mirroring de base qui te permet d'assurer de la haut dispo, sinon si tous tes serveurs sont virtualisé (sous Vmware ou Hyper-v) la solution Veeam peut être intéressante à étudier pour ces notions de répliqua. Toujours sur Vmware la fonction FT (Fault Tolerence) permet d'avoir de la très haute dispo mais avec pas mal de contrainte. Après tout dépend des SLA que tu (ou tes utilisateurs) souhaite(ent) ceci risque d'orienter tes choix d'architectures.
Cordialement
Cyrille
Le 20 janvier 2015 12:32, <jean-yves@lenhof.eu.org mailto:jean-yves@lenhof.eu.org> a écrit :
Bonjour, Pouvez-vous m'orienter sur les solutions de Haute Disponibilité et de PRA disponibles sur les Bases de données suivantes : - SQL Server - MySQL - PostgreSQL Exemple typique de solution robuste disponible chez l'un des concurrents, Oracle (écarté du fait de son coût et de ses problèmes de licensing sur des environnements virtuels VMWARE), Oracle Dataguard ! 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 !). De plus les fonctionnalités équivalentes à celle de Flashback d'Oracle pourraient aussi être un point intéressant à regarder pour le projet en question... Cordialement, JY _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
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
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/
Quand vous parlez de mysql galera : est-ce que quelqu'un a de l'expérience concernant Mariadb Galera ?
On 20/01/2015 13:25, Greg wrote:
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 mailto:frederic@de-villamil.com> a écrit :
> > On 20 Jan 2015, at 13:02, Pierre DOLIDON <sn4ky@sn4ky.net <mailto: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
Liste de diffusion du FRsAG http://www.frsag.org/
C'est la même chose, Galera est une surcouche à MySQL/MariaDB.
Le 20 janvier 2015 13:30, frsag@jack.fr.eu.org a écrit :
Quand vous parlez de mysql galera : est-ce que quelqu'un a de l'expérience concernant Mariadb Galera ?
On 20/01/2015 13:25, Greg wrote:
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 mailto:frederic@de-villamil.com> a écrit :
> > On 20 Jan 2015, at 13:02, Pierre DOLIDON <sn4ky@sn4ky.net <mailto:sn4ky@sn4ky.net>> wrote:
> > En ce qui concerne du mysql-like, regarde du côté de galeracluster.
> > Sinon, tu peux envisager une réplication mysql master-master, etfaire 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 lessynchros 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
Liste de diffusion du FRsAG http://www.frsag.org/
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour la liste,
Pour MS SQL/SQL Server, dans les dernières versions tu as aussi AlwaysOn, qui permet de régler ton problème (fonctionnement type cluster avec ou sans stockage partagé), mais il te faut un load balancer. C'est entrain de devenir le nouveau standard de haute dispo pour SQL Server, tout dépend ensuite du support des applications se connectant dessus, certains soft commerciaux n'ayant pas encore validé leur support de ces fonctions.
Pour MySQL/PostgreSQL, j'ai eu de très bon retours de clients sur Percona XtraDB (MySQL) et Pgpool-II (PostgreSQL), mais jamais testé/installé moi même.
Sinon pour la reprise d'activité en moins de 2h via VMware, je le fais actuellement pour certains clients, avec 3 "pauvre" scripts qui bascule jusqu'à ~1000 VMs en 1h15 (entre le "top failover" et le "OS ready + Applications UP" -> Il reste donc 45 min aux équipes DBA/Appli pour faire leurs tests). Je ne peux malheureusement pas fournir les scripts, mais la logique est "simpliste" -> Stockage répliqué -> Enregistrement massif de VM dans le vCenter du site restant -> Reconfig (ou pas) du réseau en fonction de la config en place -> Démarrage des VMs. Pour le retour, même chose en sens inverse, après avoir resync le stockage et sans la phase d'enregistrement, sauf si le site est à reconstruire (vCenter local / ne basculant pas).
Si le scripting ne te conviens pas, tu as toujours la solution Site Recovery Manager, toujours chez VMware, qui vas te permettre d'automatiser ta bascule sans connaissance de scripting, te permettra aussi de "tester" ton plan de DR en mode isolé, mais qui coûte un rein et nécessite de bien connaitre le produit pour l'installer.
Cordialement,
Sylvain.
2015-01-20 12:47 GMT+01:00 Cyrille Verger cverger99@gmail.com:
Bonjour Jean-Yves,
En ce qui concerne SQL Server, il existe la fonction mirroring de base qui te permet d'assurer de la haut dispo, sinon si tous tes serveurs sont virtualisé (sous Vmware ou Hyper-v) la solution Veeam peut être intéressante à étudier pour ces notions de répliqua. Toujours sur Vmware la fonction FT (Fault Tolerence) permet d'avoir de la très haute dispo mais avec pas mal de contrainte. Après tout dépend des SLA que tu (ou tes utilisateurs) souhaite(ent) ceci risque d'orienter tes choix d'architectures.
Cordialement
Cyrille
Le 20 janvier 2015 12:32, jean-yves@lenhof.eu.org a écrit :
Bonjour,
Pouvez-vous m'orienter sur les solutions de Haute Disponibilité et de PRA disponibles sur les Bases de données suivantes :
- SQL Server
- MySQL
- PostgreSQL
Exemple typique de solution robuste disponible chez l'un des concurrents, Oracle (écarté du fait de son coût et de ses problèmes de licensing sur des environnements virtuels VMWARE), Oracle Dataguard !
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 !).
De plus les fonctionnalités équivalentes à celle de Flashback d'Oracle pourraient aussi être un point intéressant à regarder pour le projet en question...
Cordialement,
JY _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 20 janvier 2015 12:32, jean-yves@lenhof.eu.org a écrit :
Bonjour,
Pouvez-vous m'orienter sur les solutions de Haute Disponibilité et de PRA disponibles sur les Bases de données suivantes :
- SQL Server
- MySQL
- PostgreSQL
Exemple typique de solution robuste disponible chez l'un des concurrents, Oracle (écarté du fait de son coût et de ses problèmes de licensing sur des environnements virtuels VMWARE), Oracle Dataguard !
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 !).
De plus les fonctionnalités équivalentes à celle de Flashback d'Oracle pourraient aussi être un point intéressant à regarder pour le projet en question...
Cordialement,
JY
Bonjour,
Pour Postgres, il est possible de mettre en place la streaming réplication, asynchrone ou synchrone. Bien entendu la réplication synchrone a un gros impact sur les perfs. En gros tu pars d'une copie du maître puis celui-ci envoie ses journaux dans un flux, le secondaire les rejoue. Il est possible de paramétrer l'esclave pour qu'il puisse effectuer des requêtes de lecture. Pour la bascule, il y a une commande ou un fichier à créer pour que le secondaire puisse recevoir des requêtes en écriture ( http://www.postgresql.org/docs/9.4/static/warm-standby-failover.html). La bascule est immédiate. Pour que les applis contactent le nouveau serveur il faut mettre en place des solutions maisons à base de heartbeat ou corosync/pacemaker. En googlant 2s je suis tombé la dessus (pas testé) : http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster
Dans le développement de Postgres on peut constater qu'il y a eu beaucoup d'efforts portés sur les mécanismes de réplications, la dernière version (9.4) en est la preuve avec la réplication logique : http://pgday.fr/slides/postgresql_9.4.pdf
Pour MySQL/PostgreSQL, j'ai eu de très bon retours de clients sur Percona
XtraDB (MySQL) et Pgpool-II (PostgreSQL), mais jamais testé/installé moi même.
Pour pgpool-II je serais plus prudent. Sur le papier c'est assez attrayant mais il a un coté couteau suisse : pooler, réplication, répartiteur de charge. Dans les faits il s'avère que l'outil est assez jeune et que le développement est assez soutenu, pas mal de corrections de bug etc ... Il réintègre le parser de requêtes de Postgres. En bref je trouve que ça fait beaucoup de choses et ça me parait assez lourd. Après je peux me tromper, peut être que dans 2 ans ça sera devenu une référence...
Bien entendu il ne faut pas se lancer à l'aveugle, il faut bien se former et effectuer tous les tests requis et surtout avoir une très bonne supervision. de la réplication. Il y a pas mal de sociétés qui proposent des formations, certaines contribuent au projet comme : Dalibo, 2ndquadrant. Pour ma part j'ai effectué une formation chez Dalibo et le retour a été très positif.
Cordialement,
Pour Postgres, il est possible de mettre en place la streaming réplication, asynchrone ou synchrone. Bien entendu la réplication synchrone a un gros impact sur les perfs. En gros tu pars d'une copie du maître puis celui-ci envoie ses journaux dans un flux, le secondaire les rejoue.
J'ai ça qui tourne avec un exabgp pour annoncer le master. Petite base, petit trafic donc pas vraiment d'expérience sur un sysème chargé mais dans mon cas ça fait bien le job.
Pour pgpool-II je serais plus prudent. Sur le papier c'est assez attrayant mais il a un coté couteau suisse : pooler, réplication, répartiteur de
De mon expérience, pgpool est une galère à boostrapper en cas de désynchro d'un des noeuds et les perfs en prennent un sacré coup.
Denis
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 :)
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.
Bon courage http://www.captainadmin.com
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 :)
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 :)
Petites précisions par rapport à mon besoin ci-dessous par rapport à certaines réponses obtenues...
La solution doit être "supportée", exit donc les trucs en beta ou les versions non supportées en natif par l'éditeur si la solution vient dans une distribution Linux. Donc soit la solution se base sur des outils fournies dans les distributions Linux, soit on peut acheter du support chez un éditeur tiers. Est-ce le cas pour les outils Percona par exemple ? (Je pense que oui au vu du site web, mais des gens ont-ils eu affaire à leur support ?)
Pour les 2h, il faut envisager le pire en terme de réactivité (ce n'est donc pas que la partie technique mais qui intègre les différentes investigations avant décision de bascule)... Pour le moment, je n'ai pas eu de précision sur la perte de données maximale admissible, même s'il s'agit je suis d'accord d'un élément important dans les choix.
Cordialement,
JYL
Le 2015-01-20 12:32, jean-yves@lenhof.eu.org a écrit :
Bonjour,
Pouvez-vous m'orienter sur les solutions de Haute Disponibilité et de PRA disponibles sur les Bases de données suivantes :
- SQL Server
- MySQL
- PostgreSQL
Exemple typique de solution robuste disponible chez l'un des concurrents, Oracle (écarté du fait de son coût et de ses problèmes de licensing sur des environnements virtuels VMWARE), Oracle Dataguard !
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 !).
De plus les fonctionnalités équivalentes à celle de Flashback d'Oracle pourraient aussi être un point intéressant à regarder pour le projet en question...
Cordialement,
JY _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
Sauf erreur de ma part, le temps indique dans un PRA n'est pas le temps entre le debut d'incident et la remontée du service sur le site de backup, mais le temps maxilam de remontée des services _après_ go du top management.
En effet PRA = perte de données = decision qui dois être escaladée. Comment garantir une durée qui depends d'une décision non maîtrisée? Comme indiqué par certains, 2h ce n'est pas le temps de restoration des données. Et pourtant, un PRA dois pallier a un "drop database" qu'il soit accidentel ou non.
Dans l'absolu, si le managent est si a cheval sur l'indisponibilité, ils devraient regarder du cote d'un PCA et non un PRA.
Cordialement,
Le 20 janvier 2015 16:48:55 CET, jean-yves@lenhof.eu.org a écrit :
Petites précisions par rapport à mon besoin ci-dessous par rapport à certaines réponses obtenues...
La solution doit être "supportée", exit donc les trucs en beta ou les versions non supportées en natif par l'éditeur si la solution vient dans une distribution Linux. Donc soit la solution se base sur des outils fournies dans les distributions Linux, soit on peut acheter du support chez un éditeur tiers. Est-ce le cas pour les outils Percona par exemple ? (Je pense que oui au vu du site web, mais des gens ont-ils eu affaire
à leur support ?)
Pour les 2h, il faut envisager le pire en terme de réactivité (ce n'est
donc pas que la partie technique mais qui intègre les différentes investigations avant décision de bascule)... Pour le moment, je n'ai pas eu de précision sur la perte de données maximale admissible, même s'il s'agit je suis d'accord d'un élément important dans les choix.
Cordialement,
JYL
Le 2015-01-20 12:32, jean-yves@lenhof.eu.org a écrit :
Bonjour,
Pouvez-vous m'orienter sur les solutions de Haute Disponibilité et de PRA disponibles sur les Bases de données suivantes :
- SQL Server
- MySQL
- PostgreSQL
Exemple typique de solution robuste disponible chez l'un des concurrents, Oracle (écarté du fait de son coût et de ses problèmes de licensing sur des environnements virtuels VMWARE), Oracle Dataguard !
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 !).
De plus les fonctionnalités équivalentes à celle de Flashback d'Oracle pourraient aussi être un point intéressant à regarder pour le projet en question...
Cordialement,
JY _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Percona est avant tout une boite qui fais du consulting MySQL (et désormais aussi MariaDB et pour leur propre fork) tout en développant ses propres outils. MariaDB corporation est anciennement SkySQL, qui à racheté MariaDB (dont le développement est géré par la fondation MariaDB pour éviter des risques d'appropriation de code par l'entreprise) et changé de nom en octobre et dont l'activité est similaire à celle de Percona, il est même précisé sur leur site qu'ils proposent toujours un support pour MySQL, sans discrimination.
Pour ceux qui s'inquièteraient de l'intégration aux distributions, le mainteneur de MariaDB sous Debian et Ubuntu (MariaDB 10.0 est inclus dans Debian 8 qui sortira normalement le mois prochain) viens d'être nommé CEO de la fondation MariaDB donc pas de soucis quant au suivi de ce côté, sachant qu'en plus MariaDB fournis déjà des dépôts pour la plupart des distributions.
Un petit détail : Galera est prévu pour être intégré sur MariaDB de base (plus de branche de code spécifique et de binaires spécifiques) à partir de la prochaine version majeure (10.1).
-- Quant à la bascule entre les deux serveurs, il faut voir d'un point de vue applicatif combien d'applications/scripts s'y connectent et à combien d'endroits sont spécifiés les paramètres de connexions (et s'il est possible d'y accéder, si par exemple des clients se connectent sur le serveur cela peux poser problème), il peux en découler qu'une simple modification de configurations ayant été bien documentées pourra suffire (mais attention à bien informer les développeurs qu'ils doivent documenter s'ils rajoutent des scripts/outils utilisant leur propre configuration) ou eventuellement que les clients se connecteraient sur une IP virtuelle pouvant sans trop de difficulté pointer sur l'un ou l'autre des serveurs.
Le 20/01/2015 16:48, jean-yves@lenhof.eu.org a écrit :
Petites précisions par rapport à mon besoin ci-dessous par rapport à certaines réponses obtenues...
La solution doit être "supportée", exit donc les trucs en beta ou les versions non supportées en natif par l'éditeur si la solution vient dans une distribution Linux. Donc soit la solution se base sur des outils fournies dans les distributions Linux, soit on peut acheter du support chez un éditeur tiers. Est-ce le cas pour les outils Percona par exemple ? (Je pense que oui au vu du site web, mais des gens ont-ils eu affaire à leur support ?)
Pour les 2h, il faut envisager le pire en terme de réactivité (ce n'est donc pas que la partie technique mais qui intègre les différentes investigations avant décision de bascule)... Pour le moment, je n'ai pas eu de précision sur la perte de données maximale admissible, même s'il s'agit je suis d'accord d'un élément important dans les choix.
-
adrien nayrat -
Cyrille Verger -
Denis Fondras -
Dominique Rousseau -
Frederic de Villamil -
frsag＠jack.fr.eu.org -
Greg -
Jean Weisbuch -
jean-yves＠lenhof.eu.org -
jr＠captainadmin.com -
Pierre DOLIDON -
Richard Demongeot -
Sylvain Huguet