Skip to content

Commit

Permalink
Relecture de logical-replication.xml
Browse files Browse the repository at this point in the history
  • Loading branch information
@gleu
Jean-Paul Argudo authored and gleu committed Aug 5, 2022
1 parent 49a1511 commit 9691d40
Showing 1 changed file with 48 additions and 48 deletions.
96 changes: 48 additions & 48 deletions postgresql/logical-replication.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,29 +5,29 @@
<para>
La réplication logique est une méthode permettant de répliquer des données au
niveau objet ainsi que les modifications apportées à ces objets, ceci basé sur
leur identité de réplication (habituellement la clé primaire). L'utilisation
du terme <quote>réplication logique</quote> est faite en opposition à la
réplication physique qui, elle, utilise l'adresse exacte des blocs couplée
leur identité de réplication (habituellement la clé primaire). L'utilisation
du terme de <quote>réplication logique</quote> est faite en opposition à la
réplication physique qui utilise elle l'adresse exacte des blocs couplée
avec une réplication octet par octet. PostgreSQL supporte ces deux méthodes,
référez-vous à l'article <xref linkend="high-availability"/>. La réplication
référez-vous à l'article <xref linkend="high-availability"/>. La réplication
logique permet un contrôle fin des données au niveau de la réplication et de
la sécurité.
</para>

<para>
La réplication logique utilise un système de
<firstterm>publication</firstterm>/<firstterm>abonnement</firstterm> avec un
<firstterm>publication</firstterm> / <firstterm>abonnement</firstterm> avec un
ou plusieurs <firstterm>abonnés</firstterm> qui s'abonnent à une ou plusieurs
<firstterm>publications</firstterm> d'un nœud particulier. Les abonnés
récupèrent les données des publications auxquelles ils sont abonnés et peuvent
éventuellement renvoyer ces informations pour permettre un système de
éventuellement renvoyer ces informations, ce qui permet un système de
réplication en cascade dans le cas de configurations plus complexes.
</para>

<para>
La réplication logique d'une table commence en générale en prenant un
La réplication logique d'une table commence en général en prenant un
instantané des données sur la base publiée et en le copiant vers la base
abonnée. Une fois cette étape réalisée, les changements sur la base publiée
abonnée. Une fois cette étape réalisée, les changements sur la base publiée
sont envoyés à la base abonnée en temps réel. La base abonnée applique les
modifications dans le même ordre qu'elles auront été réalisées de façon à ce
que la cohérence transactionnelle soit garantie pour les publications d'un
Expand All @@ -44,40 +44,40 @@
<para>
Envoyer immédiatement les changements réalisés sur une base de données, ou
sur un sous-ensemble de ces données, de façon incrémentale à une base de
données abonnée.
données abonnée;
</para>
</listitem>

<listitem>
<para>
Déclencher des triggers pour des changements spécifiques lorsqu'ils
apparaissent sur la base de données abonnée.
apparaissent sur la base de données abonnée;
</para>
</listitem>

<listitem>
<para>
Réaliser la consolidation de plusieurs bases de données au sein d'une seule
(par exemple pour répondre à des problématiques analytiques).
(par exemple pour répondre à des problématiques analytiques);
</para>
</listitem>

<listitem>
<para>
Répliquer entre des versions majeures différentes de PostgreSQL.
Répliquer entre des versions majeures différentes de PostgreSQL;
</para>
</listitem>

<listitem>
<para>
Répliquer des instances PostgreSQL sur des plateformes différentes (par
exemple de Linux à Windows).
exemple de Linux à Windows);
</para>
</listitem>

<listitem>
<para>
Donner accès à des données répliquées à différents groupes d'utilisateurs.
Donner accès à des données répliquées à différents groupes d'utilisateurs;
</para>
</listitem>

