Miguel Rodríguez Penabad escribió:
Muchas gracias a todos por responder. Al final restauramos el backup
del día anterior, porque examinar los datos de los WAL era más costoso
que volver a introducir los datos.
Ahora me queda buscarme algún buen libro de administración de
postgres, o revisar a fondo la documentación de postgres.
Se admiten sugerencias...
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html
Bueno, el consejo que te podemos dar todos es que elabores un detallado
Plan de Mitigación de Riesgos primeramente, y a partir de ahí, entonces
haces un Plan de Redundancia de tus datos, que se ajuste a tus posibles,
comentando cómo vas a resolver cada problema.
Esto es muy provechoso, más todavía cuando estás trabajando con empresas
que lo quieren todo al detalle; por lo que se le da una mayor validez a
tu trabajo.
El 2do consejo es que te estudies algunas de las herramientas que se
usan para esto (dígase Slony-1, PgPool-II, Skytools + PgBouncer,
PyReplica, Bucardo) y valores cuál es tu mejor solución en dependencia
de tu sistema.
Puntos a analizar:
- ¿Necesitas un sistema Maestro-Esclavo o MultiMaestro?
De aquí valoras usar Slony-I o Londiste (Skytools) para un esquema
Maestro-Esclavo, o Bucardo en caso de MultiMaestro.
Nota: Con Slony-I se puede simular un mecanismo de replicación
MultiMaestro con la configuración del set de replicación en un
determinado modo.
- ¿La cantidad de usuarios que se conectan a tu aplicación es
relativamente grande?
De acá valoras si necesitas un pool de conexiones, lo cual lo puedes
lograr con PgPool-II o PgBouncer.
- ¿Las bases de datos de tu aplicación son relativamente grandes? (En el
orden de los GB o de los Tb)
De acá puedes valorar cuál será tu mecanismo de almacenamiento de los
datos. Los expertos recomiendan para el directorio de datos ($PG_DATA)
usar RAID-10 para un uso más eficiente y un acceso mucho más rápido a
dichos datos; y para el directorio xlog un RAID-1, para así poder
asegurar la consistencia de los archivos WAL.
En caso de que se haga un uso extremo de los índices, puedes valorar
separarlos en un disco más rápido (básicamente en un tablespace que
contenga a este disco rápido, por ejemplo los nuevos SSD).
Para el sistema de ficheros, se recomienda xfs en caso de que estés
usando Linux, y zfs en caso de que estés usando Solaris o FreeBSD
(excelente rendimiento con PostgreSQL).
No sé realmente que más decirte, en la lista hay mucha tela por donde
cortar sobre estos temas.
Saludos
--
--------------------------------------------------------
-- Ing. Marcos Luís Ortíz Valmaseda --
-- Linux User # 418229 --
-- System Database Architect/Administrator --
-- *** PostgreSQL *** --
-- http://www.postgresql.org --
-- http://planetpostgresql.org --
-- http://www.postgresql-es.org --
-- http://commitfest.postgresql.org --
-- http://developer.postgresql.org --
-- http://www.enterprisedb.com/tservices/certification
--------------------------------------------------------
-- *** Contacto *** --
-- Twitter: http://twitter.com/@marcosluis2186 --
-- Facebook: http://www.facebook.com/marcosluis2186 --
-- GTalk: [email protected] --
--------------------------------------------------------
-- Ruby on Rails Fan/Developer --
-- http://rubyonrails.org --
-- http://www.37signals.com --
--------------------------------------------------------
-- Comunidad Técnica Cubana de PostgreSQL --
-- http://postgresql.uci.cu --
-- http://personas.grm.uci.cu/+marcos --
-- Centro de Tecnologías de Gestión de Datos (DATEC) --
-- Contacto: --
-- Correo: [email protected] --
-- Telf: +53 07-837-3737 --
-- +53 07-837-3714 --
-- Universidad de las Ciencias Informáticas --
-- http://www.uci.cu --
--------------------------------------------------------
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo
agradecerán
