Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad Always On

  • Artículo

Se aplica a:SQL Server

En este artículo se describen las consideraciones necesarias para implementar Grupos de disponibilidad AlwaysOn, incluidos requisitos previos, restricciones y recomendaciones relativos a los equipos host, los clústeres de conmutación por error de Windows Server (WSFC), las instancias del servidor y los grupos de disponibilidad. Para cada uno de estos componentes, se indican los criterios de seguridad y permisos necesarios, si existen.

Importante

Antes de implementar Grupos de disponibilidad AlwaysOn, le recomendamos encarecidamente que lea todas las secciones de este tema.

Revisiones de .NET que admiten grupos de disponibilidad

Según los componentes y características de SQL Server que use con Grupos de disponibilidad Always On, puede que tenga que instalar las revisiones de .NET adicionales identificadas en la tabla siguiente. Las revisiones pueden instalarse en cualquier orden.

Característica dependiente Revisión Vínculo
Reporting Services La revisión para .NET 3.5 SP1 incorpora compatibilidad con las características cliente SQL para AlwaysOn de intención de lectura, de solo lectura y de conmutación por error de múltiples subredes. La revisión tiene que instalarse en cada servidor de informes Reporting Services . KB 2654347: Revisión para .NET 3.5 SP1 para agregar compatibilidad con las características de Always On

Lista de comprobación: requisitos (sistema de Windows)

Para admitir la característica de Grupos de disponibilidad AlwaysOn , asegúrese de que cada equipo que vaya a participar en uno o varios grupos de disponibilidad cumpla los requisitos básicos siguientes:

Requisito Vínculo
Asegúrese de que el sistema no es un controlador de dominio. No se admiten grupos de disponibilidad en los controladores de dominio.
Procure que cada equipo ejecute Windows Server 2019 o una versión posterior. SQL Server 2022: Requisitos de hardware y software
Asegúrese de que cada equipo es un nodo en un WSFC. Clústeres de conmutación por error de Windows Server con SQL Server
Asegúrese de que el WSFC contiene los nodos suficientes para admitir las configuraciones de grupo de disponibilidad. Un nodo de clúster puede hospedar una réplica para un grupo de disponibilidad. El mismo nodo no puede hospedar dos réplicas del mismo grupo de disponibilidad. El nodo del clúster puede participar en varios grupos de disponibilidad, con una réplica de cada grupo.

Pregunte a los administradores de bases de datos cuántos nodos de clúster se requieren para admitir las réplicas de disponibilidad de los grupos de disponibilidad planeados.

¿Qué es un grupo de disponibilidad Always On?

Importante

Asegúrese también de que el entorno esté configurado correctamente para conectarse a un grupo de disponibilidad. Para más información, vea Compatibilidad con la conectividad de cliente y controlador para grupos de disponibilidad.

Recomendaciones para equipos que alojan réplicas de disponibilidad (sistema de Windows)

  • Sistemas comparables: en un grupo de disponibilidad determinado, todas las réplicas de disponibilidad deben ejecutarse en sistemas comparables que puedan controlar cargas de trabajo idénticas.

  • Adaptadores de red dedicados: para obtener el mejor rendimiento, utilice un adaptador de red (tarjeta de interfaz de red) dedicado para grupos de disponibilidad AlwaysOn.

  • Espacio en disco suficiente: todos los equipos en los que una instancia del servidor hospeda una réplica de disponibilidad deben poseer suficiente espacio en disco para todas las bases de datos del grupo de disponibilidad. Tenga en cuenta que según crecen las bases de datos principales, las correspondientes bases de datos secundarias aumentan la misma cantidad.

Permisos (sistema de Windows)

Para administrar un WSFC, el usuario debe ser administrador del sistema en cada nodo de clúster.

Para más información sobre la cuenta para administrar el clúster, vea Apéndice A: Requisitos de clúster de conmutación por error.

Tareas relacionadas (sistema de Windows)

Tarea Vínculo
Establecer el valor de HostRecordTTL. Cambiar el valor de HostRecordTTL (con Windows PowerShell)

Cambiar el valor de HostRecordTTL (con PowerShell)

  1. Abra la ventana de PowerShell mediante Ejecutar como administrador.

  2. Importe el módulo FailoverClusters.

  3. Use el cmdlet Get-ClusterResource para encontrar el recurso Nombre de red y, después, use el cmdlet Set-ClusterParameter para establecer el valor HostRecordTTL de la siguiente manera:

    Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    En el siguiente ejemplo de PowerShell se establece el HostRecordTTL en 300 segundos en un recurso de nombre de red denominado SQL Network Name (SQL35).

    Import-Module FailoverClusters

$nameResource = "SQL Network Name (SQL35)"
Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300

    Sugerencia

    Cada vez que abre una nueva ventana de PowerShell, necesita importar el módulo FailoverClusters .

Contenido relacionado (PowerShell)

Contenido relacionado (sistema Windows)

Requisitos previos y restricciones de las instancias de SQL Server

Cada grupo de disponibilidad requiere un conjunto de asociados de conmutación por error, conocido como réplicas de disponibilidad, que se hospedan en instancias de SQL Server. Una instancia del servidor determinada puede ser una instancia independiente o una instancia de clúster de conmutación por error (FCI) de SQL Server.

Esta sección:

Lista de comprobación: requisitos previos (instancia del servidor)

Requisito previo Vínculos
Este equipo host debe ser un nodo de WSFC. Las instancias de SQL Server que hospedan réplicas de disponibilidad de un determinado grupo de disponibilidad residen en nodos independientes del clúster. Un grupo de disponibilidad puede ocupar temporalmente dos clústeres mientras se migra a otro clúster. SQL Server 2016 (13.x) incorpora la novedad de los grupos de disponibilidad distribuidos. En un grupo de disponibilidad distribuido, dos grupos de disponibilidad residen en clústeres distintos. Clústeres de conmutación por error de Windows Server con SQL Server

Clústeres de conmutación por error y grupos de disponibilidad AlwaysOn (SQL Server)

Grupos de disponibilidad distribuidos
Si desea que un grupo de disponibilidad trabaje con Kerberos:

Todas las instancias de servidor que hospedan una réplica de disponibilidad para el grupo de disponibilidad deben usar la misma cuenta de servicio de SQL Server.

El administrador de dominio debe registrar manualmente un nombre principal de servicio (SPN) con Active Directory en la cuenta del servicio SQL Server para el nombre de red virtual (VNN) del agente de escucha del grupo de disponibilidad. Si el SPN se registra en una cuenta distinta de la cuenta del servicio SQL Server, la autenticación falla.

Para usar la autenticación Kerberos para la comunicación entre los puntos de conexión del grupo de disponibilidad (AG), registre manualmente los SPN para los puntos de conexión de creación de reflejo de la base de datos usados por el grupo de disponibilidad.

Importante: Si cambia la cuenta del servicio SQL Server, el administrador de dominio necesita volver a registrar manualmente el SPN.		 Registrar un nombre de entidad de seguridad de servicio para las conexiones con Kerberos

Nota:

Kerberos y los SPN exigen la autenticación mutua. El SPN se asigna a la cuenta de Windows que inicia los servicios SQL Server. Si el SPN no se registra correctamente o provoca un error, el nivel de seguridad de Windows no podrá determinar la cuenta asociada al SPN y no podrá utilizarse la autenticación Kerberos.

