SQL Server

Continuamos con nuestra serie sobre soluciones de alta disponibilidad en SQL Server hablando de la replicación. La replicación en SQL Server es un mecanismo que permite distribuir y sincronizar datos entre diferentes bases de datos, ya sea en la misma instancia o en instancias separadas. La replicación puede tener varios objetivos, como mejorar el rendimiento, la disponibilidad, la escalabilidad o la seguridad de los datos.

Existen diferentes tipos de replicación en SQL Server, cada uno con sus propias características, ventajas y desventajas. En este artículo vamos a explicar los conceptos básicos de la replicación, los tipos que existen y las razones por las que se utiliza.

¿Qué es la replicación?

La replicación es una solución que nos permite mantener actualizados los datos entre diferentes bases de datos. La base de datos que contiene los datos originales se llama publicador, y las bases de datos que reciben las copias se llaman suscriptores. El publicador puede tener uno o varios suscriptores, y cada suscriptor puede recibir una copia completa o parcial de los datos del publicador.

Todo el proceso se realiza mediante agentes, que son procesos que se encargan de leer, distribuir y aplicar los cambios de los datos entre el publicador y los suscriptores. Los agentes pueden ejecutarse de forma continua o programada, según el tipo de implementación y las necesidades del negocio.

Los agentes utilizan una base de datos intermedia llamada distribuidor, que almacena los cambios de los datos del publicador hasta que son enviados a los suscriptores. El distribuidor puede estar en la misma instancia que el publicador o en una instancia separada.

Un aspecto importante de esta solución es que se hace a nivel de objeto, es decir, se pueden seleccionar qué tablas, vistas, procedimientos almacenados u otros objetos se quieren replicar, sin tener que replicar toda la base de datos o la instancia. Esto permite tener un mayor control y flexibilidad sobre lo que se replica y cómo se replica. Además, se pueden aplicar filtros, transformaciones o reglas personalizadas para adaptar los datos y objetos replicados a las necesidades específicas de cada caso.

Tipos de replicación

Existen tres tipos principales de replicación en SQL Server según el nivel de detalle, la frecuencia y la dirección de los cambios que se quieren replicar. Elegiremos un tipo u otro de implementación en función de nuestras necesidades. 

Replicación transaccional 

Consiste en enviar los cambios de los datos del publicador a los suscriptores casi en tiempo real, después de cada transacción. Este modo de implementación es adecuado para escenarios en los que necesitamos una alta consistencia y disponibilidad de los datos. Tiene una serie de limitaciones como que todas las tablas tienen que tener PK o que no se puede modificar la estructura de las tablas que participan en la replicación. 

Replicación de instantáneas (snapshot)

Consiste en enviar una copia completa de los datos del publicador a los suscriptores cada cierto tiempo. Este modo de implementación es adecuado para escenarios en los que los datos no cambian con mucha frecuencia o no necesitamos una sincronización inmediata, como por ejemplo en sistemas de reportes o análisis.

Replicación de mezcla (merge)

Consiste en combinar la replicación transaccional y la replicación de instantáneas, permitiendo que tanto el publicador como los suscriptores puedan modificar los datos y sincronizarlos periódicamente. Este modo de implementación es adecuado para escenarios en los que se requiere una alta escalabilidad y flexibilidad, como por ejemplo en sistemas distribuidos o móviles. 

Ventajas y desventajas de la replicación

Ventajas

Como venimos viendo en los distintos artículos de esta serie, tener los datos replicados mejora el rendimiento al reducir la carga de trabajo en el publicador y permitir acceso de lectura desde diferentes ubicaciones. 

Otra de las ventajas de la replicación es que mejora la disponibilidad al proporcionar redundancia y tolerancia a fallos en caso de que el publicador o alguno de los suscriptores no esté disponible. Además nos permite agregar más suscriptores según aumente la demanda lo que se traduce en una buena escalabilidad. Por último, mejora la seguridad al permitir aplicar diferentes niveles de acceso a los datos para cada suscriptor.

Inconvenientes

Sin embargo, la replicación también tiene algunas desventajas. Aumenta la complejidad al requerir una configuración y administración más cuidadosa y detallada. Por otro lado, aumenta el consumo de recursos al requerir más espacio en disco, memoria y red para almacenar y transmitir los datos.

Además, uno de los mayores inconvenientes de la replicación es el riesgo de inconsistencia o pérdida de datos si ocurren errores o conflictos durante el proceso de replicación. Por experiencia, es uno de los procesos en SQL Server con más tasa de error y con un mantenimiento complejo y, a veces, difícil de encontrar la causa de los problemas.

Relación vs Alta Disponibilidad

Como hemos podido ver, la replicación es una forma de lograr la alta disponibilidad. Sin embargo, la replicación no es lo mismo que la alta disponibilidad, ya que esta última implica otros aspectos como el balanceo de carga, el monitoreo, la recuperación ante desastres o el mantenimiento preventivo.

Tanto la replicación como las soluciones de alta disponibilidad buscan mejorar la confiabilidad y la continuidad del servicio minimizando las interrupciones o las pérdidas de datos. La replicación y la alta disponibilidad se complementan y se benefician mutuamente. Sin embargo, mientras que la replicación se enfoca en distribuir y sincronizar los datos, una solución de alta disponibilidad nos debe garantizar el funcionamiento del servicio. La replicación puede ser una parte de una solución de alta disponibilidad, pero no es suficiente por sí sola. 

Conclusión

La replicación en SQL Server es un mecanismo poderoso y versátil que nos permite sincronizar datos entre diferentes bases de datos. Dependiendo del tipo de replicación elegido, se pueden obtener diferentes beneficios y desafíos. Como DBAs, debemos analizar las necesidades del negocio y las características de los datos antes de implementar una solución basada en la replicación. Asimismo, es importante entender la relación entre la replicación y la alta disponibilidad, y cómo ambas pueden contribuir a mejorar el servicio.

La replicación en SQL Server es un tema muy amplio y con muchas opciones de configuración y personalización. En este artículo solo hemos visto una introducción general a la teoría y el por qué de las cosas. Seguro que en futuros artículos hablaremos más en profundidad de este tema, aunque ya será fuera de esta serie. Como ya sabéis, podéis dejarme vuestras dudas y comentarios abajo, por Twitter o mail. ¡Hasta la próxima!

Continuamos con la serie de artículos sobre alta disponibilidad, hoy hablaremos de Log Shipping. Log shipping es una técnica de alta disponibilidad que permite replicar los datos de una base de datos de SQL Server en una o varias bases de datos secundarias. De esta forma, podremos tener una copia actualizada (o casi) de los datos en caso de que la base de datos principal falle o se pierda. También nos va a permitir crear copias de sólo lectura de nuestra base de datos en otra ubicación.

¿Cómo funciona Log Shipping?

Log Shipping funciona mediante la creación y el envío periódico de copias de seguridad del log de transacciones de la base de datos principal a las bases de datos secundarias. Estas copias de seguridad se restauran en las bases de datos secundarias, aplicando así los cambios que se han producido en la base de datos principal. 

Cuando configuremos Log Shipping se crearán una serie de jobs en las instancias SQL Server principal y secundarias para hacer las copias de seguridad, moverlas y restaurarlas. Podremos cambiar manualmente las programaciones de estos jobs en función de la periodicidad que deseemos en las instancias secundarias. Esto marcará en gran medida nuestro RPO, por defecto será una copia de seguridad cada 15 minutos pero podemos reducirlo si lo necesitamos.

Pros y contras de Log Shipping

Ventajas

Log shipping es una solución sencilla y económica que no requiere de licencias Enterprise ni clústers complejos para funcionar. Nos va a permitir tener varias bases de datos secundarias, lo que puede mejorar el rendimiento de las consultas de solo lectura y la distribución geográfica de los datos. Además, podremos tener un control total sobre el proceso, ya que se puede configurar la frecuencia, el horario y el modo de envío y restauración de las copias de seguridad. Por último, nos va a ayudar a mantener un RTO relativamente bajo, ya que se puede usar la base de datos secundaria como principal en caso de emergencia.

Inconvenientes

Sin embargo, Log Shipping también tiene algunas limitaciones. No garantiza una sincronización en tiempo real, siempre habrá un retraso entre la base de datos principal y las secundarias dependiendo del intervalo de copia de seguridad y restauración. Esto implica que los objetivos RPO y RTO pueden no ser tan bajos como con otras soluciones. Con Log Shipping, el RPO y el RTO dependen del intervalo configurado para las copias del log.
A nivel operativa diaria, no permite realizar cambios en la estructura o el esquema de la base de datos principal, ya que estos cambios no se replican a través de copias de log de transacciones. Tampoco nos va a permitir en ningún momento tener bases de datos secundarias en modo lectura/escritura. No es compatible con algunas características de SQL Server, como la compresión de datos, el cifrado transparente de datos o las instantáneas de base de datos. Ni con otras soluciones de alta disponibilidad como los Always On (aunque se puede llegar a hacer funcionar no es una solución aprobada por Microsoft.)
Además, no nos va a facilitar ninguna opción de balanceo automático. En caso de error, tendremos que activar manualmente la base de datos secundaria y redirigir a ella todas las conexiones.

Opciones de implementación de Log Shipping

Hemos dicho antes que en Log Shipping podemos tener las copias secundarias accesibles en modo lectura. Esto lo tendremos que configurar cuando configuremos la restauración en el servidor secundario. Tendremos la opción de restaurar las copias de seguridad en modo NORECOVERY o STANDBY. El modo STANDBY nos permitirá mantener nuestras bases de datos secundarias accesibles para lectura. Sin embargo, solo podremos hacerlo si el servidor principal y el secundario tienen la misma versión de SQL Server. Tendremos que usar el modo NORECOVERY si nuestra base de datos secundaria es de una versión superior a la principal.

Tendremos también la posibilidad de modificar el comportamiento de nuestro Log Shipping modificando los jobs que genera. En el servidor principal tendremos dos jobs, uno encargado de hacer las copias de seguridad de log de transacciones y otro que comprobará si se hacen las copias y enviará alertas en caso contrario. Es importante que no tengamos ninguna otra copia de seguridad de log fuera de este job o Log Shipping dejará de funcionar.
En el servidor secundario nos encontraremos tres jobs, el de copia de los archivos de copia de seguridad del servidor principal al secundario, el de restauración y otro de monitorización.

Por último, igual que vimos en Database Mirroring, podremos configurar una instancia SQL Server de supervisión. En este caso no será encargada del balanceo pues no tenemos opción de automatizarlo, pero sí que recibirá y almacenará el estado actual y el historial de nuestro Log Shipping.

Conclusión

Aunque siempre se habla de Log Shipping como una solución de alta disponibilidad y hasta yo lo he tratado como tal hasta este punto, realmente no lo es. Como hemos podido ver, debido a sus limitaciones de RPO y RTO la alta disponibilidad real queda muy lejos de esta solución. Sin embargo, me parece una técnica muy útil para mantener una copia actualizada y disponible de los datos en SQL Server. Esto lo convierte en una solución ideal para un DRP o para tener copias de sólo lectura de nuestro servidor de producción, por ejemplo en servidores de análisis o DWH.

Espero que este artículo te haya ayudado a entender mejor qué es Log Shipping y cómo implementarlo en SQL Server. Si tienes alguna duda o comentario, no dudes en dejarlo abajo, en Twitter o por mail. Estaré encantado de ayudarte. ¡Hasta la próxima!

El espejo de bases de datos o Database Mirroring es una solución de alta disponibilidad presente en SQL Server desde la versión 2008. Igual que la solución Always On, funciona a nivel de base de datos pero, en este caso, debe configurarse individualmente en cada base de datos. Una de las instancias actuará como primaria (principal) y otra como secundaria (espejo). Como siempre hacemos, vamos a ver sus características y cómo funciona, sin embargo no vamos a comentar cómo implementarlo. Esta es una solución discontinuada por parte de Microsoft que desaparecerá en futuras versiones de SQL en favor de Always On.

Opciones de implementación de Database Mirroring

Database Mirroring funciona sincronizando la base de datos del servidor principal con la base de datos del servidor espejo. No admite más réplicas. Sin embargo, es posible configurar una tercera instancia como testigo (witness) que se encargará del balanceo automático en caso de fallo en el servidor primario. 

La opción más común de implementación de Database Mirroring es con dos servidores SQL cada uno con una instancia replicando una base de datos del principal al espejo. Sin embargo, es posible encontrar Database Mirroring configurados entre instancias de la misma máquina. También es común encontrar una pareja de servidores que son principales para unas bases de datos y espejo para otras. Os dejo esquemas de estas implementaciones sacados de la documentación oficial:

Modos operativos de Database Mirroring

Podemos configurar nuestros Database Mirroring de tres maneras diferentes y, en función de como lo configuremos cambiarán su comportamiento. Como DBAs deberemos decidir cuál se adapta mejor a nuestro escenario.

Modo alto rendimiento

El modo alto rendimiento solo está disponible en versiones Enterprise de SQL Server. Si optamos por este modo no tendremos opción de usar un servidor como testigo. Los datos se enviarán del servidor principal al espejo de manera asíncrona. Al no admitir un servidor testigo, no es posible configurar un balanceo automático en caso de fallo del servidor principal. Cuando esto pasa, podemos esperar a que vuelva a estar operativo el principal (con la base de datos no disponible), forzar un balanceo manual (con posible pérdida de datos) o actualizar manualmente la base de datos espejo con la última copia de log del servidor principal. 

Modo alta seguridad

Disponible en todas las versiones de SQL Server el modo alta seguridad envía los datos de manera síncrona, la transacción se confirmará tras el commit en ambos servidores. Puede ser un problema si la latencia de red es elevada. En caso de fallo del servidor principal, los datos en el servidor espejo estarán actualizados y no tendremos perdida de datos. Podremos elegir si queremos esperar con la base de datos no disponible o forzar un balanceo manual sin pérdida de datos.

Modo alta seguridad con balanceo automático

Los datos se escriben de manera síncrona en el servidor principal y el espejo pero necesitaremos de un tercer servidor que haga de testigo. En caso de fallo del servidor principal, el servidor testigo será capaz de detectarlo y automáticamente balanceará el rol, convirtiéndose en principal la base de datos del servidor espejo.

Pros y contras de Database Mirroring

La principal ventaja de esta solución es su facilidad de configuración, no requiere de WSFC y es compatible con todas las ediciones y versiones de SQL Server desde 2008. Todo esto permitiéndonos configurar un balanceo automático. Además, se puede combinar con otras opciones como las FCI, el log shipping o la replicación. 

Como hemos empezado comentando, es una solución que será eliminada de futuras versiones de SQL Server en favor de Always On. Siendo soluciones de alta disponibilidad a nivel base de datos, Database Mirroring se debe configurar individualmente por base de datos, no tiene opción de configurar un listener como punto de escucha común para los dos servidores y solo admite una réplica. 

Conclusión

Hemos podido conocer los aspectos básicos de Database Mirroring, una solución de alta disponibilidad de SQL Server discontinuada y que se eliminará en un futuro. Como DBAs evitaremos configurar esta solución por los motivos ya mencionados aunque, como todos sabemos, el mundo real es muy diferente a la teoría y por eso debemos conocerlo y tener claro cómo funciona.

Hoy vamos a hablar de otra solución de alta disponibilidad de SQL Server, las instancias de conmutación por error o FCI. Al igual que los Always On, las FCI necesitan de un clúster de Windows (WSFC) para funcionar. Realmente, pocos parecidos más vamos a encontrar entre las 2 soluciones pero, no adelantemos acontecimientos, veamos en detalle cómo funcionan las FCI y luego ya la comparación con Always On. 

¿Qué son las FCI?

Como hemos podido ver, las FCI son una solución de alta disponibilidad de SQL Server basada en WSFC. En esta solución tendremos varios servidores nodos de un clúster. Estos nodos compartirán un almacenamiento compartido donde se almacenarán todos los datos de las bases de datos. El servicio de SQL solo estará en ejecución en el nodo principal del clúster pudiendo balancear a otro nodo (y parando en el principal) en caso de error de hardware, software o mantenimiento programado. Como habrás podido deducir, se trata, por tanto, de una solución de alta disponibilidad a nivel de instancia y no de base de datos como el resto de las que hemos visto. 

Elementos de una FCI

Como hemos visto, las FCI se componen de un grupo de dos o más servidores que forman parte de un WSFC. A estos miembros del clúster se les conoce como nodos. Los nodos de una FCI pueden tener diferente hardware pero deben tener la misma configuración de software para garantizar el éxito en caso de balanceo del servicio. Además de esto, el clúster tiene que tener una serie de configuraciones que vamos a detallar.

Grupo de recursos

Nuestra FCI se ejecutará dentro de un grupo de recursos de WSFC. Cada nodo del clúster tendrá una copia actualizada de las configuraciones y claves de registro almacenadas en el grupo de recursos. Sin embargo, solo el nodo activo pertenece al grupo de recursos y en caso de balanceo (automático o manual) esta propiedad pasará a otro nodo. El número máximo de nodos admitidos en una FCI dependerá de la versión de SQL Server. Además un mismo WSFC puede tener varios grupos de recursos con varias FCI. 

Almacenamiento

Como hemos visto, el almacenamiento de nuestra FCI debe ser compartido entre los nodos, esto lo podemos lograr con unidades SAN o recursos compartidos SMB. Además, desde Windows Server 2016, también se admite el espacio de almacenamiento directo (S2D). El almacenamiento, al ser común, es nuestro SPOF (Single Point Of Failure) y debemos extremar la precaución sobre él. Os recomiendo soluciones especializadas de almacenamiento con redundancia.

Instalación de SQL Server

Cada uno de los nodos del clúster tendrá instalado SQL Server de manera similar a una instalación independiente con la peculiaridad de que los servicios no se inician de manera automática, sino que es el WSFC quien levanta el servicio del nodo principal y detiene los del resto de nodos.

Red

Nuestro grupo de recursos tendrá un nombre de red virtual (VNN por sus siglas en inglés). Este VNN será el punto de acceso a nuestra instancia de SQL Server y estará asignado al nodo primario del clúster. En caso de balanceo se asignará al nuevo nodo primario.

Además, si tenemos una FCI distribuida en varias subredes, necesitaremos de direcciones IP virtuales para cada subred. En caso de balanceo, el WSFC apuntará nuestro VNN a la IP virtual de esa subred de manera que los clientes puedan seguir conectando a la instancia de forma transparente.

Ventajas de las FCI

En este punto no vamos a decir nada nuevo pero si vamos a remarcar lo que son las ventajas de esta solución de alta disponibilidad frente a otras:

– Alta disponibilidad: si el nodo activo falla, el nodo pasivo asume el rol de nodo activo automáticamente y continúa prestando el servicio sin interrupciones. El tiempo de conmutación por error depende de varios factores, pero suele ser muy corto (de segundos a minutos).

– Escalabilidad: se pueden añadir más nodos al clúster para aumentar la capacidad de procesamiento y el rendimiento. Además, se pueden crear varias FCI en el mismo clúster para distribuir la carga de trabajo.

– Facilidad de administración: se puede administrar la FCI como una única instancia de SQL Server, sin importar en qué nodo se esté ejecutando. También se puede usar el Administrador de clústeres de conmutación por error para gestionar el clúster y sus recursos.

– Compatibilidad: se puede usar una FCI con cualquier edición de SQL Server (desde la 2008 hasta la 2019) y con cualquier sistema operativo Windows Server que soporte clústeres de conmutación por error (desde el 2008 R2 hasta el 2019).

Inconvenientes de las FCI

Como ya hemos visto, el principal inconveniente de esta solución es el uso compartido del almacenamiento, lo que genera un SPOF que debe ser controlado por el equipo de storage. Si no hay disponibilidad del almacenamiento nuestras FCI no funcionarán. Esto puede no ser un problema tan grave con el estado actual de las instalaciones, donde el almacenamiento recae en cabinas de discos especializadas y, aunque tengamos distintas máquinas virtuales cada una con un almacenamiento, usan la misma base. Tenéis que valorarlo en cada caso.

Sin embargo, este no es el único inconveniente de esta solución, otro de los más graves puede ser el tiempo de balanceo que, puede ir desde varios segundos a minutos y puede no encajar en nuestro RTO. Este tiempo de respuesta es debido al uso compartido de discos y como SQL hace uso de ellos y de las páginas las caché de buffer. Entraremos en esto con más detalle en otro artículo pero tenéis que saber que el balanceo de una FCI puede tardar lo que el nodo tarde en escribir en disco una todas las páginas desfasadas. Desde SQL Server 2012 SQL permite usar puntos de comprobación indirectos (Indirect Checkpoints) para limitar el número de páginas desfasadas que se mantienen en la caché de buffer y mitigar este problema,

FCI VS Always On

Con lo que hemos visto hasta ahora podemos ya marcar las diferencias entre ambas soluciones de alta disponibilidad de SQL Server basadas en WSFC. La principal diferencia, para mi, sería el uso de almacenamiento compartido frente al almacenamiento individual redundado en cada nodo. Esto es, entre otras cosas, porque mientras las FCI son una solución de alta disponibilidad a nivel instancia, Always On lo es a nivel base de datos. Las FCI son más fáciles de administrar y nos permite tratar la instancia como una instalación individual corriendo en el nodo activo mientras que en Always On tendremos que actuar en cada uno de los servidores. Sin embargo, el tiempo de balanceo es mayor en una FCI. 

Otro aspecto clave que puede hacernos decidir por una solución u otra es la accesibilidad de las réplicas secundarias. Mientras que en una FCI solo uno de los nodos tiene el servicio en ejecución, en un Always On tendremos disponible una réplica secundaria para operaciones de lectura y copias de seguridad. Sin embargo, el coste en una FCI puede ser mucho menor al no requerir de una edición enterprise. Con una edición standard podremos tener hasta 2 nodos de FCI. Para más de 2 nodos si que necesitaremos una edición enterprise.

Conclusión

Como hemos visto las FCI son una gran solución de alta disponibilidad a un coste relativamente accesible. Nos protegen frente a todo tipo de fallos excepto los de almacenamiento. Además, son mucho más fáciles de administrar cuando tenemos muchos objetos a nivel de servidor como jobs o logins. En un Always On tendríamos que duplicar el trabajo de mantener los objetos a nivel instancia. 

Por si esto fuera poco, además, nos permiten tener varias FCI en un mismo WSFC para optimizar la carga de trabajo a la vez que protegemos nuestros servicios de caídas. Es una solución común tener varios servidores en un WSFC cada uno con una FCI activa pero que todos los nodos puedan asumir las instancias del resto en caso de fallo.

Hoy iniciamos una nueva serie en la que vamos a hablar sobre las distintas soluciones de alta disponibilidad que existen para SQL Server. Antes de nada vamos a aclarar los conceptos básicos sobre los que profundizaremos tanto hoy como estos próximos días. A continuación, vamos a resumir brevemente las distintas soluciones de SQL Server que tenemos a nuestro alcance. Solo un breve resumen ya en los próximos artículos que las veremos más en profundidad.

¿Qué es la Alta Disponibilidad?

La alta disponibilidad se refiere a la capacidad de un sistema de seguir funcionando sin interrupciones ante posibles fallos o desastres, ya sean de hardware, software o de infraestructura. 

¿Por qué es importante? 

La alta disponibilidad es importante porque nos permite garantizar la continuidad del negocio, la satisfacción de los clientes y el cumplimiento de los acuerdos de nivel de servicio (SLA).

Aspectos clave para implementar una solución de Alta Disponibilidad

Para evaluar la adecuación de una solución de alta disponibilidad, es necesario tener en cuenta dos conceptos clave: el punto de recuperación objetivo (RPO) y el tiempo de recuperación objetivo (RTO). El RPO indica la cantidad máxima de datos que se pueden perder en caso de un fallo, mientras que el RTO indica el tiempo máximo que se puede tardar en restaurar el servicio. Estos valores dependen del nivel de criticidad del sistema y del presupuesto disponible, y pueden variar desde unos pocos segundos hasta varias horas o días.

Distintas soluciones de Alta Disponibilidad

SQL Server ofrece varias opciones para implementar la alta disponibilidad, dependiendo de las necesidades y los recursos de cada organización. Algunas de las más conocidas son:

Grupos de disponibilidad Always On

Esta es una solución replica datos de forma síncrona o asíncrona entre varias réplicas secundarias con una conmutación por error automática o manual. Los grupos de disponibilidad Always On tienen una réplica primaria que recibe las transacciones y las envía a las réplicas secundarias, que pueden estar en la misma red local o en ubicaciones remotas. Además, las réplicas secundarias pueden usarse para realizar consultas de solo lectura, copias de seguridad o restauraciones, lo que mejora el rendimiento y la escalabilidad de nuestro sistema.

Always On ofrece un RPO y un RTO muy bajos, ya que los datos se sincronizan casi en tiempo real y la conmutación por error se realiza en cuestión de segundos (incluso milisegundos). Los Always On requieren que las instancias de SQL Server pertenezcan a un clúster de conmutación por error de Windows Server (WSFC) para alta disponibilidad y recuperación ante desastres.

Instancia de clúster de conmutación por error

Consiste en tener varios nodos que comparten un almacenamiento común y que pueden asumir el rol de servidor activo en caso de que el nodo principal falle. Los clústeres de conmutación de instancia requieren una configuración especial del hardware, el software y la red, así como una coordinación entre los nodos mediante un testigo (witness). Los clústeres de conmutación de instancia garantizan la disponibilidad del servicio, pero no protegen contra la pérdida o corrupción de los datos al compartir el almacenamiento de los datos. Esta solución tiene un RPO y un RTO moderados, ya que dependen del tiempo que se tarde en detectar el fallo y en activar el nodo secundario. Los clústeres de conmutación de instancia requieren que las instancias de SQL Server estén instaladas en servidores miembros de un clúster WSFC

Database mirroring (Espejo de bases de datos)) 

Esta solución consiste en tener dos instancias de SQL Server que mantienen una copia idéntica de una base de datos mediante el envío del log de transacciones. El database mirroring puede operar en modo síncrono o asíncrono, y puede tener una instancia testigo que supervise el estado de las dos instancias y realice la conmutación por error automáticamente en caso necesario. Proporciona protección contra la pérdida o corrupción de los datos, pero solo se aplica a una base de datos a la vez. Tiene otras limitaciones como que no admite el cifrado transparente de datos (TDE) o los cambios de esquema en línea. Esta solución tiene un RPO y un RTO variables, dependiendo del modo elegido y del tamaño del log.

Log shipping (Envío de Log)

Tendremos una instancia primaria que realiza copias de seguridad periódicas del log de transacciones y las enviará a una o más instancias secundarias que las restauran. El log shipping permite tener varias copias actualizadas (o casi) de una base de datos en diferentes ubicaciones, lo que facilita la recuperación ante desastres. Sin embargo, no ofrece una conmutación por error automática ni una sincronización en tiempo real, por lo que puede haber una pérdida o inconsistencia de los datos. Esta solución tiene un RPO y un RTO altos, ya que dependen de la frecuencia y la duración de las copias de seguridad y las restauraciones.

Otras soluciones de alta disponibilidad

Estas son algunas de las soluciones más populares para lograr la alta disponibilidad en SQL Server, pero no son las únicas. También existen otras opciones como la replicación, el almacenamiento distribuido o los servicios en la nube. Lo importante es evaluar las ventajas y desventajas de cada una, así como los requisitos y objetivos del negocio, para elegir la más adecuada.

Conclusión

Como hemos podido ver SQL Server ofrece diversas soluciones de alta disponibilidad que se adaptan a diferentes escenarios y necesidades. Algunas de estas soluciones requieren un clúster WSFC, mientras que otras no. Es importante conocer las características, ventajas y limitaciones de cada opción, así como los conceptos de RPO y RTO, para tomar una decisión informada y optimizar el rendimiento y la seguridad de los datos.

Espero que os haya gustado este artículo y que os sirva para conocer mejor las opciones de alta disponibilidad que ofrece SQL Server. Como siempre, cualquier duda o comentario, podéis dejarla aquí abajo, por mail o en twitter,