Re: [pgsql-fr-generale] Comment traduire "Streaming Réplication" ?

Bonjour à toutes et à tous,

Si vous êtes un aficionado de PostgreSQL, vous êtes probablement déjà au
courant qu'un patch dénomé "Streaming Réplication" vient d'être intégré
dans la branche principale du dépot CVS.

Pour le dire autrement : la future version 8.5 (ou 9.0 ?) devrait
pouvoir répliquer les données en "streaming".

Et justement, cela fait plusieurs jours que je retourne ce mot dans ma
tête et je trouve que le terme passe assez mal en français, voire qu'il
prête carrément à confusion puisque dans l'imaginaire de l'internaute
francophone ce mot apparait d'habitude dans les expressions du type
"J'ai regardé la saison 2 de Gossip Girl en streaming" ... Ce qui
d'ailleurs ne veut pas dire grand'chose mais c'est un autre problème :)

Pour revenir à PostgreSQL, la "streaming replication" c'est la capacité
d'affiner le mécanisme de Log Shipping. En effet, jusqu'à présent le log
shipping était un mécanisme de redondance un peu frustre puisque se
basait sur l'export des journaux de transaction ( nommés xlogs ou WAL ).
Ces journaux faisant 16Mo chacun, on pouvait atteindre un décalage de
16Mo entre le serveur principal et le secondaire.

La "streaming réplication" résout le problème en répliquant les données
transaction par transaction, ce qui améliore grandement la
synchronisation entre les noeuds. Vous l'aurez compris : avec cette
fonctionnalité, ajoutée au "Hot Standby" qui est déjà présent dans la
version alpha, PostgreSQL proposera dans quelques semaines un système de
réplication simple et totalement intégré au moteur.

J'en vient donc à mon problème initial : comment traduire ce terme.
Google me propose "réplication ruisselante" qui assez poétique mais pas
vraiment utilisable :-)
De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)

Avez-vous une meilleure traduction pour cette fonctionnalité ?

PS : Pour les plus impatient(e)s, la "Streaming Réplication" sera inclue
dans la version PostgreSQL 8.5 Alpha4, qui ne devrait pas tarder :-)

--
damien
dalibo.org | dalibo.com

Le 20/01/2010 09:20, damien clochard a écrit :
> [...]
> J'en vient donc à mon problème initial : comment traduire ce terme.
> Google me propose "réplication ruisselante" qui assez poétique mais pas
> vraiment utilisable :-)
> De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
> en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)
>

Réplication en flux me paraît bien.

> Avez-vous une meilleure traduction pour cette fonctionnalité ?
>
>
> PS : Pour les plus impatient(e)s, la "Streaming Réplication" sera inclue
> dans la version PostgreSQL 8.5 Alpha4, qui ne devrait pas tarder :-)
>

EUh, pas tarder... certainement pas avant un mois. Toutes les
précédentes commit fests ont montré quand même un mois entre le début de
la commitfest et sa fin.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

Je vote pour réplication au fil de l'eau :)

Le mercredi 20 janvier 2010 09:20:49, damien clochard a écrit :
> Bonjour à toutes et à tous,
>
> Si vous êtes un aficionado de PostgreSQL, vous êtes probablement déjà au
> courant qu'un patch dénomé "Streaming Réplication" vient d'être intégré
> dans la branche principale du dépot CVS.
>
> Pour le dire autrement : la future version 8.5 (ou 9.0 ?) devrait
> pouvoir répliquer les données en "streaming".
>
> Et justement, cela fait plusieurs jours que je retourne ce mot dans ma
> tête et je trouve que le terme passe assez mal en français, voire qu'il
> prête carrément à confusion puisque dans l'imaginaire de l'internaute
> francophone ce mot apparait d'habitude dans les expressions du type
> "J'ai regardé la saison 2 de Gossip Girl en streaming" ... Ce qui
> d'ailleurs ne veut pas dire grand'chose mais c'est un autre problème :)
>
> Pour revenir à PostgreSQL, la "streaming replication" c'est la capacité
> d'affiner le mécanisme de Log Shipping. En effet, jusqu'à présent le log
> shipping était un mécanisme de redondance un peu frustre puisque se
> basait sur l'export des journaux de transaction ( nommés xlogs ou WAL ).
> Ces journaux faisant 16Mo chacun, on pouvait atteindre un décalage de
> 16Mo entre le serveur principal et le secondaire.
>
> La "streaming réplication" résout le problème en répliquant les données
> transaction par transaction, ce qui améliore grandement la
> synchronisation entre les noeuds. Vous l'aurez compris : avec cette
> fonctionnalité, ajoutée au "Hot Standby" qui est déjà présent dans la
> version alpha, PostgreSQL proposera dans quelques semaines un système de
> réplication simple et totalement intégré au moteur.
>
> J'en vient donc à mon problème initial : comment traduire ce terme.
> Google me propose "réplication ruisselante" qui assez poétique mais pas
> vraiment utilisable :-)
> De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
> en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)
>
> Avez-vous une meilleure traduction pour cette fonctionnalité ?
>
>
> PS : Pour les plus impatient(e)s, la "Streaming Réplication" sera inclue
> dans la version PostgreSQL 8.5 Alpha4, qui ne devrait pas tarder :-)
>
> --
> damien
> dalibo.org | dalibo.com
>