Nota: NTLM no tiene este requisito.
Si va a usar una instancia de clúster de conmutación por error (FCI) de SQL Server para hospedar una réplica de disponibilidad, asegúrese de que comprende las restricciones de FCI y de que se cumplen los requisitos de FCI. Requisitos previos y requisitos para usar una instancia de clúster de conmutación por error (FCI) de SQL Server para hospedar una réplica de disponibilidad (más adelante en este artículo)
Cada instancia del servidor debe ejecutar la misma versión de SQL Server para participar en un grupo de disponibilidad. Para obtener más información, consulta la lista de ediciones y características compatibles al final de esta sección.
Todas las instancias del servidor que hospedan réplicas de disponibilidad para un grupo de disponibilidad deben usar la misma intercalación de SQL Server . Configurar o cambiar la intercalación del servidor
Habilite la característica de Grupos de disponibilidad AlwaysOn en cada instancia de servidor que hospeda una réplica de disponibilidad para cualquier grupo de disponibilidad. En un equipo determinado, puede habilitar tantas instancias de servidor de Grupos de disponibilidad AlwaysOn como admita la instalación de SQL Server . Habilitar o deshabilitar la característica Grupos de disponibilidad Always On

Importante: Si elimina y vuelve a crear un WSFC, debe deshabilitar y volver a habilitar la característica Grupos de disponibilidad Always On en cada instancia del servidor habilitada para dicha característica en el clúster original.
Cada instancia del servidor requiere un extremo de creación de reflejo de la base de datos. Todas las réplicas de disponibilidad, asociados de creación de reflejo de la base de datos y testigos de la instancia del servidor comparten este punto de conexión.

Si una instancia de servidor seleccionada para alojar una réplica de disponibilidad se ejecuta bajo una cuenta de usuario de dominio y no tiene todavía un punto de conexión de creación de reflejo de la base de datos, Usar el asistente para nuevo grupo de disponibilidad (SQL Server Management Studio) (o Agregar una réplica a grupo de disponibilidad Always On usando el asistente de grupo de disponibilidad en SQL Server Management) puede crear el punto de conexión y conceder el permiso CONNECT a la cuenta de servicio de la instancia de servidor. Sin embargo, si el servicio SQL Server se ejecuta como una cuenta integrada como sistema local, servicio local o servicio de red, o una cuenta que no es de dominio, debe usar certificados para la autenticación de extremos y el asistente no podrá crear un extremo de creación de reflejo de la base de datos en la instancia de servidor. En este caso, se recomienda crear los extremos de creación de reflejo de la base de datos manualmente antes de iniciar el asistente.

Nota de seguridad: La seguridad de transporte para grupos de disponibilidad Always On es la misma que para la creación de reflejo de la base de datos.		 El extremo de creación de reflejo de la base de datos (SQL Server)

Seguridad de transporte - Creación de reflejo de la base de datos - Grupos de disponibilidad Always On
Si va a agregar cualquier base de datos que usa FILESTREAM a un grupo de disponibilidad, asegúrese de que FILESTREAM está habilitado en cada instancia de servidor que alojará una réplica de disponibilidad para el grupo de disponibilidad. Habilitar y configurar FILESTREAM
Si va a agregar cualquier base de datos independiente a un grupo de disponibilidad, asegúrese de que la autenticación de base de datos independiente (la opción de configuración del servidor) esté establecida en 1 en cada instancia del servidor que aloja una réplica de disponibilidad para el grupo de disponibilidad. contained database authentication (opción de configuración del servidor)

Opciones de configuración de servidor (SQL Server)

Para obtener una lista de las características admitidas por ediciones de SQL Server en Windows, vea:

Uso de subprocesos por parte de los grupos de disponibilidad

Grupos de disponibilidad AlwaysOn tiene los siguientes requisitos para los subprocesos de trabajo:

  • En una instancia inactiva de SQL Server, Grupos de disponibilidad AlwaysOn usa 0 subprocesos.

  • El número máximo de subprocesos usados por los grupos de disponibilidad es el valor configurado para el número máximo de subprocesos de servidor ('max worker threads') menos 40.

  • Las réplicas de disponibilidad hospedadas en una instancia de servidor determinada comparten un único grupo de subprocesos en SQL Server 2019 (15.x) y versiones anteriores.

    Los subprocesos se comparten a petición, de la manera siguiente:

    • Normalmente, hay entre 3 y 10 subprocesos compartidos, pero este número puede aumentar según la carga de réplica principal.

    • Si un subproceso determinado está inactivo durante un tiempo, se libera de nuevo en el grupo de subprocesos general de SQL Server. Normalmente, un subproceso inactivo se libera después de unos 15 segundos de inactividad. Sin embargo, dependiendo de la última actividad, un subproceso inactivo se puede conservar más tiempo.

    • Una instancia de SQL Server utiliza hasta 100 subprocesos para puesta al día en paralelo para las réplicas secundarias. Cada base de datos utiliza hasta la mitad del número total de núcleos de CPU, pero no más de 16 subprocesos por base de datos. Si el número total de subprocesos necesarios para una única instancia supera los 100, SQL Server utiliza un solo subproceso de puesta al día para cada base de datos restante. Los subprocesos de rehacer en serie se liberan al cabo de aproximadamente 15 segundos de inactividad.

  • Además, los grupos de disponibilidad usan subprocesos no compartidos, de la manera siguiente:

    • Cada réplica principal usa 1 subproceso de captura de registro para cada base de datos principal. Además, usa 1 subproceso de envío de registro para cada base de datos secundaria. Los subprocesos de envío de registro se liberan después de unos 15 segundos de inactividad.

    • Una copia de seguridad en una réplica secundaria contiene un subproceso en la réplica principal mientras dura la operación de copia de seguridad.

  • SQL Server 2022 (16.x) introdujo el grupo de subprocesos de puesta al día paralelo, que es un grupo de subprocesos de nivel de instancia compartido con todas las bases de datos que tienen trabajo de puesta al día. Con este grupo, el mismo conjunto de subprocesos puede procesar los registros de bases de datos diferentes al mismo tiempo (en paralelo). En SQL Server 2019 (15.x) y versiones anteriores, el número de subprocesos disponibles para rehacer se limita a 100.

  • SQL Server 2019 (15.x) presentó una puesta al día en paralelo de las bases de datos de grupo de disponibilidad optimizadas para memoria. En SQL Server 2016 (13.x) y 2017 (14.x), las tablas basadas en disco no usan la puesta al día en paralelo si una base de datos de un grupo de disponibilidad también está optimizada para memoria.

Para más información, vea Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (Series de aprendizaje de Always ON - HADRON: Uso del grupo de trabajo para las bases de datos compatibles con HADRON) (Blog de ingenieros de CSS SQL Server).

Permisos (instancia del servidor)

Tarea Permisos necesarios
Crear el extremo de creación de reflejo de la base de datos Requiere permiso CREATE ENDPOINT o pertenecer al rol fijo de servidor sysadmin . También requiere el permiso CONTROL ON ENDPOINT. Para más información, consulte Permisos de punto de conexión de GRANT (Transact-SQL).
Habilitar Grupos de disponibilidad AlwaysOn Requiere la pertenencia al grupo Administrador en el equipo local y control total del WSFC.

Tareas relacionadas (instancia del servidor)

Tarea Artículo
Determinar si existe un extremo de creación de reflejo de la base de datos sys.database_mirroring_endpoints (Transact-SQL)
Crear el extremo de creación de reflejo de la base de datos (si aún no existe) Crear un extremo de reflejo de la base de datos para la autenticación de Windows (Transact-SQL)

Usar certificados para un punto de conexión de creación de reflejo de la base de datos (Transact-SQL)

Creación de un punto de conexión de creación de reflejo de la base de datos para un grupo de disponibilidad con PowerShell
Habilitar grupos de disponibilidad Habilitar o deshabilitar la característica Grupos de disponibilidad Always On

Contenido relacionado (instancia del servidor)

Recomendaciones de conexión de red

Se recomienda usar los mismos vínculos de red para las comunicaciones entre los nodos de WSFC y las comunicaciones entre las réplicas de disponibilidad. El uso de vínculos de red independientes puede provocar comportamientos inesperados si alguno de los vínculos da error (incluso de forma intermitente).

Por ejemplo, para que un grupo de disponibilidad admita la conmutación por error automática, la réplica secundaria que sea el asociado de conmutación por error automática debe tener el estado SYNCHRONIZED. Si el vínculo de red a esta réplica secundaria da error (incluso de forma intermitente), la réplica entra en el estado UNSYNCHRONIZED y no puede iniciarse para volver a sincronizar hasta que se restaure el vínculo. Si el WSFC solicita una conmutación automática por error mientras la réplica secundaria no está sincronizada, la conmutación por error automática no aparecerá.

Compatibilidad con conectividad de cliente

Para obtener información sobre la compatibilidad de grupos de disponibilidad Always On con la conectividad de cliente, consulte Compatibilidad de conectividad de cliente y controladores para grupos de disponibilidad.

Requisitos previos y restricciones para usar una instancia de clúster de conmutación por error (FCI) de SQL Server para alojar una réplica de disponibilidad

Esta sección:

Restricciones (FCI)

Nota:

Las instancias de clúster de conmutación por error (FCI) también admiten volúmenes compartidos en clúster (CSV). Para obtener más información sobre CSV, consulte Descripción de Volúmenes compartidos de clúster en un clúster de conmutación por error.

  • Los nodos de clúster de una FCI solo pueden alojar una réplica de un grupo de disponibilidad determinado: si agrega una réplica de disponibilidad en una FCI, los nodos de WSFC que sean posibles propietarios de FCI no pueden hospedar otra réplica del mismo grupo de disponibilidad. Para evitar posibles conflictos, se recomienda configurar los posibles propietarios de la instancia de clúster de conmutación por error. Con esto se evita que un único WSFC intente alojar dos réplicas de disponibilidad para el mismo grupo de disponibilidad.

    Además, el resto de réplicas debe alojarse en una instancia de SQL Server que resida en otro nodo de clúster del mismo clúster de conmutación por error de Windows Server. La única excepción es que mientras se migra a otro clúster, un grupo de disponibilidad puede ocupar temporalmente dos clústeres.

    Advertencia

    Si usa el Administrador de clústeres de conmutación por error para mover una instancia de clúster de conmutación por error que aloja un grupo de disponibilidad a un nodo que ya aloja una réplica del mismo grupo de disponibilidad, podría provocar la pérdida de la réplica del grupo de disponibilidad, impidiendo que se ponga en línea en el nodo de destino. Un único nodo de un clúster de conmutación por error no puede alojar más de una réplica para el mismo grupo de disponibilidad. Para más información sobre cómo sucede esto y cómo recuperarse de este problema, eche un vistazo a la entrada de blog Réplica dejada inesperadamente en grupo de disponibilidad.

  • Las FCI no admiten la conmutación automática por error por grupos de disponibilidad: las FCI no admiten la conmutación automática por error por grupos de disponibilidad; por tanto, todas las réplicas de disponibilidad hospedadas por una FCI solo se pueden configurar para la conmutación por error manual.

  • Cambiar el nombre de red de FCI: si necesita cambiar el nombre de red de una FCI que aloje una réplica de disponibilidad, tendrá que quitar la réplica del grupo de disponibilidad y, después, agregarla de nuevo. No puede quitar la réplica principal, de modo que si cambia el nombre de una FCI que aloja la réplica principal, debe conmutar por error a una réplica secundaria, después quitar la réplica principal anterior y volver a agregarla. Cambiar el nombre de una FCI puede modificar la dirección URL del extremo de creación de reflejo de la base de datos. Al agregar la réplica asegúrese de especificar la dirección URL del extremo actual.

Lista de comprobación: requisitos previos (FCI)

Requisito previo Vínculo
Asegúrese de que cada instancia de clúster de conmutación por error (FCI) de SQL Server posee el almacenamiento compartido necesario según la instalación estándar de la instancia de clúster de conmutación por error de SQL Server.

