Dba-PostgreSQL

Academia De Software Libre
www.codigolibre.org
__________________________________________________________
PostgreSql
________________________________________
2010 Manual De Administración de PostgreSql
1
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Clase de Administración
PostgreSql
Documentación Realizada Por:
Ing. Jose Paredes
DBA-Senior
Meidy Alvarez
DBA-Junior
________________________________________
2010 Manual De Administración de PostgreSql
2
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
ÍNDICE
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Dedicatoria..........................................................................................................5
Copyright.............................................................................................................6
Prefacio.................................................................................................................6
¿Qué se espera de un SGBD?...............................................................................7
¿Qué exigiremos a un SGBD?..............................................................................7
Gestión de los Recursos del kernel.......................................................................7
psql.......................................................................................................................8
Aplicaciones servidor...........................................................................................8
Arquitectura .........................................................................................................8
El proceso Postmaster..........................................................................................9
La memoria compartida.......................................................................................9
Almacenamiento físico.........................................................................................9
Ficheros................................................................................................................9
Otros ficheros.......................................................................................................9
Directorios..........................................................................................................10
Creación del cluster de bases de datos: initdb....................................................10
Creación del cluster............................................................................................11
Modificación de template1 + añadir extensiones-contrib..................................12
Puesta en marcha y parada del servidor.............................................................12
Internacionalización y localización....................................................................13
•
Ventajas..................................................................................................13
Para ver cómo está configurado en el SO ejecutar.............................................13
Procesamiento de instrucciones.........................................................................14
Gestión de transacciones....................................................................................15
•
Atomicidad (atomicity)...........................................................................15
•
Consistencia (consistency)......................................................................15
•
Aislamiento (isolation)............................................................................16
•
Persistencia (durability)..........................................................................16
Seguridad en PostgreSQL..................................................................................17
Seguridad en la manipulación de los ficheros....................................................17
Respecto a las conexiones locales vía sockets...................................................17
Seguridad en el acceso de los clientes................................................................18
Conexión local: usando los sockets del dominio Unix......................................18
Conexión remota sin encriptar usando TCP/IP (SSL y no SSL)........................19
Conexión remota encriptada SSL usando TCP/IP (solo SSL)...........................19
Esquema lógico..................................................................................................23
Creación de roles (usuarios)...............................................................................24
Listando Usuarios..............................................................................................27
Modificando Usuarios.......................................................................................27
Permitir Usuario crear BD.................................................................................29
Cambiando Nombre a un Usuario......................................................................29
Cambiar contraseña...........................................................................................29
Eliminando Usuario............................................................................................29
Creando Grupo...................................................................................................29
Agregando o eliminando un Usuario de Grupo..................................................30
Viendo los Grupos..............................................................................................30
________________________________________
2010 Manual De Administración de PostgreSql
3
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Re-Nombrando Grupo........................................................................................30
Eliminando Grupo..............................................................................................31
Creación de tablespaces.....................................................................................31
Creación de bases de datos.................................................................................32
Esquemas............................................................................................................33
Permisos.............................................................................................................34
Asignando Privilegios........................................................................................35
Quitando Privilegios...........................................................................................35
Cambiando EL propietario de una tabla.............................................................43
Listar los Objetos en Schema Public..................................................................44
Permisos y Seguridad en Schema.......................................................................45
Eliminando Schema............................................................................................45
Funciones de Schema.........................................................................................45
Esquemas especiales...........................................................................................46
Limitaciones.......................................................................................................46
Administrar privilegios de copia de seguridad...................................................46
Administrando desde GNU/Linux......................................................................48
Iniciando postmaster...........................................................................................49
Autentificación de Usuarios...............................................................................50
Creación de una base de datos............................................................................50
Acceso a la base de datos...................................................................................51
Bases de datos grandes.......................................................................................52
Tratamiento de problemas..................................................................................53
Tareas administrativas: Copias de seguridad y recuperación.............................53
Copy...................................................................................................................53
Mantenimiento del fichero de seguimiento........................................................55
Copias de seguridad............................................................................................55
Copias de seguridad de ficheros del SO.............................................................56
Desventajas de este método................................................................................56
Volcado SQL......................................................................................................56
Recuperación con psql........................................................................................58
Recuperación con pg_restore.............................................................................58
Scripts Basico de hacer Backup.........................................................................62
Crontab...............................................................................................................62
•
¿Qué es cron?..........................................................................................62
•
Iniciar cron..............................................................................................62
•
Usando cron.............................................................................................63
•
Ejecutando Cron con múltiples usuarios, comando crontab...................64
•
Controlando el acceso a cron...................................................................65
COMANDO chkconfig.....................................................................................66
Fallos en memoria secundaria (disco)................................................................67
Volcado en línea y recuperación PITR...............................................................67
Tareas administrativas: Vacuum …...................................................................69
AUTOVACUUM...............................................................................................70
Reindex...............................................................................................................70
Monitorizacion...................................................................................................71
________________________________________
2010 Manual De Administración de PostgreSql
4
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Dedicatoria
Una mención de forma especial para Antonio Perpiñán, Fundador del
Movimiento de Software Libre en República Dominicana y en América
Latina, persona de grandes principios y vastos conocimientos. No todo
hombre tiene el valor de aprender y mucho menos de enseñar, por eso sea
siempre bendecido por su calidez y gran visión. “El objeto más noble que
puede ocupar el hombre es ilustrar a sus semejantes”.
Meidy E. Alvarez Guerrero
________________________________________
2010 Manual De Administración de PostgreSql
5
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Copyright
Esta documentación es regida por los reglamentos de la GNU Free Documentation
License y la GNU General Public License v3, siéntase libre de copiar, modificar,
aprender, distribuir y redistribuir esta documentación; haga uso de su derecho como si
fuere su deber.
Prefacio
En estas paginas se plasma de manera Teorico/Practico los conocimientos necesarios para
convertirse en un Administrador de Base de Datos, usando Postgresql; la finalidad es instruir de
manera interactiva todo lo que se debe saber para un manejo eficiente de Postgresql, y aplicarlos a
este y otros motores libres. Esta es una etapa de varias en este camino hacia la carrera profesional
de la administración de base de datos y análisis de estructuras de almacenamiento de
registros de datos.
________________________________________
2010 Manual De Administración de PostgreSql
6
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
¿Qué se espera de un SGBD?
De un Sistema de Gestión de Bases de Datos esperamos:
Permita a los usuarios crear otras bases de datos y especificar su esquema por medio de
algún lenguaje de definición.
Ofrezca a los usuarios la capacidad de consultar los datos y modificarlos, usando para ello
un lenguaje de consulta y manipulación.
Brinde soporte al almacenamiento de cantidades voluminosas de datos durante un largo
período, protegiéndolo contra accidentes o utilización no autorizada.
Controle el acceso concurrente.
¿Qué exigiremos a un SGBD?
Para optar por un buen SGBD debe estudiar su:
Escalabilidad: Capacidad de mejorar con el incremento de los recursos invertidos.
Portabilidad: Exportación e importación de datos de una plataforma a otra.
Rendimiento: Recuperación, actualización, concurrencia, etc. de una manera eficiente.
Universalidad: Múltiples tipos de datos (multimedia).
Disponibilidad: 7x24.
Aplicaciones clientes.
Gestion de los Recursos del kernel:
La instalación de PostgreSQL requiere la comprobación de que el servidor será capaz de
soportarlo.
Normalmente, los valores por defecto son más que suficientes. Estos recusos afectan a la
memoria compartida y a los semáforos. Será tarea del administrador de sistemas cambiar los
valores de los parámetros si es necesario. Si el sistema no puede proporcionar los recursos
que requiere el servidor, éste no se puede poner en marcha y devuelve un error. Para una
instalación normal, los valores por defecto son suficientes.
Parámetros de PostgreSQL que afectan a la memoria compartida:
Corresponden con una órden de SQL ejecutadas dentro de la base de
datos, para saber más detalles, consultar el manual de cada programa tal como se hace en
Linux / Unix:
• clusterdb:
equivalente al comando CLUSTER de SQL, reorganiza cluster de
tablas.
• createdb:crea una base de datos.
• createlang:
define un nuevo lenguaje procedural en una base de datos.
• createuser:
creación de usuarios.
________________________________________
2010 Manual De Administración de PostgreSql
7
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
•
•
•
•
•
•
•
dropdb: borrar una base de datos.
droplang:
borrar un lenguaje procedural.
dropuser:
borrar un usuario.
ecpg:
SQL C preprocesador embebido.
pg_config:
recupera información sobre la versión instalada de PostgreSQL.
pg_dump:
extrae una base de datos en un fichero script o en otros formatos.
pg_dumpall: extrae un cluster de base de datos en un fichero script.
• pg_restore:
restaura una base de datos desde un fichero creado con pg_dump.
psql:
Terminal interactivo de PostgreSQL. Es la herramienta canónica para la ejecución de
sentencias SQL a través del shell del SO. Es una herramienta de tipo frontend que permite
describir sentencias SQL, ejecutarlas y visualizar sus resultados. El método de ingreso
puede ser mediante la inserción directa del código en la consola, o la ejecución de
sentencias dentro de un archivo de texto. Provee de diversos meta-comandos para la
ejecución de las sentencias, así como diversas opciones tipo shell propias de la herramienta.
reindexdb: reindexa una base de datos.
vacuumdb: reorganiza y analiza una base de datos.
Aplicaciones servidor:
• initdb: crea un cluster de base de datos.
•
•
•
•
ipcclean: libera la memoria compartida y los semáforos de un servidor PostgreSQL.
pg_controldata: muestra información de control de un cluster de base de datos.
pg_ctl: inicia, para o reinicia un servidor PostgreSQL.
pg_resetxlog: reinicia el write-ahead log y otras informaciones de control de un
cluster de base de datos.
• postgres: corre un servidor PostgreSQL en modo "single-user".
• postmaster: servidor de base de datos PostgreSQL multiusuario.
Arquitectura
PostgreSQL funciona con una arquitectura Cliente/Servidor, un proceso servidor
(postmaster) y una serie de aplicaciones cliente que realizan solicitudes de acciones contra
la base de datos a su proceso servidor. Por cada una de estas aplicaciones cliente, el proceso
postmaster crea un proceso postgres.
El proceso Postmaster:
Es el proceso inicial. Gestiona los accesos multiusuario y multiconexion. Levanta la
memoria compartida. Esta al tanto de solicitudes de nuevas conexiones. Lanza procesos de
atencion de demanda, realizando las operaciones sobre la base de datos a solicitud de los
clientes. Realiza el enlazado con los archivos de datos, gestionando estos ficheros, donde los
ficheros
pueden pertenecer a varias bases de datos.
La comunicacion entre BackEnd/FrontEnd se realiza mediante TCP/IP, normalmente por el
puerto 5432, creando un socket (/tmp/.s.PGSQL.5432).
________________________________________
2010 Manual De Administración de PostgreSql
8
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
La memoria compartida:
Gestiona los recursos entre procesos backend. Gestiona la cache del disco,
maneja otras estructuras internas. De esta manera podemos definir el concepto de
CLUSTER DE BASE DE DATOS, como una instancia de PostgreSQL, donde se lanza un
proceso postmaster, que puede gestionar varias bases de datos. En un servidor, pueden haber
varios cluster, cada uno tendra su postmaster, y cada postmaster escuchara por un puerto
diferente.
Nota: no confundir este concepto de ¡§cluster¡š con los tipicos que se manejan en bases de
datos de ¡§base de datos en cluster¡š o ¡§tablas en cluster¡š.
Almacenamiento fisico:
En un servidor se crean uno o varios clusters de bases de datos. La estructura fisica del
cluster se crea con el programa initdb, con este programa se determina la ubicacion fisica y
el juego de caracteres.
En las instalaciones automáticas a partir de paquetes (rpm, apt-get, etc) o en Windows, se
crea un cluster automáticamente con tres bases de datos, template0, template1 y postgres. El
cluster se crea en un directorio data dentro del directorio donde se ha instalado postgres.
Normalmente, se define una variable de entorno, PGDATA que apunte al directorio donde
se crea el cluster.
Ficheros:
• postgresql.conf: fichero de configuracion principal, contiene la asignacion a los
parametros que configuran el funcionamiento del servidor.
• pg_hba.conf: fichero de configuracion de la autenticacion de los clientes y usuarios
y del acceso a las bases de datos del cluster.
• pg_ident.conf: fichero accesorio al anterior, determina como se realiza la
autenticacion ident que contiene la correspondencia entre usuarios del Sistema
Operativo y de PostgreSQL.
• PG_VERSION: fichero de texto con la version de software Postgres que crea el
cluster .
Otros ficheros:
• postmaster.pid: se crea cuando el postmaster arranca, contiene el PID del proceso
postmaster.
• postmaster.opts: contiene las opciones con las que se ha iniciado el postmaster.
• recovery.conf, recovery.done: si se quiere o se ha hecho una recuperacion.
________________________________________
2010 Manual De Administración de PostgreSql
9
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Directorios:
• base: las plantillas y las bases de datos. contiene un directorio por cada base de
datos, dentro hay un fichero por cada tabla o indice de una base de datos, los
numeros corresponden a los OIDs de las tablas o indices.
• template0 (1): contiene las definiciones de las tablas del sistema, vistas, funciones y
tipos estandar. Nunca se debe modificar ni intentar conectarse a ella, ya que esta por
si template1 se corrompe.
• template1 (N): base de datos plantilla para crear nuevas bases de datos, se puede
modificar su estructura, anadiendo tablas, indices, funciones, etc. Es la que se usara
como plantilla para crear otras bases de datos.
• global: tablas e indices del catálogo comunes a todas las bases de datos.
catalogo compartido: pg_shadow (usuarios), pg_database, etc.
• pgstat.stat: fichero usado por el monitor de estadísticas.
• pg_control: fichero con parámetros del cluster, algunos inmutables (establecidos en
la creación del cluster) y otros variables (establecidos en la puesta en marcha).
• pg_log: ficheros de seguimiento del servidor. Se crea en la versión de Windows, en
la de Linux, se debe indicar al arrancar el postmaster en qué fichero se hace el
seguimiento.
• pg_xlog: ficheros de diario del servidor (WAL).
Contiene los diarios de escritura adelantada, para usarlos en las recuperaciones. Se
implementan como un conjunto de segmentos (ficheros) de un tamaño de 16Mb y
divididos en páginas de 8Kb.
• pg_clog: ficheros de diario para las transacciones (estado de cada transacción).
Contiene los ficheros de confirmacion. Un diario de confirmación refleja el estado de
cada transacción: confirmada, en progreso o abortada.
• pg_multixact: contiene datos sobre el estado multi-transaccional, usado para los
bloqueos compartidos de filas.
• pg_twophase: ficheros de estado para las transacciones preparadas.
• pg_subtrans: para realizar los “savepoints “ en medio de transacciones.
• pg_tblspc: información sobre los tablespaces. Cuidado porque en linux/unix
contiene enlaces a los directorios donde se crean los tablespaces y hay que controlar,
en caso de cambios de ficheros, que estén correctos.
Creación del cluster de bases de datos: initdb
Después de instalar PostgreSQL, lo primero que hay que realizar es la creación de un
cluster, teniendo en cuenta que en un servidor, se pueden crear todos los cluster que se
quieran.
________________________________________
2010 Manual De Administración de PostgreSql
10
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Creacion del cluster:
Ya vimos en un punto anterior cómo se crea un cluster de base de datos, por ejemplo, en
este curso, vamos a crear el siguiente cluster:
initdb --pgdata=$PGDATA --encoding=LATIN1 --locale=es_ES
Con este proceso se han creado tres bases de datos: template0 (que ya se ha dicho que no se
debe modificar ni debemos conectarnos a ella), template1 y postgres.
Al terminar de crear el cluster nos responde que ya podemos iniciar el postmaster de este
cluster de dos modos:
$ postmaster -D $PGDATA
o
pg_ctl -D $PGDATA -l $PGLOG start
Lo hacemos del segundo modo, ahora, una vez arrancada la instancia, podemos conectarnos
desde nuestro servidor a la base de datos usando el psql:
Si queremos parar el servidor:
$ pg_ctl stop
--Siqueremos ver la informacion inicializada por initdb:
[postgres@jp ~]$pg_controldata data/
pg_control version number:
Catalog version number:
Database system identifier:
Database cluster state:
pg_control last modified:
Latest checkpoint location:
Prior checkpoint location:
Latest checkpoint's REDO location:
Latest checkpoint's TimeLineID:
Latest checkpoint's NextXID:
Latest checkpoint's NextOID:
Latest checkpoint's NextMultiXactId:
Latest checkpoint's NextMultiOffset:
Time of latest checkpoint:
Minimum recovery ending location:
Maximum data alignment:
Database block size:
Blocks per segment of large relation:
WAL block size:
Bytes per WAL segment:
Maximum length of identifiers:
Maximum columns in an index:
Maximum size of a TOAST chunk:
Date/time type storage:
843
200904091
5470533823675219895
in production
Sat 05 Jun 2010 10:59:44 AM AST
0/2E23574
0/2BBB43C
0/2E23574
1
0/3448
35751
1
0
Sat 05 Jun 2010 10:57:32 AM AST
0/0
4
8192
131072
8192
16777216
64
32
2000
64-bit integers
________________________________________
2010 Manual De Administración de PostgreSql
11
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Float4 argument passing:
Float8 argument passing:
by value
by reference
Modificacion de template1 + añadir extensiones-contrib:
Hay que tener en cuenta ciertos aspectos antes de empezar a trabajar con nuestras bases de
datos.
template1 es una plantilla para crear otras bases de datos, conviene que, antes de crear
nuevas bases de datos, la completemos con todos aquellos elementos que consideremos que
deben estar en todas las bases de datos que creemos, lenguajes, módulos opcionales
(tsearch2, lo, dblink, etc), tablas comunes, etc. Más adelante veremos cómo se instalan estas
opciones.
¿va a ser postgres nuestra base de datos o la reservamos para pruebas o como plantilla y no
usamos template1?, ¿vamos a crear más bases de datos?
Para modificar template1 no hay más que conectarse a ella y ejecutar los scripts de base de
datos que hagan falta.
Por ejemplo, las bases de datos se suelen crear sin lenguajes, no existe el plpgsql, para
instalarlo, ejecutamos desde el sistema operativo:
$ createlang plpgsql template1
$ createlang plpgsql postgres
Lo ejecutamos también en postgres para que tenga las mismas opciones.
Pero además, en el mundo del software libre se crea código para añadir nuevas
funcionalidades. Estos módulos los hemos añadido, por ejemplo, en la instalación de
PostgreSQL en Windows, pero no en la de Linux, para poder instalarlos hay que ir al
directorio $PGSRC/contrib.
En $PGSRC/contrib hay un fichero README que indica el uso de cada una de estas
opciones.
Ejemplos de opciones que se tienen que instalar según los requerimientos de las
aplicaciones:
tsearch2: soporte para indexación usando GiST
lo: mantenimiento de tipos de datos LOB
vacuumlo: vacuum para objetos LOB
dblink: poder ejecutar sentencias en otras bases de datos
Puesta en marcha y parada del servidor:
La puesta en marcha del servidor se puede hacer de forma manual con dos comandos:
pg_ctl: facilidad para la puesta en marcha, parada y reconfiguración del servidor. Hace uso
________________________________________
2010 Manual De Administración de PostgreSql
12
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
de la instrucción que actúa sobre el servidor postgres.
postmaster: proceso servidor de base de datos.
El comando pg_ctl es el que se usa normalmente, porque permite controlar más aspectos
que el comando postmaster.
Operaciones:
•
start: puesta en marcha del servidor.
•
stop: parada del servidor.
•
restart: parada del servidor seguida de puesta en marcha.
•
reload: envia al postmaster una senal SIGHUP, que provoca que recargue toda
la informacion de configuracion. Algunas opciones de configuracion requieren
parar el servidor.
•
status: comprueba si hay un postmaster en marcha y muestra el PID y sus
opciones de puesta en marcha.
•
kill, register, unregister: opciones para la version de Windows para matar,
registrar como servicio o eliminar el servicio.
Internacionalización y localización:
Internacionalización: proceso de desarrollo de software de forma que pueda ser usado en
distintas ubicaciones.
Localización: proceso de adaptación de una aplicación para que sea usada en una ubicación
específica.
Ventajas:
1
2
3
4
5
Mensajes en varios idiomas.
Mensajes en varios juegos de caracteres.
Visualizacion de datos de usuario en diversos juegos de caracteres.
Diversos tipos de ordenaciones.
Clasificacion de caracteres: mayusculas, puntuacion, acentos, etc.
Para ver cómo está configurado en el SO ejecutar:
$ locale
Que nos mostrará la configuración activa, podemos cambiar la configuración entre
cualquiera de las que estén instaladas en el sistema operativo, para ver cuáles están
disponibles:
$ locale -a
En cuanto a los juegos de caracteres:
Soporta distintos tipos: byte simple o multibyte.
________________________________________
2010 Manual De Administración de PostgreSql
13
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
el cluster puede estar en un conjunto de caracteres y la base de datos en otro:
$ initdb -E unicode
$ createdb -E latin1 base1
SQL# create database base2 with encoding “win “;
Se produce una conversión automática entre servidor / cliente (en la tabla pg_conversion
están las conversiones por defecto.
Procesamiento de instrucciones:
Se produce un diálogo básico entre el proceso front-end (aplicación) y el proceso back-end
(postgres), que consta básicamente de los siguientes pasos:
1. La aplicación envía una instrucción al proceso postgres.
2. El servidor realiza en análisis y el proceso postgres responde OK o devuelve error.
3. La aplicación solicita la ejecución y el servidor la realiza, devolviendo Ok o error.
4. Por último la aplicación solicita la recuperación de los datos y el servidor responde con
los resultados de la instrucción.
Para el procesamiento de instrucciones PostgreSQL usa la caché de la base de datos (shared
buffers), colección de buffers de 8Kb en la memoria compartida y que sirven como caché de
las páginas de los ficheros y sentencias que se han usado recientemente. Esta memoria se
reserva cuando se pone en marcha el servidor.
Los bloques de buffers modificados se llaman "sucios" y se colocan en una lista sucia. La
lista sucia controla todas las modificaciones de datos que se hacen en la caché y que no se
han vaciado al disco. La lista sucia se vacía, por ejemplo, cuando se produce un punto de
control (checkpoint) o simplemente se llena la lista.
Si la instrucción es una consulta, el servidor siempre lee primero si tiene estos bloques de
datos en la caché, en caso contrario, los lee del disco y los copia a la cache, realizando esta
operación tantas veces como sea necesario para ejecutar una instrucción.
Si la instrucción es una actualización de datos entran en juego también los ficheros de diario
(WAL) y los buffers de diario (buffers WAL). Por ejemplo, al ejecutar un Update de una
fila:
1. Mirar si los datos están en los buffers compartidos y recuperar el valor antiguo.
2.Si no están recuperalos de los ficheros de datos y ponerlos en los shared buffers.
3.Se escribe el valor nuevo en el buffer WAL.
4.Se realiza la modiciación y se escribe en los shared buffers.
¡todavía no se han escrito los datos en disco!
________________________________________
2010 Manual De Administración de PostgreSql
14
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Gestión de transacciones:
PostgreSQL cumple las reglas ACID:
1
2
3
4
Atomicidad (atomicity).
Consistencia (consistency).
Aislamiento (isolation).
Persistencia (durability).
Atomicidad:
La palabra se deriva de átomo, que significa indivisible; como indivisibles son cada una de
las operaciones contenidas dentro de una transacción. Una transacción es un bloque de
operaciones o instrucciones dirigido a modificar una base de datos en una determinada
dirección.
En realidad, lo importante aquí, es que se cumpla la regla de todo o nada. Si todas las
operaciones se realizan con éxito, los resultados producidos por la transacción se guardan en
la base de datos. Si alguna operación falla, todas las operaciones son deshechas (rollback),
incluso aunque alguna operación haya sido realizada con éxito.
Solución
En PostgreSQL podemos hacer que un grupo de sentencias SQL se ejecuten dentro de una
transacción, encerrándolas entre las sentencias BEGIN y COMMIT. De esta forma
aseguramos que se ejecutan todas o ninguna. Si llegados a algún punto dentro de la
transacción necesitamos deshacerla completamente, utilizamos ROLLBACK, en lugar de
COMMIT, y todos los cambios son deshechos.
Durante las transacciones, existen restricciones diferidas (ser verifican al final de la
transacción) o inmediatas (se verifican en cada operación), en este caso, si alguna condición
no se cumple, la transacción queda en estado latente, algunas consultas no se pueden
realizar y las actualizaciones no tendrán efecto, con lo que solo se puede resolver
deshaciendo la transacción.
Por otro lado, PostgreSQL trata cualquier sentencia aislada como si ésta se ejecutara dentro
de una pequeña transacción; aunque no usemos BEGIN, cada sentencia incorpora
implícitamente un BEGIN y, si culmina con éxito, un COMMIT, a este modo se le conoce
como "modo autoconfirmación".
Consistencia:
Una base de datos es una herramienta para modelar y registrar una realidad cambiante. Sin
embargo, debe hacerlo consistentemente de acuerdo con unas reglas determinadas o
restricciones de integridad definidas. La realidad modelada así, puede ir cambiando al pasar
de un estado en el que cumple las reglas, a otro en el que también las cumple.
Si al ejecutar una transacción, por el motivo que sea, se incumpliera alguna de estas reglas,
la transacción no se llegaría a completar. Esto garantiza que una base de datos siempre
permanezca en un estado válido, es decir, consistente con las reglas.
________________________________________
2010 Manual De Administración de PostgreSql
15
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Solucion:
A partir de la version 7.0 se anadio gestion de integridad en PostgreSQL, las restricciones
soportadas son:
not null
check
unique
primary key
foreign key, con dos tipos ¡§match full¡š (completa) y ¡§match partial¡š (si en alguna
columna no hay valores no se comprueba la integridad, aunque esta opcion no esta
implementada)
Solo las instrucciones de clave ajena son diferibles, el resto son inmediatas.
Aislamiento:
Los resultados de una transacción que está siendo ejecutada, son invisibles a cualquier otra
transacción hasta que la primera no haya sido completada con éxito. La ejecución no
perturba a otras transacciones que se ejecuten concurrentemente.
Solución:
Frente a otro modelos tradicionales que controlan el acceso concurrente a los datos a través
de bloqueos, PostgreSQL utiliza un modelo denominado Multiversion Concurrency Control
(MVCC), según el cual, al consultar la BD, cada transacción ve una instantánea de la BD tal
como era hace un cierto tiempo (una versión de la BD) y no el estado actual de la BD. Este
mecanismo evita que una transacción pueda ver datos inconsistentes modificados por otra.
Aislando las transacciones que operan concurrentemente en distintas sesiones, un lector no
necesita esperar a un escritor; y un escritor no necesita esperar a un lector.
Persistencia o Durabilidad:
La durabilidad garantiza que los efectos resultantes de una transacción, una vez ha sido
completada con éxito, permanecen en la base de datos para siempre, incluso cuando se
puedan producir posteriormente fallos de cualquier clase.
Por ejemplo, si durante una transacción se produce un apagado del servidor, una vez
reiniciado el servidor, un sistema que lleve un registro de transacciones realizadas,
advertiría rápidamente que existe una sin completar, finalizándola correctamente.
Solución:
PostgreSQL utiliza una técnica estándar denominada WAL (Write-ahead logging, o
escritura anticipada de registros) para controlar tanto la consistencia como la durabilidad de
las transacciones.
Brevemente explicada, consiste en que los cambios en los ficheros de datos (tablas e
índices) sólo se materializan cuando existe previamente en el disco un registro en el que
están anotados dichos cambios. Siguiendo este procedimiento, no es necesario enviar
páginas al disco cada vez que una transacción se completa. Esta técnica no sólo mejora el
rendimiento del servidor, sino que ante un fallo de la máquina, será posible recuperar la BD
a partir de ese registro: cualquier cambio no aplicado a las páginas de datos en el disco será
________________________________________
2010 Manual De Administración de PostgreSql
16
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
nuevamente hecho desde el log (roll-forward recovery, o REDO) mientras que los posibles
cambios realizados en páginas de disco por transacciones incompletas, podrán ser deshechos
manteniendo la integridad y la consistencia de los datos (roll-backward recovery, o UNDO).
Estos ficheros de diario están en $PGDATA/pg_xlog, son ficheros de 16Mb, divididos en
páginas de 8Kb, el sistema crea uno inicialmente y va creando más según las necesidades,
rotando de manera cíclica según marquen los parámetros de sistema que gestionan este
funcionamiento (checkpoint_segments y archive_command).
Siguiendo con la instrucción (update de una fila), al ejecutar un COMMIT se produce:
1. Se escriben los datos del buffer WAL en los ficheros de diario WAL.
2. Se pueden refrescar las copias multiversión en los shared buffers.
3. Se retorna el control a la aplicación.
Entonces, los datos de los buffers no se han escrito en disco todavía, pero los del diario si,
así los datos de la transacción nunca se pierden.
Seguridad en PostgreSQL:
La seguridad en PostgreSQL se materializa en tres aspectos:
Seguridad en la manipulación de los ficheros de PostgreSQL.
Seguridad en los accesos de los clientes.
Definición de los privilegios para acceder a los objetos de la base de datos a los usuarios
PostgreSQL.
Seguridad en la manipulación de los ficheros:
La información más crítica está en $PGDATA.
Todos los ficheros deben pertenecer al usuario postgres.
El usuario postgres debe ser el único que pueda:
Leer, escribir y ejecutar sobre los directorios en los ficheros
leer y escribir en los ficheros
Respecto a las conexiones locales vía sockets:
Todos los usuarios usan la misma.
Se puede restringir el uso para algunos usuarios del SO.
Ver el directorio /tmp, donde existe un fichero .s.PGSQL.5432 que se crea cuando arranca
el postmaster, los permisos de este fichero son 777, cualquier usuario del SO se puede
conectar. Además hay un .s.PGSQL.5432.lock que sólo puede leer postgres.
________________________________________
2010 Manual De Administración de PostgreSql
17
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Los permisos de este socket se pueden configurar en postgresql.conf con los parámetros
unix_socket_directory, unix_socket_group y unix_socket_permission.
Seguridad en el acceso de los clientes:
Es importante poder definir desde qué equipos se pueden conectar a nuestra base de datos,
así como poder definir qué usuarios y a qué bases de datos se pueden conectar.
La configuración de este nivel de seguridad se realiza en los ficheros pg_hba.conf (hba =
host based authentication) y pg_ident.conf.
Se trata de editar una serie de reglas que se irán procesando de arriba abajo, cuando se
encuentre una regla que cumpla la conexión, se ejecutará lo que ponga en el método.
Conexión local: usando los sockets del dominio Unix:
base_datos:
ALL: se permite la conexión a cualquier base de datos.
SAMEUSER: solo a bases de datos que su nombre sea el mismo que el usuario que se
conecta.
SAMEROLE: solo a bases de datos que su nombre sea el mismo que el role que se conecta.
nombd1, nombd2, : se permite la conexión a cualquiera de las bases de datos de la lista.
@fichero: se permite la conexión a las bases de datos incluidas en el fichero, que debe estar
en el mismo directorio que pg_hba.conf.
usuario:
ALL: se permite la conexión de cualquier role.
role1, [+]role2, : se permite la conexión de los roles de la lista y además se permite la
conexión de cualquier role que sea miembro de role2.
@fichero: se permite la conexión de los roles incluidos en el fichero, que debe estar en el
mismo directorio que pg_hba.conf.
Método-Autenticación:
TRUST: conexión aceptada sin condiciones.
REJECT: conexión rechazada sin condiciones.
PASSWORD: se solicita palabra de paso sin encriptar, las palabras de paso se almacenan
en la tabla pg_authid y pueden estar cifradas o no según como se creara el role.
CRYPT: palabra de paso encriptada (versiones previas a la 7.2).
________________________________________
2010 Manual De Administración de PostgreSql
18
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
MD5: palabra de paso con el método de encriptación md5, y se almacena también con este
método. Es el método recomendado por PostgreSQL. Se obtiene un cifrado a partir de la ID
de usuario y la palabra de paso, el cliente solicita una semilla al servidor y así se obtiene un
segundo cifrado que es envíado al servidor, en el servidor se utiliza la palabra de paso
almacenada, el ID del usuario (la obtiene de la conexión) y la semilla para obtener un
cifrado
similar y los compara.
KRB5: se usa Kerberos v5 para autenticar el cliente, se ha de habilitar en la instalación del
servidor.
IDENT correspondencia: a partir del usuario de la conexión cliente (se fía de la
autenticación del cliente) y de la correspondencia indicada en la opción, se obtiene un role
de PostgreSQL para realizar la conexión. Las correspondencias se obtienen del fichero
pg_ident.conf.
SAMEUSER: el usuario del sistema operativo es el mismo que se conecta a la BD.
Cambio-usuario: el sistema mira el fichero pg_ident.conf, y busca una fila donde esté la
correspondencia llamada “cambio-usuario“ y se corresponda con el usuario conectado al
SO, haciendo la conexión a la BD con el usuario con el usuario de la columna usuario-pg.
PAM servicio-pam: autenticación usando Pluggable Authentication Method proporcionado
por el servicio PAM indicado en opción. Este método es proporcionado por el SO. Se debe
compilar el servidor con esta opción. El PAM por defecto es postgresql. Se deben
configurar los métodos PAM del SO, generalmente basta con incluir la definición del un
nuevo método en el directorio /etc/pam.d.
Conexión remota sin encriptar usando TCP/IP (SSL y no SSL):
Permite conexiones SSL y no SSL.
La palabra de paso se transmite en texto plano si es no SSL.
direccionCIDR ó direcccionIP máscara IP: especifica un rango de direcciones IP
192.168.200.0/24 ó 192.168.200.0 255.255.255.0: se pueden conectar todas las IPs de la red
192.168.200
192.168.0.0/16 ó 192.168.0.0 255.255.0.0: todos las IPs de la red 192.168
192.168.200.85/32: solo esa IP
0.0.0.0/0 ó 0.0.0.0 0.0.0.0.: cualquier IP
Conexión remota encriptada SSL usando TCP/IP (solo SSL):
La transmisión cliente-servidor es encriptada.
Los registros HOST se utilizarán para conexiones remotas no-SSL y SSL.
Los registros HOSTSSL sólo se utilizarán para conexiones remotas SSL.
Requiere instalar PostgreSQL con la opción SSL, crear los ficheros de firmas y claves y
________________________________________
2010 Manual De Administración de PostgreSql
19
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
ubicarlos en el lugar correspondiente.
Para configurar el servidor para estas opciones:
SSL tiene que estar instalado en el servidor y en los clientes que se conecten.
PostgreSQL debe estar compilado con la opción SSL.
El servidor busca en $PGDATA los ficheros server.key (clave privada del servidor, que si
está protegida en el arranque. Hay otro fichero server.crt.
Se usa el comando OpenSSL.
/*****Ejemplos de conexiones remotas*****/
(18:25:48)][postgres:data]$ vim postgresql.conf
--Para poder aceptar conecciones de otras direcciones debemos descomentar ‘listen_address’ y
cambiar su IP address(‘localhost’) a que sea igual a '*’, para que acepte todas las direcciones y
tambien descomentaremos el puerto(port)
#-----------------------------------------------------------------------------# CONNECTIONS AND AUTHENTICATION
#-----------------------------------------------------------------------------# - Connection Settings listen_addresses = '*'
# what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost', '*' = all
# (change requires restart)
port = 5432
# (change requires restart)
max_connections = 100
# (change requires restart)
--Luego de realizar los cambios se debe de reiniciar el sistema
-bash-4.0$ pg_ctl restart
/****AHORA CON EL pg_hba.conf (hba = host based authentication)****/
(19:00:20)][postgres:data]$ vim pg_hba.conf
--Ahora configuraremos el archivo ‘pg_hba.conf’ la especificacion ya sea de: base de datos,
usuario, IP-address y/o metodo de autenticacion de la cual se le va a permitir conectarce al servidor.
PostgreSQL Client Authentication Configuration File
# ===================================================
#
# Refer to the "Client Authentication" section in the
# PostgreSQL documentation for a complete description
________________________________________
2010 Manual De Administración de PostgreSql
20
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
# of this file. A short synopsis follows.
#
# This file controls: which hosts are allowed to connect, how clients
# are authenticated, which PostgreSQL user names they can use, which
# databases they can access. Records take one of these forms:
#
# local DATABASE USER METHOD [OPTIONS]
# host DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]
# hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]
# hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]
#
# 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
--Configuraremos la conexion local IPv4
--Nota: siempre que se realice algun cambio en este archivo hay que ejecutar “pg_ctl restart”.
/***Queremos que acepte coneccion desde cualquier IP y cualquier usuario pero solo para la DB
‘sacademico’***/
# TYPE DATABASE
USER CIDR-ADDRESS METHOD
# IPv4 local connections:
host
sacademico
all
0.0.0.0/0
password
--Comprobemos la coneccion
-bash-4.0$ psql -U mexy -h 168.100.0.2 sacademico
Password for user mexy:
Timing is on.
psql (8.4.3)
Type "help" for help.
[168:5432/mexy@sacademico][]#
--Otra prueba con diferente IP y usuario
-bash-4.0$ psql -U jparedes -h 192.168.100.2 sacademico
Password for user jparedes:
Timing is on.
psql (8.4.3)
Type "help" for help.
[192:5432/jparedes@sacademico][]>
--Si no cumplimos los parametros nos dira lo siguiente:
-bash-4.0$ psql -U jparedes -h 192.168.100.2 HR
psql: FATAL: no pg_hba.conf entry for host "192.168.100.2", user "jparedes", database "HR", SSL
off
________________________________________
2010 Manual De Administración de PostgreSql
21
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
/***Aqui especificamos que aceptara coneccion a cualquier DB y de cualquier ip pero siempre con
el usuario ‘mexy'.***/
# TYPE DATABASE USER
CIDR-ADDRESS METHOD
# IPv4 local connections:
host
all
mexy 0.0.0.0/0
md5
--Hagamos la coneccion
-bash-4.0$ psql -U mexy -h 192.168.100.2 sacademico
Password for user mexy:
Timing is on.
psql (8.4.3)
Type "help" for help.
[192:5432/mexy@sacademico][]#
--Chevere
--Lo mismo pero con diferente IP y DB.
-bash-4.0$ psql -U mexy -h 168.100.0.2 HR
Password for user mexy:
Timing is on.
psql (8.4.3)
Type "help" for help.
[168:5432/mexy@HR][]#
--Pero siempre con el usuario mexy porque si no nos dara el siguiente:
-bash-4.0$ psql -U jparedes -h 168.100.0.2 HR
psql: FATAL: no pg_hba.conf entry for host "168.100.0.2", user "jparedes", database "HR", SSL
off
/***Ahora especificaremos una sola IP(en este caso cualquier IP) con cualquier DB y/o usuario
pero con metodo password.***/
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# IPv4 local connections:
host
all
all
0.0.0.0/0
password
--Probemos
-bash-4.0$ psql -U mexy -h 10.0.0.1 sacademico
Password for user mexy:
Timing is on.
psql (8.4.3)
Type "help" for help.
[10:5432/mexy@sacademico][]>
--Nitido!
/*** Practica***/
--Realiza una conexion remota desde tu maquina, con un usuario, IP especifico y el metodo
password.
________________________________________
2010 Manual De Administración de PostgreSql
22
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Esquema lógico:
Concepto de Cluster de bases de datos en PostgreSQL:
Repositorio que engloba un conjunto de bases de datos, que contienen objetos que se pueden
guardar en distintos tablespaces y un conjunto de usuarios que se conectan al cluster.
Una base de datos engloba un conjunto de esquemas, los cuales tienen un usuario
propietario. En los esquemas es donde se crean los objetos (tablas, índices, procedimientos,
vistas, etc.).
Una sesión se abre contra una base de datos.
Con lo que tenemos aquí los tres elementos principales a nivel lógico en un cluster:
Bases de datos: agrupaciones de esquemas. Por defecto, siempre hay tres bases de datos
creadas, template0, template1 y postgres.
Tablespaces: ubicaciones alternativas a la que por defecto tiene el cluster. Por defecto no se
crea ninguno.
Roles: engloba el concepto de usuarios (roles de login) y grupos de permisos (roles de
grupo), estos últimos son lo mismo que los roles de Oracle. Hasta la versión 8 de Postgres
no se podían anidar roles, ahora si. Por defecto, si al crear el cluster no se ha indicado otro
usuario, se crea el usuario postgres como superusuario.
Todos los usuarios son comunes a las bases de datos del cluster, se pueden conectar con
cualquiera de las bases de datos. En este punto, las bases de datos se comportan como
esquemas de Oracle.
Las bases de datos son independientes entre ellas, no se pueden ver objetos de una base de
datos desde otra base de datos, excepto si se usan dblinks. Esto marca cómo se deben crear
las bases de datos:
Si es un servidor que acoge proyectos separados y no se han de interrelacionar:
separación en bases de datos distintas.
Si es un servidor de proyectos con recursos comunes: una única base de datos y distintos
esquemas para cada proyecto.
/****Ejemplo****/
--Viendo los Logs:
--Si queremos ver el history de todos los comandos ejecutados en el plsql:
[[local]:5432/jparedes@HR] [] # \s
o
[postgres@jp ~]$cat .psql_history
________________________________________
2010 Manual De Administración de PostgreSql
23
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Si queremos modificar el numero de comando en el History:
[[local]:5432/acolon@HR] [] > \set HISTSIZE 50000
--Para ponerlo permanente la colocamos en el archivo oculto .psqlrc:
[postgres@jp ~]$echo "\set HISTSIZE 7000" >> .psqlrc
--Verificamos el mismo:
[postgres@jp ~]$cat .psqlrc
\set PROMPT1 '[%m:%>/%n@%/] [%x] %# ':
\set HISTSIZE 5000
--Siqueremos agregar que cada consulta nos revuelva el tiempo en ejecucion en una
session:
[[local]:5432/postgres@sacademico] [] # \timing
--Si queremos que sea permanente:
[postgres@jp ~]$echo "\timing on" >> .psqlrc
--Desactivar el AUTOCOMMIT:
[postgres@jp ~]$echo "\set AUTOCOMMIT off" >> .psqlrc
--Verificar:
[[local]:5432/postgres@sacademico] [] # \set
AUTOCOMMIT = 'off'
PROMPT1 = '[%m:%>/%n@%/] [%x] %# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
VERBOSITY = 'default'
VERSION = 'PostgreSQL 8.4.4 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20080704 (Red Hat 4.1.2-46), 32-bit'
DBNAME = 'sacademico'
USER = 'postgres'
PORT = '5432'
ENCODING = 'UTF8'
HISTSIZE = '5000'
--Ya podemos hacer uso de COMMIT Y ROLLBACK.
Creación de roles (usuarios):
En PostgreSQL los usuarios son tipos de roles, el role es el concepto general.
Los roles son globales al cluster, se almacenan en la tabla del catálogo pg_authid y se
pueden consultar en las vistas pg_user y pg_roles.
________________________________________
2010 Manual De Administración de PostgreSql
24
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Desde el sistema operativo:
createuser [OPCIÓN]... [ROL]
Opciones:
-s, --superuser el rol será un superusuario
-S, --no-superuser el rol no será un superusuario
-d, --createdb el rol podrá crear bases de datos
-D, --no-createdb el rol no podrá crear bases de datos
-r, --createrole el rol podrá crear otros roles
-R, --no-createrole el rol no podrá crear otros roles
-l, --login el rol podrá conectarse (predeterminado)
-L, --no-login el rol no podrá conectarse
-i, --inherit el rol heredará los privilegios de los roles de
los cuales es miembro (predeterminado)
-I, --no-inherit rol no heredará privilegios
-c, --connection-limit=N lÍmite de conexiones para el rol
(predeterminado: sin lÍmite)
-P, --pwprompt asignar una contraseña al nuevo rol
-E, --encrypted almacenar la constraseña cifrada
-N, --unencrypted almacenar la contraseña sin cifrar
-e, --echo mostrar los comandos a medida que se ejecutan
-q, --quiet no escribir ningún mensaje
--help desplegar esta ayuda y salir
--version desplegar información de versión y salir
Opciones de conexión:
-h, --host=ANFITRIÓN nombre del servidor o directorio del socket
-p, --port=PUERTO puerto del servidor
-U, --username=NOMBRE nombre de usuario con el cual conectarse
(no el usuario a crear)
-W, --password pedir contraseña para conectarse
Si no se especifican -s, -S, -d, -D, -r, -R o el ROL, se preguntará
interactivamente.
El comando CREATE USER es ahora un alias de CREATE ROLE, pero con la opción
LOGIN por defecto.
/****Ejemplo****/
--Primero creamos un usuario:
--Creando Usuario Primero desde el Shell:
[postgres@jp ~]$createuser -W -S -d -r -e pomavid
Password:
CREATE ROLE pomavid NOSUPERUSER CREATEDB CREATEROLE INHERIT
LOGIN;
/***Practica***/
--Explique las opciones utilizadas anteriores y luego cree un usuario que no pueda
--crear usuario, y que tenga un limite de 5 conexiones ?
________________________________________
2010 Manual De Administración de PostgreSql
25
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Creando usuario desde otro usuario con su -:
[postgres@jp ~]$su - postgres -c "createuser --no-superuser --createrole --no-createdb
nitido2 --echo"
Password:
CREATE ROLE nitido2 NOSUPERUSER NOCREATEDB CREATEROLE INHERIT
LOGIN;
/***Practica***/
--Explique la opcion -c y --echo?
CREATE USER:
Tambien puede utilizar el comando CREATE USER SQL, que tiene varias opciones
disponibles con el comando createuser.
CREATE USER username [ [ WITH ]
SYSID uid
| [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password'
| CREATEDB | NOCREATEDB
| CREATEUSER | NOCREATEUSER
| IN GROUP groupname [, ...]
| VALID UNTIL 'abstime' ]
Forma Simple:
CREATE USER user;
Creara un usuario con ninguna contraseña ni privilegios adicionales. Tambien puede agregar
un usuario a un grupo ya existente y especificar una fecha en la que la contraseña del
usuario expirara. El sysid es como el numero uid de UNIX y postgres tomara un valor
predeterminado adecuado.
template1=# CREATE USER alice WITH PASSWORD 'pAssw0rd';
CREATE USER
template1=# CREATE USER bob VALID UNTIL 'Jan 31 2030';
CREATE USER
Desde el Shell:
CREATEUSER jp
/****Ejemplo****/
--Creado Usuario desde el PSQL:
[[local]:5432/postgres@postgres] [] # CREATE USER pomavid WITH PASSWORD 'plsql'
CREATEDB NOCREATEUSER;
CREATE ROLE
________________________________________
2010 Manual De Administración de PostgreSql
26
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
/***Practica***/
--Crear un usuario que expire en 3 dia y que su password este encriptado?
Listando Usuarios:
Puedes ver los usuarios en el servidor mediante la seleccion de la tabla de sistema
pg_shadow. Si usted no es un super usuario, no tendra permiso para acceder a esta tabla y
tendra que acceder a la vista pg_user lugar, que es identico, pero muestra la contraseña
como estrellas.
--Vista donde tenemos todos los usuarios almacenados:
[[local]:5432/postgres@postgres] [] # SELECT * from pg_user;
--Vamos a mostrar donde se almancenan las contraseñas:
[[local]:5432/postgres@postgres] [] # SELECT * from pg_shadow ;
Modificando Usuarios:
Si desea cambiar un usuario puede utilizar el comando SQL ALTER USER, que es similar
al comando CREATE USER excepto que usted no puede cambiar el sysid.
ALTER USER name [ [ WITH ]
[ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password'
| CREATEDB | NOCREATEDB
| CREATEUSER | NOCREATEUSER
| VALID UNTIL 'abstime' ]
/****Ejemplo****/
--Cambiando contraseña de un usuario:
[[local]:5432/postgres@postgres] [] # ALTER USER pepe WITH PASSWORD 'pomavid';
--Creacion de Roles:
CREATE ROLE General ;
CREATE ROLE Coronel ;
CREATE ROLE Cabo ;
CREATE ROLE Henry ;
--Agregamos un comentario a un ROLE, igual para otro Objeto
COMMENT ON ROLE henry IS 'Este Role es el pela papa';
--Ahora vamos a crear los Usuarios a logins en sus respectivos Roles:
--Usuario de Jose Paredes
CREATE ROLE jparedes
WITH LOGIN ENCRYPTED PASSWORD 'kikla'
IN ROLE General;
________________________________________
2010 Manual De Administración de PostgreSql
27
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Usuario de Orange
CREATE ROLE orange
WITH LOGIN PASSWORD 'orange'
IN ROLE General;
--Usuario de Deivi Bolges
CREATE ROLE dbolges
WITH LOGIN PASSWORD 'venaito'
IN ROLE General;
--Usuario de Felipe Mateo
CREATE ROLE fmateo
WITH LOGIN PASSWORD 'gentoo'
IN ROLE General;
--Usuario de Amaurys Rodriguez
CREATE ROLE arodriguez
WITH LOGIN PASSWORD 'centos'
IN ROLE Coronel
VALID UNTIL '2010-05-30';
--Usuario de Felipe Cristhian Nuñez
CREATE ROLE cnunez
WITH LOGIN PASSWORD 'salsa'
IN ROLE Coronel;
--Usuario de Felipe Franky Almonte
CREATE ROLE falmonte
WITH LOGIN PASSWORD 'bacula'
IN ROLE Coronel;
--Usuario de Elvyn Bolges
CREATE ROLE ebolges
WITH LOGIN PASSWORD 'bolsa'
IN ROLE Cabo
VALID UNTIL '2010-06-01';
--Usuario de Lus Merlin
CREATE ROLE lmerlin
WITH LOGIN PASSWORD 'quimica'
IN ROLE Cabo
VALID UNTIL '2010-05-31';
--Usuario de Henry Terrero
CREATE ROLE hterrero
WITH LOGIN PASSWORD 'java'
IN ROLE henry;
--Usuario de Anyelina Colon
CREATE ROLE acolon
WITH LOGIN PASSWORD 'secre'
IN ROLE henry;
________________________________________
2010 Manual De Administración de PostgreSql
28
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Validamos los objetos creados:
[[local]:5432/postgres@postgres] [] # SELECT * from pg_roles ;
[[local]:5432/postgres@postgres] [] # SELECT * from pg_user ;
[[local]:5432/postgres@postgres] [] # SELECT * from pg_group ;
[[local]:5432/postgres@postgres] [] # \du
[[local]:5432/postgres@postgres] [] # \dg
Permitir Usuario crear BD:
template1=# ALTER USER alice CREATEDB;
ALTER USER
Cambiando Nombre a un Usuario:
ALTER USER name RENAME TO newname;
template1=# ALTER USER bob RENAME TO colin;
ALTER USER
Cambiar contraseña:
template1=# ALTER USER colin WITH PASSWORD 'letmein';
ALTER USER
Comprobamos los Cambios y vemos los cambios: En la tabla pg_user
Eliminando Usuario:
Al igual que la creacion de usuarios, existen dos formas de eliminar los usuarios, utilizando
la línea de comandos o SQL. En la línea de comandos usariamos:
Desde el Shell
$ dropuser alice
DROP USER
Desde SQL
template1=# DROP USER colin;
DROP USER
Creando Grupo:
Los grupos son totalmente opcionales en postgresql. Solo se usan para simplificar la
concesion y revocacion de privilegios para el administrador db, y los usuarios no tienen que
ser un miembro de ningun grupo.
A diferencia de la creacion de usuarios, solo se pueden crear grupos utilizando SQL. El
comando es:
________________________________________
2010 Manual De Administración de PostgreSql
29
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
CREATE GROUP name [ [ WITH ]
SYSID gid
| USER username [, ...]]
Si quisieramos crear un grupo con alice como miembro inicial, se puede utilizar:
template1=# CREATE GROUP sales WITH USER alice;
CREATE GROUP
/****Ejemplo****/
--Creando Grupos:
[[local]:5432/postgres@postgres] [] # CREATE GROUP contabilidad;
--Creando grupo incluyendo un usuario:
[[local]:5432/postgres@postgres] [] # CREATE GROUP contabilidad user pepe;
Agregando o eliminando un Usuario de Grupo:
ALTER GROUP groupname [ADD|DROP] USER username [, ... ]
template1=# ALTER GROUP sales ADD USER bob;
ALTER GROUP
template1=# ALTER GROUP sales DROP USER alice;
ALTER GROUP
/****Ejemplo****/
--Agregando usuario al grupo creado:
[[local]:5432/postgres@postgres] [] # ALTER GROUP contabilidad ADD USER pomavid ;
--Eliminando usuario de un grupo:
[[local]:5432/postgres@postgres] [] # ALTER GROUP contabilidad DROP USER pepe ;
Viendo los Grupos:
Podemos ver la pertenencia al grupo al ver la tabla de sistema pg_group. En este ejemplo he
añadido alice nuevamente en el grupo de ventas.
template1=# select * from pg_group ;
La columna grolist muestra una lista de identificadores de usuario que estan en el grupo. Si
desea ver los nombres de usuario en un grupo en particular se puede utilizar:
template1=# select usename from pg_user, (select grolist from pg_group w
Re-Nombrando Grupo:
ALTER GROUP groupname RENAME TO newname
template1=# ALTER GROUP sales RENAME TO presales;
________________________________________
2010 Manual De Administración de PostgreSql
30
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
/****Ejemplo****/
--Vamos a renombrar un grupo:
[[local]:5432/postgres@postgres] [] # ALTER GROUP contabilidad RENAME TO dba;
Eliminando Grupo:
template1=# DROP GROUP presales;
/****Ejemplo****/
--Eliminando Grupo:
[[local]:5432/postgres@postgres] [] # DROP GROUP dba ;
/***Practica***/
--Crear un grupo llamado fcld y agregar tres usuario al mismo:
Creacion de tablespaces:
Si queremos especificar ubicaciones alternativas para determinadas bases de datos o tablas,
por ejemplo, queremos que ciertas tablas estén en otros discos distintos a los que se
encuentran por defecto, debemos crear tablespaces.
CREATE TABLESPACE tablespacename [ OWNER username ] LOCATION 'directory'
Tablespacename: no puede empezar en “ pg_“ porque está reservado a los tablespaces de
sistema.
Username: debe ser un superusuario del cluster.
Directory: se deben indicar trayectorias absolutas y el propietario del directorio debe ser el
usuario con el que se ha instalado PostgreSQL.
En versiones anteriores de PostgreSQL, existía el comando initlocation, que servía para
indicar ubicaciones alternativas para las bases de datos, y que exigía que se definiese una
variable de entorno similar a PGDATA para cada base de datos.
Nota: cuando se crean tablespaces, en $PGDATA/pg_tblspc se crean enlaces simbólicos a
los directorios físicos donde se encuentran, esto es importante tenerlo en cuenta en procesos
como el cambio de ubicaciones o en la restauración de ficheros desde una copia de
seguridad.
/****Ejemplo****/
--Trabajando con TableSpace:
--Auntomaticamente creamos el directorio tablespace en data y creamos los Los directorios
donde se alojaran los TableSpace:
[postgres@jp ~]$mkdir -p data/tablespace/tbe_{2008_{1,2},2009_{1,2},2010_1,0000_0}
________________________________________
2010 Manual De Administración de PostgreSql
31
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
ò...
--Queremos dos simplemente, uno para los datos y otro para los indices:
[postgres@jp ~]$mkdir -p data/tablespace/tablespace_datos
[postgres@jp ~]$mkdir -p data/tablespace/tablespace_index
--Aqui creamos nuestros TableSpaces:
[[local]:5432/postgres@postgres] [] # CREATE TABLESPACE TS_Pomavid_Datos
OWNER pepe LOCATION '/var/lib/pgsql/data/tablespace/tablespace_datos';
[[local]:5432/postgres@postgres] [] # CREATE TABLESPACE TS_Pomavid_Indices
OWNER pepe LOCATION '/var/lib/pgsql/data/tablespace/tablespace_index';
--Si queremos poner unos de los TableSpace por defecto:
SET default_tablespace=TS_Pomavid_Datos;
--Para saber el tamaño de que ocupa los TableSpace:
[[local]:5432/postgres@postgres] [] # SELECT
spcname,spclocation,pg_tablespace_size(spcname)/1024 "Tamaño MB"
FROM pg_tablespace
WHERE spclocation LIKE '/var/lib/pgsql/data/tablespace/tablespaces_datos%';
spcname | spclocation | Tamaño MB
---------+-------------+----------(0 rows)
Creación de bases de datos:
Una base de datos se puede crear desde la línea de comandos del sistema operativo (con el
usuario de sistema) o desde una conexión a una base de datos.(con un usuario que tenga
privilegios para crear bases de datos).
Desde el sistema operativo:
$ createdb
Opciones:
-D,
-E,
-O,
-T,
-e,
-q,
--help
--version
[OPCIÓN]... [NOMBRE] [DESCRIPCIÓN]
--tablespace=TBLSPC
tablespace por omisión de la base de datos
--encoding=CODIFICACIÓN codificación para la base de datos
--owner=DUEÑO
usuario que será dueño de la base de datos
--template=PATRÓN
base de datos patrón a copiar
--echo m
ostrar los comandos enviados al servidor
--quiet
no desplegar mensajes
mostrar esta ayuda y salir
mostrar el numero de versión y salir
________________________________________
2010 Manual De Administración de PostgreSql
32
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Opciones de conexión:
-h, --host=ANFITRIÓN nombre del servidor o directorio del socket
-p, --port=PUERTO puerto del servidor
-U, --username=USUARIO nombre de usuario para la conexión
-W, --password preguntar la contraseña
Si no se especifica, se creará una base de datos con el mismo nombre que el
usuario actual.
Desde un cliente SQL:
CREATE DATABASE name
[ [ WITH ] [ OWNER [=] dbowner ]
[ TEMPLATE [=] template ]
[ ENCODING [=] encoding ]
[ TABLESPACE [=] tablespace ]
[ CONNECTION LIMIT [=] connlimit ] ]
/****Ejemplo****/
--Ahora con el TableSpace creado ya podemos crear nuestra Bases Datos
--La misma alojara todos los objeto en el TableSpace ya creado:
--Desde el Shell:
[postgres@jp ~]$createdb poma -O pepe -D ts_pomavid_datos -e
CREATE DATABASE poma OWNER pepe TABLESPACE ts_pomavid_datos;
--Desde PsqL:
[[local]:5432/postgres@postgres] [] # CREATE DATABASE poma OWNER pepe
tablespace ts_pomavid_datos;
CREATE DATABASE
--Si queremos pasar una Base Datos ya creada a un TableSapce:
[[local]:5432/postgres@postgres] [] # ALTER DATABASE poma SET tablespace
ts_pomavid_datos ;
Esquemas:
Las bases de datos se organizan mediante esquemas, contenedores lógicos de objetos de
base de datos (tablas, vistas, procedimientos, etc.), básicamente son un espacio de nombres.
Es característico de los esquemas:
• Tienen un propietario.
• Permiten el uso de la base de datos por multiples usuarios sin interferencias.
• Permiten que se puedan instalar aplicaciones realizadas por terceros si que existan
colisiones en los nombres de los objetos.
• Para poder ver objetos de un esquema, debe usarse la notación esquema.objeto ya
que en PostgreSQL no existe el concepto de sinónimos como en Oracle.
Mas delante seguiremos hablando de Schema.!!!
________________________________________
2010 Manual De Administración de PostgreSql
33
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
/****Ejemplo****/
--Una vez creada la Base Datos procedemos a crear el Schema:
[[local]:5432/postgres@postgres] [] # CREATE SCHEMA cole authorization pepe;
CREATE SCHEMA
--Para crear un Objeto dentro del Schema creado es y en el TableSpace :
[[local]:5432/postgres@postgres] [] # CREATE TABLE cole.Bbella (Nombre Varchar(30))
tablespace ts_pomavid_datos;
--Podemos setear el search_path a nivel de base de datos y Schema, Por defecto :
[[local]:5432/postgres@postgres] [] # SET search_path TO cole;
SET
[[local]:5432/postgres@postgres] [] # SHOW search_path ;
search_path
------------cole
(1 row)
--Una vez creado el Schema todo objeto debe ser creado asi:
--**************Schema.Objeto**************
[[local]:5432/postgres@postgres] [] # SELECT * from cole.TAB TAB ;
--Listar los Schema:
[[local]:5432/postgres@pomavid] [] # \dn+
Permisos
Todos los objetos (tablas, vistas y secuencias) tienen un propietario, que es la persona que lo
creo. El propietario o un superusuario, puede establecer permisos en el objeto. Los permisos
se compone de un nombre de usuario o grupo y un conjunto de derechos. Estos derechos
descritos en la tabla de abajo.
Privilege
short name
SELECT
r
INSERT
a
UPDATE
w
DELETE
d
RULE
R
REFERENCES
x
TRIGGER
TEMPORARY
EXECUTE
USAGE
ALL
t
T
X
U
All
Description
Puede leer los datos del objeto.
Puede insertar datos en el objeto.
Puede cambiar los datos en el objeto.
Puede eliminar los datos del objeto.
Puede crear una regla sobre la tablas.
Se puede crear una clave externa a una tabla.¿Necesita
esto en ambos lados de la llave.
Se puede crear un desencadenador en la tabla.
Se puede crear una tabla temporal.
Se puede ejecutar la funcion.
Puede usar la lengua del procedimiento.
privilegios adecuados. Para las tablas, esto equivale a
arwdRxt
________________________________________
2010 Manual De Administración de PostgreSql
34
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Viendo los privilegios:
sales=# \dp
Asignando Privilegios:
GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES |
TRIGGER }
[,...] | ALL [ PRIVILEGES ] }
ON [ TABLE ] tablename [, ...]
TO { username | GROUP groupname | PUBLIC } [, ...] [ WITH GRANT OPTI
GRANT INSERT, UPDATE, DELETE ON TABLE suppliers TO bob;
Quitando Privilegios:
REVOKE INSERT UPDATE DELETE ON TABLE suppliers FROM bob CASCASE
/****Ejemplo****/
--Ahora vamos Asignacion de Derechos sobre Objetos:
--Utilizaremos el Scripts de hr mas otros objetos creados por los usuarios:
[postgres@jp ~]$psql < hr_Postgreql.sql
--Vemos los objetos insertados desde el Scripts hr:
[[local]:5432/postgres@HR] [] # \d
List of relations
Schema |
Name
| Type
| Owner
--------+-----------------------+----------+---------public | countries
| table
| postgres
public | departments
| table
| postgres
public | employees
| table
| postgres
public | job_history
| table
| postgres
public | jobs
| table
| postgres
public | locations
| table
| postgres
public | regions
| table
| postgres
public | regions_region_id_seq | sequence | postgres
(8 rows)
--Para cambiar el dueño de una tabla, de esta manera usted puede tener todos los privilegios
sobre un objeto:
[[local]:5432/postgres@HR] [] # ALTER TABLE countries owner to jparedes ;
ALTER TABLE
[[local]:5432/postgres@HR] [] # \d
List of relations
Schema |
Name
| Type | Owner
--------+-----------------------+----------+---------public | countries
| table | jparedes
________________________________________
2010 Manual De Administración de PostgreSql
35
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Ahora nos logueamos con el usuario jparedes en la Bases Datos HR:
[postgres@jp ~]$psql -U jparedes HR
psql (8.4.4)
Type "help" for help.
[[local]:5432/jparedes@HR] [] >
--Ahora tratamos de consultar una de las tablas de la Base Datos HR:
[[local]:5432/jparedes@HR] [] > SELECT * from employees ;
ERROR: permission denied for relation employees
--Vamos otorgar privilegios al usuario jparedes para hacer SELECT sobre la tabla
employees;
--como hicimos login con jparedes que no es el dueño ni tiene privilegios sobre la Bases
Datos HR,
--Tenemos que hacer login con el dueño del objeto o el DBA:
[postgres@jp ~]$psql -U postgres HR
--Ortogamos privilegios de SELECT al usuario jparedes:
[[local]:5432/postgres@HR] [] # GRANT SELECT ON employees TO jparedes;
GRANT
--Listo ya el usuario jparedes puede hacer SELECT sobre la tabla employees:
[[local]:5432/jparedes@HR] [] > SELECT first_name, salary from employees limit 1;
first_name | salary
------------+-------John
| 14000
(1 row)
--Le revocamos los privilegios de SELECT al usuario jparedes:
[[local]:5432/postgres@HR] [] # REVOKE SELECT ON employees FROM jparedes;
REVOKE
--Hacer pruebas:
[[local]:5432/jparedes@HR] [] > SELECT * from employees ;
ERROR: permission denied for relation employees
--Tenenos un ROLE llamado General y el mismo estan agregados varios usuarios
--Vamos darle privilegios de SELECT a ese ROLE completo:
[[local]:5432/postgres@HR] [] # GRANT SELECT ON employees TO general ;
--Ahora cualquira de los usuarios que estan en ese ROLE puede hacer SELECT sobre las
tablas del Schema HR:
________________________________________
2010 Manual De Administración de PostgreSql
36
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Hacer pruebas:
[postgres@jp ~]$psql -U orange HR
psql (8.4.4)
Type "help" for help.
[[local]:5432/orange@HR] [] > SELECT first_name, salary from employees limit 1;
first_name | salary
-------------+-------John
| 14000
(1 row)
--Vamos REVOCAR los privilegios al ROlE General:
[[local]:5432/postgres@HR] [] # REVOKE SELECT ON employees FROM general ;
REVOKE
--Hacer pruebas:
[[local]:5432/fmateo@HR] [] > SELECT first_name, salary from employees limit 1;
ERROR: permission denied for relation employees
--Vamos a darle todos los priviegio al ROLE General sobre un Schema:?
--Primero hacemos logion con el usuario hterrero el General de los pela papa:
[postgres@jp ~]$psql -U hterrero sacademico
psql (8.4.4)
Type "help" for help.
--Hacemos una consulta a la tabla cursos del Schema sacademicoschema:
[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos;
ERROR: relation "sacademicoschema.curso" does not exist
LINE 1: SELECT * from sacademicoschema.cursos;
^
sacademico
--Otorga los permisos en el Schema SacademicoSchema:
[[local]:5432/postgres@sacademico] [] # GRANT ALL ON SCHEMA sacademicoschema
to hterrero;
GRANT
--Prueba:
[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos;
ERROR: permission denied for relation cursos
--Otorgamos privilegios al objeto dentro del Schema:
[[local]:5432/postgres@sacademico] [] # GRANT ALL ON sacademicoschema.cursos to
hterrero;
________________________________________
2010 Manual De Administración de PostgreSql
37
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
GRANT
--Prueba:
[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos limit 2;
id_curso |
curso
| costo | fecha_registro
| quien_registro
-----------+---------------------------------+--------+--------------------------+----------1 | Diplomado GNU/Linux
| 3500 | 2009-08-05 21:57:24 | admin
2 | Unixs(Solaris*Aix*Hp-Ux) | 3500 | 2009-08-05 21:57:31 | admin
(2 rows)
--Revocando los privilegios de de un ROLE sobre un Schema:
[[local]:5432/postgres@sacademico] [] # REVOKE ALL ON SCHEMA sacademicoschema
from hterrero;
--Prueba:
[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos limit 1;
ERROR: permission denied for schema sacademicoschema
LINE 1: SELECT * from sacademicoschema.cursos limit 1;
--Acceso a los requerimientos previamente solicitados:
[[local]:5432/postgres@sacademico] [] # GRANT USAGE ON SCHEMA
sacademicoschema to hterrero;
GRANT
--Prueba:
[[local]:5432/hterrero@sacademico] [] > SELECT * from sacademicoschema.cursos limit 3;
id_curso |
curso
| costo | fecha_registro
| quien_registro
-----------+-----------------------------------+---------+---------------------------+----------1 | Diplomado GNU/Linux
| 3500 | 2009-08-05 21:57:24 | admin
2 | Unixs(Solaris*Aix*Hp-Ux) | 3500 | 2009-08-05 21:57:31 | admin
3 | Asterisk-I
| 12500 | 2009-08-16 15:57:14 | root@local
host
(3 rows)
--El usuario puede cambiar la misma session:
--Primero vemos nuestra session y usuario:
[[local]:5432/orange@sacademico] [] # SELECT session_user, current_user;
session_user | current_user
---------------+-------------orange
| orange
(1 row)
--Cambiamos de session:
[[local]:5432/jparedes@sacademico] [] # SET session AUTHORIZATION hterrero ;
SET
--Resultado:
________________________________________
2010 Manual De Administración de PostgreSql
38
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
[[local]:5432/hterrero@sacademico] [] > SELECT session_user, current_user;
session_user | current_user
----------------+-------------hterrero
| hterrero
(1 row)
--Para cambiar solo de usuario en una session:
--Primero vemos nuestra session y usuario:
[[local]:5432/jparedes@sacademico] [] # SELECT session_user, current_user;
session_user | current_user
----------------+-------------jparedes
| jparedes
(1 row)
--Cambio de ROLE:
[[local]:5432/jparedes@sacademico] [] # SET role hterrero ;
SET
--Resultado:
[[local]:5432/jparedes@sacademico] [] > SELECT session_user, current_user;
session_user | current_user
----------------+-------------jparedes
| lmerlin
(1 row)
--Para resetiar la session:
[[local]:5432/jparedes@sacademico] [] > RESET session AUTHORIZATION ;
RESET
--Verifico:
[[local]:5432/jparedes@sacademico] [] # SELECT session_user, current_user;
session_user | current_user
----------------+-------------jparedes
| jparedes
(1 row)
--Ver los permisos de los objetos existentes:
--Hacemos login en la Bases Datos HR:
[postgres@jp ~]$psql -U falmonte HR
psql (8.4.4)
Type "help" for help.
--Luego vemos informacion sobre los permisos de los objetos exists, no tenemos:
[[local]:5432/falmonte@HR] [] > \z
________________________________________
2010 Manual De Administración de PostgreSql
39
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Access privileges
Schema |
Name
| Type
| Access privileges | Column access privileges
--------+----------------------------+---------------+----------------------+-------------------------public | countries
| table
|
|
public | departments
| table
|
|
public | employees
| table
|
|
public | job_history
| table
|
|
public | jobs
| table
|
|
public | locations
| table
|
|
public | pepe
| sequence |
|
public | regions
| table
|
|
public | regions_region_id_seq | sequence |
|
(9 rows)
--Verificamos si pordemos consultas algunos de esos objetos:
[[local]:5432/hterrero@HR] [] > SELECT * from countries ;
ERROR: permission denied for relation countries
--No tenemos ningunos vamos a otorgar algunos privilegios al ROLE coronel, en el cual se
encuentra el usuario falmonte:
[[local]:5432/postgres@HR] [] # GRANT SELECT ON countries TO coronel ;
GRANT
[[local]:5432/postgres@HR] [] # GRANT UPDATE ON countries TO cnunez ;
GRANT
[[local]:5432/postgres@HR] [] # GRANT DELETE ON countries TO arodriguez ;
GRANT
[[local]:5432/postgres@HR] [] # GRANT ALL ON countries TO general ;
GRANT
--Prueba:
[[local]:5432/falmonte@HR] [] > SELECT * from countries limit 3;
country_id | region_id | name
-------------+-------------+----------AR
|
2
| Argentina
AU
|
3
| Australia
BE
|
1
| Belgium
(3 rows)
--Luego vemos informacion sobre los permisos de los objetos exists ya aplicados:
[[local]:5432/falmonte@HR] [] > \z
Access privileges
Schema |
Name
| Type | Access privileges
| Column access
privileges
----------+--------------------------+---------+-------------------------------+-------------------public | countries
| table | postgres=arwdDxt/postgres |
________________________________________
2010 Manual De Administración de PostgreSql
40
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
: coronel=r/postgres
: cnunez=w/postgres
: arodriguez=d/postgres
: general=arwdDxt/postgres
public | departments
| table
public | employees
| table
public | job_history
| table
public | jobs
| table
public | locations
| table
public | pepe
| sequence
public | regions
| table
public | regions_region_id_seq | sequence
(9 rows)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-- Si queremos Permitir conceder el mismo privilegios a otro:
[[local]:5432/postgres@HR] [] # GRANT ALL ON locations TO coronel with grant option;
--Verificamos:
[[local]:5432/falmonte@HR] [] > \z
Access privileges
Schema |
Name
| Type |
Access privileges
| Column access
privileges
----------+---------------------------+------------+-------------------------------------+---------------public | countries
| table
| postgres=arwdDxt/postgres |
: coronel=r/postgres
: cnunez=w/postgres
: arodriguez=d/postgres
: general=arwdDxt/postgres
public | departments
| table
|
|
public | employees
| table
|
|
public | job_history
| table
|
|
public | jobs
| table
|
|
public | locations
| table
| postgres=arwdDxt/postgres |
: coronel=a*r*w*d*D*x*t*/postgres
public | pepe
| sequence |
|
public | regions
| table
|
|
public | regions_region_id_seq | sequence |
|
(9 rows)
/***Practica***/
--Explique en detalle los permisos reflejados:
--Revoque el permiso de lectura a general.
--Otorgue el permiso de escritura y actualizacion a falmonte
--*****Restableciendo y Eliminando Obejtos--*****:
--Nota: Si queremos eliminar algunos objetos o Bases Datos no debe existir ningun ROLE
asociado al mismo:
________________________________________
2010 Manual De Administración de PostgreSql
41
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Regresamos a la sesión principal por defecto.
RESET SESSION AUTHORIZATION;
--Ahora vamos a otorgar y rebocar privilegios a nivel de columnas:
--Revocamos todos los privilegios al usuario acolon sobre la tabla countries de la Bases
Datos HR:
[[local]:5432/postgres@HR] [] # REVOKE ALL ON countries FROM acolon ;
--Prueba:
[[local]:5432/acolon@HR] [] > SELECT region_id from countries ;
ERROR: permission denied for relation countries
[[local]:5432/acolon@HR] [] > SELECT country_id from countries ;
ERROR: permission denied for relation countries
[[local]:5432/acolon@HR] [] > SELECT name from countries ;
ERROR: permission denied for relation countries
[[local]:5432/acolon@HR] [] > SELECT * from countries ;
ERROR: permission denied for relation countries
--Actualmente no tenemos privilegios sobre ninguna columna de la tabla countries.
--Procedemos a Otorgar privilegios a una columna de la tabla countries:
[[local]:5432/postgres@HR] [] # GRANT SELECT (name) on countries to acolon;
GRANT
--Prueba:
[[local]:5432/acolon@HR] [] > SELECT name from countries limit 3;
name
----------Argentina
Australia
Belgium
(3 rows)
--Intentamos hacer SELECT a otra columna de la misma tabla:
[[local]:5432/acolon@HR] [] > SELECT country_id from countries ;
ERROR: permission denied for relation countries
--De igualmenare solo tenemos privilegios de hacer consulta sobre esa columna
--si tratamos de actualizar nos dira:
[[local]:5432/acolon@HR] [] > UPDATE countries SET name = 'R.D' where
name='Belgium';
ERROR: permission denied for relation countries
________________________________________
2010 Manual De Administración de PostgreSql
42
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Vamos Otorgar privilegios de Actualización sobre la columna name de la tabla countries:
[[local]:5432/postgres@HR] [] # GRANT UPDATE (name) on countries to acolon;
--Prueba:
[[local]:5432/acolon@HR] [] > UPDATE countries SET name = 'San Juam' where
name='Argentina';
UPDATE 1
--Si queremos ver los privilegios de la columna name de la tabla countries:
[[local]:5432/postgres@HR] [] # \dp
Access privileges
Schema |
Name
| Type |
Access privileges
| Column access
privileges
----------+----------------------------+-----------+----------------------------------+----------------public | countries
| table
| postgres=arwdDxt/postgres | name:
: acolon=rw/postgres
public | departments
| table
|
|
public | employees
| table
|
|
public | job_history
| table
|
|
public | jobs
| table
|
|
public | locations
| table
|
|
public | regions
| table
|
|
public | regions_region_id_seq | sequence |
|
(8 rows)
--Para Revocar privilegios de una columna:
[[local]:5432/jparedes@HR] [] # REVOKE SELECT (name) on countries from acolon;
REVOKE
--Prueba:
[[local]:5432/acolon@HR] [] > SELECT name from countries limit 3;
ERROR: permission denied for relation countries
--Verificamos los privilegios:
[[local]:5432/acolon@HR] [] > \dp countries
Access privileges
Schema | Name | Type | Access privileges
| Column access privileges
----------+-------------+-------+----------------------------------+----------------------public | countries | table | postgres=arwdDxt/postgres | name: acolon=w/postgres
(1 row)
Cambiando EL propietario de una tabla:
ALTER TABLE suppliers OWNER TO bob;
Trabajando con Schema:
test=# CREATE SCHEMA foo;
CREATE SCHEMA
________________________________________
2010 Manual De Administración de PostgreSql
43
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
test=# CREATE TABLE foo.info (id INT, txt TEXT);
CREATE TABLE
test=# INSERT INTO foo.info VALUES(1, 'This is schema foo');
INSERT 23062 1
test=# CREATE SCHEMA bar;
CREATE SCHEMA
test=# CREATE TABLE bar.info (id INT, txt TEXT);
CREATE TABLE
test=# INSERT INTO bar.info VALUES(1, 'This is schema bar');
INSERT 23069 1
test=# SELECT foo.info.txt, bar.info.txt
FROM foo.info, bar.info
WHERE foo.info.id=bar.info.id;
Listar los Objetos en Schema Public:
test=# \dv
Cuando el nombre de esquema no esta previsto en un objeto de base de datos, PostgreSQL
se refiere a la ruta de busqueda ", que define el orden en el que buscar a traves de esquemas
de un nombre de objeto no calificados.
En el ejemplo anterior, info_view fue creado en el esquema publico porque el publico es
siempre por defecto que figuran en la ruta de busqueda. La configuracion actual de la ruta
de busqueda se puede ver con SHOW search_path:
test=# SHOW search_path;
Una ruta de busqueda se mantiene para cada conexion de base de datos, para cambiar la ruta
de busqueda uso search_path SET ...:
test=# SET search_path TO foo;
test=# \dt
Para alterar permanentemente la ruta de busqueda establecidos en cada conexion, el uso:
ALTER USER test SET search_path TO bar,foo;
Este cambio solo tendra efecto despues de volver a conectarse a la base de datos. Para
continuar con los ejemplos anteriores, el establecimiento de la ruta de busqueda a la barra,
foo significa ahora info bar mesa seran seleccionados por defecto:
test=# SET search_path TO bar, foo;
test=# SELECT txt FROM info;
test=# \d info
________________________________________
2010 Manual De Administración de PostgreSql
44
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Permisos y Seguridad en Schema:
CREATE SCHEMA tarzan AUTHORIZATION tarzan;
or
CREATE SCHEMA AUTHORIZATION tarzan;
El permiso USAGE determina si un usuario puede realizar ninguna operacion sobre el
esquema de otro usuario:
GRANT USAGE ON SCHEMA tarzan TO jane;
REVOKE USAGE ON SCHEMA tarzan TO jane;
Una vez que el permiso USAGE ha sido concedida, privilegios en tanto existentes como de
nueva creacion, los objetos de esquema se debe conceder de forma explicita:
GRANT SELECT ON tarzan.banana_inventory TO jane;
REVOKE SELECT ON tarzan.banana_inventory FROM jane;
Si el uso es revocado, ni objetos personales, incluidos los que el usuario tiene privilegios en
adelante, se puede acceder. Si el uso se concede de nuevo, cualquier privilegios anteriores se
reactiva automaticamente sobre el objeto.
El gran privilegio CREATE en un esquema permite a un usuario para crear objetos en el
esquema de otro usuario:
GRANT CREATE ON SCHEMA tarzan TO jane;
REVOKE CREATE ON SCHEMA tarzan TO jane;
Utilice el nombre de usuario reservado PUBLIC la hora de conceder o revocar privilegios
de todos los usuarios:
GRANT ALL ON SCHEMA tarzan TO PUBLIC;
Eliminando Schema:
Forma Simple:
DROP SCHEMA tarzan;
DROP SCHEMA tarzan CASCADE;
Funciones de Schema:
* Current_schema ()
Devuelve el nombre del esquema actual (esquema por primera vez en la ruta de
busqueda), segun lo establecido por search_path SET... Tenga en cuenta que se resolveran
en el primer esquema existente en la ruta de busqueda, no necesariamente el primero. Si no
hay un esquema se encuentra, se devuelve NULL.
* Current_schemas (boolean)
Devuelve todos los esquemas en la ruta de busqueda como una matriz, si se llama con
TRUE, esquemas implicitos (esquemas especiales como pg_catalog que se añaden a la ruta
de busqueda de forma automatica si no se especifica explicitamente) se devuelven.
________________________________________
2010 Manual De Administración de PostgreSql
45
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Esquemas especiales
Cada base de datos PostgreSQL contiene una serie de esquemas especiales requeridas por el
servidor y que no puede ser suprimida o alterada. Todos comienzan con pg_. Tenga en
cuenta que los nombres de esquema a partir de pg_ no estan permitidos.
Los esquemas especiales son:
* Pg_catalog: Contiene las tablas del sistema, las funciones y puntos de vista explotacion
de meta-informacion sobre la base de datos.
* Pg_temp_x: Contiene las tablas temporales que solo son visibles para una conexion de
base de datos concreta
* Pg_toast: Contiene manteca y dulces surtidos.
Desde PostgreSQL 7.4, tambien habra un INFORMATION_SCHEMA compuesto de
puntos de vista predefinidos que contienen informacion descriptiva sobre la base de datos
actual. Esta informacion se presenta en un formato definido en el estandar SQL y
proporciona informacion consistente y estandarizada sobre la base de datos y en cierta
medida las capacidades de la base de datos. El INFORMATION_SCHEMA es para
propositos de compatibilidad y probables, no seran relevantes para la mayoria de las
aplicaciones.
Limitaciones
Actualmente no es posible la "transferencia" objetos entre esquemas. soluciones posibles:
* Uso
CREATE TABLE AS new_schema.mytable SELECT * FROM old_schema.mytable
para transferir los datos y recrear todas las restricciones asociadas, indices, etc secuencias
manualmente.
* Crear la tabla en el nuevo esquema con la definicion actual y el uso
INSERT INTO new_schema.mytable SELECT * FROM old_schema.mytable;
para rellenar la tabla.
Cambiar el nombre de los esquemas se introducira en PostgreSQL 7.4 utilizando el esquema
ALTER .. RENOMBRAR CON ... de comandos.
Administrar privilegios de copia de seguridad:
Supongamos que usted quiere tener un 'backup' de usuario, que solo tienen la copia de
seguridad permanentes cuando este en funcionamiento. Asi pues, aqui una funcion que
puede administrar los privilegios para cada esquema (conceder y revocar).
________________________________________
2010 Manual De Administración de PostgreSql
46
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
CREATE OR REPLACE FUNCTION manage_backup_privileges(p_user text, p_schema
text, action BOOLEAN)
RETURNS void AS
$BODY$
DECLARE
objeto text;
BEGIN
FOR objeto IN
SELECT tablename FROM pg_tables WHERE schemaname = p_schema
UNION
SELECT relname FROM pg_statio_all_sequences WHERE schemaname =
p_schema
LOOP
IF action = true THEN
RAISE NOTICE 'Asignando todos los privilegios a % sobre %.%', p_user,p_schema,
objeto;
EXECUTE 'GRANT ALL PRIVILEGES ON ' || p_schema || '.' || objeto || ' TO ' ||
p_user ;
ELSE
RAISE NOTICE 'Quitando todos los privilegios a % sobre %.%', p_user,p_schema,
objeto;
EXECUTE 'REVOKE ALL PRIVILEGES ON ' || p_schema || '.' || objeto || ' FROM ' ||
p_user ;
END IF;
END LOOP;
END;
$BODY$
LANGUAGE 'plpgsql' VOLATILE;
Ejecutalo, es muy simple. Si desea activa los privilegios de uso de este formulario:
SELECT manage_backup_privileges('usuario','esquema', true);
Si desea que las Revocar los Privilegios:
SELECT manage_backup_privileges('usuario','esquema', false);
Script Bash Para Proporcionar acceso de solo lectura para cada tabla en la base de datos
PostgreSQL:
#!/bin/sh
#
# Proporcionar acceso de solo lectura en base de datos PostgreSQL
# Use: ./pgaccess $database $username
tables=$(psql $1 -A -t -c "SELECT table_name FROM information_schema.tables WHERE
table_schema = 'public';")
for table in $tables
do
echo "Proporcionar select to $2 on $table"
psql $1 -c "GRANT SELECT ON $table to $2;"
________________________________________
2010 Manual De Administración de PostgreSql
47
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
done
Como se puede ver en la actualidad hay dos variables necesarias para ejecutar el script que
son base de datos y nombre de usuario. El script anterior debe ejecutarse en el siguiente
formato. El nombre de la secuencia de comandos para pgaccess.sh eso es lo que se utiliza en
el ejemplo siguiente.
Leer usuario solo sintaxis de secuencias de comandos:
./pgaccess $database $username
Basta con sustituir $ base de datos con el nombre de la base de datos que estan
proporcionando el acceso y reemplazar $ nombre de usuario con el nombre del usuario que
se facilitara el acceso SELECT a la base de datos PostgreSQL.
Atencion
Debe usted asegurarse de que su base de datos no se
actualiza durante su backup. Si es necesario, pare el
postmaster, edite los permisos del fichero
/usr/local/pgsql/data/pg_hba.conf para permitirle
a usted solo su uso, y relance de nuevo postmaster.
Si esta usted actualizando un sistema existente, mate ahora el servidor de la base de datos.
Teclee:
$ ps ax | grep postmaster
Esto deberia listar los numeros de proceso para una serie de procesos, de un modo similar a:
263
777
? SW
p1 S
0:00 (postmaster)
0:00 grep postmaster
Teclee la siguiente línea, reemplazando pid con el identificador (id) del proceso postmaster
(263 en el caso anterior). (No utilice el id del proceso "grep
postmaster".) (N. del T. tambien puede hacerlo con la línea
$ ps ax | grep postmaster |grep -v grep
que le dara la misma salida, pero sin incluir la línea correspondiente al mismo proceso
"grep". Fin de la N. del T.)
$ kill pid
Sugerencia: En sistemas que arrancan PostgreSQL en el durante la
secuencia de arranque de la maquina, probablemente se encontrara un
fichero startup que cumplira el mismo cometido. Por ejemplo, en un sistema
Linux RedHat, se deberia encontrar que
$ /etc/rc.d/init.d/postgres.init stop
funcione correctamente para parar la base.
________________________________________
2010 Manual De Administración de PostgreSql
48
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Administrando desde GNU/Linux
Todas las ordenes de Postgres que se ejecutan directamente desde un shell de Unix se
encuentran en el directorio †œ.../bin†œ. Incluir este directorio en su variable de entorno
path facilitara mucho la ejecucion de los mismos.
Existe una coleccion de catalogos del sistema en cada servidor. La misma incluye una clase
(pg_user) que contiene una instancia para cada usuario valido en Postgres. La instancia
especifica un conjunto de privilegios sobre Postgres, como la posibilidad de actuar como
superusuario en Postgres, la posibilidad de crear/destruir bases de datos y la posibilidad de
actualizar los catalogos del sistema. Un usuario de Unix no puede hacer nada con Postgres
hasta que se instale una instancia apropiada en dicha clase. Puede encontrarse mas
informacion sobre los catalogos del sistema ejecutando consultas sobre las clases
apropiadas.
Iniciando postmaster
No le puede suceder nada a una base de datos a menos que este corriendo el proceso
postmaster. Como administrador, hay una serie de cosas que debe recordar antes de iniciar
postmaster. Vea las secciones de instalacion y configuracion en este mismo manual. De
todos modos, si ha unstalado Postgres siguiendo las instrucciones de instalacion al pie de la
letra, lo unico que tendra que hacer para iniciar el proceso postmaster es introducir esta
simple orden:
% postmaster
Ocasionalmente, postmaster escribe mensajes que le seran de ayuda para resolver
problemas. Si desea ver los mensajes de diagnostico de postmaster, puede iniciarlo con la
opcion -d y redirigir la salida al archivo de registro:
% postmaster -d > pm.log 2>&1 &
Si no desea ver los mensajes, inicielo de la forma
% postmaster -S
y postmaster sera "S"ilencioso. Observe que al no haber el signo ampersand ("&") al final
del ultimo ejemplo, no se ejecuta como proceso de fondo.
Seguridad:
La seguridad de la base de datos esta implementada en varios niveles:
Proteccion de los ficheros de la base de datos. Todos los ficheros almacenados en la base
de datos estan protegidos contra escritura por cualquier cuenta que no sea la del
superusuario de Postgres.
Las conexiones de los clientes al servidor de la base de datos estan permitidas, por
defecto, unicamente mediante sockets Unix locales y no mendiante sockets TCP/IP. Ha de
arrancarse el demonio con la opcion -i para permitir la conexion de clientes no locales.
Las conexiones de los clientes se pueden restringir por direccion IP y/o por nombre de
________________________________________
2010 Manual De Administración de PostgreSql
49
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
usuario mediante el fichero pg_hba.conf situado en PG_DATA.
Las conexiones de los clientes pueden ser autentificadas mediante otros paquetes externos.
A cada usuario de Postgres se le asigna un nombre de usuario y (opcionalmente) una
contraseña. Por defecto, los usarios no tienen permiso de escritura a bases de datos que no
hayan creado.
Los usuarios pueden ser incluidos en grupos, y el acceso a las tablas puede restringirse en
base a esos grupos.
Autentificacion de Usuarios:
Autentificacion es el proceso mediante el cual el servidor de la base de datos y el postmaster
se aseguran de que el usario que esta solicitando acceso a la base de datos es en realidad
quien dice ser. Todos los usarios que quieren utilizar Postgres se comprueban en la tabla
pg_user para asegurarse que estan autorizados a hacerlo. Actualmente, la verificacion de la
identidad del usuario se realiza de distintas formas:
Desde la shell del usuario
Un demonio que se lanza desde la shell del usuario anota el id original del usuario antes
de realizar un setuid al id del usuario postgres. El id original del usuario se emplea como
base para todo tipo de comprobaciones.
Desde la red
Si Postgres se instala como distribuido, el acceso al puerto TCP del postmaster esta
disponible para todo el mundo. El ABD configura el fichero pg_hba.conf situado en el
directorio PG_DATA especificando el sistema de autentificacion a utilizar en base al equipo
que realiza la conexion y la base de datos a la que se conecta. Ver pg_hba.conf(5) para
obtener una descripcion de los sistemas de autentificacion disponibles. Por supuesto la
autentificacion basada en equipos no es perfecta incluso en los sistemas Unix. Es posible,
para determinados intrusos, enmascarar el equipo de origen. Estos temas de seguridad estan
fuera del alcance de Postgres.
Creacion de una base de datos:
Supongamos que quiere crear una base de datos llamada mibase. Puede hacerlo con el
siguiente orden:
% createdb nombredb
Postgres le permite crear cualquier numero de bases de datos en una maquina dada, y usted
se convierte automaticamente en el administrador de la base de datos que acaba de crear.
Los nombres de las bases de datos han de comenzar por un caracter alfabetico, y su longitud
esta limitada a 31 caracteres. No todos los usuarios estan autorizados para convertirse en
administradores de bases de datos. Si Postgres rechaza la orden de crear bases de datos, es
que necesita que el administrador del sistema le garantice derechos para crear las bases de
datos. Consulte a su administrador de sistemas si le ocurre eso.
________________________________________
2010 Manual De Administración de PostgreSql
50
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
/****Ejemplo****/
/*********Shell***************/
--Si entramos al directorio data/base y queremos el oids para cual Bases Datos corresponde:
[postgres@jp base]$pwd
/var/lib/pgsql/data/base
[postgres@jp base]$ls
1 11563 11564 27369 27627 pgsql_tmp
--Comando a utilizar:
[postgres@jp ~]$oid2name
All databases:
Oid Database Name
Tablespace
---------------------------------------27627
HR
pg_default
16428
poma ts_pomavid_datos
16411
pomavid ts_pomavid_datos
11564
postgres
pg_default
27369 sacademico
pg_default
11563 template0
pg_default
1 template1
pg_default
Acceso a la base de datos:
Una vez que ha construido la base de datos, puede acceder a ella por los siguientes medios:
Ejecutando el programa monitor de terminal de Postgres (psql) que le permite introducir,
editar y ejecutar ordenes SQL de un modo interactivo.
Escribiendo un programa en C que use la biblioteca de rutinas libpq. Esto le permite enviar
ordenes SQL desde C y obtener las respuestas y mensajes de estado en su programa. Esta
interfaz se discute en el documento Guia de programacion en PostgreSQL.
Puede que quiera ejecutar el programa psql, para probar los ejemplos de este manual. Puede
activarlo para la base de datos nombredb escribiendo la orden:
% psql nombredb
Recibira como respuesta el siguiente mensaje:
Welcome to the Postgres interactive sql monitor:
type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: nombredb
nombredb=>
Copia de seguridad y restauracion:
________________________________________
2010 Manual De Administración de PostgreSql
51
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Atencion
Deben realizarse copias de seguridad de las bases de datos
regularmente. Dado que Postgres gestiona sus propios ficheros
en el sistema, no se recomienda confiar en los sistemas de copia
de seguridad del sistema para las copias de respaldo de las
bases de datos; no hay garantia de que los ficheros esten en un
estado consistente que permita su uso despues de la
restauracion.
Postgres proporciona dos utilidades para realizar las copias de seguridad de su sistema:
pg_dump para copias de seguridad de bases de datos individuales y pg_dumpall para
realizar copias de seguridad de toda la instalacion de una sola vez.
La copia de seguridad de una sola base de datos puede realizarse usando la siguiente orden:
% pg_dump nombredb > nombredb.pgdump
y puede ser restaurada usando
cat nombredb.pgdump | psql nombredb
Esta tecnica puede usarse para mover bases de datos a una nueva localizacion y para
renombrar bases de datos existentes.
Bases de datos grandes:
Dado que Postgres permite tablas de mayor tamaño que el permitido por el sistema de
ficheros, puede resultar problematico el volcado de una tabla a un fichero, ya que el fichero
resultante seguramente superara el tamaño maximo permitido.
Como pg_dump escribe en stdout, puede usar las herramientas *nix para sortear estos
posibles problemas:
Uso de volcados comprimidos:
% pg_dump nombredb | gzip > nombrefichero.dump.gz
la recuperamos con:
% createdb nombredb
% gunzip -c nombrefichero.dump.gz | psql nombredb
o
% cat nombrefichero.dump.gz | gunzip | psql nombredb
Use split:
% pg_dump nombredb | split -b 1m - nombrefichero.dump.
y lo recuperamos con:
________________________________________
2010 Manual De Administración de PostgreSql
52
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
% createdb nombredb
% cat nombrefichero.dump.* | pgsql nombredb
Por supuesto, el nombre del fichero (nombrefichero) y el contenido de la salida de pg_dump
no tiene por que coincidir con el nombre de la base de datos. Ademas, la base de datos
restaurada puede tener un nombre distinto, por lo que este mecanismo tambien es efectivo
para renombrar bases de datos.
Tratamiento de problemas :
El postmaster presenta ocasionalmente mensajes que pueden ser de ayuda en la
solución de problemas. Si desea ver mensajes de depuración de postmaster, puede iniciarlo
con la opción -d y redirigir la salida a un fichero de registro:
% postmaster -d > pm.log 2>&1 &
Si no desea ver estos mensajes, puede escribir
% postmaster -S
y el postmaster entrará en modo “S “ilencioso. Nótese que no se incluye el simbolo “& “ en
el último ejemplo, ya que el postmaster se ejecutará en segundo plano.
Tareas administrativas: Copias de seguridad y recuperación:
Una vez el sistema está en marcha, el administrador de base de datos debe establecer una
serie de tareas rutinarias para mantener el servidor en buenas condiciones, estas tareas se
pueden resumir en las siguientes:
Copias de seguridad ( y pruebas de restauración de vez en cuando)
Tarea de limpieza: VACUUM
Tarea de reindexar: REINDEX
Copy
[[local]:5432/postgres@postgres][]# \h COPY
Command: COPY
Description: copy data between a file and a table
Syntax:
COPY tablename [ ( column [, ...] ) ]
FROM { 'filename' | STDIN }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ]
[ CSV [ HEADER ]
[ QUOTE [ AS ] 'quote' ]
[ ESCAPE [ AS ] 'escape' ]
[ FORCE NOT NULL column [, ...] ]
COPY { tablename [ ( column [, ...] ) ] | ( query ) }
________________________________________
2010 Manual De Administración de PostgreSql
53
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
TO { 'filename' | STDOUT }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ]
[ CSV [ HEADER ]
[ QUOTE [ AS ] 'quote' ]
[ ESCAPE [ AS ] 'escape' ]
[ FORCE QUOTE column [, ...] ]
/****Ejemplo****/
--creemos una tabla de prueba
[[local]:5432/postgres@postgres][]# CREATE TABLE prueba (nombre varchar, apellidos
varchar);
--Creamos el archivo con las informaciones que queramos
-bash-4.0$ cat > prueba.cop
Jose
Mexy
Bianca
Joel
Jorge
--Vamos a esto....
--Realicemos el copy para la tabla prueba en la columna nombre
[[local]:5432/postgres@postgres][]# COPY prueba (nombre) from '/var/lib/pgsql/prueba.cop';
COPY 5
Time: 32.212 ms
--Veamos nuestra tabla
[[local]:5432/postgres@postgres][]# select * from prueba ;
nombre | apellidos
--------+----------Jose |
Mexy |
Bianca |
Joel |
Jorge |
(5 rows)
Time: 0.777 ms
--Nitido se efectuo correctamente
--Ahora haremos un DELETE a al tabla para borrar los datos introducidos
[[local]:5432/postgres@postgres][]# DELETE FROM prueba where nombre is not null;
DELETE 5
Time: 28.648 ms
[[local]:5432/postgres@postgres][]# SELECT * from prueba ;
nombre | apellidos
---------+----------(0 rows)
Time: 1.023 ms
________________________________________
2010 Manual De Administración de PostgreSql
54
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Okay esta vasia.
--Cambiamos el contenido de nuestro archivo
-bash-4.0$ cat > prueba.cop
Jose, Paredes
Mexy, Alvarez
Bianca, SAntana
Joel, Santos
Jorge, Almonte
--Ahora haremos el copy con un delimiter, asi especificamos que informacion va para cada
columna.
[[local]:5432/postgres@postgres][]# COPY prueba (nombre, apellidos) from '/var/lib/pgsql/
prueba.cop' with delimiter ',';
COPY 5
Time: 31.330 ms
--Tambien podemos realizarlo con \copy de la misma manera asi
[[local]:5432/postgres@postgres][]# \copy prueba (nombre, apellidos) from
'/var/lib/pgsql/prueba.cop' with delimiter ','
Time: 25.355 ms
[[local]:5432/postgres@postgres][]# select * from prueba ;
nombre | apellidos
--------+----------Jose | Paredes
Mexy | Alvarez
Bianca | SAntana
Joel | Santos
Jorge | Almonte
(5 rows)
Time: 0.718 ms
--Tendra el mismo resultado.
--Todo Ready...
Mantenimiento del fichero de seguimiento
Conviene automatizar estas tareas mediante el uso de herramientas del SO (como el cron,
rotatelogs, etc) y/o scripts.
Se deben realizar rutinariamente, se debe fijar la frecuencia adecuada para cada una de ellas
y comprobar su correcta ejecución.
Copias de seguridad:
Las copias de seguridad son esenciales para las recuperaciones frente a fallos, se deben
determinar las frecuencia conveniente, que será función del tamaño de los datos y de la
frecuencia con que son modificados, lo cual marcará la estrategia de copias de seguridad.
Algunas herramientas usadas para las copias de seguridad nos permitirán además poder
trasladar datos de unas bases de datos a otras.
________________________________________
2010 Manual De Administración de PostgreSql
55
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Además hemos de asegurarnos de que los logs, ficheros WAL, estén en otro disco, o hacer
copias más frecuentes de estos logs ya que en la versión 8 ya se pueden copiar
automáticamente y usar en la recuperación.
Existen tres formas principales de realizar copias de seguridad:
1-copia de seguridad de ficheros del SO
2-Volcado SQL usando las herramientas PostgreSQL: pg_dump (pg_dumpall) y pg_restore.
3-Volcado en línea y recuperación en el punto (PITR)
Hay que tener claro que lo que estamos tratando aquí es la copia de seguridad de las bases
de datos, de los clusters, no estamos haciendo copia de seguridad del software instalado, del
cual, conviene de vez en cuando hacer una copia de seguridad de los ficheros del SO.
Copias de seguridad de ficheros del SO:
Es el método más sencillo, pero el más ineficaz, se trata de realizar una copia de todos los
ficheros de un cluster, por ejemplo:
$ su - postgres
$ cd /tmp/backup
$ tar cvfz copia.tar.gz $PGDATA
Desventajas de este método:
La base de datos debe estar parada
No se pueden recuperar partes del cluster (bases de datos, esquemas, tablas, etc.)
La recuperación consiste en borrar todo el cluster y descomprimir el fichero de copia de
seguridad, con lo que se pierden los datos que se hayan modificado desde la última copia de
la base de datos.
Volcado SQL:
Los volcados de este tipo se realizan usando las herramientas que nos proporciona
PostgreSQL. Estos volcados son muy flexibles y de gran utilidad, nos permitirán hacer
copias de seguridad de toda la base de datos o de partes de ella, y luego, dada una copia de
seguridad, nos permitirán restaurar lo que
queramos.
Además, estas herramientas sirven para la transmisión de datos entre bases de datos.
Las herramientas que se van a utilizar son:
pg_dump: vuelca una base de datos o parte de ella a un fichero, bien en texto plano o en un
formato propio de PostgreSQL. Se puede recuperar cualquier objeto que esté en el fichero
aisladamente. El servidor debe estar en marcha.
pg_dumpall: vuelca un cluster completo
pg_restore: recupera los objetos volcados en una copia de seguridad que no se realizón en
texto plano sino en un formato propio de PostgreSQL.
________________________________________
2010 Manual De Administración de PostgreSql
56
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
psql: se usa para recuperar los volcados en texto plano.
pg_dump: Con este comando, podemos volcar una base de datos o parte de ella a un fichero
script en texto plano o en un formato propio de PostgreSQL.
Si lo hacemos en un fichero de texto plano:
Tendremos un fichero de texto con instrucciones SQL.
Podemos usar psql para restaurar.
Es portable a servidores SQL.
Si lo hacemos en un formato propio de PostgreSQL:
Debemos usar pg_restore para restaurar
Es más flexible
Sólo es portable entre servidores PostgreSQL (aunque esto no es del todo cierto, debido a
que con pg_restore se pueden crear ficheros SQL en texto plano).
Si no se especifica un nombre de base de datos entonces el valor de la variable de ambiente
PGDATABASE es usado, y lo mismo con PGUSER, PGHOST y PGPORT.
Tiene más opciones, usando œ$ man pg_dump œse pueden ver detalles de esas opciones.
Ejemplos de uso:
-- Exportar una base de datos:
$ pg_dump -f bdnominas.sql -h otro host -p 6432 bdnominas
-- Exportar un esquema, redireccionando la salida
$ pg_dump -n nominas2004 > esq_nominas2004.sql
-- Volcar una base de datos llamada mibd en un fichero tar:
$ pg_dump -Ft mibd > bd.tar
pg_dumpall:
Con pg_dumpall se realizan volcados del cluster completo, incluyendo roles de grupo y
roles de login.
Tiene más opciones, usando œ$man pg_dumpallœse pueden ver detalles de esas opciones.
Como se ve, este comando es similar a pg_dump, pero tiene algunas diferencias:
No permite la opción de indicar el fichero de salida, con lo cual hay que redireccionar la
salida a un fichero.
No tiene la opción de formatos de fichero de salida, la salida es siempre un fichero de texto
plano.
Tiene una opción muy interesante que es "-g" que permite exportar únicamente los objetos
globales, con lo que podemos generar un script que contenga la creación de usuarios y roles.
________________________________________
2010 Manual De Administración de PostgreSql
57
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Ejemplos de uso:
-- Exportar un cluster:
$ pg_dumpall > micluster.sql
-- Exportar solo los datos
$ pg_dumpall -a > misdatos.sql
-- Exportar solo los roles / usuarios de una base de datos en otro servidor
-- que además, tiene otro superusuario
$ pg_dump_all -g -h otroservidor -U otrosuperusuario -p 6432 > misusuarios.sql
-- Exportar solo los esquemas
$ pg_dumpall -s > misesquemas.sql
Recuperación con psql:
La recuperación con psql se puede hacer cuando los ficheros de volcado son texto plano con
sentencias SQL. Hacemos uso de la posibilidad que tiene psql de ejecutar código que le
viene redireccionado de entrada desde un fichero.
$ psql [bd_destino] < fichero.sql
El fichero se puede modificar antes de cargarlo, pero hay que llevar mucho cuidado con los
editores que gastemos, porque hay algunos que realizan conversiones de codificación de
caracteres o formatos y esto puede producir efectos indeseados.
Si lo que se quiere recuperar es un cluster completo o la parte global (roles/usuarios),
siempre se debe restaurar en la base de datos template1.
Recuperación con pg_restore:
Con pg_restore se pueden restaurar a partir de ficheros en formato distinto a texto plano (tar
o uno propio de PostgreSQL comprimido). Se puede seleccionar y reordenar la selección.
Hay dos modos de hacerlo:
Directamente a una base de datos, es la opción por defecto œ-dœ
Volcando en otro fichero que actua de conversor. Se crea asi un script en texto plano que
podemos modificar antes de ejecutarlo.
Por ejemplo, supongamos que hemos hecho una copia de seguridad de nuestra base de datos
en formato comprimido y se han perdido datos de una tabla de empleados, para recuperarlos
hacemos:
$ pg_restore -Fc -f empleados.sql -t empleados bd.dump
$ pgsql bdorigen œc œdrop table empleados œ
$ psql bdorigen < empleados.sql
________________________________________
2010 Manual De Administración de PostgreSql
58
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Recuperación ante fallos:
Fallos en la memoria principal
PostgreSQL se recupera bien en fallos de la memoria primaria (cortes de luz ,cuelgues, etc.),
el sistema se recupera usando los ficheros de log (WAL) y nunca se pierde una transacción
confirmada.
Los ficheros de log permiten que además, la base de datos no tenga que estar
completamente actualizada (sync) para mantener los datos ante fallos en la memoria
principal (pérdida de valores en los bufferes compartidos).
Hay un número máximo de logs: 2*CHECKPOINT_SEGMENTS+1
Si se llenan sin que se haya hecho sync,el sistema hace un sync y avisa de que hacen falta
más logs.
El trabajo y el tiempo de recuperación dependen del número de checkpoint_segments,
cuanto mayor sea el sistema aguantará más tiempo sin llevar los búferes sucios a disco y
será más eficiente, aunque también se requiere más espacio en disco y las recuperaciones
requeriran más tiempo.
/***Ejemplo****/
/****************** Backups******************/
--Vamos iniciar la parte de los Backups:
/*********PG_DUMP***************/
--Listamos todas las Bases Datos:
[postgres@jp ~]$psql -l
List of databases
Name
| Owner
| Encoding | Collation
| Ctype
| Access privileges
--------------+---------------+-----------+-----------------+-------------+-------------HR
| fcld
| UTF8 | en_US.UTF-8 | en_US.UTF-8 | =Tc/fcld
: fcld=CTc/fcld
poma
| pepe
| UTF8 | en_US.UTF-8 | en_US.UTF-8 |
pomavid | postgres
| UTF8 | en_US.UTF-8 | en_US.UTF-8 |
postgres | postgres
| UTF8
| en_US.UTF-8 | en_US.UTF-8 | =T/postgres
: postgres=CTc/postgres
sacademico | sacademico | UTF8
| en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres
| UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres
: postgres=CTc/postgres
template1 | postgres
| UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres
: postgres=CTc/postgres
(7 rows)
--Haciendo Backup de la Bases Datos HR:
[postgres@jp ~]$pg_dump -v HR > HR_Backup.sql
________________________________________
2010 Manual De Administración de PostgreSql
59
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Si queremos ver el tamaño del Backup:
[postgres@jp ~]$du -sch HR_Backup.sql
K HR_Backup.sql
K total
--Si queremos restaurar el Backup:
--Borramos la Bases Datos:
[postgres@jp ~]$dropdb HR
--Creamos la Bases Datos:
[postgres@jp ~]$createdb HR
--Hacemos login en ella y verificamos q esta vacia:
[postgres@jp ~]$psql -U jparedes HR
Timing is on.
psql (8.4.4)
Type "help" for help.
[[local]:5432/jparedes@HR] [] # \d
No relations found.
--Ahora procedemos a restautar el Backup:
[postgres@jp ~]$psql -d HR -f HR_Backup.sql
--Hacemos login en ella y verificamos:
[postgres@jp ~]$psql -U jparedes HR
Timing is on.
psql (8.4.4)
Type "help" for help.
[[local]:5432/jparedes@HR] [] # \d
List of relations
Schema |
Name
| Type | Owner
--------+-----------------------+----------+---------public | countries
| table | postgres
public | departments
| table | postgres
public | employees
| table | postgres
public | job_history
| table | postgres
public | jobs
| table | postgres
public | locations
| table | postgres
public | regions
| table | postgres
public | regions_region_id_seq | sequence | postgres
(8 rows)
--Tambien podemos restaurar el Backup de esta manera:
[postgres@jp ~]$psql HR < HR_Backup.sql
________________________________________
2010 Manual De Administración de PostgreSql
60
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Tambien con cat volcamos el backup:
[postgres@jp backups]$cat caro_hr_backup.sql |psql HR
--Ahora vamos hacer un Backup Comprimido de la Bases Datos Sacademico:
[postgres@jp ~]$pg_dump sacademico |gzip -c > sacademico_Backup.sql.gz
--Verificamos el archivo:
[postgres@jp ~]$file sacademico_Backup.sql.gz
sacademico_Backup.sql.gz: gzip compressed data, from Unix, last modified: Wed Jun 2
08:49:50 2010
--Restaurando un Backup comprimido:
[postgres@jp ~]$gunzip sacademico_Backup.sql.gz |xargs psql -d sacademico -f
sacademico_Backup.sql
/*^o^*/
--Podemos hacerlo paso a paso:
--Primero descomprimimos el Backup:
[postgres@jp ~]$gunzip -v sacademico_Backup.sql.gz
--Restauramos el Backup descomprimido:
[postgres@jp ~]$psql < sacademico_Backup.sql
--Ahora vamos hacer un Backups de una tabla especifica:
[postgres@jp ~]$pg_dump -t sacademicoschema.cursos sacademico >
sacademico_Tcurso.sql
--Realizando Backup de una maquina remota:
[postgres@jp ~]$pg_dump sacademico -h 192.168.100.13 -U postgres >
remote_sacademico.sql
Password: pepe
/***Practica***/
--Realice un backup de la DB HR utilizando la opcion -a
--Haga lo mismo pero con la opcion -v
--Explique la diferencia, Segun su resultado (verificar cada archivo.sql con cat)
/*********PG_DUMPALL***************/
--Vamos Extraer toda las Bases Datos:
[postgres@jp ~]$pg_dumpall > Full_Backup.dmp
--Volvemos a restaurar el Backup:
[postgres@jp ~]$psql -e template1 < Full_Backup.dmp
________________________________________
2010 Manual De Administración de PostgreSql
61
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Backup de una sola Bases Datos:
/*********PG_RESTORE***************/
--Primeros Hacemos un Backup del usuarios HR:
[postgres@jp ~]$pg_dump -Ft HR > hr.tar
--Ahora vamos a restaurarlo en una Bases Datos ya Existente:
[postgres@jp ~]$pg_restore -d poma hr.tar
/***Practica***/
--Restaura los backups ya realizados dela DB HR
Scripts Basico de hacer Backup:
#!/bin/bash
DIR=/backup/psql
[ ! $DIR ] && mkdir -p $DIR || :
LIST=$(psql -l | awk '{ print $1}' | grep -vE '^-|^List|^Name|template[0|1]')
for d in $LIST
do
pg_dump $d | gzip -c > $DIR/$d.out.gz
Crontab
El crontab, es un archivo en donde podemos configurar tareas para que se ejecuten automáticamente
en nuestro sistema, digamos por ejemplo descargar un archivo de respaldo diariamente, o borrar
ciertos archivos periódicamente, ejecutar un script que haga algo, etc, digamos que podemos
automatizar las tareas, para no estar haciéndolas a mano.
¿Qué es cron?
Cron es el nombre del programa que permite a usuarios Linux/Unix ejecutar automáticamente
comandos o scripts (grupos de comandos) a una hora o fecha específica. Es usado normalmente
para comandos de tareas administrativas, como respaldos, pero puede ser usado para ejecutar
cualquier cosa. Como se define en las páginas del manual de cron (#> man cron) es un demonio que
ejecuta programas agendados.
Iniciar cron
Cron es un demonio (servicio), lo que significa que solo requiere ser iniciado una vez, generalmente
con el mismo arranque del sistema. El servicio de cron se llama crond. En la mayoría de las
distribuciones el servicio se instala automáticamente y queda iniciado desde el arranque del sistema,
se puede comprobar de varias maneras:
/***Ejemplo****/
[root@guerrero ~]# /etc/init.d/crond status
crond (pid 1320) is running...
________________________________________
2010 Manual De Administración de PostgreSql
62
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Tambien con
/etc/rc.d/init.d/crond status
Usa cualquiera de los dos dependiendo de tu distro
--o si tienes el comando service instalado:
[root@guerrero ~]# service crond status
crond (pid 1320) is running...
--se puede también revisar a través del comando ps:
[root@guerrero ~]# ps -ef | grep crond
root 14320 1 1 15:51 ? 00:00:00 crond
root 14328 4304 0 15:51 pts/0 00:00:00 grep crond
--si por alguna razón, cron no esta funcionando:
[root@guerrero ~]# /etc/init.d/crond start
Starting crond: [ OK ]
--Si el servicio no estuviera configurado para arrancar desde un principio, bastaría con agregarlo
con el comando chkconfig:
[root@guerrero ~]# chkconfig --level 35 crond on
Usando cron
Hay al menos dos maneras distintas de usar cron: La primera es en el directorio /etc, donde muy
seguramente encontrarás los siguientes directorios:
•
•
•
•
cron.hourly
cron.daily
cron.weekly
cron.monthly
Si se coloca un archivo tipo script en cualquiera de estos directorios, entonces el script se ejecutará
cada hora, cada día, cada semana o cada mes, dependiendo del directorio.
Para que el archivo pueda ser ejecutado tiene que ser algo similar a lo siguiente:
#!/bin/sh
#script que genera un respaldo
cd /usr/documentos
tar czf * respaldo
cp respaldo /otra_directorio/.
Nótese que la primera línea empieza con #!, que indica que se trata de un script shell de bash, las
demás líneas son los comandos que deseamos ejecute el script. Este script podría nombrarse por
ejemplo respaldo.sh y también debemos cambiarle los permisos correspondientes para que pueda
ser ejecutado, por ejemplo:
#> chmod 700 respaldo.sh
#> ls -l respaldo.sh
-rwx------ 1 root root 0 Jul 20 09:30 respaldo.sh
La "x" en el grupo de permisos del propietario (rwx) indica que puede ser ejecutado.
Si este script lo dejamos en cron.hourly, entonces se ejecutará cada hora con un minuto de todos los
días, en un momento se entenderá el porque.
________________________________________
2010 Manual De Administración de PostgreSql
63
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Como segundo modo de ejecutar o usar cron es a través de manipular directamente el archivo
/etc/crontab. En la instalación por defecto de varias distribuciones Linux, este archivo se verá a algo
como lo siguiente:
[root@guerrero ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
#|||||
# * * * * * command to be executed
Las primeras cuatro líneas son variables que indican lo siguiente:
SHELL es el 'shell' bajo el cual se ejecuta el cron. Si no se especifica, se tomará por defecto el
indicado en la línea /etc/passwd correspondiente al usuario que este ejecutando cron.
PATH contiene o indica la ruta a los directorios en los cuales cron buscará el comando a ejecutar.
Este path es distinto al path global del sistema o del usuario.
MAIL TO es a quien se le envía la salida del comando (si es que este tiene alguna salida). Cron
enviará un correo a quien se especifique en este variable, es decir, debe ser un usuario válido del
sistema o de algún otro sistema. Si no se especifica, entonces cron enviará el correo al usuario
propietario del comando que se ejecuta.
HOME es el directorio raíz o principal del comando cron, si no se indica entonces, la raíz será la
que se indique en el archivo /etc/passwd correspondiente al usuario que ejecuta cron.
Los comentarios se indican con # al inicio de la línea.
Después de lo anterior vienen las líneas que ejecutan las tareas programadas propiamente. No hay
límites de cuantas tareas pueda haber, una por renglón. Los campos (son 7) que forman estas líneas
están formados de la siguiente manera:
Minuto Hora DiaDelMes Mes DiaDeLaSemana Usuario Comando
Un asterisco * como valor en los primeros cinco campos, indicará inicio-fin del campo, es decir
todo. Un * en el campo de minuto indicará todos los minutos.
Ejecutando Cron con múltiples usuarios, comando crontab
Linux es un sistema multiusuario y cron es de las aplicaciones que soporta el trabajo con varios
usuarios a la vez. Cada usuario puede tener su propio archivo crontab, de hecho el /etc/crontab se
asume que es el archivo crontab del usuario root, aunque no hay problema que se incluyan otros
usuarios, y de ahí el sexto campo que indica precisamente quien es el usuario que ejecuta la tarea y
es obligatorio en /etc/crontab.
Pero cuando los usuarios normales (e incluso root) desean generar su propio archivo de crontab,
entonces utilizaremos el comando crontab.
En el directorio /var/spool/cron (puede variar según la distribución), se genera un archivo cron para
cada usuario, este archivo aunque es de texto, no debe editarse directamente.
________________________________________
2010 Manual De Administración de PostgreSql
64
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Se tiene entonces, dos situaciones, generar directamente el archivo crontab con el comando:
/***Ejemplo****/
[root@guerrero ~]# crontab -e
Con lo cual se abrira el editor por default (generalemente vi) con el archivo llamado crontab vacio y
donde el usuario ingresará su tabla de tareas y que se guardará automáticamente como
/var/spool/cron/usuario.
16 8 * 1-5 ls /etc/lvm
# me listara el contenido de /lvm a las 4:20 de todos los 8 sea de lunes a viernes
crontab: installing new crontab
--Revisemos:
[root@guerrero ~]# cat /var/spool/cron/root
16 8 * 1-5 ls /etc/lvm
# me listara el contenido de /lvm a las 4:20 de todos los 8 sea de lunes a viernes
--Podemos comprobar el resultado del cron revisando:
[root@guerrero ~]# cat /var/spool/mail/root
--Super!!
Controlando el acceso a cron
Cron permite controlar que usuarios pueden o no pueden usar los servicios de cron. Esto se logra de
una manera muy sencilla a través de los siguientes archivos:
/etc/cron.allow
/etc/cron.deny
Para impedir que un usuario utilice cron o mejor dicho el comando crontab, basta con agregar su
nombre de usuario al archivo /etc/cron.deny, para permitirle su uso entonces sería agregar su
nombre de usuario en /etc/cron.allow, si por alguna razón se desea negar el uso de cron a todos los
usuarios, entonces se puede escribir la palabra ALL al inicio de cron.deny y con eso bastaría.
/****Ejemplos****/
--Le impediremos al Usuario Brouli que utilice cron
[root@guerrero ~]# echo Brouli >>/etc/cron.deny
--Revisemos el archivo
[root@guerrero ~]# cat /etc/cron.deny
Brouli
--Ahora comprovemoslo
[Brouli@guerrero ~]$ crontab -e
You (Brouli) are not allowed to use this program (crontab)
See crontab(1) for more information
________________________________________
2010 Manual De Administración de PostgreSql
65
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Si negao y pico jeje!!
Sigamos
--Impidiendo el uso para todos
[root@guerrero ~]# echo ALL >>/etc/cron.deny
o para agregar un usuario mas a cron.allow
[root@guerrero ~]# echo Brouli >>/etc/cron.allow
Si no existe el archivo cron.allow ni el archivo cron.deny, en teoría el uso de cron esta entonces sin
restricciones de usuario. Si se añaden nombres de usuarios en cron.allow, sin crear un archivo
cron.deny, tendrá el mismo efecto que haberlo creado con la palabra ALL. Esto quiere decir que
una vez creado cron.allow con un solo usuario, siempre se tendrán que especificar los demás
usuarios que se quiere usen cron, en este archivo.
COMANDO chkconfig:
El comando chkconfig se usa para cambiar, actualizar y consultar información de runlevel para los
servicios del sistema. chkconfig es un comando de administrador.
SINTAXIS:
La sintaxis es
chkconfig [opciones]
/****Ejemplo****/
--Nos lista los niveles de ejecucion y el estado del servicio (si esta activo o no).
[root@guerrero ~]# chkconfig --list
--Veamos el estado del servicio iptables
[root@guerrero ~]# chkconfig --list iptables
iptables
0:off
1:off
2:on
3:on
4:on
5:on
6:off
Iptables: es el nombre de la herramienta de espacio de usuario (User Space, es decir, área de
memoria donde todas las aplicaciones, en modo de usuario, pueden ser intercambiadas hacia
memoria virtual cuando sea necesario) a través de la cual los administradores crean reglas para cada
filtrado de paquetes y módulos de NAT. Iptables es la herramienta estándar de todas las
distribuciones modernas de GNU/Linux
--Ahora estableceremos el estado de iptables Podemos utilizar <on | off| reset| resetpriorities>, en
este caso sera off, veamos...
[root@guerrero ~]# chkconfig iptables off
--El estado del servicio iptables es totalmente inactivo.
[root@guerrero ~]# chkconfig --list iptables
iptables
0:off 1:off 2:off 3:off 4:off
5:off
6:off
--Tambien podemos definirlo por levels asi:
[root@guerrero ~]# chkconfig --level 345 iptables on
________________________________________
2010 Manual De Administración de PostgreSql
66
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--Ahora los levels 3,4 y 5 estan ON. verifiquemos
[root@guerrero ~]# chkconfig --list iptables
iptables
0:off
1:off
2:off
3:on
4:on
5:on
6:off
--Chevere!
Fallos en memoria secundaria (disco):
Hasta la versión 7.X no había recuperación total, si se producía una pérdida dentro del
$PGDATA, había que recurrir a la copia de seguridad física más reciente y desde ese
momento las actualizaciones se perdían, aunque tuviéramos los ficheros de log. Aquí es
donde, en la versión 8.X se incorpora el volcado en línea y la recuperación PITR.
Volcado en línea y recuperación PITR:
A partir de la versión 8.0.0, PostgreSQL permite actualizar la copia de seguridad con los
cambios que proporcionan en los ficheros de log que hayan sobrevivido.
Para poder utilizar esta opción tiene que estar habilitado el archivado WAL y en
funcionamiento. Los ficheros WAL son segmentos de 16Mb que se nombran
secuencialmente en el cual el sistema va copiando los cambios en la base de datos. El
sistema recicla los ficheros de log que no van a ser necesitados renombrándolos a números
superiores dentro de la secuencia.
Para activar el archivado, en el fichero postgresql.conf debemos indicar el comando de
copia para preservar los ficheros de log, parámetro archive_command, haciendo, por
ejemplo:
archive_command = cp -i %p /mnt/server/archivedir/%f < /dev/null
donde %p representa el nombre del fichero con la ruta absoluta y %f sin la ruta.
Para realizar copias de seguridad en línea se siguen los siguientes pasos:
1. activar el archivado WAL
2. antes de empezar y desde una consola SQL hay que ejecutar:
select pg_start_backup(nombre_copia);
3. con el servidor en marcha, hacemos la copia desde el sistema operativo, no hace falta
parar el servidor, por ejemplo:
$ tar cvf backup_nombre_copia.tar $PGDATA
4. cuando acaba, desde la consola SQL, marcamos el final, ejecutamos:
select pg_stop_backup();
________________________________________
2010 Manual De Administración de PostgreSql
67
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
5. se crea así un fichero de marca en el directorio $PGDATA/pg_xlog/archive_status y
copia los logs que se reciclan en donde se haya indicado en archive_command.
Para realizar una recuperación se siguen los siguientes pasos:
1. parar el postmaster
2. si tenemos espacio, copiar el cluster dañado y los tablespaces a otra ubicación
3. borrar todos los ficheros que hay dentro del cluster asi como los correspondientes a los
tablespaces
4. recuperar la copia de seguridad (comprobando los tablespaces en pg_tblspc)
$ tar xvf backup_nombre_copia
5. borrar los ficheros WAL en $PGDATA/pg_xlog porque probablemente estarán obsoletos.
6. si existen ficheros WAL sin archivar, tal como hemos hecho en el paso 2, copiarlos a
pg_xlog
7. crear un fichero de comandos de recuperación, recovery.conf en el directorio $PGDATA.
Existe una plantilla, recovery.conf.sample, en el directorio $HOME/pgsql/share. Se copia
con el nombre recovery.conf en $PGDATA y se edita. En principio, si se quiere recuperar
todo y los logs están en su sitio, no hay que tocar nada.
8. se arranca PostgreSQL que entra en modo de recuperación y procede a leer la
información de los WAL que necesite, siendo necesario evitar que se conecten usuarios
normales durante la recuperación.
9. inspeccionar la base de datos, si todo ha ido correcto, los datos estarán recuperados hasta
la última transacción confirmada y el fichero recovery.conf se renombra a recovery.done.
Conviene tener los ficheros log en un disco distinto al que está el cluster, para que la
recuperación sea mejor. Para ello, debemos mover el directorio pg_xlog a otro disco y crear
un enlace simbólico, con el cluster parado.
Por ejemplo:
$ mkdir /disco2/pg/
$ cd $PGDATA
$ mv pg_xlog /disco2/pg
$ ln s /disco2/pg/pg_xlog pg_xlog
Además, para asegurarnos que no se nos pierden archivos de log, podemos hacer un cron
que copie los archivos que no están llenos en una ubicación distinta.
En el fichero recovery_conf hay una serie de parámetros que pueden ayudar a recuperar
hasta el momento o la transacción que queramos (lo que se conoce como recuperación
Point-in-time):
restore_command: lo que ejecuta esta variable es lo que PostgreSQL ejecutará antes de
empezar la recuperación.
________________________________________
2010 Manual De Administración de PostgreSql
68
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
Por ejemplo:
restore_command = cp /mnt/server/archivedir/%f %p
recovery_target_time: hasta qué momento
recovery_target_xid: hasta una transacción determinada
recovery_target_inclusive: si los dos casos anteriores son inclusive o no.
Tareas administrativas: Vacuum:
Vacuum es un proceso de limpieza que se encarga de:
•
•
Recuperar el espacio de disco ocupado por filas modificadas o borradas.
Actualizar las estadísticas usadas por el planificador / optimizador
•
evitar la pérdida de datos muy antiguos debido al reuso del identificador de
transacción
/****Ejemplo****/
/*********VACUUMDB***************/
--Vamos a limpiar y analizar la Bases Datos HR:
[postgres@jp ~]$vacuumdb HR -v
[postgres@jp ~]$vacuumdb -ze pomavid
VACUUM ANALYZE;
Recomendaciones:
Usar VACUUM FULL si alguna tabla ha cambiado mucho y no va a crecer en el futuro.
Ejecutar VACUUM diariamente en todas las bases de datos
Hacerlo con más frecuencia sobre tablas con mucha carga de actualización.
Determinar las tablas grandes con pocas actualizaciones para eliminarlas del VACUUM.
Dentro del VACUUM, se pueden actualizar las estadísticas con la opción ANALYZE,
haciendo lo mismo que hace el comando ANALYZE, así proporciona:
1
información usada por el optimizador
1
1
no es muy pesado el proceso porque se realiza sobre una muestra al azar.
necesario si la distribución de los datos cambia mucho
El problema del XID (identificador de transacción):
Otro problema que resuelve VACUUM es el evitar la pérdida de datos muy antiguos,
porque MVCC introduce el concepto de marca de tiempo XID identificador de transacción.
________________________________________
2010 Manual De Administración de PostgreSql
69
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
XID está limitado a 32 bits, es decir cuando llega a 232 se reinicializa, tiene un
funcionamiento circular, si esto llega a ocurrir, se perderían datos. Existen además dos XID
especiales: BootstrapXID y FrozenXID. Cada vez que se ejecuta VACUUM se guarda
información que se puede consultar:
select datname, age(datfrozenxid) from pg_database;
Así, si se ejecuta poco el vacuum, la base de datos avisa al administrador, se deben limpiar
las tablas una vez cada mil millones de transacciones. El caso es que se recomienda hacer
VACUUM diario.
AUTOVACUUM:
Para evitar los problemas con la ejecución de VACUUM, a partir de la versión 8,
PostgreSQL incorpora un proceso de fondo AUTOVACUUM que se ejecuta
periódicamente cuando está habilitado y él mismo comprueba las tablas con alta carga de
actualizaciones. Hay una serie de parámetros en postgresql.conf para modificar el
comportamiento de este proceso.
Reindex:
Otras tareas importantes son las reindexaciones, ya que pueden haber índices incorrectos por
problemas en el software o hardware o porque haya que optimizar el índice debido a que
tiene páginas muertas que hay que eliminar.
Ejemplos:
-- reparar un indice:
reindex index nomindice;
-- reparar todos los índices de una tabla:
reindex table nomtabla;
-- reparar los índices del catálogo de base de datos, para esto
-- hay que levantar postmaster sin que use los índices y luego reindexar
$ export PGOPTIONS="-P: // significa lo mismo que $ postmaster -P
$ psql bd
bd=# reindex database bd;
-- reparar los índices del catálogo compartido (pg_database, pg_group, pg_shadow,
-- etc.). No se debe levantar postmaster si no que hay que arrancar un proceso
-- autónomo:
$ postgres -D $PGDATA -P prueba
backend> reindex index indice_catalogo_compartido
Se puede introducir en el cron que realice ciertas operaciones de mantenimiento:
$ crontab -e
// se abre el fichero de cron y añadimos estas líneas:
0 3 * * * psql -c 'VACUUM FULL;' test
________________________________________
2010 Manual De Administración de PostgreSql
70
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
0 3 * * * vacuumdb -a -f
0 30 * * * reindexdb bd
¡ATENCIÓN!, problema entre Reindex y Archivado WAL:
Hay que tener presente que cuando reindexamos, se rehacen muchos ficheros, con lo que
hay que llevar especial cuidado si el archivado WAL está activado, pues una reindexación
de toda la base de datos implica que se puede duplicar el tamaño de los ficheros de la base
de datos, ya que el sistema de WAL crea archivos de log para cada cambio.
Monitorizacion:
La monitorización de la actividad del servidor PostgreSQL se puede hacer con herramientas
del SO o con herramientas propias de la base de datos.
Comandos del Sistema Operativo (Linux / Unix):
La monitorización se debe fijar sobre todo en:
Uso de swap (free, vmstat, etc.)
●
Free muestra la cantidad de memoria libre y usada que tiene el sistema. Por una
parte muestra la memoria física y por otra la swap, también muestra la memoria
caché y de buffer consumida por el Kernel.
●
vmstat : Es muy similar a top ya que es un condensado de los procesos del sistema,
para que esta herramienta se vuelva dinámica se deben especificar los argumentos:
vmstat -n <numero de segundos por actualizacion >
Uso del disco (iostat, etc.)
●
iostat informa repetidamente de las estadísticas de E/S para cada disco activo del
sistema.
Monitoreo interactivo (top, ps, htop, pg_top)
ps
Usando el comando ps, podemos filtrar las filas en las que salga "postmaster:"
-- ver el proceso servidor:
$ ps -ef |grep "postmaster" | grep -v grep
-- ver los procesos backend
$ ps -ef |grep "postgres:" | grep -v grep
supongamos que tenemos una salida como la siguiente:
$ ps -ef | grep postmaster | grep –v grep
/****Ejemplo****/
/*********PROCESOS***************/
--Vamos a ver los procesos generados por el Usuario PostgreSQL:
________________________________________
2010 Manual De Administración de PostgreSql
71
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
[postgres@jp ~]$ps -Upostgres
PID TTY
TIME CMD
5668 ?
00:00:01 postmaster
5970 ?
00:00:00 postmaster
5972 ?
00:00:00 postmaster
5973 ?
00:00:00 postmaster
5974 ?
00:00:00 postmaster
5975 ?
00:00:01 postmaster
7830 ?
00:00:00 postmaster
7831 ?
00:00:00 postmaster
7850 ?
00:00:00 postmaster
8090 pts/1 00:00:01 bash
8160 pts/2 00:00:00 bash
--Tambien podemos utilizar herramientas como top, htop:
--Si queremos monitoriar nuesto server con una herramienta nativa:
[postgres@jp ~]$pg_top
last pid: 14812; load avg: 0.74, 0.43, 0.33;
up 0+02:55:34
12:07:28
4 processes: 4 sleeping
CPU states: 10.3% user, 0.0% nice, 3.0% system, 86.7% idle, 0.0% iowait
Memory: 1613M used, 2365M free, 103M buffers, 860M cached
Swap: 8000M free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
7831 postgres 25 0 54M 6964K sleep 0:00 0.00% 0.00% postgres: postgres pomavid
127.0.0.1(13687) idle
7830 postgres 24 0 53M 5600K sleep 0:00 0.00% 0.00% postgres: postgres postgres
127.0.0.1(13686) idle
14813 postgres 20 0 53M 4228K sleep 0:00 0.00% 0.00% postgres: postgres postgres
[local] idle
7850 postgres 17 0 53M 4340K sleep 0:00 0.00% 0.00% postgres: postgres pomavid
127.0.0.1(13705) idle
/***Pratica***/
--Utiliza las opciones -p y -d
--Explique su resultado.
/******Para monitorear la memoria virtual******/
[postgres@jp ~]$vmstat 2
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 2421036 105964 880432 0 0 37 36 558 826 8 2 89 2 0
0 0 0 2421036 105972 880432 0 0 0 6 1088 1249 6 1 89 4 0
--Siqueremos monitorizar la actividad de los dispositivos, particiones y sistemas en red
(NFS) del sistema,
________________________________________
2010 Manual De Administración de PostgreSql
72
Academia De Software Libre
www.codigolibre.org
__________________________________________________________
--además también muestra una media en % del uso de CPU en la máquina.
[postgres@jp ~]$iostat 2
Linux 2.6.18-194.3.1.el5PAE (jp.fcld.local)
06/05/2010
avg-cpu: %user %nice %system %iowait %steal %idle
7.60 0.03 2.04 1.72 0.00 88.61
Device:
sda
sda1
sda2
dm-0
dm-1
dm-2
dm-3
dm-4
dm-5
sdb
sdb1
dm-6
sdc
sdc1
tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
10.53
144.87
142.59 1557037 1532508
0.01
0.19
0.00
2012
4
10.52
144.65
142.59 1554721 1532504
2.12
22.06
11.36 237146 122088
0.04
0.31
0.01
3282
56
4.09
75.25
12.52 808794 134520
11.38
35.92
76.29 386026 819944
6.15
11.02
42.42 118465 455896
0.01
0.05
0.00
576
0
0.03
0.88
0.00
9474
2
0.03
0.84
0.00
9018
2
6.11
10.93
42.42 117514 455896
0.04
0.26
0.00
2814
17
0.04
0.26
0.00
2742
17
--Para ver el tamaño completo disponible en nuestro FileSystem:
[postgres@jp ~]$df -h
Filesystem
Size Used Avail Use% Mounted on
/dev/mapper/VGOracle-VLBarra
38G 1.1G 35G 3% /
/dev/mapper/VGOracle-VLOpt
141G 98G 37G 74% /opt
/dev/mapper/VGOracle-VLUsr
76G 42G 31G 58% /usr
/dev/mapper/VGOracle-VLVar
48G 1.5G 44G 4% /var
/dev/mapper/luks-e42c95a5-a0d9-47ad-a57f-53dc36e13592
142G 121G 14G 90% /home
/dev/sda1
99M 75M 20M 80% /boot
tmpfs
2.0G 0 2.0G 0% /dev/shm
/dev/sdb1
149G 149G 77M 100% /media/disk
--Si queremos ver el tamaño ocupado por el server de PostgreSQL:
[postgres@jp ~]$du -sch data/
108M data/
108M total
________________________________________
2010 Manual De Administración de PostgreSql
73