damien clochard <damien(at)dalibo(dot)info> writes:
> Avez-vous une meilleure traduction pour cette fonctionnalité ?

Réplication des journaux binaires.

--
dim

Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> EUh, pas tarder... certainement pas avant un mois. Toutes les
> précédentes commit fests ont montré quand même un mois entre le début de
> la commitfest et sa fin.

Et c'est même le calendrier annoncé. Ajouter une semaine environ le
temps de taguer les sources, préparer et distribuer les versions
binaires.

--
dim

2010/1/20 Guillaume Lelarge <guillaume(at)lelarge(dot)info>:
> Le 20/01/2010 09:20, damien clochard a écrit :
>> [...]
>> J'en vient donc à mon problème initial : comment traduire ce terme.
>> Google me propose  "réplication ruisselante" qui assez poétique mais pas
>> vraiment utilisable :-)
>> De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
>>  en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)
>>
>
> Réplication en flux me paraît bien.

Ou bien 'réplication en flux continu'. Mais un peu long...

Le 20 janvier 2010 09:37, Marc Cousin <mcousin(at)sigma(dot)fr> a écrit :
> Je vote pour réplication au fil de l'eau :)
Ce n'est pas le plus court, mais ça me plaît bien !

Laurent

Marc Cousin <mcousin(at)sigma(dot)fr> writes:
> Je vote pour réplication au fil de l'eau :)

Ça correspond aussi à Slony, Londiste, Postgres-R, Mammoth Replicator,
Bucardo, et beaucoup d'autres.

--
dim

what shows the Académie say? the Quebec OLF's online dictionary has
translations for a few related terms:

lecture en transit
diffusion en flux
données de transmission en continu

greg

On 20 Jan 2010 08:21, "damien clochard" <damien(at)dalibo(dot)info> wrote:

Bonjour à toutes et à tous,

Si vous êtes un aficionado de PostgreSQL, vous êtes probablement déjà au
courant qu'un patch dénomé "Streaming Réplication" vient d'être intégré
dans la branche principale du dépot CVS.

Pour le dire autrement : la future version 8.5 (ou 9.0 ?) devrait
pouvoir répliquer les données en "streaming".

Et justement, cela fait plusieurs jours que je retourne ce mot dans ma
tête et je trouve que le terme passe assez mal en français, voire qu'il
prête carrément à confusion puisque dans l'imaginaire de l'internaute
francophone ce mot apparait d'habitude dans les expressions du type
"J'ai regardé la saison 2 de Gossip Girl en streaming" ... Ce qui
d'ailleurs ne veut pas dire grand'chose mais c'est un autre problème :)

Pour revenir à PostgreSQL, la "streaming replication" c'est la capacité
d'affiner le mécanisme de Log Shipping. En effet, jusqu'à présent le log
shipping était un mécanisme de redondance un peu frustre puisque se
basait sur l'export des journaux de transaction ( nommés xlogs ou WAL ).
Ces journaux faisant 16Mo chacun, on pouvait atteindre un décalage de
16Mo entre le serveur principal et le secondaire.

La "streaming réplication" résout le problème en répliquant les données
transaction par transaction, ce qui améliore grandement la
synchronisation entre les noeuds. Vous l'aurez compris : avec cette
fonctionnalité, ajoutée au "Hot Standby" qui est déjà présent dans la
version alpha, PostgreSQL proposera dans quelques semaines un système de
réplication simple et totalement intégré au moteur.

