Sin embargo tengo una pregunta. ¿Qué sucede si cascan los discos?
Redundancia a nivel de controladores y discos.
El cliente en este caso debería gestionar conectarse al servidor alternativo en caso de que el primero no respondiera.
¿Puede el cliente tolerar este cambio de manera "transparente"?. No he mirado los modelos de replicación del SQL Server (ya te comento, lo usaba en cluster). Antes de tomar una decisión en un uno u otro sentido, preguntaría al cliente exponiendo el coste de cada solución y si para el es crítico que se pierdan datos.
El primer método que me comentas, aunque caro, es interesante. Sin embargo tengo una pregunta. ¿Qué sucede si cascan los discos?
En principio en estos sistemas basados en Array de discos existe una duplicidad de datos y distribución de los mismos entre distintos discos (usando sistemas RAID) que hacen prácticamente imposible que se pierdan los datos. Pero tal y como está montado si lo que falla es el Array de discos, ahí tienes un problema ya que este no está duplicado.
Por lo tanto, ¿la réplica transaccional me permite lo que necesito?
La réplica transaccional permite lo que comentas, en caso de caída el servidor original la réplica te permiten mantener el servidor de backup actualizados hasta pocos momentos antes de la caída. A partir de aquí tienes de desviar "manualmente" los clientes de una base de datos a la otra.
Un ejemplo concreto de cómo realizar una réplica transaccional totalmente encaminada a mantener un servidor de backup la tienes en los "log Shipping" en esta web [sql-server...rmance.com].
He puesto lo de "manualmente" entrecomillado porque he visto aplicaciones que hacen este cambio de forma bastante transparente usando técnicas muy simples. Intentan establecer conexión con el servidor principal, en caso de fallar esta conexión intentan conectar directamente a la base de datos de respaldo. También he visto casos de aplicaciones que se reconfiguran cambiando un parámetro en el fichero de configuración. En ambos casos el cambio es rápido y sencillo y casi transparente para el usuario final.
Re:Dependerá de tus necesidades.
(Puntos:2)( http://icewinddale.blogspot.com/ | Última bitácora: Jueves, 30 Enero de 2014, 23:34h )
-- icewinddale.blogspot.com [blogspot.com]
Re:Dependerá de tus necesidades.
(Puntos:2)( http://barrapunto.com/ | Última bitácora: Jueves, 10 Febrero de 2011, 12:31h )
En principio en estos sistemas basados en Array de discos existe una duplicidad de datos y distribución de los mismos entre distintos discos (usando sistemas RAID) que hacen prácticamente imposible que se pierdan los datos. Pero tal y como está montado si lo que falla es el Array de discos, ahí tienes un problema ya que este no está duplicado.
La réplica transaccional permite lo que comentas, en caso de caída el servidor original la réplica te permiten mantener el servidor de backup actualizados hasta pocos momentos antes de la caída. A partir de aquí tienes de desviar "manualmente" los clientes de una base de datos a la otra.
Un ejemplo concreto de cómo realizar una réplica transaccional totalmente encaminada a mantener un servidor de backup la tienes en los "log Shipping" en esta web [sql-server...rmance.com].
He puesto lo de "manualmente" entrecomillado porque he visto aplicaciones que hacen este cambio de forma bastante transparente usando técnicas muy simples. Intentan establecer conexión con el servidor principal, en caso de fallar esta conexión intentan conectar directamente a la base de datos de respaldo. También he visto casos de aplicaciones que se reconfiguran cambiando un parámetro en el fichero de configuración. En ambos casos el cambio es rápido y sencillo y casi transparente para el usuario final.