Guía rápida de PostgreSQL

1.  Introduction

Algunas cosas acerca de PostgreSQL

PostgreSQL es un sistema de base de datos relacional (RDBMS). Soporta muchas características de estos sistemas como transacciones, esquemas y claves ajenas y a menudo se le considera más segura y que cumple mejor los estándares SQL que cualquier otra base de datos bien sea comercial o de otro tipo.

Visite la página Acerca de (en inglés) en postgresql.org para más información.

Lo que cubre este documento

Este documento le guiará a través de los pasos específicos que se deben realizar para instalar la base de datos relacional PostgreSQL en Gentoo.

Los ebuilds cubiertos en este artículo son los siguientes: dev-db/postgresql-docs, dev-db/postgresql-base y dev-db/postgresql-server.

En este documento se presupone que va a instalar la última versión estable de PostgreSQL. En el momento de escribir este documento, esta versión es la 9.0.3. Modifique las ordenes indicadas en este documento de forma adecuada para especificar la versión.

Sobre los ebuilds

Los ebuilds de PostgreSQL en Portage se caracterizan por estar basados en ranuras (slots) para su versión principal. Esto le permite tener dos versiones principales de PostgreSQL funcionando a la vez, las librerías y servidores de la 8.4 y la 9.0 puede estar instaladas en el mismo sistema. Esto es útil en aquellas circunstancias en que necesite mover datos de una base de datos antigua a una nueva, o necesite tener una base de datos en producción y una de pruebas en la misma máquina. También, esto evita que una base de datos o sus librerías y ejecutables sean sobreescritos por una actualización incompatible. Esto requeriría una migración que también se cubre en esta guía.

Además, las correcciones de fallos y de seguridad que se envían a través de las actualizaciones de versiones menores, se pueden aplicar sin el miedo de corromper la base de datos o la instalación de PostgreSQL. Se puede actualizar la versión 9.0.2 a la 9.0.3 ya que su compatibilidad está garantizada y no requiere interacción por su parte salvo hacer emerge y reiniciar el proceso servidor; ninguna migración, reconfiguración o inicialización son necesarias.

Lea la Política de versiones de PostgreSQL (en inglés) para más información.

Qué aspectos no cubre este documento

Algunos aspectos de PostgreSQL no se cubren en este documento. La documentación oficial (en inglés) tiene cerca de 2.000 pages, por lo que muchos detalles quedarán fuera de esta guía de inicio. Únicamente se cubrirán los aspectos específicos de Gentoo y algunas pautas básicas de configuración.

2.  Instalación

Los ebuilds obsoletos

Si tiene alguno de los siguientes ebuilds instalados, entonces su sistema tiene instalada una versión antigua y obsoleta de PostgreSQL para Gentoo y debería migrar inmediatamente: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq y/o dev-db/postgresql.

Este documento cubre la migración desde los antiguos ebuilds a los nuevos.

Ajustes USE

Comienzo de la instalación

# emerge -av dev-db/postgresql-server

[ebuild N ] dev-db/postgresql-docs-9.0.3 0 kB
[ebuild N ]dev-db/postgresql-base-9.0.3 USE="doc nls pam readline ssl zlib
  -kerberos -ldap -pg_legacytimestamp -threads" LINGUAS="-af -cs -de -es -fa -fr
  -hr -hu -it -ko -nb -pl -pt_BR -ro -ru -sk -sl -sv -tr -zh_CN -zh_TW" 0 kB
[ebuild N ] dev-db/postgresql-server-9.0.3 USE="doc nls perl python
  -pg_legacytimestamp (-selinux) -tcl -uuid -xml" LINGUAS="-af -cs -de -es -fa
  -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -ru -sk -sl -sv -tr -zh_CN -zh_TW" 0 kB

Puede que reciba una notificación indicando que algunos de los paquetes de arriba están bloqueados por alguno de los siguientes paquetes: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq o dev-db/postgresql. Estos paquetes ya no se mantienen y por tanto son obsoletos. Consulte la sección de migración para saber cómo tratar esta situación.

Preparación para la inicialización del cluster de base de datos