J'en vient donc à mon problème initial : comment traduire ce terme.
Google me propose "réplication ruisselante" qui assez poétique mais pas
vraiment utilisable :-)
De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)

Avez-vous une meilleure traduction pour cette fonctionnalité ?

PS : Pour les plus impatient(e)s, la "Streaming Réplication" sera inclue
dans la version PostgreSQL 8.5 Alpha4, qui ne devrait pas tarder :-)

--
damien
dalibo.org | dalibo.com

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale

Réplication au niveau des transaction, ça constitue une avancée majeure (un pas de plus vers une réplication synchrone tout de même !), il faudrait le distinguer du wal shipping, tout en conservant la filiation. J'ose donc les propositions suivantes :

transaction shipping ?
réplication continue transactionnelle ? ce qui donnerait RCT (à ne pas confondre avec le Rugby Club Toulonnais...)

Quelle que soit la façon dont on l'appelle, vivement qu'on puisse l'avoir en release ! ;-)

Jean Philippe

Greg Stark a écrit :
> what shows the Académie say? the Quebec OLF's online dictionary has
> translations for a few related terms:
>
> lecture en transit
> diffusion en flux
> données de transmission en continu
>
>
> greg
>
>> On 20 Jan 2010 08:21, "damien clochard" <damien(at)dalibo(dot)info
>> <mailto:damien(at)dalibo(dot)info>> wrote:
>>
>> Bonjour à toutes et à tous,
>>
>> Si vous êtes un aficionado de PostgreSQL, vous êtes probablement déjà au
>> courant qu'un patch dénomé "Streaming Réplication" vient d'être intégré
>> dans la branche principale du dépot CVS.
>>
>> Pour le dire autrement : la future version 8.5 (ou 9.0 ?) devrait
>> pouvoir répliquer les données en "streaming".
>>
>> Et justement, cela fait plusieurs jours que je retourne ce mot dans ma
>> tête et je trouve que le terme passe assez mal en français, voire qu'il
>> prête carrément à confusion puisque dans l'imaginaire de l'internaute
>> francophone ce mot apparait d'habitude dans les expressions du type
>> "J'ai regardé la saison 2 de Gossip Girl en streaming" ... Ce qui
>> d'ailleurs ne veut pas dire grand'chose mais c'est un autre problème :)
>>
>> Pour revenir à PostgreSQL, la "streaming replication" c'est la capacité
>> d'affiner le mécanisme de Log Shipping. En effet, jusqu'à présent le log
>> shipping était un mécanisme de redondance un peu frustre puisque se
>> basait sur l'export des journaux de transaction ( nommés xlogs ou WAL ).
>> Ces journaux faisant 16Mo chacun, on pouvait atteindre un décalage de
>> 16Mo entre le serveur principal et le secondaire.
>>
>> La "streaming réplication" résout le problème en répliquant les données
>> transaction par transaction, ce qui améliore grandement la
>> synchronisation entre les noeuds. Vous l'aurez compris : avec cette
>> fonctionnalité, ajoutée au "Hot Standby" qui est déjà présent dans la
>> version alpha, PostgreSQL proposera dans quelques semaines un système de
>> réplication simple et totalement intégré au moteur.
>>
>> J'en vient donc à mon problème initial : comment traduire ce terme.
>> Google me propose "réplication ruisselante" qui assez poétique mais pas
>> vraiment utilisable :-)
>> De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
>> en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)
>>
>> Avez-vous une meilleure traduction pour cette fonctionnalité ?
>>
>>
>> PS : Pour les plus impatient(e)s, la "Streaming Réplication" sera inclue
>> dans la version PostgreSQL 8.5 Alpha4, qui ne devrait pas tarder :-)
>>
>> --
>> damien
>> dalibo.org <http://dalibo.org> | dalibo.com <http://dalibo.com>
>>
>> --
>> Sent via pgsql-fr-generale mailing list
>> (pgsql-fr-generale(at)postgresql(dot)org
>> <mailto:pgsql-fr-generale(at)postgresql(dot)org>)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-fr-generale
>

This e-mail, and any file transmitted with it, is confidential and intended solely for the use of the individual or entity to whom it is addressed. If you have received this email in error, please contact the sender and delete the email from your system. If you are not the named addressee you should not disseminate, distribute or copy this email.

For more information on Agence France-Presse, please visit our web site at http://www.afp.com

Bonjour,
je me glisse dans la discussion :
>
> Réplication au niveau des transaction

