Re: could not read block 0 in file "base/mydb/myfile": read only 0 of 8192 bytes

Bonjour,

Je vous expose mon cas, j'ai deux serveurs postgresql (9.5) en mode
streaming replication avec deux pgpool (un sur chaque host pour la
redondance).

Un incident sur le serveur master à lancé un trigger (basé sur ma
configuration) pour promouvoir le slave (et pgpool) en nouveau master.

L'ancien master est actuellement inactif en attendant de le resynchroniser.

Comme l'indique l'objet de mon mail, j'ai depuis la bascule cette erreur
(en grand nombre) dans les logs pgpool depuis le démarrage du nouveau
master.

Le fichier sur le master actuel a une taille nulle alors que sur
l'ancien master, il est d'environ 500M.

C'est la première fois que je tombe sur ce cas là, avez-vous une idée de
comment résoudre ce cas ?

Cordialement.

--

Le 31 mai 2016 4:38 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com> a écrit :
>
> Bonjour,
>
> Je vous expose mon cas, j'ai deux serveurs postgresql (9.5) en mode
streaming replication avec deux pgpool (un sur chaque host pour la
redondance).
>
> Un incident sur le serveur master à lancé un trigger (basé sur ma
configuration) pour promouvoir le slave (et pgpool) en nouveau master.
>
> L'ancien master est actuellement inactif en attendant de le
resynchroniser.
>
> Comme l'indique l'objet de mon mail, j'ai depuis la bascule cette erreur
(en grand nombre) dans les logs pgpool depuis le démarrage du nouveau
master.
>
> Le fichier sur le master actuel a une taille nulle alors que sur l'ancien
master, il est d'environ 500M.
>
> C'est la première fois que je tombe sur ce cas là, avez-vous une idée de
comment résoudre ce cas ?
>

De quel fichier parle-t-il ? Attendez-vous à devoir faire une reprise de
sauvegarde.

Le 31 mai 2016 4:48 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com> a écrit :
>
> Bonjour Guillaume,
>
> Merci pour votre retour.
>

Merci de laisser la liste en copie. Merci aussi de ne pas top-poster.

> Qu'entendez par quel fichier ? je peux interroger via la requête suivante
d’après mes recherches, en me plaçant sur ma base et en lançant :
>
> select * from pg_class where oid = {id présent dans mes logs};
>

Le message d'erreur n'indique certainement pas myfile. Vous pouvez avoir un
nombre, avec ou sans extension. C'est cela qui m'intéresse. Suivant
l'extension, c'est plus ou moins grave.

Ceci étant dit, encore une fois, il y a de fortes chances que la résolution
de votre problème passe par la restauration d'une sauvegarde.

--
Guillaume
http://www.dalibo.com

> Cordialement.
>
> Le 31/05/2016 16:43, Guillaume Lelarge a écrit :
>>
>> Le 31 mai 2016 4:38 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com> a écrit :
>> >
>> > Bonjour,
>> >
>> > Je vous expose mon cas, j'ai deux serveurs postgresql (9.5) en mode
streaming replication avec deux pgpool (un sur chaque host pour la
redondance).
>> >
>> > Un incident sur le serveur master à lancé un trigger (basé sur ma
configuration) pour promouvoir le slave (et pgpool) en nouveau master.
>> >
>> > L'ancien master est actuellement inactif en attendant de le
resynchroniser.
>> >
>> > Comme l'indique l'objet de mon mail, j'ai depuis la bascule cette
erreur (en grand nombre) dans les logs pgpool depuis le démarrage du
nouveau master.
>> >
>> > Le fichier sur le master actuel a une taille nulle alors que sur
l'ancien master, il est d'environ 500M.
>> >
>> > C'est la première fois que je tombe sur ce cas là, avez-vous une idée
de comment résoudre ce cas ?
>> >
>>
>> De quel fichier parle-t-il ? Attendez-vous à devoir faire une reprise de
sauvegarde.
>
>
> --

