relecture
This commit is contained in:
Gregory Colpart
parent
cbdb82d923
commit
15b3b94f63
|
|
@ -941,13 +941,14 @@ Plusieurs solutions de réplication plus ou moins avancées existent avec Postgr
|
|||
* _Warm Standby_ : les _WAL_ sont copiés sous forme d'archive sur un second serveur sur lequel tourne un PostgreSQL en mode _recovery_ constant. Chaque segment reçu est rejoué par PostgreSQL. Il est alors prêt à prendre le relais en cas de panne sur le serveur maître.
|
||||
* _Hot Standby_ : le principe est le même que pour le _Warm Standby_, mais le réplica peut être interrogé en lecture. Il y a néanmois une légère différence perpétuelle entre le master et le réplica car le *WAL* est transféré seulement lorsque l'archive a fini d'être écrite.
|
||||
* _Streaming Replication_ : les données sont transférées immédiatement par un processus dédié (_walsender_) dans une connexion réseau établie avec le réplica. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par réplica sur le maître pour faire tourner le processus _walsender_. En général ce système est couplé à l'envoi des *WAL* car si le réplica est trop en retard par rapport au master, il va lire les *WAL* jusqu'à avoir rattrapé son retard puis basculera tout seul sur la *streaming replication*
|
||||
* _Slony_ : système de réplication basé sur l'ajout de triggers sur chaque table à répliquer. Cela nécessite une gestion assez complexe mais c'était la seule façon d'avoir une réplication immédiate avant l'arrivée de la _Streaming Replication_. Cela reste la seule solution pour avoir une réplication au niveau des tables et non de la base entière (par exemple si vous voulez répliquer une table d'un serveur A vers un serveur B, et répliquer une autre table du serveur B vers A).
|
||||
|
||||
Pour plus de détails sur ces solutions, voir ce post sur [dba.stackexange.com](https://dba.stackexchange.com/questions/73812/postgresql-streaming-versus-file-based-replication-in-terms-of-server-behavior). Pour d'autres types de solutions pour avoir de la haute disoponibilite, PostgreSQL a [une page sur cela dans leur documentation](https://www.postgresql.org/docs/current/static/different-replication-solutions.html).
|
||||
|
||||
> *Note* : l'expédition des logs entre des serveurs pgsql nécessite qu'ils soient à la même version majeure.
|
||||
|
||||
|
||||
### Réplication native (streaming)
|
||||
### Streaming Replication
|
||||
|
||||
Voir [/HowtoPostgreSQL/Replication]().
|
||||
|
||||
|
|
|
|||
|
|
@ -367,7 +367,7 @@ $ slonik_drop_node node2 | slonik
|
|||
$ slonik_uninstall_nodes set1 node1 | slonik
|
||||
~~~
|
||||
|
||||
#### purger les tables de réplication _sl_log_1_ et _sl_log_2_
|
||||
#### purger les tables de réplication `sl_log_1` et `sl_log_2`
|
||||
|
||||
La purge des tables de réplication est un peu floue. Si l'on a besoin de purger les lignes
|
||||
inutiles des tables, on peut faire cela :
|
||||
|
|
@ -397,7 +397,7 @@ DELETE 7020095
|
|||
|
||||
À faire sur tout les nodes indépendamment.
|
||||
|
||||
#### purger complètement les tables de réplication _sl_log_1_ et _sl_log_2_
|
||||
#### purger complètement les tables de réplication `sl_log_1` et `sl_log_2`
|
||||
|
||||
Cela ne doit être fait que dans des cas particuliers :
|
||||
|
||||
|
|
@ -466,7 +466,7 @@ La nouvelle machine se voit attribuer le numéro « node3 » et est abonnée a
|
|||
|
||||
#### set mal supprimé
|
||||
|
||||
Si un set est toujours présent dans la table sl_set :
|
||||
Si un set est toujours présent dans la table `sl_set` :
|
||||
|
||||
~~~
|
||||
=# select * from _replication.sl_set;
|
||||
|
|
@ -489,19 +489,19 @@ Il faut alors le supprimer à la main :
|
|||
=# delete from _replication.sl_set where set_id=2;
|
||||
~~~
|
||||
|
||||
### Fonctionnement des tables sl_log_{1,2}
|
||||
### Fonctionnement des tables `sl_log_{1,2}`
|
||||
|
||||
1. Opération d'écriture sur le nœud maître -> les données modifiées vont être insérées dans la table _sl_log_1_, grace au trigger __replication_logtrigger_ positionné sur la table ayant subie les modifications.
|
||||
2. Sur le nœud esclave, le démon _slon_ lit à intervalles réguliers la table de log active, ici _sl_log_1_. Il va alors récupérer les nouvelles entrées pour les copier dans sa propre table de log. À noter qu'avant de se connecter à la base PostgreSQL sur le nœud maître, il « pingue » le démon slon sur le master, et si il ne répond pas, ne fait rien. Par conséquent, si un des deux démon _slon_ ne tourne pas, la réplication ne se fait pas.
|
||||
1. Opération d'écriture sur le nœud maître -> les données modifiées vont être insérées dans la table `sl_log_1`, grace au trigger *replication_logtrigger* positionné sur la table ayant subie les modifications.
|
||||
2. Sur le nœud esclave, le démon _slon_ lit à intervalles réguliers la table de log active, ici `sl_log_1`. Il va alors récupérer les nouvelles entrées pour les copier dans sa propre table de log. À noter qu'avant de se connecter à la base PostgreSQL sur le nœud maître, il « pingue » le démon slon sur le master, et si il ne répond pas, ne fait rien. Par conséquent, si un des deux démon _slon_ ne tourne pas, la réplication ne se fait pas.
|
||||
3. Les nouvelles modifications sont alors rejouer sur le slave.
|
||||
|
||||
Par défaut (option _cleanup_deletelogs=false_), les entrées dans les tables de logs ne sont pas supprimées, étant donné qu'un _DELETE_ à chaque fois peut être assez coûteux en terme de ressources pour la base de données. Un basculement de tables est alors opéré (par défaut toutes les 10 minutes, modifiable par l'option _cleanup_interval_), de _sl_log_1_ vers _sl_log_2_ ou inversement, ce qui permet de repartir sur une table vide. Un _TRUNCATE_ est alors exécuté sur l'ancienne table de log pour la nettoyer. Tous les 3 cycles de basculement, un _VACUUM_ est exécuté sur la table de log (définit par la variable _vac_frequency_).
|
||||
Par défaut (option _cleanup_deletelogs=false_), les entrées dans les tables de logs ne sont pas supprimées, étant donné qu'un _DELETE_ à chaque fois peut être assez coûteux en terme de ressources pour la base de données. Un basculement de tables est alors opéré (par défaut toutes les 10 minutes, modifiable par l'option *cleanup_interval*), de `sl_log_1` vers `sl_log_2` ou inversement, ce qui permet de repartir sur une table vide. Un _TRUNCATE_ est alors exécuté sur l'ancienne table de log pour la nettoyer. Tous les 3 cycles de basculement, un _VACUUM_ est exécuté sur la table de log (définit par la variable _vac_frequency_).
|
||||
|
||||
Pour connaître la table de log active :
|
||||
|
||||
### Monitoring
|
||||
|
||||
Des informations sur la réplication en temps réel sont disponibles dans les tables _sl_*_ du schéma __CLUSTERNAME_ (par défaut __slony_namespace_). Le détail de ces tables est disponible ici : <http://slony.info/documentation/monitoring.html>
|
||||
Des informations sur la réplication en temps réel sont disponibles dans les tables `sl_*` du schéma _CLUSTERNAME_ (par défaut `slony_namespace`. Le détail de ces tables est disponible ici : <http://slony.info/documentation/monitoring.html>
|
||||
|
||||
Un script fournit avec Slony, _check_slony_cluster.sh_peut être utilisé comme check Nagios pour vérifier que la réplication est ok. Pour qu'il puisse être utilisé en tant que postgres sans demander de mot de passe, il est nécessaire de l'adapter un peu :
|
||||
|
||||
|
|
@ -544,5 +544,5 @@ Un script fournit avec Slony, _check_slony_cluster.sh_peut être utilisé comme
|
|||
~~~
|
||||
|
||||
~~~
|
||||
/usr/share/doc/slony1-2-bin/examples/check_slony_cluster.sh slony_namespace dbrepl2 localhost
|
||||
$ /usr/share/doc/slony1-2-bin/examples/check_slony_cluster.sh slony_namespace dbrepl2 localhost
|
||||
~~~
|
||||
|
|
|
|||
Loading…
Reference in a new issue