sql >> Base de Datos >  >> RDS >> PostgreSQL

Configuración de PostgreSQL para la continuidad empresarial

Continuidad comercial para bases de datos

La continuidad del negocio para las bases de datos significa que las bases de datos deben estar continuamente operativas incluso durante los desastres. Es imperativo asegurarse de que las bases de datos de producción estén disponibles para las aplicaciones todo el tiempo, incluso durante los desastres, de lo contrario, podría terminar siendo un trato costoso. Los DBA, los arquitectos deberían asegurarse de que los entornos de base de datos puedan soportar desastres y cumplan con el SLA de recuperación ante desastres. Para garantizar que los desastres no afecten la disponibilidad de la base de datos, las bases de datos deben configurarse para la continuidad del negocio.

La configuración de bases de datos para la continuidad del negocio implica una gran cantidad de arquitectura, planificación, diseño y pruebas. Muchos factores, como los centros de datos y sus territorios geográficos, incluido el diseño de la infraestructura, se tienen en cuenta cuando se trata de diseñar e implementar una estrategia eficaz de recuperación ante desastres para las bases de datos. Eso explica el hecho de que “Continuidad del negocio =Evitar interrupciones durante desastres ”.

Para garantizar que las bases de datos de producción sobrevivan a un desastre, se debe configurar un sitio de recuperación ante desastres (DR). Los sitios de producción y DR deben ser parte de dos centros de datos geográficamente distantes. Esto significa que se debe configurar una base de datos en espera en el sitio de DR para cada base de datos de producción, de modo que los cambios de datos que se produzcan en la base de datos de producción se sincronicen inmediatamente con la base de datos en espera a través de los registros de transacciones. Esto se puede lograr mediante la capacidad de "Streaming Replication" en PostgreSQL.

¿Qué debe suceder si ocurre un desastre en la base de datos de producción (o principal)?

Cuando la base de datos de producción (principal) falla o deja de responder, la base de datos en espera debe promoverse a principal y las aplicaciones deben apuntar a la base de datos en espera (nueva primaria) recientemente promovida y todo esto debe suceder automáticamente dentro del SLA de interrupción designado. Este proceso se denomina conmutación por error.

Configuración de PostgreSQL para alta disponibilidad

Como se mencionó anteriormente, para garantizar que PostgreSQL sea compatible con la recuperación ante desastres, primero debe configurarse con Streaming Replication (base de datos principal + en espera) y con capacidades automáticas de promoción/recuperación por error en espera. Veamos cómo configurar primero la replicación de transmisión y luego el proceso de "conmutación por error".

Configuración de la base de datos en espera (replicación de transmisión)

La replicación de transmisión es la función integrada de PostgreSQL que garantiza que los datos se repliquen desde la base de datos principal a la de reserva a través de registros WAL y admita métodos de replicación asíncronos y síncronos. Esta forma de replicación es bastante confiable y adecuada para entornos que exigen una replicación en tiempo real y de alto rendimiento.

Configurar el modo de espera de transmisión es bastante simple. El primer paso es asegurarse de que las configuraciones de la base de datos principal sean las siguientes:

Configuraciones obligatorias de la base de datos principal

Asegúrese de que los siguientes parámetros estén configurados en postgresql.conf en la base de datos principal. Hacer los siguientes cambios requeriría reiniciar la base de datos.

wal_level=logical

El parámetro wal_level garantiza que la información necesaria para la replicación se escriba en los archivos WAL.

max_wal_senders=1 (or any number more than 0)

Los registros WAL se envían mediante el proceso de remitente wal desde la base de datos principal a la base de datos en espera. Por lo tanto, el parámetro anterior debe configurarse con un mínimo de 1. Se requiere más de un valor de 1 cuando se requieren varios remitentes de wal.

Habilitar archivo WAL

No existe una dependencia estricta de WAL Archiving para la replicación de transmisión. Sin embargo, se recomienda encarecidamente configurar el archivado WAL porque, si el modo en espera se retrasa y si los archivos WAL requeridos se eliminan del directorio pg_xlog (o pg_wal), se necesitarán archivos de archivo para sincronizar el modo en espera con el principal. de lo contrario, el standby debe reconstruirse desde cero.

archive_mode=on
archive_command=<archive location>

La base de datos principal debe estar configurada para aceptar conexiones desde el modo de espera.

