Où sommes nous ?

Defaillance d une alim

Recuperation d une base PostgreSQL

On devrait toujours regarder de prêt les logs systèmes : dans mon cas, les problèmes ont commencé par de sporadiques erreurs avec le disque dur. En particulier des

Feb 27 03:29:43 bPI smartd[1884]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 10 Spin_Retry_Count changed from 105 to 106

Ce message indique que le disque, pour une raison indéterminée, avait perdu sa vitesse de rotation nominale. Hum, disque en train de lâcher où autre problème.
Au début, j'étais parti sur la première possibilité surtout que dit disque avait planté à plusieurs reprises pendant de gros transfères.

On suivi des

Feb 27 03:27:50 bPI kernel: [3825266.421044] ata1: hard resetting link
Feb 27 03:27:53 bPI kernel: [3825268.731328] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Feb 27 03:27:53 bPI kernel: [3825268.771908] ata1.00: configured for UDMA/33
Feb 27 03:27:53 bPI kernel: [3825268.801748] ata1: EH complete

qui indiquent ce coup-ci que le lien avec le disque a été très ponctuellement perdu. Aïe aïe aïe.

Mais quand arrivent des

Mar  2 13:31:13 bPI usbhid-ups[2237]: libusb_get_interrupt: No such device or address
Mar  2 13:31:15 bPI upsd[1940]: Data for UPS [onduleur] is stale - check driver

le problème vient forcément d'ailleurs : en fait, c'est l'alim à 2 balles qui est en train de lâcher .

Evidemment, tout ceci est arrivé pendant nos vacances laissant bien le temps de faire des dégâts.

Les dégats

Heureusement, le bPI et ses périphs ont bien résisté à toute cette maltraitance et si le disque lui-même ne semble pas avoir souffert, ses arrêts intempestifs ont créé des corruptions sur les données en cours de mise à jour.

Pour les filesystems, un simple fschk a suffi à réparer ce qui devait l'être. Malheureusement, ça a été une autre histoire avec la base de données.

La base de données PostgreSQL

Avant toute tentative de correction, une bonne sauvegarde s'impose : heu ...

$ pg_dumpall --clean > /tmp/db.sql
pg_dump: [archiver (db)] query failed: ERROR:  MultiXactId 114439 has not been created yet -- apparent wraparound
pg_dump: [archiver (db)] query was: SELECT c.tableoid, c.oid, c.relname, c.relacl, c.relkind, c.relnamespace, (SELECT rolname FROM pg_catalog.pg_roles WHERE oid = c.relowner) AS rolname, c.relchecks, c.relhastriggers, c.relhasindex, c.relhasrules, c.relhasoids, c.relrowsecurity, c.relforcerowsecurity, c.relfrozenxid, c.relminmxid, tc.oid AS toid, tc.relfrozenxid AS tfrozenxid, tc.relminmxid AS tminmxid, c.relpersistence, c.relispopulated, c.relreplident, c.relpages, CASE WHEN c.reloftype <> 0 THEN c.reloftype::pg_catalog.regtype ELSE NULL END AS reloftype, d.refobjid AS owning_tab, d.refobjsubid AS owning_col, (SELECT spcname FROM pg_tablespace t WHERE t.oid = c.reltablespace) AS reltablespace, array_remove(array_remove(c.reloptions,'check_option=local'),'check_option=cascaded') AS reloptions, CASE WHEN 'check_option=local' = ANY (c.reloptions) THEN 'LOCAL'::text WHEN 'check_option=cascaded' = ANY (c.reloptions) THEN 'CASCADED'::text ELSE NULL END AS checkoption, tc.reloptions AS toast_reloptions FROM pg_class c LEFT JOIN pg_depend d ON (c.relkind = 'S' AND d.classid = c.tableoid AND d.objid = c.oid AND d.objsubid = 0 AND d.refclassid = c.tableoid AND d.deptype = 'a') LEFT JOIN pg_class tc ON (c.reltoastrelid = tc.oid) WHERE c.relkind in ('r', 'S', 'v', 'c', 'm', 'f') ORDER BY c.oid
pg_dumpall: pg_dump failed on database "www", exiting

Signe d'une corruption critique de la BDD. Malheureusement, tout ce que j'ai trouvé sur le web à ce propos n'ont pas fonctionné : voici donc comment je m'y suis pris pour récupérer la situation.

Faire calmement le point

Les selects sur les tables importantes fonctionnant, il semblerait que seules les méta données ont giclé ... mes données sont toujours accessibles mais malheureusement je ne peux pas utiliser les outils de postgres. La seule solution est donc de jouer le backup ... mais comme il date de plus d'1 mois, il va falloir essayer de sauvegarder les données fraiches importantes.
En effet, ma base est utilisée pour stocker les informations de toute ma domotique et des paramètres de mes machines. Si la perte de certaines d'entres elles n'a aucune importance (typiquement les charges CPU ...), d'autres méritent des efforts pour être conservé comme la production électrique.

Sauvegarde manuelle des tables importantes

Nous avons déterminé quelles sont les données importantes ... et par conséquence les tables importantes. Dans mon cas, ça sera

que nous sauvegarderons avec la commande suivante

www=# copy domestik.probe_hardware_archive to '/tmp/r/probe_hardware_archive';

Création d'un "cluster" saint

Sous Gentoo, les datafiles de la base se trouve dans le répertoire <version_postgres> du home de l'utilisateur postgres. Bref, avec ma base 9.5, ce répertoire sera ~postgres/9.5

# /etc/init.d/apache2 stop
# /etc/init.d/postgresql-9.5 stop
# emerge --config dev-db/postgresql:9.5
# /etc/init.d/postgresql-9.5 start

Chargement des anciennes données

Sous postgres, on charge le backup

$ psql template1 < /tmp/db.sql

Malheureusement, ses données ont donc 50 jours, il faut charger les tables précédement sauvegardées.

www=# truncate domestik.probe_counter;
TRUNCATE TABLE
www=# copy domestik.probe_counter from '/tmp/r/probe_counter';
COPY 501

Et voila, plus de peur que de mal pour ce coup-ci ... va falloir que j'améliore


Visitez :
La liste de nos voyages
Nos sorties Ski et rando
Copyright Laurent Faillie 2001-2017
N'oubliez pas d'entrer le mot de passe pour voir aussi les photos perso.
Contactez moi si vous souhaitez réutiliser ces photos et pour les obtenir avec une plus grande résolution.
Visites durant les 7 derniers jours Nombre de visites au total.

Vous pouvez laissez un commentaire sur cette page.