1. Comprensión de los grupos de disponibilidad AlwaysOn
1.1 Qué es y cómo funciona
Los grupos de disponibilidad Always On (AG) son una SQL Server Empresa alta disponibilidad y una solución de recuperación ante desastres que opera a nivel de base de datos. Un grupo de disponibilidad agrupa una o más bases de datos de usuarios en una única unidad de conmutación por error y las replica en hasta ocho réplicas secundarias mediante el envío continuo de registros de transacciones. Cuando la réplica principal falla, una réplica secundaria síncrona designada asume automáticamente el control, restaurando el acceso en segundos sin necesidad de almacenamiento compartido ni intervención manual.
1.2 Grupos de disponibilidad AlwaysOn vs. Instancias de clúster de conmutación por error
SQL Server Always On incluye dos tecnologías distintas: grupos de disponibilidad (AG) e instancias de clúster de conmutación por error (FCI):
| Grupos de disponibilidad siempre activos | Instancias de clúster de conmutación por error Always On | |
|---|---|---|
| Ámbito de conmutación por error | Nivel de base de datos | Nivel de instancia (todas las bases de datos conmutan por error juntas) |
| Replicación de datos | Replicación basada en registros para cada secundario | Ninguno: todos los nodos comparten el mismo almacenamiento |
| Almacenamiento compartido | No se requiere | Obligatorio (red de área de almacenamiento (SAN), iSCSI, S2D o SMB) |
| Secundarios legibles | Sí | No |
| Recuperación de desastres | Integrado (réplicas asincrónicas en todos los sitios) | No integrado sin emparejamiento con AG |
Cuándo utilizar cada uno: Utilice FCI cuando necesite conmutación por error a nivel de instancia y ya cuente con una infraestructura de almacenamiento compartido. Utilice AG cuando necesite granularidad a nivel de base de datos, recursos secundarios legibles o recuperación ante desastres. Para most Protección completa, combine ambos: ejecute cada réplica como un nodo FCI y vincúlelos en un AG.
1.3 Beneficios y limitaciones
Beneficios:
- Conmutación por error automática con objetivo de tiempo de recuperación (RTO) cercano a cero para réplicas sincrónicas;
- pérdida de datos cero (Objetivo de punto de recuperación (RPO) = 0) en modo de confirmación sincrónica;
- no se requiere almacenamiento compartido: cada réplica utiliza almacenamiento local independiente;
- Los secundarios legibles descargan las cargas de trabajo de informes y copias de seguridad del primario;
- Admite alta disponibilidad (HA) local y recuperación ante desastres (DR) entre sitios dentro de una única configuración.
Limitaciones:
- Requiere clústeres de conmutación por error de Windows Server en todas las réplicas;
- Edición Enterprise para un conjunto completo de funciones (la Edición Estándar admite Basic AG con restricciones significativas);
- El modo de confirmación sincrónica agrega latencia a las operaciones de escritura proporcional al tiempo de ida y vuelta de la red;
- Los inicios de sesión, los trabajos del Agente SQL y los servidores vinculados no se sincronizan automáticamente en SQL Server 2019 y anteriores (resuelto en SQL Server 2022 contenía grupos de disponibilidad).
2. Arquitectura de grupos de disponibilidad Always On
2.1 Componentes y conceptos básicos
2.1.1 Bases de datos de disponibilidad
Las bases de datos de disponibilidad son las bases de datos de usuarios que participan en un grupo de disponibilidad. Estas bases de datos deben cumplir requisitos específicos: deben usar el modelo de recuperación completa, contar con una copia de seguridad completa y existir en la réplica principal antes de agregarse a un grupo de disponibilidad.
Cuando una base de datos se une a un grupo de disponibilidad, pasa a formar parte de un conjunto sincronizado que conmuta por error como una unidad. Todas las bases de datos de un grupo de disponibilidad comparten el mismo estado de conmutación por error, lo que significa que si la réplica principal falla, todas las bases de datos conmutan por error a la misma réplica secundaria simultáneamente. Esto garantiza la coherencia de las aplicaciones que dependen de varias bases de datos relacionadas.
2.1.2 Réplicas de disponibilidad
Las réplicas de disponibilidad son SQL Server instancias que host Copias de bases de datos de disponibilidad. Cada réplica mantiene su propia copia física de las bases de datos, sincronizada mediante el envío de registros de transacciones. Un grupo de disponibilidad puede contener hasta nueve réplicas: una principal y hasta ocho secundarias.
2.1.3 Réplica primaria
La réplica primaria hostEs la copia de lectura y escritura de las bases de datos de disponibilidad. Todas las modificaciones de datos (INSERTAR, ACTUALIZAR, ELIMINAR) se realizan en la réplica principal. Las aplicaciones cliente se conectan a la réplica principal para todas las operaciones de escritura y, de forma predeterminada, también para las de lectura.
2.1.4 Réplicas secundarias
Réplicas secundarias host Copias de solo lectura de las bases de datos de disponibilidad, mantenidas mediante la aplicación continua de los registros de transacciones recibidos de la réplica principal. Cada réplica secundaria recibe, refuerza y aplica los registros para mantener sus copias de bases de datos sincronizadas con la principal.
2.2 Modos de disponibilidad
2.2.1 Modo de confirmación sincrónica
El modo de confirmación síncrona ofrece protección contra la pérdida de datos cero, ya que requiere que la réplica principal espere la confirmación de que los registros de transacciones se han reforzado en la réplica secundaria antes de confirmar las transacciones. Este modo es esencial para configuraciones de alta disponibilidad donde la pérdida de datos es inaceptable.
2.2.2 Modo de confirmación asincrónica
El modo de confirmación asíncrona prioriza el rendimiento de la réplica principal al permitir que las transacciones se confirmen sin esperar a que las réplicas secundarias confirmen el endurecimiento del registro. Este modo es adecuado para réplicas de recuperación ante desastres o cuando la latencia de la red impide la confirmación síncrona.
La contrapartida es la posible pérdida de datos durante la conmutación por error. Si la réplica principal falla, es posible que algunas transacciones confirmadas no lleguen a la réplica secundaria. La magnitud de la posible pérdida de datos depende del ancho de banda de la red, el rendimiento de la réplica secundaria y el momento del fallo. Las organizaciones deben asumir este riesgo al utilizar el modo asíncrono.
2.3 Tipos de conmutación por error
2.3.1 Conmutación por error automática
La conmutación por error automática permite al grupo de disponibilidad detectar fallos en la réplica principal y convertir automáticamente una réplica secundaria en principal sin intervención del administrador. Esta capacidad minimiza el RTO al eliminar la necesidad de responder manualmente a los fallos.
La conmutación por error automática requiere el modo de confirmación síncrona para garantizar la ausencia total de pérdidas de datos. Cuando está habilitado, el grupo de disponibilidad supervisa continuamente el estado de la réplica principal. Si la réplica principal deja de responder o falla, el clúster de conmutación por error de Windows Server inicia la conmutación por error automática a una réplica secundaria designada.
2.3.2 Conmutación por error manual
La conmutación por error manual permite a los administradores cambiar intencionalmente la función de réplica principal a una réplica secundaria, generalmente para fines de mantenimiento planificado o pruebas. A diferencia de la conmutación por error automática, la conmutación por error manual requiere una acción explícita del administrador para iniciarse.
La conmutación por error manual sin pérdida de datos está disponible para réplicas de confirmación síncrona. El administrador inicia la conmutación por error mediante SQL Server Management Studio, Transact-SQL o PowerShell. La réplica principal termina de procesar las transacciones actuales y envía todos los registros restantes a la tarobtiene un rol secundario y espera confirmación antes de transferir el rol principal.
La conmutación por error manual también puede ocurrir con réplicas de confirmación asincrónica, pero esto requiere una conmutación por error forzada con posible pérdida de datos. Los administradores deben usar la conmutación por error manual forzada solo en situaciones de desastre reales, cuando la réplica principal no esté disponible y la pérdida de datos sea aceptable en comparación con un tiempo de inactividad prolongado.
2.3.3 Conmutación por error forzada
La conmutación por error forzada permite la conmutación por error a una réplica secundaria asíncrona o a una secundaria que no esté completamente sincronizada, con el reconocimiento explícito de la posible pérdida de datos. Esta opción sirve como último recurso cuando la réplica principal no está disponible y no existe una secundaria sincronizada.
2.4 Sincronización de datos
2.4.1 Cómo funciona la sincronización de datos
La sincronización de datos en los grupos de disponibilidad AlwaysOn se realiza mediante el envío continuo de registros de transacciones desde la réplica principal a todas las réplicas secundarias. Esta sincronización basada en registros garantiza la consistencia y permite el almacenamiento independiente para cada réplica.
2.4.2 Registros de transacciones y endurecimiento
El endurecimiento del registro de transacciones es el paso crítico donde los registros se escriben en un almacenamiento duradero en réplicas secundarias. El endurecimiento garantiza que los registros sobrevivan a fallos de las réplicas secundarias y puedan reproducirse durante la recuperación.
2.5 Escala de lectura y réplicas secundarias legibles
2.5.1 Descarga de cargas de trabajo de solo lectura
Las réplicas secundarias legibles permiten a las organizaciones descargar cargas de trabajo de lectura intensiva de la réplica principal, lo que mejora el rendimiento general del sistema y la utilización de recursos. Esta capacidad de escalado de lectura es una de las principales ventajas de los grupos de disponibilidad frente a las soluciones de alta disponibilidad más antiguas.
Las organizaciones deben considerar los requisitos de carga de trabajo de solo lectura al diseñar las configuraciones de los grupos de disponibilidad. Múltiples servidores secundarios legibles pueden distribuir la carga de informes entre varios servidores. Las listas de enrutamiento de solo lectura definen el orden en que los servidores secundarios reciben conexiones con intención de lectura, lo que permite estrategias de balanceo de carga.
2.5.2 Operaciones de respaldo en réplicas secundarias
La ejecución de copias de seguridad en réplicas secundarias reduce la carga de entrada/salida (E/S) y de la CPU en la réplica principal, lo que le permite centrarse en las cargas de trabajo transaccionales. Esta capacidad ayuda a las organizaciones a cumplir con los requisitos de copia de seguridad sin afectar el rendimiento de la producción.
SQL Server Admite copias de seguridad completas de bases de datos, copias de seguridad diferenciales y copias de seguridad del registro de transacciones en réplicas secundarias. Las preferencias de copia de seguridad se pueden configurar para priorizar réplicas secundarias, primarias, solo secundarias o cualquier réplica. El sistema de copias de seguridad selecciona automáticamente la réplica adecuada según estas preferencias y la disponibilidad actual.
Para más detalles sobre SQL Server Copia de seguridad, consulte nuestra guía completa.
2.6 Escuchas del grupo de disponibilidad
2.6.1 ¿Qué es un oyente?
Un receptor de grupo de disponibilidad es un nombre de red virtual (VNN) y una dirección IP que las aplicaciones cliente utilizan para conectarse a las bases de datos del grupo de disponibilidad. El receptor redirige automáticamente las conexiones a la réplica principal actual, eliminando así la necesidad de que las aplicaciones rastreen cuál es el servidor principal en ese momento.
2.6.2 Enrutamiento de la conexión del cliente
El enrutamiento de la conexión del cliente a través del receptor admite intentos de conexión de lectura y escritura y de solo lectura. El receptor examina la solicitud de conexión y la enruta a la réplica adecuada según la intención de la aplicación.
3. Prerrequisitos y requisitos
3.1 Agrupamiento de conmutación por error de Windows Server para grupos de disponibilidad
3.1.1 Fundamentos de la agrupación en clústeres de conmutación por error de Windows Server
Los clústeres de conmutación por error de Windows Server (WSFC) sientan las bases para los grupos de disponibilidad AlwaysOn, ya que gestionan la pertenencia al clúster, la supervisión del estado y la orquestación de la conmutación por error. A diferencia de las instancias de clúster de conmutación por error, los grupos de disponibilidad utilizan WSFC solo para la coordinación del clúster, no para la gestión del almacenamiento compartido.
Cada SQL Server La instancia que participa en un grupo de disponibilidad debe ser un nodo de un clúster WSFC. El clúster gestiona la votación de quórum, la detección del estado del nodo y el estado de los recursos del grupo de disponibilidad. Cuando falla la réplica principal, WSFC coordina el proceso de conmutación por error y actualiza los recursos del clúster para reflejar la nueva réplica principal.
3.1.2 Configuración del quórum del clúster
El quórum del clúster determina qué nodos pueden operar cuando se producen problemas de conectividad de red, lo que evita situaciones de división de funciones donde varios nodos se autoproclaman principales de forma independiente. La configuración del quórum define qué constituye una mayoría de votos para las decisiones del clúster.
Hay varios modos de quórum disponibles para los grupos de disponibilidad:
- La mayoría de nodos utiliza únicamente los votos de los nodos del clúster y funciona bien para clústeres con un número impar de nodos.
- La mayoría de nodos y recursos compartidos de archivos agrega un voto de testigo para compartir archivos, adecuado para clústeres de nodos con números pares.
- La mayoría de nodos y discos utiliza un testigo de disco, pero es menos común para los grupos de disponibilidad ya que no se requiere almacenamiento compartido.
3.1.3 Agrupación en clústeres de múltiples subredes
La agrupación en clústeres multisubred permite que las réplicas de grupos de disponibilidad abarquen diferentes subredes de red, lo que facilita implementaciones distribuidas geográficamente en centros de datos. Esta capacidad es esencial para configuraciones de recuperación ante desastres donde las réplicas se encuentran en ubicaciones separadas.
3.2 SQL Server Requisitos de la edición
3.2.1 Características de la Edición Empresarial
SQL Server La Edición Enterprise ofrece funcionalidad completa de grupos de disponibilidad sin limitaciones. Admite hasta ocho réplicas secundarias, réplicas secundarias legibles, propagación automática, grupos de disponibilidad distribuidos y todas las funciones avanzadas.
3.2.2 Características de la edición estándar (grupos de disponibilidad básica)
SQL Server La edición Standard 2016 y posteriores admiten grupos de disponibilidad básica con limitaciones significativas. Los grupos de disponibilidad básica proporcionan funcionalidades esenciales de alta disponibilidad a un costo menor.ost, adecuado para organizaciones con requisitos más simples.
4. Configuración de grupos de disponibilidad AlwaysOn
4.1 Preparación del entorno
Antes de crear un grupo de disponibilidad, el entorno debe estar preparado adecuadamente con cuentas de Active Directory, configuraciones de servidor e infraestructura de red establecidas.
4.1.1 Configuración del controlador de dominio
El controlador de dominio de Active Directory debe estar configurado para admitir el clúster del grupo de disponibilidad y SQL Server cuentas de servicio.
- Inicie sesión en el controlador de dominio con las credenciales de administrador de dominio.
- Abierto Administrador de servidores y navega a Accesorios -> Directorio activo de usuarios y computadoras.
- Crear una unidad organizativa para SQL Server objetos si no existe uno.
- Verifique que los objetos de computadora de todos los nodos del clúster existan en Active Directory.
- Asegúrese de que los servicios del Sistema de nombres de dominio (DNS) estén configurados correctamente y que todos los nombres de servidor se resuelvan correctamente.
4.1.2 Creación de cuentas de servicio
Cree cuentas de servicio de Active Directory dedicadas para SQL Server servicios en cada nodo.
- Abierto Directorio activo de usuarios y computadoras en el controlador de dominio.
- Haga clic derecho en la unidad organizativa apropiada y seleccione New -> El sistema de reservas de escritorios, interactivo y fácil de usar, ayuda a gestores y empresas a adaptarse a la nueva rutina laboral. El sistema inteligente optimiza espacios y horarios según necesidades reales..
- Introduzca el nombre de la cuenta de servicio (por ejemplo, svc_SQLServer) y configure el Nombre de inicio de sesión del usuario.
- Haga clic en Siguiente e ingrese una contraseña segura.
- Seleccione El usuario no puede cambiar la contraseña y La contraseña nunca expira.
- Haga clic en Siguiente y luego en Acabado para crear la cuenta.
- Repita este procedimiento para cualquier cuenta de servicio adicional que necesite (SQL Server Agente, SSRS, etc.).
4.1.3 Configuración de permisos de administrador
Cuentas de servicio y las cuentas utilizadas para configurar SQL Server Debe tener permisos adecuados en todos los nodos del clúster.
- Inicie sesión en cada servidor de nodo del clúster.
- Abierto Administración de equipos de la Inicie Menú o Administrador de servidores.
- Expandir Usuarios y grupos locales y seleccione Grupos.
- Haga clic con el botón administradores y seleccione Propiedades.
- Haga clic en Agregar la extensión de e ingrese el nombre de la cuenta de servicio.
- Haga clic en Verificar nombres Para validar la cuenta, haga clic en OK.
- Haga clic en OK para cerrar el cuadro de diálogo Propiedades de administradores.
- Repita esto en todos los nodos del clúster.
4.2 Instalación y configuración de WSFC
El clúster de conmutación por error de Windows Server debe estar instalado y configurado en todos los nodos antes de habilitar los grupos de disponibilidad AlwaysOn.
4.2.1 Instalación de la función de clústeres de conmutación por error
Instale la función de clúster de conmutación por error en cada servidor que participará en el grupo de disponibilidad.
- Abierto Administrador de servidores en el primer nodo del clúster.
- Haga clic en Gestionar -> Agregar funciones y funciones.
- Haga clic en Siguiente a través de las pantallas de introducción.
- Seleccione Instalación basada en funciones o funciones y hacer clic en Siguiente.
- Seleccione el servidor local y haga clic Siguiente.
- Omite la pantalla Roles y haz clic Siguiente.
- En la pantalla Características, seleccione Clústeres de conmutación por error.
- Haga clic en Agrega características cuando se le solicite incluir herramientas de gestión.
- Haga clic en Siguiente y luego en Instalar .
- Espere a que se complete la instalación y haga clic Cerrar.
- Repita esto en todos los servidores que participarán en el clúster.
4.2.2 Creación del clúster de conmutación por error
Después de instalar la función de agrupación en clústeres de conmutación por error en todos los nodos, cree el clúster desde un nodo.
- Abierto Administrador de clústeres de conmutación por error desde Administrador de servidores -> Accesorios.
- Haga clic en Crear clúster en el panel Acciones.
- Haga clic en Siguiente en la página Antes de comenzar.
- Haga clic en Explorar y agregue todos los servidores que serán nodos del clúster.
- Haga clic en Siguiente después de agregar todos los nodos.
- Abandonar Ejecutar todas las pruebas (recomendado) Seleccionado y haga clic Siguiente.
- Revise los resultados de la prueba de validación y aborde cualquier error o advertencia.
- Haga clic en Acabado después de que la validación se complete exitosamente.
- Introduzca un nombre para el clúster y una dirección IP.
- Desmarcar Agregue todo el almacenamiento elegible al clúster ya que no se requiere almacenamiento compartido.
- Haga clic en Siguiente y revisar la confirmación.
- Haga clic en Acabado para crear el clúster.
4.2.3 Validación de la configuración del clúster
Valide la configuración del clúster para garantizar que todos los nodos puedan comunicarse correctamente y que el clúster funcione correctamente.
- In Administrador de clústeres de conmutación por error, haga clic derecho en el nombre del clúster.
- Seleccione Validar clúster en el menú.
- Haga clic en Siguiente en la página Antes de comenzar.
- Seleccione Ejecutar todas las pruebas (recomendado) y hacer clic en Siguiente.
- Haga clic en Siguiente para comenzar las pruebas de validación.
- Revise el informe de validación cuando se completen las pruebas.
- Aborde cualquier falla o advertencia identificada en el informe.
- Haga clic en Acabado para cerrar el asistente.
NUNCA instale SQL Server para grupos de disponibilidad
Instalar SQL Server en cada nodo que participará en el grupo de disponibilidad utilizando la opción de instalación independiente.
- Ejecute el SQL Server Medios de instalación en el primer nodo.
- Seleccione New SQL Server instalación independiente.
- Ingrese la clave del producto o seleccione la edición de evaluación.
- Acepte los términos de la licencia y haga clic Siguiente.
- Complete las verificaciones de requisitos previos y solucione cualquier problema.
- En la página Selección de funciones, seleccione Servicios de motor de base de datos.
- Configurar el nombre de la instancia (utilizar el mismo nombre de instancia en todos los nodos).
- En la página Configuración del servidor, especifique las credenciales de la cuenta de servicio.
- Configurar serviciostartipos de tup como Automático.
- En la página Configuración del motor de base de datos, seleccione el modo de autenticación.
- Agregar cuentas de administrador.
- Configure directorios de datos utilizando rutas consistentes en todos los nodos.
- Complete la instalación y verifique el éxito.
- Repita la instalación en todos los demás nodos del clúster con configuraciones idénticas.
4.4 Habilitación de la función Grupos de disponibilidad siempre activos
Después de instalar SQL Server En todos los nodos, habilite la función Grupos de disponibilidad siempre activa en cada instancia.
4.4.1 Habilitación mediante SQL Server Gerente de configuración
Usa SQL Server Administrador de configuración para habilitar grupos de disponibilidad AlwaysOn a través de la interfaz gráfica.
- Abierto SQL Server Gerente de configuración en el primer nodo.
- Expandir SQL Server Servicios en el panel izquierdo.
- Haga clic derecho en SQL Server instancia y seleccionar Propiedades.
- Haga clic en la pestaña Alta disponibilidad AlwaysOn .
- Comprobar Habilitar grupos de disponibilidad AlwaysOn.
- Verifique que el nombre del clúster de conmutación por error de Windows sea correcto.
- Haga clic en OK Para guardar los cambios.
- Haga clic en OK sobre la advertencia de que el servicio debe ser restarted
- Haga clic derecho en SQL Server servicio y selección Reanudación.
- Espere a que el servicio se resuelva.tart con éxito.
- Repita esto en todos los nodos del clúster.
4.4.2 Habilitación mediante PowerShell
PowerShell proporciona un método con script para habilitar grupos de disponibilidad siempre activa en varios nodos.
- Abra PowerShell como administrador en el primer nodo.
- Importar el SQL Server Módulo de PowerShell:
Import-Module SQLPS -DisableNameChecking
- Habilitar grupos de disponibilidad siempre activos:
Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force
- El servicio se reactivará automáticamente.tart cuando se utiliza el parámetro Fuerza.
- Verifique que la función esté habilitada:
Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled
- Repita este procedimiento para cada nodo del clúster, sustituyendo los nombres de servidor e instancia correspondientes.
4.4.3 Verificación de que la función esté habilitada
Verifique que los grupos de disponibilidad AlwaysOn estén habilitados en todas las instancias antes de continuar con la configuración.
- Conectarse entre sí SQL Server instancia usando SQL Server Estudio de gestión.
- Abra una nueva ventana de consulta y ejecute:
SELECT SERVERPROPERTY('IsHadrEnabled') - Verificar que el resultado sea 1 (habilitado).
- Compruebe que el SQL Server La instancia aparece en el Administrador de clústeres de conmutación por error en los roles del clúster.
- Verifique que el punto final del grupo de disponibilidad exista ejecutando lo siguiente:
SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'
- Si el punto final no existe, se creará durante la creación del grupo de disponibilidad.
4.5 Preparación de bases de datos para grupos de disponibilidad
Las bases de datos deben cumplir requisitos específicos antes de poder agregarse a un grupo de disponibilidad.
4.5.1 Requisitos del modelo de recuperación de la base de datos
Cambie el modelo de recuperación de la base de datos a COMPLETO en la réplica principal antes de agregarla a un grupo de disponibilidad.
- Conéctese a la réplica principal usando SQL Server Estudio de gestión.
- Haga clic derecho en la base de datos y seleccione Propiedades.
- Seleccione la Opciones .
- CAMBIAR modelo de recuperación a Pleno.
- Haga clic en OK para guardar el cambio
- Alternativamente, utilice Transact-SQL:
ALTER DATABASE DatabaseName SET RECOVERY FULL;
4.5.2 Realizar copias de seguridad completas de la base de datos
Realice una copia de seguridad completa de la base de datos para establecer la cadena de copia de seguridad necesaria para los grupos de disponibilidad.
- In SQL Server Management Studio, haga clic derecho en la base de datos.
- Seleccione tareas -> Retroceder.
- Verificar tipo de copia de seguridad esté configurado como Pleno.
- Seleccione un destino de respaldo o agregue un nuevo destino.
- Haga clic en OK para realizar la copia de seguridad.
- Alternativamente, utilice Transact-SQL:
BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';
4.5.3 Realizar copias de seguridad del registro de transacciones
Realice una copia de seguridad del registro de transacciones para garantizar que la cadena de registro esté establecida y minimizar el tiempo de inicialización.
- In SQL Server Management Studio, haga clic derecho en la base de datos.
- Seleccione tareas -> Retroceder.
- CAMBIAR tipo de copia de seguridad a Registro de transacciones.
- Seleccione un destino de copia de seguridad.
- Haga clic en OK para realizar la copia de seguridad.
- Alternativamente, utilice Transact-SQL:
BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';
4.6 Creación del grupo de disponibilidad
Cree el grupo de disponibilidad utilizando uno de los diversos métodos disponibles según sus preferencias y requisitos de automatización.
4.6.1 Uso del Asistente para nuevo grupo de disponibilidad
El Asistente para nuevo grupo de disponibilidad proporciona una interfaz gráfica para crear grupos de disponibilidad.
- In SQL Server Management Studio, conéctese a la instancia que lo haráost La réplica primaria.
- Expandir Alta disponibilidad AlwaysOn en el Explorador de objetos.
- Haga clic con el botón Grupos de disponibilidad y seleccione Asistente para nuevos grupos de disponibilidad.
- Haga clic en Siguiente en la página de Introducción.
- Ingrese un nombre para el grupo de disponibilidad y haga clic Siguiente.
- En la página Seleccionar bases de datos, seleccione las bases de datos que desea incluir.
- Verifique que las bases de datos cumplan con todos los requisitos previos y haga clic Siguiente.
- En la página Especificar réplicas, haga clic en Agregar réplica.
- Conectarse a cada instancia de réplica secundaria.
- Configurar propiedades de réplica para cada instancia (modo de disponibilidad, modo de conmutación por error).
- Haga clic en la pestaña Endpoints Pestaña y revisión de la configuración del punto final.
- Haga clic en la pestaña Preferencias de copia de seguridad pestaña y configurar prioridades de respaldo.
- Haga clic en la pestaña Perfil pestaña y, opcionalmente, crear un oyente.
- Haga clic en Siguiente y seleccione el método de sincronización de datos.
- Revise los resultados de la validación y solucione cualquier problema.
- Haga clic en Siguiente y revisar el resumen.
- Haga clic en Acabado para crear el grupo de disponibilidad.
- Supervisar el progreso y verificar la creación exitosa.
4.6.2 Uso de Transact-SQL
Cree grupos de disponibilidad utilizando Transact-SQL para implementaciones repetibles y con capacidad de scripting.
- Cree el grupo de disponibilidad en la réplica principal:
CREATE AVAILABILITY GROUP AG_Name FOR DATABASE DatabaseName REPLICA ON 'PrimaryServer\Instance' WITH (ENDPOINT_URL = 'TCP://PrimaryServer:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)), 'SecondaryServer\Instance' WITH (ENDPOINT_URL = 'TCP://SecondaryServer:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)); - Unir la réplica secundaria al grupo de disponibilidad:
ALTER AVAILABILITY GROUP AG_Name JOIN;
- Unirse a la base de datos secundaria:
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
4.6.3 Uso de PowerShell
PowerShell proporciona capacidades de scripting para la creación y administración de grupos de disponibilidad.
- Cree el objeto del grupo de disponibilidad:
$AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"
- Agregar bases de datos:
Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"
- Configure réplicas con las propiedades deseadas mediante el cmdlet New-SqlAvailabilityReplica.
- Unir réplicas secundarias mediante el cmdlet Join-SqlAvailabilityGroup.
4.7 Agregar réplicas al grupo de disponibilidad
Configure propiedades específicas de la réplica que controlan cómo cada instancia participa en el grupo de disponibilidad.
4.7.1 Configuración de las propiedades de la réplica
Establezca propiedades para cada réplica para definir su función y capacidades dentro del grupo de disponibilidad.
- In SQL Server Estudio de gestión, expandir Alta disponibilidad AlwaysOn -> Grupos de disponibilidad.
- Expandir el grupo de disponibilidad y luego expandir Réplicas de disponibilidad.
- Haga clic derecho en una réplica y seleccione Propiedades.
- Revisar y modificar la configuración de conexión para los roles principales y secundarios.
- Configure los valores de tiempo de espera de la sesión si es necesario.
- Haga clic en OK para guardar cambios
4.7.2 Configuración de modos de disponibilidad
Configure el modo de disponibilidad para controlar el comportamiento de sincronización entre réplicas.
- Haga clic derecho en el grupo de disponibilidad y seleccione Propiedades.
- En el cuadro de diálogo General página, vaya a la Réplicas de disponibilidad .
- Para cada réplica, seleccione Confirmación sincrónica or Confirmación asincrónica desde el desplegable.
- Utilice la confirmación sincrónica para réplicas locales de alta disponibilidad.
- Utilice la confirmación asincrónica para réplicas de recuperación ante desastres geográficamente distantes.
- Haga clic en OK para guardar la configuración.
4.7.3 Configuración de modos de conmutación por error
Configure el modo de conmutación por error para controlar cómo se produce la conmutación por error para cada réplica.
- Haga clic derecho en el grupo de disponibilidad y seleccione Propiedades.
- En el cuadro de diálogo General página, vaya a la Réplicas de disponibilidad .
- Para réplicas de confirmación sincrónicas, seleccione Automático or Manual modo de conmutación por error.
- La conmutación por error automática requiere un modo de confirmación sincrónica y habilita la conmutación por error desatendida.
- Para las réplicas de confirmación asincrónicas, solo está disponible la conmutación por error manual.
- Configure hasta tres réplicas para conmutación por error automática (una principal y dos secundarias).
- Haga clic en OK Para aplicar la configuración.
4.7.4 Configuración de preferencias de copia de seguridad
Establezca las preferencias de copia de seguridad para controlar dónde deben realizarse las operaciones de copia de seguridad.
- Haga clic derecho en el grupo de disponibilidad y seleccione Propiedades.
- Seleccione Preferencias de copia de seguridad en el panel izquierdo.
- Elija una de las preferencias de copia de seguridad:
- Prefiero secundaria:Copias de seguridad en el secundario si está disponible, de lo contrario en el principal
- Solo secundaria: Copias de seguridad solo en réplicas secundarias
- Principal: Copias de seguridad solo en la réplica principal
- Cualquier réplica:Copias de seguridad en cualquier réplica disponible
- Establecer valores de prioridad de respaldo para cada réplica (0-100).
- Los valores de prioridad más altos indican la copia de seguridad preferida tarconsigue.
- Haga clic en OK para guardar las preferencias.
4.8 Configuración del oyente del grupo de disponibilidad
Cree un escucha para proporcionar un único punto de conexión que redirija automáticamente a la réplica principal actual.
4.8.1 Creación del oyente
Agregue un oyente al grupo de disponibilidad para la administración de la conexión del cliente.
- In SQL Server Management Studio, amplíe el grupo de disponibilidad.
- Haga clic con el botón Oyentes del grupo de disponibilidad y seleccione Añadir oyente.
- Introduzca un nombre DNS para el oyente (por ejemplo, AG_Listener).
- Introduzca el número de puerto (el predeterminado es 1433).
- Seleccione IP estática para el modo de red.
- Haga clic en Agregar la extensión de para agregar una dirección IP para cada subred.
- Introduzca la dirección IP y seleccione la subred.
- Haga clic en OK para crear el oyente.
- Verifique que el oyente aparezca en el Explorador de objetos y esté en línea.
4.8.2 Configuración de DNS y ajustes de IP
Verificar el registro de DNS y la configuración de red para el oyente.
- Abra el Administrador de DNS en el controlador de dominio.
- Verifique que el nombre del oyente se haya registrado con todas las direcciones IP.
- Pruebe la resolución de DNS desde las máquinas cliente:
nslookup ListenerName
- Verifique que se devuelvan todas las direcciones IP configuradas.
- En el Administrador de clústeres de conmutación por error, expanda Roles y seleccione el grupo de disponibilidad.
- Verifique que los recursos de la dirección IP estén en línea.
- Compruebe que el recurso del nombre de red esté en línea.
4.8.3 Prueba de la conectividad del oyente
Verifique que las aplicaciones cliente puedan conectarse a través del oyente.
- Desde una máquina cliente, abra SQL Server Estudio de gestión.
- Conéctese utilizando el nombre del oyente en lugar del nombre del servidor.
- Ejecute una consulta para verificar la conexión a la réplica principal actual:
SELECT @@SERVERNAME;
- Pruebe el enrutamiento con intención de lectura agregando ApplicationIntent=ReadOnly a la cadena de conexión.
- Verificar que la conexión redirija a una réplica secundaria legible.
- Pruebe la conmutación por error conmutando manualmente el grupo de disponibilidad y verificando la reconexión.
4.9 Métodos de sincronización de datos
Elija un método de sincronización de datos para inicializar réplicas secundarias con copias de bases de datos.
4.9.1 Siembra automática
La siembra automática transfiere datos de bases de datos a través de la red sin necesidad de realizar copias de seguridad ni restauraciones manuales.
- Durante la creación del grupo de disponibilidad, seleccione Siembra automática como método de sincronización.
- Asegúrese de que haya conectividad de red y suficiente ancho de banda entre las réplicas.
- La réplica principal transmite automáticamente datos de la base de datos a las réplicas secundarias.
- Supervise el progreso de la siembra utilizando el panel del grupo de disponibilidad o DMV.
- La siembra automática requiere SQL Server 2016 o posterior.
- Para bases de datos grandes, considere el impacto en la red y programe durante períodos de bajo uso.
4.9.2 Siembra manual (copia de seguridad y restauración)
La siembra manual implica realizar copias de seguridad en la réplica principal y restaurarlas en réplicas secundarias.
- En la réplica principal, realice una copia de seguridad completa:
BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';
- Realice una copia de seguridad del registro de transacciones:
BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';
- En cada réplica secundaria, restaure la copia de seguridad completa:
RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;
- Restaurar la copia de seguridad del registro:
RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;
- Unir la base de datos al grupo de disponibilidad:
ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
- Verifique que la sincronización comience y que la base de datos alcance el estado SINCRONIZADO.
4.9.3 Archivos de instantáneas de la base de datos
Utilice archivos de instantáneas de base de datos para inicializar réplicas secundarias a partir de archivos de base de datos existentes.
- Desconecte o haga una copia de seguridad de la base de datos en la réplica principal.
- Copie los archivos de base de datos en cada réplica secundaria utilizando las mismas rutas de archivos.
- En las réplicas secundarias, adjunte la base de datos o restaure sin recuperación.
- Asegúrese de que la base de datos esté en estado RESTAURANDO.
- Unir la base de datos al grupo de disponibilidad.
- Este método es útil para bases de datos muy grandes donde la transferencia de red sería poco práctica.
5. Preguntas más frecuentes
5.1 preguntas generales
P: ¿Cuál es la diferencia entre Always On FCI y Always On AG?
R: Las instancias de clúster de conmutación por error Always On proporcionan alta disponibilidad a nivel de instancia mediante almacenamiento compartido, mientras que los grupos de disponibilidad Always On proporcionan alta disponibilidad a nivel de base de datos sin almacenamiento compartido. AG ofrece instancias secundarias legibles y una distribución geográfica más flexible.
P: ¿Puedo utilizar grupos de disponibilidad AlwaysOn con SQL Server ¿Edición estándar?
A: Sí, SQL Server La edición estándar de 2016 y las posteriores admiten grupos de disponibilidad básica con limitaciones que incluyen una base de datos por AG, dos réplicas como máximo y sin soporte secundario legible.
P: ¿Necesito almacenamiento compartido para los grupos de disponibilidad AlwaysOn?
R: No, los grupos de disponibilidad no requieren almacenamiento compartido. Cada réplica mantiene copias independientes de las bases de datos en el almacenamiento local, sincronizadas mediante el envío de registros de transacciones.
P: ¿Cuál es el número máximo de réplicas en un grupo de disponibilidad?
A: SQL Server La Edición Enterprise admite hasta nueve réplicas (una principal y ocho secundarias). Los grupos de disponibilidad distribuidos admiten hasta 18 réplicas en total en dos grupos de disponibilidad.
5.2 Preguntas de configuración
P: ¿Cómo elijo entre los modos de confirmación sincrónicos y asincrónicos?
R: Utilice la confirmación síncrona para requisitos de cero pérdida de datos dentro del mismo centro de datos o redes de baja latencia. Utilice la confirmación asíncrona para réplicas remotas de recuperación ante desastres donde la confirmación síncrona afectaría el rendimiento.
P: ¿Puedo mezclar réplicas sincrónicas y asincrónicas en el mismo grupo de disponibilidad?
R: Sí, los grupos de disponibilidad admiten configuraciones mixtas con réplicas síncronas y asincrónicas. Esto permite alta disponibilidad local con réplicas síncronas y recuperación ante desastres remota con réplicas asincrónicas.
P: ¿Qué sucede con mis conexiones durante la conmutación por error?
R: Las conexiones existentes se interrumpen al producirse una conmutación por error. Las aplicaciones con lógica de reintento de conexión se reconectan automáticamente a la nueva conexión principal a través del receptor. El proceso de conmutación por error suele completarse en cuestión de segundos o minutos.
P: ¿Necesito sincronizar inicios de sesión y trabajos en todas las réplicas?
A: en SQL Server 2019 y anteriores, sí: los inicios de sesión, los trabajos del Agente SQL y los servidores vinculados deben sincronizarse manualmente. SQL Server 2022 introduce grupos de disponibilidad contenidos que incluyen automáticamente estos objetos.
5.3 Preguntas de gestión
P: ¿Puedo ejecutar copias de seguridad en réplicas secundarias?
R: Sí, las réplicas secundarias admiten copias de seguridad completas, diferenciales y del registro de transacciones. Configure las preferencias de copia de seguridad para descargar las copias de seguridad de la réplica principal y reducir su consumo de recursos.
P: ¿Cómo puedo aplicar un parche? SQL Server ¿con un tiempo de inactividad mínimo?
R: Utilice actualizaciones continuas aplicando primero parches a las réplicas secundarias, luego realizando una conmutación por error manual a una réplica secundaria parcheada y, finalmente, aplicando parches a la réplica principal anterior. Esto minimiza el tiempo de inactividad durante la conmutación por error.
P: ¿Puedo agregar bases de datos a un grupo de disponibilidad existente?
R: Sí, se pueden agregar bases de datos a grupos de disponibilidad en ejecución. La base de datos debe estar en un modelo de recuperación completa con una copia de seguridad completa, y las réplicas secundarias deben inicializarse mediante la inicialización automática o mediante copia de seguridad y restauración manuales.
P: ¿Qué es la siembra automática y debería utilizarla?
R: La propagación automática transfiere datos de la base de datos a través de la red para inicializar réplicas secundarias sin necesidad de copias de seguridad manuales. Úsela para bases de datos más pequeñas o cuando el ancho de banda de la red sea suficiente. Para bases de datos muy grandes, la propagación manual puede ser más rápida.
P: ¿Dónde debo ejecutar DBCC CHECKDB en un grupo de disponibilidad?
R: Debe ejecutar DBCC CHECKDB en las réplicas secundarias para reducir la carga en la réplica principal. Las comprobaciones de consistencia de la base de datos pueden ejecutarse en bases de datos secundarias sin afectar el rendimiento de la réplica principal.
Para obtener más detalles sobre DBCC CHECKDB, consulte nuestra guía completa.
5.4 Preguntas de solución de problemas
P: ¿Por qué mi base de datos está en estado NO SINCRONIZANDO?
R: Las causas comunes incluyen problemas de conectividad de red, suspensión del movimiento de datos, espacio de disco insuficiente en réplicas secundarias o problemas en los endpoints. Consulte la descripción del estado de sincronización y SQL Server registros de errores para obtener detalles específicos. Si la base de datos secundaria ha ingresado un estado de recuperación o espectáculos recuperación pendiente, consulte las guías vinculadas para tarcorrecciones obtenidas
P: ¿Cómo puedo fuerza la conmutación por error cuando el servidor principal no está disponible?
A: Conéctese a una réplica secundaria y ejecute ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Esto reconoce la posible pérdida de datos y promueve la réplica secundaria a principal inmediatamente.
P: ¿Por qué los clientes no pueden conectarse con mi oyente?
A: Verifique que el oyente esté en línea en el Administrador de clúster de conmutación por error, que el registro de DNS se haya realizado correctamente, que todos los IP del oyente sean accesibles desde los clientes y que las reglas del firewall permitan el tráfico al puerto del oyente.
P: ¿Qué significa una cola de rehacer grande?
R: Una cola de rehacer grande indica que la réplica secundaria no puede aplicar los registros de registro tan rápido como llegan. Esto puede indicar cuellos de botella de E/S de disco, limitaciones de CPU o bloqueos por consultas de solo lectura en la réplica secundaria.
P: ¿Qué debo hacer si un desastre afecta a todas las réplicas y mis copias de seguridad también están dañadas?
A: Este escenario en el peor de los casos, aunque extremadamente rarPuede ocurrir debido a ataques de ransomware, fallos generalizados de almacenamiento o desastres en cascada. Su principal defensa es la prevención: mantenga réplicas distribuidas geográficamente, almacene las copias de seguridad en ubicaciones separadas y...
Pruebe periódicamente sus procedimientos de recuperación ante desastres. Si todas las opciones de recuperación estándar fallan, un especialista Herramienta de recuperación de datos SQL puede intentar extraer datos de archivos MDF dañados como medida de emergencia de último recurso.
5.5 Licencias y Cost Frecuentes
P: ¿Cómo se licencian los grupos de disponibilidad Always On?
A: SQL Server La licencia depende de la edición y el modelo de implementación. Los grupos de disponibilidad de la Edición Enterprise requieren licencias Enterprise en todas las réplicas. Las réplicas secundarias pasivas pueden optar a licencias gratuitas bajo ciertas condiciones.
P: ¿Puedo usar SQL Server ¿Edición para desarrolladores para grupos de disponibilidad?
R: Sí, la Edición para Desarrolladores incluye todas las funciones de la Edición Empresarial, incluyendo compatibilidad total con grupos de disponibilidad. Sin embargo, su licencia es solo para desarrollo y pruebas, no para producción.
P: ¿Los archivos secundarios legibles requieren licencias adicionales?
R: La licencia depende del escenario. Los servidores secundarios pasivos para recuperación ante desastres generalmente no requieren licencias. Los servidores secundarios activos que atienden cargas de trabajo de solo lectura generalmente requieren licencias, aunque las condiciones específicas varían.
P: ¿Existe una forma gratuita de obtener alta disponibilidad con SQL Server?
A: SQL Server Express Edition no admite grupos de disponibilidad. SQL Server La edición estándar admite grupos de disponibilidad básica.tarting con SQL Server 2016, proporcionando alta disponibilidad básica en licencias de Edición Estándar costs.
P: ¿Qué son los grupos de disponibilidad distribuida?
R: Los grupos de disponibilidad distribuidos son un tipo especial de grupo de disponibilidad que abarca dos grupos de disponibilidad separados, lo que permite escenarios que superan las capacidades de los grupos de disponibilidad tradicionales. Introducido en SQL Server 2016, los grupos de disponibilidad distribuida abordan los requisitos de escalabilidad y distribución geográfica.
6. Conclusión
6.1 Resumen de puntos clave
SQL Server Los Grupos de Disponibilidad Always On representan la solución líder de alta disponibilidad y recuperación ante desastres de Microsoft para bases de datos críticas. Ofrecen conmutación por error a nivel de base de datos sin necesidad de almacenamiento compartido, réplicas secundarias legibles para descargar cargas de trabajo y una distribución geográfica flexible para una protección integral de los datos. Para organizaciones que aún utilizan soluciones como envío de registros or replicaciónLos grupos de disponibilidad ofrecen una ruta de actualización más sólida y operativamente más sencilla.
6.2 Cuándo utilizar grupos de disponibilidad AlwaysOn
Elija grupos de disponibilidad cuando necesite alta disponibilidad a nivel de base de datos con conmutación por error automática. Las organizaciones que necesitan protección contra pérdida de datos cero para bases de datos críticas se benefician de las réplicas de confirmación síncronas con conmutación por error automática. Las aplicaciones que requieren capacidades de escalado de lectura aprovechan las réplicas secundarias legibles para distribuir las cargas de trabajo de consultas.
6.3 Obtener Started con su implementación
Comience la planificación del grupo de disponibilidad evaluando los requisitos del negocio, incluyendo el RTO, el RPO y las limitaciones presupuestarias. Documente la infraestructura actual de la base de datos, las dependencias de las aplicaciones y las brechas de alta disponibilidad. Diseñe una arquitectura de grupo de disponibilidad que satisfaga los requisitos sin exceder las limitaciones de recursos.
Referencias
- Documento oficial de Microsoft: ¿Qué es un grupo de disponibilidad Always On?
- Documento oficial de Microsoft: Conseguir Started con grupos de disponibilidad AlwaysOn
- Documento oficial de Microsoft: Grupos de disponibilidad distribuidos
Sobre el Autor
Yuan Sheng es un administrador de bases de datos senior (DBA) con más de 10 años de experiencia en SQL Server Entornos y gestión de bases de datos empresariales. Ha resuelto con éxito cientos de escenarios de recuperación de bases de datos en organizaciones de servicios financieros, atención médica y manufactura.
Yuan se especializa en SQL Server Recuperación de bases de datos, soluciones de alta disponibilidad y optimización del rendimiento. Su amplia experiencia práctica incluye la gestión de bases de datos multiterabyte, la implementación de Grupos de Disponibilidad Siempre Activa (AVA) y el desarrollo de estrategias automatizadas de backup y recuperación para sistemas empresariales críticos.
Gracias a su experiencia técnica y su enfoque práctico, Yuan se centra en crear guías integrales que ayuden a los administradores de bases de datos y a los profesionales de TI a resolver problemas complejos. SQL Server Aborda los desafíos de manera eficiente. Se mantiene al día con las últimas novedades. SQL Server versiones y las tecnologías de bases de datos en evolución de Microsoft, probando periódicamente escenarios de recuperación para garantizar que sus recomendaciones reflejen las mejores prácticas del mundo real.
¿Tiene preguntas acerca SQL Server ¿Necesita ayuda adicional para la recuperación de la base de datos o para solucionar problemas? Yuan le da la bienvenida. comentarios y sugerencias para mejorar estos recursos técnicos.