La siguiente configuración debe estar allí en pg_hba.conf

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

Ahora, realice una copia de seguridad de la base de datos principal y restáurela en el sitio DR. Una vez que haya terminado con la restauración, cree el archivo recovery.conf en el directorio de datos con el siguiente contenido:

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’

Ahora, inicie la base de datos en espera. La replicación de transmisión debe estar habilitada. El siguiente mensaje en el archivo de registro postgresql de la base de datos en espera confirma que la replicación de transmisión funciona correctamente:

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

Eso concluye que existe una replicación de transmisión completamente funcional. Siguiente paso para instalar/configurar repmgr. Antes de eso, comprendamos el proceso de conmutación por error.

Descargue el documento técnico hoy Administración y automatización de PostgreSQL con ClusterControlObtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnico

¿Qué es la conmutación por error?

La conmutación por error se produce cuando la base de datos principal deja de estar disponible por completo debido a un desastre. Durante el proceso de conmutación por error, la base de datos en espera se promoverá para convertirse en una nueva base de datos principal para que las aplicaciones puedan continuar con las operaciones comerciales.

Conmutación por error automática

Todo el proceso de conmutación por error tiene que ocurrir automáticamente para garantizar que exista una continuidad comercial efectiva y esto solo se puede lograr con algunas herramientas de software intermedio. La idea es evitar una intervención manual de DBA, desarrolladores.

Una de esas herramientas que ayuda a realizar la conmutación por error automática es "repmgr".

Echemos un vistazo a repmgr y sus capacidades.

Rep.

Repmgr es una herramienta de código abierto desarrollada por 2nd Quadrant. Esta herramienta ayuda a realizar diversas actividades administrativas de la base de datos, como crear y monitorear la replicación de PostgreSQL, incluida la realización de actividades de conmutación por error automatizadas en caso de desastre, y también ayuda a realizar operaciones de conmutación.

Repmgr es una herramienta fácil de instalar y las configuraciones tampoco son complejas. Primero echemos un vistazo a la instalación:

Instalando repmgr

Descarga la herramienta desde aquí.

Descomprima el tarball y realice la instalación como se muestra a continuación:

Instalé repmgr-4.2.0 en un host CentOS 7 e instalé repmgr contra PostgreSQL-11.1. Antes de la instalación, asegúrese de que el directorio bin de PostgreSQL sea parte de $PATH y el directorio lib de PostgreSQL sea parte de $LD_LIBRARY_PATH. Para entender que el repmgr está instalado contra PostgreSQL-11.1, estoy mostrando el resultado "make install" a continuación:

