Get File

EDB
Características
SOFTWARE LIBRE ANDINO – Soluciones en Software Libre a la medida de su

Empresa
Calle Julio C. Tello Nº 184, Miraflores
Lima, Perú
Teléfono: 441-9638
1
Software Libre Andino S.A.C
Calle Julio C. Tello Nº 184
Miraflores, Lima 33 - Perú
Tel (51-1) 442-9638
Fax (51-1) 442-4442
www.softwarelibreandino.com
A continuación se detalla las principales características del producto de EDB.
Seguridad:
Autenticación del cliente
Tabla de contenidos
19,1. El archivo pg_hba.conf
19,2. Usuario mapas
19.3. Métodos de autenticación
19.3.1. Autenticación de confianza
19.3.2. Autenticación de contraseña
19.3.3. GSSAPI de autenticación
19.3.4. SSPI de autenticación
19.3.5. Autenticación Kerberos
19.3.6. Autenticación basada en Ident
19.3.7. Autenticación LDAP
19.3.8. Certificado de autenticación
19.3.9. Autenticación PAM
19,4. problemas de autenticación
Cuando una aplicación cliente se conecta al servidor de base de datos, se especifica qué base de datos
PostgreSQL nombre de usuario como quiere conectarse, de la misma manera los registros de uno en un
ordenador Unix como un usuario particular. Dentro del entorno de base de datos SQL el nombre de usuario
activo determina los privilegios de acceso a los objetos de base de datos - Por lo tanto, es esencial restringir
los usuarios de bases de datos que se pueden conectar.
Nota: La autenticación es el proceso mediante el cual el servidor de base de datos de la identidad del
cliente, y por extensión determina si la aplicación cliente (o el usuario que ejecuta la aplicación cliente) se le
permite conectarse con el nombre de usuario de base de datos que se solicitó.
PostgreSQL ofrece una serie de diferentes métodos de autenticación de cliente. El método utilizado para
autenticar una conexión de cliente particular, se pueden seleccionar sobre la base de (cliente) dirección de la
máquina, base de datos y el usuario.
Nombre de usuario de base de datos PostgreSQL son lógicamente independientes de los nombres de
usuario del sistema operativo en el que corre el servidor. Si todos los usuarios de un servidor en particular
también tienen cuentas en el servidor de la máquina, tiene sentido para asignar nombres de usuario de base
de datos que coinciden con su nombre de usuario del sistema operativo. Sin embargo, un servidor que
2
Tel (51-1) 442-9638
Fax (51-1) 442-4442
acepte conexiones remotas de base de datos podría tener muchos usuarios que no tienen cuenta de
explotación del sistema local, y en tales casos no hay necesidad de conexión entre los nombres de usuario de
base de datos y nombres de usuario del sistema operativo.
19,3. Los métodos de autenticación
19.3.1. Autenticación de confianza
Cuando se especifica la autenticación de confianza, PostgreSQL asume que cualquiera que pueda
conectarse al servidor está autorizado para acceder a la base de datos con cualquier nombre de usuario de
base de datos de manera precisa. Por supuesto, las restricciones hechas en la base de datos de usuario y las
columnas siguen siendo válidas. Este método sólo debe utilizarse cuando no hay sistema operativo a nivel de
protección adecuada en las conexiones con el servidor.
La autenticación de confianza es adecuada y muy conveniente para las conexiones locales en una sola
estación de trabajo del usuario. Por lo general, no procede por sí mismo en una máquina multiusuario. Sin
embargo, puede ser capaz de utilizar la confianza incluso en una máquina multiusuario, si se restringe el
acceso al servidor de socket de dominio Unix el archivo con permisos de sistema de archivos.
Configuración de permisos del sistema de archivo sólo funcional para conexiones socket Unix. Local
conexiones TCP / IP no están limitados por los permisos de archivos del sistema. Por lo tanto, si usted desea
utilizar sistema de permisos de archivo para la seguridad local, retire el host ... 127.0.0.1 ... línea de
pg_hba.conf, o cambiar a un método de autenticación de no confianza
Autenticación de confianza sólo es adecuado para las conexiones TCP / IP si confía en que cada usuario en
cada máquina que se le permite conectarse al servidor por las líneas que especifican pg_hba.conf confianza.
Rara vez es razonable utilizar la autentificación de confianza para cualquier red TCP / IP que no sean las de
localhost (127.0.0.1).
19.3.2. Contraseña de autenticación

Los métodos de autenticación basados en contraseña md5 y contraseña. Estos métodos funcionan de
manera similar, excepto por la forma en que la contraseña se envían a través de la conexión:
respectivamente, hash MD5-y claro en texto.
Sin embargo, md5 no se puede utilizar con la db_user_namespace función. Si la conexión está protegida por
encriptación SSL entonces la contraseña se puede utilizar con seguridad (aunque certificado de autenticación
SSL podría ser una mejor opción si uno está dependiendo en el uso de SSL).
Las contraseñas de base de datos en PostgreSQL, que están separados de contraseñas del sistema
operativo del usuario. La contraseña para cada usuario de base de datos se almacena en el catálogo del
sistema pg_authid. Las contraseñas se pueden manejar con los comandos SQL CREATE USER y ALTER
USER.
19.3.3. GSSAPI de autenticación

GSSAPI es un protocolo estándar de la industria para la autenticación segura definida en el RFC 2743.
PostgreSQL soporta GSSAPI con autenticación Kerberos de acuerdo al RFC 1964. GSSAPI permite la
autenticación automática (single sign-on) para los sistemas que lo soportan. La propia autenticación es
segura, pero los datos enviados a través de la conexión de base de datos estará en claro a menos que se
utiliza SSL.
3
Tel (51-1) 442-9638
Fax (51-1) 442-4442
19.3.4. SSPI de autenticación

