Configuración del vínculo con scripts: Azure SQL Managed Instance
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:
- También es posible configurar el vínculo con SQL Server Management Studio (SSMS).
- 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.
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 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:
- Una suscripción de Azure activa. En caso de no tener ninguna, cree una cuenta gratuita.
- Versión compatible de SQL Server con la actualización de servicio necesaria instalada.
- Azure SQL Managed Instance. Inicio rápido: Creación de una instancia administrada de Azure SQL si aún no tiene una.
- Módulo de PowerShell Az.SQL 3.9.0 o superior, o la CLI de Azure 2.47.0 o posterior. O bien, use Azure Cloud Shell en línea para el navegador web para ejecutar los comandos, ya que siempre está actualizado con las versiones más recientes del módulo.
- Un entorno preparado correctamente.
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 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:
- Genere un certificado en SQL Server y obtenga su clave pública.
- Obtenga la clave pública del certificado de SQL Managed Instance.
- Intercambie las claves públicas entre SQL Server y SQL Managed Instance.
- 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 por0x
.<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 por0x
). 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
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:
<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.
Creación de un vínculo
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.
# 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.
Comprobación del 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.
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: