Re: vacuum full et hot standby WAL stream: FATAL

Bonjour

Je souhaiterais savoir si les outils pgloader et ora2pg sont capables d'estimer la complexité d'une migration MYSQL vers PostgreSQL ?

Merci d'avance
Cordialement
Didier(dot)ros(at)edf(dot)fr<mailto:Didier(dot)ros(at)edf(dot)fr>

Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

Bonjour,

ROS Didier <didier(dot)ros(at)edf(dot)fr> writes:
> Je souhaiterais savoir si les outils pgloader et ora2pg sont
> capables d'estimer la complexité d'une migration MYSQL vers PostgreSQL ?

pgloader fait directement la migration complète du schéma et des
données, et aujourd'hui ne permet pas de migrer les vues et procédures
stockées, ce qui pourrait être envisagé.

L'esprit de pgloader est de réaliser tout ce qui est automatisable
directement sans intervention humaine, afin de pouvoir mettre en place
des tests de migration complètement automatisés.

Une fois le schema et les données migrées, il reste à s'occuper du code
applicatif et de la bascule de service. Ces aspects ne sont pas pris en
charge par pgloader.

Je ne comprends pas bien comment pgloader pourrait estimer la complexité
d'une migration MySQL vers PostgreSQL : dans quelle unité exprime-t'on
la complexite d'une migration ?

Ensuite, il faudrait fournir, j'imagine, une estimation dans la bonne
unité par ligne de code de trigger et une autre par éléments de logique
SQL contenus dans les vues (jointures, groupements, etc) comme éléments
de base du calcul ?

J'aimerais autant intégrer la capacité de prendre tout cela en charge
directement dans pgloader lui-même.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Bonjour Dimitri

Merci pour ta réponse
>
>Je ne comprends pas bien comment pgloader pourrait estimer la complexité d'une migration MySQL vers PostgreSQL : dans quelle unité exprime-t'on la complexite d'une migration ?
>
A EDF, nous devons migrer plusieurs centaines de bases de données MYSQL vers PostgreSQL. Une des approches possibles est de déterminer celles qui sont le plus facile à migrer .
Voici une proposition de critères qui permettrait de classifier la complexité de la migration:
- moteur CSV, InnoDB ou MyISAM (avec InnoDB c'est plus simple car possibilité d'utiliser des Foreign Keys)
- Jeux de caractères utilisés (un ou plusieurs) par colonne avec ou sans conversion de caractères
- types d'objets et leur nombre (tables, index, procédures, triggers, event...)
- colonnes de type binaires
- tables partitionnées
- contraintes
- code stocké en base (fonctions et procédures)
- réplication ou non
- type de réplication
- la volumétrie
- type et qualité des données

En fonction des résultats obtenus, on pourrait classifier les migrations :
TYPE A :
Migration simple: Estimation entre 10 et 20 J/H

TYPE B :
Migration complexe : Estimation entre 20 et 60 J/H

Ce type d'information est très important pour les application qui prévoient de migrer vers PostgreSQL.

> Ensuite, il faudrait fournir, j'imagine, une estimation dans la bonne unité par ligne de code de trigger et une autre par éléments de logique SQL contenus dans les vues (jointures, groupements, etc)
> comme éléments de base du calcul ?
>
Non, sans aller jusque dans ces détail.
Souvent dans les grandes entreprises , une migration MYSQL vers PostgreSQL se gère en mode projet et il est souvent nécessaire d'estimer le coût de la migration avant le "GO".

Cordialement
Didier ROS

-----Message d'origine-----
De : pgsql-fr-generale-owner(at)postgresql(dot)org [mailto:pgsql-fr-generale-owner(at)postgresql(dot)org]
Envoyé : lundi 23 mai 2016 14:41
À : ROS Didier
Cc : pgsql-fr-generale(at)postgresql(dot)org
Objet : Re: [pgsql-fr-generale] Estimation du coût d'une migration MYSQL vers PostgreSQL

Bonjour,

ROS Didier <didier(dot)ros(at)edf(dot)fr> writes:
> Je souhaiterais savoir si les outils pgloader et
> ora2pg sont capables d'estimer la complexité d'une migration MYSQL vers PostgreSQL ?

pgloader fait directement la migration complète du schéma et des données, et aujourd'hui ne permet pas de migrer les vues et procédures stockées, ce qui pourrait être envisagé.

L'esprit de pgloader est de réaliser tout ce qui est automatisable directement sans intervention humaine, afin de pouvoir mettre en place des tests de migration complètement automatisés.

Une fois le schema et les données migrées, il reste à s'occuper du code applicatif et de la bascule de service. Ces aspects ne sont pas pris en charge par pgloader.

Je ne comprends pas bien comment pgloader pourrait estimer la complexité d'une migration MySQL vers PostgreSQL : dans quelle unité exprime-t'on la complexite d'une migration ?

Ensuite, il faudrait fournir, j'imagine, une estimation dans la bonne unité par ligne de code de trigger et une autre par éléments de logique SQL contenus dans les vues (jointures, groupements, etc) comme éléments de base du calcul ?

J'aimerais autant intégrer la capacité de prendre tout cela en charge directement dans pgloader lui-même.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

ora2pg peut calculer une estimation en jours/homme du cout et faire un
classement en 3 catégories (A,B,C) :

http://ora2pg.darold.net/documentation.html#migration_cost_assessment

A la base ça a été développé pour Oracle mais c'est aussi possible sous
MySQL depuis ora2pg v16 (octobre 2015)

Les chiffres estimés sont à prendre avec des pincettes mais ça donne
déjà une bonne idée et c'est pas tant la valeur absolue qui est
intéressante que la comparaison entre les différentes instances à migrer
pour déterminer les meilleures bases candidates...

Ci-dessous, une mini-conf de Gilles Darold sur le sujet :
https://youtu.be/AYeQ2loAFaM?t=3m1s

--
Damien Clochard

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Bonjour Damien

Merci pour la réponse rapide et complète.
Nous allons tester la fonctionnalité à EDF.

Cordialement
didier(dot)ros(at)edf(dot)fr

-----Message d'origine-----
De : damien(at)dalibo(dot)info [mailto:damien(at)dalibo(dot)info]
Envoyé : lundi 23 mai 2016 16:27
À : ROS Didier
Cc : pgsql-fr-generale(at)postgresql(dot)org
Objet : Re: [pgsql-fr-generale] Estimation du coût d'une migration MYSQL vers PostgreSQL

ora2pg peut calculer une estimation en jours/homme du cout et faire un classement en 3 catégories (A,B,C) :

http://ora2pg.darold.net/documentation.html#migration_cost_assessment

A la base ça a été développé pour Oracle mais c'est aussi possible sous MySQL depuis ora2pg v16 (octobre 2015)

Les chiffres estimés sont à prendre avec des pincettes mais ça donne déjà une bonne idée et c'est pas tant la valeur absolue qui est intéressante que la comparaison entre les différentes instances à migrer pour déterminer les meilleures bases candidates...

Ci-dessous, une mini-conf de Gilles Darold sur le sujet :
https://youtu.be/AYeQ2loAFaM?t=3m1s

--
Damien Clochard

Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

On 23/05/2016 14:25, ROS Didier wrote:
> Bonjour
>
>
>
> Je souhaiterais savoir si les outils pgloader et ora2pg sont
> capables d’estimer la complexité d’une migration MYSQL vers PostgreSQL ?
>
>
>
> Merci d’avance
>

Bonjour,

La grande difficulté dans une migration réside moins souvent dans la base que
dans l'application.
Entrevoir le coût d'une migration par la seule migration du schéma et des
données est beaucoup trop réducteur.
Certes, la complexité de migration d'une base est dépendante du code qu'on y
trouve et du respect des standards, mais quid des API d'accès aux bases, du
code client à adapter, des pilotes compatibles ou non...

Seul la prise en compte de la pile complète peut permettre d'estimer la
faisabilité, et le cas échéant, le travail nécessaire à la migration d'un SGBD
vers un autre.

S.
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, support et formation
01.79.72.57.75

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

bonjour,
j'ai un plantage suite à l’exécution d'un vacuum full sur une base
primaire , vacuum full afin de palier à une fragmentation suite à une
série d'insert/update sur un table d'historique instrumenté par un
autovacuum
L’erreur sur l’esclave qui le fait planté :=> 2016-05-24 03:10:07.420
UTC 0 FATAL: could not receive data from WAL stream: FATAL:
requested WAL segment 00000063000003B700000091 has already been removed
Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC
replication [unknown] 0 47/0FATAL: requested WAL segment
00000063000003B700000091 has already been removed

postgresql 9.1, pas de problème d'espace disque constaté

quelqu’un a t'il une piste ? bug , saturation des walls par le vacuum full ?

merci

l’autovacuum pour la table de supervision…

cmoip=# \d supervision_object_property_history

Table « public.supervision_object_property_history »

Colonne | Type | Modificateurs

--------------------+--------------------------+---------------

id | integer | non NULL

end_date | timestamp with time zone | non NULL

is_new_valid | boolean | non NULL

new_value | character varying(1000) |

is_old_valid | boolean |

old_value | character varying(1000) |

start_date | timestamp with time zone | non NULL

object_property_id | integer | non NULL

Index :

"supervision_object_property_history_pkey" PRIMARY KEY, btree (id)

"supervision_object_property_his_end_date_object_property_id_key" UNIQUE
CONSTRAINT, btree (object_property_id, end_date) DEFERRABLE INITIALLY
DEFERRED

"idx_fk_supervision_object_property" btree (object_property_id)

"idx_sup_obj_prop_history2" btree (start_date DESC, object_property_id)

"idx_sup_obj_prop_history3" btree (object_property_id, start_date DESC)

Contraintes de clés étrangères :

"fkfbd713ce9b43da3c" FOREIGN KEY (object_property_id) REFERENCES
supervision_object_property(id)

{fillfactor=50,autovacuum_enabled=true,autovacuum_vacuum_threshold=1000,autovacuum_vacuum_scale_factor=0,autovacuum_analyze_threshold=1000,autovacuum_analyze_scale_factor=0}

ci dessous le postgressql.conf

# #########################################################################
# NOM : postgresql.conf
# AUTEUR : J.C.DIDIOT
# DATE : 14/02/2014
# CIBLE : Serveurs master / slave
# Doit etre positionne sur tous les serveurs pour etre
# present en cas de basculement et de promote
# #########################################################################

# #########################################################################
# #########################################################################
# PARAMETRES GENERIQUES
# #########################################################################
# #########################################################################
listen_addresses = '*' # Ecoute toutes les adresses
port = 5432 # Port de connexion PGSQL
max_connections = 150 # Nombre maximal de
connexions simultanées

# #########################################################################
# #########################################################################
# POUR LE DEMARRAGE EN MODE MASTER
# #########################################################################
# #########################################################################

# #########################################################################
# Activation de l'archivage en mode hot_standby
# #########################################################################
archive_mode = on # Activation de l'archivage des
journaux de transactions WAL
wal_level = hot_standby # Niveau d'archibage
hot_standby

# #########################################################################
# Commande d'archivage / Copie du fichier wal si il n'est pas deja archive
# #########################################################################
# archive_command = 'test ! -f /mnt/postgresqlA/data/pg_archive/%f && cp
%p /mnt/postgresqlA/data/pg_archive/%f'
archive_command = 'cd .'

# #########################################################################
# Forcer generation d'un wal meme si le segment n'est pas complet
# #########################################################################
archive_timeout = 60 # Au minimum, un fichier wal
de 16 Mo genere toutes les minutes

# #########################################################################
# Nombre maximal de processus walsender en cours d execution - Nombre de
serveurs en attente
# #########################################################################
max_wal_senders=1

# #########################################################################
# Nombre de WAL a conserver dans pg_xlog pour que le slave rattrape son
retard
# #########################################################################
wal_keep_segments = 64

# #########################################################################
# Timeout pour les connexions de replication inactives / Par defaut 60000
# #########################################################################
replication_timeout = 60000 # mseconds # Termine la
connexion au bout de 60 secondes

# #########################################################################
# #########################################################################
# POUR LE DEMARRAGE EN MODE SLAVE
# #########################################################################
# #########################################################################

# #########################################################################
# Autorise la connexion au Master pour la replication
# #########################################################################
hot_standby = on

# #########################################################################
# #########################################################################
# OPTIONS PERMETTANT LA REPLICATION SYNCHRONE
# #########################################################################
# #########################################################################

# #########################################################################
# Activation la replication synchrone
# #########################################################################
synchronous_commit = on
# synchronous_standby_names # Nom du slave - Genere
dynamiquement par pacemaker

# #########################################################################
# Delais d'envoi de la confirmation d'ecriture d'un WAL de la part du
slave au master
# #########################################################################
wal_receiver_status_interval = 2 # seconds

# #########################################################################
# Forcer l'attente de la reponse du slave pour valider une operation
# #########################################################################
synchronous_commit = on

#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------

# - Where to Log -

log_destination = 'stderr' # Valid values are combinations of
# stderr, csvlog, syslog, and
eventlog,
# depending on platform. csvlog
# requires logging_collector to
be on.

# This is used when logging to stderr:
logging_collector = on # Enable capturing of stderr and csvlog
# into log files. Required to
be on for
# csvlogs.
# (change requires restart)

# These are only used if logging_collector is on:
log_directory = '/var/log/postgres' # directory where log
files are written,
# can be absolute or relative
to PGDATA
log_filename = 'postgresql-%a.log' # log file name pattern,
# can include strftime() escapes
#log_file_mode = 0600 # creation mode for log files,
# begin with 0 to use octal
notation
log_truncate_on_rotation = on # If on, an existing log file
with the
# same name as the new log file
will be
# truncated rather than
appended to.
# But such truncation only
occurs on
# time-driven rotation, not on
restarts
# or size-driven rotation.
Default is
# off, meaning append to
existing files
# in all cases.
log_rotation_age = 1d # Automatic rotation of logfiles will
# happen after that time. 0
disables.
#log_rotation_size = 20MB # Automatic rotation of
logfiles will
# happen after that much log
output.
# 0 disables.

# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'

# This is only relevant when logging to eventlog (win32):
#event_source = 'PostgreSQL'

# - When to Log -

#client_min_messages = notice # values in order of decreasing
detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# log
# notice
# warning
# error

#log_min_messages = warning # values in order of decreasing
detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic

#log_min_error_statement = error # values in order of decreasing
detail:
# debug5
# debug4
# debug3
# debug2
# debug1
# info
# notice
# warning
# error
# log
# fatal
# panic (effectively off)

#log_min_duration_statement = -1 # -1 is disabled, 0 logs all
statements
# and their durations, > 0 logs
only
# statements running at least
this number
# of milliseconds

# - What to Log -

#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = on
#log_checkpoints = off
log_connections = on
#log_disconnections = off
#log_duration = off
#log_error_verbosity = default # terse, default, or verbose
messages
#log_hostname = off
log_line_prefix = '%m %u %d %x %v' # special values:
# %a = application name
# %u = user name
# %d = database name
# %r = remote host and port
# %h = remote host
# %p = process ID
# %t = timestamp without
milliseconds
# %m = timestamp with
milliseconds
# %i = command tag
# %e = SQL state
# %c = session ID
# %l = session line number
# %s = session start timestamp
# %v = virtual transaction ID
# %x = transaction ID (0 if none)
# %q = stop here in non-session
# processes
# %% = '%'
# e.g. '<%u%%%d> '
#log_lock_waits = off # log lock waits >= deadlock_timeout
log_statement = 'none' # none, ddl, mod, all
#log_temp_files = -1 # log temporary files equal or
larger
# than the specified size in
kilobytes;
# -1 disables, 0 logs all temp
files
log_timezone = 'UTC'

# ############
# Tunning SMU
# ############
shared_buffers=2600MB
work_mem=128MB
effective_io_concurrency=1000
effective_cache_size=12GB
checkpoint_segments=16
wal_buffers=64MB
include '/mnt/postgresql/tmp/rep_mode.conf' # added by pgsql RA

----- Mail original -----
> j'ai un plantage suite à l’exécution d'un vacuum full sur une base
> primaire , vacuum full afin de palier à une fragmentation suite à
> une série d'insert/update sur un table d'historique instrumenté par
> un autovacuum
> L’erreur sur l’esclave qui le fait planté :=> 2016-05-24 03:10:07.420
> UTC 0 FATAL: could not receive data from WAL stream: FATAL:
> requested WAL segment 00000063000003B700000091 has already been
> removed
> Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC
> replication [unknown] 0 47/0FATAL: requested WAL segment
> 00000063000003B700000091 has already been removed

J'ai trouvé plusieurs occurrence du message d'erreur sur le net ; la solution semble être d'augmenter le nombre de segments (variable wal_keep_segments) ou d'activer l'archivage du WAL :

http://stackoverflow.com/questions/28201475/how-do-i-fix-a-postgresql-9-3-slave-that-cannot-keep-up-with-the-master
http://www.postgresql.org/message-id/28495974b30f304b064b36c372654517.squirrel@sq.gransy.com

Plus d'infos ici :

https://wiki.postgresql.org/wiki/Streaming_Replication
http://www.postgresql.org/docs/9.2/static/runtime-config-replication.html

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Bonjour

la rotation de vos fichiers de transaction sur le maitre est
certainement trop "courte" au regard de la capacité d'absorption des
modifications par l'esclave. Augmentez wal_keep_segments. Vous pouvez le
régler en fonction de votre espace disponible (1 segment fait 16 Mo par
défaut, Il ne faudrait pas saturer à terme le filesystem du maitre).

En revanche votre réplication est cassée. Vous devez réinitialiser votre
cluster esclave pour la relancer.

Lionel

Le 24/05/2016 17:57, Sébastien Dinot a écrit :
> ----- Mail original -----
>> j'ai un plantage suite à l’exécution d'un vacuum full sur une base
>> primaire , vacuum full afin de palier à une fragmentation suite à
>> une série d'insert/update sur un table d'historique instrumenté par
>> un autovacuum
>> L’erreur sur l’esclave qui le fait planté :=> 2016-05-24 03:10:07.420
>> UTC 0 FATAL: could not receive data from WAL stream: FATAL:
>> requested WAL segment 00000063000003B700000091 has already been
>> removed
>> Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC
>> replication [unknown] 0 47/0FATAL: requested WAL segment
>> 00000063000003B700000091 has already been removed
> J'ai trouvé plusieurs occurrence du message d'erreur sur le net ; la solution semble être d'augmenter le nombre de segments (variable wal_keep_segments) ou d'activer l'archivage du WAL :
>
> http://stackoverflow.com/questions/28201475/how-do-i-fix-a-postgresql-9-3-slave-that-cannot-keep-up-with-the-master
> http://www.postgresql.org/message-id/28495974b30f304b064b36c372654517.squirrel@sq.gransy.com
>
> Plus d'infos ici :
>
> https://wiki.postgresql.org/wiki/Streaming_Replication
> http://www.postgresql.org/docs/9.2/static/runtime-config-replication.html
>
> Sébastien
>

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Bonjour,
Comme indiqué par Lionel votre slave a "décroché" de la streaming
réplication. Celui-ci demande des journaux que le maître a déjà
recyclé.

Vous n'avez pas d'autres solution que de reconstruire votre esclave.

Plutôt que d'augmenter wal_keep_segments vous devriez mettre en place
l'archivage :
https://blog.anayrat.info/2015/01/02/replication-par-transfert-de-journaux-de-transaction-part-2/

Attention si le maître n'arrive plus à archiver il conserve les
journaux de transaction, jusqu'à remplir le système de fichier.

L'inconvénient de wal_keep_segments est qu'en cas de forte activité en
écriture) le maître peut nettoyer des wal encore nécessaire à
l'esclave (s'il n'est pas suffisamment élevé).

Le 24 mai 2016 à 18:24, Lionel Bargeot <lionel(dot)bargeot(at)gmail(dot)com> a écrit :
> Bonjour
>
> la rotation de vos fichiers de transaction sur le maitre est certainement
> trop "courte" au regard de la capacité d'absorption des modifications par
> l'esclave. Augmentez wal_keep_segments. Vous pouvez le régler en fonction de
> votre espace disponible (1 segment fait 16 Mo par défaut, Il ne faudrait pas
> saturer à terme le filesystem du maitre).
>
> En revanche votre réplication est cassée. Vous devez réinitialiser votre
> cluster esclave pour la relancer.
>
> Lionel
>
>
> Le 24/05/2016 17:57, Sébastien Dinot a écrit :
>>
>> ----- Mail original -----
>>>
>>> j'ai un plantage suite à l’exécution d'un vacuum full sur une base
>>> primaire , vacuum full afin de palier à une fragmentation suite à
>>> une série d'insert/update sur un table d'historique instrumenté par
>>> un autovacuum
>>> L’erreur sur l’esclave qui le fait planté :=> 2016-05-24 03:10:07.420
>>> UTC 0 FATAL: could not receive data from WAL stream: FATAL:
>>> requested WAL segment 00000063000003B700000091 has already been
>>> removed
>>> Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC
>>> replication [unknown] 0 47/0FATAL: requested WAL segment
>>> 00000063000003B700000091 has already been removed
>>
>> J'ai trouvé plusieurs occurrence du message d'erreur sur le net ; la
>> solution semble être d'augmenter le nombre de segments (variable
>> wal_keep_segments) ou d'activer l'archivage du WAL :
>>
>>
>> http://stackoverflow.com/questions/28201475/how-do-i-fix-a-postgresql-9-3-slave-that-cannot-keep-up-with-the-master
>>
>> http://www.postgresql.org/message-id/28495974b30f304b064b36c372654517.squirrel@sq.gransy.com
>>
>> Plus d'infos ici :
>>
>> https://wiki.postgresql.org/wiki/Streaming_Replication
>> http://www.postgresql.org/docs/9.2/static/runtime-config-replication.html
>>
>> Sébastien
>>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

On 24/05/2016 17:35, pierre crumeyrolle wrote:
> bonjour,
> j'ai un plantage suite à l’exécution d'un vacuum full sur une base primaire ,
> vacuum full afin de palier à une fragmentation suite à une série
> d'insert/update sur un table d'historique instrumenté par un autovacuum
> L’erreur sur l’esclave qui le fait planté :=> 2016-05-24 03:10:07.420 UTC 0
> FATAL: could not receive data from WAL stream: FATAL: requested WAL segment
> 00000063000003B700000091 has already been removed
> Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC replication
> [unknown] 0 47/0FATAL: requested WAL segment 00000063000003B700000091 has
> already been removed
>

Bonjour,

<Avant-propos>
La netiquette souhaiterait que vous démarriez une nouvelle discussion en
envoyant un nouveau courriel à la liste, et que vous évitiez le vol de thread
en répondant à un thread existant (même en en changeant le sujet).
</avant-propos>

En complément de ce qui vous a été proposé par Sébastien et Lionel, vous
devriez envisager l'archivage des WAL afin d'éviter d'avoir à reconstruire le
nœud secondaire lors d'une telle mésaventure.
De cette façon, lorsqu'un WAL n'est plus disponible sur le nœud principal, le
système de réplication le récupérerait dans les archives.

S.

--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, support et formation
01.79.72.57.75

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Pour information

Nous avons modifier les fichiers crm.cfg et postgresql.conf pour
augmenter le timeout de non réponse de postgresql et augmenter le
nombre de WALL pour la réplication.

Ceci à permis de repousser le moment ou le SECONDAIRE (du CLUSTER)
passe en DISCONNECT.

Modif dans crm.cfg :
primitive pgsql ocf:heartbeat:pgsql \
... 180 au lieu de 60
op monitor interval="5" timeout="180" on-fail="fence" \
... 180 au lieu de 120
op promote interval="0" timeout="180" on-fail="fence" \
... 120 au lieu de 90
op notify interval="0" timeout="120"

Modif dans postgresql.conf :
wal_keep_segments = 110 au lieu de 64
checkpoint_segments= 32 au lieu de 16

Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr> a écrit :

> ----- Mail original -----
>> j'ai un plantage suite à l’exécution d'un vacuum full sur une base
>> primaire , vacuum full afin de palier à une fragmentation suite à
>> une série d'insert/update sur un table d'historique instrumenté par
>> un autovacuum
>> L’erreur sur l’esclave qui le fait planté :=> 2016-05-24 03:10:07.420
>> UTC 0 FATAL: could not receive data from WAL stream: FATAL:
>> requested WAL segment 00000063000003B700000091 has already been
>> removed
>> Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC
>> replication [unknown] 0 47/0FATAL: requested WAL segment
>> 00000063000003B700000091 has already been removed
>
> J'ai trouvé plusieurs occurrence du message d'erreur sur le net ; la
> solution semble être d'augmenter le nombre de segments (variable
> wal_keep_segments) ou d'activer l'archivage du WAL :
>
> http://stackoverflow.com/questions/28201475/how-do-i-fix-a-postgresql-9-3-slave-that-cannot-keep-up-with-the-master
> http://www.postgresql.org/message-id/28495974b30f304b064b36c372654517.squirrel@sq.gransy.com
>
> Plus d'infos ici :
>
> https://wiki.postgresql.org/wiki/Streaming_Replication
> http://www.postgresql.org/docs/9.2/static/runtime-config-replication.html
>
> Sébastien
>
> --
> Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
> http://sebastien.dinot.free.fr/
> Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

2016-05-24 14:12 GMT-07:00 CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr>:
> Modif dans postgresql.conf :
> wal_keep_segments = 110 au lieu de 64
> checkpoint_segments= 32 au lieu de 16

Celà dépend de l'activité du maître, mais 16 ou même 32 segments de
WAL peuvent se remplir assez rapidement selon l'activité, ce qui a
pour effect de causer un fréquence rapide des checkpoints. My 2c comme
on dit de l'autre côté de l'Atlantique.
--
Michael

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

il semblerait indispensable de mettre en place l’archivage des
journaux en plus de la streaming réplication
la ceinture suffit pas faut aussi les bretelles

Stéphane Schildknecht <stephane(dot)schildknecht(at)postgres(dot)fr> a écrit :

> On 24/05/2016 17:35, pierre crumeyrolle wrote:
>> bonjour,
>> j'ai un plantage suite à l’exécution d'un vacuum full sur une base
>> primaire ,
>> vacuum full afin de palier à une fragmentation suite à une série
>> d'insert/update sur un table d'historique instrumenté par un autovacuum
>> L’erreur sur l’esclave qui le fait planté :=> 2016-05-24
>> 03:10:07.420 UTC 0
>> FATAL: could not receive data from WAL stream: FATAL: requested
>> WAL segment
>> 00000063000003B700000091 has already been removed
>> Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC replication
>> [unknown] 0 47/0FATAL: requested WAL segment 00000063000003B700000091 has
>> already been removed
>>
>
> Bonjour,
>
> <Avant-propos>
> La netiquette souhaiterait que vous démarriez une nouvelle discussion en
> envoyant un nouveau courriel à la liste, et que vous évitiez le vol de thread
> en répondant à un thread existant (même en en changeant le sujet).
> </avant-propos>
>
> En complément de ce qui vous a été proposé par Sébastien et Lionel, vous
> devriez envisager l'archivage des WAL afin d'éviter d'avoir à reconstruire le
> nœud secondaire lors d'une telle mésaventure.
> De cette façon, lorsqu'un WAL n'est plus disponible sur le nœud principal, le
> système de réplication le récupérerait dans les archives.
>
> S.
>
> --
> Stéphane Schildknecht
> Contact régional PostgreSQL pour l'Europe francophone
> Loxodata - Conseil, support et formation
> 01.79.72.57.75
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 25 mai 2016 12:01 AM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
écrit :
>
> il semblerait indispensable de mettre en place l’archivage des journaux
en plus de la streaming réplication
> la ceinture suffit pas faut aussi les bretelles
>

Oui, pour toutes les versions qui ne disposent pas encore des slots de
réplication. Avec les slots de réplication, l'archivage n'est plus
nécessaire.

>
>
> Stéphane Schildknecht <stephane(dot)schildknecht(at)postgres(dot)fr> a écrit :
>
>
>> On 24/05/2016 17:35, pierre crumeyrolle wrote:
>>>
>>> bonjour,
>>> j'ai un plantage suite à l’exécution d'un vacuum full sur une base
primaire ,
>>> vacuum full afin de palier à une fragmentation suite à une série
>>> d'insert/update sur un table d'historique instrumenté par un autovacuum
>>> L’erreur sur l’esclave qui le fait planté :=> 2016-05-24 03:10:07.420
UTC 0
>>> FATAL: could not receive data from WAL stream: FATAL: requested WAL
segment
>>> 00000063000003B700000091 has already been removed
>>> Sur le maitre, on a l’équivalent :=> 2016-05-24 00:00:00.908 UTC
replication
>>> [unknown] 0 47/0FATAL: requested WAL segment 00000063000003B700000091
has
>>> already been removed
>>>
>>
>> Bonjour,
>>
>> <Avant-propos>
>> La netiquette souhaiterait que vous démarriez une nouvelle discussion en
>> envoyant un nouveau courriel à la liste, et que vous évitiez le vol de
thread
>> en répondant à un thread existant (même en en changeant le sujet).
>> </avant-propos>
>>
>> En complément de ce qui vous a été proposé par Sébastien et Lionel, vous
>> devriez envisager l'archivage des WAL afin d'éviter d'avoir à
reconstruire le
>> nœud secondaire lors d'une telle mésaventure.
>> De cette façon, lorsqu'un WAL n'est plus disponible sur le nœud
principal, le
>> système de réplication le récupérerait dans les archives.
>>
>> S.
>>
>> --
>> Stéphane Schildknecht
>> Contact régional PostgreSQL pour l'Europe francophone
>> Loxodata - Conseil, support et formation
>> 01.79.72.57.75
>>
>>
>> --
>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Bonjour,

On 25/05/2016 08:36, Guillaume Lelarge wrote:
> Le 25 mai 2016 12:01 AM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr
> <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>> a écrit :
>>
>> il semblerait indispensable de mettre en place l’archivage des journaux en
> plus de la streaming réplication
>> la ceinture suffit pas faut aussi les bretelles
>>
>
> Oui, pour toutes les versions qui ne disposent pas encore des slots de
> réplication. Avec les slots de réplication, l'archivage n'est plus nécessaire.

Je me permets d'ajouter un petit bémol à cette affirmation.

Si le secondaire est indisponible, l'utilisation de slot de réplication conduit
à la rétention des fichiers WAL sur le primaire.

Et cela *jusqu'à* la reconnexion du secondaire. Si le secondaire ne revient pas
assez rapidement ("rapidement" étant fonction de l'activité sur le serveur
principal), on peut arriver à la saturation de la partition de stockage des
pg_xlog sur le primaire, et à l'arrêt du serveur principal.

Donc, non, l'utilisation de slots de réplication ne remplace pas l'archivage
des WAL.

Ah, autre cas intéressant, celui de la création d'un nœud secondaire avec slot
de réplication par script automatisé (genre puppet), puis suppression du nœud,
ou arrêt sans suppression du slot de réplication. Même conséquence.

S.
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, support et formation
01.79.72.57.75

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 25 mai 2016 à 10:42, Stéphane Schildknecht <
stephane(dot)schildknecht(at)postgres(dot)fr> a écrit :

> Bonjour,
>
> On 25/05/2016 08:36, Guillaume Lelarge wrote:
> > Le 25 mai 2016 12:01 AM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr
> > <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>> a écrit :
> >>
> >> il semblerait indispensable de mettre en place l’archivage des journaux
> en
> > plus de la streaming réplication
> >> la ceinture suffit pas faut aussi les bretelles
> >>
> >
> > Oui, pour toutes les versions qui ne disposent pas encore des slots de
> > réplication. Avec les slots de réplication, l'archivage n'est plus
> nécessaire.
>
> Je me permets d'ajouter un petit bémol à cette affirmation.
>
> Si le secondaire est indisponible, l'utilisation de slot de réplication
> conduit
> à la rétention des fichiers WAL sur le primaire.
>
> Et cela *jusqu'à* la reconnexion du secondaire. Si le secondaire ne
> revient pas
> assez rapidement ("rapidement" étant fonction de l'activité sur le serveur
> principal), on peut arriver à la saturation de la partition de stockage des
> pg_xlog sur le primaire, et à l'arrêt du serveur principal.
>
> Donc, non, l'utilisation de slots de réplication ne remplace pas
> l'archivage
> des WAL.
>
>
Tu as le même problème avec l'archivage. Si l'archivage ne fonctionne pas,
accumulation des journaux sur le maître...

> Ah, autre cas intéressant, celui de la création d'un nœud secondaire avec
> slot
> de réplication par script automatisé (genre puppet), puis suppression du
> nœud,
> ou arrêt sans suppression du slot de réplication. Même conséquence.
>
>

--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com

On 25/05/2016 11:09, Guillaume Lelarge wrote:
> Le 25 mai 2016 à 10:42, Stéphane Schildknecht
> <stephane(dot)schildknecht(at)postgres(dot)fr <mailto:stephane(dot)schildknecht(at)postgres(dot)fr>>
> a écrit :
>
> Bonjour,
>
> On 25/05/2016 08:36, Guillaume Lelarge wrote:
> > Le 25 mai 2016 12:01 AM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>
> > <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>>> a
> écrit :
> >>
> >> il semblerait indispensable de mettre en place l’archivage des journaux en
> > plus de la streaming réplication
> >> la ceinture suffit pas faut aussi les bretelles
> >>
> >
> > Oui, pour toutes les versions qui ne disposent pas encore des slots de
> > réplication. Avec les slots de réplication, l'archivage n'est plus nécessaire.
>
> Je me permets d'ajouter un petit bémol à cette affirmation.
>
> Si le secondaire est indisponible, l'utilisation de slot de réplication conduit
> à la rétention des fichiers WAL sur le primaire.
>
> Et cela *jusqu'à* la reconnexion du secondaire. Si le secondaire ne revient pas
> assez rapidement ("rapidement" étant fonction de l'activité sur le serveur
> principal), on peut arriver à la saturation de la partition de stockage des
> pg_xlog sur le primaire, et à l'arrêt du serveur principal.
>
> Donc, non, l'utilisation de slots de réplication ne remplace pas l'archivage
> des WAL.
>
>
> Tu as le même problème avec l'archivage. Si l'archivage ne fonctionne pas,
> accumulation des journaux sur le maître...
>

Effectivement, ma réponse n'était peut-être pas assez complète.
Je n'ai pas dit que la solution était parfaite. En l'absence de supervision,
toute solution est imparfaite, puisque faillible.

Lorsque l'on met en place une solution de réplication, il est *impératif* de
surveiller l'espace disque sur le serveur principal, et l'activité des WAL.

Pour s'assurer que le nœud secondaire soit toujours en mesure de repartir, on
peut :
- utiliser le paramètre wal_keep_segments ;
- utiliser les slots de réplication ;
- utiliser l'archivage des WAL.

Il n'y a pas de solution universelle, et les trois possibilités ne s'exclut pas.

Dans tous les cas, il faut surveiller l'activité et l'occupation des disques.

Le paramètre wal_keep_segments n'est pas forcément suffisant, il reste possible
de perdre des WAL. Mais il permet de s'assurer qu'on ne saturera pas la
partition du fait de l'empilement de WAL non consommés.

Les slots de réplication ne sont pas une solution idéale, ils ne permettent
pas, par exemple de prévoir de faire du PITR. Le risque est réel également de
ne jamais purger les WAL et de saturer les disques.

L'archivage, en soi, n'est pas suffisant, puisqu'en l'absence de surveillance
des disques sur le secondaire, on peut aussi saturer la partition WAL sur le
primaire. Ou simplement si l'archivage ne peut s'effectuer. Mais il permet de
déporter le stockage des WAL et de permettre à un nœud secondaire de prendre
plus de retard et de le rattraper sans forcément impacter le primaire.

En résumé :
Dans le cas des bases de données, le sirop Typhon n'existe pas.
Différentes méthodes sont applicables, mais en l'absence de supervision, aucune
n'est valable.

S.
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, support et formation
01.79.72.57.75

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le Wed, 25 May 2016 11:09:29 +0200,
Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :

> Le 25 mai 2016 à 10:42, Stéphane Schildknecht <
> stephane(dot)schildknecht(at)postgres(dot)fr> a écrit :
>
> > Bonjour,
> >
> > On 25/05/2016 08:36, Guillaume Lelarge wrote:
> > > Le 25 mai 2016 12:01 AM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr
> > > <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>> a écrit :
> > >>
> > >> il semblerait indispensable de mettre en place l’archivage des journaux
> > en
> > > plus de la streaming réplication
> > >> la ceinture suffit pas faut aussi les bretelles
> > >>
> > >
> > > Oui, pour toutes les versions qui ne disposent pas encore des slots de
> > > réplication. Avec les slots de réplication, l'archivage n'est plus
> > nécessaire.
> >
> > Je me permets d'ajouter un petit bémol à cette affirmation.
> >
> > Si le secondaire est indisponible, l'utilisation de slot de réplication
> > conduit
> > à la rétention des fichiers WAL sur le primaire.
> >
> > Et cela *jusqu'à* la reconnexion du secondaire. Si le secondaire ne
> > revient pas
> > assez rapidement ("rapidement" étant fonction de l'activité sur le serveur
> > principal), on peut arriver à la saturation de la partition de stockage des
> > pg_xlog sur le primaire, et à l'arrêt du serveur principal.
> >
> > Donc, non, l'utilisation de slots de réplication ne remplace pas
> > l'archivage
> > des WAL.
> >
> Tu as le même problème avec l'archivage. Si l'archivage ne fonctionne pas,
> accumulation des journaux sur le maître...

Tout ça pour dire qu'il faut savoir superviser son biniou correctement quoi. Que
ce soit pour l'archivage ou les slots.

> > Ah, autre cas intéressant, celui de la création d'un nœud secondaire avec
> > slot
> > de réplication par script automatisé (genre puppet), puis suppression du
> > nœud,
> > ou arrêt sans suppression du slot de réplication. Même conséquence.

Oui. Ceci dit, on fourni ici une piste de travail un peu hors sujet (la version
utilisée ne supporte pas les slots de répli). Si en plus on doit ré-écrire la
doc ici et ajouter toutes les conséquences dans un mail, on est pas sorti.

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

----- Mail original -----
> Oui. Ceci dit, on fourni ici une piste de travail un peu hors sujet
> (la version utilisée ne supporte pas les slots de répli).

À ce propos, pensez-vous qu'une montée de version résoudrait les problèmes signalés par Pierre ? Sauf erreur de ma part, en version 9.1, la réplication était encore jeune.

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 25 mai 2016 11:57 AM, "Sébastien Dinot" <sebastien(dot)dinot(at)free(dot)fr> a
écrit :
>
> ----- Mail original -----
> > Oui. Ceci dit, on fourni ici une piste de travail un peu hors sujet
> > (la version utilisée ne supporte pas les slots de répli).
>
> À ce propos, pensez-vous qu'une montée de version résoudrait les
problèmes signalés par Pierre ? Sauf erreur de ma part, en version 9.1, la
réplication était encore jeune.
>

Non. Ça ne lui ajouterait que des possibilités pour contourner le problème.

----- Mail original -----
> Non. Ça ne lui ajouterait que des possibilités pour contourner le
> problème.

Merci Guillaume

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

On 25/05/2016 11:56, Sébastien Dinot wrote:
> ----- Mail original -----
>> Oui. Ceci dit, on fourni ici une piste de travail un peu hors sujet
>> (la version utilisée ne supporte pas les slots de répli).
>
> À ce propos, pensez-vous qu'une montée de version résoudrait les problèmes signalés par Pierre ? Sauf erreur de ma part, en version 9.1, la réplication était encore jeune.

Le support communautaire de la version 9.1 prend fin en septembre de cette année.
Je dirais que si la montée de version ne résoud pas le problème du recyclage
des WAL, dans le cas présent, elle permet tout de même de s'affranchir de la
limite de fin de support. Et comme tu le sais, les améliorations apportées à
chaque version font de PostgreSQL un SGBD chaque jour meilleur.

Ensuite, concernant la partie réplication en streaming, la version 9.2 apporte
la possibilité de cascader les réplications, la 9.3 apporte la possibilité de
suivre un switch de timeline, la 9.4 apporte les slots de replication, la 9.5
permet aux nœuds secondaires d'archivers les WAL...

Bref, je pense que si le passage a une version plus récente de PG est
envisageable, il faut l'envisager.

S.
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, support et formation
01.79.72.57.75

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

2016-05-25 2:31 GMT-07:00 Stéphane Schildknecht
<stephane(dot)schildknecht(at)postgres(dot)fr>:
> Effectivement, ma réponse n'était peut-être pas assez complète.
> Je n'ai pas dit que la solution était parfaite. En l'absence de supervision,
> toute solution est imparfaite, puisque faillible.
>
> Lorsque l'on met en place une solution de réplication, il est *impératif* de
> surveiller l'espace disque sur le serveur principal, et l'activité des WAL.
>
> Pour s'assurer que le nœud secondaire soit toujours en mesure de repartir, on
> peut :
> - utiliser le paramètre wal_keep_segments ;
> - utiliser les slots de réplication ;
> - utiliser l'archivage des WAL.
>
> Il n'y a pas de solution universelle, et les trois possibilités ne s'exclut pas.
>
> Dans tous les cas, il faut surveiller l'activité et l'occupation des disques.
>
> Le paramètre wal_keep_segments n'est pas forcément suffisant, il reste possible
> de perdre des WAL. Mais il permet de s'assurer qu'on ne saturera pas la
> partition du fait de l'empilement de WAL non consommés.

L'archivage des WAL représente un avantage en comparaison des slots de
réplication: ils peuvent être compressés, permettant de garder plus
d'histoire pour le même montant d'espace.

> Les slots de réplication ne sont pas une solution idéale, ils ne permettent
> pas, par exemple de prévoir de faire du PITR. Le risque est réel également de
> ne jamais purger les WAL et de saturer les disques.

Amen.

> L'archivage, en soi, n'est pas suffisant, puisqu'en l'absence de surveillance
> des disques sur le secondaire, on peut aussi saturer la partition WAL sur le
> primaire. Ou simplement si l'archivage ne peut s'effectuer. Mais il permet de
> déporter le stockage des WAL et de permettre à un nœud secondaire de prendre
> plus de retard et de le rattraper sans forcément impacter le primaire.

Celà dépend grandement où se situe la priorité du cluster: le maître
peut-il être mis à terre pendant quelques minutes? Ou non?
--
Michael

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

ok merci pour ces précisions
dans l’immédiat j'ai tenté un wal_keep_segments = 4000 pour voir
réponse demain

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> a écrit :

> 2016-05-25 2:31 GMT-07:00 Stéphane Schildknecht
> <stephane(dot)schildknecht(at)postgres(dot)fr>:
>> Effectivement, ma réponse n'était peut-être pas assez complète.
>> Je n'ai pas dit que la solution était parfaite. En l'absence de supervision,
>> toute solution est imparfaite, puisque faillible.
>>
>> Lorsque l'on met en place une solution de réplication, il est *impératif* de
>> surveiller l'espace disque sur le serveur principal, et l'activité des WAL.
>>
>> Pour s'assurer que le nœud secondaire soit toujours en mesure de
>> repartir, on
>> peut :
>> - utiliser le paramètre wal_keep_segments ;
>> - utiliser les slots de réplication ;
>> - utiliser l'archivage des WAL.
>>
>> Il n'y a pas de solution universelle, et les trois possibilités ne
>> s'exclut pas.
>>
>> Dans tous les cas, il faut surveiller l'activité et l'occupation
>> des disques.
>>
>> Le paramètre wal_keep_segments n'est pas forcément suffisant, il
>> reste possible
>> de perdre des WAL. Mais il permet de s'assurer qu'on ne saturera pas la
>> partition du fait de l'empilement de WAL non consommés.
>
> L'archivage des WAL représente un avantage en comparaison des slots de
> réplication: ils peuvent être compressés, permettant de garder plus
> d'histoire pour le même montant d'espace.
>
>> Les slots de réplication ne sont pas une solution idéale, ils ne permettent
>> pas, par exemple de prévoir de faire du PITR. Le risque est réel
>> également de
>> ne jamais purger les WAL et de saturer les disques.
>
> Amen.
>
>> L'archivage, en soi, n'est pas suffisant, puisqu'en l'absence de
>> surveillance
>> des disques sur le secondaire, on peut aussi saturer la partition WAL sur le
>> primaire. Ou simplement si l'archivage ne peut s'effectuer. Mais il
>> permet de
>> déporter le stockage des WAL et de permettre à un nœud secondaire de prendre
>> plus de retard et de le rattraper sans forcément impacter le primaire.
>
> Celà dépend grandement où se situe la priorité du cluster: le maître
> peut-il être mis à terre pendant quelques minutes? Ou non?
> --
> Michael
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

hello
toujours pas de retour , test en charge ce weekend donc retour lundi
(wal_keep_segments = 4000)

question replication :
les exigences de mon système sont 0 perte de données entre primaire et
secondaire :
a t'on un retour d'expérience sur ce type d'exigence de haute
disponibilité avec postgresql , car
d’après ce que j'ai cru comprendre la réplication par streaming est
relativement jeune chez postgresql ?

cordialement

CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> a écrit :

> ok merci pour ces précisions
> dans l’immédiat j'ai tenté un wal_keep_segments = 4000 pour voir
> réponse demain
>
>
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> a écrit :
>
>> 2016-05-25 2:31 GMT-07:00 Stéphane Schildknecht
>> <stephane(dot)schildknecht(at)postgres(dot)fr>:
>>> Effectivement, ma réponse n'était peut-être pas assez complète.
>>> Je n'ai pas dit que la solution était parfaite. En l'absence de
>>> supervision,
>>> toute solution est imparfaite, puisque faillible.
>>>
>>> Lorsque l'on met en place une solution de réplication, il est
>>> *impératif* de
>>> surveiller l'espace disque sur le serveur principal, et l'activité des WAL.
>>>
>>> Pour s'assurer que le nœud secondaire soit toujours en mesure de
>>> repartir, on
>>> peut :
>>> - utiliser le paramètre wal_keep_segments ;
>>> - utiliser les slots de réplication ;
>>> - utiliser l'archivage des WAL.
>>>
>>> Il n'y a pas de solution universelle, et les trois possibilités ne
>>> s'exclut pas.
>>>
>>> Dans tous les cas, il faut surveiller l'activité et l'occupation
>>> des disques.
>>>
>>> Le paramètre wal_keep_segments n'est pas forcément suffisant, il
>>> reste possible
>>> de perdre des WAL. Mais il permet de s'assurer qu'on ne saturera pas la
>>> partition du fait de l'empilement de WAL non consommés.
>>
>> L'archivage des WAL représente un avantage en comparaison des slots de
>> réplication: ils peuvent être compressés, permettant de garder plus
>> d'histoire pour le même montant d'espace.
>>
>>> Les slots de réplication ne sont pas une solution idéale, ils ne permettent
>>> pas, par exemple de prévoir de faire du PITR. Le risque est réel
>>> également de
>>> ne jamais purger les WAL et de saturer les disques.
>>
>> Amen.
>>
>>> L'archivage, en soi, n'est pas suffisant, puisqu'en l'absence de
>>> surveillance
>>> des disques sur le secondaire, on peut aussi saturer la partition
>>> WAL sur le
>>> primaire. Ou simplement si l'archivage ne peut s'effectuer. Mais
>>> il permet de
>>> déporter le stockage des WAL et de permettre à un nœud secondaire
>>> de prendre
>>> plus de retard et de le rattraper sans forcément impacter le primaire.
>>
>> Celà dépend grandement où se situe la priorité du cluster: le maître
>> peut-il être mis à terre pendant quelques minutes? Ou non?
>> --
>> Michael
>>
>>
>> --
>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

On 27/05/2016 12:12, CRUMEYROLLE Pierre wrote:
> hello
> toujours pas de retour , test en charge ce weekend donc retour lundi
> (wal_keep_segments = 4000)
>
> question replication :
> les exigences de mon système sont 0 perte de données entre primaire et
> secondaire :
> a t'on un retour d'expérience sur ce type d'exigence de haute disponibilité
> avec postgresql , car
> d’après ce que j'ai cru comprendre la réplication par streaming est
> relativement jeune chez postgresql ?
>

Bonjour Pierre,

A l'échelle de l'humanité, effectivement, la technologie est jeune ;-)

Mais le streaming, ça fait quand même quelques années que c'est en place, et
éprouvée.
De nombreuses applications critiques l'utilisent.

Le "0 perte" est un terme assez vague. S'il s'agit de s'assurer qu'une
transaction est bien enregistrée sur un nœud secondaire avant de rendre la main
à l'application, alors on peut s'appuyer sur la réplication synchrone.

S.

--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, support et formation
01.79.72.57.75

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

tout à fait d'accord

on peut s'appuyer sur la réplication synchrone => a condition qu'elle
ne plante pas

sortie de postgresql 9.1 (réplication synchrone) en septembre 2011 ,
soit 5 ans , de nombreuses applications critiques l'utilisent =>
quelqu'un dans cette liste a t'il suivi ça en prod ?

cordialement

Stéphane Schildknecht <stephane(dot)schildknecht(at)postgres(dot)fr> a écrit :

> On 27/05/2016 12:12, CRUMEYROLLE Pierre wrote:
>> hello
>> toujours pas de retour , test en charge ce weekend donc retour lundi
>> (wal_keep_segments = 4000)
>>
>> question replication :
>> les exigences de mon système sont 0 perte de données entre primaire et
>> secondaire :
>> a t'on un retour d'expérience sur ce type d'exigence de haute disponibilité
>> avec postgresql , car
>> d’après ce que j'ai cru comprendre la réplication par streaming est
>> relativement jeune chez postgresql ?
>>
>
> Bonjour Pierre,
>
> A l'échelle de l'humanité, effectivement, la technologie est jeune ;-)
>
> Mais le streaming, ça fait quand même quelques années que c'est en place, et
> éprouvée.
> De nombreuses applications critiques l'utilisent.
>
> Le "0 perte" est un terme assez vague. S'il s'agit de s'assurer qu'une
> transaction est bien enregistrée sur un nœud secondaire avant de
> rendre la main
> à l'application, alors on peut s'appuyer sur la réplication synchrone.
>
> S.
>
>
>
> --
> Stéphane Schildknecht
> Contact régional PostgreSQL pour l'Europe francophone
> Loxodata - Conseil, support et formation
> 01.79.72.57.75
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

2016-05-27 19:12 GMT+09:00 CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr>:
> d’après ce que j'ai cru comprendre la réplication par streaming est
> relativement jeune chez postgresql ?

La réplication par streaming est au contraire plutôt mature. Celà fait
6 ans que PostgreSQL supporte cette solution.
--
Michael

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

2016-05-27 20:40 GMT+09:00 CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr>:
> sortie de postgresql 9.1 (réplication synchrone) en septembre 2011 , soit 5
> ans , de nombreuses applications critiques l'utilisent => quelqu'un dans
> cette liste a t'il suivi ça en prod ?

Oui.
--
Michael

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

ok ça me rassure pour mon test

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> a écrit :

> 2016-05-27 19:12 GMT+09:00 CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr>:
>> d’après ce que j'ai cru comprendre la réplication par streaming est
>> relativement jeune chez postgresql ?
>
> La réplication par streaming est au contraire plutôt mature. Celà fait
> 6 ans que PostgreSQL supporte cette solution.
> --
> Michael
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

On 27/05/2016 13:40, CRUMEYROLLE Pierre wrote:
> tout à fait d'accord
>
> on peut s'appuyer sur la réplication synchrone => a condition qu'elle ne plante
> pas
>
> sortie de postgresql 9.1 (réplication synchrone) en septembre 2011 , soit 5 ans
> , de nombreuses applications critiques l'utilisent => quelqu'un dans cette
> liste a t'il suivi ça en prod ?

Tout à fait.
Je ne me serai pas permis d'avancer de tels propos sans avoir de quoi les étayer.
Je ne peux pas donner publiquement les noms de mes clients utilisant ces
fonctionnalités, mais je peux vous garantir que cela est :
- stable
- mature
- fonctionnel

Et si vous abandonnez PostgreSQL 9.1 au profit de PostgreSQL 9.5, vous
bénéficierez des dernières évolutions de la réplication.
Mais c'est un autre débat.

S.
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, support et formation
01.79.72.57.75

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

> on peut s'appuyer sur la réplication synchrone => a condition qu'elle ne
> plante pas

Alors là, je reste dubitatif. Que voulez-vous dire?

En général il y a peu d'intérêt à ce que toutes les transactions soient
répliquées de manière synchrone, et en général on met en œuvre plusieurs
serveurs secondaires pour garantir la disponibilité.

L'impact sur les performances peut être sensible et l'application doit
gérer le fait qu'elle utilise la réplication synchrone (ou pour le moins
elle doit correctement appréhender les finesses du standard SQL sur le
sujet).

Cela ne se décide pas à la légère.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

hello
rectification : à condition que le vacuum full ne la plante pas
"En général il y a peu d'intérêt à ce que toutes les transactions
soient répliquées de manière synchrone" => alors pourquoi inventer une
réplication synchrone ?
cordialement

Cédric Villemain <cedric(at)2ndquadrant(dot)com> a écrit :

>> on peut s'appuyer sur la réplication synchrone => a condition qu'elle ne
>> plante pas
>
> Alors là, je reste dubitatif. Que voulez-vous dire?
>
> En général il y a peu d'intérêt à ce que toutes les transactions soient
> répliquées de manière synchrone, et en général on met en œuvre plusieurs
> serveurs secondaires pour garantir la disponibilité.
>
> L'impact sur les performances peut être sensible et l'application doit
> gérer le fait qu'elle utilise la réplication synchrone (ou pour le moins
> elle doit correctement appréhender les finesses du standard SQL sur le
> sujet).
>
> Cela ne se décide pas à la légère.
>
> --
> Cédric Villemain +33 (0)6 20 30 22 52
> http://2ndQuadrant.fr/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 27 mai 2016 3:56 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
écrit :
>
> hello
> rectification : à condition que le vacuum full ne la plante pas

Le vacuum full n'a pas planté PostgreSQL. La mauvaise configuration de
PostgreSQL a engendré un problème au niveau de l'esclave. Ce n'est pas la
même chose :-) Notamment le maître est toujours debout.

> "En général il y a peu d'intérêt à ce que toutes les transactions soient
répliquées de manière synchrone" => alors pourquoi inventer une réplication
synchrone ?

Je suis d'accord avec Cédric que décider d'utiliser une réplication
synchrone ne se fait pas à la légère. Ce n'est utile que dans très peu de
cas, ce qui explique qu'on le voit beaucoup moins fréquemment que des
réplications asynchrones.

> cordialement
>
>
> Cédric Villemain <cedric(at)2ndquadrant(dot)com> a écrit :
>
>
>>> on peut s'appuyer sur la réplication synchrone => a condition qu'elle ne
>>> plante pas
>>
>>
>> Alors là, je reste dubitatif. Que voulez-vous dire?
>>
>> En général il y a peu d'intérêt à ce que toutes les transactions soient
>> répliquées de manière synchrone, et en général on met en œuvre plusieurs
>> serveurs secondaires pour garantir la disponibilité.
>>
>> L'impact sur les performances peut être sensible et l'application doit
>> gérer le fait qu'elle utilise la réplication synchrone (ou pour le moins
>> elle doit correctement appréhender les finesses du standard SQL sur le
>> sujet).
>>
>> Cela ne se décide pas à la légère.
>>
>> --
>> Cédric Villemain +33 (0)6 20 30 22 52
>> http://2ndQuadrant.fr/
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>
>>
>> --
>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

mon exigence est : toutes les données committées sur le serveur
primaire doivent se retrouvées sur le serveur secondaire

j'ai jamais dit que Le vacuum full avait planté PostgreSQL mais par
effet domino le vacuum full plante la réplication.

Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :

> Le 27 mai 2016 3:56 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
> écrit :
>>
>> hello
>> rectification : à condition que le vacuum full ne la plante pas
>
> Le vacuum full n'a pas planté PostgreSQL. La mauvaise configuration de
> PostgreSQL a engendré un problème au niveau de l'esclave. Ce n'est pas la
> même chose :-) Notamment le maître est toujours debout.
>
>> "En général il y a peu d'intérêt à ce que toutes les transactions soient
> répliquées de manière synchrone" => alors pourquoi inventer une réplication
> synchrone ?
>
> Je suis d'accord avec Cédric que décider d'utiliser une réplication
> synchrone ne se fait pas à la légère. Ce n'est utile que dans très peu de
> cas, ce qui explique qu'on le voit beaucoup moins fréquemment que des
> réplications asynchrones.
>
>> cordialement
>>
>>
>> Cédric Villemain <cedric(at)2ndquadrant(dot)com> a écrit :
>>
>>
>>>> on peut s'appuyer sur la réplication synchrone => a condition qu'elle ne
>>>> plante pas
>>>
>>>
>>> Alors là, je reste dubitatif. Que voulez-vous dire?
>>>
>>> En général il y a peu d'intérêt à ce que toutes les transactions soient
>>> répliquées de manière synchrone, et en général on met en œuvre plusieurs
>>> serveurs secondaires pour garantir la disponibilité.
>>>
>>> L'impact sur les performances peut être sensible et l'application doit
>>> gérer le fait qu'elle utilise la réplication synchrone (ou pour le moins
>>> elle doit correctement appréhender les finesses du standard SQL sur le
>>> sujet).
>>>
>>> Cela ne se décide pas à la légère.
>>>
>>> --
>>> Cédric Villemain +33 (0)6 20 30 22 52
>>> http://2ndQuadrant.fr/
>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>>
>>>
>>> --
>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>>
>>
>>
>>
>>
>> --
>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 27 mai 2016 4:33 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
écrit :
>
> mon exigence est : toutes les données committées sur le serveur primaire
doivent se retrouvées sur le serveur secondaire
>

Dit comme ça, une réplication asynchrone suffit. Toute donnée commitée est
envoyée à l'esclave.

> j'ai jamais dit que Le vacuum full avait planté PostgreSQL mais par
effet domino le vacuum full plante la réplication.
>

Oui, tout comme plein d'autres trucs. D'où le besoin d'un système de
supervision.

> Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>
>> Le 27 mai 2016 3:56 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr>
a
>> écrit :
>>>
>>>
>>> hello
>>> rectification : à condition que le vacuum full ne la plante pas
>>
>>
>> Le vacuum full n'a pas planté PostgreSQL. La mauvaise configuration de
>> PostgreSQL a engendré un problème au niveau de l'esclave. Ce n'est pas la
>> même chose :-) Notamment le maître est toujours debout.
>>
>>> "En général il y a peu d'intérêt à ce que toutes les transactions soient
>>
>> répliquées de manière synchrone" => alors pourquoi inventer une
réplication
>> synchrone ?
>>
>> Je suis d'accord avec Cédric que décider d'utiliser une réplication
>> synchrone ne se fait pas à la légère. Ce n'est utile que dans très peu de
>> cas, ce qui explique qu'on le voit beaucoup moins fréquemment que des
>> réplications asynchrones.
>>
>>> cordialement
>>>
>>>
>>> Cédric Villemain <cedric(at)2ndquadrant(dot)com> a écrit :
>>>
>>>
>>>>> on peut s'appuyer sur la réplication synchrone => a condition qu'elle
ne
>>>>> plante pas
>>>>
>>>>
>>>>
>>>> Alors là, je reste dubitatif. Que voulez-vous dire?
>>>>
>>>> En général il y a peu d'intérêt à ce que toutes les transactions soient
>>>> répliquées de manière synchrone, et en général on met en œuvre
plusieurs
>>>> serveurs secondaires pour garantir la disponibilité.
>>>>
>>>> L'impact sur les performances peut être sensible et l'application doit
>>>> gérer le fait qu'elle utilise la réplication synchrone (ou pour le
moins
>>>> elle doit correctement appréhender les finesses du standard SQL sur le
>>>> sujet).
>>>>
>>>> Cela ne se décide pas à la légère.
>>>>
>>>> --
>>>> Cédric Villemain +33 (0)6 20 30 22 52
>>>> http://2ndQuadrant.fr/
>>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>>>
>>>>
>>>> --
>>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

en effet tout se supervise, de plus un réseau pourri ça s'améliore, ça
se sécurise, les disques aussi, la mémoire ça se gonfle etc ...

par contre je n'ai pas trouvé comment m'affranchir du vacuum full , si
ya une solution je suis preneur.

Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :

> Le 27 mai 2016 4:33 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
> écrit :
>>
>> mon exigence est : toutes les données committées sur le serveur primaire
> doivent se retrouvées sur le serveur secondaire
>>
>
> Dit comme ça, une réplication asynchrone suffit. Toute donnée commitée est
> envoyée à l'esclave.
>
>> j'ai jamais dit que Le vacuum full avait planté PostgreSQL mais par
> effet domino le vacuum full plante la réplication.
>>
>
> Oui, tout comme plein d'autres trucs. D'où le besoin d'un système de
> supervision.
>
>> Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>>
>>> Le 27 mai 2016 3:56 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr>
> a
>>> écrit :
>>>>
>>>>
>>>> hello
>>>> rectification : à condition que le vacuum full ne la plante pas
>>>
>>>
>>> Le vacuum full n'a pas planté PostgreSQL. La mauvaise configuration de
>>> PostgreSQL a engendré un problème au niveau de l'esclave. Ce n'est pas la
>>> même chose :-) Notamment le maître est toujours debout.
>>>
>>>> "En général il y a peu d'intérêt à ce que toutes les transactions soient
>>>
>>> répliquées de manière synchrone" => alors pourquoi inventer une
> réplication
>>> synchrone ?
>>>
>>> Je suis d'accord avec Cédric que décider d'utiliser une réplication
>>> synchrone ne se fait pas à la légère. Ce n'est utile que dans très peu de
>>> cas, ce qui explique qu'on le voit beaucoup moins fréquemment que des
>>> réplications asynchrones.
>>>
>>>> cordialement
>>>>
>>>>
>>>> Cédric Villemain <cedric(at)2ndquadrant(dot)com> a écrit :
>>>>
>>>>
>>>>>> on peut s'appuyer sur la réplication synchrone => a condition qu'elle
> ne
>>>>>> plante pas
>>>>>
>>>>>
>>>>>
>>>>> Alors là, je reste dubitatif. Que voulez-vous dire?
>>>>>
>>>>> En général il y a peu d'intérêt à ce que toutes les transactions soient
>>>>> répliquées de manière synchrone, et en général on met en œuvre
> plusieurs
>>>>> serveurs secondaires pour garantir la disponibilité.
>>>>>
>>>>> L'impact sur les performances peut être sensible et l'application doit
>>>>> gérer le fait qu'elle utilise la réplication synchrone (ou pour le
> moins
>>>>> elle doit correctement appréhender les finesses du standard SQL sur le
>>>>> sujet).
>>>>>
>>>>> Cela ne se décide pas à la légère.
>>>>>
>>>>> --
>>>>> Cédric Villemain +33 (0)6 20 30 22 52
>>>>> http://2ndQuadrant.fr/
>>>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>>>>
>>>>>
>>>>> --
>>>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>>
>>
>>
>>
>>
>> --
>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

si j'en crois l'extract ci dessous
réplication synchrone => il n'y a pas de risque de perte de données
au moment d'une bascule du maître ;
réplication asynchrone =>
En cas d'arrêt brutal (crash) du serveur maître, les données peuvent
ne pas avoir été complètement synchronisées avec les serveurs
esclaves. Cela occasionne une perte de données, généralement faible
mais toujours très désagréable.

d'ou le choix réplication synchrone car perte de données au moment
d'une bascule du maître interdite

extract from
http://www.dalibo.org/glmf131_mise_en_place_replication_postgresl_9.0_1

La deuxième particularité concerne le côté synchrone ou non de la
réplication. Une réplication synchrone fonctionne de la façon suivante
: une transaction n'est pas considérée validée (pas de COMMIT) tant
que tous les serveurs n'ont pas validé cette transaction. Il y a
plusieurs intérêts à ça :

il n'y a pas de risque de perte de données au moment d'une
bascule du maître ;
le résultat d'une requête est cohérent quelque soit le serveur
interrogé dans le cadre d'un cluster en répartition de charge.

Le soucis majeur de ce type de réplication est les performances (ou
plutôt les contre-performances). En effet, il faut bien comprendre que
pour chaque transaction modifiant des données, il ne suffit pas qu'un
serveur enregistre cette information. Il faut que tous l'aient
enregistré. Cela va ajouter une surcharge plus ou moins importante
suivant la solution choisie. Des solutions asynchrones existent. Elles
sont généralement plus performantes. Le serveur qui fait l'écriture
renvoie au client le fait que l'enregistrement s'est bien passé et se
charge un peu après d'envoyer l'information sur les données modifiées
aux autres serveurs. En cas d'arrêt brutal (crash) du serveur maître,
les données peuvent ne pas avoir été complètement synchronisées avec
les serveurs esclaves. Cela occasionne une perte de données,
généralement faible mais toujours très désagréable.
CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> a écrit :

> en effet tout se supervise, de plus un réseau pourri ça s'améliore,
> ça se sécurise, les disques aussi, la mémoire ça se gonfle etc ...
>
> par contre je n'ai pas trouvé comment m'affranchir du vacuum full ,
> si ya une solution je suis preneur.
>
>
>
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>
>> Le 27 mai 2016 4:33 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
>> écrit :
>>>
>>> mon exigence est : toutes les données committées sur le serveur primaire
>> doivent se retrouvées sur le serveur secondaire
>>>
>>
>> Dit comme ça, une réplication asynchrone suffit. Toute donnée commitée est
>> envoyée à l'esclave.
>>
>>> j'ai jamais dit que Le vacuum full avait planté PostgreSQL mais par
>> effet domino le vacuum full plante la réplication.
>>>
>>
>> Oui, tout comme plein d'autres trucs. D'où le besoin d'un système de
>> supervision.
>>
>>> Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>>>
>>>> Le 27 mai 2016 3:56 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr>
>> a
>>>> écrit :
>>>>>
>>>>>
>>>>> hello
>>>>> rectification : à condition que le vacuum full ne la plante pas
>>>>
>>>>
>>>> Le vacuum full n'a pas planté PostgreSQL. La mauvaise configuration de
>>>> PostgreSQL a engendré un problème au niveau de l'esclave. Ce n'est pas la
>>>> même chose :-) Notamment le maître est toujours debout.
>>>>
>>>>> "En général il y a peu d'intérêt à ce que toutes les transactions soient
>>>>
>>>> répliquées de manière synchrone" => alors pourquoi inventer une
>> réplication
>>>> synchrone ?
>>>>
>>>> Je suis d'accord avec Cédric que décider d'utiliser une réplication
>>>> synchrone ne se fait pas à la légère. Ce n'est utile que dans très peu de
>>>> cas, ce qui explique qu'on le voit beaucoup moins fréquemment que des
>>>> réplications asynchrones.
>>>>
>>>>> cordialement
>>>>>
>>>>>
>>>>> Cédric Villemain <cedric(at)2ndquadrant(dot)com> a écrit :
>>>>>
>>>>>
>>>>>>> on peut s'appuyer sur la réplication synchrone => a condition qu'elle
>> ne
>>>>>>> plante pas
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alors là, je reste dubitatif. Que voulez-vous dire?
>>>>>>
>>>>>> En général il y a peu d'intérêt à ce que toutes les transactions soient
>>>>>> répliquées de manière synchrone, et en général on met en œuvre
>> plusieurs
>>>>>> serveurs secondaires pour garantir la disponibilité.
>>>>>>
>>>>>> L'impact sur les performances peut être sensible et l'application doit
>>>>>> gérer le fait qu'elle utilise la réplication synchrone (ou pour le
>> moins
>>>>>> elle doit correctement appréhender les finesses du standard SQL sur le
>>>>>> sujet).
>>>>>>
>>>>>> Cela ne se décide pas à la légère.
>>>>>>
>>>>>> --
>>>>>> Cédric Villemain +33 (0)6 20 30 22 52
>>>>>> http://2ndQuadrant.fr/
>>>>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 27 mai 2016 4:50 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
écrit :
>
>
>
> en effet tout se supervise, de plus un réseau pourri ça s'améliore, ça se
sécurise, les disques aussi, la mémoire ça se gonfle etc ...
>
> par contre je n'ai pas trouvé comment m'affranchir du vacuum full , si ya
une solution je suis preneur.
>

Il faut que la table soit nettoyée suffisamment fréquemment avec un vacuum
standard pour ne pas avoir besoin du full.

Avec certaines activités, ce n'est pas suffisant malheureusement.

>
>
>
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>
>> Le 27 mai 2016 4:33 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr>
a
>>
>> écrit :
>>>
>>>
>>> mon exigence est : toutes les données committées sur le serveur primaire
>>
>> doivent se retrouvées sur le serveur secondaire
>>>
>>>
>>
>> Dit comme ça, une réplication asynchrone suffit. Toute donnée commitée
est
>> envoyée à l'esclave.
>>
>>> j'ai jamais dit que Le vacuum full avait planté PostgreSQL mais par
>>
>> effet domino le vacuum full plante la réplication.
>>>
>>>
>>
>> Oui, tout comme plein d'autres trucs. D'où le besoin d'un système de
>> supervision.
>>
>>> Guillaume Lelarge <guillaume(at)lelarge(dot)info> a écrit :
>>>
>>>> Le 27 mai 2016 3:56 PM, "CRUMEYROLLE Pierre" <pierre(dot)crumeyrolle(at)c-s(dot)fr
>
>>
>> a
>>>>
>>>> écrit :
>>>>>
>>>>>
>>>>>
>>>>> hello
>>>>> rectification : à condition que le vacuum full ne la plante pas
>>>>
>>>>
>>>>
>>>> Le vacuum full n'a pas planté PostgreSQL. La mauvaise configuration de
>>>> PostgreSQL a engendré un problème au niveau de l'esclave. Ce n'est pas
la
>>>> même chose :-) Notamment le maître est toujours debout.
>>>>
>>>>> "En général il y a peu d'intérêt à ce que toutes les transactions
soient
>>>>
>>>>
>>>> répliquées de manière synchrone" => alors pourquoi inventer une
>>
>> réplication
>>>>
>>>> synchrone ?
>>>>
>>>> Je suis d'accord avec Cédric que décider d'utiliser une réplication
>>>> synchrone ne se fait pas à la légère. Ce n'est utile que dans très peu
de
>>>> cas, ce qui explique qu'on le voit beaucoup moins fréquemment que des
>>>> réplications asynchrones.
>>>>
>>>>> cordialement
>>>>>
>>>>>
>>>>> Cédric Villemain <cedric(at)2ndquadrant(dot)com> a écrit :
>>>>>
>>>>>
>>>>>>> on peut s'appuyer sur la réplication synchrone => a condition
qu'elle
>>
>> ne
>>>>>>>
>>>>>>> plante pas
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alors là, je reste dubitatif. Que voulez-vous dire?
>>>>>>
>>>>>> En général il y a peu d'intérêt à ce que toutes les transactions
soient
>>>>>> répliquées de manière synchrone, et en général on met en œuvre
>>
>> plusieurs
>>>>>>
>>>>>> serveurs secondaires pour garantir la disponibilité.
>>>>>>
>>>>>> L'impact sur les performances peut être sensible et l'application
doit
>>>>>> gérer le fait qu'elle utilise la réplication synchrone (ou pour le
>>
>> moins
>>>>>>
>>>>>> elle doit correctement appréhender les finesses du standard SQL sur
le
>>>>>> sujet).
>>>>>>
>>>>>> Cela ne se décide pas à la légère.
>>>>>>
>>>>>> --
>>>>>> Cédric Villemain +33 (0)6 20 30 22 52
>>>>>> http://2ndQuadrant.fr/
>>>>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Envoi via la liste pgsql-fr-generale (
pgsql-fr-generale(at)postgresql(dot)org)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org
)
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>
>
>
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Guillaume

