Réplication en continu PostgreSQL vs réplication logique

Je me considère un peu comme un explorateur. Dans certaines choses qui est. En règle générale, je commande toujours le même plat dans un restaurant familier, car la peur de la déception l'emporte sur mon appréhension d'essayer quelque chose de nouveau.

Et bien sûr, un humain affamé a tendance à manger correctement ?

Pourtant, en ce qui concerne la technologie, en particulier SQL (PostgreSQL), j'ai tendance à trébucher à toute vitesse (ma définition de l'exploration) dans des domaines souvent inconnus, avec l'espoir d'apprendre. Quoi de mieux que l'expérience pour apprendre ?

Alors, qu'est-ce que cette divagation a à voir avec la réplication logique et en continu dans PostgreSQL ?

Je suis un novice complet dans ces domaines avec aucune connaissance. Oui, j'ai à peu près autant de connaissances dans ce domaine de Postgres qu'en astrophysique.

Ai-je mentionné que je n'avais aucune connaissance ?

Par conséquent, dans cet article de blog, je vais essayer de digérer les différences entre ces types de réplication. Sans expérience pratique dans le monde réel, je ne peux pas vous promettre le 'Be all end all ' manuscrit pour reproduction.

Il est probable que d'autres moins versés dans ce domaine particulier (comme moi) bénéficieraient de cet article de blog.

Utilisateurs et développeurs expérimentés, j'espère vous voir dans les commentaires ci-dessous.

Quelques définitions de base

Au sens large du terme, que veut dire Réplication ?

La réplication telle que définie sur le Wiktionnaire a ceci à dire :

"Processus par lequel un objet, une personne, un lieu ou une idée peut être copié, imité ou reproduit."

Pourtant, le 5ème élément répertorié s'applique davantage à cet article de blog et je pense que nous devrions également l'examiner :

"(informatique) Processus consistant à copier fréquemment des données électroniques d'une base de données sur un ordinateur ou un serveur vers une base de données sur un autre afin que tous les utilisateurs partagent le même niveau d'informations. Utilisé pour améliorer la tolérance aux pannes du système."

Maintenant, il y a quelque chose dans lequel nous pouvons entrer. La mention de copier des données d'un serveur ou d'une base de données à un autre ? Nous sommes maintenant en terrain connu...

Donc, en ajoutant ce que nous savons de cette définition, quelles sont les définitions de la réplication en continu et de la réplication logique ?

Voyons ce que le Wiki PostgreSQL a à offrir :

Streaming Replication :"fournit la capacité d'expédier et d'appliquer en continu les enregistrements WAL XLOG à un certain nombre de serveurs de secours afin de les maintenir à jour.

Et la documentation PostgreSQL a cette définition pour la réplication logique :

"La réplication logique est une méthode de réplication des objets de données et de leurs modifications, basée sur leur identité de réplication (généralement une clé primaire). Nous utilisons le terme logique par opposition à la réplication physique, qui utilise des adresses de bloc exactes et une réplication octet par octet. "

Le chapitre 19.6 La réplication de la documentation officielle regorge également de bonnes choses, alors assurez-vous de visiter cette source.

Ci-dessous, je vais tenter de relayer les différences en termes simples. (Rappelez-vous, si je trébuche, je suis novice.) Il s'agit d'un aperçu de "haut niveau" extrême.

Réplication logique

Une base de données "source" crée une PUBLICATION à l'aide de la commande CREATE PUBLICATION. (Je pense à cela en termes simples comme "l'expéditeur".)

La documentation le désigne comme éditeur.

Cette base de données d'éditeur contient les données que nous voulons répliquer. Pourtant, nous devons avoir quelque chose à répliquer et c'est là que les homologues de l'éditeur entrent en jeu. Le « abonné ». Remarquez que j'ai ajouté une forme plurielle alternative parce que d'après ce que j'ai trouvé grâce à des recherches en ligne, c'est une configuration pratique pour avoir plusieurs abonnés.

Un « abonné » (peut également être considéré comme la base de données répliquée) crée un ABONNEMENT à une base de données « source » (éditeur) définissant les informations de connexion et toutes les publications auxquelles il est abonné.

Il est possible qu'un abonné soit également éditeur, créant sa propre PUBLICATION à laquelle d'autres abonnés peuvent s'abonner.

Que se passe-t-il maintenant ?

Toutes les modifications de données qui se produisent sur l'éditeur sont envoyées à l'abonné. Ce qui, prêt à l'emploi, est tout, mais peut être configuré ou limité à certaines opérations (par exemple, INSERT, UPDATE ou DELETE).

Exemple de haut niveau :

Supposons que nous mettions à jour une ligne ou plusieurs lignes sur une table particulière dans l'éditeur, ces mises à jour et modifications sont répliquées sur l'instance de l'abonné ou sur plusieurs abonnés si ce type de configuration est implémenté.

Voici quelques éléments à retenir que je me suis senti digne de mentionner :

