Plus de checkpoint

Version imprimable

07/12/2019, 23h24
jeff1974

Plus de checkpoint

Bonjour,

J'ai une base qui tourne sous PostgreSQL 9.6 / Ubuntu 12.04 (volumétrie ~ 80Go)

Voilà quelques jours, le filesystem a été saturé par l'archivage des fichiers WAL... je sais c'est ballot mais c'est conçu ainsi.
De la place a pu être libérée et la base a repris son fonctionnement sans qu'aucune relance de service n'ait été nécessaire.

Toutefois, j'ai depuis constaté que le dossier pg_xlog ne se vidait plus.
Plus de sauvegarde non plus (basée sur amanda), le pg_start_backup() n'aboutit jamais.

En fait, il n'y a plus aucun checkpoint qui passe sur la base et un pg_control indique que le dernier date du moment de la saturation disque.
Lancée manuellement, la commande ne rend jamais la main.

N'ayant pas trouvé secours auprès de mes DBA j'espère que la communauté pourra m'aider.
La base étant répliquée, la solution ultime restera la bascule (si elle ne fait pas de checkpoint) et la reconstruction du moteur par pg_basebackup

Salutations.
JF

Pour info complémentaire, ce que retourne un strace du process checkpointer lors d'un CHECKPOINT

Code:

1
2
3
4
5
6
semop(3014694, {{4, -1, 0}}, 1
 
 
)         = -1 EINTR (Interrupted system call)
--- SIGINT (Interrupt) @ 0 (0) ---
rt_sigreturn(0x7fb272979904)            = -1 EINTR (Interrupted system call)

Un strace d'un checkpoint sur un moteur fonctionnel :|

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
epoll_wait(6,
 
7f99e19a1160, 1, 37688)   = -1 EINTR (Interrupted system call)
--- SIGINT (Interrupt) @ 0 (0) ---
write(12, "\0", 1)                      = 1
rt_sigreturn(0xc)                       = -1 EINTR (Interrupted system call)
close(6)                                = 0
write(2, "2019-12-11 09:34:07 GMT @ () [58"..., 85) = 85
open("pg_replslot/base_backup_slot/state.tmp", O_WRONLY|O_CREAT|O_EXCL, 0600) = 6
write(6, "\241\34\5\1G\315\361\r\2\0\0\0\240\0\0\0base_backup_slot"..., 176) = 176
fsync(6)                                = 0
close(6)                                = 0
rename("pg_replslot/base_backup_slot/state.tmp", "pg_replslot/base_backup_slot/state") = 0
open("pg_replslot/base_backup_slot/state", O_RDWR) = 6
fsync(6)                                = 0
close(6)                                = 0
open("pg_replslot/base_backup_slot", O_RDONLY) = 6
fsync(6)                                = 0
close(6)                                = 0
open("pg_replslot", O_RDONLY)           = 6
fsync(6)                                = 0
close(6)                                = 0
openat(AT_FDCWD, "pg_logical/snapshots", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
getdents(6, /* 2 entries */, 32768)     = 48
getdents(6, /* 0 entries */, 32768)     = 0
close(6)                                = 0
openat(AT_FDCWD, "pg_logical/mappings", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
getdents(6, /* 2 entries */, 32768)     = 48
getdents(6, /* 0 entries */, 32768)     = 0
close(6)                                = 0
unlink("pg_logical/replorigin_checkpoint.tmp") = -1 ENOENT (No such file or directory)
open("pg_logical/replorigin_checkpoint.tmp", O_WRONLY|O_CREAT|O_EXCL, 0600) = 6
write(6, "\336\332W\22", 4)             = 4
write(6, "6\262\0j", 4)                 = 4
close(6)                                = 0
open("pg_logical/replorigin_checkpoint.tmp", O_RDWR) = 6
fsync(6)                                = 0
close(6)                                = 0
open("pg_logical/replorigin_checkpoint", O_RDWR) = 6
fsync(6)                                = 0
close(6)                                = 0
rename("pg_logical/replorigin_checkpoint.tmp", "pg_logical/replorigin_checkpoint") = 0
open("pg_logical/replorigin_checkpoint", O_RDWR) = 6
fsync(6)                                = 0
close(6)                                = 0
open("pg_logical", O_RDONLY)            = 6
...

03/01/2020, 00h19
jeff1974

Bien que ce soit certainement sans mauvaises intentions, je n'ai pas pu faire avouer, je pense qu'un lutin a fait planter le moteur en tuant le process checkpointer !
Le process père a résisté et tous les process fils ont été recyclés..

Magie de l'ambiance de Noël, checkpoint et sauvegardes refonctionnent.
Le dossier pg_xlog a repris un cycle de vie et de purge normal.

Je n'ai eu aucun écho d'un dysfonctionnement de l'application ou même d'incohérences de données.
J'ai contrôlé la réplication et elle était toujours fonctionnelles.

Je rechercherai s'il s'agit bien d'une action humaine ou finalement d'une véritable défaillance du moteur telle qu'elle aurait pu/dû de produire initialement.

EDIT : Après quelques jours de congés, première chose regardé à ma reprise et j'ai la réponse... action humaine "in"volontaire avec un beau kill du process retrouvé dans l'historique des commandes.
Depuis, le moteur ne semble pas avoir bronché.