[[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/'

Configuración de repmgr para conmutación por error automática

Antes de ver la configuración de "repmgr", las bases de datos deben configurarse con la replicación de transmisión que hemos visto anteriormente. Para empezar, ambas bases de datos (principal y standby) deben configurarse con el siguiente parámetro en 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)

El parámetro anterior es para habilitar el demonio "repmgrd" que se ejecuta continuamente en segundo plano y monitorea la replicación de transmisión. Sin este parámetro, no es posible realizar una conmutación por error automática. Cambiar este parámetro necesitaría reiniciar la base de datos.
A continuación, cree el archivo de configuración repmgr (por ejemplo, con el nombre repmgr.conf) para ambas bases de datos. La base de datos primaria debe tener un archivo de configuración con los siguientes contenidos:

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

Coloque el archivo en el directorio de datos, en este caso, es "/data/pgdata11".

El archivo de configuración de la base de datos en espera debe tener el siguiente contenido:

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

Ambas bases de datos deben estar registradas con repmgr.
Registrar base de datos principal

[[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

Registrar base de datos en espera

[[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

Ejecute el siguiente comando para asegurarse de que el registro de repmgr esté funcionando.

[[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 puede observar, configuré log_level en DEBUG para generar un registro detallado en el archivo repmgr.conf del standby. Verifique los registros para ver el estado de la replicación.
Compruebe si la replicación funciona como se esperaba usando 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

El mensaje anterior confirma que la replicación funciona bien.

Ahora, si cierro la base de datos principal, el demonio repmgrd debería detectar la falla de la base de datos principal y debería promover la base de datos en espera. Veamos si eso sucede:la base de datos principal está detenida:

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

La base de datos en espera debe promoverse automáticamente. Los registros de repmgr mostrarían lo mismo:

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

Lo anterior significa precisamente que repmgr no pudo conectarse a la base de datos principal y, después de 5 intentos fallidos, la base de datos en espera se promueve a la nueva base de datos principal. A continuación se muestra lo que se muestra en los registros de la base de datos en espera promocionada (primaria nueva):


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

Solo he mencionado los parámetros importantes en el archivo de configuración repmgr. Hay muchos otros parámetros que se pueden modificar para cumplir con varios requisitos. Los otros parámetros importantes son los parámetros replication_lag_* como se muestra a continuación:

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

Repmgr verificaría los umbrales de los parámetros anteriores antes de promover el modo de espera. Si el retraso de la replicación es crítico, la promoción no seguirá adelante. Lo cual es realmente bueno porque si se promueve el modo de espera cuando hay un retraso, se produciría una pérdida de datos.

Las aplicaciones deben asegurarse de que se vuelvan a conectar con éxito al modo de espera recién promocionado dentro del plazo previsto. Los balanceadores de carga tendrían la capacidad de desviar las conexiones de la aplicación cuando la base de datos principal deja de responder. La otra alternativa sería usar herramientas de middleware como PgPool-II para garantizar que todas las conexiones se desvíen correctamente.

Para garantizar la implementación exitosa de una arquitectura de alta disponibilidad en producción, se deben realizar pruebas exhaustivas de extremo a extremo del proceso completo. En mi experiencia, solemos llamar a este ejercicio DR DRILL. Es decir, cada 6 meses más o menos, se realizaría una operación de cambio para garantizar que el modo de espera se promueva con éxito y que las conexiones de la aplicación se vuelvan a conectar al modo de espera promocionado con éxito. El primario existente se convertirá en un nuevo standby. Una vez que la operación de cambio se realiza correctamente, se eliminan las métricas para ver si se cumplen los SLA.

¿Qué es el cambio?

Como se explicó anteriormente, la conmutación es una actividad planificada en la que se intercambian los roles de la base de datos principal y de reserva. Es decir, Standby se convertirá en primario y primario se convertirá en standby. Usando repmgr, esto se puede lograr. A continuación se muestra lo que repmgr hace cuando se emite el comando de conmutación.

$ 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

¿Qué más puede hacer repmgr?

  • Repmgr puede ayudar a crear las bases de datos en espera desde cero
  • Se pueden crear varias bases de datos en espera con una maestra en ejecución
  • Se pueden construir standby en cascada, lo que creo que es más beneficioso que configurar varios standby en una base de datos maestra

¿Qué sucede si tanto el principal como el de reserva desaparecen?

Bueno, esta es una situación en la que las empresas piensan en tener varias instancias en espera. Si todos ellos se han ido, entonces, la única salida es restaurar la base de datos desde las copias de seguridad. Esta es la razón por la cual es imperativa una buena estrategia de copia de seguridad. Las copias de seguridad deben restaurarse mediante pruebas y validarse periódicamente para garantizar que las copias de seguridad sean fiables. El diseño de la infraestructura para las copias de seguridad debe ser tal que la restauración y la recuperación de las copias de seguridad no deban llevar mucho tiempo. El proceso de restauración y recuperación de las copias de seguridad debe completarse dentro del SLA designado. Los SLA para copias de seguridad están diseñados en términos de RTO (Objetivo de tiempo de recuperación) y RPO (Objetivo de punto de recuperación). Es decir, RTO:el tiempo necesario para restaurar y recuperar la copia de seguridad debe estar dentro del SLA y RPO:hasta qué punto en el tiempo se realizó la recuperación debe ser aceptable, en otros términos, es tolerancia a la pérdida de datos y, en general, las empresas dicen 0 pérdida de datos tolerancia.

Conclusión

  • La continuidad del negocio para PostgreSQL es un requisito importante para los entornos de bases de datos de misión crítica. Lograr esto implica mucha planificación y costos.
  • Los recursos y la infraestructura deben utilizarse de manera óptima para garantizar que se implemente una estrategia eficiente de recuperación ante desastres.
  • Podría haber desafíos desde la perspectiva de los costos que deben ser atendidos
  • Si el presupuesto lo permite, asegúrese de que haya varios sitios DR para la conmutación por error
  • En caso de que se deban restaurar las copias de seguridad, asegúrese de contar con una buena estrategia de copia de seguridad.