• La configuration wal_level de la base de données de l'éditeur doit être définie sur logique.
• La réplication logique n'a pas de commandes DDL (Data Definition Language).
• Sur la page Conflits de la documentation :"La réplication logique se comporte de la même manière que les opérations DML normales dans la mesure où les données seront mises à jour même si elles ont été modifiées localement sur le nœud abonné. Si les données entrantes violent des contraintes, la réplication s'arrêtera. Cela est considéré comme un conflit. Lors de la réplication des opérations UPDATE ou DELETE, les données manquantes ne produiront pas de conflit et ces opérations seront simplement ignorées."
• Les tables de l'éditeur doivent avoir un moyen de s'identifier (appelé "identité du réplica") afin de répliquer correctement les opérations DML (UPDATE et DELETE) dans n'importe quel(s) réplica(s) pour les lignes concernées. Si la table a une clé primaire, c'est la valeur par défaut (cela me semble être le bon choix), mais en l'absence de clé primaire, d'autres options de configuration sont disponibles. La ligne entière peut être utilisée s'il n'existe aucune autre clé candidate (appelée "complète"), bien que la documentation mentionne que ce n'est généralement pas une solution efficace. (Voir la section REPLICA IDENTITY dans la documentation pour une description de niveau inférieur de la façon de le définir)

Restrictions

La documentation de la section 31.4. Restrictions a quelques rappels clés sur les restrictions que je vais passer sous silence. Assurez-vous de consulter la page liée ci-dessus pour connaître le verbiage exact.

• Le schéma de base de données et les commandes DDL ne sont pas pris en charge dans la réplication. Il est suggéré que peut-être pg_dump pourrait être utilisé initialement, mais vous devrez quand même mettre à jour vous-même toutes les modifications et avancées ultérieures dans le schéma pour toutes les répliques.
• Les données des colonnes de séquence seront répliquées. Mais, la séquence elle-même ne refléterait que la valeur de départ. Pour les lectures, ça va. Mais s'il s'agit de votre choix pour le basculement, vous devrez vous-même mettre à jour la valeur actuelle. La documentation suggère pg_dump ici.
• Tronquer n'est pas encore pris en charge.
• La réplication d'objets volumineux n'est pas prise en charge.
• Les vues, les vues matérialisées, les tables racine de partition ou les tables étrangères ne sont prises en charge ni sur l'éditeur ni sur l'abonné.

Cas d'utilisation courants signalés

• Vous n'êtes intéressé que par certaines données et modifications de données que vous répliquez réellement plutôt que par la simple réplication de l'intégralité de la base de données.
• Lorsque vous avez besoin d'instances dupliquées pour des opérations en lecture seule, telles qu'un scénario d'analyse.
• Autoriser les utilisateurs ou différents sous-ensembles d'utilisateurs à accéder de manière limitée ou surveillée aux données
• Distribuer des données.
• Compatibilité avec d'autres versions de PostgreSQL.

Réplication en continu

Après avoir recherché, lu et étudié la réplication en continu, une chose que je comprends dès le départ, c'est de choisir de configurer une réplication asynchrone (par défaut) ou synchrone.

Ah, des termes plus inconnus, hein ?

Voici ma définition "de haut niveau" des deux :

Avec la réplication asynchrone, une fois qu'une transaction est validée sur le primaire, il y a un léger délai lorsque cette même transaction est validée et écrite sur le réplica. Il existe un risque de perte de données avec ce type de configuration.

• Premièrement, supposons que le maître tombe en panne.
• Deuxièmement, la ou les répliques sont tellement en retard sur le maître qu'elles ont supprimé les données et informations nécessaires pour que la ou les répliques soient même "actuelles".

Cependant, dans la réplication synchrone, aucune transaction n'est considérée comme terminée tant qu'elle n'est pas confirmée par le(s) serveur(s) maître et réplique. Qui aura écrit un commit sur les WAL des deux serveurs.

En termes que je comprends, cela signifie que les écritures sur le maître ont également été confirmées et écrites sur la réplique.

Voici l'explication officielle de la section 26.2.8. Synchronous Replication dans la documentation officielle :

"Lors de la demande de réplication synchrone, chaque validation d'une transaction d'écriture attendra la réception de la confirmation que la validation a été écrite dans le journal d'écriture anticipée sur le disque du serveur principal et du serveur de secours. “

Un autre passage de la documentation contient un bon aperçu de ce qui doit être (à mon avis), un énorme avantage :"La seule possibilité que des données puissent être perdues est si le primaire et le standby subissent des plantages en même temps."

Bien que rien ne soit impossible, c'est quand même une assez bonne assurance que vous ne vous retrouverez pas sans copie de vos données.

D'accord, nous savons que nous devons choisir l'une de ces configurations d'installation, mais quelle est l'essentiel ?

En un mot, Streaming Replication envoie et applique les fichiers WAL (Write Ahead Log) d'un serveur de base de données (maître ou primaire) à une « réplique » (base de données réceptrice).

Mais il y a une mise en garde ici à garder à l'esprit. Potentiellement, les fichiers WAL du maître peuvent être recyclés avant que le standy ne les ait reçus. Une façon d'atténuer cela consiste à augmenter le paramètre wal_keep_segments à une valeur plus élevée.

Points sur la réplication en continu

• Par défaut, la réplication en continu est asynchrone, ce qui signifie qu'il existe un délai (peut-être faible) entre les transactions validées sur le maître et leur visibilité sur le réplica.
• Les répliques se connectent au maître via une connexion réseau.
• Soyez attentif à l'authentification. Voir ici dans la documentation :"Il est très important que les privilèges d'accès pour la réplication soient configurés de manière à ce que seuls les utilisateurs de confiance puissent lire le flux WAL car il est facile d'en extraire des informations privilégiées"

Quand utiliser la réplication en continu

• Une utilisation courante (en particulier dans l'analyse) fournit une réplique "en lecture seule" pour alléger la charge du serveur principal.
• Vous avez besoin d'un environnement à haute disponibilité.
• Configuration utile pour le basculement vers le serveur de secours en cas de panne du serveur principal.