Share via

Configuración del vínculo con scripts: Azure SQL Managed Instance

  • Artículo

Se aplica a:Azure SQL Managed Instance

En este artículo se explica cómo configurar un vínculo entre SQL Server y Azure SQL Managed Instance con scripts de Transact-SQL y PowerShell o la CLI de Azure. Con el vínculo, las bases de datos de la réplica principal inicial se replican en la réplica secundaria casi en tiempo real.

Una vez creado el vínculo, puede conmutar por error a la réplica secundaria para la migración o la recuperación ante desastres.

Nota:

Información general

Use la característica de vínculo para replicar bases de datos de la réplica principal inicial a la réplica secundaria. Para SQL Server 2022, la principal inicial puede ser SQL Server o Azure SQL Managed Instance. Para SQL Server 2019 y versiones anteriores, la principal inicial debe ser SQL Server. Una vez configurado el vínculo, las bases de datos de la réplica principal inicial se replican en la réplica secundaria.

Puede dejar el vínculo en su lugar para la replicación continua de datos en un entorno híbrido entre la réplica principal y secundaria, o bien puede conmutar por error la base de datos a la réplica secundaria, migrar a Azure o para la recuperación ante desastres. Para SQL Server 2019 y versiones anteriores, la conmutación por error a Azure SQL Managed Instance interrumpe el vínculo y no se admite la conmutación por recuperación. Con SQL Server 2022, tiene la opción de mantener el vínculo y la conmutación por recuperación entre las dos réplicas: esta característica está actualmente en versión preliminar.

Si tiene previsto usar la instancia administrada secundaria solo para la recuperación ante desastres, puede ahorrar en los costos de licencia activando la ventaja de conmutación por error híbrida.

Siga las instrucciones de este artículo para configurar manualmente el vínculo entre SQL Server y Azure SQL Managed Instance. Una vez creado el enlace, su base de datos de origen obtiene una copia de solo lectura en su réplica secundaria de destino.

Sugerencia

  • Para simplificar el uso de scripts de T-SQL con los parámetros correctos para su entorno, se recomienda encarecidamente usar el Asistente para vínculos de Instancia administrada en SQL Server Management Studio (SSMS) para generar un script para crear el vínculo. En la página Resumen de la ventana Nuevo vínculo de instancia administrada, seleccione Script en lugar de Finalizar.

Requisitos previos

Nota:

Algunas funciones del vínculo están disponibles con carácter general, mientras que otras están actualmente en versión preliminar. Revise la compatibilidad de versiones para obtener más información.

Para replicar las bases de datos, necesita los siguientes requisitos previos:

Tenga en cuenta lo siguiente.

  • La característica de vínculo admite una base de datos por vínculo. Para replicar varias bases de datos en una instancia, cree un vínculo para cada base de datos individual. Por ejemplo, para replicar 10 bases de datos en SQL Managed Instance, cree 10 vínculos individuales.
  • La intercalación en SQL Server y SQL Managed Instance debe ser la misma. Una falta de coincidencia en la intercalación podría provocar una discrepancia en el uso de mayúsculas y minúsculas del nombre del servidor e impedir una conexión correcta de SQL Server a SQL Managed Instance.
  • El error 1475 en su principal inicial de SQL Server indica que necesita iniciar una nueva cadena de copias de seguridad creando una copia de seguridad completa sin la opción COPY ONLY.
  • Para establecer un vínculo, o conmutar por error, desde SQL Managed Instance a SQL Server 2022, la instancia administrada debe configurarse con la directiva de actualización de SQL Server 2022. La replicación de datos y la migración tras error de SQL Managed Instance a SQL Server 2022 no son compatibles con instancias configuradas con la directiva de actualización siempre actualizada.
  • Aunque puede establecer un vínculo de SQL Server 2022 a una SQL Managed Instance configurada con la directiva de actualización siempre actualizada, después de conmutar por error a SQL Managed Instance, ya no podrá replicar datos ni conmutar por recuperación a SQL Server 2022.

Permisos

Para SQL Server, debe tener permisos sysadmin.

Para Azure SQL Managed Instance, debe ser miembro del Colaborador de SQL Managed Instance o tener los siguientes permisos para un rol personalizado:

Microsoft.Sql/ resource Permisos necesarios
Microsoft.Sql/managedInstances /lectura, /escritura
Microsoft.Sql/managedInstances/hybridCertificate /action
Microsoft.Sql/managedInstances/databases /read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /lectura
Microsoft.Sql/managedInstances/hybridLink /lectura, /escritura, /eliminación
Microsoft.Sql/managedInstances/serverTrustCertificates /escritura, /eliminación, /lectura

Terminología y convenciones de nomenclatura

Al ejecutar los scripts de esta guía de usuario, es importante no confundir los nombres de SQL Server y SQL Managed Instance con los nombres de dominio completos (FQDN). En la tabla siguiente, se explica qué representan exactamente los distintos nombres y cómo obtener sus valores:

Terminología Descripción Cómo averiguarlo
Principal inicial 1 SQL Server o SQL Managed Instance donde se crea inicialmente el vínculo para replicar la base de datos en la réplica secundaria.
Réplica principal SQL Server o SQL Managed Instance que hospeda actualmente la base de datos principal.
Réplica secundaria SQL Server o SQL Managed Instance que recibe datos replicados casi en tiempo real de la réplica principal actual.
Nombre de servidor SQL Nombre corto y de una sola palabra de la instancia de SQL Server. Por ejemplo, sqlserver1. Ejecute SELECT @@SERVERNAME desde T-SQL.
FQDN de SQL Server Nombre de dominio completo (FQDN) de la instancia de SQL Server. Por ejemplo, sqlserver1.domain.com. Consulte la configuración de red (DNS) local o el nombre del servidor si usa una máquina virtual de Azure.
Nombre de la Instancia administrada de SQL Nombre corto y de una sola palabra de la instancia de SQL Managed Instance. Por ejemplo, managedinstance1. Consulte el nombre de la instancia administrada en Azure Portal.
FQDN de SQL Managed Instance Nombre de dominio completo (FQDN) de la instancia SQL Managed Instance. Por ejemplo, managedinstance1.6d710bcf372b.database.windows.net. Consulte el nombre de host en la página de información general de SQL Managed Instance de Azure Portal.
Nombre de dominio que se puede resolver Nombre DNS que se puede resolver en una dirección IP. Por ejemplo, al ejecutar nslookup sqlserver1.domain.com se debería devolver una dirección IP como 10.0.0.1. Ejecute el comando nslookup desde el símbolo del sistema.
Dirección IP de SQL Server Dirección IP de la instancia de SQL Server. En el caso de varias direcciones IP en SQL Server, elija la dirección IP a la que se pueda acceder desde Azure. Ejecute el comando ipconfig desde el símbolo del sistema del sistema operativo host que ejecuta SQL Server.

1 La configuración de Azure SQL Managed Instance como la principal inicial se encuentra actualmente en versión preliminar y solo se admite a partir de SQL Server 2022 CU10.

Configuración de la recuperación y copia de seguridad de las bases de datos

Si SQL Server es su principal inicial, las bases de datos que se replicarán a través del vínculo deben estar en el modelo de recuperación completa y tener al menos una copia de seguridad. Dado que Azure SQL Managed Instance realiza copias de seguridad automáticamente, omita este paso si SQL Managed Instance es el principal inicial. primary

Ejecute el código siguiente en SQL Server para todas las bases de datos que quiera replicar. Reemplace <DatabaseName> por el nombre real de la base de datos.

-- Run on SQL Server
-- Set full recovery model for all databases you want to replicate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to replicate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Para obtener más información, consulte Crear una copia de seguridad completa de base de datos.

Nota:

El vínculo solo admite replicar las bases de datos de usuario. No se admite replicar las bases de datos del sistema. Para replicar los objetos de nivel de instancia (almacenados en la base de datos master o msdb), se recomienda generar scripts y ejecutar scripts de T-SQL en la instancia de destino.

Establecimiento de la confianza entre instancias

En primer lugar, debe establecer la confianza entre las dos instancias y asegurar los puntos finales utilizados para comunicar y cifrar los datos a través de la red. Los grupos de disponibilidad distribuidos usan el punto de conexión de creación de reflejo de la base de datos del grupo de disponibilidad existente, en lugar de tener su propio punto de conexión dedicado. Por eso, se deben configurar la seguridad y la confianza entre las dos instancias mediante el punto de conexión de creación de reflejo de la base de datos del grupo de disponibilidad.

Nota:

El vínculo se basa en la tecnología de los grupos de disponibilidad Always On. El punto de conexión de creación de reflejo de la base de datos es un punto de conexión especial que los grupos de disponibilidad utilizan exclusivamente para recibir conexiones procedentes de otras instancias. El término punto de conexión de creación de reflejo de la base de datos no debe confundirse con característica heredada de creación de reflejo de la base de datos de SQL Server.

La confianza basada en certificados es la única manera admitida de proteger los puntos de conexión de creación de reflejo de la base de datos para SQL Server y SQL Managed Instance. Si tiene grupos de disponibilidad existentes que usan la autenticación de Windows, debe agregar confianza basada en certificados al punto de conexión de creación de reflejo existente como opción de autenticación secundaria. Puede hacerlo mediante la instrucción ALTER ENDPOINT, como se muestra más adelante en este artículo.

Importante

Los certificados se generan con una fecha y hora de expiración. Se deben renovar y rotar antes de que expiren.

A continuación se muestra un resumen del proceso para asegurar los puntos de conexión de duplicación de bases de datos tanto para SQL Server como para SQL Managed Instance:

  1. Genere un certificado en SQL Server y obtenga su clave pública.
  2. Obtenga la clave pública del certificado de SQL Managed Instance.
  3. Intercambie las claves públicas entre SQL Server y SQL Managed Instance.
  4. Importación de claves de entidad de certificación raíz de confianza de Azure en SQL Server

En las secciones siguientes se describen los pasos de este flujo.

Creación de un certificado en SQL Server e importación de su clave pública en SQL Managed Instance

Primero, cree una clave maestra de base de datos en la base de datos master, si aún no está presente. Inserte la contraseña en lugar de <strong_password> en el script siguiente y manténgala en un lugar confidencial y seguro. Ejecute este script de T-SQL en SQL Server:

-- Run on SQL Server
-- Create a master key encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

A continuación, genere un certificado de autenticación en SQL Server. En el script siguiente, reemplace:

  • @cert_expiry_date por la fecha de expiración del certificado deseada (fecha en el futuro).

Registre esta fecha y establezca un aviso para rotar (actualizar) el certificado de servidor SQL antes de su fecha de expiración para garantizar el funcionamiento continuo del vínculo.

Importante

Se recomienda encarecidamente usar el nombre de certificado generado automáticamente a partir de este script. Aunque se permite personalizar su propio nombre de certificado en SQL Server, este nombre no debe contener caracteres \.

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

A continuación, use la siguiente consulta T-SQL en SQL Server para comprobar que se ha creado el certificado.

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

En los resultados de la consulta, verá que el certificado se ha cifrado con la clave maestra.

Ahora, puede obtener la clave pública del certificado generado en SQL Server:

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

Guarde los valores de SQLServerCertName y SQLServerPublicKey de la salida, porque los necesitará para el siguiente paso, cuando importe el certificado.

En primer lugar, asegúrese de que ha iniciado sesión en Azure y de que ha seleccionado la suscripción donde se hospeda la instancia administrada. La selección de la suscripción adecuada es especialmente importante si tiene más de una suscripción de Azure en su cuenta.

Reemplace <SubscriptionID> con la identificación de su suscripción de Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

A continuación, use el comando New-AzSqlInstanceServerTrustCertificate de PowerShell o az sql mi partner-cert create de la CLI de Azure para cargar la clave pública del certificado de autenticación de SQL Server a Azure, como el siguiente ejemplo de PowerShell.

Rellene la información sobre el usuario necesaria, cópiela, péguela y, después, ejecute el script. Sustituya:

  • <SQLServerPublicKey> por la parte pública del certificado de SQL Server en formato binario que registró en el paso anterior. Es un valor de cadena largo que comienza por 0x.
  • <SQLServerCertName> con el nombre de certificado de servidor de SQL que registró en el paso anterior.
  • <ManagedInstanceName> por el nombre corto de la instancia administrada.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded

El resultado de esta operación será un resumen del certificado de servidor de SQL cargado en Azure.

En caso de que necesite ver todos los certificados de SQL Server cargados en una instancia administrada, use el comando Get-AzSqlInstanceServerTrustCertificate de PowerShell o az sql mi partner-cert list de la CLI de Azure en Azure Cloud Shell. Para eliminar el certificado de SQL Server cargado en una instancia administrada de SQL, use el comando Remove-AzSqlInstanceServerTrustCertificate de PowerShell o el comando az sql mi partner-cert delete de la CLI de Azure en Azure Cloud Shell.

Obtención de la clave pública del certificado de SQL Managed Instance y su importación en SQL Server

El certificado para proteger el punto de conexión de vínculo se genera automáticamente en Azure SQL Managed Instance. Obtenga la clave pública del certificado de SQL Managed Instance e impórtela en SQL Server mediante el comando Get-AzSqlInstanceEndpointCertificate sw PowerShell o az sql mi endpoint-cert show de la CLI de Azure, como el siguiente ejemplo de PowerShell.

Precaución

Al usar la CLI de Azure, deberá agregar 0x manualmente al principio de la salida de PublicKey cuando lo use en los pasos posteriores. Por ejemplo, PublicKey tendrá un aspecto similar a "0x3082033E30...".

Ejecute el siguiente script. Sustituya:

  • <SubscriptionID> por el identificador de su suscripción de Azure.
  • <ManagedInstanceName> por el nombre corto de la instancia administrada.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string

Copie toda la salida de PublicKey (empieza por 0x), ya que la necesitará en el paso siguiente.

Como alternativa, si tiene problemas para copiar y pegar PublicKey, también puede ejecutar el comando EXEC sp_get_endpoint_certificate 4 de T-SQL en la instancia administrada para obtener su clave pública para el punto de conexión de vínculo.

A continuación, importe la clave pública obtenida del certificado de seguridad de la instancia administrada en SQL Server. Ejecute la consulta siguiente en SQL Server. Sustituya:

  • <ManagedInstanceFQDN> por el nombre de dominio completo de la instancia administrada.
  • <PublicKey> por el valor de PublicKey obtenido en el paso anterior (desde Azure Cloud Shell, empieza por 0x). No es necesario usar comillas.

Importante

El nombre del certificado debe ser FQDN de SQL Managed Instance y no debe modificarse. El vínculo no estará operativo si usa un nombre personalizado.

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey>

Importación de claves de entidad de certificación raíz de confianza de Azure en SQL Server

La importación de claves de certificado raíz públicas de entidades de certificación (CA) de Microsoft y DigiCert en SQL Server es necesaria para que la instancia de SQL Server confíe en los certificados emitidos por Azure para dominios database.windows.net.

Precaución

Asegúrese de que PublicKey comienza por 0x. Es posible que tenga que agregarlo manualmente al principio de PublicKey si aún no está allí.

En primer lugar, importe el certificado de entidad de certificación raíz de PKI de Microsoft en SQL Server:

-- Run on SQL Server
-- Import Microsoft PKI root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'MicrosoftPKI')
BEGIN
    PRINT 'Creating MicrosoftPKI certificate.'
    CREATE CERTIFICATE [MicrosoftPKI] FROM BINARY = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3

    --Trust certificates issued by Microsoft PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('MicrosoftPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate MicrosoftPKI already exsits.'
GO

A continuación, importe el certificado de entidad de certificación raíz de PKI de DigiCert en SQL Server:

-- Run on SQL Server
-- Import DigiCert PKI root-authority certificate trusted by Azure to SQL Server, if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'DigiCertPKI')
BEGIN
    PRINT 'Creating DigiCertPKI certificate.'
    CREATE CERTIFICATE [DigiCertPKI] FROM BINARY = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D0

    --Trust certificates issued by DigiCert PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('DigiCertPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate DigiCertPKI already exsits.'
GO

Por último, compruebe todos los certificados creados mediante la siguiente vista de administración dinámica (DMV):

-- Run on SQL Server
SELECT * FROM sys.certificates

Protección del punto de conexión de creación de reflejo de la base de datos

Si no tiene un grupo de disponibilidad existente ni un punto de conexión de creación de reflejo de la base de datos en SQL Server, el siguiente paso es crear un punto de conexión de creación de reflejo en SQL Server y protegerlo con el certificado de SQL Server generado anteriormente. Si ya tiene un grupo de disponibilidad o un punto de conexión de réplica, pase a la sección Modificar un punto de conexión existente.

Creación y protección del punto de conexión de creación de reflejo de la base de datos en SQL Server

Para comprobar que no tiene un punto de conexión de creación de reflejo de la base de datos existente creado, use el siguiente script:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

Si la consulta anterior no muestra un punto de conexión de creación de reflejo de la base de datos existente, ejecute el siguiente script en SQL Server para obtener el nombre del certificado de SQL Server generado anteriormente.

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

Guarde el valor de SQLServerCertName de la salida, ya que lo necesitará en el siguiente paso.

Use el siguiente script para crear un nuevo punto de conexión de creación de reflejo de la base de datos en el puerto 5022 y proteger el punto de conexión con el certificado de SQL Server. Sustituya:

  • <SQL_SERVER_CERTIFICATE> por el nombre de SQLServerCertName obtenido en el paso anterior.
-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

Valide que se haya creado el punto de conexión de creación de reflejo mediante la ejecución del siguiente script en SQL Server:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

La columna state_desc de un punto de conexión creado correctamente debería indicar STARTED.

Se ha creado un nuevo punto de conexión de creación de reflejo con la autenticación de certificado y el cifrado AES habilitado.

Modificación de un punto de conexión existente

Nota

Omita este paso si acaba de crear un nuevo punto de conexión de creación de reflejo. Utilice este paso solo si usa grupos de disponibilidad existentes con un punto de conexión de creación de reflejo de la base de datos existente.

Si usa grupos de disponibilidad existentes para el vínculo o si hay un punto de conexión de creación de reflejo de la base de datos existente, compruebe primero que cumpla las siguientes condiciones obligatorias para el vínculo:

  • El tipo debe ser DATABASE_MIRRORING.
  • La autenticación de conexión debe ser CERTIFICATE.
  • El cifrado debe habilitarse.
  • El algoritmo de cifrado debe ser AES.

Ejecute la siguiente consulta en SQL Server para ver los detalles de un punto de conexión de creación de reflejo de la base de datos existente:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Si la salida muestra que el valor de connection_auth_desc del punto de conexión DATABASE_MIRRORING existente no es CERTIFICATE o el valor de encryption_algorthm_desc no es AES, el punto de conexión se debe modificar para cumplir los requisitos.

En SQL Server, se usa el mismo punto de conexión de creación de reflejo de la base de datos para los grupos de disponibilidad y los grupos de disponibilidad distribuidos. Si el valor de connection_auth_desc del punto de conexión es NTLM (autenticación de Windows) o KERBEROS, y necesita la autenticación de Windows para un grupo de disponibilidad existente, es posible modificar el punto de conexión para usar varios métodos de autenticación cambiando la opción de autenticación a NEGOTIATE CERTIFICATE. Este cambio permite que el grupo de disponibilidad existente use la autenticación de Windows, mientras se usa la autenticación de certificados para SQL Managed Instance.

Del mismo modo, si el cifrado no incluye AES y necesita el cifrado RC4, es posible modificar el punto de conexión para usar ambos algoritmos. Para más información sobre las posibles opciones para modificar los puntos de conexión, consulte la página de documentación de sys.database_mirroring_endpoints.

El siguiente script es un ejemplo de cómo modificar el punto de conexión de creación de reflejo de la base de datos existente en SQL Server. Sustituya:

  • <YourExistingEndpointName> por el nombre del punto de conexión existente.
  • <SQLServerCertName> por el nombre del certificado de SQL Server generado (obtenido en uno de los pasos anteriores).

En función de la configuración específica, es posible que tenga que personalizar aún más el script. También puede usar SELECT * FROM sys.certificates para obtener el nombre del certificado creado en SQL Server.

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

Después de ejecutar la consulta ALTER en el punto de conexión y establecer el modo de autenticación dual en Windows y certificado, use de nuevo esta consulta en SQL Server para mostrar los detalles del punto de conexión de creación de reflejo de la base de datos:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Ha modificado correctamente el punto de conexión de creación de reflejo de la base de datos del vínculo de SQL Managed Instance.

Creación de un grupo de disponibilidad en SQL Server

Si no dispone de un grupo de disponibilidad, el siguiente paso es crear uno en SQL Server, independientemente de cuál vaya a ser el principal inicial. Los comandos para crear el grupo de disponibilidad son diferentes si SQL Managed Instance es la principal inicial, que solo se admite a partir de SQL Server 2022 CU10.

Aunque es posible establecer varios vínculos para la misma base de datos, el vínculo solo admite la replicación de una base de datos por vínculo. Si desea crear varios vínculos para la misma base de datos, use el mismo grupo de disponibilidad para todos los vínculos, pero cree un nuevo grupo de disponibilidad distribuido para cada vínculo de base de datos entre SQL Server y SQL Managed Instance.

Si SQL Server es la principal inicial, cree un grupo de disponibilidad con los parámetros siguientes para un vínculo:

  • Nombre inicial del servidor principal
  • Nombre de la base de datos
  • Modo de conmutación por error MANUAL
  • Modo de inicialización AUTOMATIC

En primer lugar, averigüe el nombre de la instancia de SQL Server mediante la ejecución de la siguiente instrucción T-SQL:

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName

A continuación, use el siguiente script para crear el grupo de disponibilidad en SQL Server. Sustituya:

  • <AGName> por el nombre del grupo de disponibilidad. El vínculo de Managed Instance requiere una base de datos por cada grupo de disponibilidad. Para varias bases de datos, deberá crear varios grupos de disponibilidad. Considere la posibilidad de asignar un nombre a cada grupo de disponibilidad para que su nombre refleje la base de datos correspondiente, por ejemplo, AG_<db_name>.
  • Sustituya <DatabaseName> por el nombre de la base de datos que desea replicar.
  • <SQLServerName> por el nombre de la instancia de SQL Server obtenido en el paso anterior.
  • Sustituya <SQLServerIP> por la dirección IP de SQL Server. Como alternativa, se puede usar el nombre del equipo host de SQL Server, pero debe asegurarse de que el nombre se pueda resolver desde la red virtual de SQL Managed Instance.
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

Importante

Para SQL Server 2016, elimine WITH (CLUSTER_TYPE = NONE) de la instrucción T-SQL anterior. Déjelo tal y como está para todas las versiones posteriores de SQL Server.

A continuación, cree un grupo de disponibilidad distribuido en SQL Server. Si tiene previsto crear varios vínculos, debe crear un grupo de disponibilidad distribuido para cada vínculo, incluso si va a establecer varios vínculos para la misma base de datos.

Reemplace los valores siguientes y, a continuación, ejecute el script T-SQL para crear el grupo de disponibilidad distribuido.

  • <DAGName> por el nombre del grupo de disponibilidad distribuido. Puesto que puede configurar varios vínculos para la misma base de datos mediante la creación de un grupo de disponibilidad distribuido para cada vínculo, considere la posibilidad de asignar un nombre a cada grupo de disponibilidad distribuido en consecuencia: por ejemplo, DAG1_<db_name>, DAG2_<db_name>.
  • <AGName> por el nombre del grupo de disponibilidad creado en el paso anterior.
  • <SQLServerIP> por la dirección IP de SQL Server del paso anterior. Como alternativa, puede usar un nombre de la máquina host de SQL Server que se pueda resolver, pero asegúrese de que el nombre se pueda resolver desde la red virtual de SQL Managed Instance (lo cual requiere la configuración personalizada de Azure DNS para la subred de la instancia administrada).
  • <ManagedInstanceName> por el nombre corto de la instancia administrada.
  • <ManagedInstanceFQDN> por el nombre de dominio completo de la instancia administrada.
-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGName>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<ManagedInstanceName>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

Comprobación de los grupos de disponibilidad

Use el siguiente script para enumerar todos los grupos de disponibilidad y los grupos de disponibilidad distribuidos de la instancia de SQL Server. En este momento, el estado del grupo de disponibilidad debe ser connected y el estado de los grupos de disponibilidad distribuidos debe ser disconnected. El estado del grupo de disponibilidad distribuido cambiará a connected solo cuando se haya unido a SQL Managed Instance.

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

Como alternativa, puede usar el Explorador de objetos de SSMS para buscar grupos de disponibilidad y grupos de disponibilidad distribuidos. Expanda la carpeta Alta disponibilidad de AlwaysOn y, a continuación, la carpeta Grupos de disponibilidad.

Por último, puede crear el vínculo. Los comandos difieren en función de la instancia principal inicial. Use el comando New-AzSqlInstanceLink de PowerShell o az sql mi link create de la CLI de Azure para crear el vínculo, como el ejemplo de PowerShell de esta sección. La creación del vínculo desde una instancia de SQL Managed Instance principal no se admite actualmente con la CLI de Azure.

Si necesita ver todos los vínculos en una instancia administrada, use el comando Get-AzSqlInstanceLink de PowerShell o az sql mi link show de la CLI de Azure en Azure Cloud Shell.

Para simplificar el proceso, inicie sesión en Azure Portal y ejecute el siguiente script desde Azure Cloud Shell. Sustituya:

  • <ManagedInstanceName> por el nombre corto de la instancia administrada.
  • <AGName> por el nombre del grupo de disponibilidad creado en SQL Server.
  • <DAGName> por el nombre del grupo de disponibilidad distribuido creado en SQL Server.
  • <DatabaseName> por la base de datos replicada en el grupo de disponibilidad de SQL Server.
  • <SQLServerIP> por la dirección IP de la instancia de SQL Server. La instancia administrada debe poder acceder a la dirección IP proporcionada.
#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# Enter the availability group name that was created on SQL Server
$AGName = "<AGName>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":5022"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGName -SecondaryAvailabilityGroupName $ManagedInstanceName |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

El resultado de esta operación es una marca de tiempo de la ejecución correcta de la solicitud para crear un vínculo.

Para comprobar la conexión entre SQL Managed Instance y SQL Server, ejecute la siguiente consulta en SQL Server. La conexión no será instantánea. La DMV puede tardar hasta un minuto en empezar a mostrar una conexión correcta. Siga actualizando la DMV hasta que la conexión aparezca como CONNECTED para la réplica de SQL Managed Instance.

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

Una vez establecida la conexión, el Explorador de objetos en SSMS podría mostrar inicialmente la base de datos replicada en la réplica secundaria en estado de Restauración, ya que la fase de inicialización mueve y restaura la copia de seguridad completa de la base de datos. Una vez restaurada la base de datos, la replicación tiene que ponerse al día para que las dos bases de datos estén sincronizadas. La base de datos ya no estará en estado Restauración en curso una vez que finalice la inicialización inicial. La inicialización de bases de datos pequeñas podría ser lo suficientemente rápida como para que no vea el estado Restauración en curso inicial en SSMS.

Importante

  • El vínculo no funcionará a menos que exista conectividad de red entre SQL Server y SQL Managed Instance. Para solucionar los problemas de la conectividad de red, siga los pasos descritos en Prueba de la conectividad de red.
  • Haga copias de seguridad periódicas del archivo de registro en SQL Server. Si el espacio de registro usado alcanza el 100 %, la replicación en SQL Managed Instance se detiene hasta que se reduzca el uso de espacio. Se recomienda automatizar las copias de seguridad de registros mediante la configuración de un trabajo diario. Para más información, consulte Realizar copias de seguridad de registros con regularidad.

Detener carga de trabajo

Para conmutar por error la base de datos a la réplica secundaria, detenga primero las cargas de trabajo de la aplicación en la base de datos principal durante las horas de mantenimiento. Esto permite que la replicación de la base de datos se ponga al día en la secundaria o que pueda migrar o conmutar por error a Azure sin pérdida de datos. Aunque la base de datos principal forma parte del grupo de disponibilidad Always On, no se puede establecer en modo de solo lectura. Debe asegurarse de que las aplicaciones no están comprometiendo transacciones en la réplica principal antes de la conmutación por error.

Cambio del modo de replicación

La replicación entre SQL Server y SQL Managed Instance es asincrónica de manera predeterminada. Antes de pasar su base de datos a la secundaria, cambie el vínculo al modo síncrono. La replicación sincrónica a través de grandes distancias de red puede ralentizar las transacciones en la réplica principal.

Cambiar del modo asincrónico al modo sincrónico requiere el cambio del modo de replicación en SQL Managed Instance y SQL Server.

Cambio del modo de replicación (SQL Managed Instance)

Use Azure PowerShell o la CLI de Azure para cambiar el modo de replicación en SQL Managed Instance.

En primer lugar, asegúrese de que ha iniciado sesión en Azure y de que ha seleccionado la suscripción en la que se hospeda la instancia administrada mediante el comando Select-AzSubscription de PowerShell o el comando az account set de la CLI de Azure. La selección de la suscripción adecuada es especialmente importante si tiene más de una suscripción de Azure en su cuenta.

En el siguiente ejemplo de PowerShell, reemplace <SubscriptionID> por el ID de su suscripción a Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Asegúrese de que conoce el nombre del vínculo que desea conmutar por error. Puede usar el comando Get-AzSqlInstanceLink de PowerShell o az sql mi link list de la CLI de Azure.

Utilice el siguiente script de PowerShell para enumerar todos los vínculos activos en SQL Managed Instance. Reemplace <ManagedInstanceName> por el nombre corto de la instancia administrada.

# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO LIST ALL LINKS ON MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# List all links on the specified managed instance
Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName

En la salida del script anterior, registre la propiedad Name del vínculo que desea conmutar por error.

A continuación, cambie el modo de replicación de async para sincronizar en SQL Managed Instance para el vínculo identificado mediante el comando Update-AzSqlInstanceLink de PowerShell o az sql mi link update de la CLI de Azure.

En el siguiente ejemplo de PowerShell, sustituya:

  • <ManagedInstanceName> por el nombre corto de la instancia administrada.
  • <DAGName> con el nombre del vínculo que ha encontrado en el paso anterior (la propiedad Name del paso anterior).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO SWITCH LINK REPLICATION MODE (ASYNC\SYNC)
# ===== Enter user variables here ====

# Enter the link name 
$LinkName = "<DAGName>"  

# Enter your managed instance name – for example, "sqlmi1" 
$ManagedInstanceName = "<ManagedInstanceName>" 

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Update replication mode of the specified link
Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName |
-Name $LinkName -ReplicationMode "Sync"

El comando anterior indica que se ha realizado correctamente mostrando el resumen de la operación, con la propiedad ReplicationMode que se muestra como Sync.

En caso de que necesite revertir esta operación, ejecute el script anterior para cambiar el modo de replicación, reemplazando la cadena Sync de -ReplicationMode por Async.

Cambio del modo de replicación (SQL Server)

Use el siguiente script de T-SQL en SQL Server para cambiar el modo de replicación del grupo de disponibilidad distribuido en SQL Server de async a sync. Reemplace:

  • <DAGName> por el nombre del grupo de disponibilidad distribuido (que se ha usado para crear el vínculo).
  • <AGName> por el nombre del grupo de disponibilidad creado en SQL Server (que se ha usado para crear el vínculo).
  • <ManagedInstanceName> por el nombre de la instancia administrada.
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

Para confirmar que ha cambiado correctamente el modo de replicación del vínculo, use la siguiente vista de administración dinámica. Los resultados indican el estado SYNCHRONOUS_COMIT.

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

Ahora que ha cambiado tanto SQL Managed Instance como SQL Server al modo de sincronización, la replicación entre las dos instancias es sincrónica. Si necesita revertir este estado, siga los mismos pasos y establezca el estado async tanto para SQL Server como para SQL Managed Instance.

Comprobación de los valores LSN en SQL Server y SQL Managed Instance

Para completar la conmutación por error o la migración, confirme que la replicación ha finalizado. Para ello, debe asegurarse de que los LSN (números de secuencia de registro) en las entradas de registro para SQL Server y SQL Managed Instance sean iguales.

Inicialmente, se espera que el LSN en la base de datos principal sea mayor que el LSN en la base de datos secundaria. La latencia de red podría provocar que la replicación se retrasase un poco detrás de la principal. Dado que la carga de trabajo se ha detenido en la principal, debe esperar un tiempo a que los números de secuencia de registro coincidan y dejen de cambiar.

Use la siguiente consulta T-SQL en SQL Server para leer el número de secuencia de registro del último registro de transacciones registrado. Sustituya:

  • <DatabaseName> por el nombre de la base de datos, y busque el último número de secuencia de registro de seguridad (LSN) protegido.
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

Use la siguiente consulta T-SQL en SQL Managed Instance para leer el último número de secuencia de registro de la base de datos. Reemplace <DatabaseName> por el nombre de su base de datos.

Esta consulta funciona en una SQL Managed Instance de uso general. Para una SQL Managed Instance crítica para la empresa, quite la marca de comentario and drs.is_primary_replica = 1 al final del script. En el nivel de servicio Crítico para la empresa, este filtro garantiza que los detalles solo se lean de la réplica principal.

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

Como alternativa, también podría utilizar el comando Get-AzSqlInstanceLink de PowerShell o az sql mi link show de la CLI de Azure para obtener la propiedad LastHardenedLsn de su enlace en SQL Managed Instance para proporcionar la misma información que la consulta T-SQL anterior.

Importante

Verifique una vez más que su carga de trabajo está detenida en la principal. Compruebe que los LSN de SQL Server y SQL Managed Instance coinciden, y que permanecen coincidentes y sin cambios durante algún tiempo. Los LSN estables en ambas instancias indican que el registro final se ha replicado en la secundaria y que la carga de trabajo se ha detenido correctamente.

Conmutación por error de una base de datos

Si desea usar PowerShell para conmutar por error una base de datos entre SQL Server 2022 y SQL Managed Instance mientras mantiene el vínculo, o para realizar una conmutación por error con pérdida de datos para cualquier versión de SQL Server, use la conmutación por error entre el asistente SQL Server e Instancia administrada en SSMS para generar el script para su entorno. Puede realizar una conmutación por error planeada desde la réplica principal o secundaria. Para realizar una conmutación por error forzada, conéctese a la réplica secundaria.

Para interrumpir el vínculo y detener la replicación al conmutar por error o migrar la base de datos independientemente de la versión de SQL Server, use el comando Remove-AzSqlInstanceLink de PowerShell o az sql mi link delete de la CLI de Azure.

Precaución

  • Antes de realizar la conmutación por error, detenga la carga de trabajo en la base de datos de origen para permitir que la base de datos replicada se ponga completamente al día y realice la conmutación por error sin pérdida de datos. Si realiza una conmutación por error forzada o si interrumpe el vínculo antes de que coincidan los LSN, podría perder datos.
  • La conmutación por error de una base de datos en SQL Server 2019 y versiones anteriores interrumpe y quita el vínculo entre las dos réplicas. No se puede conmutar por recuperación a la principal inicial.
  • La conmutación por error de una base de datos mientras mantiene el vínculo con SQL Server 2022 está actualmente en versión preliminar.

El siguiente script de ejemplo interrumpe el vínculo y finaliza la replicación entre las réplicas, lo que hace que la base de datos lea y escriba en ambas instancias. Sustituya:

  • <ManagedInstanceName> por el nombre de la instancia administrada.
  • <DAGName> por el nombre del vínculo con el que se realiza la conmutación por error (salida de la propiedad Name del comando Get-AzSqlInstanceLink ejecutado anteriormente).
# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

Cuando el proceso de conmutación por error funciona, el vínculo se anula y deja de existir. Tanto la base de datos de SQL Server como la base de datos de SQL Managed Instance pueden ejecutar una carga de trabajo de lectura y escritura. Son completamente independientes. Vuelva a establecer el punto de conexión de la aplicación cadena de conexión a la base de datos que desea usar activamente.

Importante

Tras una conmutación por error exitosa a SQL Managed Instance, vuelva a apuntar manualmente la cadena de conexión de su(s) aplicación(es) al FQDN de SQL Managed Instance para completar el proceso de migración o conmutación por error y continuar su ejecución en Azure.

Limpieza de los grupos de disponibilidad

Dado que la conmutación por error con SQL Server 2022 no interrumpe el vínculo, puede optar por dejar el vínculo y los grupos de disponibilidad en su lugar.

Si decide interrumpir el vínculo o si está conmutando por error con SQL Server 2019 y versiones anteriores, debe quitar el grupo de disponibilidad distribuido para quitar los metadatos de vínculo de SQL Server. Sin embargo, puede optar por mantener el grupo de disponibilidad en SQL Server.

Para limpiar los recursos del grupo de disponibilidad, reemplace los siguientes valores y, a continuación, ejecute el código de ejemplo: En el código siguiente, reemplace:

  • <DAGName> por el nombre del grupo de disponibilidad distribuido en SQL Server (que se ha usado para crear el vínculo).
  • <AGName> por el nombre del grupo de disponibilidad en SQL Server (que se ha usado para crear el vínculo).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

Solución de problemas

En la sección se proporcionan instrucciones para solucionar problemas relacionados con la configuración y el uso del vínculo.

Errores

Si encuentra un mensaje de error al crear el vínculo o conmutar por error una base de datos, revise el mensaje de error en la ventana de salida de la consulta para obtener más información.

Si se produce un error al trabajar con el vínculo, la consulta deja de ejecutarse en el paso con error. Una vez resuelta la condición de error, vuelva a ejecutar el comando para continuar con la acción.

Estado incoherente después de la conmutación por error forzada

El uso de la conmutación por error forzada puede dar lugar a un estado incoherente entre las réplicas principal y secundaria, lo que provoca que un escenario de cerebro dividido de ambas réplicas esté en el mismo rol. La replicación de datos produce un error en este estado hasta que el usuario resuelve la situación mediante la designación manual de una réplica como principal y la otra réplica como secundaria.

Contenido relacionado

Para más información sobre la característica de vínculo, consulte los siguientes recursos: