Este documento presenta estrategias de recuperación ante desastres (DR) para Microsoft SQL Server para arquitectos y líderes técnicos responsables de diseñar e implementar la recuperación ante desastres en Google Cloud.
Las bases de datos pueden dejar de estar disponibles por diversos motivos, por ejemplo, fallos de hardware o de red. Para proporcionar acceso continuo a la base de datos durante las fallas, se mantiene una base de datos secundaria que es una réplica de una base de datos primaria. Tener la base de datos secundaria en una ubicación diferente aumenta las posibilidades de que esté disponible cuando la base de datos principal deje de estar disponible.
Si la base de datos principal deja de estar disponible, su aplicación de misión crítica se conecta a una base de datos secundaria y continúa desde el estado de datos consistente conocido más recientemente para brindar servicios a sus usuarios con un tiempo de inactividad mínimo o nulo.
El proceso de hacer que una base de datos secundaria esté disponible en caso de falla de la base de datos principal se denomina recuperación ante desastres (DR) de la base de datos . La base de datos secundaria se recupera de la falta de disponibilidad de la base de datos primaria. Idealmente, la base de datos secundaria tiene exactamente el mismo estado consistente que la base de datos primaria cuando no está disponible o solo pierde un conjunto mínimo de transacciones recientes de la base de datos primaria.
Database DR es una característica esencial para los clientes empresariales. El principal impulsor es la continuidad del negocio para las aplicaciones de misión crítica. Por ejemplo, una aplicación de misión crítica genera ingresos (comercio electrónico), proporciona servicios continuos y confiables (gestión de vuelos o centrales eléctricas) o admite funciones que preservan la vida (monitoreo de pacientes). En todos estos ejemplos, es de suma importancia que la aplicación esté disponible continuamente porque se considera de misión crítica.
La mayoría de los sistemas de administración de bases de datos brindan funcionalidad de recuperación ante desastres, incluido Microsoft SQL Server . Este documento de arquitectura analiza cómo se implementan las características de recuperación ante desastres proporcionadas por SQL Server en el contexto de Google Cloud.
Terminología
Las siguientes secciones explican los términos que se utilizan en este documento.
Arquitectura general de recuperación ante desastres
El siguiente diagrama ilustra la topología general de la arquitectura DR.
En el diagrama anterior, una aplicación accede a una base de datos primaria mientras una base de datos secundaria está en espera y refleja el estado de la base de datos primaria. Los clientes acceden a la aplicación que se ejecuta en Google Cloud.
Si la base de datos principal deja de estar disponible, los administradores de la base de datos o el equipo de operaciones deben decidir iniciar el proceso de recuperación ante desastres. Si se inicia la recuperación ante desastres de la base de datos, la aplicación se vuelve a conectar a la base de datos secundaria. Una vez conectada, la aplicación puede volver a atender a sus clientes. En una situación ideal, la aplicación está disponible en la base de datos secundaria lo antes posible para que los clientes ni siquiera experimenten una interrupción. Una alternativa es esperar a que se pueda acceder nuevamente a la base de datos principal, en lugar de iniciar la recuperación ante desastres. Por ejemplo, si el desastre es intermitente, podría ser más rápido resolver el problema en lugar de realizar una conmutación por error.
Bases de datos primarias y secundarias.
Una o más aplicaciones acceden a una base de datos primaria para proporcionar servicios de persistencia para la gestión del estado de la aplicación. Una base de datos secundaria está relacionada con una base de datos primaria y contiene una réplica de la base de datos primaria. Idealmente, el contenido de la base de datos secundaria coincide exactamente con el contenido de la base de datos primaria en cualquier momento. En muchos casos, la base de datos secundaria va por detrás de la base de datos primaria debido a retrasos en la aplicación de los cambios transaccionales realizados en la base de datos primaria. Es posible asociar más de una base de datos secundaria con una base de datos primaria, según la tecnología de la base de datos. SQL Server admite la asociación de más de una base de datos secundaria con una base de datos primaria .
Recuperación ante desastres
Si una base de datos principal deja de estar disponible, DR cambia la función de la base de datos secundaria para que se convierta en la base de datos principal. Si hay más de una base de datos secundaria, una de esas bases de datos se selecciona manualmente o en función de una lista de conmutación por error preferida. Las aplicaciones deben volver a conectarse a la nueva base de datos principal para continuar accediendo a su estado. Si la nueva base de datos principal no estaba sincronizada con el último estado conocido de la base de datos principal anterior, la aplicación se inicia desde un estado anterior (también conocido como flashback ).
Es importante tener al menos una base de datos secundaria en todo momento para cada base de datos primaria. Después de una recuperación ante desastres, asegúrese de configurar una nueva base de datos secundaria para manejar escenarios futuros de recuperación ante desastres.
Conmutación por error, conmutación y respaldo
Existen varios escenarios para cambiar la función entre las bases de datos primarias y secundarias:
- Conmutación por error : el proceso de cambiar la función de una base de datos secundaria para que sea la nueva base de datos principal y conectar todas las aplicaciones a ella. La conmutación por error no es intencional porque se activa cuando una base de datos principal deja de estar disponible. Puede configurar la conmutación por error para que se active de forma automática o manual.
- Conmutación : a diferencia de la conmutación por error, una conmutación de una base de datos primaria a una base de datos secundaria (nueva base de datos primaria) se activa intencionalmente para las pruebas iniciales y el mantenimiento programado. Pruebe su sistema de recuperación ante desastres con una conmutación periódica para garantizar la confiabilidad continua de la recuperación ante desastres.
- Respaldo : el respaldo es revertir el proceso en el que la nueva base de datos primaria se convierte en la base de datos secundaria, después de que se repara la base de datos primaria. Se activa intencionalmente una reserva para restablecer el estado antes de que se iniciara la conmutación por error o la conmutación. No es estrictamente necesario, pero se puede realizar según los requisitos de recuperación ante desastres, como la localidad o los recursos disponibles.
Google Cloud zonas y regiones
Recursos como bases de datos se encuentran en Google Cloud zonas y regiones , donde cada zona pertenece a una región. Una zona es un dominio de punto único de falla. Recomendamos implementar un recurso de alta disponibilidad y tolerante a fallas en varias zonas dentro de una región.
Para protegerse contra la interrupción de toda una región, establezca estrategias multirregionales para la recuperación ante desastres. Por ejemplo, la base de datos primaria está ubicada en una región y su base de datos secundaria correspondiente está ubicada en otra región.
Modos activos: activo-pasivo y activo-activo
Una base de datos primaria es una base de datos abierta para operaciones de lectura y escritura (operaciones DML) para que las aplicaciones que acceden a ella puedan administrar su estado. La base de datos primaria se llama base de datos activa . La base de datos secundaria correspondiente es pasiva porque replica la base de datos primaria, pero ninguna aplicación la puede utilizar para operaciones de cambio de estado. Después de una conmutación por error o una conmutación, la base de datos secundaria se convierte en la nueva base de datos principal y se convierte en una base de datos activa.
Tanto la base de datos primaria como la secundaria pueden ser bases de datos activas si la tecnología de la base de datos admite esta característica, llamada modo activo-activo . En este caso, las aplicaciones pueden conectarse a uno u otro porque ambas bases de datos están disponibles para la gestión del estado. La recuperación ante desastres en modo activo-activo no requiere una conmutación por error si solo una de las bases de datos activas deja de estar disponible. Si una base de datos activa no está disponible, la otra base de datos activa continúa estando disponible. El modo activo-activo está fuera del alcance de este artículo porque SQL Server no admite este modo.
Modos de espera: caliente, tibio, frío y sin espera
Para que la base de datos principal sea la base de datos activa, debe estar en ejecución y poder ejecutar declaraciones DML. No es necesario que la base de datos secundaria esté ejecutándose; se puede cerrar. Si no se está ejecutando, el tiempo que lleva recuperarse de un desastre aumenta porque la nueva base de datos primaria debe pasar primero a un estado de ejecución, antes de asumir la función de la nueva base de datos primaria.
Existen varias variaciones sobre cómo configurar la base de datos secundaria:
- Espera activa : la base de datos secundaria está en funcionamiento y lista para que los clientes se conecten a ella. El último cambio disponible de la base de datos principal siempre se aplica tan pronto como esté disponible.
- Espera en caliente : una base de datos secundaria está en funcionamiento; sin embargo, no necesariamente se han aplicado todavía todos los cambios de la base de datos primaria.
- Espera en frío : no se está ejecutando una base de datos secundaria. Primero, es necesario iniciarlo y luego sincronizarlo al último estado disponible.
- Sin espera : el software de la base de datos debe instalarse primero y luego iniciarse antes de que se apliquen todos los cambios de la base de datos principal. Este modo es el menos costoso porque no consume recursos cuando no se necesita, pero en comparación con los otros modos, es el que tarda más en convertirse en una nueva base de datos primaria.
Estrategias de recuperación ante desastres
En las siguientes secciones, se explican las estrategias de recuperación ante desastres que admite Microsoft SQL Server.
Dimensiones de la estrategia de recuperación
Hay varias dimensiones clave a considerar al seleccionar o implementar una estrategia de recuperación ante desastres de bases de datos. Cada dimensión tiene un espectro y el comportamiento y las expectativas de la estrategia de recuperación ante desastres dependen de la selección de los puntos del espectro. Las dimensiones clave son las siguientes:
- Objetivo de punto de recuperación (RPO) : el período de tiempo máximo aceptable durante el cual se pueden perder datos de su aplicación debido a un incidente importante. Esta dimensión varía según las formas en que se utilizan los datos. El RPO se puede expresar en duración (segundos, minutos u horas) desde el momento en que la base de datos principal no está disponible o se puede expresar como estados de procesamiento identificables (última copia de seguridad completa o última copia de seguridad incremental). No importa cómo se especifique el RPO, la estrategia de recuperación ante desastres debe implementar la medida particular para que se pueda satisfacer el requisito del RPO. El caso más exigente es el de la última transacción confirmada, lo que significa que no debe producirse ninguna pérdida de la base de datos primaria a la base de datos secundaria.
- Objetivo de tiempo de recuperación (RTO) . El período de tiempo máximo aceptable que su aplicación puede estar sin conexión. Este valor generalmente se especifica como parte de un acuerdo de nivel de servicio más amplio. El RTO generalmente se expresa en términos de duración desde el momento en que la base de datos principal no está disponible; por ejemplo, la aplicación debe estar completamente operativa en 5 minutos. El caso más exigente es inmediato para que los usuarios de la aplicación no se den cuenta de que se ha producido una recuperación ante desastres.
- Dominio de punto único de falla . Depende de usted decidir si una región se considera un dominio de punto único de falla para sus requisitos de recuperación ante desastres. Si una región es un dominio de punto único de falla para usted, entonces se debe configurar la recuperación ante desastres para que dos o más regiones participen en la configuración real. Si la región que contiene la base de datos primaria falla, la base de datos secundaria en una región diferente es la nueva base de datos primaria. Si se supone que el dominio de punto único de falla es una zona, entonces la recuperación ante desastres se puede configurar en todas las zonas dentro de una sola región. Si una zona falla, la recuperación ante desastres utiliza una segunda zona y hace que la nueva base de datos principal esté disponible en ella.
Decidir sobre estas dimensiones clave es tomar una decisión entre costo y calidad. Cuanto más bajos sean el RTO y el RPO, más costosa puede resultar la solución de recuperación ante desastres a medida que se utilizan más recursos activos. En las siguientes secciones, se analizan varias estrategias de recuperación ante desastres alternativas que representan puntos en las dimensiones en el contexto de la base de datos de Microsoft SQL Server.
Estrategias de recuperación ante desastres para SQL Server
Continuidad del negocio y recuperación de bases de datos: SQL Server describe características de disponibilidad que puede utilizar para implementar estrategias de recuperación ante desastres.
Preliminares
SQL Server se ejecuta tanto en Windows como en Linux. Sin embargo, no todas las funciones de disponibilidad están disponibles en Linux. SQL Server tiene varias ediciones, pero no todas las funciones de disponibilidad están disponibles en todas las ediciones.
SQL Server distingue instancias de bases de datos. Una instancia es el software de SQL Server que se ejecuta, mientras que una base de datos es el conjunto de datos administrados por una instancia de SQL Server.
Grupos de disponibilidad Always On
Los grupos de disponibilidad Always On brindan protección a nivel de base de datos. Un grupo de disponibilidad tiene dos o más réplicas. Una réplica es la réplica principal con acceso de lectura y escritura, y las réplicas restantes son réplicas secundarias que pueden proporcionar acceso de lectura. Cada réplica de la base de datos es administrada por una instancia independiente de SQL Server. Un grupo de disponibilidad puede contener una o más bases de datos. La cantidad de bases de datos que se pueden incluir en un grupo de disponibilidad y la cantidad de réplicas secundarias admitidas depende de la edición de SQL Server. Todas las bases de datos de un grupo de disponibilidad experimentan los mismos cambios en el ciclo de vida al mismo tiempo. Los grupos de disponibilidad implementan el modo activo-pasivo porque solo la base de datos principal admite acceso de escritura.
Cuando ocurre una conmutación por error, una réplica secundaria se convierte en la nueva réplica principal. Dado que un grupo de disponibilidad incluye instancias independientes de SQL Server, todas las operaciones capturadas en los registros de transacciones están disponibles en las réplicas. Cualquier cambio que no se capture en un registro de transacciones debe sincronizarse manualmente, por ejemplo, los inicios de sesión a nivel de instancia de SQL Server o los trabajos del Agente SQL Server. Para proporcionar protección a nivel de base de datos y protección de instancias de SQL Server, debe configurar instancias de clúster de conmutación por error (FCI). Esta arquitectura de implementación se analiza más adelante en la sección Instancia de clúster de conmutación por error siempre activa .
Puede proteger las aplicaciones de cambios de funciones mediante el uso de un oyente. Un oyente admite aplicaciones que se conectan al grupo de disponibilidad. Las aplicaciones no saben qué instancias de SQL Server administran la base de datos principal o las réplicas secundarias en ningún momento. Los agentes de escucha requieren que los clientes utilicen una versión mínima de .NET de 3.5 con una actualización o 4.0 y superior, como se describe en Continuidad del negocio y recuperación de bases de datos: SQL Server .
Los grupos de disponibilidad dependen de capas subyacentes de abstracción para proporcionar su funcionalidad. Los grupos de disponibilidad se ejecutan en un clúster de conmutación por error de Windows Server (WSFC) como se describe en Clústeres de conmutación por error de Windows Server con SQL Server . Todos los nodos que ejecutan instancias de SQL Server deben formar parte del mismo WSFC.
Las transacciones se envían desde la base de datos primaria a todas las réplicas secundarias. Hay dos modos de envío para enviar transacciones: sincrónico y asincrónico. Puede configurar de forma independiente cada réplica para utilizar uno u otro modo. En el modo de envío sincrónico, la transacción en la base de datos principal solo se realiza correctamente si se realiza correctamente en todas las réplicas secundarias que están vinculadas sincrónicamente. En el modo asíncrono, la transacción en la base de datos principal puede tener éxito aunque no todas las réplicas secundarias tengan aplicada la transacción.
Su elección del modo de envío influye en el posible RTO, RPO y su modo de espera. Por ejemplo, si las transacciones se envían a todas las réplicas en modo síncrono, todas las réplicas están exactamente en el mismo estado. El RPO (transacción más reciente) más exigente se cumple ya que todas las réplicas están completamente sincronizadas. Las réplicas secundarias son reservas activas, por lo que cualquiera de ellas puede usarse inmediatamente como base de datos principal.
La conmutación por error puede ser automática o manual. Es posible una conmutación por error automática si todas las réplicas están completamente sincronizadas. En el ejemplo anterior, esto es posible ya que todas las réplicas siempre están completamente sincronizadas.
La siguiente figura muestra un grupo de disponibilidad Always On en una sola región.
El grupo de disponibilidad se representa como un rectángulo que abarca zonas. Esto es solo con fines ilustrativos para indicar que todas las bases de datos pertenecen al mismo grupo de disponibilidad. El grupo de disponibilidad no es un recurso de nube y, como tal, no está implementado en un nodo ni en ningún otro tipo de recurso.
Instancia de clúster de conmutación por error siempre activa
Para protegerse contra fallas en los nodos, puede usar instancias de clúster de conmutación por error (FCI) en lugar de instancias independientes de SQL Server. Hay dos o más nodos que ejecutan instancias de SQL Server para administrar una base de datos (primaria o secundaria). Los nodos que administran una base de datos forman un clúster de conmutación por error. Un nodo del clúster ejecuta activamente una instancia de SQL Server mientras que los otros nodos no ejecutan instancias de SQL Server. Cuando falla el nodo que ejecuta la instancia de SQL Server, otro nodo en el clúster inicia una instancia de SQL Server, asumiendo la administración de la base de datos (conmutación por error del nodo). Este proceso de iniciar automáticamente una instancia de SQL Server proporciona una funcionalidad de alta disponibilidad.
El clúster FCI aparece como una sola unidad y los clientes que acceden al clúster no ven la conmutación por error entre nodos, excepto quizás durante un breve período de indisponibilidad. No hay pérdida de datos cuando se produce una conmutación por error de un nodo. Todo lo que se ejecuta dentro de la instancia fallida de SQL Server se mueve a otra instancia de SQL Server en el mismo clúster. Por ejemplo, los trabajos del Agente SQL Server o los servidores vinculados se mueven a otra instancia.
Los nodos del clúster FCI se pueden configurar en diferentes Google Cloud zonas. Esta arquitectura no solo proporciona alta disponibilidad en caso de falla del nodo, sino también en caso de fallas de zona. En la sección de alternativas de implementación de DR se analiza un ejemplo de implementación de esta estrategia.
Aunque diferentes nodos administran la misma base de datos y comparten la base de datos, no se requiere un almacenamiento común entre los nodos de un clúster FCI. SQL Server utiliza la funcionalidad Storage Spaces Direct (S2D) para administrar bases de datos en discos de nodos dedicados. Para obtener más información, consulte Configuración de instancias de clúster de conmutación por error de SQL Server .
En la siguiente figura se muestra el ejemplo de la sección anterior de grupos de disponibilidad Always On con FCI en lugar de instancias independientes de SQL Server. Cada FCI tiene una instancia activa de SQL Server que administra la base de datos.
Como en el caso del grupo de disponibilidad, un FCI se representa como un rectángulo. Esto tiene solo fines ilustrativos para indicar que todos los nodos pertenecen a la misma FCI. Una FCI no es un recurso en la nube y, como tal, no está implementada en un nodo ni en ningún otro tipo de recurso.
Para obtener una discusión más detallada, consulte Instancias de clúster de conmutación por error siempre activas (SQL Server) .
Grupos de disponibilidad distribuidos
Los grupos de disponibilidad distribuida son un tipo especial de grupo de disponibilidad. Un grupo de disponibilidad distribuida abarca dos grupos de disponibilidad, uno tiene la función de grupo de disponibilidad principal y el otro tiene la función de grupo de disponibilidad secundario. Los grupos de disponibilidad distribuidos pueden reenviar transacciones en modo síncrono y asíncrono desde el grupo de disponibilidad principal al grupo de disponibilidad secundario.
Aunque cada uno de los grupos de disponibilidad tiene su propia base de datos principal, esta no es una implementación activa-activa. Solo la base de datos principal del grupo de disponibilidad principal puede recibir operaciones de escritura. La base de datos principal del grupo de disponibilidad secundario se denomina reenviador. El reenviador recibe las transacciones del grupo de disponibilidad principal y las reenvía a las bases de datos secundarias del grupo de disponibilidad secundario. Una conmutación por error del grupo de disponibilidad principal al grupo de disponibilidad secundario haría que la base de datos principal del nuevo grupo de disponibilidad principal fuera accesible para operaciones de escritura.
Los grupos de disponibilidad principal y secundario no tienen que estar en la misma ubicación ni tienen que estar en el mismo sistema operativo. Sin embargo, cada grupo de disponibilidad debe tener un agente de escucha instalado. El grupo de disponibilidad distribuida en sí no tiene un agente de escucha. Los grupos de disponibilidad distribuidos no requieren que los dos grupos de disponibilidad estén en el mismo WSFC. Toda la funcionalidad necesaria para que los grupos de disponibilidad distribuidos funcionen está contenida en la funcionalidad de SQL Server y no requiere la instalación adicional de componentes subyacentes.
Un grupo de disponibilidad distribuido abarca exactamente dos grupos de disponibilidad. Un grupo de disponibilidad puede formar parte de dos grupos de disponibilidad distribuidos. Esta posibilidad soporta diferentes topologías. Una es una topología de conexión en cadena de un grupo de disponibilidad a otro en varias ubicaciones. Otra topología es una topología en forma de árbol donde el grupo de disponibilidad principal forma parte de dos grupos de disponibilidad distribuidos diferentes y separados.
Los grupos de disponibilidad distribuida son el medio principal para implementar la recuperación ante desastres en todos los sistemas operativos. Por ejemplo, el grupo de disponibilidad principal se puede configurar en Windows y un segundo grupo de disponibilidad correspondiente en Linux, donde ambos grupos de disponibilidad forman un grupo de disponibilidad distribuido.
El siguiente diagrama muestra dos grupos de disponibilidad que forman parte de un grupo de disponibilidad distribuido.
El grupo de disponibilidad 1 es el grupo de disponibilidad principal y el grupo de disponibilidad 2 es el grupo de disponibilidad secundario.
Como en el caso de los FCI, un grupo de disponibilidad distribuida se representa como un rectángulo. Esto tiene solo fines ilustrativos para indicar que todos los grupos de disponibilidad pertenecen al mismo grupo de disponibilidad distribuido. Un grupo de disponibilidad distribuido, al igual que un grupo de disponibilidad, no es un recurso en la nube y, como tal, no está implementado en un nodo ni en ningún otro tipo de recurso.
Para obtener más información, consulte Grupos de disponibilidad distribuidos .
Envío de registros
El envío de registros de transacciones es una característica de disponibilidad de SQL Server cuando el RTO y el RPO no son tan estrictos (RTO bajo y/o RPO reciente) porque la discrepancia en el estado entre una base de datos primaria y su base de datos secundaria es significativamente mayor. La discrepancia es mayor en términos de estado porque un archivo de registro de transacciones contiene muchos cambios de estado. La discrepancia también es mayor en términos de retraso porque los archivos de registro de transacciones se transportan de forma asincrónica y deben aplicarse en su totalidad a una base de datos secundaria.
Los archivos de registro de transacciones son creados por la base de datos principal y respaldados, por ejemplo, en Cloud Storage. Cada archivo de registro de transacciones se copia a cada base de datos secundaria y se le aplica. Debido a que la base de datos secundaria va por detrás de la base de datos principal, están en modo de espera en caliente. Los objetos y cambios que no son capturados por los registros de transacciones deben aplicarse manualmente a las bases de datos secundarias para establecer una sincronización completa sin pérdidas.
El Agente SQL Server automatiza el proceso general de creación, copia y aplicación de registros de transacciones. El envío de registros debe configurarse para cada base de datos individualmente. Si un grupo de disponibilidad administra más de una base de datos, se deben configurar tantos procesos de envío de registros como sea posible.
En caso de falla, el proceso de recuperación ante desastres debe iniciarse manualmente porque no existe soporte automatizado. Además, un oyente no abstrae el acceso del cliente de la base de datos principal y de las bases de datos secundarias. En caso de conmutación por error, los clientes deben poder manejar el cambio de función de una base de datos de la función secundaria a la nueva función principal por sí solos conectándose a la nueva función principal después de una recuperación ante desastres. Es posible crear abstracciones separadas independientemente de las instancias de SQL Server, por ejemplo, direcciones IP flotantes como se describe en Mejores prácticas para direcciones IP flotantes .
Debido a que el trasvase de registros es en parte un proceso manual, puede retrasar intencionalmente la aplicación de archivos de registro copiados a las bases de datos secundarias (a diferencia de los grupos de disponibilidad y los grupos de disponibilidad distribuidos donde los cambios se aplican inmediatamente). Un posible caso de uso es evitar que los errores de modificación de datos en la base de datos primaria se apliquen a las bases de datos secundarias hasta que se solucionen los errores de modificación de datos. En este caso, una base de datos secundaria que aún no tiene aplicado un error de modificación de datos podría convertirse en la base de datos principal hasta que se solucione el error de modificación de datos. Posteriormente, se puede reanudar el procesamiento normal.
Como en el caso de los grupos de disponibilidad distribuidos, puede utilizar el trasvase de registros para soluciones multiplataforma en las que, por ejemplo, la base de datos principal se ejecuta en Linux mientras que las bases de datos secundarias se ejecutan en Linux y Windows.
El siguiente diagrama ilustra una implementación multiplataforma con envío de registros. Tenga en cuenta que no existe una configuración común entre regiones como un grupo de disponibilidad distribuido en esta topología.
Los grupos de disponibilidad se encuentran en regiones separadas: uno se ejecuta en Linux y el otro en Windows.
Para obtener más información sobre el trasvase de registros de SQL Server, lea Acerca del trasvase de registros (SQL Server) .
Combinando características de disponibilidad de SQL Server
Puede implementar funciones de disponibilidad de SQL Server en diferentes combinaciones. Por ejemplo, en el caso de uso anterior, se utilizó el trasvase de registros con diferentes grupos de disponibilidad instalados en diferentes sistemas operativos.
La siguiente es una lista de posibles combinaciones de características de disponibilidad del servidor SQL:
- Utilice el trasvase de registros entre grupos de disponibilidad instalados en el mismo sistema operativo.
- Tenga un grupo de disponibilidad principal que use FCI con un grupo de disponibilidad secundario que use solo instancias independientes de SQL Server.
- Utilice un grupo de disponibilidad distribuido entre regiones cercanas y registre el envío entre regiones ubicadas en diferentes continentes.
Estas son sólo algunas de las posibles combinaciones de características de disponibilidad de SQL Server.
La flexibilidad que brindan las características de disponibilidad de SQL Server respalda el ajuste fino de una estrategia de recuperación ante desastres de acuerdo con los requisitos establecidos.
Replicación de SQL Server
La replicación de SQL Server generalmente no se considera una característica de disponibilidad, pero esta sección describe brevemente cómo se puede utilizar esta característica para la recuperación ante desastres.
La función de replicación admite la creación y mantenimiento de réplicas de bases de datos. Diferentes tipos de agentes de SQL Server colaboran para capturar cambios, transmitir cambios capturados y aplicar esos cambios a las réplicas. Este proceso es asincrónico y las réplicas generalmente van por detrás de la base de datos replicada en varios grados.
Por ejemplo, es posible tener una réplica de una base de datos de producción. En términos de recuperación ante desastres, la base de datos de producción es la base de datos primaria y la réplica es la base de datos secundaria. La función de replicación de SQL Server no sabe que las bases de datos asumen funciones diferentes en el contexto de la recuperación ante desastres. Por lo tanto, la replicación no tiene operaciones que respalden el proceso de recuperación ante desastres, por ejemplo, cambios de roles. El proceso de recuperación ante desastres debe implementarse por separado de la funcionalidad de SQL Server y debe ejecutarlo la organización que lo implementa porque no hay abstracciones de acceso de clientes.
Envío de archivos de respaldo
El envío de archivos de respaldo es otra estrategia de implementación de recuperación ante desastres. Un enfoque estándar para configurar y actualizar continuamente una base de datos secundaria es realizar una copia de seguridad completa inicial de la base de datos principal y copias de seguridad incrementales a partir de entonces. Todas las copias de seguridad incrementales se aplican a las bases de datos secundarias en el orden correcto. Existen muchas variaciones de este enfoque dependiendo de la frecuencia de las copias de seguridad incrementales y luego de la ubicación de almacenamiento del archivo de copia de seguridad (ubicación global o realmente copiada entre ubicaciones).
Esta estrategia no implica ninguna característica de disponibilidad de SQL Server al replicar cambios de estado desde la base de datos principal a cualquier base de datos secundaria. No utiliza el Agente SQL Server que se utiliza en el caso del trasvase de registros.
Para obtener más información, consulte la sección sobre Ejemplo: estrategia de recuperación ante desastres de copia de seguridad y restauración .
En comparación con el enfoque de replicación analizado en la sección anterior, tanto la replicación como el envío de archivos de respaldo tienen en común que el proceso de recuperación ante desastres se implementa fuera y por separado del conjunto de características de SQL Server. Desde la perspectiva del envío de cambios capturados, la replicación de SQL Server es más conveniente ya que implementa esta parte automáticamente mediante agentes SQL Server.
Nota sobre la interacción entre el ciclo de vida de la base de datos y el ciclo de vida de la aplicación
Una conmutación por error de una base de datos no es completamente separada e independiente de las aplicaciones que acceden a la base de datos. En principio, existen dos escenarios de fracaso.
En primer lugar, la aplicación permanece operativa mientras la base de datos realiza la conmutación por error. Desde el momento en que la base de datos principal no está disponible hasta el momento en que la nueva base de datos principal está operativa, las aplicaciones no pueden acceder a la base de datos en absoluto. Las conexiones existentes fallan y no se establecen nuevas conexiones. Durante este tiempo, la aplicación no puede atender a sus clientes, al menos en la medida en que la funcionalidad requiera acceso a la base de datos. Las aplicaciones deben reconocer cuándo está disponible la nueva base de datos principal para poder reanudar el procesamiento normal.
Las aplicaciones pueden tener un estado fuera de la base de datos, por ejemplo, en las memorias caché principales. La aplicación se asegura de que el caché sea coherente (sincronizado) con la nueva base de datos principal. Si no hubo ninguna pérdida de transacciones durante la conmutación por error, la caché podría ser coherente sin mantenimiento adicional. Sin embargo, si se produjo una pérdida de transacciones (datos) durante la conmutación por error, es posible que la memoria caché no sea coherente en relación con la nueva base de datos principal. La discusión análoga se aplica al estado compartido cuando, por ejemplo, algunos de los datos de la base de datos también forman parte de mensajes en colas o archivos en el sistema de archivos. Este aspecto de la coherencia de los datos está fuera del alcance de este documento porque no está directamente relacionado con la recuperación ante desastres de la base de datos.
En segundo lugar, es posible que una o más aplicaciones dejen de estar disponibles al mismo tiempo que la base de datos principal deja de estar disponible. Por ejemplo, si una región se desconecta, un sistema de aplicación que se ejecute en esa región no estará disponible como la base de datos principal en esa misma región. En este caso, también se debe recuperar la aplicación, no solo el sistema de base de datos principal. Junto con el proceso de recuperación ante desastres de la base de datos, debe iniciar un proceso de recuperación de aplicaciones similar. La aplicación recuperada debe conectarse a la nueva base de datos principal y reconfigurarse (por ejemplo, direcciones IP flotantes). La recuperación de aplicaciones está fuera del alcance de este documento.
Relación entre copia de seguridad y restauración para recuperación ante desastres
La copia de seguridad de una base de datos es independiente y ortogonal a la recuperación ante desastres de la base de datos. El propósito de la copia de seguridad de la base de datos es poder restaurar un estado consistente, por ejemplo, en caso de que una base de datos se pierda o se corrompa, o en caso de que sea necesario recuperar un estado anterior debido a fallas o errores de la aplicación.
La siguiente sección analiza cómo puede utilizar las copias de seguridad como un posible mecanismo para implementar la recuperación ante desastres de la base de datos. En este escenario, copia los archivos de copia de seguridad en la ubicación de la base de datos secundaria para que se pueda restaurar la base de datos secundaria. Sin embargo, los archivos de respaldo no son un requisito previo para la recuperación ante desastres; La discusión anterior sobre las características de disponibilidad presentó alternativas.
Alta disponibilidad y recuperación ante desastres
Tanto la alta disponibilidad como la recuperación ante desastres tienen en común que brindan soluciones para la indisponibilidad de la base de datos. Si una base de datos primaria deja de estar disponible, entonces una base de datos secundaria se convierte en la nueva base de datos primaria que es consistente y está disponible.
La diferencia entre alta disponibilidad y recuperación ante desastres es el dominio del único punto de falla. La alta disponibilidad soluciona una interrupción dentro de una región, por ejemplo, cuando falla una sola zona o un nodo. Una solución de alta disponibilidad proporciona una nueva base de datos primaria en otra zona de la misma región. Además, la alta disponibilidad aborda las fallas de nodos, no solo las fallas en la base de datos. Si un nodo que ejecuta una instancia de servidor SQL falla, se pone a disposición un nuevo nodo con una nueva instancia de SQL Server (consulte la discusión en la sección Siempre en la instancia de clúster de conmutación por error ).
La recuperación de desastres involucra al menos dos regiones. Aborda el caso donde una región completa no está disponible. La recuperación de desastres puede proporcionar una nueva base de datos primaria en una región diferente.
El SQL Server High disponibilidad presenta soluciones de soporte para alta disponibilidad y recuperación de desastres al mismo tiempo. Un solo grupo de disponibilidad puede abarcar las zonas dentro de una región, así como las regiones mismas. Un grupo de disponibilidad puede contener instancias de clúster de conmutación por error para abordar la alta disponibilidad.
SQL Server puede establecer grupos de disponibilidad dentro de una región para fallas de alta disponibilidad y zona, y combinarlo con el envío de registro en las regiones para abordar la recuperación de desastres.
Alternativas de implementación de DR
En las siguientes secciones, se muestran algunas posibles topologías de recuperación de desastres además de las discutidas hasta ahora. Estas topologías satisfacen diferentes requisitos RPO y RTO. Esta lista no es exhaustiva.
DR y HA INTRAREGIAL
Esta implementación es una variación de un grupo de disponibilidad que contiene FCIS, dentro de una región que consta de tres zonas. Las zonas se consideran el dominio de un solo punto de falla en este escenario.
En comparación con la implementación que se muestra anteriormente, cada FCI consta de tres nodos donde cada nodo se ejecuta en una zona diferente. El beneficio de esta configuración es que cualquiera o dos zonas pueden fallar sin requerir un proceso de recuperación de desastres.
El siguiente diagrama muestra esta configuración.
FCIS abarca todas las zonas, y cada FCI tiene una que ejecuta una instancia de SQL Server que acceda a la base de datos correspondiente. Hay dos instancias más de SQL Server que no se ejecutan en cada FCI que se pueden iniciar cuando una zona falla. Las bases de datos se muestran a través de las zonas ya que cada base de datos usa los discos de todos los nodos en un FCI determinado. No se muestra una aplicación para mayor claridad.
DR interregional: grupo de disponibilidad que abarca regiones
En este escenario, un grupo de disponibilidad se ejecuta en un clúster de conmutación por error de Windows Server y abarca dos regiones. Las regiones se consideran un dominio de falla único.
El siguiente diagrama ilustra esta configuración.
Para abordar posibles problemas de latencia, puede configurar las réplicas dentro de la región R1 para usar la propagación de transacciones sincrónicas, mientras que las réplicas en la región R2 están configuradas para usar la propagación de transacciones asíncronas.
DR interregional: transferencia de archivos de respaldo
Este escenario utiliza la transferencia de archivos de respaldo. Se vinculan dos grupos de disponibilidad en dos regiones. Cada grupo de disponibilidad tiene sus réplicas que reciben las transacciones sincrónicamente, por lo tanto, las réplicas secundarias de cada región se encuentran en una configuración de espera en caliente.
El siguiente diagrama ilustra esta configuración.
Sin embargo, los dos grupos de disponibilidad están conectados mediante transferencia de archivos de respaldo. El grupo de disponibilidad AG1 es el grupo de disponibilidad principal y el grupo de disponibilidad AG2 es el grupo de disponibilidad secundaria. Como los archivos de copia de seguridad están disponibles para el grupo de disponibilidad secundaria, se aplican allí. Este escenario se discute con más detalle en la siguiente sección, Ejemplo: estrategia DR de copia de seguridad y restaurante .
Topología de ubicación dual y ubicación terciaria
Si solo hay dos bases de datos, una base de datos primaria y una base de datos secundaria cada una en una región separada, entonces hay una duración desprotegida después de una conmutación por error desde el momento en que se ejecuta la nueva base de datos primaria y la nueva base de datos secundaria está lista. Si la nueva base de datos primaria no está disponible, mientras que la base de datos secundaria aún no se está ejecutando, entonces se produce un tiempo de inactividad difícil que solo se puede recuperar de cuando se establece una nueva base de datos primaria. Lo mismo se aplica a los grupos de disponibilidad.
Una tercera ubicación que ejecuta otra base de datos o grupo de disponibilidad secundaria puede eliminar la duración sin protección después de una conmutación por error. Esta configuración debe garantizar que una de las dos bases de datos secundarias siga siendo una base de datos secundaria y se reasigna a una nueva base de datos primaria para que no se produzca pérdida de datos. Como antes, lo mismo se aplica a los grupos de disponibilidad.
Ciclo de vida del Dr.
Independientemente de la solución de recuperación de desastres que elija, hay pasos de ciclo de vida comunes que se aplican.
En una situación real de recuperación de desastres, todos los interesados (propietarios de aplicaciones, grupos de operaciones y administradores de la base de datos) deben estar disponibles y participar activamente en la gestión de la recuperación de desastres. Las partes interesadas deben decidir sobre la autoridad de decisión (a veces denominada Maestría en la Ceremonia ) y los procesos de decisión que siguen. Además, las partes interesadas tienen que acordar sus métodos de terminología y comunicación.
Decidir iniciar un proceso de conmutación por error
A menos que la conmutación por error se inicie automáticamente, las partes interesadas deben tomar la decisión de iniciar una conmutación por error. Las diversas partes interesadas deben coordinar estrechamente la decisión cuando deciden comenzar la conmutación por error.
Comenzar un proceso de conmutación por error depende de varios factores, principalmente de la causa raíz de la base de datos primaria que no está disponible.
Si el proceso de recuperación de desastres lleva más tiempo que el tiempo esperado para resolver la falta de disponibilidad de la base de datos primaria, entonces una conmutación por error sería perjudicial. Primero, debe evaluar si restaurar la base de datos primaria es una opción factible.
Cuanto mejor se pruebe la estrategia de recuperación de desastres, y cuanto más rápido se implementa, más fácil es iniciar el proceso de conmutación por error porque se debe considerar menos incertidumbre en la decisión.
Ejecución del proceso de conmutación por error
El proceso de conmutación por error se prueba idealmente regularmente y, por lo tanto, bien conocido por los diversos interesados.
La autoridad de decisión debe ser consciente de todos los pasos que están teniendo lugar y de todos los problemas inesperados. La autoridad de decisión impulsa el proceso de conmutación por error y las partes interesadas son responsables de apoyar la autoridad de decisión.
Debe mantener estadísticas para el análisis postmortem y la mejora del proceso de conmutación por error; incluyendo duraciones de actividades, problemas que surgieron y cualquier confusión en los pasos del proceso de conmutación por error.
Protección faltante
Si solo tiene una base de datos secundaria, desde el momento en que la nueva base de datos primaria está disponible y operativa hasta que se configura una nueva base de datos secundaria, no existe una protección DR. Una falta de disponibilidad durante este tiempo puede causar un tiempo de inactividad difícil porque no es posible no fallaver a otra base de datos. Si esa situación surge, se debe configurar otra base de datos primaria y el RPA es el último punto que se puede reconstruir en función de las copias de seguridad disponibles.
A menos que se establezca la estrategia de recuperación de desastres para que haya protección en todo momento, cada parte interesada debe ser consciente de esta duración de la protección faltante para tomar precauciones adicionales durante los cambios de configuración o configuración del entorno.
Puede evitar este tiempo desprotegido si el acceso a la aplicación a la nueva base de datos primaria se retrasa hasta que la nueva base de datos secundaria esté en funcionamiento. Tan pronto como se aplican cambios de la base de datos primaria, la base de datos primaria está disponible para las aplicaciones. Si bien este enfoque evita en cualquier momento en que las aplicaciones estén desprotegidas de la DR, retrasa la finalización del proceso de recuperación de desastres.
Evite situaciones de cerebro dividido
Es importante que las aplicaciones no puedan acceder a una base de datos primaria y una base de datos secundaria al mismo tiempo, emitiendo operaciones DML. En esta situación, una inconsistencia de datos ocurre cuando la base de datos primaria y la base de datos secundaria no están de acuerdo en los valores de datos del mismo elemento de datos ( Split-Brain ). Esta arquitectura es especialmente importante si la base de datos principal no está disponible mientras continúa ejecutándose y puede recibir operaciones de escritura. Si la falta de disponibilidad es causada por la partición de la red intermitente, la partición puede detenerse en cualquier momento, y una aplicación podría volver a tener acceso. Si un proceso de conmutación por error está ocurriendo en ese momento, entonces los cambios en la antigua base de datos primaria podrían perderse, o algunas aplicaciones comienzan a operar en la nueva base de datos primaria, mientras que otras aún están accediendo a la antigua base de datos primaria.
Todo el acceso a la aplicación se desactiva en cualquier base de datos durante el proceso de conmutación por error para que ningún cambio de estado pueda ocurrir en ninguna de las bases de datos. Después de la conmutación por error, solo hay una base de datos disponible para operaciones de escritura, la nueva base de datos primaria.
Declaración de finalización
Después de que se completa el proceso de conmutación por error, todos los interesados deben ser informados explícitamente por la autoridad de decisión de que el proceso se realiza. Cualquier problema que aparezca después de la finalización debe tratarse como un incidente separado que ya no es parte del proceso de conmutación por error, sino parte del procesamiento regular. El problema podría ser una consecuencia de un problema con el proceso de conmutación por error, o un problema independiente por completo. Sin embargo, el enfoque de abordar el problema después de que se completa el proceso de conmutación por error podría ser diferente de cómo se aborda durante la ejecución del proceso de conmutación por error.
Análisis e informe post mortem
Para referencia futura y para mejorar su proceso de conmutación por error, organice un análisis post mortem inmediatamente para tomar nota de aspectos importantes, hallazgos y elementos de acción.
Escriba un informe que resume el evento de recuperación de desastres, causas raíz y todas las acciones tomadas. Este informe puede ser obligatorio si está implementando requisitos reglamentarios.
Prueba de DR y verificación
Debido a que la recuperación ante desastres no es parte de las operaciones diarias normales, su solución DR debe probarse regularmente para garantizar su funcionamiento adecuado cuando realmente sea necesario.
La frecuencia de las pruebas depende de los requisitos operativos y varía según la base de datos, la aplicación y la empresa. Además, los cambios en el entorno, como los cambios en la configuración de la red y las actualizaciones de componentes de infraestructura deberían desencadenar una prueba de recuperación de desastres si los cambios se realizan en los sistemas en los que se basa la solución de recuperación de desastres elegido. Cualquier cambio puede hacer que la solución de recuperación de desastres falle, o puede requerir ajustar el proceso de recuperación de desastres.
Puede probar manualmente iniciando el proceso de conmutación, o automáticamente siguiendo un enfoque de ingeniería del caos como se describe en la ingeniería del caos . Con las pruebas manuales, puede minimizar el impacto comercial en el tiempo de inactividad notable.
Un aspecto importante para las pruebas es recopilar estadísticas bien definidas. Algunas estadísticas importantes a considerar son las siguientes:
- Tiempo de recuperación real : mida el tiempo de recuperación real y compararlo con RTO.
- Punto de recuperación Real : Observe el punto de recuperación real y compárelo con RPO.
- Tiempo de detección de fallas: el tiempo que tardó en los DBA o el equipo de operaciones en realizar la necesidad de conmutación por error.
- Tiempo de iniciación de recuperación: el tiempo que llevó comenzar el proceso de conmutación por error después de que se detectó la falla.
- Fiabilidad: ¿Qué tan cerca se siguió el proceso de conmutación por error o se requirieron desviaciones de él? ¿Surgieron problemas inesperados que necesitaban ser investigados, posiblemente dando como resultado un cambio de estrategia de recuperación?
Según las estadísticas recopiladas, el proceso de conmutación por error puede tener que ajustarse o mejorarse para que coincida mejor con las expectativas RPO y RTO.
Ejemplo: estrategia DR de copia de seguridad y restaurante
Las siguientes secciones describen un ejemplo de estrategia de recuperación de desastres de copia de seguridad. Este escenario minimiza el uso de características de disponibilidad de servidor SQL para demostrar el esfuerzo requerido para especificar una estrategia de copia de seguridad y restauración DR y discutir aspectos que son invisibles en configuraciones más automatizadas.
Caso de uso
Se encuentra una primaria siempre en el grupo de disponibilidad y está operativo en la región R1. La secundaria siempre en el grupo de disponibilidad se agrega en la región R2 para una protección interregional adicional y disponible como conmutación por conmutación o objetivo de conmutación.
Estrategia
La estrategia de recuperación de desastres se basa en copias de seguridad de la base de datos. Se toma una copia de seguridad completa inicial seguida de copias de seguridad diferenciales posteriores. Las copias de seguridad se aplican a la secundaria siempre en el grupo de disponibilidad a medida que se toman. Todas las copias de seguridad se almacenan en un cubo de almacenamiento en la nube.
En este ejemplo, es aceptable después de la finalización de la conmutación por error que la nueva primaria siempre en el grupo de disponibilidad en R2 esté activo y desprotegido por un tiempo limitado hasta que la nueva secundaria siempre en el grupo de disponibilidad en R1 esté operativa.
No tiene que tener lugar alojamiento, ya que el grupo de disponibilidad Always en cada una de las regiones está igualmente calificado para servir como una producción siempre en el grupo de disponibilidad.
RTO y RPO
RPO se define en este ejemplo como un máximo de 60 minutos, por lo que se toma una copia de seguridad diferencial cada 60 minutos.
RTO no se establece explícitamente hasta una duración del tiempo, pero es lo más mínimo posible, inmediato es el mejor caso. El grupo de disponibilidad secundaria debe configurarse como un espera caliente. En caso de un espera caliente, todas las copias de seguridad se aplican inmediatamente para que la conmutación por error no se retrase la aplicación de copias de seguridad.
Estrategia DR de alto nivel
Las siguientes secciones describen la estrategia DR. Se mantiene breve para concentrarse en los pasos esenciales.
Configuración inicial
- Crear secundario siempre en el grupo de disponibilidad en la región R2.
- Evite el acceso a la aplicación al grupo de disponibilidad secundaria para que no se pueda ocurrir accidentalmente una situación cerebral dividida.
- Cree el cubo de archivo de respaldo B1 en el almacenamiento en la nube para contener la copia de seguridad completa inicial de Always On Disponibilidad Group en R1 y las copias de seguridad diferenciales por hora posteriores de siempre en el grupo de disponibilidad en R1. El orden correcto de las copias de seguridad diferenciales debe establecerse para que el proceso que aplique las copias de seguridad al grupo de disponibilidad secundaria pueda inferir el orden correcto. Un enfoque podría ser una convención de nombres que permita establecer el orden cronológico correcto basado en la fecha y la hora que es parte de los diversos nombres de archivos.
Estrategia de lanzamiento
- Aplique la copia de seguridad completa a la secundaria siempre en el grupo de disponibilidad en la región R2.
- A medida que las copias de seguridad diferenciales estén disponibles, aplique las que sean inmediatamente al grupo secundario siempre en el grupo de disponibilidad en R2. La solicitud inmediata es necesaria para abordar el RTO.
- Después de la copia de seguridad completa inicial y se aplican todas las copias de seguridad incrementales, la secundaria siempre en el grupo de disponibilidad está lista.
- Pruebe la estrategia DR realizando un cambio desde el grupo de disponibilidad principal al grupo de disponibilidad secundaria. Al menos una copia de seguridad incremental debe estar disponible durante la prueba.
Caso de conmutación por error o conmutación
En R2, los pasos esenciales son los siguientes:
- Asegúrese de que la última copia de seguridad diferencial se aplicara a la secundaria siempre en el grupo de disponibilidad en R2.
- Designe R2 como el nuevo primario siempre en el grupo de disponibilidad.
- Cree un nuevo cubo B2, tome una copia de seguridad completa como línea de base y abra el nuevo grupo de disponibilidad primaria para el acceso a la aplicación.
- Comience a tomar copias de seguridad diferenciales.
En R1, los pasos esenciales son los siguientes:
- Retire el cubo B1 porque ya no es necesario.
- Cuando el grupo Always On de disponibilidad en R1 vuelve a estar disponible (como un nuevo secundario siempre en el grupo de disponibilidad), evite el acceso a la aplicación y elimine todos los datos de la base de datos o restablezca a su estado inicial (vacío) (a menos que tuviera que ser recién creado).
- Aplique la copia de seguridad completa de la nueva primaria siempre en el grupo de disponibilidad en R2, y siga aplicando copias de seguridad diferenciales inmediatamente a medida que están disponibles (almacenados en el cubo B2).
Posibles mejoras
Una posible mejora en la estrategia DR es evitar tomar una copia de seguridad completa después de una conmutación por error o cambiar, mientras que aún puede configurar el nuevo grupo de disponibilidad secundaria rápidamente. En lugar de una sola copia de seguridad completa y copias de seguridad diferenciales posteriores, tome una copia de seguridad completa cada semana y cree un cubo semanal que contenga la copia de seguridad completa de la semana y todas las copias de seguridad diferenciales posteriores para esa semana. El nuevo grupo de disponibilidad primaria tiene que crear copias de seguridad diferenciales solo después de la conmutación por error (y no una copia de seguridad completa) y agregarlas al cubo. El nuevo grupo de disponibilidad secundaria simplemente aplica todas las copias de seguridad en el cubo de la semana actual. Si se utiliza este enfoque semanal, debe implementar una estrategia de limpieza o purga para eliminar las copias de seguridad obsoletas.
Otra mejora se basa en el hecho de que el nuevo grupo de disponibilidad secundaria fue el antiguo grupo de disponibilidad primaria. Si la base de datos existe y está operativa después de estar disponible nuevamente, una recuperación de tiempo en el tiempo a su última copia de seguridad diferencial evita tener que restaurarla completamente desde la última copia de seguridad completa como se describe en restaurar una base de datos de SQL Server a un punto en el tiempo (modelo de recuperación completa) . Este escenario reduce el esfuerzo y la cantidad de tiempo que el nuevo grupo de disponibilidad primaria no está protegido.
Las mejores prácticas de producción
Esta solución no especifica si las instancias de SQL Server en los grupos de disponibilidad Always On son instancias independientes o FCI. El tipo de instancias utilizadas debe decidirse antes de la implementación.
Hasta que un nuevo secundario siempre en el grupo de disponibilidad esté operativo después de una conmutación por error, hay un momento en que el Dr. no está protegido. Debe configurar un tercio siempre en grupo de disponibilidad en una tercera región.
Además, debe implementar el monitoreo para garantizar que se detecte cualquier falla o error. El monitoreo está fuera del alcance de este documento, pero es esencial para una solución de recuperación de desastres que trabaja.
¿Qué sigue?
- Configuración de SQL Server siempre en grupos de disponibilidad .
- Implementación de un SQL Server 2016 de múltiples sugerencias siempre en el grupo de disponibilidad en el motor Compute .
- Configuración de instancias de clúster de conmutación por error SQL Server .
- Ejecutando la clúster de conmutación por error de Windows Server .
- Cómo habilitar el registro en la nube, el monitoreo de la nube y el informe de errores para las aplicaciones .NET
- Instalación del agente de monitoreo de la nube .
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Eche un vistazo a nuestro Centro de arquitectura en la nube .