Excerpts from Juan's message of mar jun 26 13:16:18 -0400 2012: > 2012/6/26 Alvaro Herrera <[email protected]>
> > 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). -- Álvaro Herrera <[email protected]> - Enviado a la lista de correo pgsql-es-ayuda ([email protected]) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