SSPI es una tecnología de Windows para la autenticación segura con inicio de sesión único. PostgreSQL
usará SSPI en el modo de negociar, que utilizará Kerberos cuando sea posible y de forma automática cae en
NTLM en otros casos. Autenticación SSPI sólo funciona cuando el servidor y el cliente están ejecutando
Windows.
19.3.5. Autenticación Kerberos

Nota: Native autenticación Kerberos se considera obsoleta y debe ser utilizado sólo para compatibilidad con
versiones anteriores. Se recomienda utilizar el estándar de autenticación GSSAPI-industria en su lugar.
Kerberos es un sistema de autenticación segura adecuado estándar de la industria para la informática

distribuida sobre una red pública. Una descripción del sistema Kerberos está mucho más allá del alcance de
este documento, en toda su generalidad puede ser bastante complejo (pero potente).
PostgreSQL soporta la versión 5 de Kerberos. la compatibilidad con Kerberos tiene que estar activo cuando
PostgreSQL se construye
PostgreSQL funciona como un servicio normal de Kerberos. El nombre del principal servicio es servicename /
hostname @ dominio.
19.3.6. La autenticación basada en Ident

El método de autenticación ident de obtener el cliente del sistema operativo de nombre de usuario y utilizar
como nombre de base de datos de usuarios autorizados (con una asignación de nombre de usuario opcional).
La determinación del nombre de usuario de cliente es la crítica perspectiva de la seguridad, y funciona de
forma diferente en función de el tipo de conexión.
19.3.6.1. Ident de autenticación a través de TCP / IP

El sistema operativo con un servidor ident que escucha el puerto TCP 113 de forma predeterminada. La
funcionalidad básica de un servidor ident es responder a preguntas como "¿Qué iniciada por el usuario en la
conexión que sale de su puerto X y se conecta a mi puerto Y?". Dado que PostgreSQL sabe tanto X como Y
cuando hay una conexión física se establece, se puede interrogar al servidor ident en el host del cliente que
se conecta y, teóricamente, podría determinar el usuario del sistema operativo para cualquier conexión
determinada de esta manera. El Protocolo de identificación se describe en el RFC 1413. Prácticamente
todos los buques de tipo Unix
El inconveniente de este procedimiento es que depende de la integridad del cliente: si la máquina cliente no
es de confianza o en peligro un atacante podría ejecutar casi cualquier programa en el puerto 113 y devolver
cualquier nombre de usuario que elija. Este método de autenticación tanto, es apropiado para las redes y
cerrados en cada máquina cliente está bajo estricto control y en la base de datos y administradores de
sistemas establecer un contacto estrecho.
19.3.6.2. Ident de autenticación a través de sockets locales

En los sistemas de apoyo SO_PEERCRED solicitudes de dominios de sockets Unix (en la actualidad Linux,
FreeBSD, NetBSD, OpenBSD, BSD / OS y Solaris), la autenticación ident también se puede aplicar a
conexiones locales. En este caso, ningún riesgo de seguridad se agrega mediante la autenticación ident, de
hecho es una mejor opción para las conexiones locales de dichos sistemas.
4
Tel (51-1) 442-9638
Fax (51-1) 442-4442
En los sistemas sin SO_PEERCRED peticiones, la autenticación ident sólo está disponible para las
conexiones TCP / IP. Como solución temporal, es posible especificar la dirección 127.0.0.1 localhost y haga
las conexiones a esta dirección. Este método es confiable para la medida en que confía en el servidor ident
local.
19.3.7. Autenticación LDAP

Este método de autenticación funciona de forma parecida a la contraseña, excepto que utiliza LDAP como
método de verificación de la contraseña. LDAP se usa sólo para validar el nombre de usuario / contraseña.
Por lo tanto el usuario ya debe existir en la base de datos antes LDAP puede ser usado para la autenticación.
19.3.8. Certificado de autenticación

Este método de autenticación utiliza certificados de cliente SSL para realizar la autenticación. Por lo tanto,
sólo está disponible para conexiones SSL. Cuando se utiliza este método de autenticación, el servidor será
necesario que el cliente presente un certificado válido. No hay mensaje de contraseña se envía al cliente. El
atributo cn del certificado será comparada con el nombre de usuario de base de datos solicitada, y si
coinciden con el inicio de sesión será permitido.
19.3.9. Autenticación PAM