Le 31/05/2016 16:59, Guillaume Lelarge a écrit :
>
> Le 31 mai 2016 4:48 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com
> <mailto:mjoigny(at)neteven(dot)com>> a écrit :
> >
> > Bonjour Guillaume,
> >
> > Merci pour votre retour.
> >
>
> Merci de laisser la liste en copie. Merci aussi de ne pas top-poster.
>
> > Qu'entendez par quel fichier ? je peux interroger via la requête
> suivante d’après mes recherches, en me plaçant sur ma base et en lançant :
> >
> > select * from pg_class where oid = {id présent dans mes logs};
> >
>
> Le message d'erreur n'indique certainement pas myfile. Vous pouvez
> avoir un nombre, avec ou sans extension. C'est cela qui m'intéresse.
> Suivant l'extension, c'est plus ou moins grave.
>
Voici le message exact : could not read block 0 in file
"base/16583/12119463": read only 0 of 8192 bytes
>
> Ceci étant dit, encore une fois, il y a de fortes chances que la
> résolution de votre problème passe par la restauration d'une sauvegarde.
>
> --
> Guillaume
> http://www.dalibo.com
>
> > Cordialement.
> >
> > Le 31/05/2016 16:43, Guillaume Lelarge a écrit :
> >>
> >> Le 31 mai 2016 4:38 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com
> <mailto:mjoigny(at)neteven(dot)com>> a écrit :
> >> >
> >> > Bonjour,
> >> >
> >> > Je vous expose mon cas, j'ai deux serveurs postgresql (9.5) en
> mode streaming replication avec deux pgpool (un sur chaque host pour
> la redondance).
> >> >
> >> > Un incident sur le serveur master à lancé un trigger (basé sur ma
> configuration) pour promouvoir le slave (et pgpool) en nouveau master.
> >> >
> >> > L'ancien master est actuellement inactif en attendant de le
> resynchroniser.
> >> >
> >> > Comme l'indique l'objet de mon mail, j'ai depuis la bascule cette
> erreur (en grand nombre) dans les logs pgpool depuis le démarrage du
> nouveau master.
> >> >
> >> > Le fichier sur le master actuel a une taille nulle alors que sur
> l'ancien master, il est d'environ 500M.
> >> >
> >> > C'est la première fois que je tombe sur ce cas là, avez-vous une
> idée de comment résoudre ce cas ?
> >> >
> >>
> >> De quel fichier parle-t-il ? Attendez-vous à devoir faire une
> reprise de sauvegarde.
> >
> >
> > --
>

--

Le 31 mai 2016 5:09 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com> a écrit :
>
> Le 31/05/2016 16:59, Guillaume Lelarge a écrit :
>>
>> Le 31 mai 2016 4:48 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com> a écrit :
>> >
>> > Bonjour Guillaume,
>> >
>> > Merci pour votre retour.
>> >
>>
>> Merci de laisser la liste en copie. Merci aussi de ne pas top-poster.
>>
>> > Qu'entendez par quel fichier ? je peux interroger via la requête
suivante d’après mes recherches, en me plaçant sur ma base et en lançant :
>> >
>> > select * from pg_class where oid = {id présent dans mes logs};
>> >
>>
>> Le message d'erreur n'indique certainement pas myfile. Vous pouvez avoir
un nombre, avec ou sans extension. C'est cela qui m'intéresse. Suivant
l'extension, c'est plus ou moins grave.
>
> Voici le message exact : could not read block 0 in file
"base/16583/12119463": read only 0 of 8192 bytes
>

OK. Il s'agit donc du fichier de données d'une table, d'un index ou d'une
vue matérialisée. Dans le cas d'une table, c'est une restauration de
sauvegarde qu'il faut faire. Dans les deux autres cas, il est possible de
recréer l'index ou de rafraîchir la vue matérialisée mais je conseille
fortement de refaire une sauvegarde après, puis de restaurer la sauvegarde.
Ça permettra de détecter tout autre problème ou de s'assurer qu'il n'y en a
pas (de détectable).

--
Guillaume
http://www.dalibo.com