Una vez que se ha terminado la instalación de los paquetes puede que desee editar el fichero /etc/conf.d/postgresql-9.0. Hay tres líneas dentro de él que afectan el comportamiento por defecto del servidor y que no pueden cambiarse más adelante sin borrar el directorio que contiene el cluster de la base de datos y reinicializar.

PGDATA define el lugar donde se almacenan los ficheros de configuración. DATA_DIR define el lugar donde se creará el cluster de base de datos y ficheros relacionados. PG_INITDB_OPTS puede contener opciones extra que debe tener cuidad al definir. Las opciones extra no son obligatorias y los valores por defectos son, ejem..., razonables.

En el siguiente ejemplo, PGDATA muestra que los ficheros de configuración están almacenados en /etc/postgresql-9.0/. DATA_DIR muestra que el cluster de base de datos debe instalarse en /var/lib/postgresql/9.0/data/, que es el valor por defecto. Recuerde que es una muy buena idea, mantener la versión mayor en el nombre de la ruta. PG_INITDB_OPTS muestra que la localización por defecto debe ser en_ES.UTF-8. Esto es, orden y formateo usando el idioma español de España codificación de caracteres UTF-8.

# Location of configuration files
PGDATA="/etc/postgresql-9.0/"

# Where the data directory is located/to be created
DATA_DIR="/var/lib/postgresql/9.0/data"

# Additional options to pass to initdb.
# See 'man initdb' for available options.
PG_INITDB_OPTS="--locale=es_ES.UTF-8"

Existen seis opciones de localización que se pueden sobreescribir con --locale=. La siguiente tabla muestra las seis opciones que, en caso de ser utilizadas, serán formateadas como: --opción=lo_LO.CODIFICACIÓN.

Por ejemplo, si quiere que el idioma por defecto de las bases de datos sea el español de España, pero quiere que los mensajes aparezcan, digamos, en Sueco, entonces su variable PG_INITDB_OPTS tendría este aspecto:

PG_INITDB_OPTS="--locale=en_ES.UTF-8 --lc-messages=sv_SE.UTF-8"

Se puede encontrar una lista completa de idiomas y codificaciones de caracteres soportados por el servidor en la documentación, sin embargo, recuerde que para que esto funciones, su sistema debe tener soporte para los respectivos idiomas y codificaciones de caracteres. Compare la salida de locale -a con las codificaciones listadas en la documentaciones.

Puede cambiar la localización y codificación seleccionadas en el momento de crear la base de datos. Para cambiar la localización de la base de datos una vez creada, tendrá que eliminarla y comenzar de nuevo.

# emerge --config dev-db/postgresql-server:9.0

Esto creará el cluster de base de datos y almacenará los ficheros relacionados con el servidor en PGDATA y DATA_DIR.

3.  Configuración

Localización de los ficheros de configuración

En esta sección nos centraremos en los ficheros presentes en el directorio PGDATA, /etc/postgresql-9.0, con especial relevancia en postgresql.conf y pg_hba.conf.

postgresql.conf

Este es el fichero de configuración principal. Una línea que puede tener un especial interés es listen_addresses. Esta variable define a qué direcciones PostgreSQL se ceñirá. Por defecto, únicamente se utilizan localhost y el zócalo (socket) Unix. Cambiar listen_addresses no es suficiente para permitir conexiones remotas. Esto se cubrirá en la siguiente sección. La documentación oficial es fácil de comprender y bastante exhaustiva en todos los ajustes disponibles. Le animo a leerla ya que algunas cosas comentadas aquí pueden haber cambiado.

De un interés secundario es el destino del registro. Por defecto, todo es registrado en postmaster.log en el directorio DATA_DIR. Existe una subsección completa en postgresql.conf que cubre un montón de opciones acerca de cómo, qué y dónde registrar. Esta subsección está etiquetada como: ERROR REPORTING AND LOGGING.

Aparte de listen_addresses y las opciones de registro, el resto de valores por defecto en postgresql.conf son los suficientemente razonables para que todo funcione correctamente.

pg_hba.conf

El fichero pg_hba.conf indica a quién se permite la conexión al servidor de base de datos y qué método de autenticación se debe utilizar para establecer esta conexión. De nuevo, la documentación es lo suficientemente exhaustiva acerca de los ajustes y lo que éstos significan, sin embargo, algunas cosas se cubren aquí para que queden más claras.

