Vous n'êtes pas identifié(e).
Bnjour Panou,
J'ai pris la doc standard de PG. Il y a tout un chapitre sur le sujet.
Un énième merci, Gleu.
Bonjour,
Je viens prendre des nouvelles sur les versions PG8.4 et Slony 2 sous Windows.
Lors de nos derniers échanges, Gleu avait reproduit le pb.
Y-a-t-il eu des sorties de versions pour palier au souci?
Cordialement
En effet, cela fonctionne.
Je vous remercie encore une fois!
Bonjour,
J'ai mis en place la réplication via les WAL sur PG8.2 (vers une PG8.2) et PG8.3 (vers une PG8.3) sous XP; cela fonctionne parfaitement.
Ma nouvelle problématique est que j'ai plusieurs bases de données sur le serveur maitre que je veux pouvoir répliquer sur l'esclave.
Est-ce possible? Si oui, comment faire?
J'ai essayé de faire plusieurs pg_start_backup, mais PG refuse en me disant qu'un backup est déjà en cours quand je le fais sur la 2nde base....
Merci d'avance
Bonjour,
Je mets en place un serveur de secours en utilisant les Log Shipping.
Je suis sous Windows XP. Ayant un crash de pg_standby en utilisant la 8.4, je suis repassé en 8.3.9.
Avec cette version, la procédure se passe sans erreur, mais il me reste un point noir : les modifs effectuées sur le maitre ne sont pas reportées sur l'esclave...
Voici ce que j'ai fait; cela vous permettra sans doute de m'aider à voir où j'ai fait une erreur.
- Les 2 PG sont avec la même version (8.3.9 sous XP)
- sur le maitre:
- config de l'archivage des WAL
- pg_start_backup
- copie du dossier data sur le serveur de secours (avec les bons droits)
- pg_stop_backup
- sur l'esclave
- suppression du contenu du dossier xlog
- config du recovery.conf pour indiquer où sont dispo les WAL du maitre (copiés en local)
- démarrage de PG
- création du fichier trigger pr que pg_standby commence le traitement
PG démarre et au bout de qq secondes recovery.conf est renommé en recovery.done.
2010-01-07 11:19:24 CETLOG: automatic recovery in progress
2010-01-07 11:19:24 CETLOG: record with zero length at 0/490000B0
2010-01-07 11:19:24 CETLOG: redo is not required
2010-01-07 11:22:03 CETLOG: selected new timeline ID: 3
2010-01-07 11:22:20 CETFATAL: the database system is starting up
2010-01-07 11:22:39 CETLOG: archive recovery complete
2010-01-07 11:22:41 CETLOG: le système de bases de données est prêt pour accepter les connexions
2010-01-07 11:22:41 CETLOG: autovacuum launcher started
Quand je lance PGAdmin, je vois la base, mais je ne vois pas les dernières modifs qui ont été efféctuées sur le maître, même si des WAL ont été créés depuis.
J'ai refait le test avec une 8.3.7, et tout fonctionne.
Ai-je oublié quelque chose?
Merci encore!
Les copies d'écran ainsi que la procédure que j'utilise sont dispo à l'URL : [lien supprimé]
Le script SQL de l'onglet est : [lien supprimé]
Même chose que la dernière fois, j'enlève ces documents une fois que vous les avez récupérés.
N'y a-t-il pas une solution plus élégante pour vous envoyer ce type d'info (copie d'écran, script > 64ko)?
Merci encore
Bonjour,
C'est bien ce que je vous ai fourni.
Je vous fait des copies d'écran et vous les mets à dispo
Je vous confirme qu'aucun fichier n'arrive sous W:\
Je vais donc creuser dans ce sens.
Merci encore.
C'est vrai que je n'ai aucune activité en ce moment dessus.
Pour la fonction archivage; j'ai le dossier pg_xlog qui se complète toutes les 5 minutes (300s paramétrés ds le postgres.conf) avec les fichiers de 16Mo.
Est-ce un gage de bon fonctionnement de l'archivage?
Bonjour,
Désolé de poser une nouvelle question de débutant....
Slony 2.0.2 n'étant pas à utiliser en prod pour l'instant, je bascule donc sur le Log Shipping.
Voici la procédure que j'ai suivi (normalement celle de la doc).
J'utilise PG8.4 sous Windows.
1 / pg_start_backup a l'air de bien se passer. Contrairement à se que dit la doc; l'opération ne prends pas de temps.
C:\Program Files\PostgreSQL\8.4\bin>psql -U postgres -c "SELECT pg_start_backup('sauve_1')" dbmaitre
Mot de passe pour l'utilisateur postgres : *****
pg_start_backup
-----------------
0/9000020
(1 ligne)
2 / pg_stop_backup. L'opération n'en fini pas malgré une base qui n'a qu'une seule table et 3 enregistrements...
C:\Program Files\PostgreSQL\8.4\bin>psql -U postgres -c "SELECT pg_stop_backup()
" dbmaitre
Mot de passe pour l'utilisateur postgres : *****
ATTENTION: pg_stop_backup toujours en attente de la fin de l'archive (60 secondes passées)
ATTENTION: pg_stop_backup toujours en attente de la fin de l'archive (120 secondes passées)
ATTENTION: pg_stop_backup toujours en attente de la fin de l'archive (240 secondes passéées)
ATTENTION: pg_stop_backup toujours en attente de la fin de l'archive (480 secondes passées)
ATTENTION: pg_stop_backup toujours en attente de la fin de l'archive (960 secondes passées)
ATTENTION: pg_stop_backup toujours en attente de la fin de l'archive (1920 secondes passées)
...
J'ai paramétré postgresql.conf de la sorte (archive_timeout volontairement faible pour les tests)
# - Archiving -
archive_mode = on # allows archiving to be done
archive_command = 'xcopy /Y %p w:\%f' # command to use to archive a logfile segment
archive_timeout = 300 # force a logfile segment switch after this
et enfin le recovery.conf
restore_command = 'xcopy /Y w:\%f %p'
Merci encore
Bonjour,
Les scripts SQL des maitre et esclave faisant 218ko chacun, je vous les mets à disposition sur les URL suivantes :
[liens supprimés]
J'enlèverai ces fichiers qd vous en aurez pris connaissance.
Si vous préférez que je les poste ailleurs, n'hésitez pas à me dire où.
Cordialement
Je vous remercie de ces infos.
Je vais donc patienter avant de valider la solution que la 2.0.3 voire ultérieure soit validée.
Cordialement,
Bonnes fêtes de fin d'année.
Bonjour,
Je suis sous Windows. Les seules versions Slony 1.2.x pour Windows que j'ai trouvé sont les suivantes:
- slony-I-1.2.12R-pg82.zip
- slony-I-1.2.16R-pg83.zip
Ces 2 versions sont inférieures à la 1.2.20 dont vous parlez et sont notées comme étant pr PG 8.2 ou 8.3.
Cela peut-il fonctionner pour PG8.4?
Mon projet n'étant pas pour tout de suite, me conseillez-vous d'attendre la V2.0.x stable?
Et de manière générale, comment savoir si la version est stable étant donné que sur le site http://www.slony.info/, la V2.0.2 est noté comme "Released"?
Cordialement
Quelle version puis-je utiliser avec PG8.4 si la V2.0.2 ne doit pas l'être?
Merci encore
J'utilise la version Slony-I 2.0.2
Voici la procédure que je suis; pouvez-vous m'aider à savoir quelle étape est erronée?
dbmaitre avec une table 'tabletest' ds le schéma 'public'
dbesclave avec une table 'tabletest' (avec la même structure) ds le schéma 'public'
db1.conf
log_level=1
log_timestamp=false
cluster_name='test'
conn_info='host=127.0.0.1 user=postgres dbname=dbmaitre'
db2.conf
log_level=1
log_timestamp=false
cluster_name='test'
conn_info='host=127.0.0.1 user=postgres dbname=dbesclave'
slon –regservice
slon –addengine db1.conf
slon –addengine db2.conf
slon -listengines
Les 2 engines sont bien listés.
Dans pgAdmin,
- sur dbmaitre je créé un cluster 'test'. La création a l'air de bien se passer.
- sur dbesclave j'ajoute à un cluster existant. pgAdmin liste bien le cluster 'test', mais qd je valide, il me mets l'erreur vue ds le 1er POST.
Où ai-je manqué une étape ou, où ai-je fait une erreur?
Merci!
Au risque de dire une grosse bêtise; les 2 bases étant sur la même machine; même port.... le fait d'installer Slony sur la machine, cela ne fonctionne pas automatiquement pour les 2 bases?
Bonjour,
Je tente de mettre en place Slony-I sur PG8.4 sous Windows.
J'ai mis à jour pgAdmin en 1.10.1 pour des pb de création de cluster. Cette mise à jour faite, j'arrive à créer le cluster.
Quand je veux ajouter une base esclave (en suivant la doc http://www.pgadmin.org/docs/dev/slony-install.html), j'ai une erreur à l'étape "Joindre des nœuds supplémentaires au cluster".
2009-12-22 11:15:19 CETERREUR: la transaction est annulée, les commandes sont ignorées jusqu'à la fin du bloc de la transaction
2009-12-22 11:15:19 CETINSTRUCTION : SELECT 1;
2009-12-22 11:15:26 CETERREUR: la fonction _clusterReplication.storenode(integer, unknown, boolean) n'existe pas au caractère 8
2009-12-22 11:15:26 CETASTUCE : Aucune fonction ne correspond au nom donné et aux types d'arguments. Vous devez ajouter des conversions explicites de type.
2009-12-22 11:15:26 CETINSTRUCTION : SELECT "_clusterReplication".storenode(6, 'test', false); SELECT "_clusterReplication".enablenode(6);
2009-12-22 11:15:29 CETERREUR: la transaction est annulée, les commandes sont ignorées jusqu'à la fin du bloc de la transaction
2009-12-22 11:15:29 CETINSTRUCTION : SELECT 1;
Pour ma 1ère réplication, les 2 bases sont en local. A termes, une sera en local, l'autre déportée.
Avez-vous une idée que ce qui peut bloquer?
Merci d'avance!
OK.
C'est vraiq ue PSQL est client. Pour moi c'était aussi coté serveur, mais non.
Mes tests avec PG_DUMP/PG_RESTORE fonctionne nickel, donc, je classe l'affaire.
Je vous remercie tous des conseils que vous m'avez donné.
La seule chose que je peux certifier, c'est que je ne me suis pas amusé à modifier un fichier de plus de 1Mo.
Il me semble que que l'ai eu via PSQL -L
Si cela vous semble douteux, je pourrai le refaire.
J'oubliais, je vous confirme que le log que j'ai fourni vient bien de PSQL.
Je pense avoir compris.
L'utilisation de PG_DUMP/PSQL fonctionne en SQL soit. Mais il faut aussi que le dump soit un dump sans restriction de schéma.
Si j'utilise PG_DUMP/PG_RESTORE avec Fc ou Ft, cela fonctionne parfaitement; même avec exclusion de schéma!
Peut-être y-a-t-il une restriction à l'utilisation de l'exclusion de schéma.
Merci pour vos pistes.
Marc COUSIN,
Je me doute bien que si un schéma n'est pas sauvegardé, il ne pourra être restitué; il ne sera même pas recréé car pas ds le backup.
Dans le cas présent, les schémas présents ds le backup sont bien tous créés, mais ne sont pas tous complétés.
Dans quel cas utiliser PSQL et ds quel cas utiliser PG_RESTORE?
Bonjour,
La commande que j'utilise pour la sauvegarde est :
"pg_dump -h host -U user -p port -c -N sch_site_????????_archivage db > file.sql"
La commande que j'utilise pour la restauration est :
"psql.exe -h host -U user -p port -f script base"
