Ensuite, il faut créer les tables de façon identique sur les bases, pour cela on dump le schema de la ou des bases concernée depuis le primaire vers le secondaire :
### Ajout d'un schema à une base / utilisateur répliqué
Si l'on ajoute un schéma à une base répliqué, pour que la syncho des données de ce shcéma se fasse, il faut que l'utilisateur SQL dédié à la réplication est le droit **USAGE** sur ce schéma :
~~~
foo=# GRANT USAGE ON SCHEMA bar TO replication;
~~~
Sinon la copié initiale des données de ce schéma n'est pas copié dans la réplication, on auras des erreurs de ce type dans les logs sur le master :
~~~
2020-05-30 00:06:26.163 CEST [40846] replication@foo ERROR: permission denied for schema bar
2020-05-30 00:06:26.163 CEST [40846] replication@foo STATEMENT: COPY bar."21GEHAVL" TO STDOUT
~~~
Sur le réplica on aura des erreurs de ce type :
~~~
020-05-30 15:55:57.594 CEST [986] LOG: le processus de synchronisation des tables en réplication logique pour la souscription « mysub_sql3 », table « 21NOHAII » a démarré
2020-05-30 15:55:57.601 CEST [985] ERREUR: n'a pas pu lancer la copie initiale du contenu de la table « bar.21GEHVRH » : ERROR: permission denied for schema bar
Sur le serveur secondaire, on peut surveiller le bon fonctionnement de la réplication ainsi, mais cela indique seulement l'état sur le secondaire, il ne surveille pas la réplication par rapport au primaire :
Pour surveiller la réplication logique depuis le primaire on utilise le check_pgactivity :
<https://github.com/OPMDG/check_pgactivity>
On l'utilise avec le service *replication_slots* qui regarde le nombre de fichier WAL et le nombre de fichier dans pg_replslot pour chaque slot de réplication.
Si les fichiers WAL s'accumule ainsi que les fichiers dans pg_replslot/ c'est qu'il y a un problème de réplication, le check passe en critique est indique quel slot est impacté.
On positionne des valeurs de *warning* et *critique* comme ceci :