# TYPE  DATABASE    USER        CIDR-ADDRESS          METHOD

# "local" is for Unix domain socket connections only
local   all         all                               trust
# IPv4 local connections:
host    all         all         127.0.0.1/32          trust
# IPv6 local connections:
host    all         all         ::1/128               trust

Como ya se ha mencionado anteriormente, el servidor por defecto es seguro. O al menos debería. Por defecto, hay únicamente un rol de base de datos disponible para conectarse: postgres. La única forma de iniciar una conexión a la base de datos es a través del zócalo (socket) Unix /var/run/postgresql/.s.PGSQL.5432, cuyo propietario es el usuario y grupo de sistema postgres, la conexión a través de localhost también es posible. En lo que se refiere al anterior "debería ser seguro": Cualquier usuario del sistema puede conectarse a la base de datos a través de locahost. Incluso como el superusuario de la base de datos postgres.

Por el contrario, para realizar una conexión a través del zócalo Unix, los usuarios — incluyendo los usuario de otros servicios como apache — deben pertenecer al grupo del sistema postgres. Utilice gpasswd -a usuario postgres para al usuario usuario al grupo postgres. Las conexiones de los usuarios que no estén en el grupo postgres serán rechazadas con el mensaje "Permission denied" (Permiso denegado).

El método trust (confiable) permite a cualquier conectarse a la base de datos sin usar una contraseña. Especifica exactamente lo que indica: Confía en todas las conexiones para el tipo dado a la base de datos dada para el usuario dado (pero no el usuario del sistema) desde la localización dada sin necesidad de contraseña. Esto permite que cualquier usuario del sistema pueda conectarse como otro usuario a través de una conexión localhost. Esto no es tan peligroso como parece, pero implica un riesgo de seguridad en la mayoría de las circunstancias.

Los dos métodos que probablemente utilice son: password (contraseña) y md5. El método password method únicamente especifica que se necesita una contraseña válida para iniciar una conexión a la base de datos y que esa contraseña es enviada "de forma clara". Este método es correcto cuando esta información no salga nunca de la máquina, como una conexión a través del zócalo Unix o de localhost. El método md5 es similar al método password pero utiliza un hash md5 para evitar el envío de la contraseña en claro. Este método es el que se debe utilizar cuando la contraseña va a viajar por una red.

En este punto, al autor del documento le gustaría incidir en las dos últimas líneas (cuatro últimas si incluimos los comentarios) del fichero pg_hba.conf. PostgreSQL tiene soporte nativo de IPv6 a pesar de que no se desee este soporte. Además, las direcciones IPv4 se mapean automáticamente a IPv6, esto es, 127.0.0.1 se mapeará a :FFFF:127.0.0.1 y a una IPV6 "pura" ::FFFF:7F00:0001.

Sin embargo, parece existir alguna confusión acerca de cómo los nombres de los servidores se mapean a direcciones IP addresses. Echemos un vistazo al fichero /etc/hosts.

# IPv4 and IPv6 localhost aliases
127.0.0.1       localhost
::1             localhost

En el ejemplo de arriba, se puede comprobar que tanto las direcciones IPv4 como las IPv6 IP se mapean a localhost. Cuando psql lee este fichero, usará la primera coincidencia y la usará como la dirección de acceso, en este caso 127.0.0.1. Cuando PostgreSQL analiza esto, también coincidirá también con la dirección formateada IPv6 formatted address, por ejemplo la ::ffff:127.0.0.1. Si, por el contrario, la dirección IPv6 aparece en primer lugar, entonces psql mapeará localhost a ::1, y ::1 no es lo mismo que ::ffff:127.0.0.1. Por lo tanto, si no tiene a ::1 como una dirección de acceso permitida, psql no podrá establecer la conexión. Además de todo esto, su núcleo debe tener soporte para el protocolo IPv6 protocol.

Por lo tanto, es mejor indicar una única dirección IP a psql y en pg_hba.conf en lugar de tener que depender de que el fichero /etc/hosts esté ordenado de forma adecuada, así se elimina cualquier duda de qué direcciones está permitidas o a qué servidor se realizará la conexión.