Expand All @@ -93,8 +93,8 @@
Une base de données abonnée se comporte comme n'importe quelle autre base de
données d'une instance PostgreSQL et peut être utilisée comme base de données
de publication pour d'autres base de données en lui définissant ses propres
publications. Lorsque la base abonnée est considérée comme une base en
lecture seule par l'application, il ne va pas y avoir de problèmes de conflit.
publications. Lorsque la base abonnée est considérée comme une base en
lecture seule par l'application, il ne va pas y avoir de problèmes de conflits.
D'un autre côté, s'il y a des écritures provenant soit de l'application soit
d'un autre abonnement sur le même ensemble de tables, des conflits peuvent
survenir.
Expand All @@ -116,7 +116,7 @@
<para>
Les publications sont différenciées du schéma et n'ont pas d'impact sur la
manière dont la base est accédée. Chaque table peut être ajoutée à
différentes publications si besoin. Actuellement, les publications ne
différentes publications au besoin. Actuellement, les publications ne
contiennent que les tables et toutes les tables d'un schéma. Les objets
doivent être ajoutés explicitement, sauf si la publication a été créée pour
toutes les tables (<literal>ALL TABLES</literal>).
Expand Down Expand Up @@ -144,7 +144,7 @@
index d'unicité (avec quelques prérequis supplémentaires) peut aussi être
configuré du côté de l'abonné. Si la table n'a pas de clé convenable, alors
elle peut être configurée pour l'identité de réplicat <quote>full</quote>, ce
qui signifie que la ligne entière devient la clé. Néanmoins, ceci est très
qui signifie que la ligne entière devient la clé. Néanmoins, ceci est très
inefficace et devrait seulement être utilisé si aucune autre solution n'est
disponible. Si une identité de réplication est différente de
<quote>full</quote> du côté du publieur, une identité de réplication
Expand All @@ -154,9 +154,9 @@
configuration de l'identité de réplication. Si une table sans identité de
réplication est ajoutée à une publication qui réplique les opérations
<command>UPDATE</command> ou <command>DELETE</command>, alors les opérations
<command>UPDATE</command> ou <command>DELETE</command> suivantes causera une
<command>UPDATE</command> ou <command>DELETE</command> suivantes causeront une
erreur sur le publieur. Les opérations <command>INSERT</command> peuvent se
réaliser quelque soit l'identité de réplication.
réaliser quelle que soit l'identité de réplication.
</para>

<para>
Expand Down Expand Up @@ -264,8 +264,8 @@
L'ordre des colonnes dans la table sur le serveur abonné ne correspond pas
forcément à l'ordre sur le serveur publieur. Les types de données n'ont pas
non plus besoin de correspondre, à partir du moment où la représentation
textuelle de la donnée puisse être convertie vers le type de données cible.
Par exemple, vous pouvez répliquer d'une colonne de type <type>integer</type>
textuelle de la donnée peut être convertie vers le type de données cible.
Par exemple, vous pouvez répliquer depuis une colonne de type <type>integer</type>
vers une colonne de type <type>bigint</type>. La table cible peut aussi avoir
des colonnes supplémentaires non fournies par la table publiée. Ce type de
colonne sera rempli avec la valeur par défaut fournie dans la définition de
Expand Down Expand Up @@ -295,7 +295,7 @@
Normalement, le slot de réplication distant est créé automatiquement en
utilisant la commande <command>CREATE SUBSCRIPTION</command> et il est
supprimé automatiquement en utilisant la commande <command>DROP
SUBSCRIPTION</command>. Dans certaines situations, il peut être utile ou
SUBSCRIPTION</command>. Dans certaines situations, il peut être utile ou
nécessaire de manipuler les abonnements ainsi que les slots de réplication
sous-jacents de façon séparées. Voici quelques exemples&nbsp;:

Expand All @@ -305,7 +305,7 @@
Lorsqu'en créant un abonnement, le slot de réplication correspondant
existe déjà. Dans ce cas, l'abonnement peut être créé en utilisant
l'option <literal>create_slot = false</literal> pour réaliser
l'association avec le slot existant.
l'association avec le slot existant;
</para>
</listitem>

Expand All @@ -314,10 +314,10 @@
Lorsqu'en créant un abonnement, le serveur distant n'est pas disponible
ou dans un état indéfini. Dans ce cas, l'abonnement peut être créé en
utilisant l'option <literal>connect = false</literal>. Le serveur
distant ne sera jamais contacté. C'est la méthode utilisée par
distant ne sera alors jamais contacté. C'est la méthode utilisée par
<application>pg_dump</application>. Le slot de réplication distant devra
alors être créé manuellement avant que l'abonnement ne puisse être
activé.
activé;
</para>
</listitem>

Expand All @@ -328,7 +328,7 @@
serveur différent et sera activée depuis cette nouvelle localisation.
Dans ce cas, il faut dissocier le slot de réplication de l'abonnement
correspondant en utilisant la commande <command>ALTER
SUBSCRIPTION</command> avant de supprimer l'abonnement.
SUBSCRIPTION</command> avant de supprimer l'abonnement;
</para>
</listitem>

