ok merci, donc si on utilise des order sur une colonne, c'est bien de garder son index normal.

Merci pour toutes ces informations, c'est vrai qu'avant nous étions en 8.2.14 et que nous avions pris l'habitude de créer 2 indexs sur les colonnes où nous utilisions des LIKE et des EQUAL.

Moi j'ai un superbe script maintenant pour mon archive_command

ça fonctionne!

En effet, je suis si déçue!

ok donc sur l'esclave je lance :

/usr/pgsql-9.1/bin/pg_basebackup -h IP_MAITRE -D /data -U replication_role –v

j'essayerai dès lundi, en arrêtant un de mes standbys!
Pour le week end, je vais les laisser se reposer.

Vous parlez dans le "archive _command" ou dans le "rsync" pour la première syncro?

J'ai un standby qui n'a pas de problème de réseau car sur le même site et l'autre qui en effet peut en pâtir.
j'ai donc mis dans mon archive commande pour le standby de l'autre site :
rsync -az %p 192.168.10.xxx:/data/archives_xlog/%f
avec le z il compresse

et quand je fais le rsync pour la 1ère syncro :
rsync -avz -e ssh /data/ IP_serveur_esclave:/data/ --exclude postmaster.pid --exclude postgresql.conf --exclude pg_hba.conf --exclude save/ --exclude logs/ --exclude files/ --exclude pg_log/

Quand il n'y a que quelques fichiers de 16Mb ça va, mais comme notre base fait 20Giga, quand il doit tout rappatrier sur Paris, ça lui prend du temps. Je pourrai peut être lui faire prendre le tgv!

ok merci pour tous ces renseignements!

Hier soir, j'ai voulu lancé le rsync du standby qui n'est pas sur le même site (après le start) et j'ai pu voir que sans l'option "-z" de compression mon réseau n'est pas content, contre 3h de transfert en compression , là en 12h il n'avait pas fait grand chose, j'ai même dû le stopper pour ne pas pénaliser le réseau!

Cette nuit, je le remets avec l'option de compression

Et je testerai les temps pour tous les types de maintenance !

J'ai testé le pg_basebackup  pour éviter de faire le start, le rsync et le stop, mais ce n'est pas possible dans mon cas car mon maitre et mes standby sont sur des serveurs différents et le  pg_basebackup croit que l'ip que je lui donne est un répertoire en local!

Je crois que ça ne peut fonctionner que si le maitre et le standby sont sur le même serveur, non?

Le maitre est passif, mais fait quand même l'archive command donc la copie du fichier WAL vers le Standby?

En fait le standby vient lui demander des WAL quand il n'en a plus dans son répertoire d'attente (pour moi archive_xlog)?
Je pense que le Standby ne faisait que traiter les fichiers WAL de archive_xlog vers son pg_xlog...

Merc je note!
J'espère qu'ne production cela n'arrivera jamais

Donc si je résume :
Le maitre écrit ses fichies WAL dans son répertoire pg_xlog
Les copies en même temps par le biais de la commande "archive_command" donc moi des rsync
Et n'en garde dans son répertoire que le nombre que l'on a mis dans "wal_keep_segment"

Ensuite quand il veut en archiver un, il créé un fichier vide portant le même nom dans "pg_xlog/archive_status/" en mettant comme extension ".ready".
Et quand le serveur en standby vient lui dire "c'est ok pour le fichier nommé "xxxxx" alors il le renomme en xxxxx.done (au lieu de ready).
Et le Standby fait la même démarche  de "archive_status" et renommage ?
Il sait qu'il doit attendre 2 confirmations dans il a deux Standby?

Que ce passe-t-il si le standby est en retard et ne vient dire que très longtemps plus tard que c'est ok pour lui ?

ah ça marche! trop bien, merci!
c'est surtout pour les cas où ça arriverai en production!

non.... ce n'est pas bon tout ça?

oui en prod on nele ferai qu'une seule fois, le jour J ensuite normalement y aura pas de problème!

là justement je suis en test donc je tue souvent mes bases et mes réplications pour tout refaire!