Juan, en base a todo lo que has planteado y te han contestado me parece
lo siguiente:
1) ya te dijeron por ahi que el camino que quieres tomar para lograr tu
objetivo es futil, estoy de acuerdo.
2) revisa la permisologia de la base de datos y como ya te inidacron
llevala al minimo necesario para que todos y cada uno de los usuarios
(Aplicaciones y personas ) puedan hacer su trabajo. ten presente que la
permisología siempre debe ser individual y para mejor administración
basada en roles.
3) si persisten en tu objetivo entonces te recomiendo lo siguiente, crea
unos trigers que chequen la ejecucion de las sentencias que necesitar
auditar y/o negar sobre las tablas que requieres vigilar, y asi podras
llevar registro de quien ejecuta estas sentencias. Esto te servira con
los DML con los DDL tendrias que revisar mas a fondo.
Gracias
Mauricio Rivas
Consultor
Proyecto Optimización, Migración y Soporte Interno de Base de Datos Oracle a Tecnologías Libres (OMS BD ORCL - TIL)
Gerencia de Programa Soluciones de TI
Gerencia General de Proyectos Mayores
Gerencia General de Tecnología y Operaciones
Tel:
Cel: +58-412-392-7447
Email: mriva...@cantv.com.ve
El 26/06/2012 01:39 p.m., Juan escribió:
Alvaro
entre lineas
2012/6/26 Alvaro Herrera <alvhe...@alvh.no-ip.org
<mailto:alvhe...@alvh.no-ip.org>>
Excerpts from Juan's message of mar jun 26 13:16:18 -0400 2012:
> 2012/6/26 Alvaro Herrera <alvhe...@alvh.no-ip.org
<mailto:alvhe...@alvh.no-ip.org>>
> > PITR es sigla de "point in time recovery", que en concreto
significa que
> > uno puede recuperar hasta un determinado punto en el tiempo; o
sea que
> > si tienes los WAL desde el pasado hasta más allá del momento
en que se
> > hizo el DROP o el TRUNCATE, puedes detener el sistema y
decirle que
> > empieze a recuperar hasta justo antes del DROP o TRUNCATE.
> >
>
> Como hago eso?
> Si ya existe, donde lo leo? porque no me queda claro como,
entonces estuve
> pensando como hacerlo yo mismo.
> Yo suponia que el segundo postgres en stand by todo el tiempo
recibía los
> wal
> del "master db" ,
En el escenario en que yo estoy hablando, no hay un secundario,
sino un
área de archivado donde los logs se guardan. Está documentado acá:
24.3.3. Recovering Using a Continuous Archive Backup
...
If you want to recover to some previous point in time (say, right
before
the junior DBA dropped your main transaction table), just specify the
required stopping point in recovery.conf. You can specify the stop
point, known as the "recovery target", either by date/time, named
restore point or by completion of a specific transaction ID.
http://www.postgresql.org/docs/9.1/static/continuous-archiving.html
Creo que si el problema del cual te quieres proteger es alguien que
comete un error, la solución es no dejar que nadie se meta al servidor
de producción, sólo las aplicaciones; que las aplicaciones tengan
permisos mínimos, de manera que puedan hacer poco daño en caso de que
haya algún bug; y usar mecanismos seguros de manera que no haya
hoyos de
inyección de SQL, para evitar los maliciosos (que nunca faltan).
Tratar de parchar el sistema para impedir que alguien que se cuele
en tu
servidor haga daño me parece esfuerzo gastado en la dirección errónea.
Por ej. digamos que proteges el DROP TABLE y el TRUNCATE pero alguien
hace un DELETE de toda la tabla ... O alguien crea un trigger ON
INSERT
que invoca TRUNCATE.
> entonces lo que necesitaba era "negarle" los logs que
> tienen
> el DROP o TRUNCATE etc,, pero parece por lo que decis que no es asi.
Bueno, no. No existe un mecanismo para decirle a un standby que se
detenga. Tampoco existe (que yo sepa) un mecanismo para inspeccionar
cada registro antes de ejecutarlo, que hipotéticamente serviría para
detener la recuperación cuando encuentre algo que no le guste (por ej.
el DROP o TRUNCATE que señalas).
Alvaro, lei el PITR pero pensé que era en caliente o se otra base de
datos esta
leyendo los logs/WALLS que le tira la base que esta procesando
transacciones
esta es la base que llamo en stand by , pero parece que no, que solo
archivo los logs
y luego los aplico según corresponde.
Para aplicar el tema de detener o detectar estas sentencias de
DROP/TRUNCATE etc
pensé que leyendo el log de la base maestra podría detectar cuando
llegan estas instrucciones
frenar la copia y la db en stand by no debería tener estas
instrucciones dañinas.
salu2
jmdc
--
Álvaro Herrera <alvhe...@alvh.no-ip.org
<mailto:alvhe...@alvh.no-ip.org>>
