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 ?
Le 22-01-2010, ? propos de choix MySQL & Postgres, Pif ?crivait dans fr.comp.applications.sgbd :
Bonjour,
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement d'entreprise. Quand je dis "a", c'est avais il y a quelques années quand je m'y intéressait. Donc ma question est de savoir si il y a toujours un écart important et si MySQL est plutot dédié à l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
J'en pense que MySQL est le dernier des choix à faire si on veut quelque chose d'efficace. J'ai du MySQL et du PostgreSQL, PG se comporte bien, MySQL se comporte comme un goret. Je ne compte plus les répliques qui plantent, les interruptions de service et j'en passe. Bref, je n'utilise plus MySQL que lorsque je n'ai pas le choix (j'ai tout de même du 5, du 5.1 et du 6 sur mes serveurs). Pour tout ce qui est critique, j'ai une nette préférence pour Postgre.
C'était juste mon avis, prière de ne pas lancer bataille de clochers.
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 22-01-2010, ? propos de
choix MySQL & Postgres,
Pif ?crivait dans fr.comp.applications.sgbd :
Bonjour,
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
J'en pense que MySQL est le dernier des choix à faire si on veut
quelque chose d'efficace. J'ai du MySQL et du PostgreSQL, PG se
comporte bien, MySQL se comporte comme un goret. Je ne compte plus
les répliques qui plantent, les interruptions de service et j'en
passe. Bref, je n'utilise plus MySQL que lorsque je n'ai pas le
choix (j'ai tout de même du 5, du 5.1 et du 6 sur mes serveurs).
Pour tout ce qui est critique, j'ai une nette préférence pour Postgre.
C'était juste mon avis, prière de ne pas lancer bataille de
clochers.
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 22-01-2010, ? propos de choix MySQL & Postgres, Pif ?crivait dans fr.comp.applications.sgbd :
Bonjour,
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement d'entreprise. Quand je dis "a", c'est avais il y a quelques années quand je m'y intéressait. Donc ma question est de savoir si il y a toujours un écart important et si MySQL est plutot dédié à l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
J'en pense que MySQL est le dernier des choix à faire si on veut quelque chose d'efficace. J'ai du MySQL et du PostgreSQL, PG se comporte bien, MySQL se comporte comme un goret. Je ne compte plus les répliques qui plantent, les interruptions de service et j'en passe. Bref, je n'utilise plus MySQL que lorsque je n'ai pas le choix (j'ai tout de même du 5, du 5.1 et du 6 sur mes serveurs). Pour tout ce qui est critique, j'ai une nette préférence pour Postgre.
C'était juste mon avis, prière de ne pas lancer bataille de clochers.
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.
Alcovia
Le 22/01/2010 11:10, Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement d'entreprise. Quand je dis "a", c'est avais il y a quelques années quand je m'y intéressait. Donc ma question est de savoir si il y a toujours un écart important et si MySQL est plutot dédié à l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
si tu viens d'oracle, il n'y a pas photo: le choix PostgreSQL s'impose tant ils sont similaires. Mysql fait jouet à côté
Le 22/01/2010 11:10, Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
si tu viens d'oracle, il n'y a pas photo: le choix PostgreSQL s'impose
tant ils sont similaires. Mysql fait jouet à côté
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement d'entreprise. Quand je dis "a", c'est avais il y a quelques années quand je m'y intéressait. Donc ma question est de savoir si il y a toujours un écart important et si MySQL est plutot dédié à l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
si tu viens d'oracle, il n'y a pas photo: le choix PostgreSQL s'impose tant ils sont similaires. Mysql fait jouet à côté
WebShaker
Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement d'entreprise. Quand je dis "a", c'est avais il y a quelques années quand je m'y intéressait. Donc ma question est de savoir si il y a toujours un écart important et si MySQL est plutot dédié à l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
Moi aussi j'opterai pour postgreSQL. Mais attention coté réplication, ca reste très limité. Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas, mais les outils sont plus nombreux dans ce domaine.
Etienne
Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
Moi aussi j'opterai pour postgreSQL.
Mais attention coté réplication, ca reste très limité.
Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas,
mais les outils sont plus nombreux dans ce domaine.
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement d'entreprise. Quand je dis "a", c'est avais il y a quelques années quand je m'y intéressait. Donc ma question est de savoir si il y a toujours un écart important et si MySQL est plutot dédié à l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
Moi aussi j'opterai pour postgreSQL. Mais attention coté réplication, ca reste très limité. Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas, mais les outils sont plus nombreux dans ce domaine.
Etienne
JKB
Le 22-01-2010, ? propos de Re: choix MySQL & Postgres, WebShaker ?crivait dans fr.comp.applications.sgbd :
Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement d'entreprise. Quand je dis "a", c'est avais il y a quelques années quand je m'y intéressait. Donc ma question est de savoir si il y a toujours un écart important et si MySQL est plutot dédié à l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
Moi aussi j'opterai pour postgreSQL. Mais attention coté réplication, ca reste très limité. Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas, mais les outils sont plus nombreux dans ce domaine.
Il y a Slony-I. Je n'ai jamais utilisé, mais a priori, je ne vois pas pourquoi ce serait plus merdique que la réplication selon MySQL. Pour être tout à fait honnête, je ne vois pas comment on pourrait faire pire ;-) La réplication selon MySQL, c'est bourrin, sans vérification d'erreur (ou plutôt la réplique arrive à planter sur des transactions acceptées par le noeud maître sans aucune raison valable).
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 22-01-2010, ? propos de
Re: choix MySQL & Postgres,
WebShaker ?crivait dans fr.comp.applications.sgbd :
Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
Moi aussi j'opterai pour postgreSQL.
Mais attention coté réplication, ca reste très limité.
Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas,
mais les outils sont plus nombreux dans ce domaine.
Il y a Slony-I. Je n'ai jamais utilisé, mais a priori, je ne vois
pas pourquoi ce serait plus merdique que la réplication selon MySQL.
Pour être tout à fait honnête, je ne vois pas comment on pourrait
faire pire ;-) La réplication selon MySQL, c'est bourrin, sans
vérification d'erreur (ou plutôt la réplique arrive à planter sur
des transactions acceptées par le noeud maître sans aucune raison
valable).
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 22-01-2010, ? propos de Re: choix MySQL & Postgres, WebShaker ?crivait dans fr.comp.applications.sgbd :
Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
MySQL a une réputation d'être moins "solide" pour un usage réellement d'entreprise. Quand je dis "a", c'est avais il y a quelques années quand je m'y intéressait. Donc ma question est de savoir si il y a toujours un écart important et si MySQL est plutot dédié à l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale ou dépasse PG ?
De même, la migration me semble préférable vers PG : il propose les séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?
Merci.
Moi aussi j'opterai pour postgreSQL. Mais attention coté réplication, ca reste très limité. Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas, mais les outils sont plus nombreux dans ce domaine.
Il y a Slony-I. Je n'ai jamais utilisé, mais a priori, je ne vois pas pourquoi ce serait plus merdique que la réplication selon MySQL. Pour être tout à fait honnête, je ne vois pas comment on pourrait faire pire ;-) La réplication selon MySQL, c'est bourrin, sans vérification d'erreur (ou plutôt la réplique arrive à planter sur des transactions acceptées par le noeud maître sans aucune raison valable).
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 22/01/2010 14:10, WebShaker a écrit :
Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
[...]
Moi aussi j'opterai pour postgreSQL. Mais attention coté réplication, ca reste très limité. Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas, mais les outils sont plus nombreux dans ce domaine.
De même, PostgreSQL est sans aucun doute le meilleur choix.
Pour les outils de réplication, je dirais au contraire qu'il y a plus d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que MySQL.
Je me permettrais d'orienter vers les skytools¹, londiste ( similaire à Slony-I) et walmgr.py ( WAL Shipping ), ça tourne en prod sans probleme.
J'ajouterais qu'au dela d'une communauté de développeurs, très actifs, on trouve un éco-système logiciel très fourni ...
-- Sébastien
Le 22/01/2010 14:10, WebShaker a écrit :
Pif a écrit :
Bonjour,
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.
[...]
Moi aussi j'opterai pour postgreSQL.
Mais attention coté réplication, ca reste très limité.
Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas,
mais les outils sont plus nombreux dans ce domaine.
De même, PostgreSQL est sans aucun doute le meilleur choix.
Pour les outils de réplication, je dirais au contraire qu'il y a plus
d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que
MySQL.
Je me permettrais d'orienter vers les skytools¹, londiste ( similaire à
Slony-I) et walmgr.py ( WAL Shipping ), ça tourne en prod sans probleme.
J'ajouterais qu'au dela d'une communauté de développeurs, très actifs,
on trouve un éco-système logiciel très fourni ...
dans ma boite on utilise de l'oracle. Les licences coutent cher, et on prévoie une montée en charge qui pousserait à partir vers un système libre fiable.
J'ai eu de bons échos de PG qui propose des système de loadbalancing, des réplication, réspecte bien les standard et le transactionnel.
[...]
Moi aussi j'opterai pour postgreSQL. Mais attention coté réplication, ca reste très limité. Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas, mais les outils sont plus nombreux dans ce domaine.
De même, PostgreSQL est sans aucun doute le meilleur choix.
Pour les outils de réplication, je dirais au contraire qu'il y a plus d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que MySQL.
Je me permettrais d'orienter vers les skytools¹, londiste ( similaire à Slony-I) et walmgr.py ( WAL Shipping ), ça tourne en prod sans probleme.
J'ajouterais qu'au dela d'une communauté de développeurs, très actifs, on trouve un éco-système logiciel très fourni ...
-- Sébastien
Alain Montfranc
Le 22/01/2010, Sebastien Lardiere a supposé :
Pour les outils de réplication, je dirais au contraire qu'il y a plus d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Le 22/01/2010, Sebastien Lardiere a supposé :
Pour les outils de réplication, je dirais au contraire qu'il y a plus
d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que
MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Pour les outils de réplication, je dirais au contraire qu'il y a plus d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Sebastien Lardiere
Alain Montfranc a écrit :
Le 22/01/2010, Sebastien Lardiere a supposé :
Pour les outils de réplication, je dirais au contraire qu'il y a plus d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Il s'agit d'une technique de réplication parmi d'autre, qui nécessite pour le moment un outil externe ( walmgr.py, pg_standby )
On réplique l'ensemble du cluster, et le 'slave' n'est pas disponible, ça ne sert que pour avoir un serveur disponible en cas de panne du serveur principal.
Pour la prochaine version ( 9.0 ), ces 2 points seront largement améliorer : plus besoin d'outils externes pour la réplication, et possibilité de se connecter au 'slave' en lecture seule.
Il existe d'autres techniques de réplication, avec londiste ou slony-I, asyncrhone, basé sur des triggers, qui consiste à répliquer les DMLs vers un autre serveur actif.
Ces 2 modes de réplications répondent à des besoins tout à fait différent.
-- Sébastien
Alain Montfranc a écrit :
Le 22/01/2010, Sebastien Lardiere a supposé :
Pour les outils de réplication, je dirais au contraire qu'il y a plus
d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que
MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Il s'agit d'une technique de réplication parmi d'autre, qui nécessite
pour le moment un outil externe ( walmgr.py, pg_standby )
On réplique l'ensemble du cluster, et le 'slave' n'est pas disponible,
ça ne sert que pour avoir un serveur disponible en cas de panne du
serveur principal.
Pour la prochaine version ( 9.0 ), ces 2 points seront largement
améliorer : plus besoin d'outils externes pour la réplication, et
possibilité de se connecter au 'slave' en lecture seule.
Il existe d'autres techniques de réplication, avec londiste ou slony-I,
asyncrhone, basé sur des triggers, qui consiste à répliquer les DMLs
vers un autre serveur actif.
Ces 2 modes de réplications répondent à des besoins tout à fait différent.
Pour les outils de réplication, je dirais au contraire qu'il y a plus d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Il s'agit d'une technique de réplication parmi d'autre, qui nécessite pour le moment un outil externe ( walmgr.py, pg_standby )
On réplique l'ensemble du cluster, et le 'slave' n'est pas disponible, ça ne sert que pour avoir un serveur disponible en cas de panne du serveur principal.
Pour la prochaine version ( 9.0 ), ces 2 points seront largement améliorer : plus besoin d'outils externes pour la réplication, et possibilité de se connecter au 'slave' en lecture seule.
Il existe d'autres techniques de réplication, avec londiste ou slony-I, asyncrhone, basé sur des triggers, qui consiste à répliquer les DMLs vers un autre serveur actif.
Ces 2 modes de réplications répondent à des besoins tout à fait différent.
-- Sébastien
JKB
Le 23-01-2010, ? propos de Re: choix MySQL & Postgres, Sebastien Lardiere ?crivait dans fr.comp.applications.sgbd :
Alain Montfranc a écrit :
Le 22/01/2010, Sebastien Lardiere a supposé :
Pour les outils de réplication, je dirais au contraire qu'il y a plus d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Il s'agit d'une technique de réplication parmi d'autre, qui nécessite pour le moment un outil externe ( walmgr.py, pg_standby )
On réplique l'ensemble du cluster, et le 'slave' n'est pas disponible, ça ne sert que pour avoir un serveur disponible en cas de panne du serveur principal.
Pour la prochaine version ( 9.0 ), ces 2 points seront largement améliorer : plus besoin d'outils externes pour la réplication, et possibilité de se connecter au 'slave' en lecture seule.
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
-- 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 23-01-2010, ? propos de
Re: choix MySQL & Postgres,
Sebastien Lardiere ?crivait dans fr.comp.applications.sgbd :
Alain Montfranc a écrit :
Le 22/01/2010, Sebastien Lardiere a supposé :
Pour les outils de réplication, je dirais au contraire qu'il y a plus
d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que
MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Il s'agit d'une technique de réplication parmi d'autre, qui nécessite
pour le moment un outil externe ( walmgr.py, pg_standby )
On réplique l'ensemble du cluster, et le 'slave' n'est pas disponible,
ça ne sert que pour avoir un serveur disponible en cas de panne du
serveur principal.
Pour la prochaine version ( 9.0 ), ces 2 points seront largement
améliorer : plus besoin d'outils externes pour la réplication, et
possibilité de se connecter au 'slave' en lecture seule.
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
--
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 23-01-2010, ? propos de Re: choix MySQL & Postgres, Sebastien Lardiere ?crivait dans fr.comp.applications.sgbd :
Alain Montfranc a écrit :
Le 22/01/2010, Sebastien Lardiere a supposé :
Pour les outils de réplication, je dirais au contraire qu'il y a plus d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que MySQL.
C'est pas natif depuis la 8.2 avec le log shiping ?
Il s'agit d'une technique de réplication parmi d'autre, qui nécessite pour le moment un outil externe ( walmgr.py, pg_standby )
On réplique l'ensemble du cluster, et le 'slave' n'est pas disponible, ça ne sert que pour avoir un serveur disponible en cas de panne du serveur principal.
Pour la prochaine version ( 9.0 ), ces 2 points seront largement améliorer : plus besoin d'outils externes pour la réplication, et possibilité de se connecter au 'slave' en lecture seule.
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
-- 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 23/01/2010 12:21, JKB a écrit :
Pour la prochaine version ( 9.0 ), ces 2 points seront largement améliorer : plus besoin d'outils externes pour la réplication, et possibilité de se connecter au 'slave' en lecture seule.
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.
Oui, ça, c'est pour la future version de PostgreSQL. La version actuelle de ce mode de réplication ne permet pas de connexion au slave, du coup, on est tranquille de ce coté là.
Par contre, l'autre mode de réplication, basé sur des triggers ( londiste, slony-I ), n'empeche pas de faire des betises sur le slave. Il faut donc utiliser les ACLs ( grant, revoke ), et du coup, on peut appliquer la même recette dans MySQL.
Bon, si j'étais de mauvaise fois, je dirais que l'unique mode de réplication de MySQL est assez batard, et bancal, voire carrément foireux, mais comme je ne suis pas de mauvaise fois, je ne l'ai pas dit ...
-- Sébastien
Le 23/01/2010 12:21, JKB a écrit :
Pour la prochaine version ( 9.0 ), ces 2 points seront largement
améliorer : plus besoin d'outils externes pour la réplication, et
possibilité de se connecter au 'slave' en lecture seule.
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.
Oui, ça, c'est pour la future version de PostgreSQL. La version actuelle
de ce mode de réplication ne permet pas de connexion au slave, du coup,
on est tranquille de ce coté là.
Par contre, l'autre mode de réplication, basé sur des triggers (
londiste, slony-I ), n'empeche pas de faire des betises sur le slave. Il
faut donc utiliser les ACLs ( grant, revoke ), et du coup, on peut
appliquer la même recette dans MySQL.
Bon, si j'étais de mauvaise fois, je dirais que l'unique mode de
réplication de MySQL est assez batard, et bancal, voire carrément
foireux, mais comme je ne suis pas de mauvaise fois, je ne l'ai pas dit ...
Pour la prochaine version ( 9.0 ), ces 2 points seront largement améliorer : plus besoin d'outils externes pour la réplication, et possibilité de se connecter au 'slave' en lecture seule.
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.
Oui, ça, c'est pour la future version de PostgreSQL. La version actuelle de ce mode de réplication ne permet pas de connexion au slave, du coup, on est tranquille de ce coté là.
Par contre, l'autre mode de réplication, basé sur des triggers ( londiste, slony-I ), n'empeche pas de faire des betises sur le slave. Il faut donc utiliser les ACLs ( grant, revoke ), et du coup, on peut appliquer la même recette dans MySQL.
Bon, si j'étais de mauvaise fois, je dirais que l'unique mode de réplication de MySQL est assez batard, et bancal, voire carrément foireux, mais comme je ne suis pas de mauvaise fois, je ne l'ai pas dit ...
-- Sébastien
Pif
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 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.).
Merci.
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 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.).
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 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.).
