Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#101 Re : Installation » sauvegarde et restauration BARMAN: » 24/06/2013 09:47:54
Est ce que qq aura la gentillesse de m'aider SVP?
#102 Installation » sauvegarde et restauration BARMAN: » 21/06/2013 12:10:06
- lemjid
- Réponses : 6
Bonjour tout le monde:
Je voudrai mettre en oeuvre la sauvegarde postgresql en utilisant BARMAN. Je suis bien sûre sur un environnement de test.
Je suis en version postgres 9.2.4 et barman 1.2.0.
j'ai essayé la sauvegarde en locale (barman sur serveur postgres) et à distance (barman sur un serveur distant).
Voilà ce qu'il m'arrive: Tout les indicateur sont OK:
___________________
[barman@localhost test]$ barman show-server TEST90
Server TEST90:
active: true
description: TEST90 PostgreSQL Database
ssh_command: ssh postgres@10.122.250.90
conninfo: host=10.122.250.90 user=postgres port=5432
backup_directory: /SVG_BARMAN90/TEST90
basebackups_directory: /SVG_BARMAN90/TEST90/base
wals_directory: /SVG_BARMAN90/TEST90/wals
incoming_wals_directory: /SVG_BARMAN90/TEST90/incoming
lock_file: /SVG_BARMAN90/TEST90/TEST90.lock
compression: gzip
custom_compression_filter: None
custom_decompression_filter: None
retention_policy_mode: auto
retention_policy: None
wal_retention_policy: main
pre_backup_script: None
post_backup_script: None
minimum_redundancy: 0
current_xlog: 000000010000000000000022
last_shipped_wal: 000000010000000000000021
archive_command: rsync -a %p barman@10.122.250.90:/SVG_BARMAN90/TEST90/incoming/%f
server_txt_version: 9.2.4
data_directory: /pgsql_data_test/9.2/pg_data
archive_mode: on
config_file: /pgsql_data_test/9.2/pg_data/postgresql.conf
hba_file: /pgsql_data_test/9.2/pg_data/pg_hba.conf
ident_file: /pgsql_data_test/9.2/pg_data/pg_ident.conf
____________________________
[barman@localhost test]$ barman check TEST90
Server TEST90:
ssh: OK
PostgreSQL: OK
archive_mode: OK
archive_command: OK
directories: OK
retention policy settings: OK
compression settings: OK
minimum redundancy requirements: OK (have 1 backups, expected at least 0)
____________________________
[barman@localhost test]$ barman list-backup TEST90
TEST90 20130621T105619 - Fri Jun 21 10:56:46 2013 - Size: 315.0 MiB - WAL Size: 25.0 MiB
__________________________
Le problème:
Sur ma base je créé une table avec qq lignes, je fais une sauvegarde barman et je fais truncate ma table.
J'arrête ma base puis je fais un "barman recover TEST90 20130621T105619 /pgsql_data_test/9.2/pg_data"
et j' ai ce masage:
rsync: change_dir#1 "/pgsql_data_test/9.2/pg_data" failed: Permission denied (13)
rsync error: errors selecting input/output files, dirs (code 3) at main.c(534) [receiver=3.0.6]
rsync: connection unexpectedly closed (9 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
ERROR: Unhandled exception. See log file for more details.
_______________________
J'ai essayé un truc c'est que je fait le recover dans un repertoire dont le user "barman" est propriétaire puis je copie les fichier et répertoires de la base dans $PGDTA et je remet les droits postgres comme il faut, je redémarre la base c'est OK sauf que les données de la tables de test sont perdu. Comme si je n'ai pas restauré.
Question:
Dans mes démarches et surtout avant le démarrage de postgres, faut il faire qq chose comme un fichier recovery.conf ou autre car j'ai vu un backup.label dans mon $PGDATA. J'ai cherché partout mais il parle de redémarrage de la base après recover même dans la doc officielle.
Si qq à un URL aussi qui mène à un tuto ça sera la bienvenue.
Merci d'avance pour votre aide
#103 Réplication » cluster postgres avec pacemaker » 17/05/2013 15:44:22
- lemjid
- Réponses : 1
Bonjour tout le monde.
D'abord je ne sais pas si j'ai le droit de poster un message pareil sur le site postgresql.fr, sachant que mon pbm n'est pas exclusivement sur postgres.
Je de mande néanmoins de l'aide par rapport à votre expérience. Si mon message n'a pas ça place ici, je suis désolé merci au admins de le supprimer.
LE PBM:
J'ai une configuration streaming replication 2 machines et la haute dispo est gérer par pacemaker. le pbm quand je fait les test de bascule ça fonctionne à moitié.
le principe est:
Si la base s'arrête sur le maître, pacemaker se charge de promoter l'esclave et d'attribuer l'adresse IP flottante sur ce nouveau maître. Sauf qu'il fait la promotion et pour l'attribution de l'adresse ip flottante sur la deuxième machine ne s'effectue pas. En revanche il la supprime du serveur (ancien maître) si j'arrête la base. Le pbm quand je passe la commande " crm resource cleanup pgsqld et crm resource cleanup pgsql-ip" il fait la bascule de l'adresse.
Ce qu'il faut c'est que tout ça se passe en automatique.
J'ai cherché partout d'ou ça peut venir en vain. Merci d'avance pour votre aide.
Bien à vous
#104 Re : Optimisation » Tuning linux pour postgresql » 10/05/2013 13:54:33
Merci gleu.
Merci genius quand même et je ne pense pas qu'on est dans l'obligation d'écrire si on ne sait pas. Merci encore pour l'intret c'est déjà ça.
Bien à vous
#105 Re : Réplication » Failover sur disque partagé » 01/04/2013 11:42:24
Merci Julien,
En revanche concernant le rsync à quel niveau il faut l'utiliser. Est ce que au niveau du fichier "recovery.conf" sur la ligne 'restore_command' ou elle est parametrable quelque part? merci de m'apporter qq précisions et ou m'aiguiller vers un tuto sur le web.
Pour le Raid dans mon cas on peut dire que le raid1 sera adopter par rapport au raid5; on est d'acord.
Bien à toi
#106 Re : Optimisation » WARNING:pgstat wait timeout » 01/04/2013 11:18:43
Merci beaucoup julien.
#107 Re : Optimisation » WARNING:pgstat wait timeout » 31/03/2013 16:01:58
Avec un shared_buffer de ~3GB, un checkpoint_segment à 40 et un wal_buffers à 32MB que peut on me conseiller pour le "archive_timeout" et le "checkpoint_timeout"?
Merci d'avance
#108 Re : Réplication » Failover sur disque partagé » 31/03/2013 15:05:01
Je commence à voir plus claire. D'abord je veux juste préciser que peut être je pose des questions parfois banales et évidentes. Le problème c'est que c'est une responsabilité et je n'ai pas envie de subir des concéquences dont je n'ai pas besoin de faire un dessin. Bref
Si je me permet de résumer:
- La version e postgres sera la 9.2 (c'est déjà pris en compte et acquis pas de pbm).
- Un master/slave en hote standby pour la synchro. (avec les paramètres qui vont bien).
- La solution répertoire partagé n'ai pas conseillée dans mon cas car je ne dispose pas du raid 10. (je n'ai que du raid5 avec 3 disques). Ce n'ai pas conseillé je sais mais ce n'ai pas moi qui décide. En revanche j'ai lapossibilité du choisir du raid1.
Questions:
- Pour confirmation en cas de failover, c'est le 'pg_ctl promote' qu'il faut pour mettre l'esclave en maître?
- La reconstruction de l'ancien maître en esclave se fait via 'pg_basbackup'?
- Entre du raid5 avec 3 disque et du raid1, que choisir? et pour quel repertoire sur fs '$PGDATA', '$PGLOG' et '$PGXLOG'?
A préciser que je vais partir sur une solution de replication hot standby 1master/1slave (c'est tout ce que j'ai comme ressources). Je vais essayer de demander une 3e pour slave2 mais ce n'ai pas gagné. Qu'en penses tu?
Je vais voir d'avantage ce que fait pgbouncer il a l'air pas trop compliqué.
Bien à toi
#109 Re : Réplication » Failover sur disque partagé » 31/03/2013 13:45:04
Merci Julien,
Donc ci je comprend bien c'est un architecture Hotstandby (pour la replication synchrone) au niveu du paramètre "wal_level"=hot_standby et pas archive?
Une question très importante: Je sais que le minimum syndical est 2 machine pour maître et esclave ( ce que je dispose) mais à ton avis combien de machines faut -t- il et quel est le rôle des autres machine s'il en faut plus?
Une deuxiem pour le repertoire partagé du premier cas, comment mettre en place ce repertoire? Je pense qu'il faut le dupliquer, faut il utiliser DRBD pour le faire.
Bien à toi
#110 Réplication » Failover sur disque partagé » 30/03/2013 17:35:03
- lemjid
- Réponses : 7
Bonjour tout le monde.
J'ai lu dans la doc officielle de postgres (en français) ceci:
Le failover (ou bascule sur incident) sur disque partagé élimine la surcharge de synchronisation par l'existence d'une seule copie de la base de données. Il utilise un seul ensemble de disques partagé par plusieurs serveurs. Si le serveur principal échoue, le serveur en attente est capable de monter et démarrer la base comme s'il récupérait d'un arrêt brutal. Cela permet un failover rapide sans perte de données.
Je que j'ai compris c'est qu'il faudra seulement un cluster demarré car le "$PGDATA" est commun : (vrai ou faux)?
Mon besoin ou plutôt ce qu'on me de demande est d'avoir 2 exigences à la fois voir plus. Un sercice continu et une reprise avec le dernier commit si problème sur le maître.
Le failover sur disque partagé d'après ma compréhension ne réponds pas à un service continue. Le log-shipping non plus.
Le streaming réplication ne me garantie pas le dernier commit et le hot-standbay ne me permet pas une rapidété de lecture/ecriture sur la base vue ce qu'on lui demande de faire de plus il faut multiplier les machines ce que ne plait pas forcément aux directeurs et aux chefs de projet car il veulent plus fiable et moin cher...!
Est ce que quelqu'un pourra me conseiller une architecture optimale avec 2 machines à disposition. Pour moi je peux faire du streaming réplication vu que c'est le plus rapide à mon sens mais avec un service continue si on rajoute une bascule avec pacemaker mais je cherche à avoir une fiabilité et non perte de donnée.
Merci d'avance.
#111 Re : Optimisation » WARNING:pgstat wait timeout » 27/03/2013 20:19:16
Merci encore,
Je suis entièrement d'accord avec toi julien. J'ai commencer par augmenter le checkpoint_segments à 40 pour un FS pg_xlog de 6Go. Je ne sais pas exactement ce que je peut faire aussi. Je fait un "disable autovacuum" avant traitement pour baisser la charge d'ecriture...?? y a t il d'autre pistes STP.
Voici la config de corosync mais pour l'instant ce n'ai pas la préoccupation majeure, le plus urgent c'est ce pbm de gestion I/O.
#crm configure show
node MAITRE
node ESCLAVE
primitive pgsql-ip ocf:heartbeat:IPaddr2 \
params ip="x.x.x.x" cidr_netmask="24" \
op monitor interval="20s" \
meta is-managed="true"
primitive pgsqld ocf:pgsql:PostgreSQL \
op start interval="0" timeout="120s" \
op stop interval="0" timeout="120s" \
op monitor interval="20s" \
meta is-managed="true"
colocation pgsqld_with_pgsql-ip inf: pgsql-ip pgsqld
property $id="cib-bootstrap-options" \
dc-version="1.1.6-3.el6-a02c0f19a00c1eb2527ad38f146ebc0834814558" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
last-lrm-refresh="1364405383"
rsc_defaults $id="rsc-options" \
resource-stickiness="INFINITY" \
migration-threshold="3"
Bien à toi
#112 Re : Optimisation » WARNING:pgstat wait timeout » 27/03/2013 16:53:02
Merci "rjuju",
C'est quand même grave car ça m'a coûté une bascule sur l'esclave par pacemaker à un moment donné.
Est ce que le fait que les traitement font un "CREATE UNLOGGED TABLE table_temp AS select from table...." engendre de l'ecriture de plus si j'augmente mon "checkpoint_segments" pourra aider à ne pas générer des I/O d'avantage? Sinon que pourrais je faire?
Merci d'avance
#113 Optimisation » WARNING:pgstat wait timeout » 27/03/2013 15:05:44
- lemjid
- Réponses : 8
Bonjour à toutes et à tous,
Je rencontre un problème sur ma base en streaming réplication, version ( PostgreSQL 9.1.6 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 64-bit).
Dans le log pendant le traitement de la nuit des message répétitifs "WARNING : pgstat wait timeout".
J'ai fait la tour dans google, Hélas je n'ai pas trouvé une réponse qui correspond à mon problème.
Est ce que quelqu'un pourra m'aiguiller SVP?
Merci d'avance
#114 Re : Optimisation » Tuning linux pour postgresql » 25/03/2013 15:51:09
Merci julien,
Oui c'est un serveur dédié pour la base postgresql dont une application web se connecte dessus (pour intranet). Le système d'exploitation c'est linux RedHat " x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit". Pour le système de fichier c'est du type (ext3) sur des disques SUN.
Le But est d'obtenir un meilleur temps de réponse pour des requêtes de type insert/update sachant qu'on utilise pas de table temp.
Merci d'avance.
#115 Re : Optimisation » Tuning linux pour postgresql » 25/03/2013 13:41:55
Bonjour,
Est ce quelqu'un pourra m'aiguiller SVP?
Bien à vous
#116 Optimisation » Tuning linux pour postgresql » 22/03/2013 16:11:06
- lemjid
- Réponses : 6
Bonjour tout le monde,
Je sollicite votre aide pour tuner ma base postgresql '54GB' avec la version:
PostgreSQL 8.4.7 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-50), 64-bit
Ma base n'est pas vraiment en bonne santé au niveau rapidité. Pour commencer j'aimerai bien tuner le shmall et shmmax mais je ne suis pas sûre de ma formule de calcule car les résultats que j'ai obtenu ne sont pas convaiquants. Et si possible me donner les bonne formules de calcule.
Voici ce que j'ai comme paramètres actuellement.
#cat /proc/sys/kernel/shmall
4294967296
-------------------------------
#cat /proc/sys/kernel/shmmax
68719476736
-------------------------------
#cat /proc/meminfo
MemTotal: 16432980 kB
MemFree: 295448 kB
Buffers: 405924 kB
Cached: 13877848 kB
SwapCached: 0 kB
Active: 5328532 kB
Inactive: 9496008 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 16432980 kB
LowFree: 295448 kB
SwapTotal: 8191992 kB
SwapFree: 8191560 kB
Dirty: 4640 kB
Writeback: 0 kB
AnonPages: 541024 kB
Mapped: 4260852 kB
Slab: 867876 kB
PageTables: 245060 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 16408480 kB
Committed_AS: 6146040 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 291232 kB
VmallocChunk: 34359447083 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
---------------------------------------
#ipcs -l -m
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 67108864
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1
Est il possible aussi de me donner aussi quelques conseils pour tuner mon "postgresql.conf".
Merci d'avance.
B.LEMJID
#117 Re : PL/pgSQL » requête très lente sur PostgreSQL 8.4.2 : » 14/03/2013 16:09:25
C'est OK déjà le problème de blocage n'est plus là et c'est super. Je sort avec 2 solutions.
Je veux aussi souligner votre réactivité, disponibilité et efficacité et vous dire (guillaume et Marc) un grand MERCI.
#118 Re : PL/pgSQL » requête très lente sur PostgreSQL 8.4.2 : » 14/03/2013 15:24:09
Bonjour, Merci guillaume et merci Marc,
Ci après le résultat d'explain analyze. J'ai rajouté set work_mem sinon la requête n'aboutira pas (très lente).
set work_mem TO "1GB";
SET
Begin;
BEGIN
explain analyze delete from jahia_fields_prop where fieldid_jahia_fields_prop not in (select distinct id_jahia_fields_data from jahia_fields_data);
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Seq Scan on jahia_fields_prop (cost=458348.42..471968.60 rows=308127 width=6) (actual time=6512.137..6512.137 rows=0 loops=1)
Filter: (NOT (hashed SubPlan 1))
SubPlan 1
-> Unique (cost=0.00..450630.37 rows=3087220 width=4) (actual time=0.026..3614.092 rows=5442652 loops=1)
-> Index Scan using jahia_fields_data_index9 on jahia_fields_data (cost=0.00..434151.45 rows=6591567 width=4) (actual time=0.024..2387.432 rows=
6589256 loops=1)
Total runtime: 6535.638 ms
(6 lignes)
rollback;
ROLLBACK
Bien à vous.
#119 Re : PL/pgSQL » requête très lente sur PostgreSQL 8.4.2 : » 14/03/2013 13:19:40
Merci Marc,
Voici le plan:
explain delete from jahia_fields_prop where fieldid_jahia_fields_prop not in (select distinct id_jahia_fields_data from jahia_fields_data);
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------
Seq Scan on jahia_fields_prop (cost=465777.59..15607188979.52 rows=308127 width=6)
Filter: (NOT (SubPlan 1))
SubPlan 1
-> Materialize (cost=465777.59..508709.79 rows=3087220 width=4)
-> Unique (cost=0.00..450630.37 rows=3087220 width=4)
-> Index Scan using jahia_fields_data_index9 on jahia_fields_data (cost=0.00..434151.45 rows=6591567 width=4)
=============================================================================================
Concernant le upgrade ça va se faire mais pas dans les médiats car on est entrain de voir avec l'éditeur de l'application et ça sera du postgresql9.x
J'ai testé l'augmentation de work_mem "set work_mem to " ça marche mieux merci en revanche ça reste lent. Est il possible de la tuner pour éviter "not in"?
Merci d'avance.
#120 PL/pgSQL » requête très lente sur PostgreSQL 8.4.2 : » 14/03/2013 11:20:25
- lemjid
- Réponses : 7
Bonjour à toutes et à tous,
Je rencontre un problème de lenteur sur une requête et je demande s'il vous plais de m'aider à la "tuner". Merci d'avance.
La requêtes est:
delete from jahia_fields_prop where fieldid_jahia_fields_prop not in (select distinct id_jahia_fields_data from jahia_fields_data);
Voici les informations sur les deux tables:
select count(*) from jahia_fields_prop;
count
--------
616254
(1 ligne)
Table « public.jahia_fields_prop »
Colonne | Type | Modificateurs
---------------------------------------+--------------------------+---------------
fieldid_jahia_fields_prop | integer | non NULL
propertyname_jahia_fields_prop | character varying(250) | non NULL
propvalue_jahia_fields_prop | character varying(50) |
Index :
"jahia_fields_prop_pkey" PRIMARY KEY, btree (fieldid_jahia_fields_prop, propertyname_jahia_fields_prop)
---------------------------------
select count(*) from jahia_fields_data;
count
---------
6589256
(1 ligne)
Table « public.jahia_fields_data »
Colonne | Type | Modificateurs
------------------------------- ----+---------------------------+---------------
id_jahia_fields_data | integer | non NULL
version_id | integer | non NULL
workflow_state | integer | non NULL
language_code | character varying(10) | non NULL
connecttype_jahia_fields_data | integer |
ctnid_jahia_fields_data | integer |
fielddefid_jahia_fields_data | integer |
id_jahia_obj | integer |
type_jahia_obj | character varying(22) |
rights_jahia_fields_data | integer |
pageid_jahia_fields_data | integer |
jahiaid_jahia_fields_data | integer |
type_jahia_fields_data | integer |
value_jahia_fields_data | character varying(2048) |
Index :
"jahia_fields_data_pkey" PRIMARY KEY, btree (id_jahia_fields_data, version_id, workflow_state, language_code)
"jahia_fields_data_index" btree (id_jahia_fields_data, workflow_state, pageid_jahia_fields_data)
"jahia_fields_data_index10" btree (id_jahia_obj, type_jahia_obj, workflow_state)
"jahia_fields_data_index11" btree (id_jahia_fields_data, workflow_state, version_id, pageid_jahia_fields_data)
"jahia_fields_data_index12" btree (fielddefid_jahia_fields_data, ctnid_jahia_fields_data, workflow_state)
"jahia_fields_data_index13" btree (jahiaid_jahia_fields_data)
"jahia_fields_data_index2" btree (pageid_jahia_fields_data, ctnid_jahia_fields_data, id_jahia_fields_data, workflow_state)
"jahia_fields_data_index3" btree (pageid_jahia_fields_data, rights_jahia_fields_data, workflow_state)
"jahia_fields_data_index4" btree (ctnid_jahia_fields_data, id_jahia_fields_data)
"jahia_fields_data_index5" btree (type_jahia_fields_data, value_jahia_fields_data, workflow_state, version_id)
"jahia_fields_data_index6" btree (id_jahia_obj, ctnid_jahia_fields_data, workflow_state)
"jahia_fields_data_index7" btree (fielddefid_jahia_fields_data, id_jahia_obj, type_jahia_obj, id_jahia_fields_data)
"jahia_fields_data_index8" btree (ctnid_jahia_fields_data, workflow_state, id_jahia_fields_data)
"jahia_fields_data_index9" btree (id_jahia_fields_data, workflow_state, language_code)
Contraintes de clés étrangères :
"fk891b251a291a9bf4" FOREIGN KEY (fielddefid_jahia_fields_data) REFERENCES jahia_fields_def(id_jahia_fields_def)
Je sais que "not in" est très coûteux mais j'ai essayé avec join mais je n'ai pas réussit à le faire. J'attends vos réponses et suggestions avec plaisir et impatience.
Bien à vous