Tareas relacionadas (FCI)

Tarea Artículo
Instalación de una FCI de SQL Server Creación de una nueva instancia de clúster de conmutación por error Always On (programa de instalación)
Actualización local del FCI de SQL Server existente Actualización de una instancia del clúster de conmutación por error
Mantener el FCI de SQL Server existente Agregar o eliminar nodos en una instancia de clúster de conmutación por error (programa de instalación)

Contenido relacionado (FCI)

Requisitos previos y restricciones de los grupos de disponibilidad

Esta sección:

Restricciones (grupos de disponibilidad)

  • Las réplicas de disponibilidad deben estar hospedadas en nodos diferentes de un WSFC: en un grupo de disponibilidad concreto, las réplicas de disponibilidad deben hospedarse en instancias de servidor que se ejecuten en nodos diferentes dentro del mismo WSFC. La única excepción es que mientras se migra a otro clúster, un grupo de disponibilidad puede ocupar temporalmente dos clústeres.

    Nota

    Cada una de las diferentes máquinas virtuales de un mismo equipo físico puede hospedar una réplica de disponibilidad para el mismo grupo de disponibilidad, porque cada máquina virtual actúa como un equipo independiente.

  • Nombre único de grupo de disponibilidad: cada nombre de grupo de disponibilidad debe ser único en el WSFC. La longitud máxima del nombre de un grupo de disponibilidad es 128 caracteres.

  • Réplicas de disponibilidad: cada grupo de disponibilidad admite una réplica principal y hasta ocho réplicas secundarias. Todas las réplicas pueden ejecutarse en el modo de confirmación asincrónica, o bien hasta cinco de ellas pueden ejecutarse en el modo de confirmación sincrónica (una réplica principal con dos réplicas secundarias sincrónicas). Cada réplica debe tener un nombre de servidor único en Windows y SQL Server. Los nombres de servidor entre Windows y SQL Server deben coincidir.

  • Número máximo de grupos de disponibilidad y bases de datos de disponibilidad por equipo: El número real de bases de datos y grupos de disponibilidad que puede colocar en un equipo (equipo físico o máquina virtual) depende del hardware y de la carga de trabajo, pero no hay ningún límite impuesto. Microsoft ha probado hasta 10 grupos de disponibilidad y 100 bases de datos por máquina física, pero este no es un límite vinculante. Según la especificación de hardware en el servidor y la carga de trabajo, puede poner un mayor número de bases de datos y grupos de disponibilidad en una instancia de SQL Server. Los signos de sistemas sobrecargados pueden incluir, pero no limitarse a los siguientes: agotamiento de subprocesos de trabajo, tiempos de respuesta lentos para vistas del sistema del grupo de disponibilidad y DMV de AlwaysOn o volcados del sistema del distribuidor detenidos. Asegúrese de comprobar minuciosamente el entorno con una carga de trabajo similar a la que usará en producción para asegurarse de que puede controlar la capacidad de carga de trabajo máxima con sus contratos de nivel de servicio de aplicación. Cuando evalúe los contratos de nivel de servicio, no olvide tener en cuenta la carga en condiciones de error además de los tiempos de respuesta esperados.

  • No use el Administrador de clústeres de conmutación por error para manipular grupos de disponibilidad. El estado de una Instancia del FCI de SQL Server se comparte entre SQL Server y el clúster de conmutación por error de Windows Server (WSFC), y SQL Server mantiene información de estado sobre las instancias más detallada que de la que se ocupa el clúster. El modelo de administración supone que SQL Server debe impulsar las transacciones y se encarga de mantener la vista de estado del clúster sincronizada con la vista de estado de SQL Server. Si el estado del clúster cambia fuera de SQL Server, es posible que el estado no esté sincronizado entre WSFC y SQL Server, lo que puede provocar un comportamiento impredecible.

    Por ejemplo:

    • No cambie ninguna propiedad del grupo de disponibilidad, como los posibles propietarios.

    • No use el Administrador de clústeres de conmutación por error para conmutar grupos de disponibilidad. Debe usar Transact-SQL o SQL Server Management Studio.

  • No agregue recursos ni modifique las dependencias asociadas al rol de grupo de disponibilidad. No se recomienda colocar ningún recurso adicional (incluido el usuario o un tercero) en el rol de grupo de disponibilidad ni modificar las dependencias de rol, ya que estos cambios pueden afectar negativamente al rendimiento de la conmutación por error.

