23 ago

Instalación de PostgreSQL – Parte 4 – Configuración de la replicación

Venga ya esta la última parte de manual de como instalar PostgreSQL, nos ponemos en situación.

A estas alturas debemos tener:

Un sistema de ficheros montado –> Instalación de PostgreSQL – Parte 1 – Optimización del sistema

Un PostgreSQL instalado y configurado –> Instalación de PostgreSQL – Parte 2 – Instalación y configuració

Parámetros del Kernel modificados para que trabajen bien con nuestra configuración. –> Instalación de PostgreSQL – Parte 3 – Optimización del sistema operativo

Así que ahora nos queda montar una replicación chachi para que el sistema pueda entrar en producción con alguna seguridad….

Vamos a montar una replicación Hot Standby/Streaming Replication, es una de las alternativas, yo la selecciono porque tiene las siguientes ventajas, principalmente:

  1. Consultas al servidor secundario
  2. Replicación del schema

Y cosas a tener en cuenta.

  1. Se replica toda la base de datos, no se especifican tablespaces
  2. Los dos servidores tienen que ser de 32 o 64 bits
  3. No se pueden hacer cambios en el esclavo. (No es un cluster)
  4. Enviamos registros WAL no ficheros enteros, por lo que la replicación es más rápida.

Pues dicho esto vamos al lío!

Debemos instalar el segundo servidor, el procedimiento es igual a lo explicado en los post anteriores.

Un vez instalado debemos tener el servicio apagado y empezamos por el servidor maestro.

Servidor Maestro – Configuración

Lo primero que vamos hacer es permitir que el esclavo se pueda conectar al maestro, pero con la opcion de replicacion, esto lo haremos en el fichero pg_hba.conf.

sudo vi /var/lib/pgsql/9.2/data/pg_hba.conf

Y añadimos la linea siguiente.

host replication postgres ipdelservidoresclavo/32 trust

Importante que la parte de replication seguido de un usuario con permisos de super usuario, podemos utilizar el usuario postgre o crear un usuario con la siguiente sentencia.

CREATE USER usuario WITH SUPERUSER ENCRYPTED PASSWORD 'contraseña';

Y por ultimo el tipo de autentificación trust/md5.

Ahora el fichero de postgresql.sql, explicamos los parámetros y después modificamos, así aseguramos que entendemos lo que estamos tocando.

listen_addresses = '*'

Aquí debemos asegurarnos en el caso que tengamos otro valor que *, que el servidor esclavo se va a poder conectar al maestro, sino mal vamos.

wal_level = hot_standby

Aqui le estamos diciendo que los ficheros wal se guarden en el método hot_standby con lo que nos permitirá realizar consultas en el servidor secundario.

max_wal_senders = 1

Número de conexiones que vas a permitir, aquí deberemos colocar el numero de servidores esclavos que vayamos a tener, en mi caso 1.

wal_keep_segments = 32

Aquí vamos a decirle el numero de segmentos wal que el servidor principal va a guardar antes de empezar a borrarlos o rotarlos, esto es necesario que sea un poco alto ya que un corte de conexión entre los servidores o durante las tareas de backup es posible que podamos perder la replica.

Con esto sencillos parámetros ya tenemos configurado el servidor maestro, ahora solo falta reiniciar el servicio para cargar la configuración.

Servidor Esclavo – Configuración

Pues nos vamos también al fichero postgresql.conf, donde debemos activar la opción  hot_standby

hot_standb = on

Con esta opción le decimos al servidor esclavo que permitirá las consultas.

Vale, ahora vamos por el meollo de la cuestion, debemos crear un fichero recovery.conf en el directorio $PGDATA, podemos saber cual es nuestro directorio $PGDATA haciendo lo siguiente:

cat /etc/init.d/postgresql-9.2 | grep "^PGDATA"
PGDATA=/var/lib/pgsql/9.2/data

O sea en mi caso PGDATA=/var/lib/pgsql/9.2/data, bien pues explicamos que debemos poner el recovery.conf y después lo creamos.

standby_mode = 'on'

Le decimos que el servidor arrancara el standby_mode

primary_conninfo = 'host=ipmaestro port=5432 user=postgres'

Cadena de conexión que utilizara para conectarse al maestro

Le damos permiso al usuario postgres.

chown postgres.postgres /var/lib/pgsql/9.2/data/recovery.conf

