Compartir a través de

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, la base de datos de la principal inicial se replica 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 conmutar por recuperación entre las dos réplicas.

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

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 instancia administrada de SQL 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 se admite la configuración de Azure SQL Managed Instance como principal inicial 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.

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 para crear el certificado de punto de conexión MI. 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 = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3300D06092A864886F70D01010C05003065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F726974792032303137301E170D3139313231383232353132325A170D3432303731383233303032335A3065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F72697479203230313730820222300D06092A864886F70D01010105000382020F003082020A0282020100CA5BBE94338C299591160A95BD4762C189F39936DF4690C9A5ED786A6F479168F8276750331DA1A6FBE0E543A3840257015D9C4840825310BCBFC73B6890B6822DE5F465D0CC6D19CC95F97BAC4A94AD0EDE4B431D8707921390808364353904FCE5E96CB3B61F50943865505C1746B9B685B51CB517E8D6459DD8B226B0CAC4704AAE60A4DDB3D9ECFC3BD55772BC3FC8C9B2DE4B6BF8236C03C005BD95C7CD733B668064E31AAC2EF94705F206B69B73F578335BC7A1FB272AA1B49A918C91D33A823E7640B4CD52615170283FC5C55AF2C98C49BB145B4DC8FF674D4C1296ADF5FE78A89787D7FD5E2080DCA14B22FBD489ADBACE479747557B8F45C8672884951C6830EFEF49E0357B64E798B094DA4D853B3E55C428AF57F39E13DB46279F1EA25E4483A4A5CAD513B34B3FC4E3C2E68661A45230B97A204F6F0F3853CB330C132B8FD69ABD2AC82DB11C7D4B51CA47D14827725D87EBD545E648659DAF5290BA5BA2186557129F68B9D4156B94C4692298F433E0EDF9518E4150C9344F7690ACFC38C1D8E17BB9E3E394E14669CB0E0A506B13BAAC0F375AB712B590811E56AE572286D9C9D2D1D751E3AB3BC655FD1E0ED3740AD1DAAAEA69B897288F48C407F852433AF4CA55352CB0A66AC09CF9F281E1126AC045D967B3CEFF23A2890A54D414B92AA8D7ECF9ABCD255832798F905B9839C40806C1AC7F0E3D00A50203010001A3543052300E0603551D0F0101FF040403020186300F0603551D130101FF040530030101FF301D0603551D0E0416041409CB597F86B2708F1AC339E3C0D9E9BFBB4DB223301006092B06010401823715010403020100300D06092A864886F70D01010C05000382020100ACAF3E5DC21196898EA3E792D69715B813A2A6422E02CD16055927CA20E8BAB8E81AEC4DA89756AE6543B18F009B52CD55CD53396D624C8B0D5B7C2E44BF83108FF3538280C34F3AC76E113FE6E3169184FB6D847F3474AD89A7CEB9D7D79F846492BE95A1AD095333DDEE0AEA4A518E6F55ABBAB59446AE8C7FD8A2502565608046DB3304AE6CB598745425DC93E4F8E355153DB86DC30AA412C169856EDF64F15399E14A75209D950FE4D6DC03F15918E84789B2575A94B6A9D8172B1749E576CBC156993A37B1FF692C919193E1DF4CA337764DA19FF86D1E1DD3FAECFBF4451D136DCFF759E52227722B86F357BB30ED244DDC7D56BBA3B3F8347989C1E0F20261F7A6FC0FBB1C170BAE41D97CBD27A3FD2E3AD19394B1731D248BAF5B2089ADB7676679F53AC6A69633FE5392C846B11191C6997F8FC9D66631204110872D0CD6C1AF3498CA6483FB1357D1C1F03C7A8CA5C1FD9521A071C193677112EA8F880A691964992356FBAC2A2E70BE66C40C84EFE58BF39301F86A9093674BB268A3B5628FE93F8C7A3B5E0FE78CB8C67CEF37FD74E2C84F3372E194396DBD12AFBE0C4E707C1B6F8DB332937344166DE8F4F7E095808F965D38A4F4ABDE0A308793D84D00716245274B3A42845B7F65B76734522D9C166BAAA8D87BA3424C71C70CCA3E83E4A6EFB701305E51A379F57069A641440F86B02C91C63DEAAE0F84

    --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 exists.'
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 = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D09FAE5300D06092A864886F70D01010B05003061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F74204732301E170D3133303830313132303030305A170D3338303131353132303030305A3061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F7420473230820122300D06092A864886F70D01010105000382010F003082010A0282010100BB37CD34DC7B6BC9B26890AD4A75FF46BA210A088DF51954C9FB88DBF3AEF23A89913C7AE6AB061A6BCFAC2DE85E092444BA629A7ED6A3A87EE054752005AC50B79C631A6C30DCDA1F19B1D71EDEFDD7E0CB948337AEEC1F434EDD7B2CD2BD2EA52FE4A9B8AD3AD499A4B625E99B6B00609260FF4F214918F76790AB61069C8FF2BAE9B4E992326BB5F357E85D1BCD8C1DAB95049549F3352D96E3496DDD77E3FB494BB4AC5507A98F95B3B423BB4C6D45F0F6A9B29530B4FD4C558C274A57147C829DCD7392D3164A060C8C50D18F1E09BE17A1E621CAFD83E510BC83A50AC46728F67314143D4676C387148921344DAF0F450CA649A1BABB9CC5B1338329850203010001A3423040300F0603551D130101FF040530030101FF300E0603551D0F0101FF040403020186301D0603551D0E041604144E2254201895E6E36EE60FFAFAB912ED06178F39300D06092A864886F70D01010B05000382010100606728946F0E4863EB31DDEA6718D5897D3CC58B4A7FE9BEDB2B17DFB05F73772A3213398167428423F2456735EC88BFF88FB0610C34A4AE204C84C6DBF835E176D9DFA642BBC74408867F3674245ADA6C0D145935BDF249DDB61FC9B30D472A3D992FBB5CBBB5D420E1995F534615DB689BF0F330D53E31E28D849EE38ADADA963E3513A55FF0F970507047411157194EC08FAE06C49513172F1B259F75F2B18E99A16F13B14171FE882AC84F102055D7F31445E5E044F4EA879532930EFE5346FA2C9DFF8B22B94BD90945A4DEA4B89A58DD1B7D529F8E59438881A49E26D56FADDD0DC6377DED03921BE5775F76EE3C8DC45D565BA2D9666EB33537E532B6

    --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 exists.'
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

Validación del certificado

Después de crear los certificados, valide que el certificado de punto de conexión MI esté configurado correctamente.

En primer lugar, determine el valor certificate_id del certificado MI exportado reemplazando el valor de <ManagedInstanceFQDN> y, a continuación, ejecutando la siguiente consulta en SQL Server:

-- Run on SQL Server 
USE MASTER 
GO 

SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

A continuación, valide el certificado reemplazando el valor de <certificate_id> del resultado de la consulta anterior y, a continuación, ejecutando la siguiente consulta en SQL Server:

-- Run on SQL Server 

USE MASTER 
GO 

EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

Una respuesta de Commands completed successfully. Completion time: … indica que el certificado de punto de conexión MI se ha validado correctamente.

Si se produce un error, quite el certificado y siga los pasos descritos en la sección Obtención de la clave pública del certificado de SQL Managed Instance e importación en SQL Server para volver a importar el certificado.

Para quitar el certificado, ejecute la siguiente consulta en SQL Server:

-- Run on SQL Server 

USE MASTER 
GO 

DROP CERTIFICATE [<ManagedInstanceFQDN>] 
GO

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.

Nota:

Si ya tiene un grupo de disponibilidad existente, omita esta sección.

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:

  • <AGNameOnSQLServer> con el nombre de su grupo de disponibilidad en SQL Server. 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 [<AGNameOnSQLServer>]
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>.
  • <AGNameOnSQLServer> por el nombre del grupo de disponibilidad creado en el paso anterior.
  • <AGNameOnSQLMI> con el nombre del grupo de disponibilidad en SQL Managed Instance. El nombre debe ser único en MI de SQL. 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>_MI.
  • <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'<AGNameOnSQLServer>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<AGNameOnSQLMI>' 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.
  • <AGNameOnSQLServer> por el nombre del grupo de disponibilidad creado en SQL Server.
  • <AGNameOnSQLMI> con el nombre del grupo de disponibilidad creado en SQL Managed Instance.
  • <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.

Nota:

Si desea establecer un vínculo a un grupo de disponibilidad que ya existe, proporcione la dirección IP del agente de escucha al proporcionar el parámetro <SQLServerIP>.

#  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
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# 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 $AGNameOnSQLServer -SecondaryAvailabilityGroupName $AGNameOnSQLMI |
-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.

Realizar la primera copia de seguridad del registro de transacciones

Si SQL Server es la base de datos principal inicial, es importante realizar la primera copia de seguridad del registro de transacciones en SQL Server una vez completada la inicialización, cuando la base de datos ya no esté en el estado Restaurar... en Azure SQL Managed Instance. A continuación, realice copias de seguridad del registro de transacciones de SQL Server periódicamente para minimizar el crecimiento excesivo del registro mientras SQL Server se encuentra en el rol principal.

Si SQL Managed Instance es el principal, no es necesario realizar ninguna acción, ya que Azure SQL Managed Instance realiza copias de seguridad de registros automáticamente.

Si desea quitar el vínculo, ya sea porque ya no es necesario o porque se encuentra en un estado irreversible y debe volver a crearse, puede hacerlo con PowerShell y T-SQL.

En primer lugar, use el comando Remove-AzSqlInstanceLink de PowerShell para quitar el vínculo, como el ejemplo siguiente:

Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $managedInstanceName -Name $DAGName -Force

A continuación, use el siguiente script de T-SQL para quitar el grupo de disponibilidad distribuido en SQL Server. Sustituya <DAGName> por el nombre del grupo de disponibilidad distribuido que se ha usado para crear el vínculo:

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO

Por último, opcionalmente, puede quitar el grupo de disponibilidad si ya no tiene un uso para él. Para ello, reemplace <AGName> por el nombre del grupo de disponibilidad y, a continuación, ejecútelo en la instancia correspondiente:

DROP AVAILABILITY GROUP <AGName>  
GO

Solución de problemas

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

Contenido relacionado

Para usar el vínculo:

Para más información sobre el vínculo:

Para otros escenarios de replicación y migración, considere lo siguiente: