Barrapunto

SQL Server Replication Services proporciona distintos métodos de replicación de bases de datos que tienen una utilidad y enfoque muy concretos.

Por lo que comentas, aún que no tengo demasiados datos, entiendo que te planteas usar replicación para mantener una copia sincronizada de la base de datos en caso de que el servidor de bases de datos caiga.

Para estos casos le método más eficaz, y también el más caro, es mantener los ficheros de la base de datos en un array de discos accesible por 2 o más servidores SQL Server configurados en un cluster. En caso de que uno de los servidores caiga los demás asumen la carga adicional, resultando totalmente transparente para el usuario.

En caso de querer hacer esto de forma más barata y menos automatizada existe la posibilidad de montar una replica transaccional. En este caso si se cae el servidor principal los clientes deben redirigirse al servidor de backup, El mecanismo de replica no realizará la sustitución automáticamente.

Pero lo mejor es que te mires la documentación de SQL Server al respecto de las réplicas, donde podrás encontrar información detallada sobre los escenarios posibles y qué réplica utilizar en cada caso.

El primer método que me comentas, aunque caro, es interesante. Sin embargo tengo una pregunta. ¿Qué sucede si cascan los discos?

El segundo método que me propones me parece más interesante. Suponiendo que la réplica transaccional me permite recuperar el estado de la base de datos a un momento muy cercano a la muerte de la misma (que puede ser por diversas causas, tanto físicas como lógicas), esto resuelve el problema. El cliente en este caso debería gestionar conectarse al servidor alternativo en caso de que el primero no respondiera.

Por lo tanto, ¿la replica transaccional me permite lo que necesito?

Gracias y un saludo.