Vale pues vamos hacer la primera copia desde el servidor maestro al servidor esclavo del pg_base.

Nos vamos al servidor maestro nos conectamos al postgre y lanzamos.

psql -c "SELECT pg_start_backup('label')"

rsync -aP --exclude postmaster.pid -- exclude '*.conf' --exclude postmaster.opts /opt/PostgreSQL/9.2/ ipesclavo:/opt/PostgreSQL/9.2/

psql -c "SELECT pg_stop_backup()"

Con esto lo que estamos haciendo es, primero decirle a la base de datos que se ponga en modo backup para aseguranos la consistencia de los datos, después copiamos directamente el contenido de la BD master al esclavo excluyendo los ficheros de configuración y por ultimo sacamos a la base de datos de esta de backup.

Pues hecho eso lo único que nos queda es levantar la replica y deberemos ver algo así en el log.

LOG:  entering standby mode
LOG:  redo starts at 0/2000020
LOG:  record with zero length at 0/20001E8
LOG:  streaming replication successfully connected to primary
LOG:  consistent recovery state reached at 0/2000210
LOG:  database system is ready to accept read only connections
[  OK  ]

Así que ya tenemos nuestra replica montada!

Sentencias para comprobar el estado de la réplica.

Una buena comprobación es el fichero de log, pero ahi van unas sentencias muy interesantes.

[[email protected]] psql -h 127.0.0.1 -U postgres -c "select client_addr, state, sent_location, write_location,flush_location, replay_location from pg_stat_replication;"

client_addr  |   state   | sent_location | write_location | flush_location | replay_location
---------------+-----------+---------------+----------------+----------------+-----------------
62.73.191.194 | streaming | 0/3007C60     | 0/3007C60      | 0/3007C60      | 0/3007C60

Aqui veremos todos los clientes conectados el punto del WAL que esta utilizando y el sistema de replicación.

[[email protected] ~]# psql -h 127.0.0.1 -U postgres -c "select now() - pg_last_xact_replay_timestamp() AS replication_delay;"
replication_delay
-------------------

Esto nos mostrara el tiempo que retraso que tenemos en el esclavo respecto al maestro, comando muy util.

[[email protected] data]# ps auxww | grep ^postgres
postgres  9537  0.0  0.0 196600 10160 ?        S    Aug21   0:00 /usr/pgsql-9.2/bin/postmaster -p 5432 -D /var/lib/pgsql/9.2/data
postgres  9539  0.0  0.0 177420  1144 ?        Ss   Aug21   0:00 postgres: logger process
postgres  9540  0.0  0.0 196664  2052 ?        Ss   Aug21   0:00 postgres: startup process   recovering 000000010000000000000003
postgres  9541  0.0  0.0 196600  1816 ?        Ss   Aug21   0:00 postgres: checkpointer process
postgres  9542  0.0  0.0 196600  1372 ?        Ss   Aug21   0:00 postgres: writer process
postgres  9543  0.0  0.0 204696  3848 ?        Ss   Aug21   0:09 postgres: wal receiver process   streaming 0/3007EC0
postgres  9544  0.0  0.0 177632  1276 ?        Ss   Aug21   0:00 postgres: stats collector process

Estado de los procesos del sistema linux, donde podemos ver lo que esta haciendo.

Ale a disfrutarlo!

22 ago

Instalación de PostgreSQL – Parte 3 – Optimización del sistema operativo

Dentro del proceso de instalación de Postgre, ya hemos explicado como montar el recurso para albergar los datos de Postgre y como instalar y configurar PotgreSQL

Instalación de PostgreSQL – Parte 1 – Optimización del sistema de ficheros

Instalación de PostgreSQL – Parte 2 – Instalación y configuración de PostgreSQL

Ahora vamos a optimizar el “kernel”, bueno os explicare la mayor parte de los parámetros, pero esta vez el post estará basado en la documentación http://www.postgresql.org/docs/9.1/static/kernel-resources.html, por si queréis ampliar más información.

Lo que normalmente suele pasar es que modificamos los valores del postgres.conf olvidarnos del sistema, por ello cuando sobredimensionamos empiezan los problemas, ya que Linux se nos queda “corto”, para evitar esto debemos tener dos conceptos muy claros, la memoria compartida y los semáforos.

Bueno pues vamos por partes, primero la memoria compartida.

Los valores que vamos a tocar son lo siguientes, con su explicación pertinente.

Memoria Compartida

  • SHMMAX

El valor por defecto del núcleo es 32MB, es el tamaño de un segmento de memoria compartido. Existen varios parámetros en postgresql.conf que determinan cuanta memoria compartida necesitaremos, por ello en la mayor parte de las situaciones debemos aumentar SHMMAX como mínimo al mismo tamaño del shared_buffers, pero un poco mas siempre es mejor ya que como digo hay mas valores que comparten esta variable.

  • SHMMIN y SHMALL

El SHMMIN como os podéis imaginar es el valor mínimo y el SHMALL que debe ser SHMMAX/PAGE_SIZE, donde el PAGE_SIZE sera 4kb, lo podemos comprobar con getconf PAGESIZE.

  • fs.file-max

Numero de descripores a fichero, deberemos aumentarlo dependiendo de la ram, se puede calcular 256 por cada 4M de RAM, o ir controlando el valor cuando postgre este trabajando, de forma fácil con

lsof | wc -l

Semáforos

Bueno basándonos en la documentación las formulas para calcularlo son algo tal que así.

  • SEMMNI

ceil((max_connections + autovacuum_max_workers) / 16). El valor por defecto del núcleo suele ser 128

  • SEMMNS

ceil((max_connections + autovacuum_max_workers) / 16) * 17 + lo necesario por otras aplicaciones. El valor por defecto del núcleo suele ser 32000

  • SEMMSL

Como minimo 17. El valor por defecto del núcleo suele ser 250

  • SEMMAP

En algunos casos tiene que ser igual a SEMMNS

  • SEMVMX

Como mínimo 1000. El valor por defecto del núcleo suele ser 32767

  • SEMOPM

El valor por defecto del núcleo suele ser 32

  • SEM

Es igual a “SEMMSL SEMMNS SEMOPM SEMMNI”

Y ahora que los tenemos vamos aplicarlos al sistema, la parte de memoria primero, haremos.

vim /etc/sysctl.conf

Añadiremo o modificaremos las siguientes lineas.

kernel.shmmax = 68719476736
kernel.shmall = 4294967296
fs.file-max = 1048576

Ahora los semáforos.

Contando con la explicación se modifica con la variable kernel.sem =250     32000   32      12, en mi caso realice los cálculos que nos da la documentación y con los valores por defecto del sistema ya esta bien, pero bueno no esta de más saber como modificarlos.

Bueno resumiendo después de las tres partes debemos tener un Postgre instalado y configurado de una forma un poco diferente a la típica instalación y por norma general en el futuro nos empieza a dar problemas, por último solo nos quedara montar la replicación con eso ya tendremos un sistema listo para producción.

Ale a disfrutarlo!

20 ago

Instalación de PostgreSQL – Parte 2 – Instalación y configuración de PostgreSQL

Hoy vamos a explicar como instalar y configurar PostgreSQL, la verdad es que hay miles de documentos por internet que lo explican, pero necesito explicar ciertos valores de la configuración de PostgreSQL para poder explicar en el siguiente como configurar los parámetros del kernel.

Pues venga vamos al tema, nos ponemos en situacion, en el post anterior(Instalación de PostgreSQL – Parte 1 – Optimización del sistema de ficheros), explique como configurar y montar la partición que utilizaremos para nuestro PostgreSQL.

Pues vamos a instalarlo de forma sencilla, tenemos un RedHat 6, vamos a mirar el paquete que tenemos disponible en el repositorio y a ver si es una versión nueva, al menos la 9.2, para ver esto con un simple yum info lo veremos.

yum info postgresql.x86_64
Loaded plugins: product-id, rhnplugin, security, subscription-manager
Available Packages Name        : postgresql
Arch        : x86_64
Version     : 8.4.13 

Es mi caso tenemos una 8.4.13, era de esperar, RedHat es famoso por sus paquetes actualizados en los repositorios oficiales,  vamos a montar el repositorio oficial de PostgreSQL tal que así.

wget http://yum.postgresql.org/9.2/redhat/rhel-6-x86_64/pgdg-redhat92-9.2-7.noarch.rpm
rpm -ivh pgdg-redhat92-9.2-7.noarch.rpm
yum update
yum  --disablerepo="*" --enablerepo="pgdg92" info postgresql92-server.x86_64
Loaded plugins: product-id, rhnplugin, security, subscription-manager
Available Packages Name        : postgresql92-server
Arch        : x86_64
Version     : 9.2.4 Release     : 1PGDG.rhel6
Size        : 3.8 M Repo        : pgdg92 

