Cluster tipo Oracle RAC

2015-03-12 7:31 GMT-05:00 Romero, Fernando <fromero(at)cferroviarios(dot)com(dot)ar>:
>
> Hola como están.
> Ya que hablan de cluster tengo una consult, postgres tiene cluste real? Donde 2 nodos puedan compartir storage, o es replicación solamente lo que tiene.
> Vengo del mundo de Oracle y es una de las cosas que necesitaría.
>

Saludos Fernando,

Por favor, si tienes una pregunta crea un nuevo correo. No uses el
mismo aunque las consultas se parezcan o traten un tema similar. La
razón de eso es que al buscar en los archivos verán un asunto y
podrían no mirar el correo suponiendo que no encontrarán respuesta a
su pregunta, cuando es posible que tu pregunta (escondida dentro de
otro tema) sea justo lo que buscaban.

Ahora, para contestar tu pregunta:
Postgres usa tecnología "shared nothing" porque es más seguro que
"shared everything" que es lo que usa RAC.

¿Por qué es más seguro? Pues porque en "shared everything" si pierdes
el storage pierdes todo y sí, los storage aunque cuesten millones
fallan (lo he visto mas de una vez).

Pero, ¿shared everything es más eficiente? tampoco, el disco es la
parte más lenta de un sistema. sin importar cuantos servidores tengas
conectados, cuanto CPU o memoria (que por cierto es lo único que
ganabas con RAC y que ya no tiene sentido con la cantidad de
procesadores que puedes tener en un solo servidor), esos servidores se
verán limitados por el disco.

La ventaja de RAC:
Teóricamente la ventaja que RAC provee es Transparent Application
Failover (TAF) que es la idea de que el usuario nunca nota la falla de
un servidor sino que es automáticamente transferido al otro servidor.
Aunque esto es bastante teórico, según
http://docs.oracle.com/cd/E19509-01/820-3492/boaem/index.html existen
tres tipos de FAILOVER (session, select, none) pero y ¿si cuando fallo
el servidor se estaba en medio de una transacción y se habían
realizado escrituras? tales escrituras probablemente estarían en
memoria y por lo tanto se perderían[1] tan solo abrir una nueva
conexión en el otro servidor y fingir que las cosas están bien no me
parece una acción razonable en ese caso.

[1] http://www.dba-oracle.com/art_oramag_rac_taf.htm
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda