Gracias Mauricio. jmdc 2012/6/27 Mauricio Rafael Rivas Martinez <mriva...@cantv.com.ve>
> 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> > >> >> Excerpts from Juan's message of mar jun 26 13:16:18 -0400 2012: >> >> > 2012/6/26 Alvaro Herrera <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> >> > > > >