evolix/wiki
22
0
Fork 0
Code Releases Activity

typos et esthétique

Browse source
This commit is contained in:
Gregory Colpart 2018-06-30 18:35:57 +02:00
parent f2f982e04f
commit fd5b245804
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
HowtoPostgreSQL.md
View file

@ -568,7 +568,7 @@ wal_level = 'archive' # ou plus (hot_standby)
archive_command = 'rsync %p backup.example.net:/backup/…/archives/%f'
~~~
Ainsi, dès qu'un WAL est marqué comme complété (`pg_xlog/archive_status/*.ready`), il est copié sur le serveur de backup conformément à `archive_command`. Si la copie à réussi, le `.ready` est renommé en `.done`.
Ainsi, dès qu'un WAL est marqué comme complété (`pg_xlog/archive_status/*.ready`), il est copié sur le serveur de backup conformément à `archive_command`. Si la copie a réussi, le `.ready` est renommé en `.done`.
~~~
postgres$ psql -c "SELECT pg_start_backup('evobackup')"
@ -826,7 +826,7 @@ pg_benchmark executed 30 tests in about 5 seconds
[PgBouncer](https://pgbouncer.github.io/), de même que PgPool-II, permet de multiplexer plusieurs connexions à PostgreSQL en une seule : PgBouncer va recevoir les multiples connexions des clients et les envoyer à PostgreSQL à travers un pool de connexions qu'il maintient de manière persistente avec le serveur. L'intérêt principal est d'offrir un gain de performance puisque, avec PostgreSQL, une nouvelle connexion signifie un fork d'un nouveau processus, ce qui coûteux pour le système.
Les autres avantages sont notamment la possibilité de gérer la répartition des requêtes vers plusieurs serveurs PostgreSQL en réplication ou le redémarrage d'un serveur PostgreSQL sans coupure (les requêtes seront alors mises en file d'attente jusqu'à ce que le serveur soit à nouveau opérationnel.
Les autres avantages sont notamment la possibilité de gérer la répartition des requêtes vers plusieurs serveurs PostgreSQL en réplication ou le redémarrage d'un serveur PostgreSQL sans coupure (les requêtes seront alors mises en file d'attente jusqu'à ce que le serveur soit à nouveau opérationnel).
Dans une infrastructure multi-serveurs, il peut être installé soit sur chacun des frontaux web à la manière d'un HAProxy, soit sur les serveurs de bases de données dépendamment de ce que l'on recherche.
@ -897,6 +897,8 @@ Il existe un plugin Munin pour PgBouncer : <https://github.com/munin-monitoring/
### barman
* Documentation : <http://docs.pgbarman.org/release/2.3/>
[barman](http://www.pgbarman.org/) est un outil pour gérer les sauvegardes et les restaurations de données en se basant sur les log de transactions (WAL) de PostgreSQL.
Barman s'installe généralement sur le serveur de sauvegarde :
@ -932,8 +934,6 @@ archive_mode = on
archive_command = 'rsync -a %p barman@foo.example.com:foo/incoming/%f'
~~~
Voir [la documentation Barman](http://docs.pgbarman.org/release/2.3/).
### pgbadger
[PgBadger](https://github.com/dalibo/pgbadger) permet d'analyser des logs PostgreSQL et de générer une page HTML représentant les résultats sous forme de graphes et tableau de données.
@ -1007,7 +1007,7 @@ bench=# SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit / nullif(
Plusieurs solutions de réplication plus ou moins avancées existent avec PostgreSQL :
* _PITR_, _Point In Time Recovery_ : copie des logs de transaction (_WAL_) sur un serveur distant pour archivage. Ils peuvent ensuite être rejoués jusqu'à un point précis en cas de perte de donnée par exemple.
* _PITR_, _Point In Time Recovery_ : copie des logs de transaction (_WAL_) sur un serveur distant pour archivage. Ils peuvent ensuite être rejoués jusqu'à un point précis en cas de perte de données par exemple.
* _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*