Lors de l'utilisation d'une base de données PostgreSQL de secours, lors de l'exécution d'un grand nombre de transactions, en particulier lorsqu'une transaction d'insertion doit insérer des dizaines de millions de données (l'approche typique consiste à continuer l'insertion dans t select * from t;), le journal d'arrière-plan L'erreur est signalée comme suit:
journal au format csv:
2013-07-01 13: 25: 29.430 CST ,,, 27738,, 51d112c8.6c5a, 1,, 2013-07-01 13:25:28 CST ,, 0, LOG, 00000, "la réplication en streaming s'est connectée avec succès au primaire ",,,,,,,," libpqrcv_connect, libpqwalreceiver.c: 171 "," "
2013-07-01 13: 25: 29.430 CST ,,, 27738,, 51d112c8.6c5a, 2,, 2013-07-01 13:25:28 CST ,, 0, FATAL, XX000, "n'a pas pu recevoir les données du flux WAL: FATAL: le segment WAL demandé 0000000800002A0000000000 a déjà été supprimé
" ,,,,,,,, "libpqrcv_receive, libpqwalreceiver.c: 389 "," "
Remarques: Selon les informations d'erreur, il est facile de savoir qu'un grand nombre de xlogs sont générés dans la bibliothèque principale, et parce que postgreSQL exécute des transactions, il est envoyé à la base de données de secours lorsqu'il est soumis. Étant donné que la transaction prend trop de temps à exécuter et dépasse l'intervalle de point de contrôle par défaut, certains xlogs n'ont pas été envoyés à la base de données de secours mais ont été supprimés. Pour résoudre ce problème, les solutions généralement disponibles sont:
Tout d'abord, ajustez la valeur de
wal_keep_segments Définissez le paramètre GUC wal_keep_segments sur une valeur plus élevée , telle que 2000, et la valeur par défaut de chaque segment est 16 Mo, ce qui équivaut à 32 000 Mo, soit environ 30 Go d'espace comme espace de cache.
Cependant, cette méthode ne peut pas résoudre fondamentalement le problème. Après tout, dans un environnement de production ou un test TPCC, si une transaction doit insérer des milliards d'enregistrements, le problème peut toujours se produire.
2. Activer l'archivage L'
archivage signifie sauvegarder les xlogs qui n'ont pas été envoyés à la base de données de secours dans un certain répertoire et les restaurer dans la base de données de secours lorsque la base de données est redémarrée.
Voici des exemples de réglages des paramètres GUC:
Post 库 的 postgresql.conf 文件 中 ：
wal_level = hot_standby
archive_mode = on
archive_command = 'rsync -zaq% p postgres @ pg-slave: / var / lib / pgsql / wal_restore /% f && test! -f / var / lib / pgsql / backup / wal_archive /% f && cp% p / var / lib / pgsql / backup / wal_archive / '
archive_timeout = 300
max_wal_senders = 5
wal_keep_segments = 0 # je ne sais pas pourquoi je l'ai réglé sur ce?
Post 库 的 postgresql.conf 文件 中 ：
wal_level = hot_standby
archive_mode = on
archive_command = 'test! -f / var / lib / pgsql / backup / wal_archive /% f && cp -i% p / var / lib / pgsql / backup / wal_archive /% f </ dev / null '
hot_standby = on
wal_keep_segments = 1
Recovery 库 的 recovery.conf 文件 中 ：
standby_mode = 'on'
primary_conninfo = 'host = pg-master port = 5432 user = replicator'
restore_command = 'cp / var / lib / psql / wal_restore /% f% p'
archive_cleanup_command = ' pg_archivecleanup / var / lib / pgsql / wal_restore /% r '
3. Activer l'emplacement de réplication (disponible uniquement après pg9.4)
Cette méthode est une solution fondamentale et ne provoquera pas la perte de xlog. En d'autres termes, avant que xlog ne soit copié, il ne sera pas supprimé.
Méthode d'activation:
(1) Ajoutez postgresql.conf:
max_replication_slots = 2000
(2) Avant de copier dans la base de données de secours, la bibliothèque principale doit créer un emplacement:
postgres = # SELECT * FROM pg_create_physical_replication_slot ('node_a_slot');
slot_name | xlog_position
------------- + ---------------
node_a_slot |
postgres = # SELECT * FROM pg_replication_slots;
slot_name | slot_type | datoid | database | active | xmin | restart_lsn
------------- + ----------- + --- ----- + ---------- + -------- + ------ + -------------
node_a_slot | physique | | | f | |
(1 ligne)
(3) Ajoutez une ligne dans le fichier recovery.conf de la base de données de secours:
standby_mode = 'on'
primary_conninfo = 'host = 192.168.4.225 port = 19000 user = wslu password = xxxx'
primary_slot_name = 'node_a_slot'
Comment configurer la base de données de secours, reportez-vous à:
http://blog.csdn.net/prettyshuang/article/details/50898363#t10
Référence:
https://www.postgresql.org/docs/9.4/static/runtime-config-replication.html
https://www.postgresql.org/docs/9.4/static/warm-standby.html#CASCADING-REPLICATION
http://blog.2ndquadrant.com/postgresql-9-4-slots/
http://grokbase.com/t/postgresql/pgsql-general/13654jchy3/trouble-with-replication
http://stackoverflow.com/questions/28201475/how-do-i-fix-a-postgresql-9-3-slave-that-cannot-keep-up-with-the-master
