Re: vacuum full et hot standby WAL stream: FATAL

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 :

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 (pgsql-fr-generale(at)postgresql(dot)org)