Pues venga ahora a instalar.

yum  --disablerepo="*" --enablerepo="pgdg92" install postgresql92.x86_64 postgresql92-server.x86_64
service postgresql-9.2 initdb
/etc/init.d/postgresql-9.2 start

Ya esta esto instalado.

Pues vamos a por el fichero de configuración a tocar alguna cosilla, os explico las variables que vamos a tocar y después las modificamos, pensar que igual no queréis modificar las mismas o igual hay algunas que necesitáis para vuestra aplicación.

Como sabeis el fichero que debemos tocar es el postgresql.conf, pensar que esto no son reglas 100% ciertas y depende mucho de nuestro servidor y sobretodo del servicio que se le vaya a dar al postgre, en mi caso esta  destinado a DWH, asi que las valores que pongo irán encarados a este fin.

Opciones de configuración

  • listen_addresses = ‘*’

Ip por la cual estará escuchado el servicio

  • temp_buffers = 16MB

Tamaño máximo de buffers que se podrán reservar por sesión.

  • maintenance_work_mem = 3840kB

Memoria utilizada para la creación de índices, dependiendo de volumen de datos que tengamos la creación de índices puede ser muy costosa, así que es bueno no escatimar en este valor.

  • work_mem = 16MB

Uno de los valores más importantes y más despreciados, “work_mem” se refiere a la memoria temporal utilizada por cada sesión, para las operaciones de ordenamiento (ORDER BY) para las sesiones de diferenciación (GROUP … HAVING y DISTINCT) y para la gestión de hash (uniones HASH, indices HASH, hash_aggregations), si en nuestro sistema realizamos muchísimas consultas ordenadas, agrupadas, diferenciadas por cadenas, etc se crearán mucho de estos buffers de manera paralela, mientras más memoria asignemos, menos probabilidades hay que los ordenamientos y otras operaciones se hagan con archivos temporales en disco (más lentos que la memoria RAM).

  • checkpoint_completion_target = 0.9

Especifica el target of checkpoint completion

  • effective_cache_size =  22GB

Este valor es el encargado de decirle a postgre si en el proceso de optimización de la sentencia le podrá ponerla en memoria o no, así que si podemos darle un valor grandote haremos que las sentencias entren la mayoría en RAM con lo que nos ira mas rápido, una política conservadora puede ser asignar más o menos el 50% de la memoria disponible.

  • wal_buffers = 32MB

Es el tamaño de los segmentos WAL que aun no se han escrito en disco, este valor debe ser un 3% del shared_buffers, nunca menos de 64kb, pensemos que cada vez qaue grabamos la transaccion en disco es una bajada de rendimiento.

  • checkpoint_segments = 64

Numero de segmentos entre el WAL, con un numero más grande tendremos mas retención en el caso de fallo, pero tardara mas en recuperar.

  • shared_buffers = 7680kB

Es la memoria de trabajo compartida para todo el servidor postgreSQL, fíjese que por defecto en Debian GNU/Linux la opción es 24MB (y el valor por defecto si comentamos es 32MB), sin embargo, como esta es la memoria utilizada para trabajo de postgreSQL, es recomendable “al menos” el 25% de la RAM disponible (y jamás > 40%).

  • max_connections = 200

Pues eso

  • max_stack_depth = 8M

Define el tamaño del espacio utilizado para cómputo de operaciones complejas, su valor está asociado al límite máximo que un usuario (en este caso, “postgres”) tiene derecho a reservar un stack, el valor soportado por nuestro sistema operativo, que lo determinamos con “ulimit -s”, y lo modificaremos en el siguiente post.

  • superuser_reserved_connections = 3

Reservamos conexiones, por si en alguno momento tenemos la base de datos con max_connection y necesitamos entrar!

Como sabréis hay miles de opciones más, pero estas creo que son las más importantes, por supuesto os recomiendo la documentación de PostgreSQL ya que es muy buena, ahora las buscamos o añadimos en el postgresql.conf y reiniciamos el servicio.

Y con todo esto reiniciamos el servicio y ya tenemos la segunda parte de la instalación montada.

Ale a disfrutarlo!