4.  Arrancando el servidor

¡Pruébelo!

Arranque ahora PostgreSQL y defina la contraseña para el superusuario de la base de datos postgres. Las siguientes órdenes se deben ejecutar con el usuario 'root' tal y como se muestra a continuación:

(Cambie 'trust' a 'password' para las conexiones a localhost)
# nano -w /etc/postgresql-9.0/pg_hba.conf
# /etc/init.d/postgresql-9.0 start
postgresql-9.0  | * Starting PostgreSQL ...                             [ ok ]

(Abra una conexión al servidor y cambie la contraseña)
# psql -U postgres
psql (9.0.3)
Type "help" for help.

postgres=# \password
Enter new password:
Enter it again:
postgres=# \q

(Cambie 'trust' a 'password' para la conexión local)
# nano -w /etc/postgresql-9.0/pg_hba.conf
# /etc/init.d/postgresql-9.0 reload
postgresql-9.0 | * Reloading PostgreSQL configuration ...               [ ok ]
# rc-update add postgresql-9.0 default
 * service postgresql-9.0 added to runlevel default

En este punto, está preparado para continuar con el tutorial oficial de PostgreSQL (en inglés). El tutorial le guiará en la creación de roles, bases de datos, esquemas y todas esas útiles y divertidas características de las bases de datos relacionales.

5.  Migrando PostgreSQL

Cuándo necesita migrar

Existen dos razones por las que necesitará realizar una migración: Cuando cambie de una versión mayor a otra, por ejemplo, desde PostgreSQL 8.4.7 a 9.0.3, pero no desde 9.0.2 to 9.0.3 o cuando cambie de una base de datos con formato de sello de tiempo (timestamp) en coma flotante a otra con el formato de enteros de 64 bits.

Post-migración 9.0

La nueva utilidad pg_upgrade que incorporan las versiones 9.0 y posteriores, simplifican el proceso de migración drásticamente.

Sin embargo hay dos problemillas cuando se utiliza pg_upgrade. En primer lugar, no soporta el hecho de que los ficheros de configuración se encuentren en un directorio diferente del de datos. Esto se puede resolver usando enlaces simbólicos. En segundo lugar, solo permite la migración de bases de datos a partir de la versión 8.3 or newer. Si tiene una versión de base de datos anterior, necesitará seguir las instrucciones Pre-migración 9.0.

(Detenga los servidores desde los que va a migrar y a los que va a migrar)
# /etc/init.d/postgresql-8.4 stop
# /etc/init.d/postgresql-9.0 stop
# ln -s /etc/postgresql-8.4/*.conf /var/lib/postgresql/8.4/data/
# ln -s /etc/postgresql-9.0/*.conf /var/lib/postgresql/9.0/data/

(Compruebe las versiones disponibles, a continuación, seleccione la suya)
# eselect postgresql list
# eselect postgresql set 9.0

(Cambie el método de acceso a la base de datos del usuario 'postgres' a trust en conexiones locales para todas las bases de datos)
# nano -w /etc/postgresql-8.4/pg_hba.conf
# nano -w /etc/postgresql-9.0/pg_hba.conf

Necesitará cambiar los permisos de '/var/lib/postgresql/' antes de continuar con el siguiente paso.
# su - postgres
$ pg_upgrade -u postgres \
  -d /var/lib/postgresql/8.4/data -D /var/lib/postgresql/9.0/data \
  -b /usr/lib/postgresql-8.4/bin -B /usr/lib/postgresql-9.0/bin
(Si pg_upgrade le pide que realice alguna tarea, hágala)
$ logout

(Elimine los enlaces simbólicos que se han creado anteriormente)
# rm /var/lib/postgresql/8.4/data/*.conf
# rm /var/lib/postgresql/9.0/data/*.conf
# /etc/init.d/postgresql-9.0 start

Pre-migración 9.0: Con los ebuilds nuevos

Debido a que los nuevos ebuilds incorporan características de uso de ranuras (slots) más avanzadas que las antiguas, el tiempo en el que la base de datos está parada es mínimo, normalmente minutos en lugar de horas.