Requisitos previos (grupos de disponibilidad)

Al crear o establecer de nuevo una configuración de grupo de disponibilidad, asegúrese de que se adhiere a los siguientes requisitos.

Requisito previo Descripción
Si va a usar una instancia de clúster de conmutación por error (FCI) de SQL Server para hospedar una réplica de disponibilidad, asegúrese de que comprende las restricciones de FCI y de que se cumplen los requisitos de FCI. Requisitos previos y restricciones del uso de una instancia de clúster de conmutación por error (FCI) de SQL Server para alojar una réplica de disponibilidad (anteriormente en este artículo)

Seguridad (grupos de disponibilidad)

  • La seguridad se hereda del WSFC. El clúster de conmutación por error de Windows Server proporciona dos niveles de seguridad del usuario con una granularidad de clúster completo:

    • Acceso de solo lectura

    • Control total

      Grupos de disponibilidad AlwaysOn necesita el control total, y habilitar Grupos de disponibilidad AlwaysOn en una instancia de SQL Server proporciona control total del clúster (a través del SID de servicio).

      No puede agregar o quitar directamente la seguridad de una instancia del servidor en el Administrador de clústeres. Para administrar las sesiones de seguridad del clúster, use el administrador de configuración de SQL Server o el equivalente de WMI de SQL Server.

  • Cada instancia de SQL Server debe tener permisos de acceso al Registro, al clúster, y así sucesivamente.

  • Se recomienda utilizar cifrado para las conexiones entre las instancias del servidor que hospedan las réplicas de disponibilidad de Grupos de disponibilidad AlwaysOn .

Permisos (grupos de disponibilidad)

Tarea Permisos necesarios
Crear un grupo de disponibilidad Se requiere la pertenencia al rol fijo de servidor sysadmin y el permiso de servidor CREATE AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER.
Modificación de un grupo de disponibilidad Se requiere el permiso ALTER AVAILABILITY GROUP en el grupo de disponibilidad, el permiso CONTROL AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER.

Además, combinar una base de datos con un grupo de disponibilidad requiere ser miembro del rol fijo de base de datos db_owner .
Quitar o eliminar un grupo de disponibilidad Se requiere el permiso ALTER AVAILABILITY GROUP en el grupo de disponibilidad, el permiso CONTROL AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER. Para quitar un grupo de disponibilidad que no se encuentre hospedado en la ubicación de réplica local, se necesita el permiso CONTROL SERVER o el permiso CONTROL en ese grupo de disponibilidad.

Tareas relacionadas (grupos de disponibilidad)

Tarea Artículo
Crear un grupo de disponibilidad Usar el Asistente para grupo de disponibilidad (SQL Server Management Studio)

Creación de un grupo de disponibilidad Always On mediante Transact-SQL (T-SQL)

Creación de un grupo de disponibilidad Always On con PowerShell

Especificar la dirección URL del punto de conexión - Agregar o modificar una réplica de disponibilidad
Modificar el número de réplicas de disponibilidad Agregar una réplica secundaria a un grupo de disponibilidad Always On

Unión de una réplica secundaria a un grupo de disponibilidad Always On

Quitar una réplica secundaria de un grupo de disponibilidad (SQL Server)
Creación de una escucha de grupo de disponibilidad Configuración de un agente de escucha para un grupo de disponibilidad Always On
Eliminación de un grupo de disponibilidad Quitar un grupo de disponibilidad (SQL Server)

