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 :
Pendant la copie des tables, on peux surveillé l'avancement de la copie avec la vue `pg_subscription_rel` la colonne `srsubstate` donne l'état d'avancement pour chaque table :
* i = initialisation
* d = copie des données en cours
* s = synchronisé
* r = prêt
Lorsque les tables sont toutes en status 'r' la copie des données des tables est terminées.
### 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 :
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 :
On va prendre par exemple le cas où l'on veut migrer un serveur primaire en Postgresql11 vers Postgresql13.
* Il faut vérifier que sur le primaire toutes les tables d'une base de données ont une clé primaire, on peut exécuter cette requête qui va lister les tables qui n'ont pas de clé primaire :
~~~
SELECT tbl.table_schema, tbl.table_name FROM information_schema.tables tbl WHERE table_type = 'BASE TABLE' AND table_schema NOT IN ('pg_catalog', 'information_schema') AND NOT EXISTS ( SELECT 1 FROM information_schema.key_column_usage kcu WHERE kcu.table_name = tbl.table_name AND kcu.table_schema = tbl.table_schema );
~~~
* On crée une nouvelle instance Postgresql en version 13, soit sur un serveur distant qui va être notre futur primaire, soit on crée une nouvelle instance en version 13 sur le primaire actuel, sur un port alternatif :
~~~
$ pg_createcluster 13 prim -p 5434
~~~
Si la nouvelle instance en PG13 est sur le même serveur on baisse les valeurs de shared_buffers, effective_cache_size et max_worker_processes pour ne pas saturer le serveur.
* Dans l'idéal il ne faut pas qu'il ait de changement sur la structure pendant les opérations jusqu'à la bascule.
* Faire un dump de la scructure (schema) et les rôles sur le primaire actuel et la réinjecter sur l'instance 5434 :
* Il faut faire une réplication logique pour chaque base (dump + injection schema + création de subscription) si l'instance Postgresql contient plusieurs base.
* Mettre à jours les paramètres shared_buffers et effective_cache_size etc... et faire écouter l'instance sur le port 5432 (si l'on a créé une instance sur le serveur primaire actuel)
* Copié le pg_hba.conf sur la nouvelle instance.
* Suppression de la souscription sur la nouvelle instance :
~~~
ma_base=# ALTER SUBSCRIPTION s_upgrade DISABLE;
ma_base=# ALTER SUBSCRIPTION s_upgrade SET (slot_name = NONE);