Replicacion Base de Datos PostgreSQL usando repmgr

EL presente instructivo tiene como finalidad, mostrar los pasos básicos necesario para la instalación y configuración de un proceso de replicación (maestro – esclavo) en PostgreSQL versión 9.6, utilizando repmgr versión 4.2

La replicación es la transmisión de información derivada de las modificaciones de estado, de una base de datos a otra, en pocas palabras, todas las operaciones que que modifiquen el estado de la BD se transmiten a otra BD que “replica” las operaciones, de forma que ambas BD tengan la misma información.

Dentro de las formas de replicación tenemos:

Maestro-maestro (multi-master): En éste modo, todos los nodos involucrados están en capacidad de ejecutar operaciones de Lectura/Escritura (read/writer). En pocas palabras, cualquier nodo involucrado está en capacidad de actualizar los datos. Para mantener la consistencia de los datos, el proceso de replicación involucra tareas de resolución de conflictos, en algunos casos según el número de nodos involucrados, puede aumentar la latencia en la comunicación.

Maestro-esclavo: En éste modo, todos los cambios son registrados en el nodo principal, el cual es el único habilitado para la función Lectura/Escritura (read/writer) y es el encargado de efectuar la replicación ha todos los nodos involucrados, los cuales sólo tienen capacidad para Lectura (read).
Un caso de uso típico para la replicación maestro – esclavo, con el modo en espera (standby), el esclavo funciona como una copia de seguridad del maestro y puede ser fácilmente activado en caso de un problema con el primario

repmgr es un conjunto de herramientas de código abierto para administrar la replicación y la conmutación por error en un clúster de servidores PostgreSQL. Mejora las capacidades incorporadas de Hot-Standby de PostgreSQL con herramientas para configurar servidores de reserva, monitorear la replicación y realizar tareas administrativas como failover o operaciones de cambio manual. La herramienta no replica los datos en sí, sino que le permite controlar fácilmente la reproducción, el modo de espera (hot standby) en el servidor (s) y controlar el estado de todo el proceso de replicación.

Como ya indicamos, el ejemplo que a continuación presentamos estará dirigido a la replicación maestro – Esclavo de dos nodos (master – esclavo) utilizando la herramienta repmgr.

Requisitos:

  • Se debe contar con suficiente privilegios para la configuración de aplicativos
  • Se debe contar con instalación del servicio SSH (servidor y cliente)

Plataforma:

  • Equipos de arquitectura 64 bits
  • Sistema operativo ‘GNU/Linux’ Debian versión 9.0 (actualmente estable)

Aplicaciones:

  • postgresql-9.6 -> versión 9.6.8-1.pgdg90+1
  • repmgr -> versión 4.0.4

Continuar leyendo “Replicacion Base de Datos PostgreSQL usando repmgr”

Anuncios

Promover Servidor Esclavo (Failover Master). Replicación PostgreSQL modo: Streaming Replication

El siguiente instructivo tiene como finalidad, mostrar los pasos básicos necesarios para la promoción de servidor esclavo en caso de falla del master en una repliaction modo Streaming Replication.

Si el servidor principal (master) falla, entonces el servidor esclavo debe comenzar el procedimiento de conmutación por error (failover). PostgreSQL no proporciona un software específico para identificar una falla en el servidor master y notificar al servidor esclavo, el procedimiento por tanto es manual.

Requisitos:

  • Se debe contar con suficiente privilegios para la configuración de aplicativos
  • Se debe tener instalado y ejecución la replicación de BD PostgreSQL en modo: Streaming Replication, tal como se indica en éste enlace

Plataforma:

  • Equipos de arquitectura 64 bits
  • Sistema operativo ‘GNU/Linux’ Debian versión 9.0 (actualmente estable)

A continuación se demostrará dos (02) formas de promoción, la 1era a través del archivo recovery.conf y la 2da a través del comando pg_ctlcluster con la opción “promote”

Continuar leyendo “Promover Servidor Esclavo (Failover Master). Replicación PostgreSQL modo: Streaming Replication”

Configurar Pgpool2 como Agrupación de Conexiones “Connection Pooling” de PostgreSQL

El presente instrcutivo tiene como finalidad mostrar los pasos básicos necesarios para la configuración de Pgpool2 como Agrupación de Conexiones “Connection Pooling” de PostgreSQL.

PgPool-II mantiene las conexiones establecidas a los servidores PostgreSQL, y los vuelve a utilizar cada vez que una nueva conexión con las mismas propiedades (es decir, nombre de usuario, la base de datos, la versión del protocolo) entra en acción. Reduce la conexión de arriba, y mejora el rendimiento global del sistema.

Requisitos:

  • Se debe contar con suficiente privilegios para la configuración de aplicativos
  • Se debe tener instalado el aplicativo PostgreSQL en su versión 9.6

Plataforma:

  • Equipos de arquitectura 64 bits
  • Sistema operativo ‘GNU/Linux’ Debian versión 9.0 (actualmente estable)

Instalación:

root@server:/# aptitude install pgpool2

Configuración:

1. Editar archivo de configuración de pgpool:

root@server:/# vim /etc/pgpool2/pgpool.conf

Continuar leyendo “Configurar Pgpool2 como Agrupación de Conexiones “Connection Pooling” de PostgreSQL”

Prueba de Rendimiento “Stress” en PostgreSQL con Pgbench

El presente instructivo tiene como finalidad explicar los pasos necesrios para la instalación de Pgbench y explicar su funcionamiento a través de unos ejemplos