CRUMEYROLLE Pierre wrote:

> La deuxième particularité concerne le côté synchrone ou non de la
> réplication. Une réplication synchrone fonctionne de la façon suivante
> : une transaction n'est pas considérée validée (pas de COMMIT) tant
> que tous les serveurs n'ont pas validé cette transaction. Il y a
> plusieurs intérêts à ça :
>
> il n'y a pas de risque de perte de données au moment d'une
> bascule du maître ;
> le résultat d'une requête est cohérent quelque soit le serveur
> interrogé dans le cadre d'un cluster en répartition de charge.

Sur le dernier point, non il n'y pas de cohérence systématique,
c'est d'ailleurs une nouveauté de la 9.6 actuellement en beta:
synchronous_commit = 'remote_apply'

Voir (en anglais):
/docs/9.6/static/runtime-config-wal.html

ainsi que:
http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-remote-apply/

Cordialement,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 27 mai 2016 6:04 PM, "Daniel Verite" <daniel(at)manitou-mail(dot)org> a écrit :
>
> CRUMEYROLLE Pierre wrote:
>
> > La deuxième particularité concerne le côté synchrone ou non de la
> > réplication. Une réplication synchrone fonctionne de la façon suivante
> > : une transaction n'est pas considérée validée (pas de COMMIT) tant
> > que tous les serveurs n'ont pas validé cette transaction. Il y a
> > plusieurs intérêts à ça :
> >
> > il n'y a pas de risque de perte de données au moment d'une
> > bascule du maître ;
> > le résultat d'une requête est cohérent quelque soit le serveur
> > interrogé dans le cadre d'un cluster en répartition de charge.
>
> Sur le dernier point, non il n'y pas de cohérence systématique,
> c'est d'ailleurs une nouveauté de la 9.6 actuellement en beta:
> synchronous_commit = 'remote_apply'
>
> Voir (en anglais):
> /docs/9.6/static/runtime-config-wal.html
>
> ainsi que:
>
http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-remote-apply/
>

Ce n'est malheureusement pas la seule erreur dans cet article. Dans le cas
d'une réplication synchrone, même si on a configuré plusieurs serveurs
synchrones, le maître n'attend que la réponse du premier (et non pas de
tous comme je le dis dans l'article).

2016-05-28 2:20 GMT+09:00 Guillaume Lelarge <guillaume(at)lelarge(dot)info>:
> Le 27 mai 2016 6:04 PM, "Daniel Verite" <daniel(at)manitou-mail(dot)org> a écrit :
>> Sur le dernier point, non il n'y pas de cohérence systématique,
>> c'est d'ailleurs une nouveauté de la 9.6 actuellement en beta:
>> synchronous_commit = 'remote_apply'
>>
>> Voir (en anglais):
>> /docs/9.6/static/runtime-config-wal.html
>>
>> ainsi que:
>>
>> http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-remote-apply/
>>
>
> Ce n'est malheureusement pas la seule erreur dans cet article. Dans le cas
> d'une réplication synchrone, même si on a configuré plusieurs serveurs
> synchrones, le maître n'attend que la réponse du premier (et non pas de tous
> comme je le dis dans l'article).

Avec synchrounous_standby_names = 'N (standby1, standby2 ...
standbyM)', il me semblait que l'on attendait le message de
confirmation des N premiers esclaves listés ici. Sinon quel est
l'intérêt de pouvoir en utiliser plusieurs? On doit être sûr que le
WAL de la transaction est présente dans ces N esclaves selon
synchronous_commit bien sûr. Y a-t-il des erreurs dans des
formulations de cet article?
--
Michael

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 28 mai 2016 à 00:44, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> a écrit
:

> 2016-05-28 2:20 GMT+09:00 Guillaume Lelarge <guillaume(at)lelarge(dot)info>:
> > Le 27 mai 2016 6:04 PM, "Daniel Verite" <daniel(at)manitou-mail(dot)org> a
> écrit :
> >> Sur le dernier point, non il n'y pas de cohérence systématique,
> >> c'est d'ailleurs une nouveauté de la 9.6 actuellement en beta:
> >> synchronous_commit = 'remote_apply'
> >>
> >> Voir (en anglais):
> >> /docs/9.6/static/runtime-config-wal.html
> >>
> >> ainsi que:
> >>
> >>
> http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-remote-apply/
> >>
> >
> > Ce n'est malheureusement pas la seule erreur dans cet article. Dans le
> cas
> > d'une réplication synchrone, même si on a configuré plusieurs serveurs
> > synchrones, le maître n'attend que la réponse du premier (et non pas de
> tous
> > comme je le dis dans l'article).
>
> Avec synchrounous_standby_names = 'N (standby1, standby2 ...
> standbyM)', il me semblait que l'on attendait le message de
> confirmation des N premiers esclaves listés ici. Sinon quel est
> l'intérêt de pouvoir en utiliser plusieurs? On doit être sûr que le
> WAL de la transaction est présente dans ces N esclaves selon
> synchronous_commit bien sûr. Y a-t-il des erreurs dans des
> formulations de cet article?
>

Ah mince, je comprends le problème. Je ne parlais pas de ton article mais
du mien :), dont le lien a été donné plus haut dans la discussion (
http://www.dalibo.org/glmf131_mise_en_place_replication_postgresl_9.0_1)
qui parle de la 9.0. Et je me rend compte en disant cela que, du coup, je
ne couvrais pas la réplication synchrone telle qu'implémentée dans
PostgreSQL, vu que cette dernière n'apparaît qu'en 9.1. Et du coup, c'est
moins gênant comme "erreur". Je vais me coucher un peu mieux ce soir du
coup :-)

--
Guillaume.
http://blog.guillaume.lelarge.info
http://www.dalibo.com

Bonjour à tous,

Avant de commencer ma réponse, point vocabulaire : dans l'écosystème
PostgreSQL nous avons choisi d'arrêter les références directes à des
périodes historiques sombres et nous parlons de serveurs primaires et
secondaires (primary et standby en anglais), ou bien de réplica.

De plus, je n'ai jamais entendu d'histoire dans laquelle la défaillance
d'un maître aurait pour conséquence l'élection d'un esclave afin de le
remplacer.

À la rigueur, nous pourrions parler de Reine et de Princesse : nous
savons tous que le rôle de la Princesse est de prendre le relais de la
Reine le jour venu.

CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> writes:
>> par contre je n'ai pas trouvé comment m'affranchir du vacuum full , si ya
>> une solution je suis preneur.

Avec une version moderne de PostgreSQL et une configuration correcte de
l'autovacuum, les cas où le VACUUM FULL sont nécessaires sont supposés
être extrêmement rare. En effet, il s'agit d'une réécriture complète des
données et des indexes sur disque. Lire avec soin la documentation :

/docs/9.1/static/routine-vacuuming.html

> si j'en crois l'extract ci dessous
> réplication synchrone => il n'y a pas de risque de perte de données au
> moment d'une bascule du maître ;

Ceci est un mythe : il y a *toujours* un risque de perte de données au
moment d'une bascule du primaire. Pour éviter ce risque il est possible
(très rarement souhaitable, cependant) d'implémenter le Two-Phase
Commit, beaucoup plus lourd mais qui offre de meilleures garanties.
Revenons à nos moutons.

Prenons pour comprendre le cas simple d'un serveur PostgreSQL unique. Le
standard SQL requière l'implémentation des transactions via les
commandes START TRANSACTION, COMMIT et ROLLBACK.

Lorsque l'application envoie une demande de COMMIT de la transaction en
cours, il s'agit d'une demande. Deux réponses sont alors possibles de la
part du serveur : COMMIT si tout c'est bien passé, ROLLBACK sinon.

Voyons cela avec un exemple très facile à reproduire, puisqu'il suffit
de provoquer n'importe quelle erreur au sein de la transaction afin de
constater un échange COMMIT/ROLLBACK :

pgloader# \set ON_ERROR_ROLLBACK off
pgloader# begin;
BEGIN
pgloader*# select 1/0;
ERROR: 22012: division by zero
pgloader*# commit;
ROLLBACK

Dans un environnement de production on peut s'attendre à observer ce
genre de scénario le plus souvent lors du fameux « no space left on
device ».

Maintenant que nous comprenons mieux le protocole de validation d'une
transaction, reprenons le sujet du risque de pertes de données au moment
d'une bascule.

Le fonctionnement de la réplication PostgreSQL permet de choisir un
comportement soit synchrone soit asynchrone dans chaque transaction de
manière indépendante.

- en mode asynchrone le serveur primaire réalise le COMMIT et répond
dès que possible le message de succès au client ;

- en cas d'échec de COMMIT de la transaction, le message ROLLBACK est
systématiquement renvoyé directement au client ;

- en mode synchrone le serveur primaire réalise le COMMIT en local
puis attend un retour positif de la part d'au moins un serveur
secondaire avant de répondre au client.

Dans la version PostgreSQL 9.6 il est possible de mettre en place un
Quorum et de faire attendre le retour de plusieurs serveurs secondaires
avant de répondre au client.

Ce qui doit être très clair est le point suivant : avec un seul serveur
PostgreSQL déjà, l'application doit être consciente qu'il ne suffit pas
d'envoyer un message COMMIT pour sécuriser son activité, il faut valider
que le retour de ce message est également un COMMIT.

Si jamais le serveur PostgreSQL unique venait à planter sournoisement
après l'envoi du message COMMIT mais *avant* d'avoir pu y répondre,
alors il est *imposible* pour l'application de savoir si sa transaction
est sécurisée sur le serveur ou bien perdue à tout jamais.

Ce scénario d'incertitude existe déjà avec un simple serveur SQL,
et quelque soit le moteur utilisé car cela vient de l'architecture
client / serveur et du protocole utilisé et défini par le standard.

Maintenant, dans le cas d'une réplication synchrone et dans le scénario
où l'on choisit de basculer vers le serveur secondaire, la même
incertitude existe : il reste possible que l'application ait envoyé un
ou plusieurs messages COMMIT pour lesquels elle n'a pas reçu de retour.
Peut être que le travail de sécurisation des données de la transaction
n'est pas terminé sur le primaire, ou bien peut être que le primaire a
pu faire son travail et attend maintenant un retour du secondaire.
Lequel a peut être terminé d'enregistrer les données mais n'a pas eu le
temps d'en faire un retour au primaire au moment de la bascule. Ou bien
peut être même que le message de retour est parti mais pas encore reçu,
soit par le primaire, soit relayé par le primaire mais pas encore reçu
par l'application.

