PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Configuration de PostgreSQL pour la continuité des activités

Continuité d'activité pour les bases de données

La continuité des activités pour les bases de données signifie que les bases de données doivent être opérationnelles en permanence, même pendant les catastrophes. Il est impératif de s'assurer que les bases de données de production sont disponibles pour les applications tout le temps, même pendant les catastrophes, sinon cela pourrait finir par être une affaire coûteuse. Les administrateurs de base de données et les architectes doivent s'assurer que les environnements de base de données peuvent supporter les sinistres et sont conformes aux accords de niveau de service de reprise après sinistre. Pour s'assurer que les sinistres n'affectent pas la disponibilité de la base de données, les bases de données doivent être configurées pour la continuité des activités.

La configuration des bases de données pour la continuité des activités implique beaucoup d'architecture, de planification, de conception et de test. De nombreux facteurs tels que les centres de données et leurs territoires géographiques, y compris la conception de l'infrastructure, entrent en considération lorsqu'il s'agit de concevoir et de mettre en œuvre une stratégie efficace de reprise après sinistre pour les bases de données. Cela explique le fait que "Continuité d'activité = Éviter les pannes lors de catastrophes ”.

Pour garantir que les bases de données de production survivent à un sinistre, un site de reprise après sinistre (DR) doit être configuré. Les sites de production et de DR doivent faire partie de deux centres de données géographiquement éloignés. Cela signifie qu'une base de données de secours doit être configurée sur le site DR pour chaque base de données de production afin que les modifications de données se produisant sur la base de données de production soient immédiatement synchronisées avec la base de données de secours via les journaux de transactions. Ceci peut être réalisé par la capacité de « réplication en continu » dans PostgreSQL.

Que doit-il se passer si une catastrophe frappe la base de données de production (ou principale) ?

Lorsque la base de données de production (principale) tombe en panne ou ne répond plus, la base de données de secours doit être promue principale et les applications doivent pointer vers la base de données de secours nouvellement promue (nouvelle principale) et tout cela doit se produire automatiquement dans le SLA d'arrêt désigné. Ce processus est appelé basculement.

Configuration de PostgreSQL pour la haute disponibilité

Comme indiqué ci-dessus, pour s'assurer que PostgreSQL est conforme à la reprise après sinistre, il doit d'abord être configuré avec la réplication en continu (base de données maître + veille) et avec des capacités de promotion/basculement automatiques en veille. Voyons d'abord comment configurer la réplication en continu, puis le processus de "basculement".

Configuration de la base de données de secours (réplication en continu)

La réplication en continu est la fonctionnalité intégrée de PostgreSQL qui garantit que les données sont répliquées de la base de données principale à la base de données de secours via des enregistrements WAL et prend en charge les méthodes de réplication asynchrone et synchrone. Cette méthode de réplication est assez fiable et adaptée aux environnements exigeant une réplication en temps réel et hautement performante.

La configuration de la veille de diffusion est assez simple. La première étape consiste à s'assurer que les configurations de la base de données principale sont les suivantes :

Configurations obligatoires de la base de données principale

Assurez-vous que les paramètres suivants sont configurés dans postgresql.conf sur la base de données principale. Les modifications suivantes nécessiteraient un redémarrage de la base de données.

wal_level=logical

Le paramètre wal_level garantit que les informations requises pour la réplication sont écrites dans les fichiers WAL.

max_wal_senders=1 (or any number more than 0)

Les enregistrements WAL sont envoyés par le processus wal sender de la base de données primaire à la base de données de secours. Ainsi, le paramètre ci-dessus doit être configuré au minimum 1. Une valeur supérieure à 1 est requise lorsque plusieurs émetteurs wal sont requis.

Activer l'archivage WAL

Il n'y a pas de dépendance matérielle à l'archivage WAL pour la réplication en continu. Cependant, il est fortement recommandé de configurer l'archivage WAL car, si le standby est en retard et si les fichiers WAL requis sont supprimés du répertoire pg_xlog (ou pg_wal), alors, les fichiers d'archive seront nécessaires pour synchroniser le standby avec le primaire. sinon, la veille doit être reconstruite à partir de zéro.

archive_mode=on
archive_command=<archive location>

La base de données principale doit être configurée pour accepter les connexions depuis la veille.

La configuration ci-dessous doit être présente dans pg_hba.conf

