Re: vacuum full et hot standby WAL stream: FATAL

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 <[email protected]> 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 <[email protected]> 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 :
>
>   https://www.postgresql.org/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 ([email protected])