Expand Down Expand Up @@ -576,7 +576,7 @@ test_sub=# SELECT * FROM t3;
les changements. Si le filtre de ligne est évalué à <literal>false</literal>
ou <literal>NULL</literal>, alors la ligne n'est pas répliquée. L'expression
de la clause <literal>WHERE</literal> est évaluée avec le même rôle utilisé
pour la connexion de réplication (donc le rôle indiqué dans la clause
pour la connexion de réplication (soit le rôle indiqué dans la clause
<literal>CONNECTION</literal> de l'instruction <xref
linkend="sql-createsubscription"/>). Les filtres de ligne n'ont pas deffet
sur la commande <command>TRUNCATE</command>.
Expand All @@ -587,9 +587,9 @@ test_sub=# SELECT * FROM t3;
<title>Restrictions de l'expression</title>

<para>
La clause <literal>WHERE</literal> permet seulement des expressions simples.
La clause <literal>WHERE</literal> autorise uniquement des expressions simples.
Elle ne peut pas contenir de fonctions, opérateurs, types et collations
définis par les utilisateurs, de références aux colonnes systèmes ou à des
définis par les utilisateurs, des références aux colonnes système ou à des
fonctions internes non immutables.
</para>

Expand All @@ -610,7 +610,7 @@ test_sub=# SELECT * FROM t3;
<para>
À chaque fois qu'un <command>UPDATE</command> est traité, l'expression du
filtre de lignes est évaluée pour l'ancienne et la nouvelle ligne (autrement
dit, en utilisant les données avant et après la mise à jour). Si les deux
dit, en utilisant les données avant et après la mise à jour). Si les deux
évaluations valent <literal>true</literal>, les modifications de
l'<command>UPDATE</command> sont répliquées. Si les deux évaluations valent
<literal>false</literal>, les modifications ne sont pas répliquées. Si
Expand Down Expand Up @@ -718,7 +718,7 @@ test_sub=# SELECT * FROM t3;
paramètre <literal>publish</literal> lors de la copie des données
pré-existantes de la table, certaines lignes pourraient être copiées alors
qu'elles n'auraient pas été répliquées avec des instructions DML.
Référez-vous à <xref linkend="logical-replication-snapshot"/>, et voir
Référez-vous à <xref linkend="logical-replication-snapshot"/>, et à
<xref linkend="logical-replication-subscription-examples"/> pour des
exemples.
</para>
Expand All @@ -736,7 +736,7 @@ test_sub=# SELECT * FROM t3;
</sect2>

<sect2 id="logical-replication-row-filter-combining">
<title>Combinet plusieurs filtres de lignes</title>
<title>Combiner plusieurs filtres de lignes</title>

<para>
Si la souscription a plusieurs publications pour lesquelles la même table a
Expand All @@ -748,13 +748,13 @@ test_sub=# SELECT * FROM t3;
<itemizedlist>
<listitem>
<para>
Une des publications n'a pas de filtres de lignes.
Une des publications n'a pas de filtres de lignes;
</para>
</listitem>
<listitem>
<para>
Une des publications a été créée en utilisant <literal>FOR ALL
TABLES</literal>. Cette clause n'autorise pas les filtres de lignes.
TABLES</literal>. Cette clause n'autorise pas les filtres de lignes;
</para>
</listitem>
<listitem>
Expand Down Expand Up @@ -1030,7 +1030,7 @@ test_sub=# SELECT * FROM t1;
</programlisting></para>

<para>
Les exemples suivants montrent comme le paramètre de publication
Les exemples suivants montrent comment le paramètre de publication
<literal>publish_via_partition_root</literal> détermine si le filtre de
ligne de la table parent ou enfant sera utilisé dans le cas de tables
partitionnées.
Expand Down Expand Up @@ -1202,7 +1202,7 @@ DETAIL: Key (c)=(1) already exists.
CONTEXT: processing remote data for replication origin "pg_16395" during "INSERT" for replication target relation "public.test" in transaction 725 finished at 0/14C0378
</screen>
Le LSN de la transaction qui contient le changement violant la contrainte et
le nom d'origine de réplication peut être trouvé à partir du journal
le nom d'origine de réplication peuvent être trouvé à partir du journal
applicatif du serveur (LSN 0/14C0378 et origine de réplication
<literal>pg_16395</literal> dans le cas ci-dessus). La transaction qui a
produit le conflit peut être ignorée en utilisant l'instruction
Expand Down Expand Up @@ -1249,7 +1249,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
l'abonné mais ne correspondent pas à la structure de la table, la
réplication renverra une erreur jusqu'à ce que le schéma soit mis à jour.
Dans de nombreux cas, les erreurs intermittentes peuvent être évitées en
appliquant des modifications de schéma à l'abonné en premier.
appliquant des modifications de schéma à l'abonné en premier;
</para>
</listitem>