Ou bien plus simplement, peut être que le COMMIT a eu lieu sur le
primaire mais que les données ne sont pas encore arrivées sur le
secondaire, ou bien que le secondaire n'a pas encore eu le temps de les
sécuriser au moment de la bascule.

Il n'y a pas de magie, des électrons sont attendus qui se déplacent au
mieux à la vitesse de la lumière. La capacité de traitement de ces
électrons est relativement limitée.

Il y a *toujours* un risque de perte de données au moment d'une bascule
du primaire vers un secondaire, que la réplication soit synchrone ou
asynchrone.

Bien à vous,
--
dim

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Ok merci pour ce précisions

c'est quoi une version moderne de PostgreSQL ?

c'est quoi une configuration correcte de l'autovacuum ?

Dimitri Fontaine <dim(at)tapoueh(dot)org> a écrit :

> Bonjour à tous,
>
> Avant de commencer ma réponse, point vocabulaire : dans l'écosystème
> PostgreSQL nous avons choisi d'arrêter les références directes à des
> périodes historiques sombres et nous parlons de serveurs primaires et
> secondaires (primary et standby en anglais), ou bien de réplica.
>
> De plus, je n'ai jamais entendu d'histoire dans laquelle la défaillance
> d'un maître aurait pour conséquence l'élection d'un esclave afin de le
> remplacer.
>
> À la rigueur, nous pourrions parler de Reine et de Princesse : nous
> savons tous que le rôle de la Princesse est de prendre le relais de la
> Reine le jour venu.
>
>
> CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> writes:
>>> par contre je n'ai pas trouvé comment m'affranchir du vacuum full , si ya
>>> une solution je suis preneur.
>
> Avec une version moderne de PostgreSQL et une configuration correcte de
> l'autovacuum, les cas où le VACUUM FULL sont nécessaires sont supposés
> être extrêmement rare. En effet, il s'agit d'une réécriture complète des
> données et des indexes sur disque. Lire avec soin la documentation :
>
> /docs/9.1/static/routine-vacuuming.html
>
>> si j'en crois l'extract ci dessous
>> réplication synchrone => il n'y a pas de risque de perte de données au
>> moment d'une bascule du maître ;
>
> Ceci est un mythe : il y a *toujours* un risque de perte de données au
> moment d'une bascule du primaire. Pour éviter ce risque il est possible
> (très rarement souhaitable, cependant) d'implémenter le Two-Phase
> Commit, beaucoup plus lourd mais qui offre de meilleures garanties.
> Revenons à nos moutons.
>
>
> Prenons pour comprendre le cas simple d'un serveur PostgreSQL unique. Le
> standard SQL requière l'implémentation des transactions via les
> commandes START TRANSACTION, COMMIT et ROLLBACK.
>
> Lorsque l'application envoie une demande de COMMIT de la transaction en
> cours, il s'agit d'une demande. Deux réponses sont alors possibles de la
> part du serveur : COMMIT si tout c'est bien passé, ROLLBACK sinon.
>
> Voyons cela avec un exemple très facile à reproduire, puisqu'il suffit
> de provoquer n'importe quelle erreur au sein de la transaction afin de
> constater un échange COMMIT/ROLLBACK :
>
> pgloader# \set ON_ERROR_ROLLBACK off
> pgloader# begin;
> BEGIN
> pgloader*# select 1/0;
> ERROR: 22012: division by zero
> pgloader*# commit;
> ROLLBACK
>
> Dans un environnement de production on peut s'attendre à observer ce
> genre de scénario le plus souvent lors du fameux « no space left on
> device ».
>
> Maintenant que nous comprenons mieux le protocole de validation d'une
> transaction, reprenons le sujet du risque de pertes de données au moment
> d'une bascule.
>
> Le fonctionnement de la réplication PostgreSQL permet de choisir un
> comportement soit synchrone soit asynchrone dans chaque transaction de
> manière indépendante.
>
> - en mode asynchrone le serveur primaire réalise le COMMIT et répond
> dès que possible le message de succès au client ;
>
> - en cas d'échec de COMMIT de la transaction, le message ROLLBACK est
> systématiquement renvoyé directement au client ;
>
> - en mode synchrone le serveur primaire réalise le COMMIT en local
> puis attend un retour positif de la part d'au moins un serveur
> secondaire avant de répondre au client.
>
> Dans la version PostgreSQL 9.6 il est possible de mettre en place un
> Quorum et de faire attendre le retour de plusieurs serveurs secondaires
> avant de répondre au client.
>
>
> Ce qui doit être très clair est le point suivant : avec un seul serveur
> PostgreSQL déjà, l'application doit être consciente qu'il ne suffit pas
> d'envoyer un message COMMIT pour sécuriser son activité, il faut valider
> que le retour de ce message est également un COMMIT.
>
> Si jamais le serveur PostgreSQL unique venait à planter sournoisement
> après l'envoi du message COMMIT mais *avant* d'avoir pu y répondre,
> alors il est *imposible* pour l'application de savoir si sa transaction
> est sécurisée sur le serveur ou bien perdue à tout jamais.
>
> Ce scénario d'incertitude existe déjà avec un simple serveur SQL,
> et quelque soit le moteur utilisé car cela vient de l'architecture
> client / serveur et du protocole utilisé et défini par le standard.
>
> Maintenant, dans le cas d'une réplication synchrone et dans le scénario
> où l'on choisit de basculer vers le serveur secondaire, la même
> incertitude existe : il reste possible que l'application ait envoyé un
> ou plusieurs messages COMMIT pour lesquels elle n'a pas reçu de retour.
> Peut être que le travail de sécurisation des données de la transaction
> n'est pas terminé sur le primaire, ou bien peut être que le primaire a
> pu faire son travail et attend maintenant un retour du secondaire.
> Lequel a peut être terminé d'enregistrer les données mais n'a pas eu le
> temps d'en faire un retour au primaire au moment de la bascule. Ou bien
> peut être même que le message de retour est parti mais pas encore reçu,
> soit par le primaire, soit relayé par le primaire mais pas encore reçu
> par l'application.
>
> Ou bien plus simplement, peut être que le COMMIT a eu lieu sur le
> primaire mais que les données ne sont pas encore arrivées sur le
> secondaire, ou bien que le secondaire n'a pas encore eu le temps de les
> sécuriser au moment de la bascule.
>
>
> Il n'y a pas de magie, des électrons sont attendus qui se déplacent au
> mieux à la vitesse de la lumière. La capacité de traitement de ces
> électrons est relativement limitée.
>
>
> Il y a *toujours* un risque de perte de données au moment d'une bascule
> du primaire vers un secondaire, que la réplication soit synchrone ou
> asynchrone.
>
>
> Bien à vous,
> --
> dim

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> writes:
> c'est quoi une version moderne de PostgreSQL ?

Je dirais 9.4 ou 9.5, cf le tableau suivant :

/support/versioning/

> c'est quoi une configuration correcte de l'autovacuum ?

Ma règle au doigt mouillé est d'assigner autant de CPU que disponible
tout en validant qu'il reste de la bande passante I/O. Le nombre de CPU
sera assigné à autovacuum_max_workers et on règle ensuite les seuils de
déclenchement de manière à ce que tous les workers soient toujours
actifs.

L'image que j'aime avoir du travail de l'autovacuum est celui des
balayeurs au Curling…

--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

hello

comme convenu voila le test de charge effectué ce weekend streaming
replication + vacuum full
le status est successfull => 85 935 381 ligne d’historiques passé
avec un vacuum full OK

application patch postgresql + montée du paramètre wal_keep_segments = 4000

conclusion le wal_keep_segments améliore grandement les choses

mise en observation du processus sur une période plus longue

merci à tous pour vos retours

cordialement

Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> a écrit :

> CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> writes:
>> c'est quoi une version moderne de PostgreSQL ?
>
> Je dirais 9.4 ou 9.5, cf le tableau suivant :
>
> /support/versioning/
>
>> c'est quoi une configuration correcte de l'autovacuum ?
>
> Ma règle au doigt mouillé est d'assigner autant de CPU que disponible
> tout en validant qu'il reste de la bande passante I/O. Le nombre de CPU
> sera assigné à autovacuum_max_workers et on règle ensuite les seuils de
> déclenchement de manière à ce que tous les workers soient toujours
> actifs.
>
> L'image que j'aime avoir du travail de l'autovacuum est celui des
> balayeurs au Curling…
>
> --
> Dimitri Fontaine
> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

On 29/05/2016 14:10, Dimitri Fontaine wrote:
> Il n'y a pas de magie, des électrons sont attendus qui se déplacent au
> mieux à la vitesse de la lumière. La capacité de traitement de ces
> électrons est relativement limitée.

Je me permet de rejoindre cette constructive conversation qui est arrivé
sur mon domaine de base, malheureusement une très diffusée idée fausse.

Je risque de décevoir Dimitri parce que, en effet, les électrons ne sont
pas si rapides que ça. Très loin de la vitesse de la lumière, ils se
déplacent a une vitesse dépendent du courant électrique sur un
conducteur, et seulement si on parle de courant continu.

Sur un conducteur en cuivre, pour le courant de 1A (les signales de
transmission de données sont beaucoup plus faibles que ça), un électron
se déplace à la vitesse d'exténuants... 40 cm/h

Bon, du coup on peut dire que c'est faisable une course entre un
électron et une tortue, et la tortue a des bonnes chances de gagner.

Si on parle de courant alterné, ce qui est le cas de toute la
distribution d'énergie électrique dans nos foyers, ainsi que toute la
transmission de signales numériques, les électrons ne se déplacent même
pas. En fait, ils font un mouvement de va-et-vient et, si on supprime le
signal électrique, les électrons du conducteur vont se trouver
exactement sur la même place qu'ils étaient avant de mettre le signal.

Comment les signales si diffusent très vite sur un conducteur en cuivre
alors ?

C'est simple, un électron saute vers l'atome suivant, qui doit garder sa
charge neutre et, du coup, fait sauter un électron vers un autre atome,
et ainsi de suite, du bout au bout du conducteur.

C'est plus au moins comme un FIFO d'électrons :) , on rajoute un
électron sur un bout et un autre sort à l'autre bout. C'est pour ça qui
on donne le nom "courant", une chaîne d'électrons se déplace, jamais un
électron isolé.

Conclusion, on ne doit pas penser en vitesse de l'électron, mais en
vitesse de déplacement des signaux électriques. Celle ci est proche de
la vitesse de la lumière.

Pour les plus intéressés en savoir comment tout ça se calcule, je vous
laisse des liens wikipedia :

https://fr.wikipedia.org/wiki/Vitesse_de_l%27%C3%A9lectricit%C3%A9

Ah ! Il faut dire que les électrons en fait ne sont jamais en repos. Il
bougent même s'il n'y a pas de signal, ils s'arrêtent seulement au zéro
absolut :

https://fr.wikipedia.org/wiki/Vitesse_de_d%C3%A9rive_(%C3%A9lectricit%C3%A9)

Voilà un petit retour aux cours de physique, désolé l'off-topic, je ne
suis pas fan des idées fausses.
Flavio

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Flavio Henrique Araque Gurgel <fhagur(at)gmail(dot)com> writes:
> On 29/05/2016 14:10, Dimitri Fontaine wrote:
>> Il n'y a pas de magie, des électrons sont attendus qui se déplacent au
>> mieux à la vitesse de la lumière. La capacité de traitement de ces
>> électrons est relativement limitée.

[...]

> Conclusion, on ne doit pas penser en vitesse de l'électron, mais en
> vitesse de déplacement des signaux électriques. Celle ci est proche de
> la vitesse de la lumière.

Merci Flavio ! Comme quoi on en apprend tous les jours ;-)

--
dim

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)