L'anglais est la langue internationale par défaut, mais je suis d'avis
que rien n'interdit d'améliorer une traduction pour la rendre plus
explicite en Français.
Je propose quelque chose comme : "réplication par transaction", ou
"réplication par flux transactionnel".

J'aime bien "réplication au fil de l'eau".
Sinon, la première chose à laquelle j'ai pensé en lisant des articles
dessus c'est "à la volée", donc "réplication à la volée".
Je pense que c'est presque équivalent, mais "à la volée" a une
connotation plus dynamique que "au fil de l'eau". Mais je ne suis pas
sûre que cela soit aussi fidèle au terme "streaming".

On 20/01/2010 09:20, damien clochard wrote:
> Bonjour à toutes et à tous,

> J'en vient donc à mon problème initial : comment traduire ce terme.
> Google me propose "réplication ruisselante" qui assez poétique mais pas
> vraiment utilisable :-)
> De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
> en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)
>
> Avez-vous une meilleure traduction pour cette fonctionnalité ?
>

Le 20/01/2010 09:20, damien clochard a écrit :
> (...)J'en vient donc à mon problème initial : comment traduire ce terme.
> (...)
> Avez-vous une meilleure traduction pour cette fonctionnalité ?
>
>
Réplication en continu (sans e)

J'aime beaucoup les explications de " l'office de la langue française "
(granddictionnaire.com) :

###

Définition :
Relatif à un contenu multimédia qui est exécuté en temps réel sur le
poste client pendant la transmission.
.

Sous-entrée(s) : .
**

quasi-synonyme(s)
transit, en loc. adj.

. Note(s) :
On utilise l'expression /en continu/ lorsqu'on adopte le point de vue du
serveur qui transmet le contenu multimédia en un flot continu
(/stream/), et on utilise l'expression /en transit/ lorsqu'on adopte le
point de vue du poste client, sur lequel les données sont exécutées, au
fur et à mesure du téléchargement d'un fichier.

###

Stéphane Schildknecht
http://www.postgresql.fr

"Réplication Logique" => Peut être une traduction technique, la plus fidèle,
dans la mesure où on ne réplique que les transactions commitées.
D.
Le 20 janvier 2010 09:20, damien clochard <damien(at)dalibo(dot)info> a écrit :

> Bonjour à toutes et à tous,
>
> Si vous êtes un aficionado de PostgreSQL, vous êtes probablement déjà au
> courant qu'un patch dénomé "Streaming Réplication" vient d'être intégré
> dans la branche principale du dépot CVS.
>
> Pour le dire autrement : la future version 8.5 (ou 9.0 ?) devrait
> pouvoir répliquer les données en "streaming".
>
> Et justement, cela fait plusieurs jours que je retourne ce mot dans ma
> tête et je trouve que le terme passe assez mal en français, voire qu'il
> prête carrément à confusion puisque dans l'imaginaire de l'internaute
> francophone ce mot apparait d'habitude dans les expressions du type
> "J'ai regardé la saison 2 de Gossip Girl en streaming" ... Ce qui
> d'ailleurs ne veut pas dire grand'chose mais c'est un autre problème :)
>
> Pour revenir à PostgreSQL, la "streaming replication" c'est la capacité
> d'affiner le mécanisme de Log Shipping. En effet, jusqu'à présent le log
> shipping était un mécanisme de redondance un peu frustre puisque se
> basait sur l'export des journaux de transaction ( nommés xlogs ou WAL ).
> Ces journaux faisant 16Mo chacun, on pouvait atteindre un décalage de
> 16Mo entre le serveur principal et le secondaire.
>
> La "streaming réplication" résout le problème en répliquant les données
> transaction par transaction, ce qui améliore grandement la
> synchronisation entre les noeuds. Vous l'aurez compris : avec cette
> fonctionnalité, ajoutée au "Hot Standby" qui est déjà présent dans la
> version alpha, PostgreSQL proposera dans quelques semaines un système de
> réplication simple et totalement intégré au moteur.
>
> J'en vient donc à mon problème initial : comment traduire ce terme.
> Google me propose "réplication ruisselante" qui assez poétique mais pas
> vraiment utilisable :-)
> De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
> en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)
>
> Avez-vous une meilleure traduction pour cette fonctionnalité ?
>
>
> PS : Pour les plus impatient(e)s, la "Streaming Réplication" sera inclue
> dans la version PostgreSQL 8.5 Alpha4, qui ne devrait pas tarder :-)
>
> --
> damien
> dalibo.org | dalibo.com
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>

David Tokmatchi <dtokmatchi(dot)capdba(at)pierre-vacances(dot)fr> writes:

> "Réplication Logique" => Peut être une traduction technique, la plus
> fidèle, dans la mesure où on ne réplique que les transactions
> commitées.

Sauf que l'on réplique les journaux binaires contenant les modifications
physiques à apporter aux fichiers de données stockant la base de
données.

On est très loin du niveau « logique » ici.

Une fois de plus un terme générique tel que « fil de l'eau » ou bien
encore « en continu » peut être appliqué à toutes les solutions de
réplications asynchrones du marché. Évitons d'être coincé pour décrire
en français la 9.1.

--
dim

Le 21 janvier 2010 20:38, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> a écrit :
> David Tokmatchi <dtokmatchi(dot)capdba(at)pierre-vacances(dot)fr> writes:
>
>> "Réplication Logique" => Peut être une traduction technique, la plus
>> fidèle, dans la mesure où on ne réplique que les transactions
>> commitées.
>
> Sauf que l'on réplique les journaux binaires contenant les modifications
> physiques à apporter aux fichiers de données stockant la base de
> données.
>
> On est très loin du niveau « logique » ici.
>
> Une fois de plus un terme générique tel que « fil de l'eau » ou bien
> encore « en continu » peut être appliqué à toutes les solutions de
> réplications asynchrones du marché. Évitons d'être coincé pour décrire
> en français la 9.1.

par flux transactionnel me semblait adéquat.

>
> --
> dim
>
> --
> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-fr-generale
>

--
Cédric Villemain

Le 21 janvier 2010 23:57, Cédric Villemain
<cedric(dot)villemain(dot)debian(at)gmail(dot)com> a écrit :
> Le 21 janvier 2010 20:38, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> a écrit :
>> David Tokmatchi <dtokmatchi(dot)capdba(at)pierre-vacances(dot)fr> writes:
>>
>>> "Réplication Logique" => Peut être une traduction technique, la plus
>>> fidèle, dans la mesure où on ne réplique que les transactions
>>> commitées.
>>
>> Sauf que l'on réplique les journaux binaires contenant les modifications
>> physiques à apporter aux fichiers de données stockant la base de
>> données.
>>
>> On est très loin du niveau « logique » ici.
>>
>> Une fois de plus un terme générique tel que « fil de l'eau » ou bien
>> encore « en continu » peut être appliqué à toutes les solutions de
>> réplications asynchrones du marché. Évitons d'être coincé pour décrire
>> en français la 9.1.
>
> par flux transactionnel me semblait adéquat.

oops

par flux de transactions

>
>>
>> --
>> dim
>>
>> --
>> Sent via pgsql-fr-generale mailing list (pgsql-fr-generale(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-fr-generale
>>
>
>
>
> --
> Cédric Villemain
>

--
Cédric Villemain

Après réflexion,

Ce qu'on veut véhiculer comme idée, c'est bien que cette réplication entraine
une perte de données minime je pense. Y a t'il des gens pas d'accord avec ça ?
c'est peut être le premier point à élucider, j'ai l'impression qu'on n'est pas
tous en train de vouloir traduire la même chose.

Si c'est bien cela, on ne veut pas forcément traduire un détail de
l'implémentation, même si pour nous c'est très important que ça soit fait via
le mécanisme de journalisation, donc robuste.

Je pensais donc à 'réplication continue' plutôt que 'réplication en continu' ?
Je trouve que ça fait déjà moins lourd (le côté esthète en moi :) ), et ça
souligne bien la vraie différence avec le log shipping… je sais que je pinaille
en enlevant un mot, mais je n'ai rien vu qui me plaise vraiment pour le
moment : les propositions me semblent soit trop techniques soit trop imagées
(le fil de l'eau).

Le mercredi 20 janvier 2010 09:20:49, damien clochard a écrit :
> Bonjour à toutes et à tous,
>
> Si vous êtes un aficionado de PostgreSQL, vous êtes probablement déjà au
> courant qu'un patch dénomé "Streaming Réplication" vient d'être intégré
> dans la branche principale du dépot CVS.
>
> Pour le dire autrement : la future version 8.5 (ou 9.0 ?) devrait
> pouvoir répliquer les données en "streaming".
>
> Et justement, cela fait plusieurs jours que je retourne ce mot dans ma
> tête et je trouve que le terme passe assez mal en français, voire qu'il
> prête carrément à confusion puisque dans l'imaginaire de l'internaute
> francophone ce mot apparait d'habitude dans les expressions du type
> "J'ai regardé la saison 2 de Gossip Girl en streaming" ... Ce qui
> d'ailleurs ne veut pas dire grand'chose mais c'est un autre problème :)
>
> Pour revenir à PostgreSQL, la "streaming replication" c'est la capacité
> d'affiner le mécanisme de Log Shipping. En effet, jusqu'à présent le log
> shipping était un mécanisme de redondance un peu frustre puisque se
> basait sur l'export des journaux de transaction ( nommés xlogs ou WAL ).
> Ces journaux faisant 16Mo chacun, on pouvait atteindre un décalage de
> 16Mo entre le serveur principal et le secondaire.
>
> La "streaming réplication" résout le problème en répliquant les données
> transaction par transaction, ce qui améliore grandement la
> synchronisation entre les noeuds. Vous l'aurez compris : avec cette
> fonctionnalité, ajoutée au "Hot Standby" qui est déjà présent dans la
> version alpha, PostgreSQL proposera dans quelques semaines un système de
> réplication simple et totalement intégré au moteur.
>
> J'en vient donc à mon problème initial : comment traduire ce terme.
> Google me propose "réplication ruisselante" qui assez poétique mais pas
> vraiment utilisable :-)
> De mon coté, j'ai pensé à "réplication en continue" (bof) , "réplication
> en flux tendu" (re-bof) ou encore "réplication au fil de l'eau" (?!)
>
> Avez-vous une meilleure traduction pour cette fonctionnalité ?
>
>
> PS : Pour les plus impatient(e)s, la "Streaming Réplication" sera inclue
> dans la version PostgreSQL 8.5 Alpha4, qui ne devrait pas tarder :-)
>
> --
> damien
> dalibo.org | dalibo.com
>

Marc Cousin <mcousin(at)sigma(dot)fr> writes:
> Ce qu'on veut véhiculer comme idée, c'est bien que cette réplication entraine
> une perte de données minime je pense. Y a t'il des gens pas d'accord
> avec ça ?

Moi :)

On parlera de haute dispo et de garanties sur les données avec une
solution synchrone, c'est à dire qui ne donne le message de COMMIT que
si la transaction est déjà sur le slave (rejouée, sur disque ou bien à
la sortie du réseau, c'est à voir, un peu comme DRBD, mais tout de
même).

> Je pensais donc à 'réplication continue' plutôt que 'réplication en continu' ?
> Je trouve que ça fait déjà moins lourd (le côté esthète en moi :) ), et ça
> souligne bien la vraie différence avec le log shipping…

Il se trouve que la solution de Streaming Replication *est* du log
shipping. La seule différence avec les outils précédents c'est que c'est
intégré à PostgreSQL, qui démarre tout seul les process walsender et
walreceiver, plutôt que de passer par les archive_command et
restore_command.

Notons également que le Slave continue d'avoir besoin d'une
restore_command sachant trouver les journaux dans les archives du
master.

Je ne vois pas en quoi masquer la technique employée nous servirait, et
au risque d'insister lourdement, propose « réplication des journaux
de transactions » (en fait WAL n'est pas traduit par journal binaire
actuellement, autant reprendre les termes déjà en usage) :

http://docs.postgresqlfr.org/8.4/wal.html

--
dim

Le vendredi 22 janvier 2010 09:40:13, Dimitri Fontaine a écrit :
> Marc Cousin <mcousin(at)sigma(dot)fr> writes:
> > Ce qu'on veut véhiculer comme idée, c'est bien que cette réplication
> > entraine une perte de données minime je pense. Y a t'il des gens pas
> > d'accord avec ça ?
>
> Moi :)

Comme quoi j'ai bien fait de poser la question :)

>
> On parlera de haute dispo et de garanties sur les données avec une
> solution synchrone, c'est à dire qui ne donne le message de COMMIT que
> si la transaction est déjà sur le slave (rejouée, sur disque ou bien à
> la sortie du réseau, c'est à voir, un peu comme DRBD, mais tout de
> même).