Expand All @@ -1266,15 +1266,15 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
alors les séquences auront besoin d'être mises à jour à leur dernières
valeurs, soit en copiant les données courantes du publieur (peut-être en
utilisant <command>pg_dump</command>), soit en déterminant une valeur
suffisamment haute à partir des données de la table.
suffisamment haute à partir des données de la table;
</para>
</listitem>

<listitem>
<para>
La réplication des commandes <command>TRUNCATE</command> est supportée mais
il est nécessaire de prêter attention lors de l'utilisation de cette
commande sur des groupes de tables connectés par des clés étrangères. Lors
commande sur des groupes de tables connectés par des clés étrangères. Lors
de la réplication d'une action truncate, l'abonné tronquera le même groupe
de tables tronquées sur le publieur, qu'elles soient spécifiées
explicitement ou implicitement (grâce à la clause
Expand All @@ -1283,15 +1283,15 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
font partie de la même souscription. Cependant, si certaines tables à
tronquer ont des clés étrangères vers des tables qui ne font pas partie de
la même souscription, alors l'application de l'action truncate échouera sur
le serveur abonné.
le serveur abonné;
</para>
</listitem>

<listitem>
<para>
Les Large Objects (voir <xref linkend="largeobjects"/>) ne sont pas
répliqués. Il n'y a pas de contournement pour ça, en dehors d'enregistrer
les données dans des tables normales.
les données dans des tables normales;
</para>
</listitem>

Expand All @@ -1300,7 +1300,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
La réplication est seulement supportée par les tables, y compris les tables
partitionnées. Toute tentative de répliquer d'autres types de relation,
comme les vues, les vues matérialisées ou les tables externes, résultera en
une erreur.
une erreur;
</para>
</listitem>

Expand All @@ -1309,9 +1309,9 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
Lors de la réplication entre tables partitionnées, la réplication actuelle
a pour origine, par défaut, les partitions filles sur le publieur, donc les
partitions sur le publieur doivent exister aussi sur l'abonné en tant que
tables cibles valides. (Elles peuvent être soit des partitions filles
tables cibles valides. Elles peuvent être soit des partitions filles
elles-mêmes, soit de nouveau sous-partitionnées, soit des tables
indépendantes.). Les publications peuvent aussi spécifier les changements à
indépendantes. Les publications peuvent aussi spécifier les changements à
répliquer en utilisant l'identité et le schéma de la table racine
partitionnée au lieu de chaque partition individuelle à l'origine des
changements (voir <link linkend="sql-createpublication"><command>CREATE
Expand Down Expand Up @@ -1373,7 +1373,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
et copiées dans une instance parallèle qui utilise un type particulier de
processus apply. Ce processus va créer son propre slot de réplication et
copier les données existantes. Dès que la copie est terminée, le contenu de
la table deviendra visible aux autres processus. Une fois les données
la table deviendra visible aux autres processus. Une fois les données
existantes copiées, le processus passe en mode de synchronisation, qui
assure que la table est amenée vers un état synchronisé avec le processus
apply principal, ceci en transférant toutes les modifications survenues
Expand Down Expand Up @@ -1411,7 +1411,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
Les informations des abonnements sont consultables dans la vue <link
linkend="monitoring-pg-stat-subscription"><structname>pg_stat_subscription</structname></link>.
Cette vue contient une ligne pour chaque processus d'abonnement. Un
abonnement peut avoir zéro ou plusieurs processus abonnés selon son état.
abonnement peut avoir zéro ou plusieurs processus abonnés, selon son état.
</para>

<para>
Expand Down Expand Up @@ -1448,7 +1448,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
propriétaires de tables, incluez
<literal>options=-crow_security=off</literal> dans la chaîne de
connexion&nbsp;;: si un propriétaire de table ajoute ensuite une politique de
sécurité ligne, cette configuration imposera un arrêt de la réplication
sécurité de ligne, cette configuration imposera un arrêt de la réplication
plutôt qu'une exécution de la politique. L'accès de ce rôle à l'instance doit
avoir été déclaré dans <filename>pg_hba.conf</filename> et ce rôle doit avoir
l'attribut <literal>LOGIN</literal>.
Expand Down

0 comments on commit 9691d40

Please sign in to comment.