Implementación de Microsoft SQL Server para recuperación ante desastres multirregional

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Comprender la recuperación ante desastres

En Google Cloud, la recuperación ante desastres (DR) consiste en proporcionar continuidad del procesamiento, especialmente cuando una región falla o se vuelve inaccesible. Para sistemas como un sistema de administración de bases de datos, la recuperación ante desastres se implementa implementando el sistema en al menos dos regiones. Con esta configuración, el sistema continúa funcionando si una región deja de estar disponible.

Recuperación ante desastres del sistema de base de datos

El proceso de hacer que una base de datos secundaria esté disponible cuando falla la instancia de la base de datos principal se denomina recuperación ante desastres de la base de datos (o DR de la base de datos ). Para obtener una discusión detallada sobre este concepto, consulte Recuperación ante desastres para Microsoft SQL Server . Idealmente, el estado de la base de datos secundaria es consistente con el de la base de datos primaria en el momento en que la primaria deja de estar disponible, o a la base de datos secundaria le falta solo un pequeño conjunto de transacciones recientes de la base de datos primaria.

Arquitectura de recuperación ante desastres

Para Microsoft SQL Server, el siguiente diagrama muestra una arquitectura mínima que admite DR de base de datos.

Figura 1. Arquitectura estándar de recuperación ante desastres con Microsoft SQL Server.

Esta arquitectura funciona de la siguiente manera:

• Dos instancias de Microsoft SQL Server (una instancia principal y una instancia en espera) están ubicadas en la misma región (R1) pero en zonas diferentes (zonas A y B). Las dos instancias en R1 coordinan sus estados mediante el modo de confirmación sincrónica. El modo síncrono se utiliza porque admite alta disponibilidad y mantiene un estado de datos consistente.
• Una instancia de Microsoft SQL Server (la instancia secundaria o de recuperación ante desastres) se encuentra en una segunda región (R2). Para DR, la instancia secundaria en R2 se sincroniza con la instancia principal en R1 mediante el modo de confirmación asincrónica. El modo asíncrono se utiliza debido a su rendimiento (no ralentiza el procesamiento de confirmación en la instancia principal).

En el diagrama anterior, la arquitectura muestra un grupo de disponibilidad. El grupo de disponibilidad, si se usa con un agente de escucha, proporciona la misma cadena de conexión a los clientes si los clientes reciben el servicio de lo siguiente:

• La instancia principal
• La instancia en espera (después de una falla de zona)
• La instancia secundaria (después de un error de región y después de que la instancia secundaria se convierta en la nueva instancia principal)

En una variante de la arquitectura anterior, las dos instancias que se encuentran en la primera región (R1) se implementan en la misma zona. Este enfoque podría mejorar el rendimiento, pero no está altamente disponible; Es posible que se requiera una interrupción de zona única para iniciar el proceso de recuperación ante desastres.

Proceso básico de recuperación ante desastres

El proceso de recuperación ante desastres comienza cuando una región deja de estar disponible y la base de datos principal falla para reanudar el procesamiento en otra región operativa. El proceso de recuperación ante desastres prescribe los pasos operativos que se deben tomar, ya sea manual o automáticamente, para mitigar el error de la región y establecer una instancia primaria en ejecución en una región disponible.

Un proceso básico de recuperación ante desastres de una base de datos consta de los siguientes pasos:

1. La primera región (R1), que ejecuta la instancia de la base de datos principal, deja de estar disponible.
2. El equipo de operaciones reconoce y reconoce formalmente el desastre y decide si se requiere una conmutación por error.
3. Si se requiere una conmutación por error, la instancia de base de datos secundaria en la segunda región (R2) se convierte en la nueva instancia principal.
4. Los clientes reanudan el procesamiento en la nueva base de datos principal y acceden a la instancia principal en R2.

Aunque este proceso básico vuelve a establecer una base de datos primaria funcional, no establece una arquitectura de DR completa, donde la nueva primaria tiene una instancia de base de datos secundaria y en espera.

Proceso completo de recuperación ante desastres

Un proceso de DR completo amplía el proceso de DR básico al agregar pasos para establecer una arquitectura de DR completa después de una conmutación por error. El siguiente diagrama muestra una arquitectura DR de base de datos completa.

Figura 2. Recuperación ante desastres con una región primaria no disponible (R1).

Esta arquitectura completa de DR de base de datos funciona de la siguiente manera:

1. La primera región (R1), que ejecuta la instancia de la base de datos principal, deja de estar disponible.
2. El equipo de operaciones reconoce y reconoce formalmente el desastre y decide si se requiere una conmutación por error.
3. Si se requiere una conmutación por error, la instancia de base de datos secundaria en la segunda región (R2) se convierte en la instancia principal.
4. Otra instancia secundaria, la nueva instancia en espera, se crea, se inicia en R2 y se agrega a la instancia principal. La instancia en espera está en una zona diferente de la instancia principal. La base de datos principal ahora consta de dos instancias (primaria y en espera) que tienen alta disponibilidad.
5. En una tercera región (R3), se crea e inicia una nueva instancia de base de datos secundaria (en espera). Esta instancia secundaria está conectada de forma asíncrona a la nueva instancia principal en R2. En este punto, la arquitectura original de recuperación ante desastres está recreada y operativa.

Regreso a una región recuperada

Una vez que la primera región (R1) vuelve a estar en línea, puede alojar la nueva base de datos secundaria. Si R1 está disponible lo suficientemente pronto, puede implementar el paso 5 en el proceso de recuperación completo en R1 en lugar de R3 (la tercera región). En este caso, no se necesita una tercera región.

El siguiente diagrama muestra la arquitectura si R1 está disponible a tiempo.

Figura 3. Recuperación ante desastres después de que la región fallida R1 vuelva a estar disponible.

En esta arquitectura, los pasos de recuperación son los mismos que los descritos anteriormente en Proceso completo de recuperación ante desastres , con la diferencia de que R1 se convierte en la ubicación para las instancias secundarias en lugar de R3.

Elegir una edición de SQL Server

Este tutorial es compatible con las siguientes versiones de Microsoft SQL Server:

• SQL Server 2016 Edición Empresarial
• SQL Server 2017 Edición Empresarial
• SQL Server 2019 Edición Empresarial
• SQL Server 2022 Edición empresarial

El tutorial utiliza la función Grupos de disponibilidad AlwaysOn en SQL Server.

Si no necesita una base de datos primaria de Microsoft SQL Server de alta disponibilidad (HA) y una única instancia de base de datos es suficiente como principal, puede usar las siguientes versiones de SQL Server:

• SQL Server 2016 Edición estándar
• SQL Server 2017 Edición estándar
• SQL Server 2019 Edición estándar
• SQL Server 2022 Edición estándar

Las versiones 2016, 2017, 2019 y 2022 de SQL Server tienen Microsoft SQL Server Management Studio instalado en la imagen; No es necesario instalarlo por separado. Sin embargo, en un entorno de producción, recomendamos instalar una instancia de Microsoft SQL Server Management Studio en una máquina virtual separada en cada región. Si configura un entorno HA, debe instalar Microsoft SQL Server Management Studio una vez para cada zona para garantizar que permanezca disponible si otra zona deja de estar disponible.

Configuración de Microsoft SQL Server para DR multirregional

Esta sección utiliza las siguientes imágenes para Microsoft SQL Server:

• sql-ent-2016-win-2016 para Microsoft SQL Server 2016 Edición Empresarial
• sql-ent-2017-win-2016 para Microsoft SQL Server 2017 Edición Empresarial
• sql-ent-2019-win-2019 para Microsoft SQL Server 2019 Edición Empresarial
• sql-ent-2022-win-2022 para Microsoft SQL Server 2022 Edición empresarial

Para obtener una lista completa de imágenes, consulte Imágenes .

Configurar un clúster de alta disponibilidad de dos instancias

Para configurar una arquitectura de DR de base de datos multirregional para SQL Server, primero debe crear un clúster de alta disponibilidad (HA) de dos instancias en una región. Una instancia actúa como principal y la otra como secundaria. Para realizar este paso, siga las instrucciones en Configuración de grupos de disponibilidad AlwaysOn de SQL Server . Este tutorial utiliza us-central1 para la región principal (denominada R1 ). Antes de comenzar, revise las siguientes consideraciones:

• Si siguió los pasos en Configuración de grupos de disponibilidad AlwaysOn de SQL Server , habrá creado dos instancias de SQL Server en la misma región ( us-central1 ). Habrá implementado una instancia principal de SQL Server ( node-1 ) en us-central1-a y una instancia en espera ( node-2 ) en us-central1-b .

• Aunque implemente la arquitectura de la Figura 4 para este tutorial, se recomienda configurar un controlador de dominio en más de una zona. Este enfoque garantiza que usted establezca una arquitectura de base de datos habilitada para HA y DR. Por ejemplo, si se produce una interrupción en una zona, esa zona no se convierte en un punto único de falla para la arquitectura implementada.

Figura 4. Arquitectura estándar de recuperación ante desastres implementada en este tutorial.

Agregue una instancia secundaria para la recuperación ante desastres

A continuación, configura una tercera instancia de SQL Server (una instancia secundaria denominada node-3 ) y configura la red de la siguiente manera:

1. Cree una secuencia de comandos especializada para los nodos del clúster de conmutación por error de Windows Server. El script instala la característica necesaria de Windows y crea reglas de firewall para WSFC y SQL Server. También formatea el disco de datos y crea carpetas de datos y registros para SQL Server:

   cat << "EOF" > specialize-node.ps1
   
   $ErrorActionPreference = "stop"
   
   # Install required Windows features
   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   Install-WindowsFeature RSAT-AD-PowerShell
   
   # Open firewall for WSFC
   netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997
   
   # Open firewall for SQL Server
   netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433
   
   # Open firewall for SQL Server replication
   netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
   
   # Format data disk
   Get-Disk |
    Where partitionstyle -eq 'RAW' |
    Initialize-Disk -PartitionStyle MBR -PassThru |
    New-Partition -AssignDriveLetter -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false
   
   # Create data and log folders for SQL Server
   md d:\Data
   md d:\Logs
   EOF
   

2. Inicialice las siguientes variables:

   VPC_NAME=VPC_NAME
   SUBNET_NAME=SUBNET_NAME
   REGION=us-east1
   PD_SIZE=200
   MACHINE_TYPE=n2-standard-8
   

   Dónde:

   • VPC_NAME : nombre de su VPC
   • SUBNET_NAME : nombre de su subred para la región us-east1

3. Cree una instancia de SQL Server:

   gcloud compute instances create node-3 \
   --zone $REGION-b \
   --machine-type $MACHINE_TYPE \
   --subnet $SUBNET_NAME \
   --image-family sql-ent-2022-win-2022 \
   --image-project windows-sql-cloud \
   --tags wsfc,wsfc-node \
   --boot-disk-size 50 \
   --boot-disk-type pd-ssd \
   --boot-disk-device-name "node-3" \
   --create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
   --metadata enable-wsfc=true \
   --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1
   

4. Establezca una contraseña de Windows para la nueva instancia de SQL Server:

   1. En la consola de Google Cloud, vaya a la página de Compute Engine.

      Ir a Computadora

   2. En la columna Conectar para el node-3 del clúster de Compute Engine, seleccione la lista desplegable Establecer contraseña de Windows .

   3. Establezca el nombre de usuario y la contraseña. Anótelos para su uso posterior.

5. Haga clic en RDP para conectarse a la instancia node-3 .

6. Ingrese el nombre de usuario y la contraseña del paso anterior y luego haga clic en Aceptar .

7. Agregue la instancia al dominio de Windows:

   1. Haga clic derecho en el botón Inicio (o presione Win+X) y haga clic en Windows PowerShell (Administrador).

   2. Confirme el mensaje de elevación haciendo clic en Sí.

   3. Una la computadora a su dominio de Active Directory y reinicie:

      Add-Computer -Domain DOMAIN -Restart
      

      Reemplace DOMAIN con el nombre DNS de su dominio de Active Directory.

      Espere aproximadamente 1 minuto para que se complete el reinicio.

Agregue la instancia secundaria al clúster de conmutación por error

A continuación, agrega la instancia secundaria ( node-3 ) al clúster de conmutación por error de Windows:

1. Conéctese a las instancias node-1 o node-2 mediante RDP e inicie sesión como usuario administrador.

2. Abra una ventana de PowerShell como usuario administrador y configure variables para el entorno del clúster en este tutorial:

   $node3 = "node-3"
   $nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
   

   Reemplace SQLSRV_CLUSTER con el nombre del clúster de SQL Server.

3. Agregue la instancia secundaria al clúster:

   Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
   

   Este comando puede tardar un poco en ejecutarse. Debido a que el proceso puede dejar de responder y no regresar automáticamente, presione Enter ocasionalmente.

4. En el nodo, habilite la característica de alta disponibilidad AlwaysOn:

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

El nodo ahora forma parte del clúster de conmutación por error.

Agregar la instancia secundaria al grupo de disponibilidad existente

A continuación, agregue la instancia de SQL Server (la instancia secundaria) y la base de datos al grupo de disponibilidad:

1. Conéctese al node-3 mediante Escritorio remoto . Inicie sesión con su cuenta de usuario de dominio.

2. Abra el Administrador de configuración de SQL Server .

3. En el panel de navegación, seleccione Servicios de SQL Server

4. En la lista de servicios, haga clic derecho en SQL Server (MSSQLSERVER) y seleccione Propiedades .

5. En Iniciar sesión como , cambie la cuenta:

   • Nombre de cuenta : DOMAIN \sql_server donde DOMAIN es el nombre NetBIOS de su dominio de Active Directory.
   • Contraseña : Ingrese la contraseña que eligió previamente para la cuenta del dominio sql_server.

6. Haga clic en Aceptar .

7. Cuando se le solicite reiniciar SQL Server, seleccione Sí .

8. En cualquiera de los tres nodos de instancia, node-1 , node-2 o node-3 , abra Microsoft SQL Server Management Studio y conéctese a la instancia principal: node-1 .

   1. Vaya al Explorador de objetos.
   2. Seleccione la lista desplegable Conectar .
   3. Seleccione Motor de base de datos .
   4. En la lista desplegable Nombre del servidor , seleccione node-1 . Si el clúster no aparece en la lista, ingréselo en el campo.

9. Haga clic en Nueva consulta .

10. Pegue el siguiente comando para agregar una dirección IP al escucha que se utiliza para el nodo y luego haga clic en Ejecutar :

    ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
    

    Reemplace LOAD_BALANCER_IP_ADDRESS con la dirección IP del equilibrador de carga en la región us-east1 .

11. En el Explorador de objetos, expanda el nodo Alta disponibilidad AlwaysOn y luego expanda el nodo Grupos de disponibilidad .

12. Haga clic con el botón derecho en el grupo de disponibilidad denominado bookshelf-ag y luego seleccione Agregar réplica .

13. En la página Introducción , haga clic en el nodo Alta disponibilidad AlwaysOn y luego haga clic en el nodo Grupos de disponibilidad .

14. En la página Conectar a réplicas , haga clic en Conectar para conectarse al node-2 de réplica secundaria existente.

15. En la página Especificar réplicas , haga clic en Agregar réplica y luego agregue el nuevo nodo node-3 . No seleccione Conmutación por error automática porque la conmutación por error automática provoca una confirmación sincrónica. Una configuración de este tipo trasciende las fronteras regionales, lo cual no recomendamos.

16. En la página Seleccionar sincronización de datos , seleccione Siembra automática .

    Como no hay ningún escucha, la página de Validación genera una advertencia que puede ignorar.

17. Complete los pasos del asistente.

El modo de conmutación por error para node-1 y node-2 es automático, mientras que para node-3 es manual. Esta diferencia es una forma de distinguir la alta disponibilidad de la recuperación ante desastres.

El grupo de disponibilidad ya está listo. Configuró dos nodos para alta disponibilidad y un tercer nodo para recuperación ante desastres.

Simulando una recuperación ante desastres

En esta sección, probará la arquitectura de recuperación ante desastres para este tutorial y considerará implementaciones de DR opcionales.

Simule una interrupción y ejecute una conmutación por error de DR

1. Simule una falla o interrupción en la región primaria:

   1. En Microsoft SQL Server Management Studio en node-1 , conéctese al node-1 .

   2. Crea una tabla. Después de agregar réplicas en pasos posteriores, verifica que la réplica funcione comprobando si esta tabla está presente.

      USE bookshelf
      GO
      CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
      GO
      

   3. En Cloud Shell, apague ambos servidores en la región principal us-central1 :

      gcloud compute instances stop node-2 --zone us-central1-b --quiet
      gcloud compute instances stop node-1 --zone us-central1-a --quiet
      

2. En Microsoft SQL Server Management Studio en node-3 , conéctese al node-3 .

3. Ejecute una conmutación por error y establezca el modo de disponibilidad en confirmación síncrona. Es necesario forzar una conmutación por error porque el nodo está en modo de confirmación asincrónica.

   ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [bookshelf-ag]
   MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   Puede reanudar el procesamiento; node-3 es ahora la instancia principal.

4. (Opcional) Cree una nueva tabla en node-3 . Después de sincronizar las réplicas con el nuevo primario, verifique si esta tabla está replicada en las réplicas.

   USE bookshelf
   GO
   CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
   GO
   

Aunque node-3 es el principal en este momento, es posible que desee volver a la región original o configurar una nueva instancia secundaria y una instancia en espera para volver a crear una arquitectura de recuperación ante desastres completa. La siguiente sección analiza estas opciones.

(Opcional) Recree una arquitectura de recuperación ante desastres que replique completamente las transacciones

Este caso de uso aborda una falla en la que todas las transacciones se replican desde la base de datos principal a la secundaria antes de que falle la principal. En este escenario ideal, no se pierden datos; el estado del secundario es consistente con el primario en el punto de falla.

En este escenario, puede recrear una arquitectura de recuperación ante desastres completa de dos maneras:

• Vuelva al primario original y al modo de espera original (si están disponibles).
• Cree un nuevo modo de espera y un secundario para node-3 en caso de que el principal y el modo de espera originales no estén disponibles.

Método 1: volver al estado primario y al modo de espera originales

1. En Cloud Shell, inicie el sistema primario y en espera original (antiguo):

   gcloud compute instances start node-1 --zone us-central1-a --quiet
   gcloud compute instances start node-2 --zone us-central1-b --quiet
   

2. En Microsoft SQL Server Management Studio, vuelva a agregar node-1 y node-2 como réplicas secundarias:

   1. En node-3 , agregue los dos servidores en modo de confirmación asincrónica:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. En node-1 , comience a sincronizar las bases de datos nuevamente:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

   3. En node-2 , comience a sincronizar las bases de datos nuevamente:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

3. Haga que node-1 sea el principal nuevamente:

   1. En node-3 , cambie el modo de disponibilidad del node-1 a confirmación síncrona. El node-1 vuelve a ser el principal.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. En node-1 , cambie node-1 para que sea el principal y los otros dos nodos para que sean los secundarios:

      USE [master]
      GO
      -- Node 1 becomes primary
      ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

Una vez que todos los comandos se ejecutan correctamente, node-1 es el principal y los demás nodos son secundarios, como se muestra en el siguiente diagrama.

Método 2: configurar un nuevo primario y uno de reserva

Es posible que no pueda recuperar las instancias primaria y en espera originales del error, que tarde demasiado en recuperarlas o que la región sea inaccesible. Un enfoque es mantener node-3 como principal y luego crear una nueva instancia en espera y una nueva instancia secundaria, como se muestra en el siguiente diagrama.

Figura 5. Recuperación ante desastres con la región primaria original R1 no disponible.

Esta implementación requiere que haga lo siguiente:

• Mantenga node-3 como principal en us-east1 .

• Agregue una nueva instancia en espera ( node-4 ) en una zona diferente en us-east1 . Este paso establece la nueva implementación como de alta disponibilidad.

• Cree una nueva instancia secundaria ( node-5 ) en una región separada, por ejemplo, us-west2 . Este paso configura la nueva implementación para la recuperación ante desastres. El despliegue general ya está completo. La arquitectura de la base de datos es totalmente compatible con HA y DR.

(Opcional) Ejecutar un respaldo cuando falten transacciones

Una falla no ideal se produce cuando una o más transacciones confirmadas en el primario no se replican en el secundario en el momento del fallo (también conocido como fallo grave ). En una conmutación por error, se pierden todas las transacciones confirmadas que no se replican.

Para probar los pasos de conmutación por error para este escenario, debe generar un error grave. El mejor enfoque para generar una falla grave es el siguiente:

• Cambie la red para que no haya conectividad entre las instancias primaria y secundaria.
• Cambie el principal de alguna manera; por ejemplo, agregue una tabla o inserte algunos datos.
• Realice el proceso de conmutación por error como se describió anteriormente para que el secundario se convierta en el nuevo primario.

Los pasos para el proceso de conmutación por error son idénticos al escenario ideal , excepto que la tabla agregada al primario después de que se interrumpe la conectividad de la red no es visible en el secundario.

Su única opción para solucionar un error grave es eliminar las réplicas ( node-1 y node-2 ) del grupo de disponibilidad y sincronizar las réplicas nuevamente. La sincronización cambia su estado para que coincida con el secundario. Cualquier transacción que no se haya replicado antes del error se pierde.

Para agregar node-1 como instancia secundaria, puede seguir los mismos pasos para agregar node-3 anteriormente (consulte Agregar la instancia secundaria al clúster de conmutación por error anteriormente) con la siguiente diferencia: node-3 ahora es el principal, no node-1 . Debe reemplazar cualquier instancia del node-3 con el nombre del servidor que agregue al grupo de disponibilidad. Si reutiliza la misma máquina virtual ( node-1 y node-2 ), no necesita agregar el servidor al clúster de conmutación por error de Windows Server; Solo agregue la instancia de SQL Server nuevamente al grupo de disponibilidad.

En este punto, node-3 es el primario y node-1 y node-2 son secundarios. Ahora es posible volver al node-1 , hacer que node-2 sea el de reserva y node-3 el secundario. El sistema ahora tiene el mismo estado que tenía antes del fallo.

Conmutación por error automática

La conmutación automática por error a una instancia secundaria como principal puede crear problemas. Una vez que el primario original vuelve a estar disponible, puede ocurrir una situación de cerebro dividido si algunos clientes acceden al secundario mientras que otros escriben en el primario restaurado. En este caso, la primaria y la secundaria posiblemente se actualicen en paralelo y sus estados diverjan. Para evitar esta situación, este tutorial proporciona instrucciones para una conmutación por error manual en la que usted decide si (o cuándo) realizar la conmutación por error.

Si implementa una conmutación por error automática, debe asegurarse de que solo una de las instancias configuradas sea la principal y pueda modificarse. Cualquier instancia secundaria o en espera no debe proporcionar acceso de escritura a ningún cliente (excepto al principal para la replicación del estado). Además, debe evitar una cadena rápida de conmutaciones por error posteriores en poco tiempo. Por ejemplo, una conmutación por error cada cinco minutos no sería una estrategia confiable de recuperación ante desastres. Para los procesos de conmutación por error automatizados, puede incorporar protecciones contra escenarios problemáticos como estos e incluso involucrar a un administrador de base de datos para decisiones complejas, si es necesario.

Arquitectura de implementación alternativa

Este tutorial configura una arquitectura de recuperación ante desastres con una instancia secundaria que se convierte en la instancia principal en una conmutación por error, como se muestra en el siguiente diagrama.

Figura 6. Arquitectura estándar de recuperación ante desastres utilizando Microsoft SQL Server.

Esto significa que, en caso de una conmutación por error, la implementación resultante tiene una única instancia hasta que sea posible un respaldo o hasta que configure una instancia en espera (para HA) y una secundaria (para DR).

Una arquitectura de implementación alternativa consiste en configurar dos instancias secundarias. Ambas instancias son réplicas de la primaria. Si se produce una conmutación por error, puede reconfigurar uno de los secundarios como modo de espera. Los siguientes diagramas muestran la arquitectura de implementación antes y después de una conmutación por error.

Figura 7. Arquitectura estándar de recuperación ante desastres con dos instancias secundarias.

Figura 8. Arquitectura estándar de recuperación ante desastres con dos instancias secundarias después de la conmutación por error.

Si bien aún debe convertir uno de los dos secundarios en modo de espera (Figura 8), este proceso es mucho más rápido que crear y configurar un nuevo modo de espera desde cero.

También puede abordar la DR con una configuración análoga a esta arquitectura de uso de dos instancias secundarias. Además de tener dos secundarios en una segunda región (Figura 7), puede implementar otros dos secundarios en una tercera región. Esta configuración le permite crear de manera eficiente una arquitectura de implementación habilitada para HA y DR después de una falla en la región principal.