host    replication     postgres        <standby-database-host-ip>/32            trust

Maintenant, effectuez une sauvegarde de la base de données principale et restaurez-la sur le site DR. Une fois la restauration terminée, créez le fichier recovery.conf dans le répertoire data avec le contenu ci-dessous :

standby_mode=’on’
primary_conninfo=’host=<master-database-host-ip>, port=<master-database-port>, user=<replication-user>’
restore_command=’cp /database/wal_restore/%f %p’
trigger_file=’/database/promote_trigfile’
recovery_target_timeline=’latest’

Maintenant, démarrez la base de données de secours. La réplication en continu doit être activée. Le message ci-dessous dans le fichier journal postgresql de la base de données de secours confirme que la réplication en continu fonctionne avec succès :

2018-01-13 00:22:44 AEDT [4432]: [1] user=,db=,app=,client= LOG:  started streaming WAL from primary at 127/CD000000 on timeline 1
2018-01-13 00:22:44 AEDT [4268]: [5] user=,db=,app=,client= LOG:  redo starts at 127/CD380170

Cela conclut qu'une réplication en continu entièrement fonctionnelle est en place. Prochaine étape pour installer/configurer repmgr. Avant cela, laissez-nous comprendre le processus de basculement.

Téléchargez le livre blanc aujourd'hui PostgreSQL Management &Automation with ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blanc

Qu'est-ce que le basculement ?

Le basculement se produit lorsque la base de données principale devient complètement indisponible en raison d'un sinistre. Pendant le processus de basculement, la base de données de secours sera promue pour devenir une nouvelle base de données principale afin que les applications puissent poursuivre les opérations commerciales.

Basculement automatique

L'ensemble du processus de basculement doit se produire automatiquement pour garantir une continuité d'activité efficace et cela ne peut être réalisé que par certains outils middleware. L'idée est d'éviter une intervention manuelle des DBA, Développeurs.

L'un de ces outils qui permet d'effectuer un basculement automatique est "repmgr".

Jetons un coup d'œil à repmgr et à ses capacités.

Repmgr

Repmgr est un outil open source développé par 2nd Quadrant. Cet outil permet d'effectuer diverses activités d'administration de base de données telles que la création et la surveillance de la réplication PostgreSQL, y compris l'exécution d'activités de basculement automatisées en cas de sinistre et permet également d'effectuer des opérations de basculement.

Repmgr est un outil facile à installer et les configurations ne sont pas non plus complexes. Voyons d'abord l'installation :

Installer repmgr

Téléchargez l'outil à partir d'ici.

Décompressez l'archive et effectuez l'installation comme indiqué ci-dessous :

J'ai installé repmgr-4.2.0 sur un hôte CentOS 7 et j'ai installé repmgr sur PostgreSQL-11.1.Avant l'installation, assurez-vous que le répertoire bin PostgreSQL fait partie de $PATH et que le répertoire lib PostgreSQL fait partie de $LD_LIBRARY_PATH. Pour comprendre que le repmgr est installé sur PostgreSQL-11.1, j'affiche la sortie "make install" ci-dessous :

[[email protected] repmgr-4.2.0]# ./configure --prefix=/opt/repmgr-4.2
[[email protected] repmgr-4.2.0]# make
[[email protected] repmgr-4.2.0]# make install
Building against PostgreSQL 11
/bin/mkdir -p '/opt/pgsql-11.1/lib'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/share/extension'
/bin/mkdir -p '/opt/pgsql-11.1/bin'
/bin/install -c -m 755  repmgr.so '/opt/pgsql-11.1/lib/repmgr.so'
/bin/install -c -m 644 .//repmgr.control '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 644 .//repmgr--unpackaged--4.0.sql .//repmgr--4.0.sql .//repmgr--4.0--4.1.sql .//repmgr--4.1.sql .//repmgr--4.1--4.2.sql .//repmgr--4.2.sql  '/opt/pgsql-11.1/share/extension/'
/bin/install -c -m 755 repmgr repmgrd '/opt/pgsql-11.1/bin/'

Configuration de repmgr pour le basculement automatique

Avant de se pencher sur la configuration de "repmgr", les bases de données doivent être configurées avec la réplication en continu, comme nous l'avons vu précédemment. Pour commencer, les deux bases de données (primaire et de secours) doivent être configurées avec le paramètre suivant dans postgresql.conf :

Primary

