dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
pr=E9voie une mont=E9e en charge qui pousserait =E0 partir vers un syst=E8m=
e
libre fiable.
J'ai eu de bons =E9chos de PG qui propose des syst=E8me de loadbalancing,
des r=E9plication, r=E9specte bien les standard et le transactionnel.
MySQL a une r=E9putation d'=EAtre moins "solide" pour un usage r=E9ellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques ann=E9es
quand je m'y int=E9ressait. Donc ma question est de savoir si il y a
toujours un =E9cart important et si MySQL est plutot d=E9di=E9 =E0
l'h=E9bergement de blogs, CMS, et compagnie ou si aujourd'hui il =E9gale
ou d=E9passe PG ?
De m=EAme, la migration me semble pr=E9f=E9rable vers PG : il propose les
s=E9quences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Oui, ça c'est un point négatif pou MySQL. Les connexions sur l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
JKB
Hello,
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de la réplication multi-master) pour pouvoir écrire à la fois sur le maitre et le serveur de secours.
gg
JKB a écrit :
Oui, ça c'est un point négatif pou MySQL. Les connexions sur
l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
JKB
Hello,
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de
la réplication multi-master) pour pouvoir écrire à la fois sur le maitre
et le serveur de secours.
Oui, ça c'est un point négatif pou MySQL. Les connexions sur l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
JKB
Hello,
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de la réplication multi-master) pour pouvoir écrire à la fois sur le maitre et le serveur de secours.
gg
Sebastien Lardiere
Le 25/01/2010 21:58, Pif a écrit :
Bonjour,
Bonjour,
merci pour vos recommandations pour PG. Coté réplication, on m'avait dit du bien de Sequoia, et PG Pool II est recommandé par la doc PG.... personne ne les cite. Ils sont moins bon ?
Il s'agit de 2 outils assez différents de ceux déjà cités. Il s'agit ici de connecter les outils clients à la base via un gestionnaire de connexions qui s'occupe d'envoyer les transactions à N serveurs de bases de données. Ce sont donc les ordres SQL qui sont répliqués, plutôt que les données.
Selon la base de données, et ce qu'on y fait ( triggers, procédures stockées, ... ), on a potentiellement des données différentes entre les différentes bases de données du groupe, et des difficultés non-négligeables pour les synchroniser.
Je ne conseille pas ce mode de 'réplication' ...
Il s'agit d'une appli interne avec des données de facturations qui nécessite une fiabilité importante pour pouvoir récupérer les données. Je n'ai pas besoin d'une ultra haute dispo, mais la redondance était pour moi un outil permettant de faire de la redondance - pour la sauvegarde des données, - la dispo éventuellement - le load balancing (certains clients consomme beaucoup pour du reporting, d'autres vont etre ouverts en internet et pas seulement intranet, etc.).
Amha, une réplication des tables utiles pour le reporting, un (ou N ) WAL Shipping pour la reprise sur incident, c'est déja un premier pas interressant.
-- Sébastien
Le 25/01/2010 21:58, Pif a écrit :
Bonjour,
Bonjour,
merci pour vos recommandations pour PG. Coté réplication, on m'avait
dit du bien de Sequoia, et PG Pool II est recommandé par la doc PG....
personne ne les cite. Ils sont moins bon ?
Il s'agit de 2 outils assez différents de ceux déjà cités. Il s'agit ici
de connecter les outils clients à la base via un gestionnaire de
connexions qui s'occupe d'envoyer les transactions à N serveurs de bases
de données. Ce sont donc les ordres SQL qui sont répliqués, plutôt que
les données.
Selon la base de données, et ce qu'on y fait ( triggers, procédures
stockées, ... ), on a potentiellement des données différentes entre les
différentes bases de données du groupe, et des difficultés
non-négligeables pour les synchroniser.
Je ne conseille pas ce mode de 'réplication' ...
Il s'agit d'une appli interne avec des données de facturations qui
nécessite une fiabilité importante pour pouvoir récupérer les données.
Je n'ai pas besoin d'une ultra haute dispo, mais la redondance était
pour moi un outil permettant de faire de la redondance
- pour la sauvegarde des données,
- la dispo éventuellement
- le load balancing (certains clients consomme beaucoup pour du
reporting, d'autres vont etre ouverts en internet et pas seulement
intranet, etc.).
Amha, une réplication des tables utiles pour le reporting, un (ou N )
WAL Shipping pour la reprise sur incident, c'est déja un premier pas
interressant.
merci pour vos recommandations pour PG. Coté réplication, on m'avait dit du bien de Sequoia, et PG Pool II est recommandé par la doc PG.... personne ne les cite. Ils sont moins bon ?
Il s'agit de 2 outils assez différents de ceux déjà cités. Il s'agit ici de connecter les outils clients à la base via un gestionnaire de connexions qui s'occupe d'envoyer les transactions à N serveurs de bases de données. Ce sont donc les ordres SQL qui sont répliqués, plutôt que les données.
Selon la base de données, et ce qu'on y fait ( triggers, procédures stockées, ... ), on a potentiellement des données différentes entre les différentes bases de données du groupe, et des difficultés non-négligeables pour les synchroniser.
Je ne conseille pas ce mode de 'réplication' ...
Il s'agit d'une appli interne avec des données de facturations qui nécessite une fiabilité importante pour pouvoir récupérer les données. Je n'ai pas besoin d'une ultra haute dispo, mais la redondance était pour moi un outil permettant de faire de la redondance - pour la sauvegarde des données, - la dispo éventuellement - le load balancing (certains clients consomme beaucoup pour du reporting, d'autres vont etre ouverts en internet et pas seulement intranet, etc.).
Amha, une réplication des tables utiles pour le reporting, un (ou N ) WAL Shipping pour la reprise sur incident, c'est déja un premier pas interressant.
-- Sébastien
Sebastien Lardiere
Le 26/01/2010 10:03, Jerome PAULIN a écrit :
JKB a écrit :
Oui, ça c'est un point négatif pou MySQL. Les connexions sur l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de la réplication multi-master) pour pouvoir écrire à la fois sur le maitre et le serveur de secours.
Bonjour,
Même sans cette config boiteuse de multi-master, il est parfaitement possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke correctement.
-- Sébastien
Le 26/01/2010 10:03, Jerome PAULIN a écrit :
JKB a écrit :
Oui, ça c'est un point négatif pou MySQL. Les connexions sur
l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de
la réplication multi-master) pour pouvoir écrire à la fois sur le maitre
et le serveur de secours.
Bonjour,
Même sans cette config boiteuse de multi-master, il est parfaitement
possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke
correctement.
Oui, ça c'est un point négatif pou MySQL. Les connexions sur l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de la réplication multi-master) pour pouvoir écrire à la fois sur le maitre et le serveur de secours.
Bonjour,
Même sans cette config boiteuse de multi-master, il est parfaitement possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke correctement.
-- Sébastien
JKB
Le 26-01-2010, ? propos de Re: choix MySQL & Postgres, Sebastien Lardiere ?crivait dans fr.comp.applications.sgbd :
Le 26/01/2010 10:03, Jerome PAULIN a écrit :
JKB a écrit :
Oui, ça c'est un point négatif pou MySQL. Les connexions sur l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de la réplication multi-master) pour pouvoir écrire à la fois sur le maitre et le serveur de secours.
Bonjour,
Même sans cette config boiteuse de multi-master, il est parfaitement possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke correctement.
Ce qui est illusoire. On oublie toujours quelque chose dans un coin. La logique voudrait qu'on ne puisse _jamais_ écrire sur un slave. Ça devrait être interdit par défaut sauf pour le thread esclave.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 26-01-2010, ? propos de
Re: choix MySQL & Postgres,
Sebastien Lardiere ?crivait dans fr.comp.applications.sgbd :
Le 26/01/2010 10:03, Jerome PAULIN a écrit :
JKB a écrit :
Oui, ça c'est un point négatif pou MySQL. Les connexions sur
l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de
la réplication multi-master) pour pouvoir écrire à la fois sur le maitre
et le serveur de secours.
Bonjour,
Même sans cette config boiteuse de multi-master, il est parfaitement
possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke
correctement.
Ce qui est illusoire. On oublie toujours quelque chose dans un
coin. La logique voudrait qu'on ne puisse _jamais_ écrire sur un
slave. Ça devrait être interdit par défaut sauf pour le thread
esclave.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 26-01-2010, ? propos de Re: choix MySQL & Postgres, Sebastien Lardiere ?crivait dans fr.comp.applications.sgbd :
Le 26/01/2010 10:03, Jerome PAULIN a écrit :
JKB a écrit :
Oui, ça c'est un point négatif pou MySQL. Les connexions sur l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.
Il s'agit plus d'un problème de paramétrage de MySQL (il faut faire de la réplication multi-master) pour pouvoir écrire à la fois sur le maitre et le serveur de secours.
Bonjour,
Même sans cette config boiteuse de multi-master, il est parfaitement possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke correctement.
Ce qui est illusoire. On oublie toujours quelque chose dans un coin. La logique voudrait qu'on ne puisse _jamais_ écrire sur un slave. Ça devrait être interdit par défaut sauf pour le thread esclave.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Sebastien Lardiere
Le 26/01/2010 10:44, JKB a écrit :
Même sans cette config boiteuse de multi-master, il est parfaitement possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke correctement.
Ce qui est illusoire. On oublie toujours quelque chose dans un coin. La logique voudrait qu'on ne puisse _jamais_ écrire sur un slave. Ça devrait être interdit par défaut sauf pour le thread esclave.
En effet, mais, entre MySQL et PostgreSQL, il n'existe pas d'outil de réplication qui permette cela pour le moment.
Encore quelques mois d'attente pour PostgreSQL 9.0
-- Sébastien
Le 26/01/2010 10:44, JKB a écrit :
Même sans cette config boiteuse de multi-master, il est parfaitement
possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke
correctement.
Ce qui est illusoire. On oublie toujours quelque chose dans un
coin. La logique voudrait qu'on ne puisse _jamais_ écrire sur un
slave. Ça devrait être interdit par défaut sauf pour le thread
esclave.
En effet, mais, entre MySQL et PostgreSQL, il n'existe pas d'outil de
réplication qui permette cela pour le moment.
Encore quelques mois d'attente pour PostgreSQL 9.0
Même sans cette config boiteuse de multi-master, il est parfaitement possible d'écrire dans le slave MySQL.
Il est donc nécessaire d'utiliser les commandes grant et revoke correctement.
Ce qui est illusoire. On oublie toujours quelque chose dans un coin. La logique voudrait qu'on ne puisse _jamais_ écrire sur un slave. Ça devrait être interdit par défaut sauf pour le thread esclave.
En effet, mais, entre MySQL et PostgreSQL, il n'existe pas d'outil de réplication qui permette cela pour le moment.
Encore quelques mois d'attente pour PostgreSQL 9.0