D'accord avec toi. Je n'ai d'ailleurs pas parlé de ça non plus. L'intérêt de
la streaming replication c'est qu'elle réduit le RPO, sans le rendre nul. Donc
qu'elle améliore la situation par rapport au log shipping classique (celui
utilisé sur une base de standby en temps normal, où la granularité est de
l'ordre de la fréquence de génération des journaux).

>
> > Je pensais donc à 'réplication continue' plutôt que 'réplication en
> > continu' ? Je trouve que ça fait déjà moins lourd (le côté esthète en moi
> > :) ), et ça souligne bien la vraie différence avec le log shipping…
>
> Il se trouve que la solution de Streaming Replication *est* du log
> shipping. La seule différence avec les outils précédents c'est que c'est
> intégré à PostgreSQL, qui démarre tout seul les process walsender et
> walreceiver, plutôt que de passer par les archive_command et
> restore_command.

C'est tout de même différent dans le sens où les senders envoient des
enregistrements de wal au lieu de wal entière, ce qui permet justement d'avoir
une perte de données beaucoup plus faible en cas de bascule. Par contre
d'accord avec toi, ça s'appuie sur le même mécanisme (et c'est le point le
plus important, c'est ce qui en fait un gage de qualité).

>
> Notons également que le Slave continue d'avoir besoin d'une
> restore_command sachant trouver les journaux dans les archives du
> master.

Je ne vois pas de mention de celà ici :
http://developer.postgresql.org/pgdocs/postgres/warm-standby.html
(mais je n'ai pas encore testé le streaming pour le moment, si c'est ton cas
et que tu en es sûr, j'ai rien dit :) )

>
> Je ne vois pas en quoi masquer la technique employée nous servirait, et
> au risque d'insister lourdement, propose « réplication des journaux
> de transactions » (en fait WAL n'est pas traduit par journal binaire
> actuellement, autant reprendre les termes déjà en usage) :
>
> http://docs.postgresqlfr.org/8.4/wal.html
>

Je ne parle pas de masquer la technique volontairement, mais je pense que son
nom doit refléter ce qu'elle fait, pas forcément comment elle le fait.

Marc Cousin <mcousin(at)sigma(dot)fr> writes:
> D'accord avec toi. Je n'ai d'ailleurs pas parlé de ça non plus. L'intérêt de
> la streaming replication c'est qu'elle réduit le RPO, sans le rendre nul. Donc
> qu'elle améliore la situation par rapport au log shipping classique (celui
> utilisé sur une base de standby en temps normal, où la granularité est de
> l'ordre de la fréquence de génération des journaux).

Ça dépend de la solution utilisée, voir walmgr.py master sync et si je
me souviens bien archive_timeout pour forcer une fermeture du WAL avant
les 16 MBits.

http://skytools.projects.postgresql.org/doc/walmgr.html
http://www.postgresql.org/docs/8.4/static/runtime-config-wal.html

> C'est tout de même différent dans le sens où les senders envoient des
> enregistrements de wal au lieu de wal entière, ce qui permet justement d'avoir
> une perte de données beaucoup plus faible en cas de bascule. Par contre
> d'accord avec toi, ça s'appuie sur le même mécanisme (et c'est le point le
> plus important, c'est ce qui en fait un gage de qualité).

Je reste mal à l'aise avec ta façon d'aborder le sujet, qui à mon sens
mélange le délais de réplication avec la fiabilité de la solution. Une
granularité plus fine est un avantage certain, mais que je placerais
dans le cadre de la fraîcheur des données accessibles en lecture seule
sur l'esclave.

>> Notons également que le Slave continue d'avoir besoin d'une
>> restore_command sachant trouver les journaux dans les archives du
>> master.
>
> Je ne vois pas de mention de celà ici :
> http://developer.postgresql.org/pgdocs/postgres/warm-standby.html
> (mais je n'ai pas encore testé le streaming pour le moment, si c'est ton cas
> et que tu en es sûr, j'ai rien dit :) )

http://archives.postgresql.org/pgsql-hackers/2010-01/msg01906.php
http://archives.postgresql.org/pgsql-hackers/2010-01/msg02005.php

> Je ne parle pas de masquer la technique volontairement, mais je pense que son
> nom doit refléter ce qu'elle fait, pas forcément comment elle le fait.

Je continuer de préférer « réplication des journaux de transaction »…
Enfin c'est juste une proposition, un peu appuyée quoi  :)

--
Dimitri Fontaine
PostgreSQL DBA, Architecte