max_replication_slots
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal d’emplacements de réplication définis simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
2-262143 |
| Type de paramètre |
statique |
| Documentation |
max_replication_slots |
Notes spécifiques à Azure
La valeur par défaut du max_replication_slots paramètre est 10. Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4 max_replication_slots pour que la haute disponibilité fonctionne correctement.
Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_replication_slots sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_replication_slot. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
max_slot_wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille maximale du WAL qui peut être réservée par les emplacements de réplication. Les emplacements de réplication sont marqués comme ayant échoué et les segments libérés pour suppression ou recyclage, si cet espace est occupé par WAL sur le disque. |
| Type de données |
entier |
| Valeur par défaut |
-1 |
| Valeurs autorisées |
-1 |
| Type de paramètre |
lecture seule |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal de processus d’expéditeur WAL exécutés simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
5-100 |
| Type de paramètre |
statique |
| Documentation |
max_wal_senders |
Notes spécifiques à Azure
La valeur par défaut du paramètre de max_wal_senders serveur définie lorsque vous provisionnez l’instance du serveur flexible Azure Database pour PostgreSQL ne doit jamais être réduite ci-dessous 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez d’augmenter max_wal_senders à une valeur beaucoup plus élevée pour pouvoir faire face à la réplication logique d’un nombre important de tables, gardez les points importants suivants à l’esprit :
- La réplication logique d’un grand nombre de tables n’a pas nécessairement besoin d’un grand nombre d’expéditeurs WAL.
- La seule raison pour laquelle vous avez besoin d’un expéditeur WAL distinct par table ou d’un groupe de tables est que vous avez besoin d’abonnements distincts pour chacune de ces tables ou groupes de.
- Quel que soit le nombre d’expéditeurs WAL utilisés pour la réplication physique et logique, ils sont tous actifs à la fois, chaque fois qu’un back-end écrit quelque chose dans le journal d’écriture anticipée. Dans ce cas, les expéditeurs WAL affectés à la réplication logique se réveillent tous :
- Décoder tous les nouveaux enregistrements dans le WAL.
- Filtrer les enregistrements de journal qui ne les intéressent pas.
- Répliquez les données pertinentes pour chacune d’entre elles.
- Les processus d'envoi WAL sont comparables aux connexions en ce que, lorsqu'ils sont inactifs, il n’a pas d’importance combien il y en a. Cependant, s’ils sont actifs, ils vont juste concurrencer pour les mêmes ressources et les performances pourraient finir par être terriblement mauvais. Cela est particulièrement vrai pour les expéditeurs avec la réplication logique, car le décodage logique est plutôt coûteux pour le processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Pour la réplication physique, ce n'est pas si important, car les émetteurs WAL n'utilisent pas la CPU de manière intensive et ont tendance à être limités par la bande passante réseau en priorité.
- Par conséquent, en général, il est préférable de ne pas avoir beaucoup plus d’expéditeurs WAL que vCores.
- Il est recommandé d’ajouter de la place à quelques expéditeurs WAL supplémentaires pour prendre en charge une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent vous aider à l’illustrer mieux.
- Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
- Pour un serveur avec 16 vCores, haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous pouvez configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + emplacements physiques pour les réplicas en lecture (4) + emplacements logiques (5) + un supplément pour la croissance future, compte tenu des vCores disponibles (2) = 13.
- Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4
max_wal_senders pour que la haute disponibilité fonctionne correctement. Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_wal_senders sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_wal_senders. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
- Si vous pensez toujours que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, contactez-nous, décrivez votre scénario en détail et expliquez ce que vous considérez comme étant la valeur minimale acceptable dont vous avez besoin pour que votre scénario fonctionne correctement.
track_commit_timestamp
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Collecte le temps de validation des transactions. |
| Type de données |
boolean |
| Valeur par défaut |
off |
| Valeurs autorisées |
on,off |
| Type de paramètre |
statique |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille des fichiers WAL conservés pour les serveurs de secours. |
| Type de données |
entier |
| Valeur par défaut |
400 |
| Valeurs autorisées |
400 |
| Type de paramètre |
lecture seule |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la durée maximale d’attente pour la réplication WAL. |
| Type de données |
entier |
| Valeur par défaut |
60000 |
| Valeurs autorisées |
0-2147483647 |
| Type de paramètre |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal d’emplacements de réplication définis simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
2-262143 |
| Type de paramètre |
statique |
| Documentation |
max_replication_slots |
Notes spécifiques à Azure
La valeur par défaut du max_replication_slots paramètre est 10. Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4 max_replication_slots pour que la haute disponibilité fonctionne correctement.
Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_replication_slots sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_replication_slot. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
max_slot_wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille maximale du WAL qui peut être réservée par les emplacements de réplication. Les emplacements de réplication sont marqués comme ayant échoué et les segments libérés pour suppression ou recyclage, si cet espace est occupé par WAL sur le disque. |
| Type de données |
entier |
| Valeur par défaut |
-1 |
| Valeurs autorisées |
-1 |
| Type de paramètre |
lecture seule |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal de processus d’expéditeur WAL exécutés simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
5-100 |
| Type de paramètre |
statique |
| Documentation |
max_wal_senders |
Notes spécifiques à Azure
La valeur par défaut du paramètre de max_wal_senders serveur définie lorsque vous provisionnez l’instance du serveur flexible Azure Database pour PostgreSQL ne doit jamais être réduite ci-dessous 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez d’augmenter max_wal_senders à une valeur beaucoup plus élevée pour pouvoir faire face à la réplication logique d’un nombre important de tables, gardez les points importants suivants à l’esprit :
- La réplication logique d’un grand nombre de tables n’a pas nécessairement besoin d’un grand nombre d’expéditeurs WAL.
- La seule raison pour laquelle vous avez besoin d’un expéditeur WAL distinct par table ou d’un groupe de tables est que vous avez besoin d’abonnements distincts pour chacune de ces tables ou groupes de.
- Quel que soit le nombre d’expéditeurs WAL utilisés pour la réplication physique et logique, ils sont tous actifs à la fois, chaque fois qu’un back-end écrit quelque chose dans le journal d’écriture anticipée. Dans ce cas, les expéditeurs WAL affectés à la réplication logique se réveillent tous :
- Décoder tous les nouveaux enregistrements dans le WAL.
- Filtrer les enregistrements de journal qui ne les intéressent pas.
- Répliquez les données pertinentes pour chacune d’entre elles.
- Les processus d'envoi WAL sont comparables aux connexions en ce que, lorsqu'ils sont inactifs, il n’a pas d’importance combien il y en a. Cependant, s’ils sont actifs, ils vont juste concurrencer pour les mêmes ressources et les performances pourraient finir par être terriblement mauvais. Cela est particulièrement vrai pour les expéditeurs avec la réplication logique, car le décodage logique est plutôt coûteux pour le processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Pour la réplication physique, ce n'est pas si important, car les émetteurs WAL n'utilisent pas la CPU de manière intensive et ont tendance à être limités par la bande passante réseau en priorité.
- Par conséquent, en général, il est préférable de ne pas avoir beaucoup plus d’expéditeurs WAL que vCores.
- Il est recommandé d’ajouter de la place à quelques expéditeurs WAL supplémentaires pour prendre en charge une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent vous aider à l’illustrer mieux.
- Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
- Pour un serveur avec 16 vCores, haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous pouvez configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + emplacements physiques pour les réplicas en lecture (4) + emplacements logiques (5) + un supplément pour la croissance future, compte tenu des vCores disponibles (2) = 13.
- Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4
max_wal_senders pour que la haute disponibilité fonctionne correctement. Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_wal_senders sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_wal_senders. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
- Si vous pensez toujours que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, contactez-nous, décrivez votre scénario en détail et expliquez ce que vous considérez comme étant la valeur minimale acceptable dont vous avez besoin pour que votre scénario fonctionne correctement.
track_commit_timestamp
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Collecte le temps de validation des transactions. |
| Type de données |
boolean |
| Valeur par défaut |
off |
| Valeurs autorisées |
on,off |
| Type de paramètre |
statique |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille des fichiers WAL conservés pour les serveurs de secours. |
| Type de données |
entier |
| Valeur par défaut |
400 |
| Valeurs autorisées |
400 |
| Type de paramètre |
lecture seule |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la durée maximale d’attente pour la réplication WAL. |
| Type de données |
entier |
| Valeur par défaut |
60000 |
| Valeurs autorisées |
0-2147483647 |
| Type de paramètre |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Spécifie le nombre maximal d’emplacements de réplication que le serveur peut prendre en charge. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
2-262143 |
| Type de paramètre |
statique |
| Documentation |
max_replication_slots |
Notes spécifiques à Azure
La valeur par défaut du max_replication_slots paramètre est 10. Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4 max_replication_slots pour que la haute disponibilité fonctionne correctement.
Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_replication_slots sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_replication_slot. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
max_slot_wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille maximale du WAL qui peut être réservée par les emplacements de réplication. |
| Type de données |
entier |
| Valeur par défaut |
-1 |
| Valeurs autorisées |
-1 |
| Type de paramètre |
lecture seule |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal de processus d’expéditeur WAL exécutés simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
5-100 |
| Type de paramètre |
statique |
| Documentation |
max_wal_senders |
Notes spécifiques à Azure
La valeur par défaut du paramètre de max_wal_senders serveur définie lorsque vous provisionnez l’instance du serveur flexible Azure Database pour PostgreSQL ne doit jamais être réduite ci-dessous 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez d’augmenter max_wal_senders à une valeur beaucoup plus élevée pour pouvoir faire face à la réplication logique d’un nombre important de tables, gardez les points importants suivants à l’esprit :
- La réplication logique d’un grand nombre de tables n’a pas nécessairement besoin d’un grand nombre d’expéditeurs WAL.
- La seule raison pour laquelle vous avez besoin d’un expéditeur WAL distinct par table ou d’un groupe de tables est que vous avez besoin d’abonnements distincts pour chacune de ces tables ou groupes de.
- Quel que soit le nombre d’expéditeurs WAL utilisés pour la réplication physique et logique, ils sont tous actifs à la fois, chaque fois qu’un back-end écrit quelque chose dans le journal d’écriture anticipée. Dans ce cas, les expéditeurs WAL affectés à la réplication logique se réveillent tous :
- Décoder tous les nouveaux enregistrements dans le WAL.
- Filtrer les enregistrements de journal qui ne les intéressent pas.
- Répliquez les données pertinentes pour chacune d’entre elles.
- Les processus d'envoi WAL sont comparables aux connexions en ce que, lorsqu'ils sont inactifs, il n’a pas d’importance combien il y en a. Cependant, s’ils sont actifs, ils vont juste concurrencer pour les mêmes ressources et les performances pourraient finir par être terriblement mauvais. Cela est particulièrement vrai pour les expéditeurs avec la réplication logique, car le décodage logique est plutôt coûteux pour le processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Pour la réplication physique, ce n'est pas si important, car les émetteurs WAL n'utilisent pas la CPU de manière intensive et ont tendance à être limités par la bande passante réseau en priorité.
- Par conséquent, en général, il est préférable de ne pas avoir beaucoup plus d’expéditeurs WAL que vCores.
- Il est recommandé d’ajouter de la place à quelques expéditeurs WAL supplémentaires pour prendre en charge une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent vous aider à l’illustrer mieux.
- Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
- Pour un serveur avec 16 vCores, haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous pouvez configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + emplacements physiques pour les réplicas en lecture (4) + emplacements logiques (5) + un supplément pour la croissance future, compte tenu des vCores disponibles (2) = 13.
- Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4
max_wal_senders pour que la haute disponibilité fonctionne correctement. Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_wal_senders sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_wal_senders. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
- Si vous pensez toujours que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, contactez-nous, décrivez votre scénario en détail et expliquez ce que vous considérez comme étant la valeur minimale acceptable dont vous avez besoin pour que votre scénario fonctionne correctement.
track_commit_timestamp
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Collecte le temps de validation des transactions. |
| Type de données |
boolean |
| Valeur par défaut |
off |
| Valeurs autorisées |
on,off |
| Type de paramètre |
statique |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille des fichiers WAL conservés pour les serveurs de secours. |
| Type de données |
entier |
| Valeur par défaut |
400 |
| Valeurs autorisées |
400 |
| Type de paramètre |
lecture seule |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la durée maximale d’attente pour la réplication WAL. |
| Type de données |
entier |
| Valeur par défaut |
60000 |
| Valeurs autorisées |
0-2147483647 |
| Type de paramètre |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Spécifie le nombre maximal d’emplacements de réplication que le serveur peut prendre en charge. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
2-262143 |
| Type de paramètre |
statique |
| Documentation |
max_replication_slots |
Notes spécifiques à Azure
La valeur par défaut du max_replication_slots paramètre est 10. Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4 max_replication_slots pour que la haute disponibilité fonctionne correctement.
Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_replication_slots sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_replication_slot. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
max_slot_wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille maximale du WAL qui peut être réservée par les emplacements de réplication. |
| Type de données |
entier |
| Valeur par défaut |
-1 |
| Valeurs autorisées |
-1 |
| Type de paramètre |
lecture seule |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal de processus d’expéditeur WAL exécutés simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
5-100 |
| Type de paramètre |
statique |
| Documentation |
max_wal_senders |
Notes spécifiques à Azure
La valeur par défaut du paramètre de max_wal_senders serveur définie lorsque vous provisionnez l’instance du serveur flexible Azure Database pour PostgreSQL ne doit jamais être réduite ci-dessous 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez d’augmenter max_wal_senders à une valeur beaucoup plus élevée pour pouvoir faire face à la réplication logique d’un nombre important de tables, gardez les points importants suivants à l’esprit :
- La réplication logique d’un grand nombre de tables n’a pas nécessairement besoin d’un grand nombre d’expéditeurs WAL.
- La seule raison pour laquelle vous avez besoin d’un expéditeur WAL distinct par table ou d’un groupe de tables est que vous avez besoin d’abonnements distincts pour chacune de ces tables ou groupes de.
- Quel que soit le nombre d’expéditeurs WAL utilisés pour la réplication physique et logique, ils sont tous actifs à la fois, chaque fois qu’un back-end écrit quelque chose dans le journal d’écriture anticipée. Dans ce cas, les expéditeurs WAL affectés à la réplication logique se réveillent tous :
- Décoder tous les nouveaux enregistrements dans le WAL.
- Filtrer les enregistrements de journal qui ne les intéressent pas.
- Répliquez les données pertinentes pour chacune d’entre elles.
- Les processus d'envoi WAL sont comparables aux connexions en ce que, lorsqu'ils sont inactifs, il n’a pas d’importance combien il y en a. Cependant, s’ils sont actifs, ils vont juste concurrencer pour les mêmes ressources et les performances pourraient finir par être terriblement mauvais. Cela est particulièrement vrai pour les expéditeurs avec la réplication logique, car le décodage logique est plutôt coûteux pour le processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Pour la réplication physique, ce n'est pas si important, car les émetteurs WAL n'utilisent pas la CPU de manière intensive et ont tendance à être limités par la bande passante réseau en priorité.
- Par conséquent, en général, il est préférable de ne pas avoir beaucoup plus d’expéditeurs WAL que vCores.
- Il est recommandé d’ajouter de la place à quelques expéditeurs WAL supplémentaires pour prendre en charge une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent vous aider à l’illustrer mieux.
- Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
- Pour un serveur avec 16 vCores, haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous pouvez configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + emplacements physiques pour les réplicas en lecture (4) + emplacements logiques (5) + un supplément pour la croissance future, compte tenu des vCores disponibles (2) = 13.
- Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4
max_wal_senders pour que la haute disponibilité fonctionne correctement. Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_wal_senders sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_wal_senders. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
- Si vous pensez toujours que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, contactez-nous, décrivez votre scénario en détail et expliquez ce que vous considérez comme étant la valeur minimale acceptable dont vous avez besoin pour que votre scénario fonctionne correctement.
track_commit_timestamp
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Collecte le temps de validation des transactions. |
| Type de données |
boolean |
| Valeur par défaut |
off |
| Valeurs autorisées |
on,off |
| Type de paramètre |
statique |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille des fichiers WAL conservés pour les serveurs de secours. |
| Type de données |
entier |
| Valeur par défaut |
400 |
| Valeurs autorisées |
400 |
| Type de paramètre |
lecture seule |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la durée maximale d’attente pour la réplication WAL. |
| Type de données |
entier |
| Valeur par défaut |
60000 |
| Valeurs autorisées |
0-2147483647 |
| Type de paramètre |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Spécifie le nombre maximal d’emplacements de réplication que le serveur peut prendre en charge. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
2-262143 |
| Type de paramètre |
statique |
| Documentation |
max_replication_slots |
Notes spécifiques à Azure
La valeur par défaut du max_replication_slots paramètre est 10. Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4 max_replication_slots pour que la haute disponibilité fonctionne correctement.
Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_replication_slots sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_replication_slot. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
max_slot_wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille maximale du WAL qui peut être réservée par les emplacements de réplication. |
| Type de données |
entier |
| Valeur par défaut |
-1 |
| Valeurs autorisées |
-1 |
| Type de paramètre |
lecture seule |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal de processus d’expéditeur WAL exécutés simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
5-100 |
| Type de paramètre |
statique |
| Documentation |
max_wal_senders |
Notes spécifiques à Azure
La valeur par défaut du paramètre de max_wal_senders serveur définie lorsque vous provisionnez l’instance du serveur flexible Azure Database pour PostgreSQL ne doit jamais être réduite ci-dessous 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez d’augmenter max_wal_senders à une valeur beaucoup plus élevée pour pouvoir faire face à la réplication logique d’un nombre important de tables, gardez les points importants suivants à l’esprit :
- La réplication logique d’un grand nombre de tables n’a pas nécessairement besoin d’un grand nombre d’expéditeurs WAL.
- La seule raison pour laquelle vous avez besoin d’un expéditeur WAL distinct par table ou d’un groupe de tables est que vous avez besoin d’abonnements distincts pour chacune de ces tables ou groupes de.
- Quel que soit le nombre d’expéditeurs WAL utilisés pour la réplication physique et logique, ils sont tous actifs à la fois, chaque fois qu’un back-end écrit quelque chose dans le journal d’écriture anticipée. Dans ce cas, les expéditeurs WAL affectés à la réplication logique se réveillent tous :
- Décoder tous les nouveaux enregistrements dans le WAL.
- Filtrer les enregistrements de journal qui ne les intéressent pas.
- Répliquez les données pertinentes pour chacune d’entre elles.
- Les processus d'envoi WAL sont comparables aux connexions en ce que, lorsqu'ils sont inactifs, il n’a pas d’importance combien il y en a. Cependant, s’ils sont actifs, ils vont juste concurrencer pour les mêmes ressources et les performances pourraient finir par être terriblement mauvais. Cela est particulièrement vrai pour les expéditeurs avec la réplication logique, car le décodage logique est plutôt coûteux pour le processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Pour la réplication physique, ce n'est pas si important, car les émetteurs WAL n'utilisent pas la CPU de manière intensive et ont tendance à être limités par la bande passante réseau en priorité.
- Par conséquent, en général, il est préférable de ne pas avoir beaucoup plus d’expéditeurs WAL que vCores.
- Il est recommandé d’ajouter de la place à quelques expéditeurs WAL supplémentaires pour prendre en charge une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent vous aider à l’illustrer mieux.
- Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
- Pour un serveur avec 16 vCores, haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous pouvez configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + emplacements physiques pour les réplicas en lecture (4) + emplacements logiques (5) + un supplément pour la croissance future, compte tenu des vCores disponibles (2) = 13.
- Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4
max_wal_senders pour que la haute disponibilité fonctionne correctement. Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_wal_senders sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_wal_senders. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
- Si vous pensez toujours que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, contactez-nous, décrivez votre scénario en détail et expliquez ce que vous considérez comme étant la valeur minimale acceptable dont vous avez besoin pour que votre scénario fonctionne correctement.
track_commit_timestamp
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Collecte le temps de validation des transactions. |
| Type de données |
boolean |
| Valeur par défaut |
off |
| Valeurs autorisées |
on,off |
| Type de paramètre |
statique |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille des fichiers WAL conservés pour les serveurs de secours. |
| Type de données |
entier |
| Valeur par défaut |
400 |
| Valeurs autorisées |
400 |
| Type de paramètre |
lecture seule |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la durée maximale d’attente pour la réplication WAL. |
| Type de données |
entier |
| Valeur par défaut |
60000 |
| Valeurs autorisées |
0-2147483647 |
| Type de paramètre |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Spécifie le nombre maximal d’emplacements de réplication que le serveur peut prendre en charge. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
2-262143 |
| Type de paramètre |
statique |
| Documentation |
max_replication_slots |
Notes spécifiques à Azure
La valeur par défaut du max_replication_slots paramètre est 10. Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4 max_replication_slots pour que la haute disponibilité fonctionne correctement.
Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_replication_slots sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_replication_slot. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
max_slot_wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille maximale du WAL qui peut être réservée par les emplacements de réplication. |
| Type de données |
entier |
| Valeur par défaut |
-1 |
| Valeurs autorisées |
-1 |
| Type de paramètre |
lecture seule |
| Documentation |
max_slot_wal_keep_size |
max_wal_senders
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal de processus d’expéditeur WAL exécutés simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
5-100 |
| Type de paramètre |
statique |
| Documentation |
max_wal_senders |
Notes spécifiques à Azure
La valeur par défaut du paramètre de max_wal_senders serveur définie lorsque vous provisionnez l’instance du serveur flexible Azure Database pour PostgreSQL ne doit jamais être réduite ci-dessous 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez d’augmenter max_wal_senders à une valeur beaucoup plus élevée pour pouvoir faire face à la réplication logique d’un nombre important de tables, gardez les points importants suivants à l’esprit :
- La réplication logique d’un grand nombre de tables n’a pas nécessairement besoin d’un grand nombre d’expéditeurs WAL.
- La seule raison pour laquelle vous avez besoin d’un expéditeur WAL distinct par table ou d’un groupe de tables est que vous avez besoin d’abonnements distincts pour chacune de ces tables ou groupes de.
- Quel que soit le nombre d’expéditeurs WAL utilisés pour la réplication physique et logique, ils sont tous actifs à la fois, chaque fois qu’un back-end écrit quelque chose dans le journal d’écriture anticipée. Dans ce cas, les expéditeurs WAL affectés à la réplication logique se réveillent tous :
- Décoder tous les nouveaux enregistrements dans le WAL.
- Filtrer les enregistrements de journal qui ne les intéressent pas.
- Répliquez les données pertinentes pour chacune d’entre elles.
- Les processus d'envoi WAL sont comparables aux connexions en ce que, lorsqu'ils sont inactifs, il n’a pas d’importance combien il y en a. Cependant, s’ils sont actifs, ils vont juste concurrencer pour les mêmes ressources et les performances pourraient finir par être terriblement mauvais. Cela est particulièrement vrai pour les expéditeurs avec la réplication logique, car le décodage logique est plutôt coûteux pour le processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Pour la réplication physique, ce n'est pas si important, car les émetteurs WAL n'utilisent pas la CPU de manière intensive et ont tendance à être limités par la bande passante réseau en priorité.
- Par conséquent, en général, il est préférable de ne pas avoir beaucoup plus d’expéditeurs WAL que vCores.
- Il est recommandé d’ajouter de la place à quelques expéditeurs WAL supplémentaires pour prendre en charge une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent vous aider à l’illustrer mieux.
- Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
- Pour un serveur avec 16 vCores, haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous pouvez configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + emplacements physiques pour les réplicas en lecture (4) + emplacements logiques (5) + un supplément pour la croissance future, compte tenu des vCores disponibles (2) = 13.
- Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4
max_wal_senders pour que la haute disponibilité fonctionne correctement. Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_wal_senders sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_wal_senders. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
- Si vous pensez toujours que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, contactez-nous, décrivez votre scénario en détail et expliquez ce que vous considérez comme étant la valeur minimale acceptable dont vous avez besoin pour que votre scénario fonctionne correctement.
track_commit_timestamp
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Collecte le temps de validation des transactions. |
| Type de données |
boolean |
| Valeur par défaut |
off |
| Valeurs autorisées |
on,off |
| Type de paramètre |
statique |
| Documentation |
track_commit_timestamp |
wal_keep_size
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la taille des fichiers WAL conservés pour les serveurs de secours. |
| Type de données |
entier |
| Valeur par défaut |
400 |
| Valeurs autorisées |
400 |
| Type de paramètre |
lecture seule |
| Documentation |
wal_keep_size |
wal_sender_timeout
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la durée maximale d’attente pour la réplication WAL. |
| Type de données |
entier |
| Valeur par défaut |
60000 |
| Valeurs autorisées |
0-2147483647 |
| Type de paramètre |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Spécifie le nombre maximal d’emplacements de réplication que le serveur peut prendre en charge. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
2-262143 |
| Type de paramètre |
statique |
| Documentation |
max_replication_slots |
Notes spécifiques à Azure
La valeur par défaut du max_replication_slots paramètre est 10. Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4 max_replication_slots pour que la haute disponibilité fonctionne correctement.
Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_replication_slots sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_replication_slot. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
max_wal_senders
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal de processus d’expéditeur WAL exécutés simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
5-100 |
| Type de paramètre |
statique |
| Documentation |
max_wal_senders |
Notes spécifiques à Azure
La valeur par défaut du paramètre de max_wal_senders serveur définie lorsque vous provisionnez l’instance du serveur flexible Azure Database pour PostgreSQL ne doit jamais être réduite ci-dessous 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez d’augmenter max_wal_senders à une valeur beaucoup plus élevée pour pouvoir faire face à la réplication logique d’un nombre important de tables, gardez les points importants suivants à l’esprit :
- La réplication logique d’un grand nombre de tables n’a pas nécessairement besoin d’un grand nombre d’expéditeurs WAL.
- La seule raison pour laquelle vous avez besoin d’un expéditeur WAL distinct par table ou d’un groupe de tables est que vous avez besoin d’abonnements distincts pour chacune de ces tables ou groupes de.
- Quel que soit le nombre d’expéditeurs WAL utilisés pour la réplication physique et logique, ils sont tous actifs à la fois, chaque fois qu’un back-end écrit quelque chose dans le journal d’écriture anticipée. Dans ce cas, les expéditeurs WAL affectés à la réplication logique se réveillent tous :
- Décoder tous les nouveaux enregistrements dans le WAL.
- Filtrer les enregistrements de journal qui ne les intéressent pas.
- Répliquez les données pertinentes pour chacune d’entre elles.
- Les processus d'envoi WAL sont comparables aux connexions en ce que, lorsqu'ils sont inactifs, il n’a pas d’importance combien il y en a. Cependant, s’ils sont actifs, ils vont juste concurrencer pour les mêmes ressources et les performances pourraient finir par être terriblement mauvais. Cela est particulièrement vrai pour les expéditeurs avec la réplication logique, car le décodage logique est plutôt coûteux pour le processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Pour la réplication physique, ce n'est pas si important, car les émetteurs WAL n'utilisent pas la CPU de manière intensive et ont tendance à être limités par la bande passante réseau en priorité.
- Par conséquent, en général, il est préférable de ne pas avoir beaucoup plus d’expéditeurs WAL que vCores.
- Il est recommandé d’ajouter de la place à quelques expéditeurs WAL supplémentaires pour prendre en charge une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent vous aider à l’illustrer mieux.
- Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
- Pour un serveur avec 16 vCores, haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous pouvez configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + emplacements physiques pour les réplicas en lecture (4) + emplacements logiques (5) + un supplément pour la croissance future, compte tenu des vCores disponibles (2) = 13.
- Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4
max_wal_senders pour que la haute disponibilité fonctionne correctement. Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_wal_senders sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_wal_senders. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
- Si vous pensez toujours que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, contactez-nous, décrivez votre scénario en détail et expliquez ce que vous considérez comme étant la valeur minimale acceptable dont vous avez besoin pour que votre scénario fonctionne correctement.
track_commit_timestamp
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Collecte le temps de validation des transactions. |
| Type de données |
boolean |
| Valeur par défaut |
off |
| Valeurs autorisées |
on,off |
| Type de paramètre |
statique |
| Documentation |
track_commit_timestamp |
segments WAL à conserver (wal_keep_segments)
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre de fichiers WAL conservés pour les serveurs de secours. |
| Type de données |
entier |
| Valeur par défaut |
25 |
| Valeurs autorisées |
25 |
| Type de paramètre |
lecture seule |
| Documentation |
|
wal_sender_timeout
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la durée maximale d’attente pour la réplication WAL. |
| Type de données |
entier |
| Valeur par défaut |
60000 |
| Valeurs autorisées |
0-2147483647 |
| Type de paramètre |
dynamic |
| Documentation |
wal_sender_timeout |
max_replication_slots
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Spécifie le nombre maximal d’emplacements de réplication que le serveur peut prendre en charge. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
2-262143 |
| Type de paramètre |
statique |
| Documentation |
max_replication_slots |
Notes spécifiques à Azure
La valeur par défaut du max_replication_slots paramètre est 10. Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4 max_replication_slots pour que la haute disponibilité fonctionne correctement.
Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_replication_slots sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_replication_slot. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
max_wal_senders
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre maximal de processus d’expéditeur WAL exécutés simultanément. |
| Type de données |
entier |
| Valeur par défaut |
10 |
| Valeurs autorisées |
5-100 |
| Type de paramètre |
statique |
| Documentation |
max_wal_senders |
Notes spécifiques à Azure
La valeur par défaut du paramètre de max_wal_senders serveur définie lorsque vous provisionnez l’instance du serveur flexible Azure Database pour PostgreSQL ne doit jamais être réduite ci-dessous 2 (if HA is enabled) + number of read replicas provisioned + slots_used_in_logical_replication.
Lorsque vous envisagez d’augmenter max_wal_senders à une valeur beaucoup plus élevée pour pouvoir faire face à la réplication logique d’un nombre important de tables, gardez les points importants suivants à l’esprit :
- La réplication logique d’un grand nombre de tables n’a pas nécessairement besoin d’un grand nombre d’expéditeurs WAL.
- La seule raison pour laquelle vous avez besoin d’un expéditeur WAL distinct par table ou d’un groupe de tables est que vous avez besoin d’abonnements distincts pour chacune de ces tables ou groupes de.
- Quel que soit le nombre d’expéditeurs WAL utilisés pour la réplication physique et logique, ils sont tous actifs à la fois, chaque fois qu’un back-end écrit quelque chose dans le journal d’écriture anticipée. Dans ce cas, les expéditeurs WAL affectés à la réplication logique se réveillent tous :
- Décoder tous les nouveaux enregistrements dans le WAL.
- Filtrer les enregistrements de journal qui ne les intéressent pas.
- Répliquez les données pertinentes pour chacune d’entre elles.
- Les processus d'envoi WAL sont comparables aux connexions en ce que, lorsqu'ils sont inactifs, il n’a pas d’importance combien il y en a. Cependant, s’ils sont actifs, ils vont juste concurrencer pour les mêmes ressources et les performances pourraient finir par être terriblement mauvais. Cela est particulièrement vrai pour les expéditeurs avec la réplication logique, car le décodage logique est plutôt coûteux pour le processeur. Chaque Worker doit décoder le journal WAL entier, même s’il ne réplique que les opérations affectant une seule table, lesquelles ne représentant qu’un petit pourcentage de toutes les données dans le journal write-ahead log. Pour la réplication physique, ce n'est pas si important, car les émetteurs WAL n'utilisent pas la CPU de manière intensive et ont tendance à être limités par la bande passante réseau en priorité.
- Par conséquent, en général, il est préférable de ne pas avoir beaucoup plus d’expéditeurs WAL que vCores.
- Il est recommandé d’ajouter de la place à quelques expéditeurs WAL supplémentaires pour prendre en charge une croissance future ou des pics temporaires dans les connexions de réplication. Les deux exemples suivants peuvent vous aider à l’illustrer mieux.
- Pour un serveur avec 8 cœurs virtuels, une haute disponibilité désactivée, 2 réplicas en lecture et 3 emplacements de réplication logique, vous souhaitez peut-être configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (0) + des compartiments physiques pour les réplicas en lecture (2) + des emplacements logiques (3) + quelques-uns de plus pour une croissance future, en considérant les cœurs virtuels disponibles (1) = 6.
- Pour un serveur avec 16 vCores, haute disponibilité activée, 4 réplicas en lecture et 5 emplacements de réplication logique, vous pouvez configurer
max_wal_senders comme somme des emplacements physiques pour la haute disponibilité (2) + emplacements physiques pour les réplicas en lecture (4) + emplacements logiques (5) + un supplément pour la croissance future, compte tenu des vCores disponibles (2) = 13.
- Si vous activez la haute disponibilité, vous avez besoin d’un minimum de 4
max_wal_senders pour que la haute disponibilité fonctionne correctement. Pour un serveur avec une haute disponibilité activée, plus 5 réplicas de lecture et 12 emplacements de réplication logique, vous pouvez configurer max_wal_senders sur 21. En effet, chaque réplique en lecture et chaque emplacement de réplication logique nécessite un max_wal_senders. Il en faut donc au total 1 (emplacement) * 5 (répliques en lecture) + 12 (emplacements de réplication logique) + 4 (pour que la haute disponibilité fonctionne correctement) = 21.
- Si vous pensez toujours que la valeur maximale autorisée pour ce paramètre est trop faible pour vos besoins, contactez-nous, décrivez votre scénario en détail et expliquez ce que vous considérez comme étant la valeur minimale acceptable dont vous avez besoin pour que votre scénario fonctionne correctement.
track_commit_timestamp
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Collecte le temps de validation des transactions. |
| Type de données |
boolean |
| Valeur par défaut |
off |
| Valeurs autorisées |
on,off |
| Type de paramètre |
statique |
| Documentation |
track_commit_timestamp |
segments WAL à conserver (wal_keep_segments)
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit le nombre de fichiers WAL conservés pour les serveurs de secours. |
| Type de données |
entier |
| Valeur par défaut |
25 |
| Valeurs autorisées |
25 |
| Type de paramètre |
lecture seule |
| Documentation |
|
wal_sender_timeout
| Caractéristique |
Valeur |
| Catégorie |
Réplication / Envoi de serveurs |
| Descriptif |
Définit la durée maximale d’attente pour la réplication WAL. |
| Type de données |
entier |
| Valeur par défaut |
60000 |
| Valeurs autorisées |
0-2147483647 |
| Type de paramètre |
dynamic |
| Documentation |
wal_sender_timeout |