Este método de autenticación funciona de forma parecida a la contraseña, excepto que utiliza PAM
(Pluggable Authentication Modules) como mecanismo de autenticación. El PAM por defecto es el nombre del
servicio postgresql. PAM sólo se utiliza para validar nombre de usuario / contraseña pares. Por lo tanto el
usuario ya debe existir en la base de datos antes PAM puede ser usado para la autenticación.
Compresión de Datos
Cache Infinito
El rendimiento de base de datos suele ser gobernado por dos factores concurrentes:
● La memoria es el acceso rápido, acceso a disco es lento.
● Espacio de memoria es escasa, espacio en disco es abundante.
Postgres Plus Advanced Server intenta minimizar Entradas/Salidas al mantener los datos usados
frecuentemente en la memoria. Si el proceso se inicia, el primer servidor crea una estructura de datos en
memoria que es conocido como el caché del búfer. El buffer cache se organiza como una colección de 8K
(8192 bytes) páginas: cada página en la caché del búfer corresponde a una página en alguna tabla o índice.
El buffer cache se comparte entre todos los procesos de servicio a una base de datos dada.
Cuando se selecciona una fila de una tabla, Advanced Server lee la página que contiene la fila en la caché
de búfer compartido. Si no hay suficiente espacio libre en la memoria caché, Advanced Server desaloja a
alguna otra página de la caché. Si Advanced Server desaloja a una página que ha sido modificado, que los
datos se escribe de vuelta al disco, de lo contrario, simplemente se descarta. Índice de las páginas se
almacenan en caché en el buffer cache compartida.
La figura 1.1 muestra el flujo de datos en una sesión típica de Advanced Server:
5
Tel (51-1) 442-9638
Fax (51-1) 442-4442
Figura 1.1 - Flujo de datos
Una aplicación cliente envía una consulta al servidor de Postgres y el servidor busca en la caché del búfer
compartida para los datos requeridos. Si los datos solicitados se encuentra en la caché, el servidor
inmediatamente envía los datos al cliente. Si no, el servidor lee la página que contiene los datos en el buffer
cache compartida, desalojando a una o más páginas si es necesario. Si el servidor decide desalojar a una
página que ha sido modificado, esa página se escribe en disco.
Como puede ver, una consulta se ejecutará mucho más rápido si los datos necesarios se encuentran en la
caché del búfer compartido.
Una forma de mejorar el rendimiento es aumentar la cantidad de memoria que se puede dedicar a la caché
del búfer compartido. Sin embargo, la mayoría de ordenadores imponer un límite estricto sobre la cantidad de
RAM que se puede instalar. Para ayudar a sortear este límite, infinito caché le permite utilizar la memoria de
otros ordenadores conectados a la red.
Con caché infinito configurado correctamente, Advanced Server, destinará una parte de la memoria instalada
en cada servidor de caché como una caché de memoria secundaria. Cuando una aplicación cliente envía una
consulta al servidor, el servidor primero busca en la caché del búfer compartida para los datos requeridos, si
los datos solicitados no se encuentra en la caché, el servidor busca la página necesaria en uno de los
servidores caché.
La figura 1.2 muestra el flujo de datos en una sesión de Advanced Server con Infinito caché:
6
Tel (51-1) 442-9638
Fax (51-1) 442-4442
Figura 1.2 - El flujo de datos con el Infinito caché
Cuando una aplicación cliente envía una consulta al servidor, el servidor busca en la caché del búfer
compartida para los datos requeridos. Si los datos solicitados se encuentra en la caché, el servidor
inmediatamente envía los datos al cliente. Si no, el servidor envía una solicitud de la página en un servidor de
caché específicos, si el servidor de caché tiene una copia de la página que envía los datos al servidor y las
copias servidor de la página en la caché de búfer compartido. Si la página deseada no se encuentra en la
caché primaria (la caché del búfer compartida) o en la memoria caché secundaria (la nube de servidores
caché), Advanced Server debe leer la página desde el disco.
Como puede ver, caché infinito puede mejorar el rendimiento mediante el uso de memoria RAM de otros
ordenadores en su red a fin de evitar la lectura de datos de acceso frecuente desde el disco.
Backup y Respaldo de datos
Capítulo 24. Copia de seguridad y restauración
Tabla de contenidos
24,1. SQL Dump
24.1.1. Restaurando el dump
24.1.2. Uso de pg_dumpall
24.1.3. Manipulación de grandes bases de datos
24,2. File Level Backup System
24,3. Continúa Archivo y Point-In-Tiempo de recuperación (PITR)
7
Tel (51-1) 442-9638
Fax (51-1) 442-4442
24.3.1. Configuración de archivo WAL
24.3.2. Realización de una copia de seguridad de la Base
24.3.3. La recuperación mediante una copia de seguridad continúa
24.3.4. Líneas de tiempo
24,4 Servidores Hot Standby para alta disponibilidad (Warm Standby Servers for High Availability)
24,5. migración entre versiones
Al igual que con todo lo que contiene valiosos datos, bases de datos PostgreSQL debe ser respaldada
regularmente. Si bien el procedimiento es esencialmente simple, es importante tener una comprensión clara
de las técnicas y supuestos subyacentes.
Hay tres enfoques diferentes, fundamentalmente, a la copia de seguridad de datos PostgreSQL:
• SQL dump
• Nivel de Seguridad de Sistema de archivos
• Archivo continuo
24,1. SQL Dump
dbname> pg_dump archivosalida