Requisitos previos y restricciones de las bases de datos de disponibilidad

Para poder agregar una base de datos a un grupo de disponibilidad, la base de datos debe cumplir los requisitos previos y restricciones siguientes.

Esta sección:

Lista de comprobación: requisitos (bases de datos de disponibilidad)

Para poder agregarse a un grupo de disponibilidad, una base de datos debe:

Requisitos Vínculo
Ser una base de datos de usuario. Las bases de datos del sistema no pueden pertenecer a un grupo de disponibilidad.
Residir en la instancia de SQL Server donde esté creando el grupo de disponibilidad y ser accesible a la instancia del servidor.
Ser una base de datos de lectura y escritura. Las bases de datos de solo lectura no se pueden agregar a un grupo de disponibilidad. sys.databases (is_read_only = 0)
Ser una base de datos multiusuario. sys.databases (user_access = 0)
No utilizar AUTO_CLOSE. sys.databases (is_auto_close_on = 0)
Use el modelo de recuperación completa. sys.databases (recovery_model = 1)
Posea al menos una copia de seguridad completa de la base de datos.

Nota: Después de establecer una base de datos en modo de recuperación completa, se requiere una copia de seguridad completa para iniciar la cadena de registros de recuperación completa.		 Crear una copia de seguridad completa de base de datos
No pertenecer a ningún grupo de disponibilidad existente sys.databases (group_database_id = NULL)
No estar configurada para la creación de reflejo de la base de datos. sys.database_mirroring (si la base de datos no participa en la creación de reflejo, todas las columnas con el prefijo “mirroring_” son NULL).
Para poder agregar una base de datos que usa FILESTREAM a un grupo de disponibilidad, asegúrese de que FILESTREAM está habilitado en cada instancia del servidor que hospeda o que hospedará una réplica de disponibilidad para el grupo de disponibilidad. Habilitar y configurar FILESTREAM
Antes de agregar una base de datos independiente a un grupo de disponibilidad, asegúrese de que la opción de servidor contained database authentication está establecida en 1 en cada instancia del servidor que hospeda o que hospedará una réplica de disponibilidad para el grupo de disponibilidad. contained database authentication (opción de configuración del servidor)

Opciones de configuración de servidor (SQL Server)

Nota

Grupos de disponibilidad AlwaysOn funciona con cualquier nivel de compatibilidad con bases de datos.

Restricciones (bases de datos de disponibilidad)

  • Si la ruta de acceso de archivo (incluida la letra de unidad) de una base de datos secundaria es diferente de la ruta de acceso de la base de datos principal correspondiente, se aplican las restricciones siguientes:

  • No se puede quitar una base de datos que pertenezca actualmente a un grupo de disponibilidad.

Seguimiento de las bases de datos protegidas por TDE

Si usa cifrado de datos transparente (TDE), la clave de certificado o asimétrica para crear y descifrar otras claves debe ser la misma en todas las instancias de servidor que hospedan una réplica de disponibilidad para el grupo de disponibilidad. Para obtener más información, vea Mover una base de datos protegida por TDE a otra instancia de SQL Server.

Permisos (bases de datos de disponibilidad)

Requiere el permiso ALTER en la base de datos.

Tareas relacionadas (bases de datos de disponibilidad)

Tarea Artículo
Preparar una base de datos secundaria (manualmente) Preparación de una base de datos secundaria para un grupo de disponibilidad Always On
Combinar una base de datos secundaria con un grupo de disponibilidad (manualmente) Unión de una base de datos secundaria con un grupo de disponibilidad Always On
Modificar el número de bases de datos de disponibilidad Adición de una base de datos a un grupo de disponibilidad Always On

Quitar una base de datos secundaria de un grupo de disponibilidad (SQL Server)

Eliminación de una base de datos principal de un grupo de disponibilidad Always On

Contenido relacionado