Editor Top
Las bases de datos son cosas maravillosas, hasta que se estropean. Luego, se queda esperando una recuperación para deshacer transacciones largas y reproducir archivos de registro. Cuanto más complejas sean las transacciones, más tiempo puede llevar la recuperación, lo que le permitirá depender de soluciones alternativas para mantener su negocio en funcionamiento. La recuperación lenta es costosa, cuesta tiempo y dinero.
Entonces, ¿cómo podemos recuperar nuestras bases de datos rápidamente, con una interrupción mínima de los procesos comerciales? A veces, eso requiere volver a la investigación básica o, en este caso, a un artículo de Microsoft Research de 2019 titulado “Recuperación de tiempo constante en Azure SQL Database”. El documento es fascinante y promete una forma de recuperar bases de datos en tiempo constante con archivos de registro más pequeños. Si bien está claramente dirigido a los servicios en la nube, donde mantener el almacenamiento de recuperación al mínimo tiene un valor económico distintivo, es una técnica que puede funcionar en cualquier lugar. Los beneficios ciertamente parecen claros, ya que la mayoría de las recuperaciones toman menos de tres minutos en lugar de horas.
A la antigua: ARIES
La mayoría de las bases de datos, incluidas SQL Server y Azure SQL, dependen del protocolo ARIES. El algoritmo para recuperación y aislamiento que aprovecha la semántica es una herramienta fundamental para las bases de datos modernas, que utiliza el registro de escritura anticipada para proporcionar una forma de recuperar el estado de la base de datos. ARIES utiliza tres tipos de registro, solo deshacer, solo rehacer y deshacer-rehacer. Estos registran cada actualización, con el tipo de registro que determina qué tipo de recuperación se puede intentar, con el objetivo de recuperar un estado anterior o posterior para cada operación de actualización en su base de datos, manejar cambios en sus registros y tablas.
Tanto SQL Server como Azure SQL usan el registro de transacciones para reproducir operaciones desde el último buen estado conocido, analizando el registro para determinar el estado de todas las transacciones registradas, rehaciendo las transacciones confirmadas en orden de la más antigua a la más reciente, mientras deshace las transacciones no confirmadas en orden inverso. del más nuevo al más antiguo. Una vez que se completa este proceso, su base de datos vuelve a estar en línea y lista para usar. SQL Server tiene mucho que manejar en una recuperación de ARIES, ya que una recuperación completa puede requerir dos o tres pasos a través de los registros, especialmente cuando se trata de transacciones largas que requieren múltiples actualizaciones.
VER: Política de recuperación de recursos y datos (TechRepublic Premium)
Aquí hay formas de mejorar el rendimiento, que generalmente implican aprovechar las técnicas de procesamiento en paralelo, pero requieren inversiones significativas en hardware y necesitan servidores de alta potencia. Eso podría estar bien para las bases de datos locales en las que está preparado para tener el hardware necesario a mano, pero no es realmente práctico en la nube, donde no solo la base de datos se ejecuta en hardware optimizado, sino que también puede ser mucho más grande. que en su propio hardware. Hay otros problemas relacionados con el uso de múltiples inquilinos de las plataformas en la nube, donde los recursos informáticos se comparten en el hardware que se ejecuta con una carga mayor. Las restricciones resultantes en las operaciones en la nube significan que la recuperación y la conmutación por error son mucho más probables que en las instalaciones, por lo que es esencial contar con un proceso de recuperación más rápido.
Y ahora lo nuevo: ADR
La nueva técnica de recuperación de bases de datos de Microsoft tiene como objetivo evitar los problemas que surgen con la recuperación en la nube, manteniendo el tiempo de inactividad al mínimo y sin requerir recursos adicionales, sin importar cuán grande sea la carga de trabajo.
El nuevo algoritmo de recuperación de tiempo constante combina ARIES con el control de concurrencia de múltiples versiones de SQL Server. Diseñado para administrar transacciones concurrentes, MVCC usa una base de datos temporal para almacenar diferentes versiones de filas como actualizaciones de datos, organizando cambios basados en ID de transacciones y marcas de tiempo. Este almacén se elimina cada vez que se reinicia la base de datos, ya que solo se necesita para mantener el aislamiento entre transacciones simultáneas. Las filas antiguas se eliminan de la base de datos, lo que mantiene bajos los requisitos de almacenamiento.
Esta tienda es la base para la recuperación de tiempo constante, que tanto Azure SQL y SQL Server ahora llaman Recuperación acelerada de bases de datos (ADR). En lugar de esperar a que se reviertan los registros de transacciones, ahora obtiene una reversión de transacciones casi instantánea, sin efectos de las transacciones de ejecución prolongada. Y como el sistema subyacente se basa en la tienda MVCC, se mantiene pequeño o, como lo describe Microsoft, «agresivamente truncado». Esta versión de MVCC forma parte de la base de datos del usuario y se denomina Almacén de versiones persistentes (el MVCC original sigue siendo un almacén independiente y sigue siendo compatible con las características de simultaneidad de Azure SQL).
Implementación de recuperación de tiempo constante
Si bien el proceso de recuperación es muy similar al utilizado por ARIES, es mucho más rápido ya que no necesita procesar todo el registro de transacciones. En su lugar, los datos del nuevo PVS se utilizan para proporcionar una reproducción instantánea de las transacciones entre el último punto de control y la transacción no confirmada más antigua. Esto deja solo un corto período de transacciones para rehacer. Al mismo tiempo, se utiliza un nuevo flujo de registro en memoria para reproducir operaciones no versionadas, como administración de caché y bloqueos, y al mismo tiempo mantener pequeño el registro de transacciones. Este flujo de registro secundario (el sLog) se copia en el registro de transacciones en los puntos de control, manteniéndolo pequeño pero asegurando que sus datos estén allí si necesita replicar una base de datos completa como parte de un proceso de recuperación empresarial.
Si usa Azure SQL Database y Aure SQL Managed Instance, entonces ya está usando ADR. También está disponible para otras bases de datos basadas en SQL Server, incluido SQL Server 2019 y Azure Synapse SQL. Si usa SQL Server 2019, es posible que ADR no sea necesario para todas sus operaciones, pero sin duda vale la pena considerarlo si tiene transacciones largas, registros de transacciones grandes o si la recuperación de la base de datos ha causado interrupciones significativas en el pasado. Hay algunos casos, como cuando usa la creación de reflejo de la base de datos, que no es compatible.
Para activar ADR, utilice la línea de comandos de SQL Server para activar o desactivar ADR y para definir el grupo de archivos utilizado para alojar sus datos de PVS. El proceso puede llevar algún tiempo, lo que afecta las operaciones normales, ya que bloquea su base de datos mientras se ejecuta, evitando que se inicien nuevas sesiones hasta que se complete la configuración. Una vez que se libera el bloqueo, su base de datos estará protegida por ADR.
Es un cambio simple que tiene un gran efecto, evitando tiempos de inactividad significativos en aplicaciones de datos complejas. Pero como todos los cambios simples, esa línea de código depende de mucho trabajo del equipo de SQL Server de Microsoft y sus contrapartes de Microsoft Research. Esta es una ocasión en la que podemos ver fácilmente cómo la investigación se convierte en un producto y cómo puede tener un gran impacto no solo en Azure sino también en nuestros propios centros de datos.
