Recientemente, ha habido muchas especulaciones algo nerviosas aquí y aquí) sobre qué opciones de alta disponibilidad estarán disponibles para SQL Server Standard Edition, una vez que se elimine la creación de reflejo de la base de datos (DBM) en una versión futura de SQL Server.
La creación de reflejo de la base de datos (DBM) quedó obsoleta en SQL Server 2012, y Microsoft sugirió que migre a los grupos de disponibilidad AlwaysOn (que requiere SQL Server Enterprise Edition), y señaló además:"Si su edición de SQL Server no es compatible con los grupos de disponibilidad AlwaysOn, use envío de registros”.
El lenguaje de obsolescencia exacto fue “Las siguientes características del motor de base de datos de SQL Server son compatibles con la próxima versión de SQL Server, pero se eliminarán en una versión posterior. No se ha determinado la versión específica de SQL Server. Está previsto que estas características se eliminen en una versión futura de SQL Server. Las funciones obsoletas no deben usarse en aplicaciones nuevas”.
¿Significa esto que debe dejar de usar la creación de reflejo de la base de datos para las nuevas aplicaciones de inmediato? Yo diría:"¡Por supuesto que no!" La creación de reflejo de la base de datos sigue funcionando igual que en el pasado y no se eliminará del producto durante bastante tiempo. Si tiene sentido usar DBM para ayudar a cumplir con sus objetivos de objetivo de punto de recuperación (RPO) y objetivo de tiempo de recuperación (RTO), continúe y use esa característica para nuevas aplicaciones. A diferencia de una función de lenguaje T-SQL en desuso (que podría ser mucho más difícil de reescribir, probar e implementar), será mucho más fácil cambiar de DBM a alguna otra técnica HA/DR en el futuro.
Históricamente, una función obsoleta de SQL Server en realidad no se eliminó en tres versiones principales después de la versión en la que se anunció públicamente la obsolescencia. Si Microsoft sigue ese patrón, la creación de reflejo de la base de datos no se eliminará hasta "SQL Server 2018" (dado SQL Server 2014, un "SQL Server 2016" especulativo y un "SQL Server 2018" aún más especulativo).
Según Mary Jo Foley, SQL Server 2014 debería estar disponible a principios de 2014. Supongamos que "SQL Server 2016" está disponible en enero de 2016 y "SQL Server 2018" está disponible en enero de 2018. Si esta línea de tiempo de versión completamente especulativa terminara siendo exactos, eso significaría que un cliente de SQL Server Standard Edition aún podría usar la creación de reflejo de la base de datos en "SQL Server 2018", que permanecería en el soporte principal de Microsoft hasta enero de 2023, y estaría en soporte extendido hasta enero de 2028 ¡Falta mucho tiempo para eso!
Esto le da a Microsoft (y a sus clientes de Standard Edition) mucho tiempo para encontrar un reemplazo viable para la creación de reflejo de la base de datos. Microsoft tiene varias opciones obvias aquí. Primero, podrían revertir la decisión de desaprobación de DBM. Eso no requeriría trabajo de desarrollo y prueba por parte de Microsoft, pero extendería la carga de soporte para DBM más en el futuro. En segundo lugar, podrían permitir una versión limitada de los grupos de disponibilidad en SQL Server Standard Edition (restringido a una o dos réplicas). En tercer lugar, parece muy probable que haya alguna característica relacionada con Azure que se ofrecerá como reemplazo de DBM). También podría haber una tecnología HA/DR completamente nueva disponible para entonces.
Los clientes de SQL Server Standard Edition tienen varias opciones obvias de lo que harán a medida que DBM se acerque a ser eliminado del producto. En primer lugar, podrían optar por simplemente permanecer en una versión de SQL Server que todavía usa la creación de reflejo de la base de datos (que podría ser cualquier versión desde SQL Server 2005 hasta mi "SQL Server 2018" imaginario). Actualmente, todavía hay una gran cantidad de clientes de SQL Server que utilizan felizmente versiones anteriores de SQL Server, como SQL Server 2000 y SQL Server 2005, y es probable que esa tendencia continúe. En mi experiencia, las organizaciones que eligen o necesitan usar SQL Server Standard Edition por cualquier motivo, también tienden a ser más lentas para actualizar a las nuevas versiones de SQL Server a medida que las lanza Microsoft.
En segundo lugar, podrían pasar a SQL Server Enterprise Edition en algún momento durante los próximos años. Después de todo, hay muchas características atractivas en SQL Server Enterprise Edition que tienen mucho sentido para usar en una aplicación de misión crítica que en realidad es clave para su negocio. Muchas organizaciones pueden encontrar los medios para pagar SQL Server Enterprise Edition en algún momento en el futuro, por varias razones.
En tercer lugar, estoy seguro de que habrá muchos incentivos fuertes de Microsoft para que los clientes simplemente trasladen gran parte de su infraestructura de base de datos a Azure durante los próximos años. Esta podría ser una alternativa perfectamente viable en muchas situaciones.
Por supuesto, no todo el mundo estará contento con alguna de estas alternativas. Si realmente le preocupa la obsolescencia de la creación de reflejo de la base de datos (sin que se anuncie públicamente un reemplazo completamente viable), tiene varias alternativas.
Primero, podría considerar calmarse y esperar un poco más para ver qué sucede a medida que aprendemos más sobre las versiones futuras de SQL Server a medida que pasa el tiempo. Es muy probable que Microsoft no haya tomado ninguna decisión final en esta área (pero puede apostar que lo han pensado). También puede intentar comunicarse en privado con las personas que conoce en el Grupo de productos para presentar su caso. La estrategia menos efectiva (al menos en mi experiencia) sería quejarse en voz alta y públicamente sobre este problema, especialmente antes de que Microsoft haya anunciado sus intenciones para el futuro. Ser la "rueda chirriante" pública a veces es contraproducente...
¿Qué piensas sobre esto? ¿La obsolescencia de la creación de reflejo de la base de datos (sin un reemplazo viable anunciado para la edición estándar) es una preocupación importante para usted? ¿Es esto parte de un gran diseño para obligarlo a usar Enterprise Edition o Azure? ¡Me encantaría escuchar tu opinión!
