Vous n'êtes pas identifié(e).
Bonjour Sébastien,
Je n'ai pas ajouté le "hot_standby = on" sur mon serveur 2 car, dans un premier temps, je teste une simple restauration autonome.
Pour le pg_hba.conf, c'est pour pouvoir faire le pg_basebackup sur le maître.
Re,
J'ai trouvé mon erreur.
Lors de l'étape de restauration, j'ai bien supprimé le recovery.conf (pour ne pas démarrer du standby), mais j'ai aussi supprimé le contenu de mon pg_xlog.
Désolé du dérangement.
Bonjour,
Je travaille sur un moteur 9.5.2 sous Cent-OS 7.2. J'ai 2 VM pour moi jouer :-)
Je souhaite apprendre : l'archivage des WAL, la sauvegarde, le warm-standby, le hot-standby, le streaming replication.
J'ai activé l'archivage des WAL (vers mon serveur 2) :
wal_level = archive
archive_mode = on
archive_command = 'ssh postgres@dev-postgres-02 test ! -f /home/postgres/PG_ARC/%f && scp %p dev-postgres-02:/home/postgres/PG_ARC/%f'
archive_timeout = 1min
J'ai suivi la procédure suivante pour faire la sauvegarde :
- Créér le Rôle REPLICATION : CREATE ROLE replic WITH PASSWORD 'ma_replic' REPLICATION LOGIN;
- Ajouter au fichier postgresql.conf : max_wal_senders=1
- Ajouter au fichier pg_hba.conf : host replication replic 127.0.0.1/32 md5
- Ajouter au .pgpass : mon-serveur:5432:*:replic:ma_replic
- Arrêter/Redémarrer l'instance
- Faire la sauvegarde : pg_basebackup -D /home/postgres/HOT_BACKUP -F t -R -x -z -c fast -l hot_backup_${HOSTNAME}_`date '+%Y%m%d'` -P -v -U replic
J'ai restauré sur mon serveur 2.
Modifié le postgresql.conf :
#wal_level = minimal
#archive_mode = off
#archive_command = ''
#max_wal_senders = 0
#archive_timeout = 0
Lorsque je démarre, j'obtiens les logs suivants :
2016-05-20 08:41:20 CEST [1366]: [1-1] user= 2016-05-20 08:41:20 CEST LOG: database system was interrupted; last known up at 2016-05-20 07:20:39 CEST
2016-05-20 08:41:20 CEST [1366]: [2-1] user= 2016-05-20 08:41:20 CEST LOG: invalid checkpoint record
2016-05-20 08:41:20 CEST [1366]: [3-1] user= 2016-05-20 08:41:20 CEST FATAL: could not locate required checkpoint record
2016-05-20 08:41:20 CEST [1366]: [4-1] user= 2016-05-20 08:41:20 CEST HINT: If you are not restoring from a backup, try removing the file "/home/postgres/PG_DATA/backup_label".
2016-05-20 08:41:20 CEST [1364]: [3-1] user= 2016-05-20 08:41:20 CEST LOG: startup process (PID 1366) exited with exit code 1
2016-05-20 08:41:20 CEST [1364]: [4-1] user= 2016-05-20 08:41:20 CEST LOG: aborting startup due to startup process failure
Est-ce que j'ai raté quelque chose pour avoir une sauvegarde autonome (dans un premier temps) ?
Est-ce bien l'option -x de la commande pg_basebackup qui se charge d'intégrer les WAL nécessaires ?
Pouvez-vous m'aider svp ?
Rebonjour,
Un peu trop la tête dans le guidon (ce soir c'est les vacances :-)).
J'ai indiqué "/home/postgres" dans PGPASSFILE au lieu de "/home/postgres/.pgpass".
Il manquait également le nom de mon_serveur dans le /etc/hosts.
Désolé du dérangement.
Bonjour,
Je travaille sur un moteur 9.5.2 sous Cent-OS 7.2.
J'essaye d'améliorer la sécurité de mon serveur.
J'ai créé un fichier .pgpass dans le répertoire /home/postgres de mon user postgres (mon_serveur:ma_base:postgres:mon_password). J'ai ensuite fait un chmod 0600 .pgpass.
J'ai ajouté le chemin vers mon fichier dans la variable d'environnement PGPASSFILE (PGPASSFILE=/home/postgres, EXPORT PGPASSFILE) dans mon le fichier .bash_profile de mon user postgres.
J'ai mis cela dans mon pg_hba.conf :
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
Lorsque je fais un : psql -U postgres, j'obtiens :
WARNING: password file "/home/postgres" is not a plain file
psql: FATAL: no pg_hba.conf entry for host "10.72.4.11", user "postgres", database "ma_base"
Pourquoi ce warning ?
Et pourquoi le message FATAL ?
Est-ce que j'ai raté quelque chose ?
D'avance merci.
Bonjour Guillaume,
C'est juste que d'une part : je trouve que notre base est plutôt réactive. Que nous allons mettre en place prochainement quelques purges automatiques de certaines tables (pour ne pas garder un historique trop important inutilement), ce qui devrait apporter encore un peu de gain.
D'autre part, j'avais l'impression, en voyant certaines infos sur le net, que les avis sur les SSD étaient un peu mitigé, d'où ma réticence.
Merci pour les infos.
Bonjour,
Personne pour apporter une réponse à mes questions ?
Merci.
Bonjour,
Merci Guillaume.
Bonjour tout le monde,
Je travaille actuellement avec un moteur PostgreSQL 9.2.3, sous Cent-OS 5.4.
Je deux tables :
ORDRE_DE_FABRICATION (
id serial NOT NULL,
ordre character varying(10) NOT NULL,
libelle character varying(40) NOT NULL,
date_crea date NOT NULL,
date_sold date,
CONSTRAINT pk_ordre PRIMARY KEY (ordre))
DOCUMENT (
id_document character varying(150) NOT NULL,
libelle character varying(40),
id_type_document character varying(3),
ordre character varying(10) NOT NULL,
CONSTRAINT pk_document PRIMARY KEY (id_document),
CONSTRAINT fk_document_ordre FOREIGN KEY (ordre) REFERENCES ordre_de_fabrication(ordre) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION)
Je voudrai que, lorsque je viens faire un UPDATE sur le champ DATE_SOLD de la table ORDRE_DE_FABRICATION, tous les enregistrements de la table DOCUMENT ayant le champ ORDRE à la valeur du champ ORDRE de la table ORDRE_DE_FABRICATION soient supprimés (qu'il y en ait ou pas).
La volumétrie devrait être d'environ 300000 à 500000 enregistrements (des deux côtés, globalement du 1 pour 1).
Est-ce possible avec un trigger ? est-ce la bonne solution ?
D'avance merci pour votre aide.
Bonjour Messieurs,
Merci pour les infos et le lien.
Pour aller plus loin : Comment évaluer la sollicitation des disques ?
- Nous avons des checkpoints toutes les 10min.
- 70% des blocs écrits le sont par les checkpoints,
- Le volume moyen écrit par les checkpoints est de 13MB,
- Le volume global écrit à la seconde est de 30KB,
- Le volume global lu à la seconde est de 2MB.
- La sonde système sur les IO disks nous donne :
- Moyenne Lecture sur disque du moteur à 50k/s,
- Moyenne Ecriture sur disque du moteur à 100k/s,
- Moyenne Lecture sur disque des données à 300k/s,
- Moyenne Ecriture sur disque des données à 53k/s,
Quelles pistes faut-il explorer côté configuration du moteur pour avoir plus d'utilisation d'index ?
Pour la HA : nous avons comme impératif de pouvoir redémarrer en 2 heures, avec une perte de données acceptable de 5 minutes. Rien n'est encore décidé au niveau solution.
Pour la version 9.5 : nous sommes actuellement en 9.3.2, nous pourrons faire un upgrade lors de la mise en place de la HA.
Bonjour tout le monde,
Je travaille actuellement avec un moteur PostgreSQL 9.3.2, sous Cent-OS 6.4.
Machine : Xeon-X5650-2.67GHz, 32 Go de RAM, moteur et fichiers traces sur disque 300 Go 10000 tours EXT4, données sur disque 146 Go 15000 tours EXT4, xlog sur disque 146 Go 15000 tours EXT4.
Paramètres : Shared_buffers=8192MB, Max_connections=300, Work_mem=10MB, Maintenance_work_mem=4096MB, Checkpoint_segments=64, Checkpoint_timeout=10min, Effective_cache_size=21840MB, Stats_temp_directory=/ramcache, Log_autovacuum_min_duration=300, Autovacuum_naptime=10min
Taille de la BD = 30Go,
Moyenne journalière Insert=300000, Update=600000, Delete=120000
Moyenne connexions journalière=200
Trois plus grosses tables :
- 50 millions d'enr, 9Go table, 5.6Go index
- 14 millions d'enr, 3.3Go table, 3.6Go index
- 7 millions d'enr, 1.7Go table, 2Go index
Cache Hit/Miss en moyenne à 99%
Dans mon entreprise, j'entends parler de passage au SSD. Qu'en est-il des interrogations sur ce support ? Sont-ils maintenant "fiables" ? les gains de performance sont-ils réels ?
J'ai lu un "vieux" post : "quel SSD pour booster une base de données ?" de 2012, qui parlait de SSD.
Avez-vous des retours d'expérience, des conseils, des infos sur ce support ?
Nous envisageons la mise en place d'un PCA/PRA.
Quelles solutions sont envisageables ?
Faut-il passer à la version 9.5 dans le cas d'une solution de haute disponibilité PostgreSQL ? ou peut-on rester en 9.3.2 ?
Merci pour vos réponses.
Bonjour Guillaume,
J'avais pensé mettre LOG_MIN_MESSAGE à NOTICE et mettre un RAISE NOTICE 'select monschema.maprocedure(%,%,%,%)',$1,$2,$3,$4; avant le RETURN de mes procédures stockées.
C'est une petite "bidouille" mais pourquoi pas ?
Bonjour,
Je travaille avec un moteur 9.3.2 sous Cent-OS 6.5.
J'ai des procédures stockées qui renvoie des curseurs.
J'avais paramétré LOG_MIN_DURATION_STATEMENT à 0 pour tracer les durées de toutes les instructions. Ainsi je voyais :
2015-12-03 07:34:39 CET [28722]: [3331-1] user=toto 127.0.0.1 2015-12-02 10:39:53 CET LOG: duration: 25.174 ms statement: select monschema.maprocedure('FR', 'LENS', '40054',30) as data
2015-12-03 07:34:39 CET [28722]: [3332-1] user=toto 127.0.0.1 2015-12-02 10:39:53 CET LOG: duration: 162.360 ms statement: fetch all in "<unnamed portal 959>"
J'ai aujourd'hui, paramétré LOG_MIN_DURATION_STATEMENT à 100, pour réduire le volume des traces.
Problème, je ne vois plus les appels aux procédures stockées, mais uniquement la durée "du retour du curseur" s'il est supérieur à 100ms :
2015-12-04 10:30:20 CET [26419]: [18068-1] user=toto 127.0.0.1 2015-11-29 06:33:12 CET LOG: duration: 366.774 ms statement: fetch all in "<unnamed portal 5359>"
De ce fait, je ne sais plus quel appel à quelle procédure stockée est "long".
Y-a-t'il un moyen de retrouver cette information sans réactiver la trace de toutes les instructions ?
D'avance merci.
Bonjour Guillaume,
Ok, merci :-(
Bonjour,
Je travaille avec un moteur 9.3.2 sous Cent-OS 6.5.
Est-il possible d'avoir des informations statistiques sur l'utilisation des vues (pg_stat....) ?
Je voudrais savoir si mes vues sont utilisées ou pas ?
Merci.
Bonjour Messieurs,
Ok, merci.
Bonjour,
Je travaille sous CenOS 5.9 avec un moteur PostgreSQL 9.3.2.
Est-il possible de ne pas enregistrer l'activité d'un User dans les logs ?
D'avance merci pour les réponses.
Bonjour Guillaume,
Le problème est que :
pour une BD de 21Go, la consommation est de 7Go,
pour une BD de 46Go, la consommation grimpe à 34Go
D'où mon interrogation ?
Bonjour Julien,
Ah oui, je l'avais lu, merci pour le rappel. Il est vrai que mon script date un peu. Je vais supprimer les Reindexdb.
Je lance la commande linux "du" à intervalle régulier pendant l'exécution. De plus, les journaux de transaction sont sur un autre disque.
Bonjour Guillaume,
Les 2, si j'ai bien compris PostgreSQL trace ces actions dans les journaux de transaction et "clone" les objets pour les reconstruire de façon "réorganisé".
Oui, pendant l'opération.
Le Vacuum n'est-il pas pour "réorganiser" les données et mettre à jour les stats, le Reindex pour "reconstruire" les indexes ?
Je fais un Vacuum Full pour garder ma base la plus "propre" et la plus réactive possible.
Bonjour à tous,
J'ai 2 bases de structure différente sur 2 machines différentes :
1) Xeon-X5650-2.67GHz, 32Go RAM, Cent-OS 6.4, Disque 146 Go / 15000 Tours / Ext4, Moteur Pg 9.3.2, Base 21 Go
2) Xeon-X5650-2.67GHz, 32Go RAM, Cent-OS 6.4, Disque 146 Go / 15000 Tours / Ext4, Moteur Pg 9.2.4, Base 46 Go
Les configurations sont les suivantes :
1) Max_connections=300 ; Shared_buffers=8192MB ; Maintenance_work_mem=4096MB ; Checkpoint_segments=64 ; Checkpoint_timeout=10min ; Effective_cache_size=21840MB
2) Max_connections=100 ; Shared_buffers=3072MB ; Maintenance_work_mem=1536MB ; Checkpoint_segments=32 ; Checkpoint_timeout=5min ; Effective_cache_size=8192MB
Chaque dimanche, comme il n'y a pas d'activité, j'effectue les opérations de maintenance suivantes sur les 2 serveurs :
vacuumdb -a -f -z
reindexdb -a
reindexdb -s
La consommation d'espace disque de ces commandes est la suivante :
1) 7Go
2) 34Go
Comment peut-on expliquer une telle différence de consommation d'espace disque ?
La version du moteur PostgreSQL ?
La différence de configuration du fichier postgresql.conf ?
Une augmentation "exponentielle" par rapport à la taille de la base ?
Avez-vous déjà constaté ce phénomène ?
D'avance merci pour les réponses.
Bonjour Guillaume,
Oui, merci. J'ai finalement trouvé.
Pour ceux que cela intéresse :
CREATE OR REPLACE FUNCTION infos_tables() RETURNS void AS
$BODY$
DECLARE
cSchema VARCHAR;
cTable VARCHAR;
tTabSchema VARCHAR[]:=ARRAY['toto','tata','titi'];
tTabToto VARCHAR[]:=ARRAY['table1','table2','table3'];
tTabTata VARCHAR[]:=ARRAY['table1','table2','table3','table4','table5'];
tTabTiti VARCHAR[]:=ARRAY['table1','table2','table3','table4'];
nNbEnr INTEGER;
nSize BIGINT;
BEGIN
DELETE FROM infos_table_snap WHERE EXTRACT(DAYS FROM CURRENT_TIMESTAMP-now)::INTEGER>60;
FOREACH cSchema IN ARRAY tTabSchema LOOP
FOREACH cTable IN ARRAY CASE WHEN cSchema='toto' THEN tTabToto ELSE CASE WHEN cSchema='tata' THEN tTabTata ELSE CASE WHEN cSchema='titi' THEN tTabTiti END END END LOOP
EXECUTE 'SELECT COUNT(*) FROM '||cSchema||'.'||cTable INTO nNbEnr;
EXECUTE 'SELECT PG_TABLE_SIZE('||CHR(39)||cSchema||'.'||cTable||CHR(39)||')/1024/1024' INTO nSize;
EXECUTE 'INSERT INTO infos_table_snap(now,schema_name,table_name,nb_enr,size) VALUES('||'CURRENT_TIMESTAMP'||','||CHR(39)||cSchema||CHR(39)||','||CHR(39)||cTable||CHR(39)||','||nNbEnr||','||nSize||')';
RAISE NOTICE 'Extraction infos Table : %.%',cSchema,cTable;
END LOOP;
END LOOP;
END;
$BODY$
LANGUAGE plpgsql VOLATILE COST 100;
Bonjour,
Je travaille sous CenOS 5.9 avec un moteur PostgreSQL 9.3.2.
Je souhaite écrire une Fonction qui, avec une liste de tables définie dans la partie DECLARE, exécute par exemple un SELECT COUNT(*) FROM "table de la liste" et insère le résultat dans une table.
Est-t-il possible de définir des listes, ou des tableaux, ou autres, dans la partie DECLARE ?
D'avance merci pour les réponses.
Bonjour,
J'ai finalement trouvé.
MA solution pour ceux que cela pourrait intéresser :
select size-(last_value(size) over(order by now desc rows between unbounded preceding and unbounded following))
FROM test
WHERE extract(week from now)=extract(week from current_date)-1
ORDER BY now desc limit 1;
Bonjour,
Je travaille sous CenOS 5.9 avec un moteur PostgreSQL 9.3.2.
J'ai la table suivante :
CREATE TABLE test(
id serial NOT NULL,
now timestamp with time zone NOT NULL,
size bigint NOT NULL,
CONSTRAINT pk_test PRIMARY KEY (id));
Je l'alimente de façon journalière (mais si j'ai commencé à l'alimenter un mercredi, je n'ai pas forcement de ligne pour le premier jour de la semaine).
Le champ size ne fait que cumuler de jour en jour, à la manière des stats PostgreSQL.
Je voudrai faire une requête qui me retourne la différence entre la size du dernier jour "alimenté" de la semaine dernière et la size du premier jour "alimenté" de la semaine dernière.
J'arrive bien à sélectionner les enregistrements de la semaine dernière :
SELECT * FROM test WHERE extract(week from now)=extract(week from current_date)-1 ORDER BY now DESC;
Cela me retourne par exemple :
5;"2015-04-12 00:01:01.587489+02";15988320440
4;"2015-04-11 00:01:01.446174+02";15959443640
3;"2015-04-10 00:01:02.15777+02";15798061240
2;"2015-04-09 00:01:02.160302+02";15676590264
1;"2015-04-08 00:01:01.655994+02";15561124024
Le problème est pour faire la différence entre premier et dernier jour.
J'ai regardé les fonctions window avec first_value et last_value mais je n'arrive pas à un résultat. Ce n'est peut-être pas la bonne technique.
Quelqu'un peut-il orienter mes recherches, svp ?