>>
>> > Cordialement.
>> >
>> > Le 31/05/2016 16:43, Guillaume Lelarge a écrit :
>> >>
>> >> Le 31 mai 2016 4:38 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com> a
écrit :
>> >> >
>> >> > Bonjour,
>> >> >
>> >> > Je vous expose mon cas, j'ai deux serveurs postgresql (9.5) en mode
streaming replication avec deux pgpool (un sur chaque host pour la
redondance).
>> >> >
>> >> > Un incident sur le serveur master à lancé un trigger (basé sur ma
configuration) pour promouvoir le slave (et pgpool) en nouveau master.
>> >> >
>> >> > L'ancien master est actuellement inactif en attendant de le
resynchroniser.
>> >> >
>> >> > Comme l'indique l'objet de mon mail, j'ai depuis la bascule cette
erreur (en grand nombre) dans les logs pgpool depuis le démarrage du
nouveau master.
>> >> >
>> >> > Le fichier sur le master actuel a une taille nulle alors que sur
l'ancien master, il est d'environ 500M.
>> >> >
>> >> > C'est la première fois que je tombe sur ce cas là, avez-vous une
idée de comment résoudre ce cas ?
>> >> >
>> >>
>> >> De quel fichier parle-t-il ? Attendez-vous à devoir faire une reprise
de sauvegarde.
>> >
>> >
>> > --
>
>
> --

Peut-on identifier précisément si c'est une table, un index ou une vue ?

Si je comprends bien, je dois faire une sauvegarde puis une restauration
dans la foulée pour corriger le problème ?

Le 31/05/2016 18:18, Guillaume Lelarge a écrit :
>
> Le 31 mai 2016 5:09 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com
> <mailto:mjoigny(at)neteven(dot)com>> a écrit :
> >
> > Le 31/05/2016 16:59, Guillaume Lelarge a écrit :
> >>
> >> Le 31 mai 2016 4:48 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com
> <mailto:mjoigny(at)neteven(dot)com>> a écrit :
> >> >
> >> > Bonjour Guillaume,
> >> >
> >> > Merci pour votre retour.
> >> >
> >>
> >> Merci de laisser la liste en copie. Merci aussi de ne pas top-poster.
> >>
> >> > Qu'entendez par quel fichier ? je peux interroger via la requête
> suivante d’après mes recherches, en me plaçant sur ma base et en lançant :
> >> >
> >> > select * from pg_class where oid = {id présent dans mes logs};
> >> >
> >>
> >> Le message d'erreur n'indique certainement pas myfile. Vous pouvez
> avoir un nombre, avec ou sans extension. C'est cela qui m'intéresse.
> Suivant l'extension, c'est plus ou moins grave.
> >
> > Voici le message exact : could not read block 0 in file
> "base/16583/12119463": read only 0 of 8192 bytes
> >
>
> OK. Il s'agit donc du fichier de données d'une table, d'un index ou
> d'une vue matérialisée. Dans le cas d'une table, c'est une
> restauration de sauvegarde qu'il faut faire. Dans les deux autres cas,
> il est possible de recréer l'index ou de rafraîchir la vue
> matérialisée mais je conseille fortement de refaire une sauvegarde
> après, puis de restaurer la sauvegarde. Ça permettra de détecter tout
> autre problème ou de s'assurer qu'il n'y en a pas (de détectable).
>
> --
> Guillaume
> http://www.dalibo.com
>
> >>
> >> > Cordialement.
> >> >
> >> > Le 31/05/2016 16:43, Guillaume Lelarge a écrit :
> >> >>
> >> >> Le 31 mai 2016 4:38 PM, "Michael JOIGNY" <mjoigny(at)neteven(dot)com
> <mailto:mjoigny(at)neteven(dot)com>> a écrit :
> >> >> >
> >> >> > Bonjour,
> >> >> >
> >> >> > Je vous expose mon cas, j'ai deux serveurs postgresql (9.5) en
> mode streaming replication avec deux pgpool (un sur chaque host pour
> la redondance).
> >> >> >
> >> >> > Un incident sur le serveur master à lancé un trigger (basé sur
> ma configuration) pour promouvoir le slave (et pgpool) en nouveau master.
> >> >> >
> >> >> > L'ancien master est actuellement inactif en attendant de le
> resynchroniser.
> >> >> >
> >> >> > Comme l'indique l'objet de mon mail, j'ai depuis la bascule
> cette erreur (en grand nombre) dans les logs pgpool depuis le
> démarrage du nouveau master.
> >> >> >
> >> >> > Le fichier sur le master actuel a une taille nulle alors que
> sur l'ancien master, il est d'environ 500M.
> >> >> >
> >> >> > C'est la première fois que je tombe sur ce cas là, avez-vous
> une idée de comment résoudre ce cas ?
> >> >> >
> >> >>
> >> >> De quel fichier parle-t-il ? Attendez-vous à devoir faire une
> reprise de sauvegarde.
> >> >
> >> >
> >> > --
> >
> >
> > --
>

