Vous n'êtes pas identifié(e).
Pages : 1
Bon ça y est, tout fonctionne.
Je me suis inspiré de la procédure dans les articles que tu m'as donnés. Je fais une sauvegarde manuelle, et pour le transfert des journaux, j'utilise un script qui les envoie à deux endroits : sur le serveur de sauvegarde de Barman comme auparavant, ainsi que dans un répertoire sur le serveur esclave. Mais je ne vois pas pourquoi ça ne fonctionnait pas auparavant avec Barman, et je voudrais bien savoir ce qui clochait. Peut être qu'en faisant la restauration avec Barman, et en conservant l'envoi des fichiers journaux sur l'esclave ça marchera. On verra si j'ai le temps de faire l'essai.
Maintenant, je m'amuse avec pgpool pour mettre en place un failover auto.
Merci pour ton aide.
Denis
Tout à fait, les 2 VMs sont identiques, à la taille du disque près.
Je viens de finir les essais sans barman, j'ai eu des problèmes d'espace disque justement. Je casse l'esclave et le remonte avant de recommencer...
Merci pour votre aide.
Tout à fait. Voici les étapes que j'ai suivi :
1 - j'ai recréé le maitre
2 - je l'ai passé à wal_level = hot_standby
3 - je l'ai redémarré
4 - j'ai mis à jour ubuntu, pour avoir la même version que l'esclave
5 - j'ai importé la base sur le maitre
6 - j'ai fait la sauvegarde du maitre avec barman
7 - j'ai restauré la base sur l'esclave toujours avec barman
8 - j'ai redémarré postgresql sur l'esclave
9 - j'ai en place la réplication : création des fichiers restore_command.sh, recovery.conf, archive_command.sh, j'ai mis dans postgresql.conf hot_standby = on
10 - Postgresql n'a pas redémarré, voici les logs :
2013-12-19 15:02:59 CET LOG: entering standby mode
2013-12-19 15:02:59 CET LOG: connection received: host=[local]
2013-12-19 15:02:59 CET [local] LOG: incomplete startup packet
bzip2: Can't guess original name for pg_xlog/RECOVERYXLOG -- using pg_xlog/RECOVERYXLOG.out
2013-12-19 15:03:00 CET LOG: connection received: host=[local]
2013-12-19 15:03:00 CET [local] FATAL: the database system is starting up
2013-12-19 15:03:00 CET LOG: restored log file "00000001000000010000005B" from archive
2013-12-19 15:03:00 CET LOG: record with zero length at 1/5B0000A8
2013-12-19 15:03:00 CET WARNING: WAL was generated with wal_level=minimal, data may be missing
2013-12-19 15:03:00 CET HINT: This happens if you temporarily set wal_level=minimal without taking a new base backup.
2013-12-19 15:03:00 CET FATAL: hot standby is not possible because wal_level was not set to "hot_standby" on the master server
2013-12-19 15:03:00 CET HINT: Either set wal_level to "hot_standby" on the master, or turn off hot_standby here.
2013-12-19 15:03:00 CET LOG: startup process (PID 2711) exited with exit code 1
2013-12-19 15:03:00 CET LOG: aborting startup due to startup process failureJ'ai beau cherché, je ne vois pas ce qui diffère de la procédure telle que décrite dans la doc officielle, si ce n'est que je me sers de barman pour la sauvegarde et que je dois décompresser les fichiers wals. Mais d'après ce que j'ai compris, barman ne fait qu'automatiser la procédure de sauvegarde manuelle, dans les logs je vois bien le select pg_start_backup() et le pg_end_backup.
Le pire, c'est que la semaine dernière tout a fonctionné du premier coup. C'est depuis que j'ai voulu refaire l'ensemble des opérations et les noter en prévision du passage en prod que ça coince...
--
Denis
Mais justement c'est ça que je ne comprends pas : sur le master, le wal_level a toujours été à hot_standby, il n'a jamais été à minimal !
Pourquoi donc ai-je ce message ? Ça va me rendre fou. Ce matin j'ai pété la VM maitre pour réinstaller ubuntu, et la première chose que j'ai faite, c'est de mettre wal_level à hot_standby et de redémarrer postgresql, avant même d'importer ma base de test. Et pourtant, j'ai encore eu ce message de wal_level à minimal... J'ai noté étape par étape ce que je faisais, je n'ai pas trouvé ce qui cloche...
J'en suis maintenant à faire une sauvegarde manuelle comme décrit dans l'article plutôt qu'avec barman, mais je crains que ça continue pareil. Un coup ça marche, je refais pareil, ça marche plus, et sans que je trouve ce qui diffère...
PS : merci pour le truc des logs à stderr, les logs sont effectivement beaucoup plus facile à lire.
Bonjour, et merci pour la réponse.
Si j'ai utilisé barman, c'est simplement que la documentation de PostgreSQL indique que les fichiers wals utilisés pour la réplication doivent être à un endroit accessible par le maitre et l'esclave. J'ai donc tout naturellement pensé au serveur de sauvegarde, pour éviter d'utiliser un autre serveur pour faire la même chose. Pour restaurer la base sur le serveur esclave avant la mise en place de la réplication, je la fais avec barman également. Ce n'est qu'une fois que la base restaurée tourne que je mets en œuvre la réplication, en demandant au serveur esclave d'aller chercher les fichiers journaux que le maitre a envoyé sur le serveur de sauvegarde. Et c'est quand j'arrive à faire tourner le réplication par transfert de fichiers journaux que je met en place la réplication par streaming, qui elle marche très bien. Est-ce les bonnes étapes : Restauration -> Réplication par fichier journal -> Réplication par streaming ?
Quant au message d'erreur indiquant que wal_level est à minimal, il a toujours été à hot_standby, du moins après l'import de la base. Je ne comprends donc pas pourquoi j'ai ce message. Je vais essayer ce matin en le mettant à hot_standby avant l'import, juste après l'installation de PostgreSQL.
Et merci pour ces deux articles que je ne connaissais pas, je vais me plonger dedans. Pour mettre en place la réplication, je m'étais basé uniquement sur la documentation officielle. J'espère trouver quelques pistes intéressantes dans ces articles.
Bonjour,
j'essaye depuis plusieurs jours de mettre en place la réplication par fichier journaux entre 2 serveurs PostgreSQL, en préalable de la réplication par streaming. Et des fois, ça fonctionne, mais plus souvent, ça ne fonctionne pas, et je n'arrive pas à savoir pourquoi ...
Voilà comment je procède ;
Je fais une sauvegarde du serveur maître avec barman. La configuration de l'archivage est configuré comme suit :
wal_level = hot_standby
checkpoint_segments = 3
checkpoint_timeout = 5min
checkpoint_completion_target = 0.5
checkpoint_warning = 30s
archive_mode = on
archive_command = 'rsync -a %p barman@backup:/var/lib/barman/master/incoming/%f'
archive_timeout = 60Je restaure cette sauvegarde sur le serveur esclave, je redémarre ma base, c'est OK, je retrouve bien mes enregistrements. Je mets donc en place la réplication par fichier journaux. Voici la partie réplication de mon postgresql.conf :
hot_standby = on
max_standby_archive_delay = 30s
max_standby_streaming_delay = 30s
wal_receiver_status_interval = 10s
hot_standby_feedback = offMon recovery.conf :
restore_command = '/var/lib/postgresql/9.1/main/restore_command.sh %f %p'
standby_mode = on
archive_cleanup_command = 'pg_archivecleanup /var/lib/postgres/9.1/main/pg_xlog %r'Mon script restore_command.sh :
#!/bin/bash
# $1: %f nom du journal souhaité
# $2: %p nom du chemin où copier le journal
scp barman@backup:master/wals/0000000100000000/$1 $2
bzip2 -d $2
mv $2.out $2Mon script archive_command.sh :
#!/bin/bash
# $1: %r le fichier le plus ancien à conservé
pg_archivecleanup /var/lib/postgres/9.1/main/pg_xlog $1Et là, je n'arrive plus à redémarrer postgresql, j'ai ça dans les logs :
2013-12-18 18:05:53.327 CET,,,2334,,52b1d5f0.91e,3,,2013-12-18 18:05:52 CET,,0,LOG,00000,"restored log file ""00000001000000000000008C"" from archive",,,,,,,,,""
2013-12-18 18:05:53.327 CET,,,2334,,52b1d5f0.91e,4,,2013-12-18 18:05:52 CET,,0,LOG,00000,"invalid record length at 0/8C0000A8",,,,,,,,,""
2013-12-18 18:05:53.411 CET,,,2334,,52b1d5f0.91e,5,,2013-12-18 18:05:52 CET,,0,WARNING,01000,"WAL was generated with wal_level=minimal, data may be missing",,"This happens if you temporarily set wal_level=minimal without taking a new base backup.",,,,,,,""
2013-12-18 18:05:53.412 CET,,,2334,,52b1d5f0.91e,6,,2013-12-18 18:05:52 CET,,0,FATAL,XX000,"hot standby is not possible because wal_level was not set to ""hot_standby"" on the master server",,"Either set wal_level to ""hot_standby"" on the master, or turn off hot_standby here.",,,,,,,""Si je mets hot_standby sur off, ça reste bloqué en démarrage : service postgresql restart me dit ok, mais je peux pas me connecter, et j'ai ça dans les logs :
2013-12-18 18:07:10.639 CET,"postgres","postgres",2413,"[local]",52b1d63e.96d,2,"",2013-12-18 18:07:10 CET,,0,FATAL,57P03,"the database system is starting up",,,,,,,,,""
2013-12-18 18:07:10.944 CET,,,2404,,52b1d63e.964,3,,2013-12-18 18:07:10 CET,,0,LOG,00000,"restored log file ""00000001000000000000008C"" from archive",,,,,,,,,""
2013-12-18 18:07:10.944 CET,,,2404,,52b1d63e.964,4,,2013-12-18 18:07:10 CET,,0,LOG,00000,"invalid record length at 0/8C0000A8",,,,,,,,,""
2013-12-18 18:07:10.964 CET,,,2404,,52b1d63e.964,5,,2013-12-18 18:07:10 CET,,0,WARNING,01000,"WAL was generated with wal_level=minimal, data may be missing",,"This happens if you temporarily set wal_level=minimal without taking a new base backup.",,,,,,,""
2013-12-18 18:07:10.967 CET,,,2404,,52b1d63e.964,6,,2013-12-18 18:07:10 CET,,0,LOG,00000,"consistent recovery state reached at 0/8C000100",,,,,,,,,""
2013-12-18 18:07:10.967 CET,,,2404,,52b1d63e.964,7,,2013-12-18 18:07:10 CET,,0,LOG,00000,"record with zero length at 0/8C000100",,,,,,,,,""
2013-12-18 18:07:11.145 CET,,,2424,"",52b1d63f.978,1,"",2013-12-18 18:07:11 CET,,0,LOG,00000,"connection received: host=[local]",,,,,,,,,""J'ai pensé à moment donné que le problème venait que barman compressait les archives, puisqu'en lui disant de ne pas les compresser, ça fonctionnait. J'ai remis la compression, ça fonctionnait. J'ai recommencé à 0, ça marche plus ... J'ai fait un md5 des fichiers archives sur le maitre et après décompression sur l'esclave, c'est le même...
J'ai pensé qu'il me mettait record with zero length at 0/8C000100 parce que je n'avais pas modifié la base après la sauvegarde et que mon fichier wal était vide, j'ai donc inséré un enregistrement, attendu que mon fichier wal arrive sur le serveur de backup, ça a marché. J'ai recommencé, ça marche de nouveau plus...
Bref, je suis incapable de voir la différence des cas où ça fonctionne, et où ça ne fonctionne pas...
PostgreSQL est en version 9.1.11 sur les deux machines, des Ubuntu Server 12.04.
Merci de votre aide, je n'ai vraiment pas la moindre idée de ce qui se passe.
J'ai trouvé...
Je lançais pgpool2 avec la commande
sudo service pgpool2 startLe problème venait du script de lancement du service. En rajoutant l'option -D dans le script pour le lancement de pgpool2, tout fonctionne normalement : les health check ont lieu sur les 2 serveurs, et les SELECT vont bien vers l'esclave !
Bonjour,
j'essaye de mettre en place un cluster de serveurs postgresql avec pgpool2, en mode maitre / esclave et load balancing, mais les requêtes select sont toujours envoyés au maitre, jamais à l'esclave.
Pour mes tests, j'utilise trois VM Ubuntu server 12.04, la première avec pgpool2 version 3.1.1, les deux autres avec postgresql 9.1. J'ai mis en place la réplication par streaming entre le maitre et l'esclave, ça marche impeccable, les enregistrements insérés dans le maitres apparaissent dans l'esclave à peine une seconde plus tard. Pour traquer les requêtes sur les différents serveurs, j'ai mis log_statement à all sur le maitre et l'esclave.
Pour exécuter mes requêtes, je me connecte sur le serveur de pool avec psql, et je peux exécuter mes requêtes, sauf que quand je regarde les logs, toutes les requête sont exécutées sur le maitre, alors que je m'attendais à ce que les SELECT sont envoyés à l'esclave. Dans les logs du maitre, je vois bien les connexions / déconnexions toutes les 10 secondes pour les health check, mais rien du tout coté esclave. Pourtant, je peux me connecter depuis la machine de pool sur l'esclave avec psql. Si je coupe le master et redémarre pgpool, au bout d'un moment, je peux me connecter sur l'esclave et lancer des requêtes dessus, mais je ne peux pas faire d'insertion, la connexion est en read only. Et après redémarrage du maitre, on n'arrive plus à s'y connecter. Avec les logs pgpool en débug, le health check répond :
Dec 12 17:51:52 pool pgpool[4434]: health_check: 0 th DB node status: 3
Dec 12 17:51:52 pool pgpool[4434]: health_check: 1 th DB node status: 1Pourtant, psql permet de s'y connecter et d'exécuter des requêtes...
Voici mon fichier pgpool.conf :
listen_addresses = '*'
port = 5432
socket_dir = '/var/run/postgresql'
pcp_port = 9898
pcp_socket_dir = '/var/run/postgresql'
# - Backend Connection Settings -
backend_hostname0 = '192.168.1.51'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/9.1/main'
backend_flag0 = 'ALLOW_TO_FAILOVER'
backend_hostname1 = '192.168.1.52'
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/9.1/main'
backend_flag1 = 'ALLOW_TO_FAILOVER'
# - Authentication -
enable_pool_hba = on
pool_passwd = 'pool_passwd' # fichier du mot de passe
authentication_timeout = 60
# - SSL Connections -
ssl = off
#------------------------------------------------------------------------------
# POOLS
#------------------------------------------------------------------------------
# - Pool size -
num_init_children = 32
max_pool = 4
# - Life time -
child_life_time = 300
child_max_connections = 0
connection_life_time = 0
client_idle_limit = 0
#------------------------------------------------------------------------------
# LOGS
#------------------------------------------------------------------------------
log_destination = 'syslog'
print_timestamp = on
log_connections = on
log_hostname = off
log_statement = on
log_per_node_statement = on
log_standby_delay = 'none'
syslog_facility = 'LOCAL0'
syslog_ident = 'pgpool'
debug_level = 0
#------------------------------------------------------------------------------
# FILE LOCATIONS
#------------------------------------------------------------------------------
pid_file_name = '/var/run/postgresql/pgpool.pid'
logdir = '/var/log/postgresql'
#------------------------------------------------------------------------------
# CONNECTION POOLING
#------------------------------------------------------------------------------
connection_cache = on
reset_query_list = 'ABORT; DISCARD ALL'
#reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT'
#------------------------------------------------------------------------------
# REPLICATION MODE
#------------------------------------------------------------------------------
replication_mode = off
#replicate_select = off
#insert_lock = on
#lobj_lock_table = ''
# - Degenerate handling -
#replication_stop_on_mismatch = off
#failover_if_affected_tuples_mismatch = off
#------------------------------------------------------------------------------
# LOAD BALANCING MODE
#------------------------------------------------------------------------------
load_balance_mode = on
ignore_leading_white_space = on
white_function_list = ''
black_function_list = 'nextval,setval'
#------------------------------------------------------------------------------
# MASTER/SLAVE MODE
#------------------------------------------------------------------------------
master_slave_mode = on
master_slave_sub_mode = 'stream'
# - Streaming -
sr_check_period = 0
sr_check_user = ''
sr_check_password = ''
delay_threshold = 0
# - Special commands -
#follow_master_command = ''
#------------------------------------------------------------------------------
# PARALLEL MODE AND QUERY CACHE
#------------------------------------------------------------------------------
parallel_mode = off
enable_query_cache = off
pgpool2_hostname = ''
# - System DB info -
system_db_hostname = 'localhost'
system_db_port = 5432
system_db_dbname = 'pgpool'
system_db_schema = 'pgpool_catalog'
system_db_user = 'pgpool'
system_db_password = ''
#------------------------------------------------------------------------------
# HEALTH CHECK
#------------------------------------------------------------------------------
health_check_period = 0
health_check_timeout = 20
health_check_user = 'nobody'
health_check_password = ''
#------------------------------------------------------------------------------
# FAILOVER AND FAILBACK
#------------------------------------------------------------------------------
#failover_command = ''
#failback_command = ''
#fail_over_on_backend_error = on
#------------------------------------------------------------------------------
# ONLINE RECOVERY
#------------------------------------------------------------------------------
recovery_user = 'postgres'
recovery_password = 'postgres'
recovery_1st_stage_command = ''
recovery_2nd_stage_command = ''
recovery_timeout = 90
client_idle_limit_in_recovery = 0
#------------------------------------------------------------------------------
# OTHERS
#------------------------------------------------------------------------------
relcache_expire = 0Je vous remercie de votre aide, ma configuration me semble correcte, je n'ai pas la moindre idée pourquoi le load balancing ne fonctionne pas.
Denis
Pages : 1