En este documento se presentan estrategias de recuperación tras fallos para Microsoft SQL Server dirigidas a arquitectos y responsables técnicos que se encargan de diseñar e implementar la recuperación tras fallos en Google Cloud.
Las bases de datos pueden dejar de estar disponibles por varios motivos, como fallos de hardware o de red. Para proporcionar acceso continuo a la base de datos durante los fallos, se mantiene una base de datos secundaria que es una réplica de una base de datos principal. Tener la base de datos secundaria en una ubicación diferente aumenta las probabilidades de que esté disponible cuando la base de datos principal no lo esté.
Si la base de datos principal deja de estar disponible, tu aplicación crítica se conectará a una base de datos secundaria y continuará desde el estado de datos coherente más reciente para proporcionar servicios a tus usuarios con un tiempo de inactividad mínimo o nulo.
El proceso de poner a disposición una base de datos secundaria cuando falla la base de datos principal se denomina recuperación tras desastres (DR) de la base de datos. La base de datos secundaria se recupera de la indisponibilidad de la base de datos principal. Lo ideal es que la base de datos secundaria tenga exactamente el mismo estado coherente que la base de datos principal cuando no esté disponible o solo le falte un conjunto mínimo de transacciones recientes de la base de datos principal.
La recuperación ante desastres de bases de datos es una función esencial para los clientes empresariales. El principal motivo es la continuidad del negocio de las aplicaciones esenciales. Por ejemplo, una aplicación crítica genera ingresos (comercio electrónico), proporciona servicios fiables y continuos (gestión de vuelos o centrales eléctricas) o admite funciones que salvan vidas (monitorización de pacientes). En todos estos ejemplos, es de suma importancia que la aplicación esté disponible de forma continua, ya que se considera esencial.
La mayoría de los sistemas de gestión de bases de datos ofrecen funciones de recuperación tras desastres, incluido Microsoft SQL Server. En este documento de arquitectura se explica cómo se implementan las funciones de recuperación tras desastres que proporciona SQL Server en el contexto de Google Cloud.
Terminología
En las siguientes secciones se explican los términos que se usan en este documento.
Arquitectura de recuperación ante desastres general
En el siguiente diagrama se muestra la topología general de la arquitectura de recuperación ante desastres.
En el diagrama anterior, una aplicación accede a una base de datos principal mientras una base de datos secundaria está en espera y refleja el estado de la base de datos principal. Los clientes están accediendo 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 si inician 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 que se haya conectado, la aplicación podrá volver a servir a sus clientes. En una situación ideal, la aplicación está disponible en la base de datos secundaria lo antes posible, de modo que los clientes ni siquiera experimenten una interrupción. Una alternativa es esperar a que se pueda acceder de nuevo a la base de datos principal en lugar de iniciar la recuperación ante desastres. Por ejemplo, si el desastre es intermitente, puede que sea más rápido resolver el problema que hacer un failover.
Bases de datos principales y secundarias
Una o varias aplicaciones acceden a una base de datos principal 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 principal y contiene una réplica de la base de datos principal. Lo ideal es que el contenido de la base de datos secundaria coincida exactamente con el de la base de datos principal en cualquier momento. En muchos casos, la base de datos secundaria se retrasa con respecto a la principal debido a los retrasos en la aplicación de los cambios transaccionales realizados en la base de datos principal. Es posible asociar más de una base de datos secundaria a una base de datos principal, en función de la tecnología de la base de datos. SQL Server admite asociar más de una base de datos secundaria a una base de datos principal.
Recuperación tras fallos
Si una base de datos principal deja de estar disponible, la recuperación ante desastres cambia el rol 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, se selecciona una de ellas manualmente o en función de una lista de conmutación por error preferida. Las aplicaciones tienen que volver a conectarse a la nueva base de datos principal para seguir 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 restauración).
Es importante tener al menos una base de datos secundaria en todo momento por cada base de datos principal. Después de una recuperación ante desastres, asegúrate de que se haya configurado una nueva base de datos secundaria para gestionar futuras situaciones de recuperación ante desastres.
Conmutación por error, conmutación y respaldo
Hay varios casos en los que se puede cambiar el rol entre las bases de datos principal y secundaria:
- Conmutación por error: proceso por el que se cambia el rol de una base de datos secundaria para que sea la nueva base de datos principal y se conecten todas las aplicaciones a ella. La conmutación por error no es intencionada porque se activa cuando la base de datos principal deja de estar disponible. Puedes configurar la conmutación por error para que se active automáticamente o manualmente.
- Cambio: a diferencia de la conmutación por error, el cambio de una base de datos principal a una secundaria (nueva base de datos principal) se activa de forma intencionada para realizar pruebas iniciales y tareas de mantenimiento programadas. Prueba tu sistema de recuperación tras fallos con un cambio periódico habitual para asegurarte de que sigue siendo fiable.
- Conmutación por error: la conmutación por error es el proceso inverso en el que la nueva base de datos principal se convierte en la secundaria después de que se haya reparado la base de datos principal. Se activa un fallback de forma intencionada 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 hacer en función de los requisitos de recuperación ante desastres, como la ubicación o los recursos disponibles.
Google Cloud zonas y regiones
Los recursos, como las 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 fallo. Te recomendamos que despliegues un recurso con alta disponibilidad y tolerancia a fallos en varias zonas de una región.
Para protegerte frente a las interrupciones de servicio de una región completa, establece estrategias multirregionales para la recuperación tras fallos. Por ejemplo, la base de datos principal se encuentra en una región y su base de datos secundaria correspondiente se encuentra en otra región.
Modos activos: activo-pasivo y activo-activo
Una base de datos principal es una base de datos abierta para operaciones de lectura y escritura (operaciones DML) para que las aplicaciones que acceden a ella puedan gestionar su estado. La base de datos principal se denomina activa. La base de datos secundaria correspondiente es pasiva porque replica la base de datos principal, pero ninguna aplicación puede acceder a ella para realizar operaciones de cambio de estado. Después de una conmutación por error o de una conmutación, la base de datos secundaria se convierte en la nueva base de datos principal y pasa a ser una base de datos activa.
Tanto la base de datos principal como la secundaria pueden estar activas si la tecnología de base de datos admite esta función, llamada modo activo-activo. En este caso, las aplicaciones pueden conectarse a una u otra porque ambas bases de datos están disponibles para la gestión de estados. 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 sigue estando disponible. El modo activo-activo no se incluye en este artículo porque SQL Server no lo admite.
Modos de espera: caliente, templado, 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 instrucciones DML. No es necesario que la base de datos secundaria esté en funcionamiento, puede cerrarse. Si no se está ejecutando, el tiempo que se tarda en recuperarse de un desastre aumenta porque primero se debe poner en funcionamiento la nueva base de datos principal antes de que asuma el rol de nueva base de datos principal.
Hay varias formas de configurar la base de datos secundaria:
- Hot standby: la base de datos secundaria está activa y lista para que los clientes se conecten a ella. El último cambio disponible de la base de datos principal siempre se aplica en cuanto está disponible.
- Standby activo: una base de datos secundaria está activa, pero no se han aplicado todos los cambios de la base de datos principal.
- Standby en frío: una base de datos secundaria no está en ejecución. Primero, debe iniciarse y, después, sincronizarse con el último estado disponible.
- Sin modo de espera: el software de la base de datos se debe instalar primero y, a continuación, iniciarse antes de que se apliquen todos los cambios de la base de datos principal. Este modo es el menos caro porque no consume recursos cuando no es necesario, pero, en comparación con los otros modos, es el que más tarda en convertirse en una nueva base de datos principal.
Estrategias de recuperación ante desastres
En las siguientes secciones, se explican las estrategias de recuperación tras fallos que admite Microsoft SQL Server.
Dimensiones de la estrategia de recuperación
Hay varias dimensiones clave que debes tener en cuenta al seleccionar o implementar una estrategia de recuperación tras 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 los puntos que se seleccionen en el espectro. Las dimensiones clave son las siguientes:
- Objetivo de punto de recuperación (RPO): tiempo máximo aceptable durante el cual se pueden perder datos de tu aplicación debido a un incidente grave. Esta dimensión varía en función de las formas en que se usan 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 como estados de procesamiento identificables (última copia de seguridad completa o última copia de seguridad incremental). Independientemente de cómo se especifique el RPO, la estrategia de recuperación ante desastres debe implementar la medida concreta para que se pueda cumplir el requisito de RPO. El caso más exigente es la última transacción confirmada, lo que significa que no debe producirse ninguna pérdida de la base de datos principal a la secundaria.
- Objetivo de tiempo de recuperación (RTO). Tiempo máximo aceptable que tu aplicación puede estar sin conexión. Este valor suele especificarse como parte de un contrato de nivel de servicio más amplio. El RTO suele expresarse 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 totalmente operativa en un plazo de 5 minutos. El caso más exigente es el inmediato, de forma que los usuarios de la aplicación no se den cuenta de que se ha producido una recuperación tras un desastre.
- Dominio de punto único de fallo. Tú decides si una región se considera un dominio de punto único de fallo para tus requisitos de recuperación ante desastres. Si una región es un único punto de fallo para ti, la recuperación ante desastres debe configurarse de forma que se incluyan dos o más regiones en la configuración real. Si falla la región que contiene la base de datos principal, la base de datos secundaria de otra región se convierte en la nueva base de datos principal. Si se considera que el dominio de punto único de fallo es una zona, la recuperación tras desastres se puede configurar en varias zonas de una misma región. Si falla una zona, la recuperación tras desastres utiliza una segunda zona y hace que la nueva base de datos principal esté disponible en ella.
Decidir estas dimensiones clave es tomar una decisión entre el coste y la calidad. Cuanto menores sean el tiempo de recuperación y el punto de recuperación, más costosa puede ser la solución de recuperación tras desastres, ya que se utilizan más recursos activos. En las siguientes secciones, se describen varias estrategias de recuperación tras fallos alternativas que representan puntos en las dimensiones en el contexto de la base de datos de Microsoft SQL Server.
Estrategias de recuperación tras fallos para SQL Server
En el artículo Continuidad de la actividad empresarial y recuperación de bases de datos: SQL Server se describen las funciones de disponibilidad que puedes usar para implementar estrategias de recuperación tras desastres.
Preliminares
SQL Server se ejecuta en Windows y Linux. Sin embargo, no todas las funciones de accesibilidad 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 entre instancias y bases de datos. Una instancia es el software de SQL Server en ejecución, mientras que una base de datos es el conjunto de datos que gestiona una instancia de SQL Server.
Grupos de disponibilidad Always On
Los grupos de disponibilidad Always On proporcionan 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, que tiene 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 se gestiona mediante una instancia de SQL Server independiente. Un grupo de disponibilidad puede contener una o varias bases de datos. El número de bases de datos que se pueden incluir en un grupo de disponibilidad y el número de réplicas secundarias admitidas dependen 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 se produce una conmutación por error, una réplica secundaria se convierte en la nueva réplica principal. Como un grupo de disponibilidad incluye instancias de SQL Server independientes, todas las operaciones registradas en los registros de transacciones están disponibles en las réplicas. Cualquier cambio que no se registre 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 de SQL Server. Para proporcionar protección a nivel de base de datos y de instancia de SQL Server, debe configurar instancias de clúster de conmutación por error (FCIs). Esta arquitectura de implementación se describe más adelante en la sección Instancia de clúster de conmutación por error Always On.
Puedes proteger las aplicaciones de los cambios de rol mediante un listener. Un receptor admite aplicaciones que se conectan al grupo de disponibilidad. Las aplicaciones no saben qué instancias de SQL Server gestionan la base de datos principal o las réplicas secundarias en ningún momento. Los listeners requieren que los clientes usen una versión de .NET igual o superior a 3.5 con una actualización o 4.0, tal como se indica en Continuidad de la actividad empresarial y recuperación de bases de datos: SQL Server.
Los grupos de disponibilidad se basan en capas de abstracción subyacentes para proporcionar sus funciones. Los grupos de disponibilidad se ejecutan en un clúster de conmutación por error de Windows Server (WSFC), tal como se describe en el artículo Clústeres de conmutación por error de Windows Server con SQL Server. Todos los nodos que ejecuten instancias de SQL Server deben formar parte del mismo WSFC.
Las transacciones se envían desde la base de datos principal a todas las réplicas secundarias. Hay dos modos de envío de transacciones: síncrono y asíncrono. Puedes configurar cada réplica de forma independiente para que use uno u otro modo. En el modo de envío síncrono, la transacción en la base de datos principal solo se realiza correctamente si se completa en todas las réplicas secundarias que están vinculadas de forma síncrona. En el modo asíncrono, la transacción en la base de datos principal puede completarse aunque no se haya aplicado a todas las réplicas secundarias.
El modo de envío que elijas influirá en el tiempo de inactividad, el punto de recuperación y el modo de espera. Por ejemplo, si las transacciones se envían a todas las réplicas en modo síncrono, todas las réplicas tienen exactamente el mismo estado. El RPO más exigente (la transacción más reciente) se cumple, ya que todas las réplicas están totalmente sincronizadas. Las réplicas secundarias son de reserva activa, por lo que cualquiera de ellas se puede usar inmediatamente como base de datos principal.
La conmutación por error puede ser automática o manual. Es posible realizar una conmutación por error automática si todas las réplicas están totalmente sincronizadas. En el ejemplo anterior, esto es posible porque todas las réplicas están siempre totalmente sincronizadas.
En la siguiente figura se 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 se muestra 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 en la nube y, por lo tanto, no se implementa en un nodo ni en ningún otro tipo de recurso.
Instancia de clúster de conmutación por error Always On
Para protegerte frente a los fallos de nodos, puedes usar instancias de clúster de conmutación por error (FCIs) en lugar de instancias de SQL Server independientes. Hay dos o más nodos que ejecutan instancias de SQL Server para gestionar una base de datos (principal o secundaria). Los nodos que gestionan 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 demás nodos no ejecutan instancias de SQL Server. Si falla el nodo que ejecuta la instancia de SQL Server, otro nodo del clúster inicia una instancia de SQL Server y toma el control de la base de datos (conmutación por error de nodo). Este proceso de inicio automático de una instancia de SQL Server proporciona funciones de alta disponibilidad.
El clúster de 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 periodo de tiempo en el que no está disponible. No se pierden datos cuando se produce una conmutación por error de un nodo. Todo lo que se esté ejecutando en la instancia de SQL Server que ha fallado se moverá a otra instancia de SQL Server del mismo clúster. Por ejemplo, las tareas del agente de SQL Server o los servidores vinculados se mueven a otra instancia.
Los nodos de clúster de FCI se pueden configurar en diferentes Google Cloud zonas. Esta arquitectura no solo proporciona alta disponibilidad en caso de fallo de un nodo, sino también en caso de fallo de una zona. En la sección Alternativas de implementación de DR se describe un ejemplo de implementación de esta estrategia.
Aunque diferentes nodos gestionan la misma base de datos y la comparten, no se necesita almacenamiento común entre los nodos de un clúster FCI. SQL Server usa la función Espacios de almacenamiento directo (S2D) para gestionar bases de datos en discos de nodos dedicados. Para obtener más información, consulta el artículo sobre cómo configurar instancias de clústeres de conmutación por error de SQL Server.
En la siguiente figura se muestra el ejemplo de la sección anterior sobre grupos de disponibilidad AlwaysOn con instancias de clústeres de conmutación por error en lugar de instancias de SQL Server independientes. Cada FCI tiene una instancia de SQL Server activa que gestiona la base de datos.
Al igual que en el caso del grupo de disponibilidad, un FCI se representa como un rectángulo. Esto es solo para ilustrar que todos los nodos pertenecen al mismo FCI. Un FCI no es un recurso de nube y, por lo tanto, no se implementa en un nodo ni en ningún otro tipo de recurso.
Para obtener información más detallada, consulta Instancias de clúster de conmutación por error Always On (SQL Server).
Grupos de disponibilidad distribuidos
Los grupos de disponibilidad distribuidos son un tipo especial de grupo de disponibilidad. Un grupo de disponibilidad distribuido abarca dos grupos de disponibilidad: uno tiene el rol de grupo de disponibilidad principal y el otro, el 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, no se trata de 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 llama "forwarder". 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. Si se produce una conmutación por error del grupo de disponibilidad principal al secundario, se podrá acceder a la base de datos principal del nuevo grupo de disponibilidad principal para realizar operaciones de escritura.
Los grupos de disponibilidad principal y secundario no tienen por qué estar en la misma ubicación ni en el mismo sistema operativo. Sin embargo, cada grupo de disponibilidad debe tener un receptor instalado. El propio grupo de disponibilidad distribuido no tiene un agente de escucha. Los grupos de disponibilidad distribuidos no requieren que los dos grupos de disponibilidad estén en el mismo clúster de conmutación por error de Windows Server (WSFC). Toda la funcionalidad necesaria para que funcionen los grupos de disponibilidad distribuidos se incluye 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 admite 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 de tipo árbol en la que el grupo de disponibilidad principal forma parte de dos grupos de disponibilidad distribuidos diferentes e independientes.
Los grupos de disponibilidad distribuidos son el medio principal para implementar la recuperación ante desastres en diferentes sistemas operativos. Por ejemplo, el grupo de disponibilidad principal se puede configurar en Windows y un segundo grupo de disponibilidad correspondiente en Linux. Ambos grupos de disponibilidad forman un grupo de disponibilidad distribuido.
En el siguiente diagrama se muestran 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.
Al igual que en el caso de las FCI, un grupo de disponibilidad distribuido se representa como un rectángulo. Esto se muestra solo con 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 de nube y, por lo tanto, no se implementa en un nodo ni en ningún otro tipo de recurso.
Para obtener más información, consulta Grupos de disponibilidad distribuidos.
Envío de registros
El envío de registros de transacciones es una función de disponibilidad de SQL Server que se usa cuando el tiempo de inactividad y el tiempo de recuperación no son tan estrictos (tiempo de inactividad bajo o tiempo de recuperación reciente) porque la discrepancia en el estado entre una base de datos principal 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 tiempo de latencia, ya que los archivos de registro de transacciones se transportan de forma asíncrona y deben aplicarse en su totalidad a una base de datos secundaria.
La base de datos principal crea archivos de registro de transacciones y se hace una copia de seguridad de ellos, por ejemplo, en Cloud Storage. Cada archivo de registro de transacciones se copia en cada base de datos secundaria y se aplica a ella. Como la base de datos secundaria va por detrás de la principal, se encuentra en modo de espera activa. Los objetos y los cambios que no se registran en los registros de transacciones se deben aplicar 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 se debe configurar para cada base de datos por separado. Si un grupo de disponibilidad gestiona más de una base de datos, se deben configurar tantos procesos de envío de registros como bases de datos haya.
En caso de fallo, el proceso de recuperación ante desastres se debe iniciar manualmente, ya que no hay asistencia automatizada. Además, el acceso de los clientes no se abstrae de la base de datos principal y las secundarias mediante un listener. En caso de conmutación por error, los clientes deben poder gestionar por sí mismos el cambio de rol de una base de datos de secundario a principal conectándose a la nueva principal después de una recuperación ante desastres. Es posible crear abstracciones independientes de las instancias de SQL Server, como las direcciones IP flotantes, tal como se describe en las prácticas recomendadas para direcciones IP flotantes.
Como el envío de registros es en parte un proceso manual, puedes retrasar la aplicación de los archivos de registro copiados a las bases de datos secundarias de forma intencionada (a diferencia de los grupos de disponibilidad y los grupos de disponibilidad distribuidos, en los que los cambios se aplican inmediatamente). Un posible caso práctico es evitar que los errores de modificación de datos en la base de datos principal se apliquen a las bases de datos secundarias hasta que se resuelvan. En este caso, una base de datos secundaria a la que aún no se le haya aplicado un error de modificación de datos podría convertirse en la base de datos principal hasta que se resuelva el error de modificación de datos. Después, se puede reanudar el procesamiento normal.
Al igual que en el caso de los grupos de disponibilidad distribuidos, puede usar el envío de registros para soluciones multiplataforma en las que, por ejemplo, la base de datos principal se ejecute en Linux, mientras que las bases de datos secundarias se ejecuten en Linux y Windows.
En el siguiente diagrama se muestra una implementación multiplataforma con envío de registros. Ten en cuenta que no hay una configuración común en todas las regiones, como un grupo de disponibilidad distribuido en esta topología.
Los grupos de disponibilidad se encuentran en regiones independientes. Uno se ejecuta en Linux y el otro en Windows.
Para obtener más información sobre el envío de registros de SQL Server, consulta el artículo Acerca del envío de registros (SQL Server).
Combinar funciones de disponibilidad de SQL Server
Puedes implementar las funciones de disponibilidad de SQL Server en diferentes combinaciones. Por ejemplo, en el caso práctico anterior, el envío de registros se usó con diferentes grupos de disponibilidad instalados en distintos sistemas operativos.
A continuación, se muestra una lista de las posibles combinaciones de funciones de disponibilidad de SQL Server:
- Use el envío de registros entre grupos de disponibilidad instalados en el mismo sistema operativo.
- Tener un grupo de disponibilidad principal que use instancias de clúster de conmutación por error con un grupo de disponibilidad secundario que solo use instancias independientes de SQL Server.
- Usa un grupo de disponibilidad distribuido entre regiones cercanas y el envío de registros entre regiones ubicadas en continentes diferentes.
Estas son solo algunas de las combinaciones posibles de las funciones de disponibilidad de SQL Server.
La flexibilidad que ofrecen las funciones de disponibilidad de SQL Server permite ajustar una estrategia de recuperación tras desastres según los requisitos establecidos.
Replicación de SQL Server
La replicación de SQL Server no se considera una función de disponibilidad, pero en esta sección se describe brevemente cómo se puede usar esta función para la recuperación ante desastres.
La función de replicación permite crear y mantener réplicas de bases de datos. Los distintos tipos de agentes de SQL Server colaboran para capturar los cambios, transmitirlos y aplicarlos a las réplicas. Este proceso es asíncrono y las réplicas suelen ir con retraso con respecto a la base de datos de replicación en distintos grados.
Por ejemplo, es posible tener una réplica de una base de datos de producción. En cuanto a la recuperación tras desastres, la base de datos de producción es la base de datos principal 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 diferentes funciones en el contexto de la recuperación ante desastres. Por lo tanto, la replicación no tiene operaciones que admitan el proceso de recuperación ante desastres, como los cambios de rol. El proceso de recuperación ante desastres se debe implementar por separado de la funcionalidad de SQL Server y lo debe ejecutar la organización que lo implemente, ya que no hay abstracciones de acceso de cliente.
Envío de archivos de copia de seguridad
El envío de archivos de copia de seguridad es otra estrategia de implementación de recuperación tras desastres. Una forma habitual de configurar y actualizar continuamente una base de datos secundaria es hacer una copia de seguridad completa inicial de la base de datos principal y, después, copias de seguridad incrementales. Todas las copias de seguridad incrementales se aplican a las bases de datos secundarias en el orden correcto. Hay muchas variaciones de este enfoque en función de la frecuencia de las copias de seguridad incrementales y de la ubicación de almacenamiento de los archivos de copia de seguridad (ubicación global o copia entre ubicaciones).
Esta estrategia no implica ninguna función de disponibilidad de SQL Server al replicar los cambios de estado de la base de datos principal a cualquier base de datos secundaria. No utiliza el agente de SQL Server que se usa en el caso del envío de registros.
Para obtener más información, consulta la sección sobre la estrategia de recuperación tras desastres de copia de seguridad y restauración.
En comparación con el enfoque de replicación descrito en la sección anterior, tanto la replicación como el envío de archivos de copia de seguridad tienen en común que el proceso de recuperación tras desastres se implementa fuera del conjunto de funciones de SQL Server y por separado. Desde el punto de vista del envío de los cambios capturados, la replicación de SQL Server es más cómoda, ya que implementa esta parte automáticamente mediante agentes de 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 la base de datos no es completamente independiente de las aplicaciones que acceden a la base de datos. En principio, hay dos posibles situaciones de fallo.
En primer lugar, la aplicación sigue funcionando mientras se produce la conmutación por error de la base de datos. Desde el momento en que la base de datos principal no está disponible hasta que la nueva base de datos principal está operativa, las aplicaciones no pueden acceder a la base de datos. Las conexiones existentes fallan y no se establecen nuevas conexiones. Durante este tiempo, la aplicación no podrá prestar servicio 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 cachés de la memoria principal. La aplicación se asegura de que la caché sea coherente (sincronizada) con la nueva base de datos principal. Si no se ha perdido ninguna transacción durante la conmutación por error, es posible que la caché sea coherente sin necesidad de realizar más tareas de mantenimiento. Sin embargo, si se ha producido una pérdida de datos de transacción durante la conmutación por error, es posible que la caché no sea coherente con respecto a la nueva base de datos principal. La misma lógica se aplica al estado compartido cuando, por ejemplo, algunos de los datos de la base de datos también forman parte de los mensajes de las colas o de los archivos del sistema de archivos. Este aspecto de la coherencia de los datos no se trata en este documento porque no está directamente relacionado con la recuperación ante desastres de bases de datos.
En segundo lugar, es posible que una o varias aplicaciones dejen de estar disponibles al mismo tiempo que la base de datos principal. Por ejemplo, si una región se queda sin conexión, un sistema de aplicaciones que se ejecute en esa región no estará disponible, al igual que la base de datos principal de esa misma región. En este caso, también se debe recuperar la aplicación, no solo el sistema de base de datos principal. Además del proceso de recuperación tras un desastre de la base de datos, debes iniciar un proceso de recuperación de la aplicación similar. La aplicación recuperada debe conectarse a la nueva base de datos principal y volver a configurarse (por ejemplo, las direcciones IP flotantes). La recuperación de aplicaciones no se trata en este documento.
Relación entre la copia de seguridad y la restauración con la recuperación tras fallos
Crear una copia de seguridad de una base de datos es independiente y ortogonal a la recuperación tras desastres de la base de datos. El objetivo de las copias de seguridad de bases de datos es poder restaurar un estado coherente. Por ejemplo, si una base de datos se pierde o se daña, o si se tiene que recuperar un estado anterior debido a errores o fallos de la aplicación.
En la siguiente sección se explica cómo puedes usar las copias de seguridad como uno de los mecanismos posibles para implementar la recuperación tras desastres de la base de datos. En este caso, se copian los archivos de copia de seguridad en la ubicación de la base de datos secundaria para que se pueda restaurar. Sin embargo, los archivos de copia de seguridad no son un requisito previo para la recuperación ante desastres. En la sección anterior se han presentado alternativas a las funciones de disponibilidad.
Alta disponibilidad y recuperación tras fallos
Tanto la alta disponibilidad como la recuperación tras fallos tienen en común que proporcionan soluciones para la falta de disponibilidad de la base de datos. Si una base de datos principal deja de estar disponible, una base de datos secundaria se convierte en la nueva base de datos principal, que es coherente y está disponible.
La diferencia entre la alta disponibilidad y la recuperación tras fallos es el dominio de punto único de fallo. La alta disponibilidad aborda las interrupciones en 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 principal en otra zona de la misma región. Además, la alta disponibilidad aborda los fallos de los nodos, no solo los de las bases de datos. Si falla un nodo que ejecuta una instancia de SQL Server, se pone a disposición un nuevo nodo que ejecuta una nueva instancia de SQL Server (consulta la sección Instancia de clúster de conmutación por error Always On).
La recuperación tras fallos implica al menos dos regiones. Se trata del caso en el que una región completa deja de estar disponible. La recuperación tras desastres puede proporcionar una nueva base de datos principal en otra región.
Las funciones de alta disponibilidad de SQL Server admiten soluciones de alta disponibilidad y recuperación tras desastres al mismo tiempo. Un único grupo de disponibilidad puede abarcar las zonas de una región, así como las propias regiones. 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 en una región para lograr una alta disponibilidad y hacer frente a los fallos de zona, así como combinarlo con el envío de registros entre regiones para abordar la recuperación tras desastres.
Alternativas de implementación de recuperación ante desastres
En las siguientes secciones, se muestran algunas topologías de recuperación ante desastres posibles, además de las que se han analizado hasta ahora. Estas topologías cumplen diferentes requisitos de RPO y RTO. Esta lista no es exhaustiva.
Recuperación tras desastres y alta disponibilidad intrarregionales
Este despliegue es una variación de un grupo de disponibilidad que contiene FCI, dentro de una región formada por tres zonas. En este caso, las zonas se consideran el único punto del dominio de fallo.
En comparación con el despliegue que se ha mostrado antes, cada FCI consta de tres nodos, y cada nodo se ejecuta en una zona diferente. La ventaja de esta configuración es que pueden fallar una o dos zonas sin que sea necesario un proceso de recuperación ante desastres.
En el siguiente diagrama se muestra esta configuración.
Las instancias de clústeres de conmutación por error abarcan todas las zonas y cada una de ellas tiene una instancia de SQL Server en ejecución que accede a la base de datos correspondiente. Hay dos instancias de SQL Server más que no se ejecutan en cada FCI y que se pueden iniciar cuando falla una zona. Las bases de datos se muestran en todas las zonas, ya que cada base de datos usa los discos de todos los nodos de un FCI determinado. No se muestra una aplicación para que quede más claro.
Recuperación ante desastres interregional: grupo de disponibilidad que abarca regiones
En este caso, 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 único dominio de fallo.
En el siguiente diagrama se muestra esta configuración.
Para solucionar posibles problemas de latencia, puedes configurar las réplicas de la región R1 para que usen la propagación de transacciones síncrona, mientras que las réplicas de la región R2 se configuran para que usen la propagación de transacciones asíncrona.
Recuperación tras desastres interregional: transferencia de archivos de copia de seguridad
En este ejemplo se usa la transferencia de archivos de copia de seguridad. Se vinculan dos grupos de disponibilidad de dos regiones. Cada grupo de disponibilidad tiene sus réplicas recibiendo las transacciones de forma síncrona. Por lo tanto, las réplicas secundarias de cada región están en una configuración de espera activa.
En el siguiente diagrama se muestra esta configuración.
Sin embargo, los dos grupos de disponibilidad están conectados mediante la transferencia de archivos de copia de seguridad. El grupo de disponibilidad AG1 es el grupo de disponibilidad principal y el grupo de disponibilidad AG2 es el grupo de disponibilidad secundario. A medida que los archivos de copia de seguridad se ponen a disposición del grupo de disponibilidad secundario, se aplican en él. Este caso se analiza con más detalle en la siguiente sección, Ejemplo: estrategia de recuperación ante desastres de copia de seguridad y restauración.
Topología de ubicación dual y de ubicación terciaria
Si solo hay dos bases de datos, una principal y otra secundaria, cada una en una región diferente, habrá un periodo sin protección después de una conmutación por error, desde el momento en que se ejecute la nueva base de datos principal hasta que esté lista la nueva base de datos secundaria. Si la nueva base de datos principal deja de estar disponible mientras la base de datos secundaria aún no está en funcionamiento, se produce un tiempo de inactividad grave que solo se puede recuperar cuando se establece una nueva base de datos principal. Lo mismo ocurre con los grupos de disponibilidad.
Una tercera ubicación que ejecute otra base de datos secundaria o grupo de disponibilidad puede eliminar la duración desprotegida después de una conmutación por error. Esta configuración debe asegurar que una de las dos bases de datos secundarias siga siendo una base de datos secundaria y se reasigne a una nueva base de datos principal para que no se pierdan datos. Al igual que antes, esto también se aplica a los grupos de disponibilidad.
Ciclo de vida de la recuperación ante desastres
Independientemente de la solución de recuperación ante desastres que elijas, hay pasos comunes del ciclo de vida que se aplican.
En una situación real de recuperación ante desastres, todas las partes interesadas (propietarios de aplicaciones, grupos de operaciones y administradores de bases de datos) deben estar disponibles y participar activamente en la gestión de la recuperación ante desastres. Las partes interesadas deben decidir quién tiene la autoridad para tomar decisiones (a veces se le llama maestro de ceremonias) y qué procesos de toma de decisiones siguen. Además, las partes interesadas deben ponerse de acuerdo en su terminología y sus métodos de comunicación.
Decidir si se inicia 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 iniciarla. Las distintas partes interesadas deben coordinarse estrechamente para tomar la decisión de iniciar la conmutación por error.
El inicio de un proceso de conmutación por error depende de varios factores, principalmente de la causa principal por la que la base de datos principal no está disponible.
Si el proceso de recuperación ante desastres tarda más de lo previsto en resolver la indisponibilidad de la base de datos principal, la conmutación por error sería perjudicial. En primer lugar, debes evaluar si restaurar la base de datos principal es una opción viable.
Cuanto mejor se pruebe la estrategia de recuperación tras desastres y más rápido se implemente, más fácil será iniciar el proceso de conmutación por error, ya que habrá menos incertidumbre que tener en cuenta en la decisión.
Ejecución del proceso de conmutación por error
Lo ideal es que el proceso de conmutación por error se pruebe con regularidad y, por lo tanto, que los distintos participantes lo conozcan bien.
La autoridad competente debe estar al tanto de todos los pasos que se estén llevando a cabo y de todos los problemas inesperados que surjan. La autoridad de decisión dirige el proceso de conmutación por error y las partes interesadas son responsables de apoyar a la autoridad de decisión.
Debes conservar estadísticas para el análisis post mortem y la mejora del proceso de conmutación por error, incluidas las duraciones de las actividades, los problemas que hayan surgido y cualquier confusión en los pasos del proceso de conmutación por error.
Falta protección
Si solo tienes una base de datos secundaria, no habrá protección de recuperación ante desastres desde el momento en que la nueva base de datos principal esté disponible y operativa hasta que se configure una nueva base de datos secundaria. Si no está disponible durante este tiempo, puede producirse un tiempo de inactividad prolongado, ya que no se puede conmutar por error a otra base de datos. Si se da esta situación, se debe configurar otra base de datos principal y la RPA es el último punto que se puede reconstruir a partir de las copias de seguridad disponibles.
A menos que la estrategia de recuperación ante desastres se configure de forma que haya protección en todo momento, todas las partes interesadas deben ser conscientes de esta duración de la protección que falta para tomar precauciones adicionales durante la configuración o los cambios en la configuración del entorno.
Puedes evitar este periodo sin protección si el acceso de la aplicación a la nueva base de datos principal se retrasa hasta que la nueva base de datos secundaria esté operativa. En cuanto se aplican los cambios de la base de datos principal, esta está disponible para las aplicaciones. Aunque este enfoque evita que las aplicaciones estén desprotegidas frente a la recuperación ante desastres, retrasa la finalización del proceso.
Evitar situaciones de cerebro dividido
Es importante que las aplicaciones no puedan acceder a una base de datos principal y a una secundaria al mismo tiempo para emitir operaciones de DML. En esta situación, se produce una incoherencia de datos en la que tanto la base de datos principal como la secundaria no coinciden en los valores de datos del mismo elemento de datos (cerebro dividido). Esta arquitectura es especialmente importante si la base de datos principal deja de estar disponible mientras sigue ejecutándose y puede recibir operaciones de escritura. Si la no disponibilidad se debe a una partición de red intermitente, la partición puede detenerse en cualquier momento y una aplicación puede volver a tener acceso. Si se produce un proceso de conmutación por error en ese momento, es posible que se pierdan los cambios en la antigua base de datos principal o que algunas aplicaciones empiecen a operar en la nueva base de datos principal mientras que otras sigan accediendo a la antigua.
Durante el proceso de conmutación por error, se desactiva el acceso de todas las aplicaciones a cualquier base de datos para que no se produzcan cambios de estado en ninguna de ellas. Después de la conmutación por error, solo habrá una base de datos disponible para las operaciones de escritura: la nueva base de datos principal.
Declaración de finalización
Una vez completado el proceso de conmutación por error, la autoridad responsable debe informar explícitamente a todas las partes interesadas de que el proceso ha finalizado. Cualquier problema que se produzca después de completar el proceso debe tratarse como un incidente independiente que ya no forma parte del proceso de conmutación por error, sino del proceso normal. Puede que el problema sea consecuencia de un fallo en el proceso de conmutación por error o que se trate de un problema independiente. Sin embargo, la forma de abordar el problema después de que se complete el proceso de conmutación por error puede ser diferente de cómo se aborda durante la ejecución del proceso de conmutación por error.
Análisis y elaboración de informes post mortem
Para futuras consultas y para mejorar el proceso de conmutación por error, organiza un análisis post mortem inmediatamente para anotar los aspectos, las conclusiones y las tareas importantes.
Escribe un informe que resuma el evento de recuperación ante desastres, las causas principales y todas las acciones que se han llevado a cabo. Puede que este informe sea obligatorio si implementas requisitos normativos.
Pruebas y verificación de recuperación ante desastres
Como la recuperación ante desastres no forma parte de las operaciones cotidianas, tu solución de recuperación ante desastres debe probarse periódicamente para asegurar que funcione correctamente cuando 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 los componentes de la infraestructura, deben activar una prueba de recuperación tras desastres si los cambios se realizan en los sistemas en los que se basa la solución de recuperación tras desastres elegida. Cualquier cambio puede provocar que la solución de recuperación tras desastres falle o que sea necesario ajustar el proceso de recuperación tras desastres.
Puedes hacer pruebas manualmente iniciando el proceso de cambio o automáticamente siguiendo un enfoque de ingeniería del caos, tal como se describe en Ingeniería del caos. Con las pruebas manuales, puede minimizar el impacto en la empresa en caso de que se prevea un tiempo de inactividad considerable.
Un aspecto importante de las pruebas es recoger estadísticas bien definidas. Estas son algunas estadísticas importantes que debes tener en cuenta:
- Tiempo de recuperación real: mide el tiempo de recuperación real y compáralo con el RTO.
- Punto de recuperación real: observa el punto de recuperación real y compáralo con el RPO.
- Tiempo de detección de errores: el tiempo que tardaron los administradores de bases de datos o el equipo de operaciones en darse cuenta de que era necesario realizar una conmutación por error.
- Tiempo hasta el inicio de la recuperación: el tiempo que se ha tardado en iniciar el proceso de conmutación por error después de que se detectara el fallo.
- Fiabilidad: ¿se ha seguido el proceso de conmutación por error de forma precisa o se han necesitado desviaciones? ¿Han surgido problemas inesperados que deban investigarse y que puedan provocar un cambio en la estrategia de recuperación?
En función de las estadísticas recogidas, es posible que el proceso de conmutación por error tenga que ajustarse o mejorarse para que se adapte mejor a las expectativas de RPO y RTO.
Ejemplo: estrategia de recuperación tras fallos de copia de seguridad y restauración
En las siguientes secciones se describe una estrategia de recuperación tras desastres basada en copias de seguridad y restauración. En este caso, se minimiza el uso de las funciones de disponibilidad de SQL Server para mostrar el esfuerzo necesario para especificar una estrategia de copia de seguridad y restauración ante desastres, así como para analizar aspectos que no se ven en configuraciones más automatizadas.
Caso práctico
Un grupo de disponibilidad Always On principal se encuentra y funciona en la región R1. El grupo de disponibilidad Always On secundario se añade en la región R2 para ofrecer protección adicional entre regiones y está disponible como destino de conmutación por error o de cambio.
Estrategia
La estrategia de recuperación tras fallos se basa en copias de seguridad de la base de datos. Se hace una copia de seguridad completa inicial y, después, copias de seguridad diferenciales. Las copias de seguridad se aplican al grupo de disponibilidad secundario Always On a medida que se realizan. Todas las copias de seguridad se almacenan en un segmento de Cloud Storage.
En este ejemplo, es aceptable que, una vez completada la conmutación por error, el nuevo grupo de disponibilidad Always On principal de R2 esté activo y sin protección durante un tiempo limitado hasta que el nuevo grupo de disponibilidad Always On secundario de R1 esté operativo.
No es necesario realizar ninguna conmutación por error, ya que el grupo de disponibilidad Always On de cada región está igualmente cualificado para actuar como grupo de disponibilidad Always On de producción.
RTO y RPO
En este ejemplo, el RPO se define como un máximo de 60 minutos, por lo que se realiza una copia de seguridad diferencial cada 60 minutos.
El RTO no se define explícitamente como un periodo de tiempo, sino que debe ser lo más breve posible (lo ideal es que sea inmediato). El grupo de disponibilidad secundario debe configurarse como de espera activa. En caso de una espera activa, todas las copias de seguridad se aplican inmediatamente para que la conmutación por error no se retrase al aplicar las copias de seguridad.
Estrategia de recuperación ante desastres de alto nivel
En las siguientes secciones se describe la estrategia de recuperación ante desastres. Se ha mantenido breve para centrarse en los pasos esenciales.
Configuración inicial
- Crea un grupo de disponibilidad Always On secundario en la región R2.
- Impide que la aplicación acceda al grupo de disponibilidad secundario para que no se produzca una situación de cerebro dividido por error.
- Crea el segmento de copia de seguridad B1 en Cloud Storage para que contenga la copia de seguridad completa inicial del grupo de disponibilidad Always On de R1 y las copias de seguridad diferenciales por horas posteriores del grupo de disponibilidad Always On de R1. Se debe establecer el orden correcto de las copias de seguridad diferenciales para que el proceso que aplica las copias de seguridad al grupo de disponibilidad secundario pueda inferir el orden correcto. Una opción podría ser una convención de nomenclatura que permita establecer el orden cronológico correcto en función de la fecha y la hora, que forman parte de los nombres de los distintos archivos.
Estrategia de lanzamiento
- Aplica la copia de seguridad completa al grupo de disponibilidad Always On secundario de la región R2.
- Cuando haya copias de seguridad diferenciales disponibles, aplícalas inmediatamente al grupo de disponibilidad Always On secundario de R2. La aplicación inmediata es necesaria para abordar el RTO.
- Una vez que se haya aplicado la copia de seguridad completa inicial y todas las copias de seguridad incrementales, el grupo de disponibilidad Always On secundario estará listo.
- Prueba la estrategia de recuperación ante desastres realizando un cambio de la réplica principal a la secundaria. Durante las pruebas, debe haber al menos una copia de seguridad incremental.
Caso de conmutación por error o conmutación
En R2, los pasos esenciales son los siguientes:
- Asegúrate de que se haya aplicado la última copia de seguridad diferencial al grupo de disponibilidad Always On secundario de R2.
- Designa R2 como el nuevo grupo de disponibilidad Always On principal.
- Crea un nuevo contenedor B2, haz una copia de seguridad completa como base y abre el nuevo grupo de disponibilidad principal para que la aplicación pueda acceder.
- Empieza a crear copias de seguridad diferenciales.
En la ronda 1, los pasos esenciales son los siguientes:
- Elimina el contenedor B1 porque ya no es necesario.
- Cuando el grupo de disponibilidad Always On de R1 vuelva a estar disponible (como un nuevo grupo de disponibilidad Always On secundario), impide el acceso a la aplicación y elimina todos los datos de la base de datos o restablece su estado inicial (vacío), a menos que se haya tenido que crear de nuevo.
- Aplica la copia de seguridad completa del nuevo grupo de disponibilidad Always On principal de R2 y sigue aplicando copias de seguridad diferenciales inmediatamente a medida que estén disponibles (almacenadas en el contenedor B2).
Posibles mejoras
Una posible mejora de la estrategia de recuperación tras fallos es evitar hacer una copia de seguridad completa después de una conmutación por error o una conmutación, pero seguir pudiendo configurar el nuevo grupo de disponibilidad secundario rápidamente. En lugar de hacer una sola copia de seguridad completa y copias de seguridad diferenciales posteriores, haz una copia de seguridad completa cada semana y crea un contenedor semanal que contenga la copia de seguridad completa de la semana y todas las copias de seguridad diferenciales posteriores de esa semana. El nuevo grupo de disponibilidad principal tiene que crear copias de seguridad diferenciales solo después de la conmutación por error (y no una copia de seguridad completa) y añadirlas al contenedor. El nuevo grupo de disponibilidad secundario simplemente aplica todas las copias de seguridad del segmento de la semana actual. Si se usa este enfoque semanal, debes 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 secundario era el antiguo grupo de disponibilidad principal. Si la base de datos existe y funciona después de volver a estar disponible, la recuperación a un momento dado de su última copia de seguridad diferencial evita tener que restaurarla por completo a partir de la última copia de seguridad completa, tal como se describe en Restaurar una base de datos de SQL Server a un momento dado (modelo de recuperación completa). En este caso, se reduce el esfuerzo y el tiempo que el nuevo grupo de disponibilidad principal está desprotegido.
Prácticas recomendadas para la producción
Esta solución no especifica si las instancias de SQL Server de los grupos de disponibilidad AlwaysOn son independientes o instancias de FCI. El tipo de instancias que se va a usar debe decidirse antes de la implementación.
Hasta que un nuevo grupo de disponibilidad secundario Always On esté operativo después de una conmutación por error, habrá un periodo en el que la recuperación ante desastres no esté protegida. Deberías configurar un grupo de disponibilidad Always On en una tercera región.
Además, debes implementar una monitorización para asegurarte de que se detecta cualquier fallo o error. La monitorización no se incluye en este documento, pero es esencial para que una solución de recuperación tras fallos funcione.
Siguientes pasos
- Configurar grupos de disponibilidad Always On de SQL Server.
- Desplegar un grupo de disponibilidad Always On de SQL Server 2016 con varias subredes en Compute Engine.
- Configurar instancias de clústeres de conmutación por error de SQL Server
- Ejecutar clústeres de conmutación por error de Windows Server.
- Cómo habilitar Cloud Logging, Cloud Monitoring y Error Reporting en aplicaciones .NET
- Instalar el agente de Cloud Monitoring.
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.