pg_dump es un asiduo cliente de la aplicación de PostgreSQL (aunque particularmente uno inteligente).
Esto significa que usted puede hacer este procedimiento de copia de seguridad de cualquier host remoto que
tenga acceso a la base de datos. Pero recuerde que pg_dump no opera con permisos especiales. En
particular, debe tener acceso de lectura a todas las tablas que desea una copia de seguridad, por lo que en la
práctica casi siempre tiene que ejecutarlo como superusuario base de datos.
Para especificar qué servidor de base de datos deben comunicarse con pg_dump, utilice las opciones de
línea de comandos-h host-p puerto. El equipo por defecto es el Localhost o lo que su variable de entorno
PGHOST especifica. Del mismo modo, el puerto por defecto es indicado por el medio ambiente PGPORT
variable o, en su defecto, por la compilación de forma predeterminada. (Convenientemente, el servidor
normalmente tiene el mismo compilado en forma predeterminada.)
Al igual que cualquier otra aplicación cliente, PostgreSQL pg_dump toma de forma predeterminada en
contacto con el nombre de usuario de base de datos que es igual al sistema de nombres de usuario de
operación actual. Para anular esto es necesario especificar la opción -U o establecer el PGUSER variable de
entorno. Recuerde que las conexiones pg_dump están sujetas a los mecanismos de autenticación de cliente
normal
24.1.1. Restaurando el dump
Los archivos de texto creados por pg_dump están concebidos para ser leídos en el programa psql.
dbname <psql INFILE
Donde INFILE es lo que se utiliza como archivo de salida para el comando pg_dump. La base de datos
dbname no se creará por este comando, por lo que debe crear a sí mismo de template0 antes de ejecutar
8
Tel (51-1) 442-9638
Fax (51-1) 442-4442
(por ejemplo, psql, con createdb-T template0 dbname). Apoya opciones psql similar a pg_dump 's para
especificar el servidor de base de datos para conectarse y el nombre de usuario para su uso.
Antes de restaurar un SQL dump, todos los usuarios que poseen objetos o que se le ha concedido los
permisos en los objetos dumping de la base de datos ya debe existir. Si no lo hacen, entonces, la
restauración no volver a crear los objetos con el original de propiedad y / o permisos.
De forma predeterminada, la secuencia de comandos psql seguirá ejecutando después de un error de SQL
se encuentra. Es posible que desee utilizar el siguiente comando en la parte superior de la secuencia de
comandos para modificar esta actitud y la salida psql con un estado de salida de 3 si un error SQL:
pg_dump Use 's formato de dump personalizada. Si PostgreSQL fue construido en un sistema con la
biblioteca de compresión zlib instalado, el formato de volcado personalizada comprimir los datos en que se
escribe en el archivo de salida. Esto producirá tamaños de archivo de volcado similar a gzip usando, pero
tiene la ventaja añadida de que las tablas se pueden restaurar de forma selectiva. El siguiente comando
vuelca una base de datos utilizando el formato de volcado personalizada:
-Fc pg_dump dbname nombre de archivo>
Un formato de volcado personalizada no es un script para psql, sino que debe ser restaurada con pg_restore,
por ejemplo:
pg_restore dbname-d nombre de archivo
Ver la pg_dump y pg_restore páginas de referencia para más detalles.
Para las grandes bases de datos muy, puede ser necesario combinar la ruptura con uno de los otros dos
enfoques.
24,2. Sistema de archivos de copia de seguridad de nivel
Una estrategia de copia de seguridad alternativa es copiar directamente los archivos que utiliza PostgreSQL
para almacenar los datos en la base de datos
Puede utilizar cualquier método que prefiera para hacer copias de seguridad habituales del sistema de
archivos, por ejemplo:
tar-cf backup.tar / usr / local / pgsql / data
1. El servidor de base de datos debe ser apagado con el fin de obtener una copia de seguridad útil. -A
mitad de camino de medidas como rechazar la totalidad de las conexiones no funciona (en parte
debido y herramientas similares de alquitrán no tome una instantánea atómica de la situación del sis-
tema de archivos, sino también por el almacenamiento en búfer interno en el servidor). No hace falta
decir que también es necesario apagar el servidor antes de restaurar los datos.
24,3. Archivado continua y Point-In-Tiempo de recuperación (PITR)
En todo momento, PostgreSQL mantiene una escritura anticipada de la bitácora (WAL) en el pg_xlog /
subdirectorio del directorio de datos de clúster. El registro describe cada cambio realizado a los archivos de
datos de la base de datos. Este registro existe principalmente para propósitos de seguridad de una colisión:
si el sistema se bloquea, la base de datos se puede restaurar a la coherencia de "reproducir" las entradas del
registro realizados desde el último punto de control. Sin embargo, la existencia del registro hace posible el
uso de una tercera estrategia de copias de seguridad de bases de datos: podemos combinar un sistema de
nivel de copia de seguridad de archivos con copias de seguridad de los archivos WAL. Si la recuperación es
necesaria, restaurar la copia de seguridad y, a continuación de la reproducción de copia de seguridad de
9
Tel (51-1) 442-9638
Fax (51-1) 442-4442
archivos WAL traer la copia de seguridad hasta el momento actual. Este enfoque es más complejo de
administrar que uno de los enfoques anteriores, pero tiene algunas ventajas importantes:
24.3.1. Configuración de archivado WAL

Un sistema ejecutando PostgreSQL produce una larga secuencia indefinida de los registros de WAL. El
sistema se divide físicamente en los archivos de esta secuencia de segmentos WAL, que normalmente son
de 16 MB cada uno (aunque el tamaño de segmento puede ser alterado en la construcción de PostgreSQL).
El segmento de los archivos tienen nombres numéricos que reflejan su posición en la secuencia de WAL
abstracto. Cuando no utilice el archivo WAL, el sistema normalmente sólo crea un segmento de unos pocos
archivos y luego "recicla" les cambia el nombre no se necesitan archivos segmento más largo a los números
de segmento superior. Se supone que un archivo de segmentos cuyo contenido preceden el puesto de
control-antes-pasado ya no es de interés y pueden ser reciclados.
24.3.2. Hacer una copia de seguridad de la Base

El procedimiento para hacer una copia de seguridad de base es relativamente simple:
1. Asegúrese de que el archivado WAL está habilitado y en funcionamiento.

2. Conéctese a la base de datos como un super-usuario, y el comando:
pg_start_backup SELECT ('label');
Donde etiqueta cualquier cadena que desee utilizar para identificar de manera única esta operación
de respaldo. (Una buena práctica es utilizar la ruta completa en la que la intención de poner el
archivo de copia de seguridad). pg_start_backup crea un archivo de etiquetas de seguridad, llamado
backup_label, en el directorio del clúster con la información sobre la copia de seguridad.
3. Realizar la copia de seguridad, utilizando cualquier sistema de archivos de copia de seguridad-her-

ramienta conveniente.
4. Una vez más conectarse a la base de datos como un super-usuario, y el comando:

pg_stop_backup SELECT ();
Esto termina el modo de copia de seguridad y realiza un interruptor automático para el segmento de
WAL siguiente. La razón para el cambio es necesario para que el segmento de WAL último archivo
escrito durante el intervalo de copia de seguridad estará listo para archivar.
5. Una vez que el segmento de WAL archivos utilizados para la copia de seguridad se archivan, ya es-
tá resuelto. El archivo identificado por pg_stop_backup «resultado s es el último segmento que se
requiere para formar un conjunto completo de archivos de copia de seguridad.
24.3.3. Recuperación usando un archivo de copia de seguridad continúa

1. Detenga el servidor, si se está ejecutando.
2. Si usted tiene el espacio para hacerlo, copie el grupo en su totalidad y cualquier directorio de datos
de tablas en una ubicación temporal en caso que los necesite más tarde.
3. Limpie todos los archivos existentes y subdirectorios bajo el directorio de datos de clúster y en los
directorios raíz de una de tablas que está utilizando.
4. Restaurar la base de datos los archivos de su copia de seguridad de base. Tenga cuidado de que
se restauran con el derecho de propiedad (el sistema de utilización de bases de datos, no como
root!) Y con los permisos adecuados. Si está utilizando espacios de tablas, debe comprobar que los
enlaces simbólicos en pg_tblspc / se restauraron correctamente.
10
Tel (51-1) 442-9638
Fax (51-1) 442-4442
5. Quite todos los archivos presentes en pg_xlog /; éstos proceden de un vertedero de copia de segur-
idad y, por tanto, probablemente más que obsoleto actual. Si no pg_xlog archivo / en absoluto, a
continuación, volver a crearlo, teniendo cuidado para asegurarse de que vuelva a establecerse como
un enlace simbólico si lo hubiese creado de esa manera antes.
6. Si había desarchivado segmento de archivos WAL que guardó en el paso 2, copiarlos en pg_xlog /.
(Es mejor para copiarlos, moverlos, no, de modo que usted todavía tiene los archivos sin modificar si
se produce un problema y hay que empezar de nuevo.)
7. Crear un comando de recuperación recovery.conf archivo en el directorio de datos del clúster . Us-
ted también puede modificar temporalmente pg_hba.conf para evitar que usuarios comunes y corri-
entes de conexión hasta que esté seguro de la recuperación ha funcionado.
8. Inicie el servidor. El servidor se pone en modo de recuperación y proceda a leer el archivado WAL
archivos que necesita. Si la recuperación se interrumpió debido a un error externo, el servidor sim-
plemente se puede reiniciar y continuará la recuperación. Una vez finalizado el proceso de recuper-
ación, el servidor cambiará el nombre a recovery.conf recovery.done (para evitar que accidental-
mente volver a entrar en modo de recuperación en caso de un accidente después) y luego la base
de datos las operaciones normales de comenzar.
9. Inspeccione el contenido de la base de datos para asegurarse de que se haya recuperado a donde
usted quiere estar. Si no, vuelva al paso 1. Si todo va bien la cosa, en sus usuarios mediante la res-
tauración de pg_hba.conf a la normalidad.
24.3.3.1. Recuperación Configuración

Estos valores sólo se pueden hacer en el archivo recovery.conf, y se aplican únicamente para la duración de
la recuperación. Deben ponerse a cero para su posterior valorización que desea realizar. No se pueden
cambiar una vez que la recuperación ha comenzado.
24.3.4. Líneas de tiempo

La capacidad de restaurar la base de datos a un punto anterior en el tiempo. Tal vez se le cayó una tabla
crítica a las 5:15 pm en la noche del martes, pero no se dio cuenta de su error hasta el mediodía del
miércoles, saque la copia de seguridad, restaurar al punto en el tiempo 5: 14 hs Martes por la noche, y están
en marcha y funcionando. EDB soporta estas funcionalidades.
24,4. Servidores Hot Standby para alta disponibilidad
Archivo continuo puede ser usado para crear una alta disponibilidad (HA) de configuración del clúster con
uno o más servidores de reserva listos para asumir las operaciones si el servidor principal falla. Esta
capacidad es ampliamente conocida como hot wait
El servidor en espera de trabajo y primaria juntos para proporcionar esta capacidad, aunque los servidores
están sólo débilmente acoplados. El servidor principal funciona en modo de archivo continuo, mientras que
cada servidor de reserva opera en modo de recuperación continua para la lectura de los archivos WAL.
24.4.5. Actualización incremental de copias de seguridad
Este concepto se conoce generalmente como copias de seguridad actualizadas de forma incremental, la
acumulación de registro de cambios, o más simplemente, la acumulación de cambio. EDB soporta esta
funcionalidad.
11
Tel (51-1) 442-9638
Fax (51-1) 442-4442
Auditoria de Base de Datos (Database Auditing)

2.2 Base de datos de auditoria
Además Postgres Advanced Server proporciona la capacidad de producir informes de auditoria. de auditoria
de base de datos permiten a los administradores de bases de datos, administradores de seguridad, auditores,
y los operadores realizar un seguimiento y analizar las actividades de base de datos. Estas actividades
incluyen el acceso y la utilización de la base de datos junto con la creación de datos, cambiar o suprimir. El
sistema de auditoria se basa en los parámetros de configuración en el archivo postgresql.conf.
Uso de la DBA Management Server, estos informes de auditoria se puede generar y ver, sin embargo, la
configuración de auditoria en el archivo postgresql.conf primero debe estar habilitado.
2.2.1 Parámetros de configuración de auditoria

La siguiente es una descripción de los parámetros de configuración que la auditoria de base de datos de
control. Estos parámetros se encuentran en el archivo postgresql.conf.
edb_audit
Activa o desactiva la auditoría de base de datos. El xml valores o csv se habilita la auditoría de
base de datos. Estos valores representan el formato de archivo en el que se va a auditar la
información capturada. Ninguna de ellas podrá desactivar la base de datos de auditoría y es la
opción por defecto. Esta opción sólo puede activarse al empezar el servidor o en el archivo
postgresql.conf.
edb_audit_directory
Especifica el directorio donde los archivos de registro se crearán. La ruta del directorio puede
ser relativa o absoluta a la carpeta de datos. Esta opción sólo puede activarse al empezar el
servidor o en el archivo de configuración postgresql.conf.
edb_audit_filename
Especifica el nombre de archivo del expediente de auditoría donde se almacena la información

de auditoría. El nombre de archivo por defecto será de auditoría-% Y-% m-% d_% H% M% S.
Las secuencias de escape, Y% m% etc, serán reemplazados por los valores actuales adecuado
en función de la fecha y hora del sistema. Esta opción sólo puede activarse al empezar el
servidor o en el archivo de configuración postgresql.conf.
edb_audit_rotation_day
Especifica el día de la semana en que para hacer girar los expedientes de auditoría. Los valores
válidos son el sol, L, M, X, J, V, S, todos y ninguno. Para desactivar la rotación, establezca el
valor a ninguno. Para girar el archivo de todos los días, establezca el valor a cada
edb_audit_rotation_day. Para girar el archivo en un día específico de la semana, establezca el
valor en el día de la semana deseado. Ninguno es el valor por defecto. Esta opción sólo puede
activarse al empezar el servidor o en el archivo de configuración postgresql.conf.
edb_audit_rotation_size
Especifica un umbral de tamaño de archivo en megabytes cuando la rotación de archivos se

verán obligados a ocurrir. El valor predeterminado es 0 MB. Si el parámetro se comenta o se
establece en 0, la rotación del archivo en una base de tamaño no se producirá. Esta opción sólo
puede activarse al empezar el servidor o en el archivo de configuración postgresql.conf.
12
Tel (51-1) 442-9638
Fax (51-1) 442-4442
edb_audit_rotation_seconds
Especifica el tiempo de rotación en segundos cuando un nuevo archivo de registro debe ser
creado. Para desactivar esta característica, establezca este parámetro a 0. Esta opción sólo
puede activarse al empezar el servidor o en el archivo de configuración postgresql.conf.
edb_audit_connect
Permite la auditoría de intentos de conexión de base de datos por los usuarios. Para
deshabilitar la auditoría de todos los intentos de conexión, sistema edb_audit_connect a ninguno.
Para auditar todos los intentos de conexión fallidos, establezca el valor a no. Para auditar todos
los intentos de conexión, establezca el valor para todos. Esta opción sólo puede activarse al
empezar el servidor o en el archivo de configuración postgresql.conf.
edb_audit_disconnect
Permite la auditoría de base de datos de desconexiones de los usuarios conectados. Para

habilitar la auditoría de las desconexiones, establezca el valor para todos. Para deshabilitar,
establezca el valor a ninguno. Esta opción sólo puede activarse al empezar el servidor o en el
archivo de configuración postgresql.conf.
edb_audit_statement
Este parámetro de configuración se utiliza para especificar la auditoría de las distintas

categorías de sentencias SQL. Para auditar los estados resultantes en el error, establezca el
valor del parámetro de error. Para auditar los estados DDL como CREATE TABLE, ALTER
TABLE, etc, establezca el valor del parámetro ddl. Modificación comandos como INSERT,
UPDATE, DELETE, etc, pueden ser controladas mediante el establecimiento de
edb_audit_statement de LMD. Establecer el valor a todos ejercer el control de todas las
declaraciones, mientras que ninguno desactiva esta función. Esta opción sólo puede activarse al
empezar el servidor o en el archivo de configuración postgresql.conf.
Cada línea de auditoría se precede con un prefijo que no se puede cambiar. El prefijo se compone del
nombre del usuario, nombre de base de datos, host remoto y puerto, identificador de proceso, el identificador
de sesión, ID de transacción, fecha y hora, y tipo de evento.
El siguiente es el CVS y XML de salida cuando la auditoría está habilitada:
CSV archivo de registro de auditoría
,,, 1452,, ,2008-03-13 12:40:02, puesta en marcha, "Auditoría: sistema de base de datos está listo"
EnterpriseDB, mgmtsvr, 127.0.0.1 (1266), 1620,47 d9595b.654 ,0,2008-03-13 12:42:03, conectar ":
conexión autorizada AUDIT: base de datos de usuario = = EnterpriseDB mgmtsvr"
EnterpriseDB, mgmtsvr, 127.0.0.1 (1266), 1620,47 d9595b.654 ,1588,2008-03-13 12:42:08, ddl,

"Auditoría: Estado: Mesa HILOSEQUENCES caída
"
EnterpriseDB, mgmtsvr, 127.0.0.1 (1266), 1620,47 d9595b.654 ,1590,2008-03-13 12:42:09, ddl,

"Auditoría: Estado: crear HILOSEQUENCES tabla (
SEQUENCENAME varchar (50) no nulo,
HIGHVALUES entero no nulo,
restricción de clave principal hilo_pk (SEQUENCENAME)
13
Tel (51-1) 442-9638
Fax (51-1) 442-4442
"
EnterpriseDB, edb, 127.0.0.1 (1269), 904,47 d9598d.388 ,0,2008-03-13 12:42:53, conectar ": conexión
autorizada AUDIT: user = base de datos de EnterpriseDB edb ="
EnterpriseDB, edb, 127.0.0.1 (1269), 904,47 d9598d.388 ,1618,2008-03-13 12:43:02, ddl, "Auditoría:
Estado: tabla de prueba CREATE (f1 entero);"
EnterpriseDB, edb, 127.0.0.1 (1269), 904,47 d9598d.388 ,1620,2008-03-13 12:43:02, sentencia SQL,
"Auditoría: Estado: * testx DE SELECT;"
XML archivo de registro de auditoría
process_id="2516" <Event time="2008-03-13 13:22:42 "type="startup">
<message> AUDIT: sistema de base de datos es <listo / message>
</ Evento>
evento de usuario <= "EnterpriseDB" base de datos = "mgmtsvr" remote_host_and_port = "127.0.0.1

(1281)"
process_id = "352" session_id = "47d96338.160" transacción = "0"
tiempo = "13/03/2008 13:24:08" type = "conectar">
<message> AUDIT: conexión autorizada: usuario = EnterpriseDB
base de datos = mgmtsvr </ message>
</ Evento>
2.2.2 Auditoria Ver Registros

En el DBA Management Server, seleccione la opción Ver de Auditoria en el menú Registros de
seguimiento para ver información de auditoria.
14
Tel (51-1) 442-9638
Fax (51-1) 442-4442
Ver Figura 21 Registros de Auditoria
En el Informe de Ver Auditoria, las opciones de auditoria seleccionados en el archivo postgresql.conf se

muestran en la mano izquierda de la pantalla. Las casillas de verificación en el centro de la pantalla para
facilitar la selección posterior de los tipos de declaraciones que se muestra en el informe.
Ver Figura 22 Auditoria
Los estados auditados fueron generados por el siguiente período de sesiones en PSQL.
15
Tel (51-1) 442-9638
Fax (51-1) 442-4442
edb = # CREATE tabla de prueba (f1 entero);
CREATE TABLE
edb = # INSERT INTO prueba VALUES (100);
INSERTAR 0 1
edb = # SELECT * FROM testx;
ERROR: relation "testx" no existe
edb = # DROP TABLE prueba;
DROP TABLE
Tenga en cuenta que el comando INSERT éxito no aparece en la lista de auditoría desde
edb_audit_statement no se ha establecido para incluir comandos éxito LMD.
Escalabilidad (scalability)
2,3 de alta disponibilidad y balanceo de carga

Servidores de bases de datos pueden trabajar juntos para permitir a un segundo servidor hacerse cargo
rápidamente si el servidor principal falla (alta disponibilidad), o para permitir que varios ordenadores servir a
los mismos datos (de equilibrio de carga). Idealmente, los servidores de base de datos podrían trabajar juntos
sin problemas. Los servidores de base de datos de sólo lectura se pueden combinar con relativa facilidad,
también. Desafortunadamente, la mayoría de servidores de bases de datos tienen una lectura / escritura de
la mezcla de las solicitudes, y de lectura / escritura servidores son mucho más difíciles de combinar. Esto se
debe a que aunque los datos de sólo lectura, hay que colocar en cada servidor de una sola vez, una escritura
en cualquier servidor tiene que ser propagada a todos los servidores para que los futuros requerimientos de
lectura a los servidores devuelvan resultados consistentes.
2.3.1 conmutación por error de disco compartido

Conmutación por error de disco compartido evita la sobrecarga de sincronización por tener sólo una copia de
la base de datos. Se utiliza una matriz de disco único que es compartido por varios servidores. Si el servidor
de base de datos principal falla, el servidor de reserva es capaz de montar e iniciar la base de datos como si
se recuperaba de un accidente de base de datos. Esto permite la conmutación por error rápida sin pérdida de
datos.
Funcionalidad de hardware compartido es común en los dispositivos de almacenamiento en red. Usando un

sistema de archivos de red también es posible, aunque se debe tener cuidado que el sistema de archivos
tenga pleno comportamiento POSIX. Una limitación importante de este método es que si la matriz de disco
compartido falla o se daña, los servidores primarios y de reserva son funcionales. Otra cuestión es que el
servidor de reserva no debe acceder al almacenamiento compartido, mientras el servidor principal está en
ejecución.
2.3.2 Uso de espera caliente Point-In-Tiempo de recuperación

Un servidor espera caliente (vea la sección llamada "Warm Standby servidores de alta disponibilidad" en el
capítulo llamado "Copia de seguridad y restauración" en la documentación del Servidor Avanzado) pueden
mantenerse actualizados mediante la lectura de una corriente de fichero de registro (WAL) registros. Si el
16
Tel (51-1) 442-9638
Fax (51-1) 442-4442
servidor principal falla, el modo de hot wait contiene la casi totalidad de los datos del servidor principal, y se
puede obtener rápidamente el servidor maestro la nueva base de datos. Esta es asíncrona y sólo se puede
hacer para el servidor de base de datos.
2.3.3 amo-esclavo de replicación

Un esclavo de replicación setup-maestro envía todas las consultas de modificación de datos en el servidor
maestro. El servidor maestro envía de forma asincrónica los cambios de datos en el servidor esclavo.
Consultas de esclavo puede responder de sólo lectura mientras el servidor maestro está en ejecución. El
servidor esclavo es ideal para las consultas de almacén de datos.
2.3.4 Declaración de replicación basado en Middleware

Con base replicación de middleware de instrucción, un programa intercepta todas las consultas SQL y lo
envía a uno o todos los servidores. Cada servidor funciona de manera independiente. Leer-escribir consultas
se envían a todos los servidores, mientras que las consultas de sólo lectura se pueden enviar a un solo
servidor, permitiendo la carga de trabajo leer a distribuir.
2.3.5 replicación síncrona Multi-Master

En varios maestros de replicación sincrónica, cada servidor puede aceptar las solicitudes de escritura, y los
datos modificados se transmite desde el servidor original para todos los servidores de otros antes de cada
transacción. De hecho, el rendimiento de escritura es a menudo peor que la de un único servidor. Leer
solicitudes se pueden enviar a cualquier servidor. Algunas implementaciones de uso compartido de disco
para reducir la sobrecarga de la comunicación. replicación síncrona de varios maestros es el mejor para las
cargas de trabajo sobre todo leer, aunque su gran ventaja es que cualquier servidor puede aceptar las
solicitudes de escritura - no hay necesidad de particionar las cargas de trabajo entre servidores maestro y
esclavo, y debido a los cambios de datos se envían desde un servidor a otro , no hay problema con las
funciones no-determinista como el random ().
2.3.6 replicación asíncrona Multi-Master

Para los servidores que no están regularmente en contacto, como ordenadores portátiles o servidores
remotos, de mantenimiento de datos consistentes entre los servidores es un reto. Uso de varios maestros de
replicación asincrónica, cada servidor funciona de forma independiente, y periódicamente se comunica con
los demás servidores para identificar las operaciones en conflicto. Los conflictos pueden ser resueltos por los
usuarios o de las normas de resolución de conflictos.
2.3.7 Datos de creación de particiones

Particionamiento de datos divide las tablas en conjuntos de datos. Cada sistema puede ser modificado por
un solo servidor. Por ejemplo, los datos pueden ser divididas por las oficinas, por ejemplo, EE.UU. y oficinas
EnterpriseDB Pakistán, con un servidor en cada oficina. Si las consultas combinando los datos de EE.UU. y
Pakistán son necesarias, una aplicación puede consultar ambos servidores, o maestro / esclavo de
replicación se puede utilizar para guardar una copia de sólo lectura de los datos de la oficina del otro en cada
servidor.
2.3.8 paralelo varios servidores de consultas de ejecución

Muchas de las soluciones por encima de permitir a los servidores múltiples manejar varias consultas, permitir
que una sola consulta a usar varios servidores para completar más rápido. Esta solución permite a los
servidores múltiples para trabajar simultáneamente en una única consulta. Esto se logra generalmente
mediante el fraccionamiento de los datos entre los servidores y hacer que cada servidor de ejecutar su parte
de la consulta y devolver los resultados a un servidor central donde se combinan y se devuelve al usuario.
Pgpool-II tiene esta capacidad.
17
Tel (51-1) 442-9638
Fax (51-1) 442-4442
18

Get File

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Get File

Transféré par

Droits d'auteur :

Formats disponibles

EDB

SOFTWARE LIBRE ANDINO – Soluciones en Software Libre a la medida de su

Calle Julio C. Tello Nº 184, Miraflores

A continuación se detalla las principales características del producto de EDB.

19,1. El archivo pg_hba.conf

19,2. Usuario mapas

19.3. Métodos de autenticación

19.3.1. Autenticación de confianza

19.3.2. Autenticación de contraseña

19.3.3. GSSAPI de autenticación

19.3.4. SSPI de autenticación

19.3.5. Autenticación Kerberos

19.3.6. Autenticación basada en Ident

19.3.7. Autenticación LDAP

19.3.8. Certificado de autenticación

19.3.9. Autenticación PAM

19,4. problemas de autenticación

19,3. Los métodos de autenticación

19.3.1. Autenticación de confianza

19.3.2. Contraseña de autenticación

19.3.3. GSSAPI de autenticación

19.3.4. SSPI de autenticación

19.3.5. Autenticación Kerberos

Kerberos es un sistema de autenticación segura adecuado estándar de la industria para la informática

19.3.6. La autenticación basada en Ident

19.3.6.1. Ident de autenticación a través de TCP / IP

19.3.6.2. Ident de autenticación a través de sockets locales

19.3.7. Autenticación LDAP

19.3.8. Certificado de autenticación

19.3.9. Autenticación PAM

● La memoria es el acceso rápido, acceso a disco es lento.

● Espacio de memoria es escasa, espacio en disco es abundante.

Figura 1.1 - Flujo de datos

Figura 1.2 - El flujo de datos con el Infinito caché

Backup y Respaldo de datos

Capítulo 24. Copia de seguridad y restauración

24,1. SQL Dump

24.1.1. Restaurando el dump

24.1.2. Uso de pg_dumpall

24.1.3. Manipulación de grandes bases de datos

24,2. File Level Backup System

24,3. Continúa Archivo y Point-In-Tiempo de recuperación (PITR)

24.3.1. Configuración de archivo WAL

24.3.2. Realización de una copia de seguridad de la Base

24.3.3. La recuperación mediante una copia de seguridad continúa

24.3.4. Líneas de tiempo

24,5. migración entre versiones

Hay tres enfoques diferentes, fundamentalmente, a la copia de seguridad de datos PostgreSQL:

24,1. SQL Dump

dbname> pg_dump archivosalida

24.1.1. Restaurando el dump

24,2. Sistema de archivos de copia de seguridad de nivel

24,3. Archivado continua y Point-In-Tiempo de recuperación (PITR)

24.3.1. Configuración de archivado WAL

24.3.2. Hacer una copia de seguridad de la Base

1. Asegúrese de que el archivado WAL está habilitado y en funcionamiento.

3. Realizar la copia de seguridad, utilizando cualquier sistema de archivos de copia de seguridad-her-

4. Una vez más conectarse a la base de datos como un super-usuario, y el comando:

24.3.3. Recuperación usando un archivo de copia de seguridad continúa

24.3.3.1. Recuperación Configuración

24.3.4. Líneas de tiempo

24,4. Servidores Hot Standby para alta disponibilidad

24.4.5. Actualización incremental de copias de seguridad