Instalación de PostgreSQL básica

PostgreSQL es una de las grandes maravillas del software libre, robusto, potente, altamente funcional, distribuido en miles de formas posibles (greenplum=clusterizador masivo, postgres Plus=”imitador” de Oracle,deepgreen=granjas de datawarehousing con postgreSQL, etc) puede ser optimizado (como todo lo que es software libre) de maneras inimaginables para cada necesidad específica. Entonces, ¿por qué hay gente que denigra de él? …

El primer error que comete la gente, es pretender que un sistema tan necesario como la base de datos, sea utilizado “directamente” luego de su instalación; un detalle de distribuciones Linux como Debian, es no optimizar para ningún aspecto (ya que son meta-distribuciones genéricas sin una orientación específica).

Mientras Oracle saca libros de 900 páginas de cómo optimizar el hardware al máximo, sistema de archivos, sistema operativo y la base de datos como tal, mucha gente piensa “migrar” a postgreSQL ejecutando un “aptitude install postgresql” y dejándolo así … nada más perdido y lejos de la realidad.

Acá, ejecutaremos una instalación que debería ser “básica”, la más básica, para un entorno pequeño de datos, para que sus sistemas “rindan”.

Preámbulo

Entre los aspectos más importantes de postgreSQL destaca que “no debería” compartir acceso a disco con el sistema operativo, esto es, si es posible que postgreSQL esté en una partición distinta a “root” (incluso un disco separado, de ser recomendable); por lo que la opción “instalar y usar” no debería ser para instalaciones en producción de postgreSQL 9.1.

Hay que tomar en cuenta que postgreSQL (como cualquier otra base de datos) debería ser optimizada posteriormente a su instalación de manera correcta, una de las optimizaciones más necesarias (pero que casi nadie sigue) es gestionar los espacios de datos y separarlos del tablespace pg_default (que gestiona la DB “postgres”, la DB de “information_schema” y demás información, por lo general en “/var/lib/postgresql/9.1/main”); además, ambos deberían estar separados de la partición raíz donde está el sistema operativo.

Las optimizaciones acá realizadas son de las más sencillas a nombrar para postgreSQL, se tomó una máquina virtual en Xen 4.1 en una portátil y se optimizó de lo más básico, para demostrar, que hasta en los cambios más sencillos, pueden afectar el “performance” de aplicaciones diseñadas con postgreSQL.

Preparación primaria

Si nos encontramos instalando un servidor de datos, lo primero que deberiamos pensar es en separar el montaje de /var del resto del sistema, de hecho, si podemos incluso separar /var/log sería muy apropiado; también es bueno separar /tmp (más 1Gb es innecesario) ya que si no separamos /tmp, Debian GNU/Linux utilizará un tmpfs montado en RAM para gestionar /tmp (restándonos un poco de RAM para trabajar, además que postgreSQL no utiliza la partición /tmp).

Un esquema básico podría ser:

• / (raiz) (Debian GNU/Linux no ocupa más de 5Gb en este modo)
• /tmp (1Gb como máximo)
• swap (Lo necesario, aunque no mayor a 2GB en sistemas con más de 4Gb de RAM)
• /var (2~4GB ya que será un servidor en producción)

Y de resto, un volumen lógico (LVM) que podemos modificar de tamaño de acuerdo a nuestra necesidad.

Luego de instalado el sistema, procedemos a instalar PostgreSQL.

Instalación

La instalación de postgreSQL 9.1 en Debian GNU/Linux es bastante sencilla:

• Instalamos postgreSQL 9.1 (pero así no se debería quedar):

  apt-get install postgresql-9.1

PostgreSQL por defecto, creará una carpeta de configuración en: /etc/postgresql/9.1/main/

Y creará un espacio de datos en: /var/lib/postgresql/9.1/main/

Que no utilizaremos para nuestra base de datos, ya que crearemos un espacio propio.

Configuración inicial

Siempre es recomendable dejar el usuario “postgres” (el super-usuario de PostgreSQL) como un usuario “para accesos de emergencia”, ya que este usuario tiene garantizado el acceso a todas partes(si eres root en el sistema), es recomendable que NINGUNA base de datos tenga como “owner” el usuario postgres (y evitar en lo posible utilizarlo como usuario de acceso desde sistemas, aunque esto, obviamente lo he visto más de una vez ocurrir hasta en sistemas web).

• Creamos un super-usuario para nuestras necesidades, primero cambiamos al usuario postgres:

  su postgres

• Creamos un usuario, que será nuestro “super-usuario” para “nuestros” accesos, evitando así el usuario postgres:

  
  createuser -sPl jesuslara
  
  
  - ingresamos nuestra contraseña
  
  -Enter password for new role: 
  
  
  Enter it again:

• Ejecutamos la consola SQL de postgreSQL:

  psql

• Garantizamos al usuario que creaste acceso irrestricto sobre el la DB postgres:

  
  psql (9.1.3)
  
  Type "help" for help.
  
  ostgres=# grant all on database postgres to jesuslara;
  
  
  pGRANT
  

Y salimos de la consola:

postgres=#\quit

Configuración de postgreSQL

• Accedemos al directorio /etc/postgresql/9.1/main

  cd /etc/postgresql/9.1/main

• Si vamos a acceder de manera remota a nuestro postgreSQL, agregamos la siguiente línea al archivo pg_hba.conf:

  
  # la forma es:
  
  # host -> database (all: todas las db) -> usuario (all: todos los usuarios) -> subnet (de nuestra red) -> modo de clave
  
  host    all     jesuslara       192.168.100.0/24        md5
  

• Habilitamos el acceso remoto en nuestro postgreSQL:

archivo /etc/postgresql/9.1/main/postgresql.conf

listen_addresses = '*'

Optimización del archivo postgresql.conf

• Y cambiamos algunas opciones básicas del archivo postgresql.conf:

  shared_buffers = 256MB

‘shared_buffers’: 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%).

temp_buffers = 16MB

‘temp_buffers’: La memoria temporal utilizada por cada sesión para las tablas temporarias y para apertura de tablas en cada sesión de cada base de datos, tome en cuenta que este valor dependerá obviamente de la cantidad de datos que carga cada sesión y dependerá muchísimo del sistema que se utiliza.

work_mem = 16MB

‘work_mem’: 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).

max_stack_depth = 8MB

‘max_stack_depth’: 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 nuestra distribución se determina con “ulimit -s”.

shared_preload_libraries = '$libdir/plpython2.so'

‘shared_preload_libraries’: Permite cargar una librería específica cuando arranca el sistema, si utilizamos muchos procedimientos almacenados en un lenguaje específico (ej: python, perl, tcl, java, etc), es bueno pre-cargarla para que esté disponible cuando se utilice por primera vez. Nota: esta opción ralentiza un poco el reinicio del sistema.

bgwriter_delay = 500ms

‘bgwriter_delay’: El background-writer es un proceso del servidor que se encarga de escribir a disco todos los “shared_buffers” modificados, este proceso conlleva una carga de I/O sobre el disco, su modificación permite o reducir el valor para evitar en lo más posible pérdidas de datos en equipos que pueden fallar, o su incremento permite reducir el I/O al disco duro en sistemas perfectamente protegidos.

Modificados estos parámetros básicos, vamos a modificar nuestro sistema operativo.

Fuente:enlace