En los ejemplos que siguen, se asume que está utilizando las localizaciones y puertos por defecto, y que está migrando desde la versión 8.3 a la 8.4. Cambie lo que necesite si su sistema no tiene los ajustes por defecto.

Si no lo ha hecho aún, siga las instrucciones de instalación antes de comenzar la migración. La compilación puede dificultar el rendimiento del servidor de base de datos, pero se puede continuar trabajando.

Se necesita modificar un par de ficheros antes de comenzar la migración. Cambie el valor de PGPORT en el fichero de configuración /etc/conf.d/postgresql-8.4 a 6543. (Cualquier número de puerto distinto al definido en su antigua instalación funcionará igualmente).

A continuación, edite el fichero /etc/postgresql-8.3/pg_hba.conf de forma que únicamente el superusuario postgres pueda acceder a la base de datos a través del zócalo Unix.

# cp -p /etc/postgresql-8.3/pg_hba.conf /etc/postgresql-8.4/

(Lo que sigue debería ser seguro, Lea la documentación para estar más seguro)
#  cp -p /etc/postgresql-8.3/postgresql.conf /etc/postgresql-8.4/

(No olvide copiar cualquier fichero de configuración que necesite)

# /etc/init.d/postgresql-8.3 reload
# /etc/init.d/postgresql-8.4 start

(Comience entubando los datos desde el antiguo cluster al nuevo)
# pg_dumpall -U postgres -p 5432 | psql -U postgres -d postgres -p 6543
# /etc/init.d/postgresql-8.3 stop
# /etc/init.d/postgresql-8.4 stop

(Cambie PGPORT de nuevo al valor 5432.)
# nano -w /etc/conf.d/postgresql-8.4
(Permita de nuevo el acceso a los usuarios)
# nano -w /etc/postgresql-8.4/pg_hba.conf
# /etc/init.d/postgresql-8.4 start
# rc-update del postgresql-8.3 && rc-update add postgresql-8.4 default

Seguramente todo haya ido de acuerdo al plan y habrá actualizado de forma correcta su servidor y éste contendrá exactamente los mismos datos, bit a bit, tal y como estaban en el antiguo servidor.

Pre-migración 9.0: Desde los ebuilds obsoletos

Necesitará programar la bajada de su servidor durante algún tiempo. Los antiguos ebuilds no se pueden instalar a la vez que los nuevos. Por lo tanto, debe asumir que su servidor estará caído durante algunas horas. Puede que incluso durante un fin de semana.

Antes de empezar, necesitará denegar el acceso al servidor, de modo que no se puedan realizar cambios en los datos. Seguramente también quiera hacer una copia de seguridad de los ficheros postgresql.conf y pg_hba.conf y de cualquier otro fichero de configuración que crea importante.

# pg_dumpall -U postgres > backup_file
# /etc/init.d/postgresql stop
# emerge -C dev-db/postgresql dev-db/libpq dev-db/postgresql-client \
  dev-db/postgresql-client

(Siga los pasos descritos en este documento para instalar y configurar el servidor)

# /etc/init.d/postgresql-8.4 start
# psql -f backup_file postgres

Puede que algunos paquetes que estaban construidos contra los antiguos paquetes queden rotos, por lo tanto, una vez que haya instalado dev-db/postgresql-base y/o dev-db/postgresql-server revdep-rebuild para volver a construir cualquier paquete afectado.

6.  Utilidades

pgAdmin III

pgAdmin III es una utilidad gráfica para gestionar PostgreSQL.

7.  Resolución de problemas

El servidor carece de funciones de instrumentación

Este problema es fácil de solucionar, la solución dependerá de la versión que esté utilizando. Lo que es más complicado es encontrar la respuesta. Lo que se necesita es una importación de un fichero que ya existe en el dispositivo de almacenamiento: adminpack.sql. Para resolver este problema, ejecute la orden apropiada para la versión que tenga instalada:

# psql -U postgres --file /usr/share/postgresql-9.0/contrib/adminpack.sql

# psql -U postgres -c "CREATE EXTENSION adminpack;"

El contenido de este documento, a no ser que se especifique expresamente, está registrado bajo los términos de la licencia CC-BY-SA-2.5. Se aplican las Pautas de Utilización del logotipo y nombre de Gentoo.