Requisitos:

  • Se debe contar con suficiente privilegios para la configuración de aplicativos
  • Se debe tener instalado postgreSQL-Server

Plataforma:

  • Equipos de arquitectura 64 bits
  • Sistema operativo ‘GNU/Linux’ Debian versión 8.0 (actualmente estable)

Aplicaciones:

  • Pgbench versión (PostgreSQL) 9.6.5

Instalación:

root@server:/# aptitude install postgresql-contrib-9.6

Continuar leyendo “Prueba de Rendimiento “Stress” en PostgreSQL con Pgbench”

Crear Nueva Instancia/Cluster BD Postgresql

EL presente instructivo tiene como finalidad, presentar los comandos básicos necesarios para crear una nueva instancia de BD en postgresql instalado sobre debian.

En el siguiente ejemplo se creará una instancia (cluster) de postgresql versión 9.3 (aunque ha sido probado con 9.4 y 9.6) con el nombre de webapi y que se ejecutará en el puerto 5433. Actualmente se encuentra corriendo una instancia de BD, la misma es instalada por defecto por Debian en el momento de la instalación de postgresql, los datos de la instancia (cluster) son: versión 9.3 con el nombre de main, en el puerto 5432.

Comandos:
1. Listar las instancias o cluster creados (por defecto debian crea el cluster 9.3 main):

root@database:/home/operador# pg_lsclusters
Ver Cluster    Port Status Owner    Data directory                     Log file
9.3 main       5432 online postgres /var/lib/postgresql/9.3/main       /var/log/postgresql/postgresql-9.3-main.log

Continuar leyendo “Crear Nueva Instancia/Cluster BD Postgresql”

Reducir el Tiempo, Reciclar y Reusar el Estado TIME_WAIT en conexión TCP

El presente instructivo tiene como finalidad presentar los pasos básicos necesarios para la configuración en el kernel de Linux del estado TIME_WAIT de conexión TCP.
Ésta configuración puede ser utilizada para optimizar las conexiones de servicios Web o Base de Datos, aunque es recomendado configurar una aplicación para el agrupamiento de conexiones (connection pooling) o en el caso del servidor WEB el Keep-Alive.

El agrupamiento de conexiones (connection pooling) permite entre otras cosas, el manejo de una colección de conexiones abiertas a una base de datos de manera que puedan ser reutilizadas al realizar múltiples consultas o actualizaciones. En el caso de los serviodres WEB (Apache), el “Keep-Alive”, permite “mantener viva” la conexión de un cliente durante algún periodo corto de tiempo.

En aplicaciones como Mysql, PostgreSQL, Oracle, entre otros entre otros suelen aperturar y cerrar conexiones a cada instante y dependiendo del número de usuarios y la demanda (peticiones por segundo), aumenta la posibilidad de sufrir degradación del servicio.

Cuando una conexión TCP se cierra activamente, el puerto DEBE permanecer en el estado de TIME-WAIT durante un tiempo de 2xMSL (Maximum Segment Lifetime), es decir 2 minutos, tiempo en el cual la conexión esta ocupada y no puede ser reutilizado inmediatamente.

A continuación esquema(Según Protocolo de Control de Transmisión RFC: 793) secuencia normal de cierre de una conexión TCP:

       TCP A                                                TCP B

  1.  ESTABLISHED                                          ESTABLISHED

  2.  (Close)
      FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  --> CLOSE-WAIT

  3.  FIN-WAIT-2  <-- <SEQ=300><ACK=101><CTL=ACK>      <-- CLOSE-WAIT

  4.                                                       (Close)
      TIME-WAIT   <--  <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ASK

  5.  TIME-WAIT   --> <SEQ=101><ACK=301><CTL=ACK>      --> CLOSED

  6.  (2 MSL)
      CLOSED

RFC 793. TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION. 3.5. Closing a Connection. Secuencia de cierre normal. Figura 13
Continuar leyendo “Reducir el Tiempo, Reciclar y Reusar el Estado TIME_WAIT en conexión TCP”

ELementos de optimización (Tunning) PostgreSQL

EL presente instructivo tiene como finalidad configurar algunos elementos que optimizarán el funcionamiento de PostgreSQL en nuetro servidor. Se estarán efectuando recomendaciones sobre la aplicación postgreSQL y el sistema operativo, las mismas se encontran orientadas a lograr un mejor desempeño de postgresql.

Requisitos:

  • Se debe contar con suficiente privilegios para la configuración de aplicativos

Plataforma:

  • Equipos de arquitectura 64 bits
  • Sistema operativo ‘GNU/Linux’ Debian versión 6.0 (actualmente estable)

Aplicaciones:

  • PostgreSQL Versión 9.X

Nota: Las siguientes configuraciones se encuentran ajustadas para un equipo con 8GB de RAM

Puntos a Tratar en el Instructivo:

  • Punto#1. RECOMENDACIONES SOBRE APLICACION PostgreSQL
  • Punto#2. RECOMENDACIONES SOBRE SISTEMA OPERATIVO
  • Punto#3. RECOMENDACIONES SOBRE SEGURIDAD:

Punto#1. RECOMENDACIONES SOBRE APLICACION PostgreSQL

1. Editar archivo de configuración de postgreSQL

root@server:/~# nano /etc/postgresql/9.1/main/postgresql.conf

Continuar leyendo “ELementos de optimización (Tunning) PostgreSQL”