[[email protected] log]$ grep "shared_preload" /data/pgdata11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Standby

[[email protected] log]$ grep "shared_preload" /data/pgdata-standby11/postgresql.conf
shared_preload_libraries = 'repmgr'     # (change requires restart)

Le paramètre ci-dessus permet d'activer le démon "repmgrd" qui s'exécute en continu en arrière-plan et surveille la réplication en continu. Sans ce paramètre, il n'est pas possible d'effectuer un basculement automatique. La modification de ce paramètre nécessiterait un redémarrage de la base de données.
Ensuite, créez le fichier de configuration repmgr (disons avec le nom repmgr.conf) pour les deux bases de données. La base de données principale doit avoir un fichier de configuration avec le contenu suivant :

node_id=1
node_name=node1
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2'
data_directory='/data/pgdata11'

Placez le fichier dans le répertoire data, dans ce cas, il s'agit de "/data/pgdata11".

Le fichier de configuration de la base de données de secours doit avoir le contenu suivant :

node_id=2
node_name=node2
conninfo='host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2'
data_directory='/data/pgdata-standby11'

failover=automatic
promote_command='repmgr standby promote -f /data/pgdata-standby11/repmgr.conf'
follow_command='repmgr standby follow -f /data/pgdata-standby11/repmgr.conf --upstream-node-id=%n'

monitoring_history=yes
monitor_interval_secs=5

log_file='/data/pgdata-standby11/repmgr_logs/repmgr.log'
log_status_interval=5
log_level=DEBUG

promote_check_timeout=5
promote_check_interval=1

master_response_timeout=5
reconnect_attempts=5
reconnect_interval=10

Les deux bases de données doivent être enregistrées auprès de repmgr.
Enregistrer la base de données principale

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata11/repmgr.conf primary register
INFO: connecting to primary database...
NOTICE: attempting to install extension "repmgr"
NOTICE: "repmgr" extension successfully installed
NOTICE: primary node record (id: 1) registered

Enregistrer la base de données de secours

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf standby register --upstream-node-id=1
INFO: connecting to local node "node2" (ID: 2)
INFO: connecting to primary database
INFO: standby registration complete
NOTICE: standby node "node2" (id: 2) successfully registered

Exécutez la commande ci-dessous pour vous assurer que la journalisation repmgr fonctionne.

[[email protected] ~]$ repmgrd -f /data/pgdata-standby11/repmgr.conf --verbose --monitoring-history
[2019-02-16 16:31:26] [NOTICE] using provided configuration file "/data/pgdata-standby11/repmgr.conf"
[2019-02-16 16:31:26] [WARNING] master_response_timeout/5: unknown name/value pair provided; ignoring
[2019-02-16 16:31:26] [NOTICE] redirecting logging output to "/data/pgdata-standby11/repmgr_logs/repmgr.log"

Si vous pouvez observer, j'ai configuré log_level sur DEBUG pour générer une journalisation détaillée dans le fichier repmgr.conf du standby. Vérifiez les journaux pour l'état de la réplication.
Vérifiez si la réplication fonctionne comme prévu à l'aide de repmgr :

[[email protected] pgdata-standby11]$ repmgr -f /data/pgdata-standby11/repmgr.conf cluster show
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2

Le message ci-dessus confirme que la réplication fonctionne correctement.

Maintenant, si j'arrête la base de données principale, le démon repmgrd devrait détecter l'échec de la base de données principale et promouvoir la base de données de secours. Voyons si cela se produit - La base de données principale est arrêtée :

[[email protected] ~]$ pg_ctl -D /data/pgdata-standby11 stop
waiting for server to shut down.... done
server stopped

La base de données de secours doit être promue automatiquement. Les journaux repmgr afficheraient la même chose :

fallback_application_name=repmgr is 2
[2019-02-14 17:09:23] [WARNING] unable to reconnect to node 1 after 5 attempts
[2019-02-14 17:09:23] [DEBUG] is_server_available(): ping status for host=xxx.xxx.xx.xx user=postgres dbname=postgres port=6432 connect_timeout=2 is 0
[2019-02-14 17:09:23] [DEBUG] do_election(): electoral term is 1
[2019-02-14 17:09:23] [DEBUG] get_active_sibling_node_records():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name     FROM repmgr.nodes n    WHERE n.upstream_node_id = 1      AND n.node_id != 2      AND n.active IS TRUE ORDER BY n.node_id
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - closing open connections
[2019-02-14 17:09:23] [DEBUG] clear_node_info_list() - unlinking
[2019-02-14 17:09:23] [DEBUG] do_election(): primary location is "default", standby location is "default"
[2019-02-14 17:09:23] [DEBUG] no other nodes - we win by default
[2019-02-14 17:09:23] [DEBUG] election result: WON
[2019-02-14 17:09:23] [NOTICE] this node is the only available candidate and will now promote itself
[2019-02-14 17:09:23] [DEBUG] get_node_record():
  SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name   FROM repmgr.nodes n  WHERE n.node_id = 1
[2019-02-14 17:09:23] [INFO] promote_command is:
  "repmgr standby promote -f /data/pgdata-standby11/repmgr.conf"
WARNING: master_response_timeout/5: unknown name/value pair provided; ignoring
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx fallback_application_name=repmgr"
DEBUG: connecting to: "user=postgres connect_timeout=2 dbname=postgres host=xxx.xxx.xx.xx port=6432 fallback_application_name=repmgr"
NOTICE: promoting standby to primary
DETAIL: promoting server "node2" (ID: 2) using "pg_ctl  -w -D '/data/pgdata-standby11' promote"
DETAIL: waiting up to 5 seconds (parameter "promote_check_timeout") for promotion to complete
DEBUG: setting node 2 as primary and marking existing primary as failed
NOTICE: STANDBY PROMOTE successful
DETAIL: server "node2" (ID: 2) was successfully promoted to primary

Ce qui précède signifie précisément que repmgr n'a pas pu se connecter à la base de données principale et après 5 tentatives infructueuses, la veille est promue vers la nouvelle base de données principale. Voici ce qui s'affiche dans les journaux de la base de données de secours promue (nouveau primaire) :


2019-02-14 17:09:21 AEDT [20789]: [1] user=,db=,app=,client= FATAL:  could not connect to the primary server: could not connect to server: Connection refused
                Is the server running on host "xxx.xxx.xx.xx" and accepting
                TCP/IP connections on port 5432?
2019-02-14 17:09:23 AEDT [20506]: [7] user=,db=,app=,client= LOG:  received promote request
2019-02-14 17:09:23 AEDT [20506]: [8] user=,db=,app=,client= LOG:  redo done at 10F/5A335FF0
2019-02-14 17:09:23 AEDT [20506]: [9] user=,db=,app=,client= LOG:  last completed transaction was at log time 2019-02-14 17:08:38.350695+11
2019-02-14 17:09:23 AEDT [20506]: [10] user=,db=,app=,client= LOG:  selected new timeline ID: 2
2019-02-14 17:09:23 AEDT [20506]: [11] user=,db=,app=,client= LOG:  archive recovery complete
2019-02-14 17:09:24 AEDT [20507]: [1] user=,db=,app=,client= LOG:  checkpoint starting: force
2019-02-14 17:09:24 AEDT [20504]: [7] user=,db=,app=,client= LOG:  database system is ready to accept connections

Je n'ai mentionné que les paramètres importants dans le fichier de configuration de repmgr. Il existe de nombreux autres paramètres qui peuvent être modifiés pour répondre à diverses exigences. Les autres paramètres importants sont les paramètres replication_lag_* comme indiqué ci-dessous :

#replication_lag_warning=300            # repmgr node check --replication-lag
#replication_lag_critical=600           #

Repmgr vérifierait les seuils des paramètres ci-dessus avant de promouvoir la veille. Si le délai de réplication est critique, la promotion n'aura pas lieu. Ce qui est vraiment bien car si la veille est promue lorsqu'il y a un décalage, cela entraînerait une perte de données.

Les applications doivent s'assurer qu'elles se reconnectent avec succès à la veille nouvellement promue dans le délai prévu. Les équilibreurs de charge auraient la capacité de détourner les connexions d'application lorsque la base de données principale ne répond plus. L'autre alternative serait d'utiliser des outils middleware comme PgPool-II pour s'assurer que toutes les connexions sont détournées avec succès.

