ALTER AVAILABILITY GROUP (Transact-SQL)

  • Artículo

Modifica un grupo de disponibilidad Siempre visible existente en SQL Server 2012. La mayoría de los argumentos de ALTER AVAILABILITY GROUP solo se admiten en la réplica principal actual. Sin embargo, los argumentos JOIN, FAILOVER y FORCE_FAILOVER_ALLOW_DATA_LOSS solo se admiten en réplicas secundarias.

Icono de vínculo a temas Convenciones de sintaxis de Transact-SQL

Sintaxis

ALTER AVAILABILITY GROUP group_name 
  {
     SET ( <set_option_spec> ) 
   | ADD DATABASE database_name 
   | REMOVE DATABASE database_name
   | ADD REPLICA ON <add_replica_spec> 
   | MODIFY REPLICA ON <modify_replica_spec>
   | REMOVE REPLICA ON <server_instance>
   | JOIN
   | FAILOVER
   | FORCE_FAILOVER_ALLOW_DATA_LOSS   | ADD LISTENER ‘dns_name’ ( <add_listener_option> )
   | MODIFY LISTENER ‘dns_name’ ( <modify_listener_option> )
   | RESTART LISTENER ‘dns_name’
   | REMOVE LISTENER ‘dns_name’
   | OFFLINE
  }
[ ; ]

<set_option_spec> ::= 
    AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }
  | FAILURE_CONDITION_LEVEL  = { 1 | 2 | 3 | 4 | 5 } 
  | HEALTH_CHECK_TIMEOUT = milliseconds 

<server_instance> ::= 
 { 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }

<add_replica_spec>::=
  <server_instance> WITH
    (
       ENDPOINT_URL = 'TCP://system-address:port',
       AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT },
       FAILOVER_MODE = { AUTOMATIC | MANUAL }
       [ , <add_replica_option> [ ,...n ] ]
    ) 

  <add_replica_option>::=
       BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( { 
          ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } 
        | READ_ONLY_ROUTING_URL = 'TCP://system-address:port' 
          } )
     | PRIMARY_ROLE ( { 
          ALLOW_CONNECTIONS = { READ_WRITE | ALL } 
        | READ_ONLY_ROUTING_LIST = { ( ‘<server_instance>’ [ ,...n ] ) | NONE } 
          } )
     | SESSION_TIMEOUT = seconds 


<modify_replica_spec>::=
  <server_instance> WITH
    (  
       ENDPOINT_URL = 'TCP://system-address:port' 
     | AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT } 
     | FAILOVER_MODE = { AUTOMATIC | MANUAL } 
     | BACKUP_PRIORITY = n
     | SECONDARY_ROLE ( { 
          ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL } 
        | READ_ONLY_ROUTING_URL = 'TCP://system-address:port' 
          } )
     | PRIMARY_ROLE ( { 
          ALLOW_CONNECTIONS = { READ_WRITE | ALL } 
        | READ_ONLY_ROUTING_LIST = { ( ‘<server_instance>’ [ ,...n ] ) | NONE } 
          } )
     | SESSION_TIMEOUT = seconds 
    )  


<add_listener_option> ::=
   {
      WITH DHCP [ ON ( <network_subnet_option> ) ]
    | WITH IP ( { ( <ip_address_option> ) } [ , ...n ] ) [ , PORT = listener_port ]
   }

  <network_subnet_option> ::=
     ‘four_part_ipv4_address’, ‘four_part_ipv4_mask’  

  <ip_address_option> ::=
     { 
        ‘four_part_ipv4_address’, ‘four_part_ipv4_mask’
      | ‘ipv6_address’
     }

<modify_listener_option>::=
    {
       ADD IP ( <ip_address_option> ) 
     | PORT = listener_port
    }

Argumentos

  • group_name
    Especifica el nombre del nuevo grupo de disponibilidad. group_name debe ser un identificador de SQL Server válido y debe ser único en todos los grupos de disponibilidad del clúster de WSFC.

  • AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }
    Especifica una preferencia sobre cómo un trabajo de copia de seguridad debe evaluar la réplica principal cuando elige realizar copias de seguridad. Puede crear un script con un trabajo de copia de seguridad para que se tenga en cuenta la preferencia de copia de seguridad automatizada. Es importante entender que SQL Server no aplica la preferencia, por lo que las copias de seguridad ad hoc no resultan afectadas.

    Solo se admite en la réplica principal.

    Éstos son sus valores:

    • PRIMARY
      Especifica que las copias de seguridad deben realizarse siempre en la réplica principal. Esta opción es útil si necesita usar características de copia de seguridad, como crear copias de seguridad diferenciales, que no se admiten cuando la copia de seguridad se ejecuta en una réplica secundaria.

      Nota importanteImportante

      Si piensa usar el trasvase de registros para preparar cualquier base de datos secundaria de un grupo de disponibilidad, establezca la preferencia de copia de seguridad automatizada en Principal hasta que todas las bases de datos secundarias se hayan preparado y combinado con el grupo de disponibilidad.

    • SECONDARY_ONLY
      Especifica que las copias de seguridad no deben realizarse nunca en la réplica principal. Si la réplica principal es la única réplica en línea, no se debe realizar la copia de seguridad.

    • SECONDARY
      Especifica que las copias de seguridad se deben realizar en una réplica secundaria a menos que la réplica principal sea la única réplica en línea. En ese caso, la copia de seguridad se debe realizar en la réplica principal. Este es el comportamiento predeterminado.

    • NONE
      Especifica que, de acuerdo con sus preferencias, los trabajos de copia de seguridad omitan el rol de las réplicas de disponibilidad cuando la réplica realiza copias de seguridad. Tenga en cuenta que los trabajos de copia de seguridad pueden considerar otros factores, como la prioridad de copia de seguridad de cada réplica de disponibilidad junto con su estado operativo y de conexión.

    Nota importanteImportante

    No se aplica el valor AUTOMATED_BACKUP_PREFERENCE. La interpretación de esta preferencia depende de la lógica, si existe, del script con los trabajos de copia de seguridad ejecutado para las bases de datos de un grupo de disponibilidad dado. La configuración de preferencia de copia de seguridad automatizada no tiene ningún efecto sobre las copias de seguridad ad hoc. Para obtener más información, vea Configurar la copia de seguridad en réplicas de disponibilidad (SQL Server).

    [!NOTA]

    Para ver la preferencia de copia de seguridad automatizada de un grupo de disponibilidad existente, seleccione la columna automated_backup_preference o automated_backup_preference_desc de la vista del catálogo sys.availability_groups. Además, se puede usar sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) para determinar la réplica de copia de seguridad preferida. Esta función siempre devolverá 1 para al menos una de las réplicas, incluso cuando AUTOMATED_BACKUP_PREFERENCE = NONE.

  • FAILURE_CONDITION_LEVEL = { 1 | 2 | 3 | 4 | 5 }
    Especifica qué condiciones de error desencadenarán una conmutación por error automática para este grupo de disponibilidad. FAILURE_CONDITION_LEVEL se establece en el nivel de grupo, pero solo se aplica a las réplicas de disponibilidad que tienen configurado el modo de disponibilidad de confirmación sincrónica (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT). Además, las condiciones de error pueden desencadenar una conmutación automática por error solamente si las réplicas principal y secundaria están configuradas para el modo de conmutación automática por error (FAILOVER_MODE = AUTOMATIC) y la réplica secundaria está sincronizada actualmente con la réplica principal.

    Solo se admite en la réplica principal.

    Los niveles de condición de error (1-5) abarcan desde el nivel menos restrictivo (1) al más restrictivo (5). Un nivel de condición dado abarca todos los niveles menos restrictivos. Así pues, el nivel de condición más estricto (el nivel 5) incluye los cuatro niveles de condición menos restrictivos (1-4), el nivel 4 incluye los niveles 1-3, y así sucesivamente. En la tabla siguiente se describe la condición de error correspondiente a cada nivel.

    Nivel

    Condición de error

    1

    Especifica que se debe iniciar una conmutación por error automática en los casos siguientes:

    2

    Especifica que se debe iniciar una conmutación por error automática en los casos siguientes:

    • La instancia de SQL Server no se conecta al clúster y se ha superado el umbral de HEALTH_CHECK_TIMEOUT del grupo de disponibilidad especificado por el usuario.

    • La réplica de disponibilidad tiene un estado de error.

    3

    Especifica que se debe iniciar una conmutación automática por error en caso de errores internos de SQL Server graves, como bloqueos por subproceso huérfanos, infracciones graves de acceso de escritura o un volcado excesivo.

    Este es el comportamiento predeterminado.

    4

    Especifica que se debe iniciar una conmutación automática por error en caso de errores internos de SQL Server moderados, tales como una condición persistente de memoria insuficiente en el grupo de recursos de servidor interno de SQL Server.

    5

    Especifica que se debe iniciar una conmutación por error automática en el caso de condiciones de error designadas, incluidas las siguientes:

    • Se han agotado los subprocesos de trabajo del motor de SQL.

    • Detección de un interbloqueo irresoluble.

    [!NOTA]

    La falta de respuesta de una instancia de SQL Server a solicitudes del cliente no se aplica a los grupos de la disponibilidad.

    Los valores de FAILURE_CONDITION_LEVEL y HEALTH_CHECK_TIMEOUT definen una directiva flexible de conmutación por error para un grupo dado. Esta directiva flexible de conmutación por error proporciona mayor control sobre las condiciones que deben causar una conmutación por error automática. Para obtener más información, vea Directiva de conmutación por error flexible para conmutación automática por error de un grupo de disponibilidad (SQL Server).

  • HEALTH_CHECK_TIMEOUT = milliseconds
    Especifica el tiempo de espera (en milisegundos) para que el procedimiento almacenado sp_server_diagnostics devuelva información de estado del servidor antes de que el clúster de WSFC asuma que la instancia del servidor está inactiva o bloqueada. HEALTH_CHECK_TIMEOUT se establece en el nivel de grupo, pero solo se aplica a réplicas de disponibilidad que tienen configurado el modo de confirmación sincrónica con conmutación de error automática (AVAILIBILITY_MODE = SYNCHRONOUS_COMMIT). Además, el tiempo de espera de comprobación del estado puede desencadenar una conmutación por error automática solamente si las réplicas principal y secundaria están configuradas para el modo de conmutación por error automático (FAILOVER_MODE = AUTOMATIC) y la réplica secundaria está sincronizada actualmente con la réplica principal.

    El valor predeterminado de HEALTH_CHECK_TIMEOUT es 30000 milisegundos (30 segundos). El valor mínimo es 15000 milisegundos (15 segundos) y el valor máximo es 4294967295 milisegundos.

    Solo se admite en la réplica principal.

    Nota importanteImportante

    sp_server_diagnostics no realiza comprobaciones de estado en el nivel de base de datos.

  • ADD DATABASE database_name
    Especifica una lista de una o más bases de datos de usuario que desea agregar al grupo de disponibilidad. Es preciso que estas bases de datos residan en la instancia de SQL Server que hospeda la réplica principal actual. Puede especificar varias bases de datos para un grupo de disponibilidad, pero cada base de datos puede pertenecer a solo un grupo de disponibilidad. Para obtener información acerca del tipo de bases de datos que un grupo de disponibilidad puede admitir, vea Requisitos previos, restricciones y recomendaciones para Grupos de disponibilidad AlwaysOn (SQL Server). Para saber qué bases de datos locales pertenecen a un grupo de disponibilidad, vea la columna replica_id en la vista de catálogo sys.databases.

    Solo se admite en la réplica principal.

    [!NOTA]

    Una vez haya creado la disponibilidad del grupo, deberá conectarse a cada instancia del servidor que hospede una réplica secundaria y, posteriormente, preparar cada base de datos secundaria y combinarla con la disponibilidad de grupo. Para obtener más información, vea Iniciar el movimiento de datos en una base de datos secundaria AlwaysOn (SQL Server).

  • REMOVE DATABASE database_name
    Quita la base de datos principal especificada y las bases de datos secundarias correspondientes del grupo de disponibilidad. Solo se admite en la réplica principal.

    Para obtener información acerca de los pasos recomendados después de quitar una base de datos de disponibilidad de un grupo de disponibilidad, vea Quitar una base de datos principal de un grupo de disponibilidad (SQL Server).

  • ADD REPLICA ON
    Especifica de una a cuatro instancias de SQL Server para que hospeden las réplicas secundarias de un grupo de disponibilidad. Cada réplica se especifica mediante la dirección de su instancia de servidor seguida de una cláusula WITH (…).

    Solo se admite en la réplica principal.

    Debe unir cada réplica secundaria nueva al grupo de disponibilidad. Para obtener más información, vea la descripción de la opción JOIN, más adelante en esta sección.

  • <instancia_servidor>
    Especifica la dirección de la instancia de SQL Server que sea el host para la réplica. El formato de la dirección depende de si la instancia es la instancia predeterminada o una instancia con nombre y de si es una instancia independiente o una instancia de clúster de conmutación por error (FCI). La sintaxis es la siguiente:

    { 'system_name[\instance_name]' | 'FCI_network_name[\instance_name]' }

    Los componentes de esta dirección son los siguientes:

    • system_name
      Es el nombre de NetBIOS del equipo en el que reside la instancia de destino de SQL Server. Este equipo debe ser un nodo de WSFC.

    • FCI_network_name
      Es el nombre de red que se utiliza para tener acceso a un clúster de conmutación por error de SQL Server. Utilice este argumento si la instancia de servidor participa como asociado de conmutación por error de SQL Server. La ejecución de SELECT @@SERVERNAME en una instancia de servidor de FCI devuelve la cadena 'FCI_network_name[\instance_name]' completa (que es el nombre completo de la réplica).

    • instance_name
      Es el nombre de una instancia de SQL Server hospedada por system_name o FCI_network_name y que tiene AlwaysOn habilitado. En el caso de una instancia de servidor predeterminada, instance_name es opcional. El nombre de la instancia no distingue mayúsculas de minúsculas. En una instancia de servidor independiente, este nombre de valor es el mismo que el valor devuelto mediante la ejecución de SELECT @@SERVERNAME.

    • \
      Es un separador que solo se utiliza cuando se especifica instance_name, para separarlo de system_name o de FCI_network_name.

    Para obtener información sobre los requisitos previos para los nodos y las instancias de servidor de WSFC, vea Requisitos previos, restricciones y recomendaciones para Grupos de disponibilidad AlwaysOn (SQL Server).

  • ENDPOINT_URL ='TCP://system-address:port'
    Especifica la ruta de acceso de la dirección URL para el extremo de creación de reflejo de la base de datos en la instancia de SQL Server que va a hospedar a la réplica de disponibilidad que va a agregar o modificar.

    ENDPOINT_URL es obligatorio en la cláusula ADD REPLICA ON y opcional en la cláusula MODIFY REPLICA ON. Para obtener más información, vea Especificar la dirección URL del extremo al agregar o modificar una réplica de disponibilidad (SQL Server).

  • 'TCP://system-address:port'
    Determina una dirección URL para especificar una dirección URL del extremo o una dirección URL de enrutamiento de solo lectura. Los parámetros de la dirección URL son como sigue:

    • system-address
      Es una cadena, como un nombre de sistema, un nombre de dominio completo o una dirección IP, que identifica sin ambigüedad el equipo de destino.

    • port
      Es un número de puerto que está asociado al extremo de creación de reflejo de la instancia del servidor (para la opción de ENDPOINT_URL) o en el número de puerto que utiliza Motor de base de datos de la instancia del servidor (para la opción de READ_ONLY_ROUTING_URL).

  • AVAILABILITY_MODE = { SYNCHRONOUS_COMMIT | ASYNCHRONOUS_COMMIT }
    Especifica si la réplica principal tiene que esperar a que la réplica secundaria confirme la protección (escritura) de los registros en el disco para poder confirmar la transacción en una base de datos principal dada. Las transacciones realizadas en diferentes bases de datos en la misma réplica principal se pueden confirmar de manera independiente.

    • SYNCHRONOUS_COMMIT
      Especifica que la réplica principal esperará a confirmar las transacciones hasta que se hayan protegido en la réplica secundaria (modo de confirmación sincrónica). Puede especificar SYNCHRONOUS_COMMIT hasta para tres réplicas, incluida la réplica principal.

    • ASYNCHRONOUS_COMMIT
      Especifica que la réplica principal confirma las transacciones sin esperar a que esta réplica secundaria proteja el registro (modo de disponibilidad de confirmación sincrónica). Puede especificar ASYNCHRONOUS_COMMIT hasta para cinco réplicas de disponibilidad, incluida la réplica principal.

    AVAILABILITY_MODE es obligatorio en la cláusula ADD REPLICA ON y opcional en la cláusula MODIFY REPLICA ON. Para obtener más información, vea Modos de disponibilidad (grupos de disponibilidad AlwaysOn).

  • FAILOVER_MODE = { AUTOMATIC | MANUAL }
    Especifica el modo de conmutación por error de la réplica de disponibilidad que está definiendo.

    • AUTOMATIC
      Habilita la conmutación por error automática. AUTOMATIC solo se admite si se especifica también AVAILABILITY_MODE = SYNCHRONOUS_COMMIT. Puede especificar AUTOMATIC para dos réplicas de disponibilidad, incluida la réplica principal.

      [!NOTA]

      Las instancias de clúster de conmutación por error (FCI) de SQL Server no admiten la conmutación automática por error de grupos de disponibilidad, por lo tanto, todas las réplicas de disponibilidad hospedadas por un FCI solo se pueden configurar para la conmutación por error manual.

    • MANUAL
      Permite que el administrador de la base de datos habilite la conmutación por error manual o la conmutación manual forzada (conmutación por error forzada).

    FAILOVER_MODE es obligatorio en la cláusula ADD REPLICA ON y opcional en la cláusula MODIFY REPLICA ON. Existen dos tipos de conmutación por error manual, la conmutación por error manual sin pérdida de datos y la conmutación por error forzada (con pérdida de datos posible), que se admiten en diferentes condiciones. Para obtener más información, vea Conmutación por error y modos de conmutación por error (grupos de disponibilidad AlwaysOn).

  • BACKUP_PRIORITY **=**n
    Especifica la prioridad para realizar copias de seguridad en esta réplica en relación con las otras réplicas del mismo grupo de disponibilidad. El valor es un número entero en el rango de 0..100. Estos valores tienen los significados siguientes:

    • 1..100 indica que la réplica de disponibilidad se podría elegir para realizar copias de seguridad. 1 indica la prioridad mínima y 100 indica la prioridad máxima. Si BACKUP_PRIORITY = 1, la réplica de disponibilidad se elegiría para realizar copias de seguridad solamente si no hay réplicas más prioritarias disponibles actualmente.

    • 0 indica que esta réplica de disponibilidad nunca se elegirá para realizar copias de seguridad. Esto es útil, por ejemplo, para una réplica de disponibilidad remota en la que no desee nunca realizar la conmutación por error para las copias de seguridad.

    Para obtener más información, vea Secundarias activas: copia de seguridad en las réplicas secundarias (grupos de disponibilidad AlwaysOn).

  • SECONDARY_ROLE ( … )
    Especifica la configuración específica del rol que se aplicará si esta réplica de disponibilidad posee actualmente el rol secundario (es decir, siempre que sea una réplica secundaria). Dentro de los paréntesis, especifique una o ambas de las opciones de rol secundario. Si se especifican ambas, utilice una lista separada por comas.

    Las opciones de rol secundario son las siguientes:

    • ALLOW_CONNECTIONS = { NO | READ_ONLY | ALL }
      Especifica si las bases de datos de una réplica de disponibilidad determinada que está realizando el rol secundario (es decir, actuando como réplica secundaria) pueden aceptar conexiones de los clientes; uno de los tipos de conexión siguientes:

      • NO
        No se permiten conexiones de usuario a las bases de datos secundarias de esta réplica. No están disponibles para acceso de lectura. Este es el comportamiento predeterminado.

      • READ_ONLY
        Solo se permiten conexiones con las bases de datos de la réplica secundaria donde la propiedad Application Intent se establece en ReadOnly. Para obtener más información acerca de esta propiedad, vea Usar palabras clave de cadena de conexión con SQL Server Native Client.

      • ALL
        Se permiten todas las conexiones con las bases de datos de la réplica secundaria para acceso de solo lectura.

      Para obtener más información, vea Secundarias activas: réplicas secundarias legibles (grupos de disponibilidad AlwaysOn).

    • READ_ONLY_ROUTING_URL = 'TCP://system-address:port'
      Especifica la dirección URL que se va a usar para enrutar las solicitudes de conexión de intención de lectura de enrutamiento para esta réplica de disponibilidad. Es la dirección URL en la que escucha el motor de base de datos de SQL Server. Normalmente, la instancia predeterminada del motor de base de datos de SQL Server escucha en el puerto TCP 1433.

      Para una instancia con nombre, puede obtener el número de puerto si consulta las columnas port y type_desc de la vista de administración dinámica de sys.dm_tcp_listener_states. La instancia de servidor usa el agente de escucha de Transact-SQL (type_desc = 'TSQL').

      Para obtener más información sobre cómo calcular la dirección URL de enrutamiento de solo lectura para una réplica de disponibilidad, vea Calcular read_only_routing_url para AlwaysOn.

      [!NOTA]

      En el caso de una instancia con nombre de SQL Server, se debe configurar el agente de escucha de Transact-SQL para que use un puerto específico. Para obtener más información, vea Configurar un servidor para que escuche en un puerto TCP específico (Administrador de configuración de SQL Server).

  • PRIMARY_ROLE ( … )
    Especifica la configuración específica del rol que se aplicará si esta réplica de disponibilidad posee actualmente el rol primario (es decir, siempre que sea la réplica primaria). Dentro de los paréntesis, especifique una o ambas de las opciones de rol primarias. Si se especifican ambas, utilice una lista separada por comas.

    El rol principal de las opciones es el siguiente:

    • ALLOW_CONNECTIONS = { READ_WRITE | ALL }
      Especifica el tipo de conexión que la base de datos de una réplica de disponibilidad determinada que está realizando el rol principal (es decir, actuando como réplica principal) puede aceptar de los clientes; uno de los tipos de conexión siguientes:

      • READ_WRITE
        No se permiten las conexiones en las que la propiedad de conexión Application Intent esté establecida en ReadOnly. Cuando la propiedad Application Intent está establecida en ReadWrite o no tiene ningún valor, se permite la conexión. Para obtener más información sobre propiedad de conexión Application Intent, vea Usar palabras clave de cadena de conexión con SQL Server Native Client.

      • ALL
        Se permiten todas las conexiones con las bases de datos de la réplica principal. Este es el comportamiento predeterminado.

    • READ_ONLY_ROUTING_LIST = { (‘<server_instance>’ [ ,...n ] ) | NONE }
      Especifica una lista separada por comas de instancias de servidor que hospedan réplicas de disponibilidad para este grupo de disponibilidad y que cumplen los requisitos siguientes al ejecutarse con el rol secundario:

      • Está configurado para permitir todas las conexiones o las conexiones de solo lectura (vea el argumento ALLOW_CONNECTIONS de la opción SECONDARY_ROLE de más arriba).

      • Tiene definida su dirección URL de enrutamiento de solo lectura (vea el argumento READ_ONLY_ROUTING_URL de la opción de SECONDARY_ROLE de más arriba).

      Estos son los valores de READ_ONLY_ROUTING_LIST:

      • <instancia_servidor>
        Especifica la dirección de la instancia de SQL Server que es el host para una réplica de disponibilidad que es una réplica secundaria inteligible cuando se ejecuta en el rol secundario.

        Use una lista separada por comas para especificar todas las instancias del servidor que pueden hospedar una réplica secundaria inteligible. El enrutamiento de solo lectura seguirá el orden en que las instancias de servidor se especifican en la lista. Si incluye la instancia del servidor de host de una réplica en la lista de enrutamiento de solo lectura de la réplica, por lo general, resulta recomendable colocar esta instancia del servidor al final de la lista, ya que las conexiones de intención de lectura van a una réplica secundaria, si hay alguna disponible. .

      • NONE
        Especifica que cuando esta réplica de disponibilidad es la réplica primaria, no se admitirá en el enrutamiento de solo lectura. Este es el comportamiento predeterminado. Cuando se utiliza con MODIFY REPLICA ON, este valor deshabilita una lista existente, en caso de que la hubiera.

  • SESSION_TIMEOUT **=**seconds
    Especifica el período de espera de la sesión en segundos. Si no especifica esta opción, el período equivale a 10 segundos de forma predeterminada. El valor mínimo es de 5 segundos.

    Nota importanteImportante

    Es recomendable que mantenga el período de espera en 10 segundos o más.

    Para obtener más información sobre el tiempo de espera de la sesión, vea Información general de los grupos de disponibilidad AlwaysOn (SQL Server).

  • MODIFY REPLICA ON
    Modifica alguna de las réplicas del grupo de disponibilidad. La lista de réplicas que se van a modificar contiene la dirección de la instancia de servidor y una cláusula WITH (…) para cada réplica.

    Solo se admite en la réplica principal.

  • REMOVE REPLICA ON
    Quita la réplica secundaria especificada del grupo de disponibilidad. La réplica principal actual no se puede quitar de un grupo de disponibilidad. Cuando se quita, la réplica deja de recibir datos. Se quitan sus bases de datos secundarias del grupo de disponibilidad y se activa el estado RESTORING.

    Solo se admite en la réplica principal.

    [!NOTA]

    Si quita una réplica mientras no está disponible o está en estado de error, cuando vuelva a conectarla verá que ya no pertenece al grupo de disponibilidad.

  • JOIN
    Hace que la instancia de servidor local hospede una réplica secundaria en el grupo de disponibilidad especificado.

    Solo se admite en una réplica secundaria que no se haya combinado aún con un grupo de disponibilidad.

    Para obtener más información, vea Combinar una réplica secundaria con un grupo de disponibilidad (SQL Server).

  • FAILOVER
    Inicia una conmutación por error manual del grupo de disponibilidad sin pérdida de datos a la réplica secundaria a la que está conectado. La réplica en la que se escribe un comando de conmutación por error se denomina destino de conmutación por error. El destino de la conmutación por error asumirá el rol principal y recuperará su copia de cada base de datos y las pondrá en línea como las nuevas bases de datos principales. La réplica principal anterior realiza la transición de forma simultánea al rol secundario y sus bases de datos se convierten en bases de datos secundarias, además quedan suspendidas inmediatamente. Potencialmente, estos roles se pueden alternar mediante una serie de errores.

    Solo se admite en una réplica secundaria de confirmación sincrónica que se sincronice actualmente con la réplica primaria. Tenga en cuenta que para sincronizar réplicas secundarias, la réplica principal también debe ejecutarse en modo de confirmación sincrónica.

    [!NOTA]

    Un comando de conmutación por error realiza la devolución en cuanto el destino de la conmutación por error acepte el comando. Sin embargo, la recuperación de la base de datos se produce de forma asincrónica cuando el grupo de disponibilidad ha terminado la conmutación por error.

    Para obtener información acerca de las limitaciones, los requisitos previos y las recomendaciones para realizar una conmutación por error manual planeada, vea Realizar una conmutación por error manual planeada de un grupo de disponibilidad (SQL Server).

  • FORCE_FAILOVER_ALLOW_DATA_LOSS

    Nota de advertenciaAdvertencia

    Forzar la conmutación por error, que podría causar pérdida de datos, es estrictamente un método de recuperación ante desastres. Por lo tanto, es absolutamente recomendable que solo fuerce la conmutación por error si la réplica principal ya no se está ejecutando, si asume el riesgo de perder datos o si debe restaurar el servicio al grupo de disponibilidad inmediatamente.

    Solo se admite en una réplica cuyo rol esté en el estado SECONDARY o RESOLVING. La réplica en la que se escribe un comando de conmutación por error se denomina destino de conmutación por error.

    Fuerza la conmutación por error del grupo de disponibilidad, con posible pérdida de datos, al destino de la conmutación por error. El destino de la conmutación por error asumirá el rol principal y recuperará su copia de cada base de datos y las pondrá en línea como las nuevas bases de datos principales. En cualquier réplica secundaria restante, cada base de datos secundaria se suspende hasta que se reanude manualmente. Cuando la réplica principal anterior está disponible, cambiará al rol secundario y sus bases de datos se convertirán en bases de datos secundarias suspendidas.

    [!NOTA]

    Un comando de conmutación por error realiza la devolución en cuanto el destino de la conmutación por error acepte el comando. Sin embargo, la recuperación de la base de datos se produce de forma asincrónica cuando el grupo de disponibilidad ha terminado la conmutación por error.

    Para obtener información acerca de las limitaciones, los requisitos previos y las recomendaciones para forzar la conmutación por error y el efecto que tiene una conmutación por error forzada en las bases de datos que antes eran principales en el grupo de disponibilidad, vea Realizar una conmutación por error manual forzada de un grupo de disponibilidad (SQL Server).

  • ADD LISTENER ‘dns_name’( <add_listener_option> )
    Define un nuevo agente de escucha para este grupo de disponibilidad. Solo se admite en la réplica principal.

    Nota importanteImportante

    Antes de crear el primer agente de escucha, se recomienda encarecidamente que lea Crear o configurar un agente de escucha del grupo de disponibilidad (SQL Server).

    Después de crear un agente de escucha para un grupo de disponibilidad determinado, es absolutamente recomendable que haga lo siguiente:

    • Pida al administrador de red que reserve la dirección IP del agente de escucha para su uso exclusivo.

    • Proporcione el nombre del host DNS del agente de escucha a los desarrolladores de aplicaciones para que lo usen en las cadenas de conexión cuando soliciten conexiones cliente a este grupo de disponibilidad.

  • dns_name
    Especifica el nombre de host DNS del agente de escucha del grupo de disponibilidad. El nombre DNS del agente de escucha debe ser único en el dominio y en NetBIOS.

    dns_name es un valor de cadena. Este nombre solo puede contener caracteres alfanuméricos, guiones (-) y caracteres de subrayado (_), en cualquier orden. Los nombres de host DNS no distinguen entre mayúsculas y minúsculas. La longitud máxima es de 63 caracteres.

    Es recomendable que especifique una cadena que tenga sentido. Por ejemplo, para un grupo de disponibilidad denominado AG1, un nombre de host DNS significativo sería ag1-listener.

    Nota importanteImportante

    NetBIOS reconoce solo los 15 primeros caracteres en dns_name. Si tiene dos clústeres de WSFC controlados por la misma instancia de Active Directory e intenta crear agentes de escucha del grupo de disponibilidad en los dos clústeres utilizando nombres con más de 15 caracteres y un prefijo idéntico de 15 caracteres, obtendrá un error notificando que el recurso de nombre de red virtual no se pudo poner en línea. Para obtener información acerca de las reglas de nomenclatura de prefijos para los nombres DNS, vea Asignación de nombres de dominio.

  • <add_listener_option>
    ADD LISTENER toma una de las siguientes opciones:

    • WITH DHCP [ ON { (‘four_part_ipv4_address’,‘four_part_ipv4_mask’) } ]
      Especifica que el agente de escucha del grupo de disponibilidad utilizará el protocolo DHCP (Protocolo de configuración dinámica de host). Opcionalmente, utilice la cláusula ON para identificar la red en la que se creará esta escucha. DHCP está limitado a una sola subred que se usa para cada instancia del servidor que hospeda una réplica de disponibilidad en el grupo de disponibilidad.

      Nota importanteImportante

      No se recomienda DHCP en el entorno de producción. Si hay un tiempo de inactividad y expira la concesión de IP para DHCP, se necesitará más tiempo para registrar la nueva dirección IP de red DHCP que está asociada con el nombre DNS de escucha, lo que puede afectar a la conectividad de cliente. Sin embargo, DHCP es adecuado para configurar el entorno de desarrollo y pruebas para comprobar características básicas de los grupos de disponibilidad y para la integración con las aplicaciones.

      Por ejemplo:

      WITH DHCP ON ('10.120.19.0','255.255.254.0')

    • WITH IP ( { (‘four_part_ipv4_address’,‘four_part_ipv4_mask’) | (‘ipv6_address’) } [ , ...n ] ) [ , PORT **=**listener_port ]
      Especifica que, en lugar de utilizar DHCP, la escucha del grupo de disponibilidad utilizará una o más direcciones IP estáticas. Para crear un grupo de disponibilidad a través de varias subredes, cada subred requiere una dirección IP estática en la configuración de la escucha. Para una subred determinada, la dirección IP estática puede ser una dirección IPv4 o una dirección IPv6. Póngase en contacto con el administrador de red para obtener una dirección IP estática para cada subred que hospeda una réplica de disponibilidad para el nuevo grupo de disponibilidad.

      Por ejemplo:

      WITH IP ( ('10.120.19.155','255.255.254.0') )

  • four_part_ipv4_address
    Especifica una dirección IPv4 de cuatro partes para el agente de escucha de un grupo de disponibilidad. Por ejemplo, 10.120.19.155.

  • four_part_ipv4_mask
    Especifica una máscara IPv4 de cuatro partes para el agente de escucha de un grupo de disponibilidad. Por ejemplo, 255.255.254.0.

  • ipv6_address
    Especifica una dirección IPv6 para el agente de escucha de un grupo de disponibilidad. Por ejemplo, 2001::4898:23:1002:20f:1fff:feff:b3a3.

  • PORT = listener_port
    Especifica el número de puerto (listener_port) que va a usar el agente de escucha de un grupo de disponibilidad especificado por una cláusula WITH IP. PORT es opcional.

    Se admite el número de puerto predeterminado, 1433. Sin embargo, si le preocupa la seguridad, le recomendamos que use otro número de puerto.

    Por ejemplo: WITH IP ( ('2001::4898:23:1002:20f:1fff:feff:b3a3') ) , PORT = 7777

  • MODIFY LISTENER ‘dns_name’  ( <modify_listener_option> )
    Modifica el agente de escucha de un grupo de disponibilidad existente para este grupo de disponibilidad. Solo se admite en la réplica principal.

  • <modify_listener_option>
    MODIFY LISTENER toma una de las siguientes opciones:

    • ADD IP { (‘four_part_ipv4_address’,  ‘four_part_ipv4_mask’) | (‘dns_nameipv6_address’) }
      Agrega la dirección IP especificada al agente de escucha del grupo de disponibilidad especificado por dns_name.

    • PORT = listener_port
      Vea la descripción de este argumento anteriormente en esta sección.

  • RESTART LISTENER ‘dns_name’
    Reinicia la escucha asociada con el nombre DNS especificado. Solo se admite en la réplica principal.

  • REMOVE LISTENER ‘dns_name’
    Quita la escucha asociada con el nombre DNS especificado. Solo se admite en la réplica principal.

  • OFFLINE
    Pone sin conexión un grupo de disponibilidad que está en línea. No se produce ninguna pérdida de datos para las bases de datos con confirmación sincrónica.

    Cuando un grupo de disponibilidad pasa a estar sin conexión, sus bases de datos dejan de estar disponibles para los clientes y no puede volver a poner el grupo de disponibilidad en línea. Por tanto, use la opción OFFLINE solo durante la migración entre clústeres de Grupos de disponibilidad AlwaysOn, al migrar recursos de grupo de disponibilidad a un nuevo clúster de WSFC.

    Para obtener más información, vea Poner sin conexión un grupo de disponibilidad (SQL Server).

Icono de flecha usado con el vínculo Volver al principio[Arriba]

Requisitos previos y restricciones

Para obtener información sobre los requisitos previos y las restricciones en las réplicas de disponibilidad y en sus instancias de servidor host y equipos, vea Requisitos previos, restricciones y recomendaciones para Grupos de disponibilidad AlwaysOn (SQL Server).

Para obtener información acerca de las restricciones sobre las instrucciones AVAILABILITY GROUP de Transact-SQL, vea Información general sobre instrucciones Transact-SQL para grupos de disponibilidad de AlwaysOn (SQL Server).

Seguridad

Permisos

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.

Ejemplos

A.Unir una réplica secundaria a un grupo de disponibilidad

En el ejemplo siguiente se une al grupo de disponibilidad AccountsAG una réplica secundaria a la que está conectado.

ALTER AVAILABILITY GROUP AccountsAG JOIN;
GO

B.Forzar la conmutación por error de un grupo de disponibilidad

En el ejemplo siguiente se fuerza al grupo de disponibilidad AccountsAG a que realice una conmutación por error para la réplica secundaria a la que está conectado.

ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
GO

Vea también

Referencia

CREATE AVAILABILITY GROUP (Transact-SQL)

ALTER DATABASE SET HADR (Transact-SQL)

DROP AVAILABILITY GROUP (Transact-SQL)

sys.availability_replicas (Transact-SQL)

sys.availability_groups (Transact-SQL)

Conceptos

Solucionar problemas de configuración de grupos de disponibilidad AlwaysOn (SQL Server)

Información general de los grupos de disponibilidad AlwaysOn (SQL Server)

Agentes de escucha del grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server)