Comment optimiser la réplication logique PostgreSQL

La réplication logique ou Pglogical est un mécanisme de réplication basé sur WAL au niveau de la table qui réplique les données de tables spécifiques entre deux instances PostgreSQL. Il semble y avoir une confusion entre « pglogical » et « Logical Replication ». Les deux fournissent le même type de mécanisme de réplication avec quelques différences dans les fonctionnalités et les capacités. La réplication logique est introduite dans PostgreSQL-10 en tant que fonctionnalité intégrée contrairement à pglogical qui est une extension. "Pglogical" avec des développements continus en cours, reste la seule option pour implémenter la réplication logique pour les environnements utilisant des versions de PostgreSQL antérieures à 10. Finalement, toutes les fonctionnalités faisant partie de pglogical feront partie de la réplication logique. En d'autres termes, pglogical (extension) est devenu la réplication logique (fonctionnalité intégrée). L'avantage de base de la réplication logique est qu'il n'a pas besoin d'installer/créer d'extensions, ce qui est à son tour bénéfique pour les environnements où l'installation d'extensions est restreinte.

Ce blog se concentrera sur l'optimisation de la réplication logique. Cela signifie que les conseils et techniques d'optimisation mis en évidence dans ce blog s'appliqueront à la fois à la réplication pglogical et logique.

La réplication logique est une réplication basée sur WAL qui est la première du genre. En tant que DBA, ce serait un mécanisme de réplication beaucoup plus fiable et performant par rapport à d'autres solutions de réplication basées sur des déclencheurs. Les modifications apportées aux tables faisant partie de la réplication pglogical sont répliquées en temps réel via des enregistrements WAL, ce qui la rend très efficace et simple. Tous les autres mécanismes de réplication du marché sont basés sur des déclencheurs, ce qui peut poser des problèmes de performances et de maintenance. Avec l'arrivée de la réplication logique, la dépendance à la réplication basée sur les déclencheurs a presque disparu.

Il existe d'autres blogs qui expliquent comment configurer la réplication logique de manière assez détaillée.

Dans ce blog, l'accent sera mis sur la façon d'optimiser la réplication logique.

Optimiser la réplication logique

Pour commencer, le comportement de la «réplication logique» est assez similaire à celui de la «réplication en continu», la seule différence est que la réplication en continu réplique la base de données complète alors que la réplication logique ne réplique que des tables individuelles. Lors du choix de tables individuelles spécifiques à répliquer, il y a des facteurs/défis à prévoir.

Examinons les facteurs influençant la réplication logique.

Facteurs influençant les performances de réplication logique

L'optimisation de la réplication logique est importante pour garantir que les données sont répliquées de manière transparente, sans aucune interruption. Il y a des facteurs à prévoir avant de le mettre en place. Jetons-y un coup d'œil :

• Le type de données stockées dans les tables à répliquer
• Dans quelle mesure les tables sont-elles actives sur le plan transactionnel (partie de la réplication) ?
• La capacité de l'infrastructure doit être prévue
• La configuration des paramètres doit être effectuée de manière optimale

Tous les facteurs ci-dessus influencent davantage la réplication logique. Examinons-les en détail.

Types de données de réplication logique PostgreSQL

Il est important de comprendre le type de données stockées dans la table. Si la partie table de la réplication stocke du texte volumineux ou des objets binaires et rencontre un nombre élevé de transactions, la réplication peut alors ralentir en raison d'une utilisation élevée des ressources d'infrastructure. La capacité de l'infrastructure doit être suffisante pour gérer une réplication de données aussi complexe et de grande taille.

Comment les tables actives font partie de la réplication de manière transactionnelle

Lors de la réplication de tables hautement transactionnelles actives, la réplication peut être en retard de synchronisation en raison de problèmes de performances d'E/S, de blocages, etc., qui doivent être pris en compte. Cela peut ne pas rendre les environnements de base de données de production plus sains. Si le nombre de tables répliquées est élevé et que les données sont répliquées sur plusieurs sites, l'utilisation du processeur peut être élevée et un plus grand nombre de processeurs (ou de cœurs de processeur) est requis.

Capacité des infrastructures

Avant d'envisager la réplication logique comme solution, il est important de s'assurer que la capacité de l'infrastructure des serveurs de base de données est suffisante. Si un grand nombre de tables sont répliquées, il doit y avoir suffisamment de CPU disponibles pour effectuer la tâche de réplication.

Lors de la réplication d'un grand nombre de tables, envisagez de les diviser en groupes et de les répliquer en parallèle. Encore une fois, cela nécessitera que plusieurs processeurs soient disponibles pour la réplication. Si les changements de données dans les tables en cours de réplication sont fréquents et élevés, cela peut également avoir un impact sur les performances de réplication.

Optimisation des paramètres pour la réplication logique

Les paramètres configurés pour le fonctionnement de la réplication logique doivent être réglés de manière optimale pour garantir que la réplication ne s'interrompt pas.

Voyons d'abord les paramètres nécessaires à sa configuration :

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Régler max_wal_senders

max_wal_senders doit toujours être supérieur au nombre de répliques. Si les données sont répliquées sur plusieurs sites, plusieurs max_wal_senders entrent en jeu. Il est donc important de s'assurer que ce paramètre est défini sur un nombre optimal.

Régler max_replication_slots

En général, toutes les modifications de données se produisant sur les tables sont écrites dans des fichiers WAL dans pg_xlog / pg_wal qui sont appelés enregistrements WAL. Le processus d'envoi Wal récupèrerait ces enregistrements WAL (appartenant aux tables en cours de réplication) et les enverrait aux répliques et le processus wal_receiver sur le site de réplique appliquerait ces modifications au nœud abonné.

Les fichiers WAL sont supprimés de l'emplacement pg_xlog/pg_wal chaque fois qu'un point de contrôle se produit. Si les fichiers WAL sont supprimés avant même que les modifications ne soient appliquées au nœud de l'abonné, la réplication s'interromprait et prendrait du retard. En cas de retard du nœud d'abonné, un emplacement de réplication garantirait que tous les fichiers WAL nécessaires à la synchronisation de l'abonné avec le fournisseur sont conservés. Il est recommandé de configurer un emplacement de réplication pour chaque nœud d'abonné.

Régler max_worker_processes

Il est important d'avoir un nombre optimal de processeurs de travail configurés. Cela dépend du nombre maximum de processus qu'un serveur peut avoir. Ceci n'est possible que dans les environnements multi-CPU. Max_worker_processes garantira que plusieurs processus sont générés pour faire le travail plus rapidement en utilisant plusieurs cœurs de processeur. Lors de la réplication de données à l'aide de la réplication logique, ce paramètre peut aider à générer plusieurs processus de travail pour répliquer les données plus rapidement. Il existe un paramètre spécifique appelé max_logical_worker_processes qui garantira que plusieurs processus sont utilisés pour copier les données.

Réglage max_logical_worker_processes

Ce paramètre spécifie le nombre maximal de processus de travail logiques requis pour effectuer la réplication et la synchronisation des données de table. Cette valeur est extraite de max_worker_processes qui doit être supérieure à cette valeur de paramètre. Ce paramètre est très utile lors de la réplication de données sur plusieurs sites dans des environnements multiprocesseurs. La valeur par défaut est 4. La valeur maximale dépend du nombre de processus de travail pris en charge par le système.

Réglage de max_sync_workers_per_subscription

Ce paramètre spécifie le nombre maximal de processus de synchronisation requis par abonnement. Le processus de synchronisation a lieu pendant la synchronisation initiale des données et pour s'assurer que cela se produit plus rapidement, ce paramètre peut être utilisé. Actuellement, un seul processus de synchronisation peut être configuré par table, ce qui signifie que plusieurs tables peuvent être initialement synchronisées en parallèle. La valeur par défaut est 2. Cette valeur est choisie à partir de la valeur max_logical_worker_processes.

Ce sont les paramètres qui doivent être réglés pour garantir que la réplication logique est efficace et plus rapide. Les autres paramètres qui affectent également la réplication logique sont les suivants.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Ces paramètres n'ont aucun effet sur le nœud fournisseur.

Conclusion

Les tables spécifiques à la réplication sont une exigence courante qui se pose dans les systèmes de bases de données volumineux et complexes. Cela peut être à des fins de reporting commercial ou d'entreposage de données. En tant que DBA, je pense que la réplication logique répond grandement à ces objectifs en raison de sa mise en œuvre facile avec moins de complexité. La configuration et le réglage de la réplication logique nécessitent une bonne quantité de planification, d'architecture et de tests. La quantité de données répliquées en temps réel doit être évaluée pour s'assurer qu'un système de réplication efficace et sans apparence est en place. Pour conclure, les bases de données s'exécutant dans PostgreSQL-10, la réplication logique est la voie à suivre et pour les bases de données s'exécutant dans les versions PostgreSQL <10, pglogical est l'option.