--

Michael JOIGNY wrote:

> Peut-on identifier précisément si c'est une table, un index ou une vue ?

Dans ce message:

could not read block 0 in file
"base/16583/12119463": read only 0 of 8192 bytes

Le premier nombre: 16583 est l'OID de la base
et le deuxième est le relfilenode de la relation.

Pour identifier la base en question:
select datname from pg_database where oid=16583;

Une fois connecté à cette base, pour retrouver l'objet auquel
correspond ce fichier:

select * from pg_class where relfilenode=12119463;

ou, en plus fin:

select
n.nspname AS schename,
c.relname,
c.relkind
from pg_class c
join pg_namespace n on (c.relnamespace = n.oid)
where c.relfilenode = 12119463;

relkind donnera le type de la relation, table ou index ou autre,
voir la doc pour les champs de pg_class plus généralement.

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)

"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> select * from pg_class where relfilenode=12119463;

Attention, utiliser la fonction pg_relation_filenode() ici :

select *
from pg_class
where pg_relation_filenode(oid::regclass) = 12119463;

Cela couvre les relation partagées (catalogues communs à toutes les
bases de données) et certains cas de réécritures de tables sur disque.

--
dim

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

Bonjour,

Merci pour vos retours (Dimitri & Guillaume).

Il s'agissait d'un index en cause, avez-vous une idée sur pourquoi un
index en particulier plutôt qu'un autre, à savoir que celui-ci était
sollicité assez souvent.

Cordialement.

Le 31/05/2016 23:26, Dimitri Fontaine a écrit :
> "Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
>> select * from pg_class where relfilenode=12119463;
> Attention, utiliser la fonction pg_relation_filenode() ici :
>
> select *
> from pg_class
> where pg_relation_filenode(oid::regclass) = 12119463;
>
> Cela couvre les relation partagées (catalogues communs à toutes les
> bases de données) et certains cas de réécritures de tables sur disque.
>

--

> Bonjour,
>
> Merci pour vos retours (Dimitri & Guillaume).
>
> Il s'agissait d'un index en cause, avez-vous une idée sur pourquoi un
> index en particulier plutôt qu'un autre, à savoir que celui-ci était
> sollicité assez souvent.

Quel type d'index s'agit-il ?
Les index Hash, par exemple, ont besoin d'être reconstruits après
fail-over, restauration ou même un crash du serveur.

Flavio

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

Bonjour Flavio,

C'est effectivement le cas de l'index identifié, merci pour votre retour.

Savez-vous la raison de ce fonctionnement ?

Le 01/06/2016 11:26, Flavio Henrique Araque Gurgel a écrit :
>> Bonjour,
>>
>> Merci pour vos retours (Dimitri & Guillaume).
>>
>> Il s'agissait d'un index en cause, avez-vous une idée sur pourquoi un
>> index en particulier plutôt qu'un autre, à savoir que celui-ci était
>> sollicité assez souvent.
> Quel type d'index s'agit-il ?
> Les index Hash, par exemple, ont besoin d'être reconstruits après
> fail-over, restauration ou même un crash du serveur.
>
> Flavio
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--

> Bonjour Flavio,
>
> C'est effectivement le cas de l'index identifié, merci pour votre retour.
>
> Savez-vous la raison de ce fonctionnement ?

Je vous invite à consulter la documentation, l'explication est dans le
carré "Attention" :

http://docs.postgresqlfr.org/9.5/indexes-types.html

Flavio

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

Un grand merci pour votre retour.

Cordialement.

Le 01/06/2016 11:33, Flavio Henrique Araque Gurgel a écrit :
>> Bonjour Flavio,
>>
>> C'est effectivement le cas de l'index identifié, merci pour votre retour.
>>
>> Savez-vous la raison de ce fonctionnement ?
> Je vous invite à consulter la documentation, l'explication est dans le
> carré "Attention" :
>
> http://docs.postgresqlfr.org/9.5/indexes-types.html
>
> Flavio
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

--