Pour s'assurer qu'une architecture haute disponibilité réussie est déployée en production, des tests approfondis de bout en bout de l'ensemble du processus doivent être effectués. D'après mon expérience, nous appelons cet exercice DR DRILL. Cela signifie que tous les 6 mois environ, une opération de basculement serait effectuée pour s'assurer que la mise en veille est correctement promue et que les connexions de l'application se reconnectent avec succès à la mise en veille promue. Le primaire existant deviendra un nouveau standby. Une fois l'opération de basculement réussie, les métriques sont supprimées pour vérifier que les SLA sont respectés.

Qu'est-ce que le basculement ?

Comme expliqué ci-dessus, le basculement est une activité planifiée dans laquelle les rôles des bases de données principale et de secours sont inversés. Cela signifie que Standby deviendra primaire et primaire deviendra standby. En utilisant repmgr, cela peut être réalisé. Vous trouverez ci-dessous ce que fait repmgr lorsque la commande de basculement est émise.

$ repmgr -f /etc/repmgr.conf standby switchover
    NOTICE: executing switchover on node "node2" (ID: 2)
    INFO: searching for primary node
    INFO: checking if node 1 is primary
    INFO: current primary node is 1
    INFO: SSH connection to host "node1" succeeded
    INFO: archive mode is "off"
    INFO: replication lag on this standby is 0 seconds
    NOTICE: local node "node2" (ID: 2) will be promoted to primary; current primary "node1" (ID: 1) will be demoted to standby
    NOTICE: stopping current primary node "node1" (ID: 1)
    NOTICE: issuing CHECKPOINT
    DETAIL: executing server command "pg_ctl -D '/data/pgdata11' -m fast -W stop"
    INFO: checking primary status; 1 of 6 attempts
    NOTICE: current primary has been cleanly shut down at location 0/0501460
    NOTICE: promoting standby to primary
    DETAIL: promoting server "node2" (ID: 2) using "pg_ctl -D '/data/pgdata-standby11' promote"
    server promoting
    NOTICE: STANDBY PROMOTE successful
    DETAIL: server "node2" (ID: 2) was successfully promoted to primary
    INFO: setting node 1's primary to node 2
    NOTICE: starting server using  "pg_ctl -D '/data/pgdata11' restart"
    NOTICE: NODE REJOIN successful
    DETAIL: node 1 is now attached to node 2
    NOTICE: switchover was successful
    DETAIL: node "node2" is now primary
    NOTICE: STANDBY SWITCHOVER is complete

Que peut faire d'autre repmgr ?

  • Repmgr peut aider à créer les bases de données de secours à partir de zéro
  • Plusieurs bases de données de secours peuvent être créées avec un maître en cours d'exécution
  • Des standby en cascade peuvent être construits, ce qui me semble plus avantageux que de configurer plusieurs standbys sur une base de données principale

Que se passe-t-il si l'élément principal et l'élément de secours ont disparu ?

Eh bien, c'est une situation dans laquelle les entreprises envisagent d'avoir plusieurs instances de secours. Si tous ont disparu, la seule solution consiste à restaurer la base de données à partir des sauvegardes. C'est la raison pour laquelle une bonne stratégie de sauvegarde est impérative. Les sauvegardes doivent être testées et validées régulièrement pour garantir la fiabilité des sauvegardes. La conception de l'infrastructure pour les sauvegardes doit être telle que la restauration et la récupération des sauvegardes ne doivent pas prendre longtemps. Le processus de restauration et de récupération des sauvegardes doit être effectué dans le cadre du SLA désigné. Les SLA pour les sauvegardes sont conçus en termes de RTO (Recovery Time Objective) et RPO (Recovery Point Objective). Autrement dit, RTO :le temps nécessaire pour restaurer et récupérer la sauvegarde doit être compris dans le SLA et le RPO :jusqu'à quel moment la récupération a été effectuée doit être acceptable, en d'autres termes, il s'agit de la tolérance à la perte de données et généralement les entreprises disent 0 perte de données tolérance.

Conclusion

  • La continuité des activités pour PostgreSQL est une exigence importante pour les environnements de bases de données stratégiques. Cela implique beaucoup de planification et de coûts.
  • Les ressources et l'infrastructure doivent être utilisées de manière optimale pour garantir la mise en place d'une stratégie efficace de reprise après sinistre.
  • Il pourrait y avoir des défis du point de vue des coûts qui doivent être pris en compte
  • Si le budget le permet, assurez-vous qu'il existe plusieurs sites DR à basculer
  • Si les sauvegardes doivent être restaurées, assurez-vous qu'une bonne stratégie de sauvegarde est en place.