1 architecture de déploiement
2 Host Configuration
(Host ID20)
sed -ir "s/#*max_replication_slots.*/max_replication_slots= 10/" $PGDATA/postgresql.conf
sed -ir "s/#*max_wal_senders.*/max_wal_senders = 10/" $PGDATA/postgresql.conf
sed -ir "s/#*wal_level.*/wal_level = replica/" $PGDATA/postgresql.conf
sed -ir "s/#*archive_mode.*/archive_mode = on/" $PGDATA/postgresql.conf
sed -ir "s/#*archive_command.*/archive_command = 'test ! -f \${PGHOME}\/archive\/%f \&\& cp %p \${PGHOME}\/archive\/%f'/" $PGDATA/postgresql.conf
3 récupération d'archives
(ID21)
3.1 sauvegarde Fundamentals (fonctionnement maître)
Note 1: Si la base de données avec initdb faire archives, obtenez une erreur
LOG: fichier WAL est la base de données différent système
Note 2: Pourquoi archiver?
Si le flux n'est pas la réplication continue vous utilisez l' archivage de fichiers, le serveur peut récupérer ces vieux segments WAL avant que l'ordinateur de sauvegarde reçoit le segment WAL. Si cela se produit, la machine de sauvegarde devra à partir d' une nouvelle initialisation de sauvegarde de base. En mettant en wal_keep_segments à une valeur assez élevée pour assurer que l' ancien segment de WAL ne sera pas réutilisé ou mis au rebut trop tôt comme une machine à sous copie de sauvegarde, cette situation peut être évitée. Si vous définissez une machine de sauvegarde peut accéder à l'archive WAL, vous n'avez pas besoin de ces solutions, car l'archive peut conserver suffisamment longtemps, la machine de sauvegarde pour la machine de sauvegarde peut toujours utiliser l'archive pour rattraper l'ordinateur hôte.
Etape 1: Configurer canal pg_hba.conf
Deuxième étape:pg_basebackup -Fp -P -x -D ~/app/data/pg_root21 -l basebackup21
3.2 Configuration de la récupération d'archives
cp $PGHOME/share/recovery.conf.sample ./recovery.conf
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*restore_command.*/restore_command = 'cp \/home\/gaomingjie\/app\/pgsql20\/archive\/%f %p'/" $PGDATA/recovery.conf
Machine Préparation journal (non-stop pour le dernier journal):
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000004': No such file or directory
LOG: restored log file "000000010000000000000004" from archive
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000005': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000005': No such file or directory
cp: cannot stat `/home/gaomingjie/app/pgsql20/archive/000000010000000000000005': No such file or directory
Procédé Status:
/home/gaomingjie/app/pgsql21/bin/postgres
\_ postgres: startup process recovering 000000010000000000000005
\_ postgres: checkpointer process
\_ postgres: writer process
4 flux de réplication asynchrone
(ID22)
Par la réplication en aval par défaut est asynchrone, dans ce cas, valider une transaction sur le serveur principal devient Il y a un léger décalage entre le visible et le changement dans le serveur de sauvegarde. Toutefois, ce délai que l'envoi de journaux basé sur des fichiers d'une manière beaucoup plus petite, la capacité du serveur de sauvegarde de principe est suffisante pour maintenir le retard de charge est généralement moins d'une seconde. Dans le flux de copie, pas archive_timeout pour réduire la fenêtre de perte de données. Sur les systèmes qui prennent en charge l'option prise keepalive, réglage tcp_keepalives_idle, tcp_keepalives_interval et tcp_keepalives_count contribuer au serveur principal remarquait une connexion interrompue rapidement.
4.1 Fundamentals sauvegarde (fonctionnement maître)
Etape 1: Configurer canal pg_hba.conf
Définissez les autorisations d'accès pour une bonne copie est très important, de sorte que seuls les utilisateurs de confiance peuvent lire le flux WAL, car il est facile d'extraire les informations nécessaires pour accéder à des privilèges du flux WAL. Compte en tant que serveur de sauvegarde doit avoir un super-utilisateur ou l'authentification des privilèges REPLICATION au serveur principal. Nous vous recommandons de copier pour créer un compte utilisateur dédié a des privilèges de réplication et de se connecter. Bien que le privilège REPLICATION donne un privilège très élevé, mais il ne permet pas aux utilisateurs de modifier des données sur le système principal, et vous pouvez le privilège SUPERUSER.
配置方法1（本例中不使用这种配置方法）:
pg_hba.conf:
host replication gaomingjie 127.0.0.1/32 trust
配置方法2(创建用户后使用密码校验)：
create role foo login replication password 'server@123';
pg_hba.conf:
host replication foo 127.0.0.1/32 md5
Deuxième étape:pg_basebackup -Fp -P -x -D ~/app/data/pg_root22 -l basebackup22
4,2 configuration paramètre de débit duplication
cp $PGHOME/share/recovery.conf.sample ./recovery.conf
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*primary_conninfo.*/primary_conninfo= 'host=127.0.0.1 port=9420 user=foo password=server@123'/" $PGDATA/recovery.conf
informations du journal
LOG: database system was shut down in recovery at 2017-04-27 11:46:42 CST
LOG: entering standby mode
LOG: redo starts at 0/6000028
LOG: consistent recovery state reached at 0/7000000
LOG: started streaming WAL from primary at 0/7000000 on timeline 1
Etat du processus
/home/gaomingjie/app/pgsql22/bin/postgres
\_ postgres: startup process recovering 000000010000000000000007
\_ postgres: checkpointer process
\_ postgres: writer process
\_ postgres: wal receiver process streaming 0/7000140
4.3 état de réplication Surveillance du débit
Une copie des indicateurs importants de la santé flux est généré nombre d'enregistrements WAL mais n'a pas été appliquée sur un serveur de sauvegarde sur le serveur principal. Vous pouvez écrire les dernières positions WAL WAL et le serveur de sauvegarde reçus par la comparaison du serveur principal actuel pour calculer l'hystérésis.
Ils peuvent être utilisés séparément sur pg_last_xlog_receive_location de pg_current_xlog_location sur le serveur maître et le serveur de secours pour récupérer. Dernière WAL emplacement de réception serveur de sauvegarde est également affiché dans le processus processus récepteur WAL dans l'état que l'utilisation de l' état des affichages de commande ps.
Vous pouvez pg_stat_replication de liste pour récupérer processus d'expéditeur WAL. pg_current_xlog_location de grandes différences entre le serveur maître et le sent_location de domaine sous une grande charge, et la différence entre la pg_last_xlog_receive_location de sent_location supérieur pourraient indiquer un serveur de réseau et une sauvegarde ou un retard de serveur de secours est sous une grande charge .
postgres=# select * from pg_stat_replication;
-[ RECORD 1 ]----+-----------------------------
pid | 11715
usesysid | 16393
usename | foo
application_name | walreceiver
client_addr | 127.0.0.1
client_hostname |
client_port | 51930
backend_start | 2017-04-27 14:12:57.43909+08
backend_xmin |
state | streaming
sent_location | 0/8000610
write_location | 0/8000610
flush_location | 0/8000610
replay_location | 0/8000610
sync_priority | 0
sync_state | async
5 Hot écoulement du bain de transfert asynchrone d'attente (en cascade primaire)
(ID23)
5.1 sauvegarde Fundamentals (fonctionnement maître)
Première étape: configurer les autorisations
create role foo login replication password 'server@123';
pg_hba.conf:
host replication foo 127.0.0.1/32 md5
Deuxième étape:pg_basebackup -Fp -P -x -D ~/app/data/pg_root23 -l basebackup23
La troisième étape: le noeud maître crée un écoulement du bain de transfert
SELECT * FROM pg_create_physical_replication_slot('node_slot_23');
SELECT * FROM pg_replication_slots;
-[ RECORD 1 ]-------+-------------
slot_name | node_slot_23
plugin |
slot_type | physical
datoid |
database |
active | f
active_pid |
xmin |
catalog_xmin |
restart_lsn |
confirmed_flush_lsn |
5.2 Configuration de paramètres de flux en copiant
sed -ir "s/#*hot_standby.*/hot_standby= on/" $PGDATA/postgresql.conf
cp $PGHOME/share/recovery.conf.sample ./recovery.conf
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*primary_conninfo.*/primary_conninfo= 'host=127.0.0.1 port=9420 user=foo password=server@123'/" $PGDATA/recovery.conf
sed -ir "s/#*primary_slot_name.*/primary_slot_name= 'node_slot_23'/" $PGDATA/recovery.conf
informations du journal
LOG: entering standby mode
LOG: redo starts at 0/9000028
LOG: consistent recovery state reached at 0/A000060
LOG: invalid record length at 0/A000060: wanted 24, got 0
LOG: database system is ready to accept read only connections
LOG: started streaming WAL from primary at 0/A000000 on timeline 1
Etat du processus
/home/gaomingjie/app/pgsql23/bin/postgres
\_ postgres: startup process recovering 00000001000000000000000A
\_ postgres: checkpointer process
\_ postgres: writer process
\_ postgres: stats collector process
\_ postgres: wal receiver process
L'état du noeud maître requête flux copier rainure
psql
psql (9.6.0)
Type "help" for help.
postgres=# \x
Expanded display is on.
postgres=# SELECT * FROM pg_replication_slots;
-[ RECORD 1 ]-------+-------------
slot_name | node_slot_23
plugin |
slot_type | physical
datoid |
database |
active | t
active_pid | 14799
xmin |
catalog_xmin |
restart_lsn | 0/B001148
confirmed_flush_lsn |
psql -U foo -W "dbname=postgres replication=database"
Password for user foo:
psql (9.6.0)
Type "help" for help.
postgres=> IDENTIFY_SYSTEM;
systemid | timeline | xlogpos | dbname
---------------------+----------+-----------+----------
6413518490021561706 | 1 | 0/B001148 | postgres
(1 row)
5,3 concepts de réplication de flux de rainure
fentes de copie fournissent une méthode automatisée pour garantir que le maître ne soit pas retirée avant de recevoir toute la machine back-up segment de WAL, et le maître ne supprime pas le conflit pourrait conduire à la reprise de la ligne, même si la machine de sauvegarde hors ouvrir ainsi.
Comme alternative à la copie de la fente peut également être utilisé pour prévenir wal_keep_segments enlever les vieux segments WAL, ou l' utilisation archive_command le segment stocké dans une archive. Cependant, ces méthodes entraînent souvent plus que le segment WAL requis réservés et copier uniquement la période de réservation de créneau besoin connu. Un avantage de ces méthodes est qu'elles fournissent une limite pour les besoins d' espace pg_xlog, mais n'utilisent pas la fente de copie.
De même, la protection de hot_standby vacuum_defer_cleanup_age et la ligne correspondante n'est pas supprimé sous vide, mais l'ancien ne peut pas fournir une protection pendant la machine de sauvegarde est éteint, alors que ce dernier besoin d'être mis à une valeur élevée fournissent déjà une protection adéquate. Copiez le réservoir pour remédier à ces lacunes.
5.4 pour interroger et manipuler le bain de transfert
Chaque emplacement de copie a un nom, le nom peut contenir des lettres minuscules, des chiffres et le caractère de soulignement. Copier des rainures existantes et leur statut peut être vu dans les pg_replication_slots vue.
Copie canal d'écoulement fonction de corrélation
pg_create_physical_replication_slot
pg_drop_replication_slot
pg_create_logical_replication_slot
pg_logical_slot_get_changes
pg_logical_slot_peek_changes
pg_logical_slot_get_binary_changes
pg_logical_slot_peek_binary_changes
pg_replication_origin_create
pg_replication_origin_drop
pg_replication_origin_oid
pg_replication_origin_session_setup
pg_replication_origin_session_reset
pg_replication_origin_session_is_setup
pg_replication_origin_session_progress
pg_replication_origin_xact_setup
pg_replication_origin_xact_reset
pg_replication_origin_advance
pg_replication_origin_progress
pg_logical_emit_message
Préparation 6 en cascade asynchrone
(ID24)
6.1 Fundamentals sauvegarde (opération noeud maître 23)
pg_basebackup -U foo -W -Fp -P -x -D ~/app/data/pg_root24 -l basebackup24
Note: Cette connexion ne 23 sauvegarde de base.
6.2 Configuration des paramètres duplication de flux
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*primary_conninfo.*/primary_conninfo= 'host=127.0.0.1 port=9423 user=foo password=server@123'/" $PGDATA/recovery.conf
informations du journal
LOG: database system was interrupted while in recovery at log time 2017-04-28 11:13:33 CST
HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
LOG: entering standby mode
LOG: redo starts at 0/B00D958
LOG: consistent recovery state reached at 0/B00DA38
LOG: invalid record length at 0/B00DA38: wanted 24, got 0
LOG: database system is ready to accept read only connections
LOG: started streaming WAL from primary at 0/B000000 on timeline 1
Etat du processus
/home/gaomingjie/app/pgsql23/bin/postgres
\_ postgres: startup process recovering 00000001000000000000000B
\_ postgres: checkpointer process
\_ postgres: writer process
\_ postgres: stats collector process
\_ postgres: wal receiver process streaming 0/B00DBF8
\_ postgres: wal sender process foo 127.0.0.1(58019) streaming 0/B00DBF8
/home/gaomingjie/app/pgsql24/bin/postgres
\_ postgres: startup process recovering 00000001000000000000000B
\_ postgres: checkpointer process
\_ postgres: writer process
\_ postgres: stats collector process
\_ postgres: wal receiver process streaming 0/B00DBF8
7 réplication de flux de synchronisation de redondance (archives ouvertes)
(ID25)
Lors de la demande de réplication synchrone, une opération d'écriture de chaque soumission attendra jusqu'à ce qu'il reçoive un accusé de réception indiquant que la présentation sur le serveur principal et le serveur de sauvegarde ont été écrites dans le journal des transactions sur le disque. La seule possibilité que les données seront perdues est le serveur principal et un serveur de sauvegarde en même temps se sont effondrés. Cela peut fournir un niveau de persistance plus élevé, bien que seul l'administrateur du système pour placer la relation entre les deux serveurs et la gestion. Demande de modification améliore l'utilisateur ne perd pas confiance, mais aussi augmenter inutilement le temps de réponse pour une transaction de demande. Le temps minimum d'attente est le temps de retour et vient entre le serveur principal et le serveur de sauvegarde. Les transactions en lecture seule et annulation de la transaction n'a pas besoin d'attendre une réponse serveur de sauvegarde. Validation des transactions enfant n'a pas besoin d'attendre pour un serveur de sauvegarde réponse, et seule la couche supérieure soumise seulement besoin d'attendre. opération de longue durée (par exemple, les données de chargement ou de construction d'index) sans attendre le message de soumission finale. Toutes validation en deux phases actions demandées à attendre, y compris la préparation et la soumission.
7.1 sauvegarde Fundamentals (noeud maître de commande 20)
Première étape: configurer les autorisations
create role foo login replication password 'server@123';
pg_hba.conf:
host replication foo 127.0.0.1/32 md5
Deuxième étape:pg_basebackup -U foo -W -Fp -P -x -D ~/app/data/pg_root25 -l basebackup25
Note: Cette connexion ne 20 sauvegarde de base.
La troisième étape: modifier les paramètres synchronous_standby_names.
sed -ir "s/#*synchronous_standby_names.*/synchronous_standby_names= '1 (s1)'/" $PGDATA/postgresql.conf
7.2 Configuration des paramètres duplication de flux
sed -ir "s/#*hot_standby.*/hot_standby= on/" $PGDATA/postgresql.conf
cp $PGHOME/share/recovery.conf.sample ./recovery.conf
sed -ir "s/#*standby_mode.*/standby_mode= on/" $PGDATA/recovery.conf
sed -ir "s/#*primary_conninfo.*/primary_conninfo= 'application_name=s1 host=127.0.0.1 port=9420 user=foo password=server@123'/" $PGDATA/recovery.conf
sed -ir "s/#*archive_mode.*/archive_mode = always/" $PGDATA/postgresql.conf
sed -ir "s/#*archive_command.*/archive_command = 'test ! -f \${PGHOME}\/archive\/%f \&\& cp %p \${PGHOME}\/archive\/%f'/" $PGDATA/postgresql.conf
Les informations du journal de nœud maître
LOG: standby "s1" is now a synchronous standby with priority 1
demande d'état de noeud maître double
postgres=# select * from pg_stat_replication where application_name='s1';
-[ RECORD 1 ]----+------------------------------
pid | 23543
usesysid | 16393
usename | foo
application_name | s1
client_addr | 127.0.0.1
client_hostname |
client_port | 48481
backend_start | 2017-04-28 14:45:03.051153+08
backend_xmin |
state | streaming
sent_location | 0/E0000D0
write_location | 0/E0000D0
flush_location | 0/E0000D0
replay_location | 0/E0000D0
sync_priority | 1
sync_state | sync
7.3 paramètres connexes
synchronous_commit
| valeurs | veux dire |
|---|---|
| remote_apply | Lorsque les dossiers sont soumis à rejouer le serveur de sauvegarde envoie un message de réponse, il fait la transaction devient visible. Si vous sélectionnez le serveur de sauvegarde du serveur maître de liste des priorités en tant que synchronisation de sauvegarde, décidera lors de libérer l' attente des dossiers de validation des transactions de confirmation sont reçus en conformité avec le serveur de sauvegarde et l'autre à partir du message de sauvegarde de synchronisation de réponse. Ces paramètres permettent à l'administrateur de spécifier quels serveurs doivent être synchronisés réserve de secours. Remarque la configuration de réplication synchrone principalement sur l'ordinateur hôte. Nommer le serveur de sauvegarde doit être directement connecté à l'ordinateur hôte, l'ordinateur hôte en utilisant une cascade de rien de réplication de serveur de sauvegarde en aval. remote_apply cause de chaque livraison attendra jusqu'à ce que le serveur de sauvegarde de synchronisation en cours ont indiqué qu'ils avaient rejoué la transaction, ce qui rendrait la transaction visible aux requêtes des utilisateurs. Dans le cas le plus simple, cela est compatible avec une charge de cause à effet d' équilibrage quittant une pièce. Si la demande est un arrêt rapide vers le bas, les utilisateurs cesseront d' attente. Cependant, avant l'utilisation de la réplication asynchrone, est transmis au serveur de sauvegarde des enregistrements WAL actuellement connecté à tous les non résolues, le serveur ne ferme pas complètement. |
| remote_write | Résultant dans chaque communication sont en attente d'un serveur de sauvegarde a reçu le dossier écrit et le soumettre à confirmer son propre système d'exploitation est situé, mais pas à attendre que les données soient balayées sur le disque sur le serveur de sauvegarde. Cette disposition offre une protection persistante que sur le point faible: le serveur de sauvegarde peut perdre des données en cas d'accident du système d'exploitation, bien qu'il ne soit pas un accident PostgreSQL. Cependant, dans la pratique, il est un cadre utile car elle permet de réduire le temps de réponse de la transaction. Dans le cas que lorsque le serveur principal et un serveur tombe en panne de sauvegarde et la base de données principale du serveur tout endommagé, la perte de données se produit. |
