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> >
